누가 누구에게 무엇을 말했는가
Source: Dev.to
Incident Overview
2023년 2월 20일, 한 개발자가 X에 스크린샷을 올렸습니다.
그는 Claude Code에 오류 메시지를 제출했습니다. Claude는 “Commit these changes?” 라고 응답했습니다.
그는 어떤 변경인지 몰라 “What changes?” 라고 물었습니다.
Claude는 커밋을 시작했습니다.
이는 명백한 방식의 오작동이 아니라, Claude가 누가 누구에게 무엇을 말했는지 추적을 잃어버렸기 때문이었습니다—자신의 질문을 개발자의 지시로 오해하고 실행한 것이었습니다. 중지시키자 승인 모달이 나타났고, 그는 이를 거부했지만 Claude는 계속 물었습니다.
자신의 행동을 스크린샷으로 보여주며, Claude는 턴 순서를 혼동했으며—이는 하위 에이전트들이 비동기적으로 대화 기록을 업데이트하면서 발생한 부작용이라고 설명했습니다.
그 설명은 다음 문서에 기록되어 있습니다:
- GitHub issue #7881 – 여러 하위 에이전트가 동일한 세션 ID를 공유해, 어떤 에이전트가 누구에게 무엇을 말했는지 추적하는 것이 구조적으로 불가능합니다.
- GitHub issue #25000 – 하위 에이전트가 권한 규칙을 우회합니다.
- GitHub issue #22900 – VS Code 확장 프로그램이 메인 대화 기록을 유지하지 않고, 하위 에이전트 기록만을 보관합니다.
개발자의 경험은 예외적인 경우가 아니라, 설계가 예상하지 못한 상황에서 설계대로 작동한 결과였습니다.
This is not a bug report. It’s what happens when accountability becomes structurally impossible.
This is part of a series on what AI actually changes in software development. Previous pieces: The Gatekeeping Panic, The Meter Was Always Running.
책임 가정
이 분야에서 전개되는 논지는 책임이 해답이라는 것이다—AI 탐지기든, 게이트키핑이든, 생성 속도를 늦추는 것이든 아니다. 책임이란 누가 결정을 내렸는지, 누가 커밋을 소유했는지, 새벽 3시 에 누가 호출되는지를 아는 것을 의미한다.
그 논리는 다음과 같은 상황에서 성립한다:
- 루프에 인간이 한 명만 있을 때.
- 코드베이스가 하나일 때.
- 커밋 히스토리가 하나일 때.
결정의 사슬이 추적 가능했기 때문에 책임이 가능했다.
에이전시 시스템은 그 사슬을 해체한다.
하위 에이전트가 공유 상태에 비동기적으로 기록하고, 세션 ID가 어느 에이전트가 어떤 행동을 했는지 구분하지 못하며, 오케스트레이터가 작업 중간에 일관성을 잃을 때, “누가 이 결정을 내렸는가?” 라는 질문은 명확한 답을 갖지 못한다. 이는 아무도 책임을 지고 싶어 하지 않기 때문이 아니라, 시스템이 책임을 구조적으로 불가능하게 만들기 때문이다.
내가 쓴 게이트키핑 글에 대한 댓글에서 Apogee Watcher는 정확히 이렇게 명명했다: 위험은 단순히 책임이 회피되는 것이 아니라—책임이 형식적인 것이 되는 것이다. 커밋에 이름을 적을 수는 있지만, 그 이름이 적힌 사람이 실제로 무엇을 승인했는지는 보장할 수 없다.
이 격차가 다음 물결의 생산 실패가 발생할 지점이다.
트레이스 문제
LangChain 공동 설립자인 Harrison Chase가 심각하게 고려할 만한 주장을 제시했습니다.
에이전트 시스템에서는 코드가 골격에 불과합니다. 실제 결정은 런타임, 즉 모델 내부에서 이루어집니다. 전통적인 디버깅은 코드를 읽고 동작을 이해할 수 있다고 가정합니다. 에이전트와 함께라면 그렇지 못합니다.
그의 결론: 트레이스가 진실의 근원이 된다—툴 호출 순서, 입력 및 출력, 추론 단계—즉 여러분의 감사 기록입니다.
설득력 있는 주장입니다. Burkov의 스크린샷은 정확히 어디서 문제가 발생하는지를 보여줍니다.
하위 에이전트가 공유 대화 기록에 비동기적으로 쓰면, 트레이스 자체가 신뢰할 수 없게 됩니다. Issue #22900 은 VS Code 확장 프로그램이 하위 에이전트 전사만을 지속하고—주 대화는 저장하지 않음을 확인합니다. 오케스트레이터의 추론, 턴 순서 혼란, 시스템이 자신의 질문을 사용자 지시로 오해한 순간—이 모든 것이 트레이스에 남을 보장이 없습니다.
- 기록되지 않은 것은 감사할 수 없습니다.
- 중요한 결정을 놓친 트레이스에서는 책임을 부여할 수 없습니다.
Chase는 트레이스가 진실의 근원이 되어야 한다는 점에서 옳습니다. 문제는 현재 아키텍처가 트레이스를 아직 신뢰할 수 있게 만들지 못했다는 것입니다. 감사 기록에 빈틈이 생기고, 그 빈틈이 바로 책임이 사라지는 지점입니다.
Source:
누가 누구에게 뭐라고 했는가
책임 논증이 틀린 것은 아니다; 불완전할 뿐이다.
- 커밋을 누가 소유했는지 아는 것이 중요하다.
- 새벽 3시에 누가 호출되는지 아는 것이 중요하다.
- 문서화된 거절, 공개적인 책무, 배포 전 검증 등 문화 구축—이 모든 것이 중요하다.
하지만 이는 시스템이 무슨 일이 일어났는지 알려줄 수 있다고 가정한다.
에이전트 시스템은 그 가정이 성립하기 전에 프로덕션에 배포되고 있다:
- 하위 에이전트가 세션 ID를 공유한다.
- 대화 기록이 지속되지 않는다.
- 순서 혼란으로 시스템이 스스로 질문을 실행한다.
- 하위 에이전트가 우회하는 권한 규칙.
- 아직 신뢰할 수 있는 진실의 원천이 되지 못한 추적 아키텍처.
이를 이해하는 개발자는 AI가 자신을 대체한다는 것에 겁먹지 않는다. 대신 더 어려운 질문을 던진다:
- 이 에이전트가 실제로 무엇을 했는가?
- 어떤 하위 에이전트가 이 결정을 내렸는가?
- 잘못된 부분에 대한 추적은 어디에 있는가?
- 추론 과정을 재구성할 수 있는가, 아니면 사라졌는가?
이 질문들은 판단, 검증, 그리고 조직적 기억을 요구한다—이 시리즈가 주장해 온 동일한 역량이다. 하지만 동시에 새로운 기술도 필요하다: 블라인드 스팟이 어디에 있는지, 그리고 이를 어떻게 보완할 수 있는지 알 만큼 에이전트 아키텍처를 깊이 이해하는 것.
Enough to know where the accountability gaps live before something fails in production.
There's a kind of accountability that works — one human, one codebase, one commit history, receipts that are fully yours. A nine‑day timeline you can reconstruct. A public reckoning you can point to.
That worked because there was one human in the loop.
Add subagents. Share the session ID. Let the transcripts fail to persist.
Now try to produce the receipt.