저는 Claude Code를 꽤 오래 써왔습니다. 개발자가 아닌데도 이 도구가 일하는 방식을 완전히 바꿔놨다고 생각할 만큼, 솔직히 좀 놀라운 경험이었죠. 그런데 얼마 전, Claude Code의 소스코드가 유출됐다는 소식을 들었습니다. 그리고 개발자들이 그 코드를 보고 비웃었다는 이야기까지 들었을 때, 처음엔 잘 이해가 되지 않았습니다. 사실 비개발자인 저는 봐도 뭐가 문제인지 알 방법이 없었죠.

그래서 코드 대신 반응을 읽어봤습니다. Claude Code의 소스코드를 본 개발자들이 뭐라고 하는지, 어떤 맥락에서 비웃었는지를 따라가다 보니, 코드 품질 논쟁 너머에 있는 다른 이야기에 닿았습니다.

코드를 열어본 개발자들의 반응

2026년 3월 31일, Anthropic이 Claude Code 패키지를 npm에 업데이트하면서 실수로 59.8MB짜리 소스맵 파일을 함께 올렸습니다. 내부 디버깅용으로 만든 파일이었는데, 그 파일 안에 전체 소스코드로 향하는 경로가 담겨 있었습니다. 누군가 그걸 발견해 X에 올렸고, 몇 시간 만에 수천 명의 개발자가 코드를 열어봤습니다.

그리고 그들의 반응은 다소 냉혹했습니다.

코드 안에는 print.ts라는 파일이 있었는데, 전체 길이가 5,594줄이었습니다. 그 안에 함수 하나가 3,167줄에 달했습니다. 쉽게 말하면, 책 한 권 분량의 내용이 단락 구분도 목차도 없이 하나의 문단으로 쓰인 것과 비슷합니다. 읽을 수는 있지만, 특정 부분을 찾거나 고치려면 전체를 다 뒤져야 하는 구조였죠. 게다가 AI 회사인데 감정 분석에 AI 대신 단순 규칙 기반 문자열 탐색을 쓰고 있었고, 64,464줄의 코드에 오류 검증 장치는 하나도 없었죠.

Bluesky(블루스카이)에는 이런 말이 올라왔습니다.

"Vibe coded garbage can get you to $2.5 billion annualized recurring revenue in under a year if the product market fit is there."
"대충 짠 쓰레기 코드도, 제품이 시장에 맞으면 1년 안에 연 매출 25억 달러를 만들 수 있다."

이 문장은 쓰레기 코드라는 조롱과, 그래도 25억 달러를 만들었다는 인정이 한 문장 안에 공존하고있죠. 개발자 커뮤니티 안에서도 반응은 엇갈렸습니다. "이런 구조는 유지보수 악몽/ 이건 정말 쓰레기 코드다"라는 쪽과, "이번 유출로, 형펀없는 코드도 훌륭한 제품을 만들 수 있고 이는 이미 시장이 검증했다"는 쪽이 동시에 등장했죠. 누군가에게는 대충 짠 쓰레기 코드라고 불리는 제품이, 시장 선두를 달리고 있다니 아이러니하지 않나요? (해커뉴스에서 이번 유출에 관한 다양한 반응을 확인해볼 수 있습니다.)

경험은 코드로 복제되지 않는다

이번 유출로 Claude Code의 내부가 드러났는데도 점유율이 흔들리지 않았다는 것, 그 자체가 하나의 질문이라 생각합니다. 생각해보면 경쟁자들의 코드는 이미 오래전부터 공개돼 있었습니다. Gemini CLI는 Apache 2.0 라이선스로 GitHub에 올라가 있고, OpenAI의 Codex CLI도 마찬가지입니다. 코드를 자유롭게 확인하고, 수정하고, 포크할 수 있습니다. 그런데 2026년 초 여러 매체의 보도를 종합하면, AI 개발 도구 시장에서 Claude Code의 점유율은 아직도 약 31%로 추정됩니다. 소스를 공개한 경쟁자들이 왜 이 격차를 좁히지 못하는 걸까요.

유출 직후 Hacker News에 공유된 build.ms의 글이 이 질문을 정면으로 파고들었습니다. 필자의 답은 이렇습니다. 사용자가 지불하는 건 코드에 대한 접근권이 아니라, 모델과 도구가 매끄럽게 통합된 경험이라고요. 코드를 공개하는 것과 그 경험을 복제하는 건 다른 문제라는 겁니다.

이 말이 가리키는 건 두 층위입니다. 하나는 모델 자체입니다. Gemini CLI를 쓰면 Gemini를 쓰게 되고, Codex CLI를 쓰면 OpenAI 모델을 쓰게 됩니다. 코드를 복사해도 그 안에 흐르는 모델은 복사되지 않습니다. 다른 하나는 도구와 모델 사이의 통합 방식입니다. 어떤 맥락을 얼마나 넣을지, 파일 구조를 어떻게 읽을지, 에러를 어떻게 처리할지. 이 결정들은 수많은 실제 사용 속에서 쌓인 것들입니다. 코드를 복사한다고 그 축적이 따라오지는 않습니다.

