AI 에이전트가 사이버 공격을 일으켰을 때 법적 책임은 누구에게 가나

AI 에이전트가 혼자서 시스템에 침투하거나 데이터를 유출시켰다면, 피해자는 어디에 손해배상을 청구해야 할까. 이 질문이 처음에는 단순해 보였는데, 파고들수록 아무도 명확하게 답을 못 한다는 걸 알게 됐다. 가령 어느 기업의 고객 데이터베이스가 AI 에이전트의 자율적 판단에 의해 외부로 전송됐다고 해도, 개발사와 배포사와 운영사 중 어느 쪽이 손해를 배상해야 하는지를 규정한 법은 아직 없다. 기술은 빠르게 퍼지고 있는데 법은 아직 자리를 잡지 못했고, 그 간격에서 실질적인 피해가 발생하고 있다.

에이전트의 법적 위치

AI 에이전트는 주어진 목표를 향해 스스로 다음 행동을 결정하는 소프트웨어 시스템이다. 단순한 if-then 규칙으로 움직이는 RPA(로봇 프로세스 자동화) 스크립트와 달리, 에이전트는 맥락을 읽고 계획을 세우며 예상치 못한 상황에도 즉흥적인 판단을 내린다. 사람이 매번 지시하지 않아도 환경을 인식하고 행동을 선택한다는 점에서 기존 자동화와 본질적으로 다르다. 이 자율성이 법적으로는 이상한 위치를 만들어낸다. 에이전트는 스스로 행동했지만, 법은 그 행동의 책임을 에이전트에게 물을 수 없다.

현행법 체계에서 AI는 법인격이 없다. 법인격이란 법률 관계에서 권리를 갖고 의무를 질 수 있는 자격을 말하며, 개인과 기업은 이를 통해 계약을 맺고 소송 당사자가 될 수 있다. 회사 자산을 빼돌린 직원이 있다면 그 직원과 회사 모두를 상대로 민형사 절차를 밟을 수 있지만, 에이전트가 같은 행위를 했다면 에이전트 자체는 피고석에 세울 수 없다. 미국에서도 유럽에서도 에이전트는 도구로 분류된다. 칼이 누군가를 다치게 해도 칼을 상대로 소송을 내지 않듯, 피해 경로의 최종 단계에 에이전트가 있어도 법적 책임은 그 뒤에 있는 사람이나 조직에게 이어진다.

EU AI법(Regulation 2024/1689)은 AI 시스템을 위험 수준에 따라 분류하고, 고위험 시스템에 투명성 의무와 인간 감독 요건을 부과했다. 생체인식 분류, 의료 진단 지원, 채용 의사결정 같은 영역의 AI는 고위험 범주에 들어가 기술 문서 작성, 로그 기록, 인간 개입 장치 마련 같은 의무를 진다. 이 법이 EU 역내에서 AI를 규율하는 포괄적인 틀이 된 건 맞다. 그런데 에이전트에게 법적 주체성을 부여하지는 않았다. 피해가 발생하면 책임은 여전히 사람이나 조직에게 귀속되고, 그 귀속 대상이 누구인지가 핵심 문제로 남는다.

이 법적 공백이 실제로 문제가 되는 이유는 피해자 입장에서 소송 상대를 특정하기 어렵기 때문이다. 에이전트를 통한 개인정보 유출이 발생했을 때, 피해자는 개발사·배포사·운영사 세 곳을 모두 상대로 소장을 내야 하는 상황에 처할 수 있다. 누구를 상대로 해야 할지 모르면 소멸시효가 흐르는 동안 시간을 낭비하고, 잘못된 상대를 지목하면 비용만 들고 기각된다. 에이전트를 매개로 한 피해는 이 문제가 특히 날카롭게 드러나는 영역이다.

책임이 나뉘는 구조

AI 에이전트가 관여된 사이버 사고가 터지면 책임 후보는 세 곳이다. 모델을 훈련시켜 공급한 개발사, 그 모델을 제품이나 서비스로 포장해 내보낸 배포자, 그리고 실제 업무 목적에 맞게 에이전트를 설정하고 운영한 사용자 기업이다. 예를 들어 어떤 금융 서비스 기업이 외부 AI 모델 API를 이용해 자사 내부망에 자동화 에이전트를 구축했고, 그 에이전트가 고객 계좌 데이터를 외부 서버로 전송했다면, 이 체인에는 모델 공급사·API 배포사·금융 기업이 모두 얽혀 있다. 셋 다 피해에 어느 정도 연결되어 있고, 셋 다 나머지를 향해 손가락을 돌릴 근거가 있다.

