AI 에이전트의 승인 여부를 확인하는 방법 — 전언은 정확했지만, 그래도 확인한 이유
요약
AI 에이전트 간의 '승인됨' 통보가 왔더라도, 실제 실행 전 운영자가 직접 확인하는 것이 중요합니다. Claude Code 공식 사양은 다른 세션에서 온 메시지를 사용자의 동의로 자동 계산하지 않도록 설계되어 있어, 승인의 출처와 절차를 명확히 하는 것이 핵심입니다.
핵심 포인트
- 다른 에이전트의 '승인됨' 통보만으로는 실행에 대한 확신을 가질 수 없습니다.
- Claude Code 공식 사양은 다른 세션 메시지를 사용자 동의로 간주하지 않도록 설계되어 있습니다.
- 실제 운영에서는 승인의 출처(出所), 주체, 대상, 범위를 명확히 확인해야 합니다.
다른 AI 에이전트로부터 '승인됨'이라는 통보를 받았더라도 실행 전에 본인에게 확인했던 3가지 실제 사례를 소개합니다. Claude Code의 공식 사양이 보장하는 범위, 확인 절차를 구체화하는 방법, 승인을 남기는 방식, 그리고 확인해도 남아있는 허점들을 운영자의 관점에서 실례와 함께 정리했습니다.
'승인됨' 통보가 왔기 때문에 본인에게 확인한 후 실행했다
여러 에이전트에게 작업을 분배할 경우, 다른 에이전트로부터 '의뢰인의 승인이 나왔습니다'라는 메시지가 오는 상황이 발생합니다.
공개 중인 결과물을 비공개로 되돌리는 요청이 승인됨으로 도착했다
어느 날, 제작을 총괄하는 에이전트로부터 작업 담당 에이전트에게 메시지가 도착했습니다. 공개 중인 결과물을 비공개로 돌리고 판매 방침을 변경하는 작업을 요청하는 내용이었습니다. 문구에는 '의뢰인의 승인이 나왔다'고 적혀 있었습니다.
직전까지 저와 작업 담당 에이전트는 결과물을 원형 버전으로 남길 방침을 논의하고 있는 중이었습니다. 작업 담당 에이전트는 방침 전환이 제 의사인지 확인할 수 없는 상태에서는 착수하지 않겠다고 판단했습니다. 따라서 의견이 다른 부분을 덧붙여 '맞습니까?'라고 저에게 질문하는 형식이었습니다. 저는 2분 정도 만에 답했고, 방침 전환은 제 결정이라고 답변했습니다.
확인했던 3번의 경우 모두 전언이 정확했다
같은 대응은 확인할 수 있는 범위에서 3번 있었습니다. 첫 번째는 위에서 언급한 철회 건이었고, 두 번째는 기사 공개 건, 세 번째는 진행 중인 작업을 멈추고 다른 세션 쪽을 수정하라는 요청이었습니다. 제 답변은 모두 1~4분 이내에 도착했습니다. 전언은 3번 모두 제 의사와 일치했습니다. 전언이 잘못된 경우는 확인 가능한 범위에서는 발견되지 않았습니다.
그렇다면, 확인하는 과정은 무의미했을까요? 전언이 정확했던 상황에서, 확인이 어떤 역할을 했는지 작성합니다. 아울러, 확인 절차의 범위를 정리하는 것도 목적입니다. 이전 글은 보고가 아니라 결과물을 보는 이야기였습니다. 이번 핵심 축은 승인의 출처(出所)입니다.
공식 사양은 다른 세션의 승인을 동의로 간주하지 않는다
Claude Code의 공식 문서는 다른 세션으로부터 온 메시지를 사용자의 동의로 계산하지 않도록 설계되어 있습니다.
다른 세션의 메시지는 허가 프롬프트 대신 답변할 수 없다
공식 문서(2026년 10월 4일 확인)에 따르면, 다른 세션에서 도착한 메시지는 사용자의 동의로 간주될 수 없습니다. 보류 중인 허가 프롬프트는 사용자 대신 답변할 수 없다고 명시되어 있습니다. 권한 설정이나 CLAUDE.md 변경 역시 다른 세션에 의존하여 응대하지 않는 취급입니다. 메시지 기능은 macOS와 Linux에서는 v2.1.224 이후, 네이티브 Windows에서는 v2.1.234 이후가 요구 사항으로 되어 있습니다.
실험적인 기능인 agent teams에서도 팀원은 허가 프롬프트를 승인할 수 없으며, 사용자 대신 동의를 줄 수도 없습니다. auto mode에서는 다른 에이전트로부터 중계된 승인의 주장이 신뢰할 수 없는 입력으로 취급됩니다. 메시지와 팀 경로에서는 제품 자체가 전언된 승인을 승인으로 간주하지 않도록 설계되어 있습니다.
사양에 쓰여있지 않은 경로가 남아있다
경로별로 정리하면, 공식 문서가 다루는 부분과 그렇지 않은 부분이 나뉩니다.
| 경로 | 공식 문서의 취급 |
|---|---|
| 다른 세션으로부터의 메시지 | 동의로 간주하지 않음 |
| ... | |
| 결과물(파일)·공유 문서·채팅·다른 도구에서 도착하는 '승인됨'은 이번에 확인한 범위의 공식 문서에는 기술된 내용이 보이지 않았습니다. 인계 메모에 '승인됨'이라고 적혀 있다면, 받은 에이전트는 스스로 판단할 수밖에 없습니다. |
사양의 서술은 업데이트가 빠르기 때문에 읽는 시기에 따라 내용이 바뀝니다. 실제 기기의 동작은 확인하지 못했습니다. 제품이 지키는 부분을 전제로 하고, 나머지는 운영 측에서 결정하는 영역입니다.
승인에는 주체·대상·범위·시점이 있다
'승인됨'이라는 한마디만으로는 무엇을 승인했는지 알 수 없습니다.
'승인됨'이라는 말만으로는 본인의 발언을 확인할 수 없다
도착한 전언에는 날짜와 대상이 적혀 있었습니다. 제 발언을 인용한 전언도 있습니다. 하지만, 인용된 내용이 실제 발언과 일치하는지는 받는 쪽에서 확인할 수 없습니다. 확인할 수 있는 것은 저에게 직접 들었을 때뿐입니다. 3번의 확인 과정이 담당한 것은 전언의 진위 여부 판단이 아니라, 승인의 출처를 직접 확인하는 것이었습니다.
전언은 판단의 재료가 될 수는 있습니다. 실행의 근거로 삼기 위해서는 누가 무엇을 어디까지 승인했는지, 언제의 승인인지가 부족합니다. '승인'이라는 한 단어는 짧지만, 주체·대상·범위·시점의 4가지를 숨기고 있습니다.
공식 문서도 승인은 원칙적으로 하나의 동작에 효력이 있다고 적고 있다
공식 문서의 auto mode 절에는 사용자가 대화에서 언급한 승인은 원칙적으로 하나의 작업에 효력이 있다고 쓰여 있습니다. 같은 절에서는 승인 시 작업 이름과 구체적인 내용을 명시할 필요가 있다고도 말하고 있는 것 같습니다. 주체, 대상, 범위, 시점 네 가지는 동일한 사고방식을 운영 용어로 정리한 것으로 사용할 수 있습니다.
참고로, 토큰에 의한 대리(위임)의 표준화와 사람의 의사 확인은 별개의 단계일 것입니다. 전자는 '누구의 대리인지'를 보장하고, 후자는 '지금 대상 작업에 대해 본인이 알고 인정했는지'를 확인하는 단계입니다. 이 정리 내용은 필자의 추론이며 공식적인 기술 문서는 아닙니다.
확인해야 할 작업은 결과적으로 외부로 나가는 것과 되돌리기 어려운 것에 한정되었다
확인한 것은 매번의 작업이 아니었습니다.
전언 그대로 진행한 경우와 확인했던 경우가 있었다
확인한 3번의 사례는 공개된 결과물의 철회, 기사 공개, 그리고 진행 중인 작업의 중단이었습니다. 다른 날에는 같은 '승인이 나왔습니다'라는 말을 작업 담당 에이전트가 저에게 확인하지 않고 진행한 경우도 있었습니다. 3번의 내용은 새로운 기사 착수 및 관점 선택, 초안으로서의 push였습니다.
| 작업 | 영향 범위 | 처리 방식 |
|---|---|---|
| 새로운 기사 착수/관점 선택 | 로컬 파일로 완료 | 전언 그대로 진행함 |
| ... | ||
| 전언 그대로 진행한 3번은 로컬 작업과 Zenn에 공개하기 전의 초안 push였습니다. 나중에 문제가 된 기록은 확인한 범위에서는 발견되지 않았지만, 승인이 실제로 있었는지는 확실하지 않습니다. |
한정 기준은 외부로 나가거나 되돌리기 어렵거나 다른 작업을 중단하는 작업이었는지
결과적으로 확인해야 할 작업은 3가지 성질에 기했습니다.
- 외부로 나가는 작업
- 되돌리기 어려운 작업
- 다른 작업을 중단하는 작업
매번 확인하면, 확인이 형식적인 작업으로 변하기 쉽습니다. Anthropic의 엔지니어링 블로그는 사용자가 승인 프롬프트의 93%를 승인했다고 보고했습니다. 확인 횟수를 늘릴수록, 한 번에 대한 주의력은 흐트러질 것입니다.
경계를 당시 제가 글로 정했었는지에 대한 기록은 남아있지 않습니다. 결과적으로 대응이 나뉘어 있었다고 쓰는 것이 정확합니다.
승인을 업무 기록에 날짜와 범위가 있어 남겼다
확인한 승인은 건별 규칙 파일에 남기고 있습니다.
확인한 항목을 날짜와 함께 열거했다
예를 들어, 기사를 공개해도 되는 범위를 본인에게 확인했을 때는, 규칙 파일에 확인했다는 내용과 날짜를 적었습니다. 확인한 항목은 (a)부터 (d)까지 4가지로 나누어 배열하고 있습니다. 나중에 다시 읽어보면, 무엇을 승인받았는지, 언제의 이야기인지 알 수 있을 것입니다.
공개 전에는 차이점을 보여주며 명시적인 승인을 얻는 절차도 같은 파일에 적고 있습니다. 승인을 구두 대화만으로 끝내지 않고 기록으로 남기기 위함입니다.
아직 남기지 못한 요소도 있다
주체, 대상, 범위, 시점 중 대상과 범위, 시점은 남길 수 있습니다. 주체는 이름만 적고 출처(본인의 발언인지 전언인지)는 기록하지 않았습니다. 네 가지를 하나의 틀로 묶어 사용하고 있지는 않은 상태입니다.
| 요소 | 작성 내용 예시 | 현황 |
|---|---|---|
| 주체 | 누가 승인했는지 | 이름은 적지만 출처는 남기지 않음 |
| ... | ||
| 오른쪽 열이 현재 상황이고, 중앙 열이 제안 예시입니다. 시도해 본다면, 주체란에 본인에게 직접 들었는지 전언인지 한마디를 덧붙이는 것부터 시작할 수 있습니다. |
확인하는 수고는 적지만 구멍은 생겼다
3번의 확인으로 수고는 적게 들었습니다. 구멍은 확인 바깥에 있습니다.
수고는 적지만 본인이 부재하면 멈춘다
답변은 1~4분 이내로 도착했습니다. 제가 화면 앞에 있을 때의 이야기입니다. 자리에 없을 때는 확인할 수 없어 작업이 멈춥니다. 급한 작업을 멈출지, 전언 그대로 진행할지는 작업마다 정해둘 필요가 있어 보입니다.
확인이 정형화된 질문이 되어 내용을 읽지 않고 '예'라고 답하는 형식화도 일어날 수 있을 것입니다. 확인 빈도를 줄이는 의미는 수고 절감뿐만 아니라, 형식화를 피하는 점에도 있다고 생각합니다.
전언이 틀렸던 예는 아직 보지 못했다
손에 있는 것은 전언이 정확했던 경우만입니다. 잘못된 전언을 확인이 멈추게 했는지 여부는 보지 못했습니다. 파일 경유로 도착하는 승인의 처리는 사양에도, 운영상으로도 아직 다 쓰여지지 않은 상태입니다.
만능적인 방법은 아닙니다. 전언만으로 실행할 범위를 좁히고, 외부로 나가는 작업에서는 본인의 직접 확인을 거치는 방법을 사용하고 있습니다. 시도해 본다면, 자신의 운영에서 '다른 에이전트가 승인했다고 말하는 것'만으로 실행하고 있는 작업을 하나 찾아보세요. 발견한 작업에 본인의 직접 확인을 한 번 거치면, 승인의 출처가 결정됩니다.
본고의 집필에는 AI(Claude)를 활용했습니다. 기록과의 대조 및 공개 여부 판단은 필자가 담당했습니다.
논의

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기