GeekNews에 공유된 Codex CLI 변경 사항을 보면, OpenAI가 멀티에이전트 통신 자체를 암호화로 가려버리기 시작했습니다. 단순한 트래픽 보호가 아니라, 감사 추적(audit trail)의 의도적 회귀라는 평가가 긱뉴스 토론에서 거의 정설처럼 굳어지고 있습니다.
한국 독자 입장에서 흥미로운 건 이 변화가 LLM API의 또 다른 "보안 이벤트"가 아니라, 에이전트 인프라의 거버넌스 층에 있다는 점입니다. 멀티에이전트 시스템이 SaaS·B2B 백엔드로 자리 잡을수록, 부모-자식 에이전트 간 통신은 단순한 IPC가 아니라 컴플라이언스 로그가 되어야 하는데 — 그 자리에 정확히 암호화가 들어간 모순이 핵심입니다.
- Codex CLI의 MultiAgentV2가
spawn_agent,send_message,followup_task메시지를 암호화하면서, 부모 롤아웃·이력·추적에서 위임 내용을 사람이 읽을 수 없게 되는 감사 추적 회귀가 발생함 - 2026년 6월 5일 병합된 PR #26210 이후
InterAgentCommunication.content는 비워지고 페이로드가encrypted_content에만 저장되며, 수신자 이력과 통신 로그도 암호문을 기록함 - 문제는 구독·모델·플랫폼과 무관하고 MultiAgentV2가 활성화된 0.137.0 이후 빌드에 해당하며, 암호화 도구 스키마의 요청 검증 실패를 다루는 #26753과는 별개임
- 제안된 수정은 수신 모델용 암호화
message와 로컬 감사용 필수 평문 필드를 함께 보관하되, 전달 식별에는 암호문이나 ID를 사용하고 평문 감사 데이터에는 동일한 크기 제한을 적용하는 방식임 spawn_agent용 프로토타입은 별도 스냅샷 커밋에 구현됐지만send_message와followup_task, 이력·재생·디버그 화면까지 같은 계약을 적용하는 작업은 남아 있으며, 이슈는 아직 Open 상태임
발생 범위와 회귀 조건
- 암호화 변경 PR #26210은 2026년 6월 5일 병합됐으며, 이를 포함하고 MultiAgentV2를 활성화한 0.137.0 이후 빌드가 대상임
- 영향받는 도구는
spawn_agent,send_message,followup_task이며 구독, 모델, 운영체제, 터미널 환경과는 무관함 - 로컬 환경 상태가 아니라 병합된 코드 동작에서 확인되는 회귀이므로 Codex doctor 보고서는 해당하지 않음
- 재현 절차는 다음과 같음
1. PR #26210을 포함한 빌드에서 MultiAgentV2를 활성화함
2. 모델이 spawn_agent, send_message, followup_task 중 하나를 호출하게 함
3. 부모 롤아웃·이력·추적에서 서브에이전트 작업을 확인함
4. 작업이나 메시지 본문 대신 암호문만 확인됨
사라진 로컬 감사 정보
- 암호화된 전달 자체는 프라이버시 강화로 이해할 수 있지만, 현재 구현은 로컬 롤아웃 이력, 추적 축약, 부모 측 감사·디버그 화면에서도 사람이 읽을 수 있는 내용을 제거함
- 그 결과 사후 롤아웃 검토에서 다음 질문에 답하기 어려움
spawn_agent가 자식 에이전트에 어떤 작업을 부여했는지- 서브에이전트에 어떤 메시지를 보냈는지
- 특정 자식 스레드가 왜 생성됐는지
- 이슈 #26753은 암호화 도구 스키마가 요청 검증 과정에서 400 오류를 반환하는 문제이며, 이번 이슈는 스키마가 승인된 뒤의 감사 가능성과 디버깅 가능성을 다룸
- 목표는 암호화 전달을 반드시 되돌리는 것이 아니라, 암호화를 유지하면서 로컬에서 위임 내용을 읽을 수 있게 하는 것임
현재 코드의 데이터 흐름
InterAgentCommunication::new_encrypted()는content를 빈 문자열로 초기화하고 페이로드를encrypted_content에만 저장함- 일반 생성자
new()는 평문을content에 저장하고encrypted_content를 비워 둠 - 암호화 생성자는 반대로
content를 비우고encrypted_content에 값을 넣음 to_model_input_item()은encrypted_content가 있으면NEW_TASK또는MESSAGE머리말과 암호화 페이로드만ResponseItem::AgentMessage에 넣음- 따라서 런타임의
content만 채워도 읽을 수 있는ResponseItem이 자동으로 영속화되지 않음 - 별도의 로컬 감사 저장 경로가 필요함
communication_from_tool_message()는 도구의message를new_encrypted()에 직접 넘겨 평문content가 없는 통신 객체를 만듦send_message와followup_task인자 처리는target과 암호화된message만 역직렬화함- 빈
message는 거부하지만 별도의 평문 동반 필드가 없음 - 공유 메시지 전달 경로는 이 값을 그대로
InterAgentCommunication생성에 사용함
이력과 로그에 암호문이 남는 이유
- 수신 측 기록 경로는
to_model_input_item()이 만든 모델용ResponseItem을 대화 이력과 롤아웃에 저장함 - 암호화 통신에서는 이 항목에 읽을 수 있는 감사 문구가 아니라 암호화 전달 페이로드가 포함됨
- 롤아웃에는
InterAgentCommunicationMetadata와 해당ResponseItem이 함께 영속화됨 - 구조화 통신 로그도
content가 비어 있으면encrypted_content를 이벤트의content로 대체함 - 이 구조에서는 사람이 읽는 메시지로 표시되는 필드에도 암호문이 들어가므로, 단순히 전달 암호화를 유지하는 것과 로컬 감사 데이터를 보존하는 요구가 분리되지 않음
제안된 이중 콘텐츠 계약
- 기존 암호화
message는 수신 모델 전달용 페이로드로 유지함 - 각 MultiAgentV2 통신 도구에 필수 평문 감사 필드를 추가함
spawn_agent:task_messagesend_message,followup_task:task_message또는message_text처럼 일관된 이름- 핸들러 경계에서 빈 평문 감사 값을 거부함
InterAgentCommunication에는 두 값을 함께 저장함encrypted_content: 암호화된messagecontent: 사람이 읽을 수 있는 감사 사본to_model_input_item()은 변경하지 않아 수신 모델에는 로컬 감사 사본이 아닌 암호문만 전달함- 부모 도구 호출과 롤아웃에는 평문 필드를 영속화하고, 구조화 추적의 상호작용 간선과 로컬 통신 로그에도 이를 유지함
- 도구 호출과 자식 전달 항목의 상관관계는 평문 일치가 아니라 암호문 또는 ID로 판별함
- 평문 필드는 감사 메타데이터이며 암호화 전달의 식별자를 대체하지 않음
- 새 평문 감사 필드에는 대응하는 위임 메시지와 동일한 강제 크기 제한을 적용해 롤아웃이나 컨텍스트 항목이 무제한으로 커지지 않게 함
spawn_agent 프로토타입과 남은 작업
ignatremizov@df9a7c4스냅샷 커밋은spawn_agent에 제안된 구조를 구현함- v2
spawn_agent스키마는task_message를 필수 필드로 지정함 task_message검증을 수행한 뒤, 평문과 암호문을 함께 구성함content에는 평문 감사 사본을 넣음encrypted_content에는 수신 모델용 암호화 페이로드를 유지함- 롤아웃 추적 축약에서도 감사 콘텐츠와 전달 매칭 콘텐츠를 분리하고, 암호문으로 전달을 연결하면서 평문 감사 내용을 적용함
- 남은 작업은 같은 이중 콘텐츠 계약을
send_message와followup_task에 적용하고, 모든 사용자 대상 이력·재생·디버그 화면이 암호문 대신 감사 사본을 읽게 하는 것임
완료 조건과 현재 상태
- 부모 롤아웃과 이력에서 v2
spawn_agent,send_message,followup_task의 평문을 읽을 수 있어야 함 - 암호화가 활성화된 경우에도 자식 모델은 암호화된 전달 페이로드만 받아야 함
- 구조화된 롤아웃 추적 간선에는 크기가 제한된 평문
message_content가 들어가야 함 - 통신 로그는 평문 감사 콘텐츠가 있으면 이를 사용하고, 읽을 수 있는 메시지 필드에 암호문을 대신 넣지 않아야 함
- 재개·재생은 감사 사본을 보존하되 이를 자식 모델 컨텍스트에 주입하지 않아야 함
- 기존 평문 v1 통신 동작은 바뀌지 않아야 함
- 세 가지 v2 도구 모두에 대해 읽을 수 있는 로컬 감사 데이터와 암호화된 수신 모델 입력을 함께 검증하는 회귀 테스트가 필요함
- 제공된 페이지에서는 이슈가 Open 상태이며, 상위 저장소에 수정이 병합됐다는 결과는 없음
한국 시장에서의 시사점
한국에서도 사내 멀티에이전트 오케스트레이션을 도입하는 케이스가 늘고 있습니다. 셀바스AI, 네이버 하이퍼클로바, LG 엑사원 계열의 한국형 에이전트 스택에서도 동일 패턴이 등장할 가능성이 높습니다. 특히 금융·공공·의료 도메인에서는 부모-자식 에이전트 메시지 자체가 감사 대상인데, 위장된 "보안 강화"로 이를 가리면 결국 내부 컴플라이언스 리스크가 됩니다.
운영 측면에서 우리가 챙겨야 할 것은 세 가지입니다.
원문: GeekNews #31449 — Codex가 서브에이전트 프롬프트 암호화를 시작함
📰 원본 출처 · https://news.hada.io/topic?id=31449 (#N=31449)
이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.