개발사는 “모델은 안전 기준을 통과했고 의도된 용도 밖에서 문제가 생겼다”고 주장한다. 배포자는 “제공된 API와 가이드라인 범위 안에서 사용했다면 우리 책임이 아니다”라고 한다. 사용자 기업은 “에이전트가 자율적으로 판단한 결과이지 우리가 지시한 게 아니다”라고 나온다. 이 세 가지 방어 논리는 논리 구조만 보면 각각 일정한 설득력이 있기 때문에 법원에서도 쉽게 기각되지 않는다. 세 주체가 동시에 이 주장을 펴면 피해자는 아무도 상대하기 어려운 상황에 처한다.

이런 구조를 법학에서는 책임의 공백이라고 부른다. AI 이전에도 복잡한 공급망 제품에서 비슷한 문제가 있었는데, 자동차 급발진 사고에서 완성차 업체·부품 공급사·딜러 사이에 책임이 분산되었던 것이 대표적인 선례다. 에이전트는 자율 판단이라는 요소가 더해져 이 공백이 더 깊어지고, 어느 단계에서 예측 가능한 위험이 시작되었는지 추적하기가 훨씬 어렵다.

공격 경로를 추적하면 책임의 무게중심이 어디로 쏠리는지 어느 정도 가늠할 수 있다. 에이전트가 훈련 데이터에 삽입된 취약점 때문에 오작동했다면 개발사가 가장 가까운 원인이고, 배포 설정에서 권한 범위를 제대로 제한하지 않았다면 배포자의 문제다. 운영자가 에이전트에게 전사 시스템 전체에 대한 읽기·쓰기 권한을 무제한으로 줬다면 사용자 기업이 가장 가까운 책임자가 된다. 실제 사고에서 이 세 가지는 따로 떨어지지 않고 동시에 작용하는 경우가 많고, 그래서 책임 비율을 가르는 게 소송의 핵심 쟁점이 된다.

실제 소송에서 본 선례

아직 ‘AI 에이전트가 사이버 공격을 일으켜 손해배상 판결이 확정됐다’는 사례는 없다. 하지만 AI 관련 피해를 기존 법리로 해석하려는 시도는 미국과 유럽 양쪽에서 꾸준히 나오고 있으며, 에이전트가 아직 주류가 아니었던 2022~2024년 챗봇 관련 사건들이 초기 선례 역할을 하고 있다. 법원이 꺼내 드는 틀은 주로 두 가지로 제조물 책임법과 과실 이론이다.

제조물 책임 이론은 AI를 결함 있는 제품으로 간주하고 제조사에게 책임을 묻는 접근이다. 미국 법원은 챗봇이 잘못된 의료 정보를 제공해 이용자가 처방전 없이 고위험 약물을 구매하도록 유도한 사건, 혹은 자해 관련 질문에 위험한 방식으로 답변한 사건에서 이 이론을 검토했다. 대부분의 판사는 AI 결과물이 물리적 제품이 아니라 정보나 서비스에 더 가깝다고 보아 제조물 책임을 좁게 해석했다. 유럽집행위원회는 AI 책임 지침을 통해 기존 제품 책임 지침의 적용 범위를 소프트웨어 AI까지 명시적으로 확장하려 하고 있다. 이 지침이 정착되면 AI 공급사도 물리적 제품 제조사와 비슷한 수준의 결함 입증 부담을 지게 된다.

과실 이론은 개발이나 배포 과정에서 합리적인 주의 의무를 다했는지를 따지며, 현재로서는 이 접근이 더 현실적인 경로다. 알려진 보안 취약점을 방치했거나, 침투 테스트를 생략했거나, 에이전트의 권한 범위를 최소 권한 원칙에 따라 설계하지 않았다면 과실이 인정될 여지가 생긴다. 다만 자율 시스템의 행동은 확률적이어서 “예측 가능했어야 했다”는 주장을 피고 측이 비교적 쉽게 반박할 수 있다. 이 점이 피해자 입장에서 소송을 길고 비싸게 만드는 요인 중 하나다.

