무슨 일이 있었나요?
Anthropic이 만든 AI 코딩 도구 Claude Code의 소스코드가 의도치 않게 외부에 공개되는 일이 벌어졌어요. 해킹이나 내부자 유출 같은 드라마틱한 사건이 아니라, NPM 패키지에 포함된 소스맵(source map) 파일 때문에 일어난 일이에요.
소스맵이 뭐냐면, JavaScript 코드를 배포할 때 보통 번들링(여러 파일을 하나로 합치기)과 미니파이(변수명을 줄이고 공백을 제거해서 파일 크기를 줄이기) 과정을 거치거든요. 이렇게 하면 배포용 코드는 사람이 읽기 힘든 형태가 돼요. 소스맵은 이 변환된 코드를 원래 소스코드와 매핑해주는 파일이에요. 주로 디버깅할 때 쓰이는데, 브라우저 개발자 도구에서 원본 코드를 보면서 디버깅할 수 있게 해주는 역할을 하죠.
문제는 이 소스맵 파일이 NPM 레지스트리에 올라간 Claude Code 패키지 안에 그대로 포함되어 있었다는 거예요. 소스맵에는 원본 소스코드의 전체 내용이 담겨 있기 때문에, 누구든 NPM에서 패키지를 받아서 소스맵을 열어보면 미니파이 전의 원본 코드를 복원할 수 있었던 거죠.
기술적으로 어떻게 발생한 건가요?
이건 사실 많은 개발팀이 간과하는 부분이에요. 빌드 파이프라인을 구성할 때, 개발 환경에서는 디버깅을 위해 소스맵을 생성하는 게 당연하거든요. 문제는 프로덕션 빌드에서도 소스맵 생성 옵션이 켜져 있거나, 생성된 소스맵 파일을 배포 패키지에서 제외하는 걸 깜빡하는 경우예요.
Webpack, esbuild, Rollup 같은 번들러를 쓸 때 sourcemap: true 옵션이 켜져 있으면 .map 파일이 생성되는데요, .npmignore나 package.json의 files 필드에서 이 .map 파일을 명시적으로 제외하지 않으면 NPM에 퍼블리시할 때 함께 올라가게 돼요. Claude Code의 경우가 정확히 이 상황이었던 거예요.
소스맵 파일의 구조를 잠깐 살펴보면, JSON 형식으로 되어 있고 sourcesContent라는 필드에 원본 소스코드가 통째로 들어가 있어요. 그래서 별도의 디컴파일 도구 없이도, 소스맵 파일 하나만 있으면 원본 코드를 거의 완벽하게 복원할 수 있어요. 이게 웹 프론트엔드에서는 어차피 브라우저에서 다 보이니까 크게 문제가 안 되는데, 서버사이드 코드나 CLI 도구 같은 경우에는 의도하지 않은 코드 공개가 되는 거죠.
유출된 코드에서 알 수 있는 것들
유출된 소스코드를 통해 Claude Code의 내부 구조가 상당 부분 드러났어요. Claude Code가 어떻게 터미널 명령어를 실행하고, 파일을 읽고 쓰며, Claude API와 통신하는지에 대한 구현 디테일이 공개된 거예요. 시스템 프롬프트의 구조나 도구 호출 방식 같은 것들도 확인할 수 있게 되었고요.
이런 유출은 보안 관점에서 몇 가지 우려를 낳아요. 내부 구현을 알면 잠재적인 취약점을 찾기 더 쉬워지거든요. 물론 오픈소스 프로젝트는 코드가 공개되어 있어도 안전하게 운영되니까, 코드 공개 자체가 곧 보안 위험은 아니에요. 하지만 "공개할 준비가 된 상태에서 공개하는 것"과 "의도치 않게 유출되는 것"은 다른 문제죠. 전자는 보안 리뷰를 거친 상태이고, 후자는 그렇지 않을 수 있으니까요.
이런 실수, 생각보다 흔합니다
소스맵 유출은 사실 Claude Code만의 문제가 아니에요. 상당수의 웹 서비스들이 프로덕션 환경에서 소스맵을 노출하고 있어요. 브라우저 개발자 도구를 열어서 Sources 탭을 확인해보면, 유명 서비스들도 소스맵을 통해 원본 코드가 노출되는 경우가 종종 있거든요.
NPM 패키지 쪽에서도 비슷한 사례가 여러 번 있었어요. .env 파일이 패키지에 포함되어 API 키가 노출되거나, 내부 테스트 파일이 함께 올라가는 경우도 있었죠. NPM에 한번 퍼블리시된 파일은 unpublish 정책 때문에 쉽게 제거할 수 없는 경우도 있어서, 사전 방지가 정말 중요해요.
비슷한 맥락에서, Docker 이미지에 소스코드나 시크릿이 포함되는 것도 자주 발생하는 실수예요. 멀티스테이지 빌드를 사용하지 않으면, 빌드 과정에서 사용된 소스코드와 의존성이 최종 이미지에 그대로 남을 수 있거든요.
한국 개발자를 위한 실무 체크리스트
이번 사건은 NPM 패키지를 퍼블리시하는 모든 개발자에게 좋은 교훈이 돼요. 특히 회사에서 내부 라이브러리를 private NPM 레지스트리에 올리거나, 오픈소스 프로젝트를 관리하는 분들이라면 아래 사항을 꼭 점검해보세요.
첫째, 빌드 설정에서 프로덕션 빌드 시 소스맵 생성을 비활성화하세요. Webpack이라면 devtool: false, esbuild라면 sourcemap: false로 설정하면 돼요. 개발 환경에서만 소스맵을 생성하도록 환경 변수로 분기하는 게 좋아요.
둘째, .npmignore 파일을 꼼꼼히 관리하세요. 혹은 package.json의 files 필드에 배포할 파일만 명시적으로 나열하는 화이트리스트 방식을 쓰는 게 더 안전해요. 블랙리스트 방식(제외할 파일 나열)보다 화이트리스트 방식(포함할 파일만 나열)이 실수를 줄여줘요.
셋째, 퍼블리시 전에 npm pack으로 어떤 파일이 포함되는지 확인하세요. npm pack --dry-run 명령어를 치면 실제로 NPM에 올라갈 파일 목록을 미리 볼 수 있어요. 이걸 CI에 넣어두면 실수를 미리 잡을 수 있죠.
넷째, CI/CD 파이프라인에 퍼블리시 전 검증 단계를 추가하세요. .map 파일, .env 파일, 테스트 코드 등 배포하면 안 되는 파일이 포함되어 있는지 자동으로 체크하는 스크립트를 넣어두면 사람의 실수를 기계가 잡아줘요.
마무리
핵심 한줄 정리: Claude Code의 소스코드가 NPM 패키지의 소스맵 파일을 통해 의도치 않게 유출되었고, 이는 빌드 파이프라인 관리의 중요성을 다시 한번 일깨워주는 사건이에요.
혹시 여러분의 프로젝트에서도 소스맵이 프로덕션에 노출되고 있지는 않은지 확인해보신 적 있나요? 그리고 NPM 퍼블리시 전에 어떤 검증 과정을 거치고 계신지 궁금해요. 의외로 체크 안 하고 있는 부분이 있을 수 있거든요.
🔗 출처: Hacker News
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공