발표에서 확인된 핵심 사실

AI가 복잡한 작업을 수행하다 엉뚱한 답을 내놓으면 개발자는 가장 먼저 내부 로그를 뜯어본다. 어떤 지시를 내렸고 어디서 꼬였는지 확인해야만 문제를 고칠 수 있기 때문이다. 그런데 최근 Codex CLI(명령어 라인 인터페이스) 0.137.0 이후 빌드에서 MultiAgentV2(여러 AI 에이전트가 협업하는 구조)를 활성화하면 이 로그가 암호화되어 사람이 읽을 수 없는 현상이 나타났다.

이 문제는 2026년 6월 5일 병합된 PR #26210 이후의 빌드를 사용하는 모든 환경에서 공통적으로 발생한다. 사용자가 어떤 구독 플랜을 이용하는지, 어떤 모델이나 플랫폼을 선택했는지는 문제 발생 여부와 무관하다. 운영체제나 터미널 환경이 무엇이든 관계없이 MultiAgentV2가 활성화되어 있다면 에이전트 간의 통신 내용이 암호화되어 내부 작동 과정을 추적할 수 없다.

개발팀은 이를 해결하기 위해 일부 기능부터 프로토타입을 적용하고 있다. 새로운 에이전트를 생성하는 spawn_agent 기능은 스냅샷 커밋을 통해 제안된 구조의 구현을 마쳤다. 하지만 에이전트끼리 메시지를 주고받는 send_message나 후속 작업을 처리하는 followup_task에 동일한 계약을 적용하는 작업은 아직 완료되지 않았다. 이력 재생 기능과 디버그 화면까지 모두 업데이트해야 하는 상황이라 관련 이슈는 여전히 Open 상태로 남아 있다.

기술이 실제로 작동하는 방식

보안을 강화하면 운영의 투명성이 사라지는 비용을 치러야 한다. Codex CLI 0.137.0 이후 빌드에서는 에이전트끼리 주고받는 대화 내용이 암호화되어 관리자가 로그를 읽을 수 없게 됐다. InterAgentCommunication(에이전트 간 통신 구조)의 `new_encrypted()` 생성자가 `content`라는 평문 필드를 빈 문자열로 초기화하고, 실제 페이로드를 `encrypted_content`라는 암호화 필드에만 저장하기 때문이다. 이 과정에서 데이터 흐름은 평문 필드를 완전히 건너뛰고 암호문 필드로만 집중된다. 시스템이 작동하는 런타임 단계에서 `content` 필드에 임시로 내용을 채우더라도, 정작 저장소에는 읽을 수 없는 형태로 남는 ResponseItem(응답 항목)만 자동으로 기록되는 구조다.

보안을 유지하면서도 사후 검토가 가능하도록 평문 필드를 함께 남기는 이중 콘텐츠 계약 방식이 대안으로 제안됐다. 수신 모델에게 전달할 암호화된 메시지와 로컬 감사용 필수 평문 필드인 `task_message`를 동시에 저장하는 설계다. 전달 식별에는 암호문이나 ID를 사용해 보안을 지키고, 사람이 읽어야 하는 감사 데이터만 따로 보관하는 방식이다. 특히 평문 필드에는 엄격한 크기 제한을 적용해 롤아웃이나 컨텍스트 항목이 무제한으로 커져 시스템 성능을 떨어뜨리는 상황을 방지한다. 보안 강화라는 목적과 운영 효율이라는 실무적 요구 사이의 충돌을 해결하려는 설계 패턴이다.

MultiAgentV2의 메시지 암호화 도입으로 인해 감사

평소처럼 로그 화면을 열었는데 읽을 수 없는 외계어 같은 암호만 가득한 상황을 마주했다. Codex CLI의 MultiAgentV2(여러 AI 에이전트가 협업하는 시스템)가 메시지 보안을 위해 암호화를 도입하면서 감사 추적 회귀가 발생했다. 구체적으로 spawn_agent(에이전트 생성), send_message(메시지 전송), followup_task(후속 작업)와 같은 핵심 메시지들이 암호화 대상이 되었다. 이 때문에 부모 롤아웃(작업의 전체 전개 과정)이나 이력, 추적 화면에서 에이전트가 다른 에이전트에게 어떤 내용을 위임했는지 사람이 읽고 판단할 수 없게 되었다. 로그 상의 기록은 존재하지만 그 내용을 알 수 없어 추적이 불가능해진 상태다. 보안을 위해 잠근 문이 정작 문제를 해결해야 할 운영자의 디버깅이라는 열쇠를 잃어버리게 만든 셈이다.

이번 현상은 요청 검증 단계에서 발생한 단순한 기술 오류와는 성격이 완전히 다르다. 이전의 이슈 #26753은 암호화 도구 스키마(데이터 구조 정의서)가 요청 검증 과정에서 400 오류를 반환하며 시스템 진입 자체를 막았던 사례다. 하지만 이번 이슈는 스키마가 정상적으로 승인되어 시스템이 작동한 이후의 감사 가능성과 디버깅 가능성을 다룬다. 즉, 요청이 성공했느냐의 문제가 아니라 성공한 요청이 남긴 기록을 사람이 읽을 수 있느냐의 문제다. 이는 보안 강화라는 목적이 운영 효율성이라는 실무적 필요성과 충돌하며 발생한 결과로, 기록의 암호화가 디버깅의 가시성을 완전히 가려버린 사례다.

AI 에이전트의 사고 과정을 추적하려 로그를 열었을 때, 암호화된 텍스트만 가득한 화면을 마주하는 것은 개발자에게 큰 벽이다. Codex CLI 0.137.0부터는 에이전트 간 통신 구조인 InterAgentCommunication에서 기존 내용을 비우고 암호화된 데이터만 남겨 보안을 강화했지만, 그 대가로 운영의 투명성을 잃었다.

결국 보안과 효율의 충돌을 해결하는 열쇠는 기록을 분리해 관리하는 이중 저장 설계에 있다. 실무자는 보안의 강도와 디버깅의 가시성 사이에서 어떤 균형점을 잡을지 이 설계 패턴을 통해 결정해야 한다.