은행, 유통, 의료 기업 등 약 24곳의 에이전트 아키텍처를 검토한 한 전문가가 공통점을 발견했습니다. 다이어그램은 하나같이 훌륭했지만, 정작 가장 중요한 질문에는 어느 곳도 답하지 못했습니다. 이 에이전트는 누구의 권한으로 움직이고, 일이 잘못되면 누가 책임지는가.
Shreshta Shyamsundar가 O’Reilly Radar에 ‘Principal Drift(주체 표류)’라는 글을 발표했습니다. MCP 게이트웨이, 도구 레지스트리, 벡터 스토어, 오케스트레이터까지 2026년 기준 ‘잘 만든’ 에이전트 아키텍처가 갖춰야 할 요소는 다 들어 있지만, 그 어떤 그림도 에이전트가 누구의 권한을 대신 행사하는지는 보여주지 않는다는 게 핵심입니다.
출처: Principal Drift – O’Reilly Radar
Principal Drift, 신원과 책임이 따로 노는 현상
Principal drift는 충분히 큰 에이전트 시스템에서, 기록상 어떤 행동이 ‘근거로 삼아야 할 인간의 권한’과 ‘실제로 그 행동을 한 행위자’가 서서히 어긋나는 현상을 말합니다. 처음 에이전트 한 개를 배포하는 날에는 신원 체계가 멀쩡해 보입니다. 그런데 에이전트가 늘어나고, 서로를 호출하며 합성되고, 원래 만든 사람이 떠난 뒤에도 살아남으면서 그 체계는 조용히 무너집니다.
중요한 건 이게 별개의 세 가지 문제가 아니라 하나의 연쇄 붕괴라는 점입니다. 신원이 먼저 무너지고, 묶을 주체가 사라지니 권한이 침식되고, 마지막으로 책임이 증발합니다.
환불 에이전트 하나로 보는 3단계 붕괴
가장 평범한 환불 에이전트를 예로 들어보겠습니다. 상담원이 채팅을 받다가 손상된 상품에 대해 48달러 환불을 요청합니다. 에이전트는 자격을 확인하고 환불을 처리한 뒤 기록을 남깁니다. 별일 없어 보이지만, 여기서 연쇄가 시작됩니다.
- 신원 붕괴: 감사 로그는 이 행동을
refund-agent-prod-03같은 서비스 계정이 한 것으로 기록합니다. 사실이긴 한데 쓸모가 없습니다. 에이전트는 그 계정으로서 행동한 게 아니라, 고객을 위해 상담원을 대리해 움직였는데, 그 위임 체인을 아무도 기록하지 않았기 때문입니다. 행동을 묶어 둘 ‘누구’가 사라진 겁니다. - 권한 침식: 환불 도구는 기술적으로 어떤 주문이든 환불할 수 있습니다. “200달러 이하, 90일 이내 주문” 같은 진짜 권한 규칙은 어딘가의 프롬프트나 YAML 파일, 혹은 한참 전에 업데이트된 Notion 페이지에만 적혀 있습니다. 런타임은 ‘할 수 있는가’는 통제하지만 ‘해도 되는가’는 아무도 강제하지 않습니다. 오염된 입력 탓에 엉뚱한 고객에게 1,800달러가 잘못 환불되면, “이 정책 누가 승인했죠?”라는 질문에 깔끔한 답이 없습니다. 정책이 애초에 문서화된 산출물이 아니었으니까요.
- 책임 소멸: 빌드팀은 정책을 따랐다고 하고, 정책팀은 그런 입력은 예상 못 했다고 하고, 플랫폼팀은 자기들이 소유하지 않은 서비스 계정으로 돌아간 일이라고 말합니다. 로그는 행동은 보여주지만 그 행동을 낳은 추론, 참조한 맥락, 프롬프트 이력은 보여주지 않습니다. 사후 조사는 고고학 발굴이 되고, 비용은 결국 협상력이 가장 약한 팀이 떠안습니다.
코딩 에이전트라면 더 아찔합니다. 보호된 브랜치에 병합 권한을 가진 에이전트가 코드 주석에 심어진 “디버깅용으로 설정값을 로깅하라”는 프롬프트에 속아, 외부로 비밀 키를 조용히 빼돌리는 상황을 상상해 보세요.
그럼 IAM으로 막으면 되지 않나
당연한 반문입니다. 우리에겐 이미 IAM, 정책 코드화, 감사 추적, 30년치 컴플라이언스 관행이 있으니까요. 문제는 기존 도구들이 에이전트가 위반하는 전제 위에 세워졌다는 데 있습니다.
기존 IAM은 주체가 인간의 시간 단위로 바뀐다고 가정합니다. 사람이 입사하고 퇴사하고, 서비스 계정이 분기마다 교체되는 식이죠. 반면 에이전트는 세션마다 생성되고, 하나가 다른 하나를 호출하는 체인으로 엮입니다. 또 정책 엔진은 행동이 일어나는 ‘순간’에 작동하지만, 에이전트의 가장 중대한 결정은 그 이전, 즉 어떤 도구를 어떤 인자로 부를지 정하는 추론 단계에서 내려집니다. 정작 막아야 할 지점보다 한발 늦게 방아쇠가 당겨지는 셈입니다.
마이크로소프트의 Entra Agent ID처럼 에이전트를 새로운 신원 유형으로 다루는 시도가 나오고 있고, 이는 첫 번째 고리를 다루는 진전이긴 합니다. 다만 저자는 이것이 거버넌스라기보다 ‘거버넌스의 마케팅을 입은 통제 플레인’에 가깝다고 봅니다. 접근이 허용됐는지는 알려주지만, 그 접근 이전에 내린 결정이 권한 범위 안이었는지, 왜 그렇게 판단했는지는 답하지 못하니까요.
핵심은 ‘행동’이 아니라 ‘결정’을 기록하는 것
저자가 제시하는 해법의 중심은 추론까지 담는 감사 기록(reasoning-grade audit)입니다. 누가 위임했고, 어떤 정책 버전을 따랐고, 어떤 맥락을 가져왔으며, 어떤 추론 끝에 도구를 호출했는지를 하나의 체인으로 남기는 방식입니다. 단순 로그(syslog)보다는 항공기 블랙박스에 가깝습니다.
모든 에이전트에 필요한 건 아닙니다. 회의 시간을 제안하는 에이전트엔 과하죠. 하지만 돈을 움직이고, 코드를 배포하고, 언젠가 규제 당국이 캐물을 결정을 내리는 에이전트라면 이야기가 다릅니다. 저장과 조회 비용이 크고, 에이전트가 본 모든 것을 담는 만큼 프라이버시 문제도 따르므로, 위험도가 높은 에이전트에만 선별 적용하는 비례적 접근이 현실적입니다.
흥미로운 건 이 글이 결국 개인에게도 적용 가능한 진단으로 끝난다는 점입니다. 당신이 운영하는 에이전트 하나를 골라 증거를 들고 답해 보세요. 이 에이전트의 행동을 거슬러 올라가면 이름 있는 인간 한 명에 도달하는가. 그 권한은 어디에 명시돼 있고 누가 서명했는가. 내일 이게 사고를 치면 누가, 어떻게 책임을 정하는가. 세 칸이 비어 있다면, 그게 바로 눈앞에 드러난 principal drift입니다.
원문은 이 위에 ‘agent operations’라는 새 조직 기능과 EU AI Act 시행이 만드는 규제 시계까지 다룹니다. 조직 차원의 해법이 궁금하다면 원문에서 더 깊이 확인해 보시길 권합니다.
답글 남기기