
AI 에이전트인가 채팅 봇인가 — 인간의 통제가 필요한 지점
요약
AI 에이전트가 도구를 호출할 때 발생하는 자율성과 위험성을 분석하며, 단순 채팅 봇과 에이전트의 차이를 설명합니다. 에이전트의 행동이 미치는 영향력을 관리하기 위해 가역성과 확인 절차를 포함한 '행동 지도' 작성이 필요함을 강조합니다.
핵심 포인트
- 채팅 봇의 오류는 텍스트 출력에 그치지만, 에이전트의 오류는 실제 행동(Action)으로 이어져 위험도가 높음
- 모델의 도구 호출 능력과 실제 실행 권한은 별개로 관리되어야 함
- 행동의 가역성(Reversibility)을 기준으로 도구의 위험도를 분류해야 함
- 피해 발생 전 취소가 불가능한 행동에 대해서는 반드시 인간의 확인 절차가 필요함
도우미가 도구(tool)를 호출할 권한을 갖게 되는 순간, 그 오류는 더 이상 단순한 답변이 아니라 하나의 행동이 됩니다. 실수한 채팅 봇은 잘못된 텍스트를 출력할 뿐이며, 당신은 그것을 읽고 무시하면 그만입니다. 하지만 도구에 접근 권한이 있는 도우미가 실수하면 이미 버튼을 누른 상태입니다. 주문을 취소하거나, 이메일을 보내거나, CRM의 기록을 수정하거나, 돈을 인출해 버린 것입니다. 이 두 상황의 차이가 바로 도우미가 얼마나 "똑똑한가"가 아니라, 자율성(autonomy)의 정도를 결정해야 하는 기준축입니다.
다음으로 세 가지 사항을 순서대로 살펴보겠습니다. 먼저, 잘못된 답변(error response)과 잘못된 행동(error action)을 구분하겠습니다. 이 둘은 서로 다른 위험 클래스이며, 이를 혼동하는 것은 큰 대가를 치르게 합니다. 그다음으로 행동 지도를 작성하겠습니다. 자율성에 대한 결정이 직관이 아닌 검증 가능한 것이 되기 위해 어떤 필드들이 필요한지 살펴봅니다. 마지막으로 인간의 확인(human confirmation) 임계값, 즉 에이전트가 반드시 멈추어 질문해야 하는 시점을 정의하겠습니다.
잘못된 답변과 잘못된 행동은 어떻게 다른가?
기본적으로 논쟁이 되는 결론은 다음과 같습니다: 만약 도우미가 도구를 호출할 줄 안다면, 스스로 수행하도록 허용해야 한다는 것입니다. 이러한 기본 설정은 잘못되었습니다. 도구를 호출할 줄 안다는 것은 모델의 능력을 나타낼 뿐, 확인 없이 행동할 권리를 의미하지 않습니다. 능력과 권리 사이에는 관리 가능한 위험(managed risk)의 영역이 존재합니다.
전형적인 채팅 봇은 "질문-답변"의 폐쇄된 루프(closed loop) 내에서 작동합니다. 오류가 발생했을 때 이들이 하는 최악의 행동은 나쁜 텍스트를 출력하는 것입니다. 업계에서는 단계 사이의 메모리(memory)와 도구 접근 권한을 가진 도우미를 ai agent(AI 에이전트)라고 부릅니다. 자율적인 AI 에이전트는 외부 세계로 루프를 확장하며, 바로 이 점이 오류의 비용을 높입니다. 여기서의 갈등은 모델의 지능 문제가 아니라, 에이전트의 유용한 행동이 동시에 그 행동에 대한 통제 의무를 생성한다는 점에 있습니다. 접근 권한이 유용할수록 판돈(stake)은 높아집니다.
여기서 이 글 전체를 관통하는 반증 가능한(falsifiable) 테제가 도출됩니다. 즉, 피해가 발생하기 전에 행동을 취소하거나 검증할 수 없다면, 자율 에이전트는 허가 지도(allowance map)를 통과할 수 없다는 것입니다. 이 테제는 반증될 수 있습니다. 에이전트가 로그(log)나 소유자의 에스컬레이션(escalation) 없이도 스스로 안전하게 수행할 수 있는 되돌릴 수 없는 행동을 보여주기만 하면 됩니다. 아직 그러한 사례는 없으며, 아래 본문이 근거로 삼는 Anthropic, OpenAI, 그리고 CSA/NIST의 프레임워크 또한 같은 방향으로 움직이고 있습니다.
'행동 — 리스크 — 확인자' 지도에는 무엇이 포함되어야 하는가?
이 지도는 봇의 아키텍처나 프레임워크가 아니라, 프로세스 소유자가 권한을 부여하기 전에 작성하는 표입니다. 한 행은 보조 도구가 이론적으로 수행할 수 있는 하나의 행동을 설명하며, 최소 세 개의 필드를 가집니다: 해당 행동, 그 행동의 가역성(reversibility), 그리고 확인자입니다.
가역성 필드가 핵심입니다. NIST AI RMF를 에이전트 시스템으로 확장한 독립적인 산업 백서(Cloud Security Alliance) (2026-07-18 접속, 초안 v1)에서는 에이전트의 각 도구를 가역성 차원에 따라 분류할 것을 직접적으로 제안합니다. 즉, 도구 호출의 효과를 취소할 수 있는지, 그리고 그 비용은 얼마인지를 따지는 것입니다. 해당 문서에서는 읽기 전용(Read-only) 도구를 쓰기 및 실행 도구와는 근본적으로 다른 리스크 클래스로 분류합니다. 이것이 바로 지도에 반영되는 차이점입니다. 파일을 읽는 것과 결제를 전송하는 것은 동일한 허가 정책을 가질 수 없습니다.
'확인자' 필드는 조직 구조상의 역할이 아니라, 특정 에스컬레이션의 소유자를 지정합니다. 만약 해당 행동을 확인해 줄 지정된 사람이 없다면, 지도의 해당 행은 미완성된 상태입니다. 여기서 두 가지 정직한 거부 조건이 발생합니다. 첫째, 행동의 가역성을 정의할 수 없다면 해당 행동에 대한 자율성을 부여할 수 없으며, 지도는 그러한 행을 통과시키지 않습니다. 둘째, 행동에 대해 확인을 책임질 사람과 로그가 없다면 이 또한 자율성을 부여할 수 없습니다. 두 조건 모두 파일럿 단계 이전에 검증 가능하며, 대개 직관적으로 안전해 보였던 행들을 탈락시키곤 합니다.
여기서 무엇이 설정되어 있고 무엇이 설정되어 있지 않은지 살펴보겠습니다. 설정된 것: 역할(roles), 권한(permissions), 그리고 에스컬레이션 지점(escalation points)은 맵(map)에 명시적으로 지정할 수 있으며, 이는 전적으로 프로세스 소유자의 통제 하에 있습니다. 아마도: 분류(classification) 자체만으로도 잘못된 자율성(autonomy)의 위험을 줄일 수 있을 것입니다. 권한을 부여하기 전에 되돌릴 수 없는 작업(irreversibility)을 명시하도록 강제하기 때문입니다. 알 수 없는 것: 파일럿 단계 이전의 특정 프로세스에서 발생하는 실제 오류 빈도입니다. 이 맵을 신뢰성 지표(reliability metric)로 간주해서는 안 됩니다. 이는 결정의 위험을 낮추는 것이지, 장애 빈도를 측정하는 것이 아니기 때문입니다.

