AI-First 팀 리드가 가장 먼저 받는 질문
"Claude Code, 우리 팀에 써도 안전해요?"
솔직히 말하면, 저도 한동안 이 질문에 명확한 답을 못 했습니다. 생산성은 체감되는데, 보안은 불안하고, 팀원한테 "그냥 써봐" 하기엔 찜찜한 그 지점. 최근 두 가지 소식이 이 질문에 대한 제 생각을 정리해줬습니다. 하나는 꽤 무거운 취약점 리포트, 다른 하나는 믿기 어려울 만큼 인상적인 마이그레이션 성공 사례입니다.
그림자 먼저: 저장소를 '열기만' 해도 털립니다
Check Point Research가 Claude Code에서 발견한 취약점 3건이 공개됐습니다. 모두 패치가 완료된 상태지만, 내용을 보면 그냥 넘기기 어렵습니다.
첫 번째는 .claude/settings.json의 프로젝트 훅(Hooks)을 이용한 코드 인젝션입니다(CVSS 8.7). 사용자 동의 없이 임의 코드가 실행될 수 있었고, 2025년 9월 v1.0.87에서 패치됐습니다. 두 번째는 .mcp.json의 enableAllProjectMcpServers 옵션을 악용해 MCP 서버 초기화 시 쉘 명령을 자동 실행시키는 방식(CVE-2025-59536, CVSS 8.7)으로, 2025년 10월 v1.0.111에서 막혔습니다. 세 번째는 ANTHROPIC_BASE_URL 환경변수를 공격자 서버로 덮어써 API 키를 탈취하는 구조(CVE-2026-21852, CVSS 5.3)였으며, 2026년 1월 v2.0.65에서 수정됐습니다.
세 취약점의 공통점이 핵심입니다. 신뢰하지 않는 저장소를 클론하거나 여는 것만으로 공격이 시작됩니다. 코드를 읽거나 실행하지 않아도 됩니다. Check Point는 이를 두고 "설정 파일 자체가 실행 레이어의 일부가 됐다"고 표현했습니다. AI 에이전트가 명령 실행·외부 연동·네트워크 통신을 자율적으로 수행하게 되면서, 소스 코드뿐 아니라 저장소를 여는 행위 자체가 공급망 위협의 시작점이 될 수 있다는 경고입니다.
팀 단위로 쓰면 이 리스크는 곱셈이 됩니다. 팀원 한 명이 외부 기여자의 PR을 로컬에서 열어보는 순간, API 키가 유출될 수 있었던 구조였으니까요.
빛: 25,000줄, 2주, 제로 리그레션
그럼에도 AI 코딩 에이전트를 포기하기 어려운 이유가 있습니다. dev.to에 공개된 사례 하나가 그 이유를 수치로 보여줍니다.
Ladybird 브라우저의 JavaScript 엔진 프론트엔드인 LibJS 전체를 C++에서 Rust로 포팅한 작업입니다. 렉서·파서·AST·바이트코드 생성기까지, 버그 하나가 수천 개 프로그램을 조용히 망가뜨릴 수 있는 코어 컴포넌트였습니다. 경험 많은 엔지니어라면 몇 달을 잡는 작업이라고 했습니다.
Andreas Kling은 Claude Code와 Codex를 활용해 2주 만에 완료했습니다. ECMAScript 테스트 스위트 52,898개, Ladybird 내부 테스트 12,461개, 성능 리그레션 모두 제로. 요구 조건은 '기능적으로 유사'가 아닌 바이트 단위로 동일한 AST·바이트코드 출력이었습니다.
방법론이 숫자보다 중요합니다
이 사례에서 진짜 훔쳐야 할 건 '2주·25,000줄'이라는 헤드라인이 아니라 작업 구조입니다.
① 아키텍처 결정은 사람이 쥔다. AI는 "이 함수를 Rust로 변환해줘"라는 경계 명확한 태스크만 받았습니다. 로드맵·설계 방향·우선순위는 전부 엔지니어가 가져갔습니다. AI가 '엔지니어링을 하는' 것과 '엔지니어가 AI로 실행 속도를 곱하는' 것은 전혀 다른 결과를 냅니다.
② 작은 단위로 쪼갠다. 파일 단위나 모듈 단위가 아니라 함수 단위, 데이터 구조 단위. AI의 오류율은 범위와 함께 복리로 늘어납니다. 30줄짜리 출력은 즉시 검증 가능하고, 1,000줄짜리 출력은 리뷰하는 시간에 이미 속도 이점이 증발합니다.
③ 두 번째 모델로 적대적 리뷰. 생성한 모델과 다른 모델이 출력물을 리뷰합니다. 첫 번째 모델은 '완결되어 보이는 것'을 만들려 하고, 두 번째 모델은 원본 코드에 대한 애착이 없기 때문에 훨씬 날카롭게 문제를 찾아냅니다. AI를 생성에만 쓰고 검증에는 안 쓰는 건 절반만 쓰는 겁니다.
④ 타협 없는 검증 기준. '바이트 단위 동일 출력'이라는 하드 요구사항이 '그냥 테스트 통과'와 다른 결과를 만들었습니다. K8s 마이그레이션이라면 kubectl apply --dry-run=server와 스키마 검증, 정책 체크가 이 역할을 합니다.
테크 리드가 지금 당장 해야 할 일
두 소식을 같이 보면 행동 지침이 꽤 명확해집니다.
버전부터 확인하세요. 패치는 완료됐지만, 팀 전체가 최신 버전을 쓰고 있는지 확인하는 건 리드의 몫입니다. v1.0.87, v1.0.111, v2.0.65 이상인지 지금 바로 체크할 수 있습니다.
"신뢰하지 않는 저장소는 열지 않는다"를 팀 룰로 명문화하세요. 외부 PR 리뷰, 오픈소스 기여 코드 확인 등 일상적인 작업이 이 벡터에 해당합니다. 지금 당장 온보딩 문서에 한 줄 추가하는 게 가장 빠른 보안 조치입니다.
ANTHROPIC_BASE_URL 환경변수를 CI/CD에서 관리하세요. 개발자 로컬에서 임의로 덮어쓸 수 없도록 환경 격리하는 것도 공급망 리스크를 줄이는 방법입니다.
그리고 마이그레이션 방법론은 지금 팀에서 "다음 분기로 미루고 있는" 작업에 바로 적용해 보세요. K8s API 버전 업그레이드, Helm → Kustomize 전환, Terraform 스테이트 마이그레이션. 이 사례의 핵심은 'AI가 한다'가 아니라 '사람이 설계하고 AI로 실행 속도를 올린다'는 구조에 있습니다.
전망: 설정 파일이 공격 표면이 되는 세상
Anthropci는 Claude Code에 원격 제어 기능을 추가하고, 컴퓨터 사용 에이전트 기업 Vercept를 인수하는 등 에이전트 역량을 빠르게 확장하고 있습니다. 모바일과 브라우저에서 로컬 PC의 Claude Code 세션을 이어받는 원격 제어 기능은 특히 비동기 협업 환경에서 매력적입니다.
하지만 기능이 강해질수록 공격 표면도 넓어집니다. Check Point의 경고처럼, AI 에이전트가 자율적으로 명령을 실행하고 외부와 통신하는 구조에서는 설정 파일이 곧 실행 레이어입니다. .claude/settings.json, .mcp.json이 이제 소스 코드만큼, 어쩌면 그보다 더 민감하게 관리돼야 한다는 의미입니다.
"AI는 도구이자 동료다"라는 말을 자주 씁니다. 동료를 팀에 합류시킬 때 우리가 하는 것처럼—보안 권한을 최소화하고, 작업 범위를 명확히 정의하고, 산출물을 검증하는 프로세스를 갖추는 것—그게 Claude Code를 팀에 제대로 도입하는 방법입니다. 불안해서 못 쓰는 것도, 맹신하고 아무 저장소나 여는 것도 정답이 아닙니다.