본 글에서 알 수 있는 내용:
- 기업의 사내 프록시/게이트웨이가 특정 헤더를 거부하여 발생하던 요청 실패가 수정된 내용
- 백그라운드 클린업(Background Cleanup) 시 최근 붙여넣은 이미지가 사라지는 버그 상세
- Monitor 툴이 Bedrock, Vertex, Foundry 환경에서도 사용 가능해진 변경 사항의 실무 영향
2026년 10월 24일 (UTC), Claude Code v2.1.310이 출시되었습니다. 공식 릴리스 노트는 GitHub에 공개되어 있습니다.
변경점은 매우 다양하지만, 이번에는 대기업 사내 환경에서 claude -p를 사용하여 자동화 파이프라인을 운영하는 입장에서 '확인해 볼 필요가 있다'고 느낀 변경 사항들을 중심으로 정리했습니다. 모든 내용을 아우르는 요약이라기보다는 실무에 영향을 줄 수 있는 내용으로 좁혔습니다.
출처: Anthropic (2026-10-24 공개) https://github.com/anthropics/claude-code/releases/tag/v2.1.310
릴리스 노트에는 다음과 같은 설명이 있습니다.
Fixed requests failing behind some gateways and compatible servers that reject the effort-2025-11-24 beta value or mid-conversation system messages; Claude Code now retries without them
쉽게 말해, 사내 보안 게이트웨이나 기업 프록시가 Claude Code의 요청에 포함된 특정 헤더 값(effort-2025-11-24라는 beta 값) 또는 대화 중간에 추가되는 시스템 메시지를 '부정확한(不正な) 헤더'로 거부하는 경우가 있었습니다. 이 경우 요청이 실패했습니다.
v2.1.310부터는 그러한 환경을 감지하고 재시도할 때 해당 항목들을 제외한 형태로 다시 전송하도록 변경되었습니다.
대기업 특유의 문제점
일반적인 클라우드 환경에서는 문제가 되지 않지만, 대기업에서는 흔히 볼 수 있는 구성입니다. 사내에서 외부 API로 통신하는 경우 한 번 보안 게이트웨이를 거치도록 설계되어 있고, 그 게이트웨이가 '모르는 HTTP 헤더는 모두 차단한다'라는 설정이 되어 있을 때가 있습니다. Claude Code와 같은 새로운 툴이 새로운 beta 헤더를 추가했을 때, 그 값이 허용 목록에 포함되어 있지 않으면 거부될 수 있습니다.
Claude Code를 사내 도입하려 할 때 '왠지 연결이 안 된다', '가끔 실패한다'는 경험을 하셨다면, 이 버전 이후에서 개선되었을 가능성이 있습니다.
본인의 환경(claude -p를 사용한 무인 실행 파이프라인)에서 이 문제가 재현되는지 로그를 확인하는 범위에서는 명확하게 특정할 수 없었습니다. 다만 기업 내부 프록시를 거치는 환경에서 불안정했다면, 이 버전에 업데이트한 후의 동작을 관찰해 보시는 것을 권장합니다.
mid-conversation system messages에 대하여
또 다른 수정 대상인 'mid-conversation system messages(대화 중간에 전송되는 시스템 메시지)'는 대화가 진행되면서 컨텍스트 관리 목적으로 Claude Code가 동적으로 추가하는 내부 시스템 메시지를 말합니다. 일부 게이트웨이가 이를 '첫 번째 메시지와 형식이 다르다'고 거부하는 경우가 있었습니다. 기업용 API 게이트웨이 제품(Azure API Management 등)에서 자체적인 요청 검사를 넣은 환경에서 발생하기 쉬운 문제로 추측하고 있습니다 (미확인).
Fixed background cleanup deleting some recent files, such as pasted images, when cleanupPeriodDays is set to a very large value
cleanupPeriodDays를 긴 값(큰 숫자)으로 설정했을 경우, 최근 붙여넣은 이미지가 백그라운드 클린업 처리 과정에서 실수로 삭제되는 버그가 있었습니다.
왜 이런 일이 발생했는가
cleanupPeriodDays
이 옵션은 오래된 파일을 자동으로 삭제할 때까지의 일수를 지정합니다. 원래는 "N일 이상 오래된 파일"을 삭제해야 하지만, 값이 너무 크면 계산에 오류가 발생하여(아마도 정수 오버플로우나 날짜/시간 계산 버그) "최근" 파일이 잘못 "오래됨"으로 판정되었습니다.
이 버그는 "오랫동안 보존하고 싶어서 큰 값을 설정했다"는 의도가 역으로 작용하여 발견하기 어려운 문제였습니다.
영향을 받기 쉬웠던 환경
- 스크린샷이나 그림을 붙여넣으며 작업하는 경우에
cleanupPeriodDays를 길게 설정했던 환경
- CI 또는 자동화 파이프라인에서 이미지 파일을 처리한 후 확인하는 설계
본 프로젝트에서는 이미지 붙여넣기가 적어 직접적인 영향은 확인되지 않았으나, 설정을 한 경우에는 v2.1.310으로 업데이트하여 개선됩니다.
Monitor 툴과 플러그인 모니터가 Bedrock, Vertex, 그리고 Foundry에 추가되었으며, 텔레메트리 또는 필수적이지 않은 트래픽이 비활성화된 경우에도 긴 포그라운드 슬립(long foreground sleeps)이 차단됩니다.
Monitor 툴은 명령어의 출력을 실시간으로 읽어 루프의 종료 조건을 판별하는 메커니즘입니다. 이 기능이 Bedrock, Vertex, Foundry를 통해 Claude Code를 구동하는 환경에서도 사용할 수 있게 되었습니다.
또한, 텔레메트리나 비필수 트래픽이 무효화된 환경(네트워크 제한이 엄격한 환경)에서도 작동하게 된 점도 함께 확인해 볼 가치가 있습니다.
긴 포그라운드 슬립 차단 (long foreground sleeps)
더불어, 긴 포그라운드 슬립(long foreground sleeps) 또한 이러한 환경에서 차단되게 되었습니다. 이는 claude -p를 사용한 무인 실행 파이프라인에서 의도치 않게 장시간 대기하는 경우를 방지하기 위한 변경입니다.
무인 실행 파이프라인에서 Monitor 툴을 사용하는 경우, Bedrock 및 Vertex 환경에서 이 변경으로 인해 동작 방식이 달라질 수 있습니다. 특히 long foreground sleeps에 의존하는 플로우는 사전에 확인해 보는 것이 좋습니다.
실무 적용 시 영향
AWS Bedrock이나 Google Vertex AI를 통해 Claude를 사용하는 대기업의 AI 기반 팀들은, Claude Code와의 통합 부분에서 Monitor 툴을 사용할 수 있게 되면서 더욱 세밀한 실행 제어가 가능해졌습니다. 비용 및 보안 관점에서 텔레메트리를 비활성화하는 환경에서의 동작이 보장된 것도 기업 도입 장벽 중 하나가 낮아진 느낌입니다.
'Prompt is too long' 오류 발생 후 컴팩션(대화 압축) 처리에서, base64나 SVG와 같이 '문자당 정보 밀도가 높은 텍스트'를 포함하는 대화 내용이 과도하게 축소되지 않고 대량으로 남아 다음 요청 역시 같은 이유로 실패하는 사례가 있었습니다.
요컨대, "프롬프트가 너무 김 → 컴팩션 → 여전히 너무 김 → 다시 실패"라는 루프가 발생하고 있었던 것입니다.
자동화 파이프라인에서 자주 발생했던 이유
장시간 자동 실행 파이프라인에서는 스크린샷(base64 인코딩 이미지)이나 그래프, SVG 파일을 포함한 응답이 누적되는 경우가 있습니다. 이러한 파일들은 '고밀도 텍스트'에 해당하므로 이 버그에 취약했습니다.
본 프로젝트에서는 weekly-reports/daily-log.md (30만 자 초과)와 같은 대용량 파일을 읽어오지 않도록 하고 있는데, 그 이유 중 하나가 이러한 '토큰 밀도가 높은 상태'를 피하기 위해서이기도 합니다. 이번 수정으로 이 문제가 근본적으로 개선되었다면 장시간 파이프라인의 안정성에 기여할 것이라고 생각합니다.
Windows 환경에서 Git Bash가 설치되어 있지 않은 경우, PreToolUse와 PermissionRequest 후크의 명령어가 "따옴표로 묶인 경로만" 형식이었을 때, 후크가 원래 차단해야 할 도구 호출(tool call)이 통과해 버리는 버그가 있었습니다.
실무에 미치는 영향
Windows 작업 스케줄러에서 Claude Code의 자동 실행을 설정하여 사용하고 있고, 후크를 이용해 접근 제어를 하고 있는 환경이라면 확인해 볼 가치가 있습니다. "후크로 막았다고 생각했는데 통과했던" 문제가 해결되는 변경 사항입니다.
특히 Git Bash가 없는 Windows 서버 환경에서 운영하는 경우와 관련이 깊습니다. 후크 설정을 재검토할 기회가 될 것입니다.
이번 릴리스에는 VSCode 확장 및 클라우드 세션 관련 수정사항이 다수 포함되어 있습니다. 항목별로 정리합니다.
VSCode 확장
- 플랜 리뷰 카드에서 "피드백을 보내고 계획을 계속하기" 버튼을 Enter 키로 눌렀을 때, 플랜이 승인된 것으로 잘못 처리되던 버그를 수정했습니다.
- 브랜치 전환 후 클라우드 세션 패널에 "Something went wrong"이 표시되던 문제를 수정했습니다.
클라우드 세션(Enterprise)
- 클라우드 세션과 원격 제어(Remote Control) 권한을 Enterprise의 사용자 지정 역할(custom role)에 추가할 수 있게 되었습니다 (역할별로 접근 제어가 가능해짐).
- 클라우드 환경 설정 스크립트에 "파일에서 불러오기" 버튼이 추가되었습니다.
- 클라우드 환경 편집 다이얼로그에서 저장 및 아카이브 실패 시 오류가 다이얼로그 내에 표시되도록 개선되었습니다.
- 일반 설정에서 클라우드 세션이나 원격 제어를 켜기 할 때 확인 화면이 나타나도록 변경되었습니다.
Enterprise 환경에서 클라우드 세션을 배포하는 팀은 역할 설정 변경(사용자 지정 역할에 권한 추가)이 필요할 수 있으므로 확인해 두시면 좋습니다.
기타 (자동 실행 및 이미지 표시 개선)
- 비대화형 세션(-p, Agent SDK)에서 압축 시 메모리 사용량을 개선했습니다 (큰 트랜스크립트 파일 처리 효율성 향상).
- tmux, kitty, Ghostty, iTerm2에서의 이미지 렌더링을 개선했습니다.
- auto 모드에서 작업 디렉터리 외부의 로드를 차단할 때 표시되는 설명 문구를 개선했습니다.
(참고: 게이트웨이 호환성 수정은 실제로 어떤 게이트웨이 제품/버전에서 효과가 나타나는지 (사내 프록시 종류 및 설정에 따라 다름) 확인해야 합니다.)
- Monitor 도구를 Bedrock을 통해 사용했을 때의 성능 영향.
- 비대화형 세션 메모리 개선이 어느 정도 크기의 트랜스크립트 파일에서 효과를 볼 수 있는지 여부.
v2.1.309와 v2.1.310처럼 짧은 간격으로 릴리스가 이어지고 있습니다. 자동화 파이프라인을 운영하는 팀은 변경 로그를 정기적으로 확인해 두는 것이 좋습니다.
대기업의 AI 추진 담당자로서 바라볼 때, 이번 수정들은 "사내 환경에서의 장벽을 하나씩 제거해 나가는" 방향성이 느껴집니다. 게이트웨이 호환성, Windows의 후크(hook), Enterprise의 역할 관리 등 모두 "사용하고 싶지만 사내 환경에서는 어려웠던" 목소리에 응답하는 내용입니다.
대기업 현장에서 AI 에이전트의 본래 가동률을 높여나갈 때 느끼는 점들은 별도의 글로 정리했습니다.