Claude Code v2.1.291은 화려한 릴리스가 아닙니다. 고친 것은 두 줄입니다.
① cloud session에서 permission prompt 답변이
사라지던 regression 수정 (2.1.290에서 발생)
② 종료 시 마지막 메시지가 유실되던 문제 수정
(2.1.288에서 발생)
지루해 보이나요? 코딩 에이전트를 production에 쓰는 사람에게는 정반대입니다. 승인 답변이 사라진다는 것은 "사용자가 허락했는데 실행이 안 됐거나, 반대로 허락하지 않은 것이 실행됐을 수 있다"는 뜻이고, 마지막 메시지가 유실된다는 것은 "무슨 일이 일어났는지 기록이 없다"는 뜻입니다. 둘 다 신뢰성의 심장부를 찌릅니다.
어제(v2.1.290)가 더 중요하다: permission plumbing
바로 전날 릴리스인 v2.1.290에서 들어온 세 가지가 이번 이야기의 본체입니다. Mods 글의 연장선입니다.
serverToolUses
→ Mod의 turn.step 훅 결과에 포함
→ API(서버) 측이 직접 실행한 tool call의
id·이름·입력·시작/종료 시각
→ 내 머신이 아닌 곳에서 돈 일도 장부에 오른다
agentId
→ plugin 훅의 tool.check 이벤트에 포함
→ 이 승인 요청이 서브에이전트 것인지
메인 세션 것인지 구분 가능
→ "누구의 결정인가"를 헷갈리지 않는다
ceiling
→ tool.check 훅이 읽는 질문·판정에 포함
→ 조직이 해당 tool에 요구하는 승인 등급(높이)
→ "이 작업은 상위 승인이 필요하다"를 규칙으로 넘긴다
표로 정리하면 이렇습니다.
| 추가된 것 | 붙는 위치 | 해결하는 문제 |
|---|---|---|
ceiling |
승인 질문·판정 | 조직 결재선을 코드로 표현 |
agentId |
승인 요청 이벤트 | 서브에이전트 요청과 메인 요청 구분 |
serverToolUses |
턴 실행 결과 | 서버 측 실행까지 감사 추적에 포함 |
핵심 변화는 승인 결정이 단순 yes/no에서 "조직 규칙 + 행위자 + 실행 위치를 고려한 결정"으로 이동했다는 점입니다. 예를 들어 production을 건드리는 작업에는 높은 ceiling을 걸고, 서브에이전트 발 요청은 별도 정책으로 다르게 처리하는 식의 제어가 훅 단에서 작성 가능해집니다.
왜 UX보다 "누가 호출했고, 무엇으로 승인됐는가"인가
코딩 에이전트가 강해질수록 사람이 직접 보는 화면보다 백그라운드에서 도는 실행이 많아집니다. 이때 신뢰성을 지탱하는 것은 예쁜 UI가 아니라 다음 네 개의 기록입니다.
agentId 누가 (메인인가, 어느 서브에이전트인가)
tool call 무엇을 (어떤 tool을 어떤 인자로)
approval 무엇으로 (어떤 승인·어떤 ceiling으로)
result 어떻게 됐는가 (성공·실패·부작용)
v2.1.291의 두 버그가 뼈아픈 이유가 여기 있습니다. 승인 답변이 유실되면 approval 칸이 비고, 종료 시 메시지가 유실되면 result 칸이 빕니다. 기록의 두 칸이 비는 순간, 사후에 "그래서 production에 무슨 일이 있었나"를 아무도 답할 수 없습니다.
CodeBridge Mini Lab: output이 아니라 trace를 남기자
브리핑의 액션을 실험으로 옮기면 이렇습니다. Claude Code plugin이나 Mod를 만든다면 출력 로그부터가 아니라 trace 스키마부터 잡으세요.
매 tool 실행마다 1줄 기록 (JSONL 권장):
{
"ts": "실행 시각",
"agentId": "main | subagent 이름",
"tool": "tool 이름",
"args": "인자 요약 (비밀값은 마스킹)",
"ceiling": "적용된 승인 등급",
"decision": "allow | deny | ask",
"result": "exit code / 요약",
"serverSide": "서버 실행 여부 (serverToolUses)"
}
주간 리뷰 질문:
[ ] 서브에이전트 발 호출 중想定 밖의 것이 있는가
[ ] ceiling 높은 작업이 적절한 승인으로 실행됐는가
[ ] 서버 측 실행 중 로컬 로그에 없던 것이 있는가
[ ] 같은 거부가 반복되는가 (규칙으로 승격 후보)
MCP 재인증 글의 step-up 승인, 옵저버빌리티 글의 실행 묶기와 합치면 "승인-실행-관측" 한 바퀴가 완성됩니다.
업데이트 실무 팁도 하나. claude --version으로 버전을 확인하고, 네이티브 설치는 claude update 후 재시작까지 해야 적용됩니다. self-hosted cloud runner는 호스트 바이너리를 직접 올리고 runner를 재시작해야 합니다. "stable 채널에서 최신"이라는 표시가 곧 2.1.291이라는 뜻은 아닙니다.
결론: 강한 에이전트일수록 장부가 먼저다
한 줄로 정리합니다.
에이전트의 능력은 모델이 정하고, 신뢰성은 기록이 정한다.
v2.1.290이 "기록할 수 있는 재료"를 깔았고, v2.1.291이 "기록이 사라지지 않게" 막았습니다. 순서가 맞습니다. 여러분의 plugin과 Mod도 같은 순서로 가면 됩니다. output 수집이 아니라 agentId + tool call + approval + result의 trace 구조를 먼저, 자동화는 그 다음에.
짧고 굵은 다음 행동: 이번 주 돌리는 Claude Code 작업에 위 JSONL 8개 필드 로깅부터 붙여보세요. 일주일 뒤 로그를 읽으면, 다음에 만들어야 할 승인 gate가 저절로 보입니다.
함께 읽으면 좋은 글
참고 자료
이 주제를 직접 따라가며 배우고 싶다면
승인 게이트와 trace 구조를 손으로 쌓는 연습이 필요하다면, CLAUDE.md·Skills·Hooks·서브에이전트·MCP를 실제 프로젝트에 쌓는 과정이 이 글의 Mini Lab과 바로 이어집니다.