Claude Code 2.1.161, MCP 비밀값과 셸 설정 보호

AI 요약

• 무슨 일: Anthropic이 Claude Code 2.1.160과 2.1.161을 2026년 6월 2일 연달아 공개했습니다.
  • 2.1.160은 shell startup file과 build-tool config 쓰기 전 승인을 추가했고, 2.1.161은 claude mcp 출력의 비밀값을 redaction합니다.
• 의미: AI 코딩 에이전트의 보안 경계가 모델 응답보다 로컬 설정 파일, MCP 연결, 터미널 출력으로 내려왔습니다.
• 실무 영향: acceptEdits를 켜도 실행 권한을 줄 수 있는 설정 파일은 다시 묻고, MCP 서버 정보는 로그에 그대로 남기기 어렵게 바뀝니다.
• 주의점: 이번 변경은 권한 모델의 보강입니다. secret scanning, workspace trust, CI 격리, 감사 로그 설계는 여전히 별도 운영 과제입니다.

Anthropic의 anthropics/claude-code 저장소가 2026년 6월 2일 두 개의 릴리스를 연달아 올렸습니다. GitHub release note 기준 v2.1.160은 02:10, v2.1.161은 21:58에 공개됐습니다. 겉으로는 작은 CLI 수정처럼 보이지만, 바뀐 항목은 Claude Code가 어디서 멈춰야 하는지에 가깝습니다. 셸 시작 파일, Git 설정, build-tool config, MCP 서버 출력은 모두 로컬 코딩 에이전트가 실수하면 바로 실행 권한이나 비밀값 노출로 이어질 수 있는 지점입니다.

v2.1.160의 첫 줄은 shell startup file입니다. Claude Code는 .zshenv, .zlogin, .bash_login, ~/.config/git/에 쓰기 전 prompt를 추가했습니다. release note는 이런 파일이 unintended command execution으로 이어질 수 있다고 설명합니다. 일반 코드 파일 한 줄을 고치는 것과 셸 시작 파일을 고치는 것은 위험이 다릅니다. 전자는 저장소 안의 diff로 남고 리뷰할 수 있지만, 후자는 다음 터미널 시작이나 Git 명령 실행 때 사용자 환경 전체에 영향을 줄 수 있습니다.

같은 릴리스의 두 번째 줄은 acceptEdits 사용자에게 더 직접적입니다. Claude Code는 acceptEdits mode에서도 실행 권한을 부여할 수 있는 build-tool config 파일에는 쓰기 전 prompt를 띄웁니다. 대상 예시는 .npmrc, .yarnrc*, bunfig.toml, .bazelrc, .pre-commit-config.yaml, .devcontainer/입니다. acceptEdits는 "파일 편집을 자동 승인"한다는 제품명에 가깝지만, Anthropic은 이번 릴리스에서 "편집"과 "실행 경로 변경"을 분리했습니다.

이 구분은 AI 코딩 도구가 autocomplete에서 agent workflow로 바뀐 뒤 더 중요해졌습니다. Claude Code는 파일을 읽고, 수정하고, shell command를 실행하고, MCP server와 background session을 다룹니다. 개발자가 acceptEdits를 켠 이유는 매번 작은 diff 승인에 답하지 않기 위해서입니다. 그러나 .npmrc나 .devcontainer/는 다음 설치, 빌드, 컨테이너 시작의 동작을 바꿀 수 있습니다. 사용자가 "컴포넌트 파일 수정"을 맡겼는데 agent가 package lifecycle hook이나 dev container 설정을 바꾸는 경우, 자동 편집의 편의는 실행 권한 변경으로 확장됩니다.

Claude Code 공식 문서의 permission mode 설명도 이 차이를 전제로 합니다. 문서는 acceptEdits가 working directory 안의 파일 편집과 mkdir, touch, rm, mv, cp, sed 같은 일반 filesystem command를 자동 승인한다고 설명합니다. 동시에 bypassPermissions를 제외한 모든 mode에서 protected path 쓰기는 자동 승인되지 않는다고 적습니다. 이번 v2.1.160은 protected path의 실제 목록과 의미를 제품 사용자가 더 체감하게 만든 변경입니다.

v2.1.161은 MCP 쪽을 건드립니다. release note는 claude mcp list/get/add가 secrets를 terminal에 출력하던 문제를 고쳤다고 적었습니다. ${VAR} reference는 더 이상 확장하지 않고, credential header와 URL secret은 redaction됩니다. MCP는 모델에게 외부 context와 tool을 붙이는 경로입니다. MCP server 설정에는 endpoint, header, token, 조직 내부 URL, 개발용 credential이 들어갈 수 있습니다. CLI가 이를 친절하게 펼쳐 보여주면 문제를 디버깅하기는 쉽지만, 터미널 scrollback, session log, screen recording, support bundle에 비밀값이 남습니다.

