일은 맡겨도, 책임은 맡길 수 없다

일은 넘어가는데, 책임은 왜 안 넘어가나

2026년의 에이전틱 AI는 확실히 예전과 다르다. 그저 질문에 답만 하고 끝나는 게 아니다. 스스로 계획을 세우고, 여러 단계를 차례로 실행하고, 필요하면 외부 도구까지 불러다 실제 업무를 처리한다. 우리 대신 메일을 보내고, 청구서를 정리하고, 코드를 배포하고, 고객 문의까지 마무리 짓는다.

그런데 도입을 검토하는 실무자들은 하나같이 어느 지점에서 멈칫한다. IT 전문매체 CIO는 2025년 말 클린트 볼턴의 기사에서 그 망설임을 이런 물음으로 정리했다. "정말 믿고 맡길 수 있는가, 실수했을 때 책임은 누가 지는가." 같은 기사에서 복셀 CTO 브라이언 오설리번은 그런 불신이 걷히지 않으면 에이전트가 "비용만 들고 실질적인 역할은 못 하는 시스템"에 그친다고 짚었다.

이건 기술이 얼마나 똑똑하냐의 문제가 아니다. 정확도가 아무리 높아도, 나머지 몇 퍼센트에서 사고가 났을 때 그 뒷감당을 누가 하느냐는 완전히 다른 질문이기 때문이다. 일은 넘길 수 있지만, 책임은 그렇게 쉽게 넘어가지 않는다.

왜 책임 소재가 유독 흐려지는가

사람에게 일을 맡길 때는 책임 구조가 비교적 단순하다. 담당자가 실수하면 담당자가 1차로 책임을 지고, 관리자가 감독한 몫을 나눠 진다. 사슬이 눈에 보인다.

그런데 여기에 에이전트가 끼어드는 순간, 그 사슬이 갑자기 여러 갈래로 흩어진다. 실제로 법률 실무에서는 에이전트가 사고를 냈을 때 우선 짚는 두 축을 '만든 개발사'와 '투입한 배치자'로 본다.

• 에이전트를 만든 개발사 — 모델과 도구를 설계한 쪽
• 에이전트를 배치한 회사 — 그 도구를 업무에 투입하기로 결정한 쪽
• 에이전트를 운영·감독한 담당자 — 권한을 주고 지켜본 쪽
• 에이전트 자체 — 법적 인격이 없어, 애초에 책임의 주체가 될 수 없는 존재

마지막 항목이 문제의 핵심이다. 에이전트는 잘못을 저질러도 책임질 법적 자격이 없다. 그래서 실제로 사고가 터지면, 책임은 위의 세 주체 사이 어딘가로 되돌아온다. 법률 논의에서 '책임의 공백(accountability gap)'이라 부르는 지점이 여기다 — 손해는 분명한데 정작 행동을 한 주체는 책임을 물을 법적 틀 바깥에 있다. 그런데 계약서에 누가 무엇을 진다고 또렷이 적혀 있지 않으면, 서로 미루기에 딱 좋은 구조가 되어 버린다.

에이전트가 알아서 판단하는 폭이 넓어질수록 "이게 누가 시켜서 한 일이냐"가 흐려진다. 그리고 그 모호함은 곧장 책임의 공백으로 이어진다.

자율성이 올라갈수록 책임은 무거워진다

역설적이게도, 에이전트가 유능해질수록 일을 맡기는 쪽의 부담은 오히려 커진다. 단순한 자동화 도구라면 "버튼을 잘못 눌렀네"로 끝날 일이, 스스로 판단하는 에이전트에게서는 예상 못 한 방향으로 커질 수 있기 때문이다.

예를 들어 보자. 환불을 승인하는 에이전트가 정책을 잘못 이해해, 있어선 안 될 환불을 대량으로 처리했다고 하자. 이건 단순한 오작동이 아니다. 에이전트가 자기 판단으로 내린 '결정'이다. 사람이라면 중간에 "뭔가 이상한데" 하고 손을 멈췄을 지점을, 에이전트는 지시받은 목표만 바라보며 끝까지 밀고 나간다.

그래서 자율성은 두 얼굴을 갖는다. 생산성을 끌어올리는 원천이면서, 동시에 사고를 키우는 증폭기다.

결국 책임 문제는 "이 에이전트에게 어디까지 권한을 줄 것인가"라는 설계 문제와 떼어 놓을 수 없다. 현실적인 출발점은 위험을 등급으로 나누는 것이다. 되돌릴 수 없는 행동—송금, 삭제, 외부 발송, 계약 체결—에는 반드시 사람의 최종 승인을 끼워 넣고, 위험이 낮은 반복 작업에만 완전한 자율을 허용하는 식이다. 이는 EU AI법이 고위험 시스템에 요구하는 인간 감독 원칙(제14조)과도 맞닿는다 — 감독의 강도는 시스템의 자율성과 위험에 비례해야 하고, 사람은 언제든 개입하거나 작동을 멈출 수 있어야 한다는 것이다.

책임을 관리하는 세 가지 축

