요약: Claude Code 5월 릴리스에서 눈에 띄는 변화는 Agent View와 /goal 명령입니다. 여러 코딩 세션이 동시에 돌아가는 환경에서는 “어떤 에이전트가 아직 작업 중인지”, “어디서 사용자 승인이 필요한지”, “완료 조건이 무엇인지”가 병목이 됩니다. 이번 업데이트는 코딩 에이전트를 개인용 터미널 도구에서 팀 운영 도구로 끌어올리는 신호에 가깝습니다.
GitHub 릴리스 노트에 따르면 Claude Code는 Agent View를 Research Preview로 추가했습니다. claude agents를 실행하면 running, blocked, done 상태의 Claude Code 세션을 한 목록에서 볼 수 있습니다. 또한 /goal 명령이 추가돼 완료 조건을 설정하면 Claude가 여러 turn에 걸쳐 그 조건을 만족할 때까지 작업을 이어갑니다. 인터랙티브 모드, -p, Remote Control에서 동작하고 elapsed time, turn count, token 사용량을 overlay로 보여준다는 설명도 포함돼 있습니다.
이 변화는 작은 기능 추가처럼 보이지만, 실제 운영에서는 꽤 큽니다. 지금까지 코딩 에이전트 관리는 보통 tmux 창, 터미널 로그, Git 상태, PR 링크를 사람이 직접 엮어서 봤습니다. 작업이 하나일 때는 충분합니다. 하지만 버그 수정, 리팩터링, 테스트 작성, 문서 업데이트가 동시에 돌아가면 “에이전트가 일을 하고 있는지 멈춰 있는지” 자체가 관리 포인트가 됩니다.
개발팀에서 AI 코딩 에이전트를 쓰기 시작하면 처음에는 속도가 빨라집니다. 문제는 두 번째 단계에서 옵니다. 세션이 늘어나면 추적 비용이 올라갑니다. 한 에이전트는 테스트 실패로 막혀 있고, 다른 에이전트는 권한 승인을 기다리고, 또 다른 에이전트는 이미 완료됐지만 PR이 만들어지지 않은 상태가 됩니다. 이때 사람이 모든 터미널을 열어 확인하면 자동화의 이점이 줄어듭니다.
Agent View는 이 문제를 상태 관리 문제로 바꿉니다. 작업 단위별로 running, blocked, done을 볼 수 있으면 운영자는 개입해야 할 작업만 골라 볼 수 있습니다. /goal은 완료 정의를 명시하게 만듭니다. “홈 화면 고쳐줘”보다 “테스트가 통과하고 PR 설명에 변경 파일과 검증 결과가 포함되면 완료”가 훨씬 좋은 목표입니다. 완료 조건이 명확해야 에이전트도 덜 헤매고, 사람도 결과를 검수하기 쉽습니다.
첫 번째 지표는 blocked 시간입니다. 에이전트가 실행 중인 시간보다 승인을 기다리는 시간이 길다면 권한 정책이나 프롬프트가 잘못됐을 가능성이 큽니다. 반복적으로 같은 명령에서 막힌다면 허용 가능한 명령과 승인 필요한 명령을 분리해야 합니다.
두 번째 지표는 turn 수입니다. 간단한 수정이 20 turn 이상 이어진다면 초기 컨텍스트가 부족했거나 목표가 모호했을 수 있습니다. /goal을 쓸 때는 완료 조건뿐 아니라 금지 조건도 같이 적는 것이 좋습니다. 예를 들어 “UI 문구만 수정하고 데이터 모델은 건드리지 말 것”, “스냅샷 테스트는 업데이트하지 말고 원인을 수정할 것”처럼 범위를 제한합니다.
세 번째 지표는 token 비용입니다. 릴리스 노트에는 plugin details에서 컴포넌트 인벤토리와 세션별 예상 token cost를 보여주는 기능도 포함돼 있습니다. 스킬, 플러그인, MCP 서버가 늘어날수록 기본 컨텍스트가 비대해집니다. 팀 단위 운영에서는 “항상 모든 도구를 켜는 방식”보다 작업별로 필요한 플러그인만 로드하는 방식이 낫습니다.
이번 릴리스에는 MCP와 hook 관련 수정도 많습니다. MCP stdio server에 CLAUDE_PROJECT_DIR가 전달되고, .mcp.json 편집 후 재시작 없이 reconnect가 가능해졌으며, subagent API 요청에는 agent id와 parent agent id가 포함됩니다. OpenTelemetry span에도 agent_id, parent_agent_id가 붙는다고 설명돼 있습니다.
이건 관측성 측면에서 중요합니다. 멀티 에이전트 작업에서는 누가 어떤 하위 작업을 만들었는지 알아야 합니다. 부모 에이전트가 리팩터링을 지시했고, 자식 에이전트가 테스트를 수정했다면 PR 리뷰에서 그 흐름이 보여야 합니다. 그렇지 않으면 실패가 났을 때 “어느 세션이 원인인지”를 찾는 데 시간이 오래 걸립니다.
hook args가 shell 없이 직접 command를 spawn하는 exec form을 지원한다는 점도 운영상 의미가 있습니다. shell quoting 문제는 자동화에서 자주 터지는 작은 지뢰입니다. 경로에 공백이 있거나 placeholder 치환이 섞이면 hook이 의도와 다르게 실행될 수 있습니다. 직접 exec form은 이런 오류를 줄입니다.
도입할 때는 세 가지 규칙을 먼저 정하는 것이 좋습니다. 첫째, 모든 작업은 goal을 가져야 합니다. 목표, 완료 조건, 금지 조건, 검증 명령을 한 번에 적습니다. 둘째, 세션 이름은 사람이 읽을 수 있어야 합니다. fix-login-redirect, refactor-billing-api, write-e2e-checkout처럼 목적이 드러나야 Agent View에서 빠르게 판단할 수 있습니다. 셋째, blocked 상태에 대한 SLA를 둡니다. 예를 들어 10분 이상 blocked면 운영자가 확인하고, 30분 이상이면 작업을 중단하거나 목표를 줄입니다.
작업 프롬프트도 바뀌어야 합니다. “코드 고쳐줘” 대신 다음 정보를 포함합니다. 관련 파일, 재현 방법, 기대 동작, 검증 명령, 건드리면 안 되는 범위, PR 설명 형식입니다. 에이전트가 장시간 자율적으로 움직일수록 초기 계약이 중요해집니다.
/goal에 완료 조건과 금지 조건을 적는다.출처: anthropics/claude-code GitHub releases.