이 변경은 "MCP 설정을 안전하게 만들었다"는 완성 선언이 아닙니다. 더 정확하게는 secret이 새는 한 경로를 줄인 것입니다. MCP server 자체가 어떤 credential을 요구하는지, 그 credential이 어떤 repository와 data source에 접근하는지, 로그가 어디에 저장되는지, 팀원이 같은 설정을 공유할 때 어떤 vault를 쓰는지는 여전히 운영 설계입니다. 그래도 CLI 출력 redaction은 기본값의 차이를 만듭니다. 개발자가 claude mcp get을 쳤을 때 실수로 토큰을 복사해 이슈나 채팅에 붙이는 사고를 줄일 수 있습니다.

MCP 보안에서 작은 출력 정책이 큰 이유는 agent의 연결 목록이 곧 공격 표면이기 때문입니다. 코딩 에이전트가 repository만 읽는다면 위험은 주로 source tree 안에 머뭅니다. MCP가 붙으면 ticket, database schema, cloud console, browser automation, secret scanner, internal API, docs search가 모델의 tool 목록으로 들어옵니다. 이때 보안 검토 대상은 "생성된 코드가 안전한가"뿐 아니라 "agent가 어떤 tool과 credential을 볼 수 있는가"입니다. v2.1.161의 redaction은 그 연결 정보를 터미널에 덜 노출하는 쪽의 수정입니다.

v2.1.161에는 관측성 변화도 있습니다. OTEL_RESOURCE_ATTRIBUTES 값이 metric datapoint label에 포함돼, usage metric을 team이나 repo 같은 custom dimension으로 나눠 볼 수 있게 됐습니다. 에이전트 운영에서 이 기능은 비용 추적만의 문제가 아닙니다. 어느 팀이 어떤 저장소에서 장시간 background session을 많이 쓰는지, 어떤 repo가 MCP나 workflow agent 사용량을 급격히 늘리는지, 특정 release 뒤 실패율이 어떻게 바뀌는지 확인할 때 label은 감사와 운영의 공통 입력이 됩니다.

관측성은 통제와 다릅니다. team label이 붙었다고 위험한 command가 막히지는 않습니다. 하지만 운영팀은 막을 대상을 먼저 알아야 합니다. Claude Code가 background session, workflow agent, ultracode, MCP server처럼 긴 실행과 외부 연결을 늘릴수록, 관리자는 "누가 얼마나 썼는가"와 "어떤 tool surface가 켜졌는가"를 같은 대시보드에서 봐야 합니다. OpenTelemetry label 지원은 이 요구에 맞는 낮은 층의 변경입니다.

v2.1.160은 반대로 마찰을 줄인 항목도 넣었습니다. 단일 파일 grep, egrep, fgrep 명령은 이제 read-before-edit check를 만족합니다. 이전에는 파일을 grep으로 본 뒤에도 별도 Read가 필요할 수 있었습니다. 이 수정은 보안 프롬프트가 무작정 늘어나는 방향이 아니라는 점을 보여줍니다. 위험한 설정 파일 쓰기는 다시 묻고, 이미 확인한 단일 파일 편집은 중복 확인을 줄입니다. 좋은 permission system은 모든 것을 막는 시스템이 아니라 위험의 종류에 따라 질문 위치를 바꾸는 시스템입니다.

보조 보도인 DevelopersIO의 6월 2일 정리도 v2.1.160의 승인 프롬프트를 주요 변화로 봤습니다. 대상은 shell startup file, Git config, build-tool config입니다. 이 관찰은 release note의 우선순위와도 맞습니다. Anthropic이 해당 항목을 목록 맨 위에 둔 것은 사용자 경험에서 prompt fatigue가 계속 문제이지만, 특정 파일군은 자동 승인보다 명시 승인이 더 낫다고 판단했다는 뜻입니다.

이 판단은 최근 Claude Code 권한 논쟁과도 이어집니다. 공식 permission mode 문서는 default, acceptEdits, plan, auto, dontAsk, bypassPermissions를 나눕니다. auto는 background safety check로 더 많은 작업을 진행하게 하고, bypassPermissions는 isolated container나 VM에서만 쓰라는 문서상 경고가 붙습니다. 사용자는 긴 작업에서 prompt를 줄이고 싶어 하지만, 보안팀은 agent가 command와 file write를 묶어 처리할 때 승인 기록을 잃고 싶지 않습니다. v2.1.160은 이 두 요구 사이에서 파일 종류별 예외를 늘린 사례입니다.

