요약: Claude Code 최신 릴리스에서는 subagent 백그라운드 실행, Claude in Chrome GA, background agent 알림, 자동 재시도와 복구 개선이 한꺼번에 들어왔습니다. 코딩 에이전트를 장난감이 아니라 팀 개발 도구로 쓰려면 이제 ‘실패했을 때 어떤 상태로 돌아오는가’를 봐야 합니다.
Anthropic의 Claude Code 릴리스 노트에는 최근 개발자 워크플로우에 직접 영향을 주는 변경이 많습니다. 핵심만 뽑으면 subagents가 기본적으로 백그라운드에서 실행되고, Claude in Chrome이 일반 제공 상태가 됐으며, background agent가 입력 필요 또는 완료 상태를 notification hook으로 알릴 수 있게 됐습니다. 또한 네트워크 단절, API 오류, rate limit, SSH cold-start, 메모리 부족, daemon 재시작 같은 장시간 작업의 실패 지점에 대한 복구가 크게 보강됐습니다.
이 업데이트가 중요한 이유는 Claude Code가 단순한 터미널 챗봇에서 ‘여러 작업을 동시에 맡기고, 완료되면 다시 합류하는 개발 운영 도구’로 이동하고 있기 때문입니다. 한 세션에서 리팩터링, 테스트 수정, 문서 업데이트를 동시에 돌리고 결과를 회수하는 패턴이 더 자연스러워졌습니다.
기존에는 subagent를 호출하면 메인 세션이 그 결과를 기다리는 느낌이 강했습니다. 이제는 subagent가 기본적으로 백그라운드에서 돌고, Claude는 다른 작업을 계속 진행할 수 있습니다. 이 변화는 작아 보이지만 실제 개발 흐름에서는 큽니다.
예를 들어 큰 레포에서 다음 작업을 동시에 처리할 수 있습니다.
문제는 동시성이 늘어나면 상태 관리도 어려워진다는 점입니다. 그래서 이번 릴리스의 진짜 가치는 ‘백그라운드가 된다’가 아니라 ‘백그라운드 작업이 실패하거나 중단됐을 때 부모 세션이 더 정확히 알 수 있다’에 있습니다. 릴리스 노트에는 rate limit이나 server error로 잘린 subagent가 조용히 실패하지 않고 partial work를 부모에게 돌려준다는 수정이 포함되어 있습니다. API 오류를 성공 결과로 잘못 보고하던 문제도 수정됐습니다.
코딩 에이전트를 실무에 붙이면 실패는 대부분 모델 품질보다 운영 경계에서 납니다. 긴 명령을 돌리다가 진행 표시가 멈춥니다. SSH 세션이 흔들립니다. background daemon이 이전 기록을 잘못 읽고 같은 작업을 다시 실행합니다. 네트워크가 잠깐 끊겨 streaming response가 사라집니다. 병렬 요청 중 usage limit 경고가 꼬입니다.
이번 릴리스는 이런 실패를 꽤 구체적으로 다룹니다. 예를 들어 streaming 중 overloaded/server error가 나도 partial output을 보존하고 incomplete-response notice를 붙입니다. background job progress indicator가 긴 명령 중 멈춰 보이는 문제를 고쳤습니다. memory-starved machine에서는 generic error 대신 메모리 부족을 알려줍니다. unclean shutdown 뒤 corrupted worker record 때문에 Linux daemon이 50초마다 자기 자신과 모든 agent를 죽이는 문제도 수정됐습니다.
실무적으로는 “에이전트가 실패하지 않는다”가 아니라 “실패 원인이 작업자에게 보인다”가 더 중요합니다. 원인이 보여야 재실행할지, 부분 결과를 살릴지, 사람에게 넘길지 결정할 수 있습니다.
Claude in Chrome 일반 제공은 웹 QA와 브라우저 기반 디버깅 쪽에서 의미가 큽니다. 프론트엔드 작업에서 모델이 브라우저를 직접 보며 UI 상태를 확인하고, 콘솔 에러나 화면 깨짐을 보고 수정 제안을 할 수 있는 방향으로 가고 있습니다.
다만 브라우저 도구는 권한과 안전성이 더 중요합니다. 릴리스 노트에는 plan mode에서 state-changing browser tool calls에 대해 prompt가 제대로 뜨도록 수정됐고, read-only browser_batch 호출은 자동 허용되도록 고쳤다는 내용이 있습니다. 즉 브라우저 자동화가 넓어질수록 읽기 작업과 상태 변경 작업을 구분하는 권한 모델이 핵심이 됩니다.
팀에서 Claude in Chrome을 도입한다면 처음부터 결제, 계정 설정, 운영 데이터 변경 화면에 자유 접근시키면 안 됩니다. 로컬 개발 서버, staging, read-only QA 페이지부터 시작해야 합니다.
이번 릴리스에서 눈에 띄는 항목 중 하나는 transient server rate-limit error를 subscriber 대상으로 backoff와 함께 자동 재시도한다는 점입니다. 또 CLAUDE_CODE_RETRY_WATCHDOG가 non-capacity transient error의 기본 retry count를 300으로 올리고, CLAUDE_CODE_MAX_RETRIES의 15 제한을 해제한다는 내용도 있습니다.
이건 장시간 코딩 작업에 직접 영향을 줍니다. 대규모 리팩터링이나 테스트 수정 작업은 중간에 API가 잠깐 흔들렸다고 전체 결과를 버리면 손실이 큽니다. 자동 재시도가 partial output 보존, background 작업 복구와 결합되면, 에이전트 작업은 더 배치 작업에 가까워집니다.
하지만 무작정 재시도 횟수를 늘리는 것도 위험합니다. 잘못된 명령, 외부 API 장애, 권한 오류를 300번 반복하면 비용과 시간이 낭비됩니다. retry policy는 transient error에만 강하게 적용하고, deterministic failure에는 빨리 멈추게 해야 합니다.
Claude Code를 여러 명이 함께 쓰는 팀이라면 이번 변화에 맞춰 운영 규칙도 바꿔야 합니다. 우선 background agent가 만든 변경은 반드시 별도 브랜치나 worktree에서 관리해야 합니다. 릴리스 노트에는 background agents launched from claude agents가 code work를 마치면 commit, push, draft PR까지 열 수 있다는 내용도 있습니다. 자동 PR은 편하지만, 권한 없는 저장소나 실험 브랜치에서 무분별하게 돌리면 리뷰 큐가 오염됩니다.
둘째, partial work를 결과물로 인정하는 기준을 정해야 합니다. 예를 들어 “테스트 명령까지 통과한 경우만 완료”, “빌드는 실패했지만 원인 분석과 수정 후보가 있으면 partial accepted”, “API usage limit으로 중단되면 재시도 전 사람 승인 필요” 같은 규칙입니다.
셋째, 브라우저와 shell 권한을 분리해야 합니다. 읽기 전용 확인, 로컬 파일 수정, 외부 네트워크 접근, 배포 명령은 서로 다른 승인 단계로 둬야 합니다.