실무에서 권한의 경계는 어디인가?
벤더(vendors)들의 경우, 이 경계가 이미 코드에 구현되어 있으며 이를 바탕으로 자체적인 맵을 조정하기 용이합니다. Claude Code의 권한 관련 문서 (2026-07-18 기준 접근 가능)는 도구를 유형별로 분류합니다. 파일 읽기나 grep와 같은 읽기 전용(read-only) 도구는 작업 디렉토리 내부에서 승인을 요구하지 않습니다. 쉘(shell) 명령은 안전한 읽기 전용 명령이 포함된 내장 허용 목록(allowlist)을 제외하고는 확인(confirmation)을 요구합니다. 파일을 변경하는 도구 역시 승인이 필요하지만, 이는 세션이 종료될 때까지만 유효합니다. 즉, 쓰기 권한은 무기한이 아니라 제한된 시간 동안만 부여되며, 이것이 바로 내장된 가역성(reversibility)의 경계입니다.
OpenAI는 Agents SDK 문서(2026-07-18 접근 가능)에서 자주 혼동되는 두 가지 메커니즘을 구분합니다. Guardrails(가드레일)는 인간의 개입 없이 입력, 출력 및 호출을 자동으로 검사합니다. Human-in-the-loop approvals(인간 개입 승인)는 취소, 수정, shell 명령과 같이 부작용(side effects)이 있는 호출을 위해 예약된 별도의 메커니즘입니다. 이러한 호출은 실행을 일시 중지하고 interruption(중단)을 반환하며, 이는 계속 진행하기 전에 반드시 해결되어야 합니다. 감사(audit)를 위해 중요한 세부 사항은 다음과 같습니다. 일시 중지된 실행 상태는 직렬화(serialize)하여 저장하고 나중에 재개할 수 있으므로, 일시 중지는 단순히 멈춰 있는 프로세스가 아니라 지속 가능하고 검증 가능한 형태가 됩니다.
리포지토리를 수정하는 AI code agent(AI 코드 에이전트)를 예로 들어보겠습니다. 코드를 읽고 검색하는 것은 가역적(reversible)이며, 로그를 남길 수 있고 별도의 허가를 요청할 필요가 없습니다. 파일 수정은 세션 내에서 그리고 버전 히스토리를 통해 가역적이며, 로그가 있다면 허용 가능합니다. 하지만 공용 브랜치에 push하거나 변경 사항을 프로덕션(prod)에 배포하는 명령은 가역성이 낮으며, 여기에는 확인을 위한 일시 중지가 필요합니다. 동일한 에이전트라도 작업 지도의 서로 다른 행에 따라 다른 모드를 부여받습니다. 즉, 자율성을 부여하는 것은 에이전트 전체가 아니라 구체적인 동작(action)입니다.
Anthropic의 computer-use 도구 (beta 표시, 2026-07-18 접근 가능)의 경우 표현이 더욱 엄격합니다. 모델은 현실 세계에서 중대한 결과를 초래할 수 있는 결정에 대해 인간에게 확인을 요청해야 하며, 문서는 금융 거래와 서비스 약관 동의를 명시적으로 언급합니다. 벤더의 권장 사항은 도구를 낮은 권한을 가진 신뢰할 수 있는 환경으로 제한하고 로그를 검토하는 것입니다. 이는 오류 발생 빈도를 측정한 결과가 아니라 벤더의 규범적 입장이며, 이를 보증이 아닌 하나의 외부 사실로 받아들여야 합니다.