연구 쪽에서도 같은 질문이 나옵니다. 2026년 4월 arXiv에 올라온 Measuring the Permission Gate 논문은 Claude Code auto mode를 permission gate로 보고 stress-test evaluation을 수행했습니다. 논문 초록은 production traffic 기준 false positive와 false negative를 언급하며, permission classifier가 위험한 tool call을 어떻게 통과시키거나 막는지 다룹니다. 또 다른 2026년 4월 분석인 Dive into Claude Code는 Claude Code를 permission system, MCP, plugins, skills, hooks, subagent delegation, session storage가 결합된 agent system으로 설명합니다. 이번 릴리스의 변경 지점도 바로 그 시스템 주변부입니다.

개발팀이 이번 릴리스에서 바로 확인할 항목은 세 가지입니다. 첫째, acceptEdits나 auto를 기본값으로 쓰는 팀은 shell startup file, Git config, build-tool config에 대한 새 prompt가 CI 또는 headless automation에서 어떻게 동작하는지 봐야 합니다. prompt가 필요한데 headless run이 응답할 수 없으면 작업이 멈출 수 있습니다. 둘째, MCP server 설정을 claude mcp list/get/add로 점검하던 운영 문서가 있다면, redaction 이후 출력 예시를 다시 캡처해야 합니다. 셋째, OpenTelemetry를 쓰는 팀은 OTEL_RESOURCE_ATTRIBUTES에 team, repo, environment 같은 label을 어떤 이름으로 넣을지 정해야 합니다.

보안팀은 이번 변경을 secret scanning의 대체물로 보면 안 됩니다. redaction은 터미널 출력의 노출을 줄이지만, .mcp.json, environment variable, shell history, CI log, issue attachment, screen recording은 다른 경로입니다. MCP server token은 가능하면 vault나 환경 변수 reference로 유지하고, repository 안 설정 파일에는 실제 credential을 두지 않는 편이 낫습니다. Claude Code가 ${VAR}를 확장하지 않는다고 해서, 그 변수가 어디서 주입되는지까지 해결되는 것은 아닙니다.

플랫폼 팀에는 정책 문서의 표현도 바꿔야 합니다. "AI 코딩 도구는 파일을 자동 수정할 수 있다"보다 "AI 코딩 도구는 일반 파일 편집, 실행 경로 변경, credential 연결, 외부 tool call을 서로 다른 승인 단위로 본다"는 식의 문장이 더 정확합니다. .tsx 파일 수정, .npmrc 수정, MCP header 수정, pre-commit hook 수정은 모두 같은 editor action처럼 보일 수 있지만, 실패했을 때의 피해 범위는 다릅니다. 팀 규칙도 파일 확장자보다 실행 효과를 기준으로 써야 합니다.

사용자 경험의 부담도 남습니다. 승인 프롬프트가 늘어나면 개발자는 더 강한 auto mode나 bypass mode를 찾습니다. 과한 차단은 보안을 높이기보다 우회 동기를 만듭니다. Claude Code가 grep 결과를 read-before-edit로 인정한 부분은 그래서 중요합니다. 제품은 위험한 설정 파일에서는 멈추고, 충분히 확인된 파일 편집에서는 중복 질문을 줄여야 합니다. permission system의 품질은 경고 문구의 강도보다 질문의 정확도에서 갈립니다.

이번 릴리스는 화려한 모델 발표가 아닙니다. 새 benchmark도 없고, 대형 기능 이름도 없습니다. 그러나 AI 코딩 에이전트가 실제 개발 환경에 들어갈수록 이런 낮은 층의 변경이 더 자주 중요해집니다. 에이전트가 안전하지 않은 이유는 모델이 틀린 답을 할 수 있어서만이 아닙니다. 셸 시작 파일을 바꾸고, build config로 실행 경로를 만들고, MCP credential을 출력하고, background session 로그에 민감한 정보를 남길 수 있기 때문입니다.

Claude Code 2.1.160과 2.1.161은 그 위험을 제품의 작은 프롬프트와 redaction 규칙으로 나눠 처리합니다. 개발자에게 남는 질문은 명확합니다. 자동 편집을 어디까지 허용할 것인가, 실행 권한을 주는 설정 파일은 누가 승인할 것인가, MCP 비밀값은 어디에 저장하고 어떻게 보여줄 것인가, 사용량 metric은 어떤 팀과 저장소 단위로 남길 것인가입니다. AI 코딩 도구 운영은 이제 모델 선택표보다 로컬 permission table과 로그 정책에서 먼저 차이가 납니다.