코덱스 서브에이전트 로그가 암호문이 됐다

코덱스(Codex) 명령줄 도구가 에이전트끼리 주고받는 메시지를 암호화하면서, 정작 사용자 자신도 무엇을 위임했는지 되짚을 수 없게 됐다는 지적이 나왔다. 부모 에이전트의 기록과 추적 화면에 사람이 읽을 수 있는 내용 대신 암호문만 남는 현상이다. 관련 이슈는 아직 열려 있는 상태다.

무슨 일인가 / 배경

문제의 출발은 2026년 6월 5일 병합된 코덱스 저장소의 풀 리퀘스트 26210번이다. 이 변경 이후 멀티에이전트V2(MultiAgentV2)가 켜진 빌드에서는 에이전트를 띄우는 spawn_agent, 메시지를 보내는 send_message, 후속 작업을 넘기는 followup_task 세 도구의 내용이 암호화된다. 적용 범위는 이 변경을 포함하고 멀티에이전트V2가 켜진 0.137.0 이후 빌드다. 구독 종류나 모델, 운영체제와는 무관하며 개인 환경 설정 문제도 아니다. 병합된 코드의 동작 자체에서 나오는 회귀다.

같은 시기에 보고된 26753번 이슈와는 별개다. 그쪽은 암호화된 도구 스키마가 요청 검증에서 오류를 내는 문제이고, 이번 건은 스키마가 통과한 뒤의 감사 가능성과 디버깅 가능성을 다룬다.

핵심 짚어보기

원인은 데이터 구조에 있다. 암호화 전용 생성자는 통신 객체를 만들 때 평문이 들어가야 할 자리를 빈 문자열로 비우고, 실제 내용을 암호화 필드에만 담는다. 일반 생성자와 정확히 반대다. 그리고 이 객체를 모델 입력으로 바꾸는 단계에서 새 작업이나 메시지라는 머리말과 암호화된 덩어리만 실려 나간다. 문제는 대화 이력과 기록에 저장되는 것이 바로 이 모델용 항목이라는 점이다. 도구가 보낸 메시지도 평문을 거치지 않고 곧장 암호화 생성자로 넘어간다. 결과적으로 수신자 이력에도, 구조화된 통신 로그에도 암호문만 쌓인다.

그래서 나중에 기록을 열어도 답할 수 없는 질문이 생긴다. 부모가 자식 에이전트에게 대체 무슨 작업을 맡겼는지, 어떤 메시지를 보냈는지, 저 자식 스레드가 왜 만들어졌는지다. 자동화의 실패를 사후에 추적하려는 사람에게는 치명적인 공백이다.

짚어둘 것은 방향 자체를 되돌리자는 얘기가 아니라는 점이다. 전달 구간 암호화는 프라이버시 강화로 이해할 수 있다. 제안된 수정안은 둘을 함께 가져간다. 수신 모델용으로는 암호화된 메시지를 유지하되, 로컬 감사용 평문 필드를 필수로 함께 보관하자는 것이다. 전달 대상 식별에는 암호문이나 식별자를 쓰고, 평문 감사 데이터에도 같은 크기 제한을 걸자는 세부안까지 붙었다. spawn_agent용 시제품은 별도 스냅샷 커밋으로 구현됐지만, 나머지 두 도구와 이력·재생·디버그 화면까지 같은 계약을 적용하는 일은 남아 있다.

1인기업 실전 적용 포인트

• 위임 로그를 도구에만 맡기지 마라. 서브에이전트를 띄우기 직전에 지시문을 내 파일에 한 줄 덧붙이는 습관을 들이면, 프레임워크가 무엇을 감추든 내 기록은 남는다.
• 자동 업데이트를 켜둔 무인 자동화라면 버전을 고정할지 검토하라. 이번 건처럼 어느 날 업데이트 한 번으로 로그가 통째로 암호문이 되는 변화가 실제로 일어난다.
• 밤새 도는 에이전트일수록 '무엇을 시켰나'가 남아야 아침에 결과를 검증할 수 있다. 결과물만 남고 지시가 사라지면 잘된 건지 판단할 기준이 없다.
• 같은 증상을 겪는다면 이슈에 재현 절차를 붙여 의견을 남겨라. 이런 우선순위는 결국 겪은 사람 수로 정해진다.

전망 / 주의점

이 사건은 개별 버그를 넘는 교훈을 준다. 에이전트가 에이전트를 부리는 구조가 표준이 될수록, 성능만큼이나 '왜 그렇게 했는지 나중에 읽을 수 있는가'가 도구의 품질이 된다. 전송 암호화와 로컬 감사는 원리상 충돌하지 않는다. 다만 이슈가 아직 열린 상태인 만큼, 지금 멀티에이전트V2로 중요한 자동화를 굴리고 있다면 위임 내역을 스스로 기록하는 우회책을 마련해 두는 편이 안전하다.

출처: 긱뉴스 (https://news.hada.io/topic?id=31449)