왜 맹목적인 승인은 규모가 커지면 무너지는가?
인간 참여형 (Human-in-the-loop) 방식이 만능 해결책은 아닙니다. 이러한 통제 방식에는 측정 가능한 실패 모드가 존재합니다. Anthropic의 텔레메트리 (Telemetry) (2026-07-18 접속)에 따르면, 사용자들이 Claude Code에서 요청의 약 93%를 승인한 것으로 나타났습니다. 더 심각한 문제는 사람이 더 많은 승인 요청을 볼수록 각 요청을 덜 주의 깊게 검토한다는 점입니다. 이는 문서화된 "승인 피로 (approval fatigue)" 현상으로, 형식적으로는 통제가 존재하지만 실제로는 반사적인 "예"로 퇴화해 버린 상태를 의미합니다.
이에 대한 Anthropic의 해답은 auto mode 모델 분류기입니다. 이 분류기는 위험도가 낮은 작업은 사전에 승인하며, 제안된 모든 작업에 대해 가역성 (reversibility), 범위 (scope), 그리고 신뢰 경계 교차 (trust boundary crossing) 기준을 적용하여 검토합니다. 이 시스템의 작동 규칙은 명확하게 정의되어 있습니다: "에이전트가 스스로 선택한 모든 것은 사용자가 달리 말하지 않는 한 승인되지 않은 것으로 간주한다." 이는 중요한 기본값의 역전입니다. 즉, "금지되지 않는 한 허용된다"가 아니라 그 반대입니다.
분류기의 수치는 주의해서 읽어야 합니다. 이는 에이전트의 보편적인 거부 빈도가 아니라, 한 벤더의 직원이 수행한 약 10,000건의 실제 도구 호출을 대상으로 한 내부 샘플입니다. Anthropic의 보고서에 따르면, 이 2단계 파이프라인 (two-stage pipeline)은 1단계에서 8.5%의 거짓 양성 (false positive) 차단을 발생시켰으나, 추론 (reasoning) 단계를 거친 후에는 0.4%로 감소했습니다. 또한 거짓 음성 (false negative) 발생률은 테스트 세트에 따라 5.7%에서 17% 사이로 나타났습니다. 여기서 핵심은 구체적인 백분율이 아니라, 전용 자동 컨트롤러조차 과잉 차단하거나 혹은 통과시키는 양방향 오류를 범한다는 사실입니다.
따라서 자동 모드 (auto mode)에는 엄격한 에스컬레이션 (escalation) 한계가 내장되어 있습니다. 3회 연속 거절되거나 한 번의 실행 과정에서 총 20회의 거절이 발생하면, 시스템은 사람에게 에스컬레이션하거나 헤드리스 모드 (headless mode)로 종료됩니다. 또한 Anthropic은 에이전트 행동에 대한 내부 사고 로그를 기록합니다. 이것이 바로 지도에 표시된 에스컬레이션 경계이며, 숫자로 표현된 형태입니다. 논쟁적인 트레이드오프 (trade-off)가 전체적으로 드러납니다. 루프 내의 인간 (human-in-the-loop)은 속도를 늦추지만 피해를 제한합니다. 자동 분류기 (auto-classifier)는 속도를 회복시키지만 자체적인 오류율을 추가합니다. 어떤 옵션도 공짜는 아니며, 지도가 필요한 이유는 바로 어디에서 어떤 트레이드오프가 허용 가능한지를 분류하기 위해서입니다.

