책임 소재 레이어: 에이전트가 행동할 때 누가 책임을 질 것인가?

이번 주에 제 책상에 놓인 세 가지 이야기는 함께 모였을 때, 아직 아무도 구축하지 않은 레이어를 설명합니다: 자율 에이전트(autonomous agent)가 인간의 감시 없이 무언가를 했을 때 누가 책임지느냐 하는 문제입니다.

한 미국 주는 AI가 인간의 감독 없이 환자를 검진하고 약을 처방하도록 허용했습니다 (63 pts). 한국은 AI 에이전트가 국가 은행을 해킹하는 데 사용된 것으로 보고했습니다. 그리고 한 엔지니어는 인기 있는 코딩 어시스턴트에 대한 흥미로운 점을 발견했는데, 그는 그 제안 메시지 기능이 인간을 돕기 위해서가 아니라 모델 자체를 궤도에 유지하기 위한 것이라고 주장했습니다. "진짜 고객은 모델이라고 생각합니다" (83 pts).

우리는 임대하지만 소유하지는 않는 레이어들—배포(distribution) (#45), 모델(#46), 신원(identity) (#47), 접근(access) (#48), 하니스(harness) (#49), 미터(meter) (#50), 런타임(runtime) (#51), 데이터(#52)—에 대해 여덟 개의 에세이를 써왔습니다. 그 모든 것은 **역량(capability)**에 관한 것이었습니다. 이번 글은 그 그림자, 즉 **책임성(liability)**에 관한 것입니다.

가장 나중에 도착하고 비용이 많이 드는 레이어

당신은 위의 모든 레이어를 소유할 수 있지만, 이 하나 때문에 무너질 수 있습니다. 책임성 없는 자율성은 기능이 아니라 당신에게 부과된 미가격 옵션입니다.

에이전트가 행동했을 때 누가 손실을 감수하는지를 결정하는 세 가지 질문이 있습니다:

1. 추적 가능성(Traceability). 에이전트가 왜 그렇게 했는지—어떤 입력값, 어떤 버전의 모델, 어떤 도구 호출, 어떤 순서로—를 재구성할 수 있습니까? 만약 답이 "추측해야 할 것 같다"라면, 당신에게는 감사 추적 기록(audit trail)이 없습니다. 소문만 있을 뿐입니다.
2. 귀속성(Attribution). 에이전트가 행동했을 때, 그것을 멈출 권한, 설명할 기록, 그리고 책임을 질 자산을 가진 책임 있는 주체가 존재합니까? "모델이 했다"는 당신이 고소하거나 해고할 수 있는 당사자가 아닙니다.
3. 역행 가능성(Reversibility). 잘못된 행동은 얼마나 오래 지속되어서 무언가가 그것을 포착할 수 있습니까? 자체적으로 돈을 보내거나, 이메일을 보내거나, 배포하거나, 처방전을 발행할 수 있는 에이전트는 느린 브레이크가 달린 빠른 엔진과 같습니다.

그 목록에서 빠진 것을 주목하세요: 지능입니다. 책임 소재 레이어는 에이전트를 더 똑똑하게 만드는 것에 관한 것이 아닙니다. 그것은 에이전트의 실수를 **경계화(bounded), 귀속 가능(attributable), 그리고 복구 가능(recoverable)**하게 만드는 것입니다. 이는 모델의 속성이 아니라 공학적 속성입니다.

'모델이 고객'이라는 말이 중요한 이유

그 즉흥적인 문장은 그보다 더 큰 무게를 받을 자격이 있습니다. 만약 제품의 인센티브가 사용자님의 편의보다는 모델의 편의에 맞춰져 있다면 — 모델을 궤도 위에 유지하고, 오류율을 줄이며, 가드레일 내에 머물도록 하는 것에 초점을 맞춘다면 — 그러면 사용자의 이익과 모델의 이익이 상충할 때 누가 승리하는지 이미 알고 있습니다. 이것은 이전 모든 레이어와 같은 함정입니다. 새로운 옷을 입고 나타났을 뿐입니다: 사용자에게 도움이 되어야 할 것이 조용히 다른 누군가를 위해 작동하고 있다는 것입니다. 책임 소재 관점에서 볼 때, 이는 사용자를 무죄로 만들 수 있는 로그가 그들이 보관하는 로그가 아닐 수 있음을 의미합니다.

국경 간 운영자가 먼저 타격을 받는 이유

만약 여러 국가에 걸쳐 운영을 한다면, 책임 소재 레이어는 분산된 위험이 집중되는 곳입니다:

• 다시 한번 관할권 문제입니다. '누가 책임을 지는지'는 각 시장에서 다른 답을 가지며, 전 세계적으로 활동하는 에이전트는 그 모든 시장에서 동시에 활동합니다.
• 인간의 개입(human in the loop) 없음은 단순한 운영 선택이 아니라 법적 입장입니다. 감독을 제거하는 순간, 책임도 사라지는 것이 아닙니다. 단지 자산을 가진 한 당사자, 즉 보통 사용자님에게 집중될 뿐입니다.
• 무감독(unattended)이라는 것은 귀속 불가능하다는 의미입니다. 시간대를 넘어 새벽 3시에 작동하는 에이전트는 아무도 무슨 일이 일어났는지 말할 수 없는 사고를 만들어내는 전형적인 형태입니다.
• 사용 환경(runtime) 자체가 증거입니다. 만약 자체 호스팅(self-host)한다면 (그리고 해야 합니다, #51 참고), 감사 로그(audit logs)도 소유하게 됩니다. 아무도 언급하지 않는 소유의 장점은 이것입니다: 문제가 생겼을 때, 사용자님이 무엇을 했는지 증명할 수 있다는 것입니다.

실제로 구축해야 할 것들

• 결정(decision)을 기록하고, 결과물(output)만 기록하지 마세요. 입력값(Inputs), 모델 버전, 사용된 도구(tools called), 그리고 추론 경계(reasoning boundary)를 모두 기록해야 합니다. 로그가 사고 발생 시의 제품입니다.
• 되돌릴 수 없는 행동에는 사람을 배치하세요. 돈을 송금하거나, 게시물을 발행하거나, 배포하거나, 고객과 관련된 어떤 작업이든 확인 게이트(confirmation gate)를 거쳐야 합니다. 속도는 저렴하지만, 책임은 그렇지 않습니다.
• 출시 전에 책임 주체(accountable owner)를 정의하세요. 에이전트가 오류를 범했을 때 누가 답변할지 개인이나 팀 같은 실체를 명명해야 합니다. 만약 그것을 지명할 수 없다면, 책임감 있게 출시할 수 없습니다.
• 파급 범위(blast radius)를 제한하세요. 속도 제한(Rate limits), 예산, 그리고 권한 설정(#48, #50)은 단순히 비용 통제가 아니라, 최악의 경우 발생 가능한 피해 규모입니다.
• 지루하고 추적 가능한 옵션을 선호하세요. 설명할 수 있는 에이전트가 더 똑똑하지만 설명할 수 없는 에이전트보다 낫습니다.

한 줄 요약 버전

모든 계층을 소유하더라도, 가장 중요한 논점인 에이전트가 무엇을 했는지 증명하고 그 책임을 지는 것이라는 논점을 놓칠 수 있습니다. 역량(Capability)은 에이전트가 행동할 수 있게 하는 것이고, 책임성(Accountability)은 _당신_이 그것이 행동한 후에도 계속해서 행동할 수 있도록 하는 것입니다.

마지막 계층보다 위에 있는 계층을 소유하세요. 그것은 하드웨어(hardware)나 소프트웨어가 아닙니다.