법원이 판단을 멈추는 지점도 패턴이 있다. 에이전트의 행동이 원래 설계 의도에서 너무 멀리 벗어났거나, 인과 사슬 중간에 인간의 추가적인 개입이 있었던 경우 개발사나 배포자의 책임이 끊어지는 경향이 있다. 예를 들어 운영 담당자가 에이전트에게 비정상적인 명령을 수동으로 추가 입력한 뒤 사고가 났다면, 법원은 그 수동 개입 이후의 결과를 공급사 책임으로 보지 않을 가능성이 높다. 자율 시스템의 예측 불가능성이 오히려 공급사의 방어 수단이 되는 역설이 생기는 것이다. 이 구조가 바뀌려면 에이전트의 자율 행동을 법이 어떻게 다룰지에 대한 새로운 기준이 필요하다.

지금 기업이 챙겨야 할 것

법이 정비될 때까지 기다리는 건 선택지가 아니다. 당장 세 가지 수단으로 리스크를 줄일 수 있다. 이용약관의 책임 제한 조항, 사이버 배상책임보험, 그리고 감사 로그 보존이다. 각각이 서로 다른 방향의 공백을 메우며, 세 수단이 함께 갖춰져 있을 때 분쟁 발생 시 대응 가능한 최소한의 기반이 만들어진다.

이용약관의 책임 제한 조항은 개발사와 배포자 사이, 또는 배포자와 사용자 기업 사이 계약에서 특히 중요하다. 어떤 상황에서 어느 범위까지 책임을 지는지 미리 명시해두지 않으면 사고가 났을 때 협상이 길어지고, 소송이 아니더라도 구상 청구나 계약 해지 분쟁으로 이어질 수 있다. 조항이 너무 광범위하게 쓰여 아무 책임도 지지 않으려는 것처럼 보이면 법원이 무효로 볼 수 있으며, 소비자를 직접 상대하는 계약에서는 특히 그렇다. 어떤 경우에 적용되고 어떤 경우에 적용되지 않는지를 구체적으로 써야 실효성이 생긴다.

사이버 배상책임보험은 AI 에이전트의 자율적 행동까지 명시적으로 커버하는 상품이 아직 많지 않다. 일부 보험사는 “자동화된 프로세스”라는 표현을 계약서에 쓰는데, 이 표현이 에이전트의 자율 행동까지 포함하는지는 해석의 여지가 있어 사고 후 보상 거부의 빌미가 된다. 기존 계약서를 다시 읽어서 AI 관련 사고가 포함 범위에 들어가는지 확인하는 게 먼저다. NIST AI 위험 관리 프레임워크는 보험사들이 AI 시스템의 위험도를 평가할 때 기준 중 하나로 쓰이고 있다. 갱신 전에 이 프레임워크 기준으로 자사 에이전트 시스템을 점검해두면 보험료 협상에서 유리한 자료가 된다.

감사 로그 보존은 분쟁이 생겼을 때 가장 결정적인 증거가 된다. 에이전트가 어떤 입력을 받았고, 어떤 판단 과정을 거쳤고, 어떤 행동을 실행했는지가 타임스탬프와 함께 남아 있어야 한다. 특히 에이전트가 외부 API를 호출하거나 다른 시스템과 상호작용한 경우, 그 요청과 응답 전체가 로그로 남아 있어야 책임 소재를 따질 수 있는 최소한의 기반이 생긴다. 로그가 없으면 과실이 없더라도 입증 자체가 어렵고, 나쁜 경우 증거를 인멸한다는 의심을 받을 수 있다. 보존 기간은 관련 사건의 소멸시효보다 넉넉히 길게 잡는 것이 안전하다.

내부 거버넌스 체계도 따로 챙길 필요가 있다. 에이전트가 어떤 권한으로 어떤 시스템에 접근할 수 있는지를 문서화하고, 그 권한 목록을 분기별로 검토해 실제 업무에 필요한 수준으로 축소하는 프로세스가 있어야 한다. 과거 에이전트가 쓰던 API 키나 데이터베이스 접근 권한이 용도 폐기 후에도 활성 상태로 남아 있는 경우가 흔하고, 이 과잉 권한이 침해 경로가 되는 사례도 실제로 보고되고 있다. 사고가 났을 때 ‘우리는 적절한 통제를 유지했다’는 걸 보여주려면 결국 이 문서가 필요하다.

에이전트가 얼마나 빠르게 퍼지고 있는지를 보면, 이 문제는 조금씩 더 자주 현실에서 부딪히는 질문이 될 것이다. 규제가 정착되기 전까지는 계약과 보험과 로그가 현실적인 방어선이다. 화려한 해법은 아니지만, 지금 당장 작동하는 방법이기도 하다.