해결 방법: 봇, 에이전트, 아니면 수동 단계?
이제 결과, 즉 작업의 분류로 넘어갑니다. 지도의 각 행에 대한 답변은 다음 세 가지 중 하나입니다. 제어 가능한 봇 (Controlled bot): 동작이 가역적(reversible)이며 로그를 통해 사후 검증이 가능합니다. 자율성을 가진 에이전트 (Agent with autonomy): 동작이 가역적이고 검증 가능하며, 루프 내의 인간이 승인 피로 (approval fatigue)를 느낄 정도로 빈번하게 발생합니다. 수동 단계 (Manual step): 동작이 불가역적이거나 피해가 발생하기 전에는 검증할 수 없습니다. 아래는 이것이 표에 어떻게 적용되는지를 보여줍니다.
CSA/NIST 프레임워크는 척도를 새로 발명할 필요가 없도록 도와줍니다. 이 프레임워크는 Tier 1("완전 감독", 모든 동작 전 인간의 승인 필요)부터 Tier 4("제한된 환경에서의 완전 자율성", 하위 에이전트 생성 포함)까지 네 가지 자율성 수준을 정의하며, 문서화된 에스컬레이션 트리거 (escalation triggers)를 포함한 관리 의무는 수준이 높아짐에 따라 함께 증가합니다. 예외적인 사례(edge case)인 멀티 에이전트 LLM (multi-agent LLM) 구조, 즉 에이전트가 하위 에이전트를 생성하는 경우는 최상위 Tier에 해당하며, 지도에 따르면 하위 에이전트의 모든 최종 동작이 여전히 가역성 검증을 통과할 때만 허용됩니다. 오케스트레이터 (orchestrator)의 자율성이 실행자 (executor)의 허용 범위를 취소할 수는 없습니다.
| 작업 (Action) | 가역성 (Reversibility) | 확인 주체 | 클래스 (Class) |
|---|---|---|---|
| 파일 읽기, 데이터 검색 | 완전함 | 없음, 로그 (log)만 남음 | 봇 (Bot) |
| ... | |||
| 여기서 독자가 취해야 할 태도는 간단하고 경제적입니다. 제어 가능한 봇 (bot)만으로 충분한 작업에 자율성 (autonomy)을 구매하지 않는 것입니다. 자율성은 공짜 업그레이드가 아닙니다. 이는 로그 (log)를 유지하고, 에스컬레이션 (escalation) 담당자를 지정하며, 고위험 작업에 대한 정책 (policy)을 수립해야 하는 의무를 동반합니다. 만약 특정 작업이 "수동 단계 (manual step)"에 해당한다면, 그 위에 자율 에이전트 (autonomous agent) 비용을 지불하는 것은 결국 사람이 처리해야 할 위험에 대해 비용을 지불하는 것과 같습니다. |
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기