SK AX는 2026년 1월 발표한 에이전트 AI 트렌드 보고서에서, 에이전트를 실제 업무에 안착시키려면 강력한 거버넌스 모델과 AI 관찰 가능성, 그리고 부서·에이전트 간 협력이 필수라고 짚는다. 이 세 가지는 그대로 책임 소재를 다루는 실무의 틀로 읽힌다.

첫째, 거버넌스. 에이전트가 무엇을 할 수 있고 무엇은 할 수 없는지, 어떤 행동에는 사람의 승인이 필요한지를 미리 정해 두는 일이다. 핵심은 순서다. 책임 소재를 사고가 난 뒤에 따지는 게 아니라, 사고가 나기 전에 계약과 정책으로 못 박아 두는 것. 개발사와의 계약서, 내부 권한 정책, 승인 워크플로가 여기에 들어간다.

둘째, 관찰 가능성(Observability). 에이전트가 언제, 무엇을 근거로, 어떤 행동을 했는지를 로그로 남기는 일이다. 책임을 가리려면 먼저 "무슨 일이 있었는지"를 되짚을 수 있어야 한다. 판단의 근거, 불러낸 도구, 참조한 데이터가 추적되지 않으면 책임을 논하는 일 자체가 불가능하다. 이는 수사적 과장이 아니다 — 2026년의 법률 실무 논의도, 입력값·추론 사슬·사람이 개입하거나 건너뛴 지점을 담은 감사 로그가 없으면 사고 후 책임 입증이 '구조적으로 불가능'해진다고 본다. 감사 로그는 사고 대응의 전제 조건인 셈이다.

셋째, 부서 간 협력. 책임은 IT 부서 혼자 짊어질 수 있는 게 아니다. 법무는 계약과 규제를, 보안은 권한과 접근을, 현업은 업무의 맥락을, 경영진은 어디까지 위험을 감수할지를 나눠 맡아야 한다. 책임 소재가 흐려지는 가장 큰 이유는, "이건 기술팀 일이지" 하며 한 곳에 떠넘길 때 생긴다.

결국은 '감독하는 사람'이 남는다

지금까지의 법적·실무적 합의는 대체로 한 방향을 가리킨다. 에이전트를 들여 이익을 얻는 쪽, 그리고 그 에이전트에게 권한을 주고 감독하기로 한 쪽이 결과에 책임을 진다는 것이다. 2026년 들어 여러 법역이 '합리적 감독(reasonable oversight)' 기준을 받아들이면서, 견고한 모니터링·감사 체계를 갖췄음을 입증하지 못하는 한 에이전트를 배치한 조직이 책임을 진다는 쪽으로 정리되고 있다.

실제 판례도 같은 방향이다. 2024년 캐나다에서 에어캐나다는 자사 웹사이트 챗봇이 잘못 안내한 환불 정책을 두고 "챗봇은 스스로 책임지는 별개의 존재"라고 항변했지만, 브리티시컬럼비아주 심판소는 이를 받아들이지 않고 회사가 그 안내에 책임을 지도록 했다. 다시 말해, "AI가 한 일이라 우리는 몰랐다"는 말은 면책 사유가 되기 어렵다. 오히려 감독 의무를 게을리한 책임이 하나 더 얹힐 뿐이다.

그래서 에이전트 도입은, 사람을 일에서 완전히 빼내는 프로젝트가 아니다. 오히려 사람의 역할을 '실행자'에서 '감독자'로 옮기는 프로젝트에 가깝다. 실무자는 이제 모든 작업을 직접 하지는 않는다. 그 대신 에이전트가 내린 결정을 검토하고, 이상한 신호를 알아채고, 위험한 행동을 곧바로 멈춰 세울 수 있는 자리를 지켜야 한다. 위임을 얻은 대가로, 감독의 책임이 남는 것이다.

도입 전에 스스로 던져야 할 질문

에이전트에게 업무를 맡기기 전에, 다음 질문에 답할 수 있는지 스스로 점검해 볼 만하다.

• 이 에이전트가 되돌릴 수 없는 행동을 할 수 있는가? 그렇다면 사람의 승인 단계가 마련돼 있는가?
• 사고가 났을 때, 개발사와 우리 회사 사이의 책임 배분이 계약서에 적혀 있는가?
• 에이전트의 판단과 행동을 나중에 되짚을 수 있는 로그가 남는가?
• 이상 상황에서 에이전트를 즉시 멈출 수 있는 사람과 절차가 정해져 있는가?
• 이 위임의 이익과 위험을, IT뿐 아니라 법무·보안·현업이 함께 검토했는가?

이 질문들에 또렷이 답하지 못한다면, 아직 그 업무를 맡길 준비가 안 된 것이다. 에이전트의 성능이 모자라서가 아니라, 책임의 구조가 준비되지 않았기 때문이다.

기술은 이미 상당한 수준에 올라와 있다. 남은 과제는 따로 있다. 그 기술을 어떻게 신뢰의 틀 안에 앉힐 것인가, 그리고 잘못됐을 때 누가 책임질지를 미리 정해 둘 것인가. 책임 소재를 사고 이후로 미루지 않는 것 — 그것이 에이전트 시대의 위임을 지탱하는 최소한의 조건이다.