저도 이 말이 직관적으로 맞다는 느낌이 듭니다. Claude Code를 쓸 때 저는 코드를 보지 않습니다. 지시를 내리고, 결과를 받고, 그 결과가 맞는지 판단합니다. 내부가 3,167줄짜리 함수로 돌아가든, 100개의 모듈로 분리돼 있든 그건 경험에 영향을 주지 않습니다. 이 말이 불편하게 들릴 수 있다는 걸 압니다. 특히 코드 품질을 중요하게 생각해온 개발자라면요.

Anthropic이 선택한 건 클린 코드가 아니었다

Claude Code 총괄 Boris Cherny가 인터뷰에서 꺼낸 말이 있습니다. Anthropic은 코드를 더 잘 읽기 위한 시스템이 아니라, 코드 변경의 결과를 더 빠르게 감지하기 위한 시스템을 만들고 있다고요.

차이가 미묘하게 들리지만, 실제론 꽤 다른 방향입니다. 전통적인 접근은 이렇습니다. 코드를 잘 짜면 버그가 줄고, 버그가 줄면 제품이 안정적이다. 그래서 코드 리뷰가 있고, 테스트가 있고, 모듈화 원칙이 있습니다. Anthropic의 접근은 다릅니다. 코드를 아무리 잘 짜도 버그는 생긴다. 그렇다면 버그가 생겼을 때 얼마나 빨리 감지하고, 얼마나 빨리 되돌릴 수 있는가가 더 중요하다. 예방보다 감지와 복구에 투자하는 것입니다.

이쯤에서 저도 드는 의문이 있었습니다. 기술부채는요? 빠르게 감지하고 복구해도, 나쁜 코드가 쌓이면 결국 더 이상 빠르게 움직일 수 없게 되지 않을까요. 틀린 지적이 아닙니다. 깔끔하게 짜지 않으면 나중에 손댈 수 없는 코드가 된다는 것은, 전통적인 개발 원칙이 존재하는 이유 중 하나이기도 합니다. 그리고 Anthropic이 이 문제를 피해갈 수 있다는 보장은 없습니다. 다만 아래 두 가지가 이 그림을 조금 복잡하게 만듭니다.

하나는 Anthropic 자신이 만든 도구가 코드 리팩터링을 도울 수 있다는 점입니다. 기술부채가 쌓이더라도 Claude Code로 정리할 수 있다면, 그 비용이 예전과 같지 않을 수 있습니다. 다른 하나는 속도 자체가 만들어낸 결과입니다. 빠르게 배포하고 빠르게 감지하면서 시장을 선점했고, 그 격차가 기술부채보다 먼저 작동했습니다.

이렇게 보면 3,167줄짜리 함수가 조금 다르게 읽힙니다. 유지보수성 측면에서 이상적인 구조는 아닙니다. 그런데 빠른 배포와 빠른 감지를 우선하는 팀이 선택할 수 있는 트레이드오프이기도 합니다. 저는 이걸 의도 없는 구조라고 보기 어렵다는 생각입니다.

마무리: 이건 코드만의 이야기가 아니다

이쯤에서 저는 이 이야기를 소프트웨어 밖으로 꺼내보고 싶었습니다.

완벽한 기획과 준비를 위해 출시를 미루는 팀과, 일단 내보내고 반응을 보는 팀. 실수가 나오지 않도록 프로세스를 촘촘하게 만드는 조직과, 실수가 나왔을 때 빠르게 알아채는 시스템을 만드는 조직. 두 방향은 서로 다른 전제 위에 서 있습니다. 완벽함을 추구하는 방향은 "실수를 막는 게 회복하는 것보다 낫다"는 전제입니다. 빠른 감지를 추구하는 방향은 "실수는 어차피 생긴다, 그러면 빨리 아는 게 낫다"는 전제입니다.

이 역시 두 전제 중 어느 쪽이 맞다고 단정하기가 어렵습니다. 그런데 Anthropic이 어떤 전제를 골랐는지, 그리고 그 결과가 어땠는지는 이미 결과로 나와 있습니다. 코드 리뷰를 통과 못 할 코드로 만든 제품이 시장을 지배하고 있는 이유는, 단순히 "코드 품질이 중요하지 않아서"가 아닐 수 있습니다. 완벽하게 짜는 것보다 빠르게 감지하는 쪽에 에너지를 쏟았기 때문일 수 있습니다. 그리고 그 판단이 어디까지 통하는지는, 앞으로 더 지켜봐야할 것 입니다.