AI가 코드를 짜는데 왜 팀은 막히나
Dario Amodei가 "2025년 안에 AI가 코드의 90%를 작성할 것"이라고 했을 때, 많은 엔지니어들은 그 예측을 반쯤 흘려들었다. 그런데 지금 현장에서 실제로 일어나고 있는 일을 보면, 예측보다 더 흥미로운 문제가 드러난다. AI가 코드를 '많이' 짜는 팀과, 그 코드로 '실제로 제품을 만드는' 팀이 다르다는 것이다.
Claude Code 제작자 Boris Cherny는 지난 12월 자신이 커밋한 코드의 100%가 AI 작성이었다고 밝혔다. FTIR 분석 플랫폼을 혼자 구축한 재료공학 연구자는 전체 코드의 약 70%를 Claude와 함께 썼다. 숫자만 보면 성공 사례다. 그런데 같은 도구로, 비슷한 비율로 AI를 쓰면서도 localhost를 벗어나지 못하는 팀이 훨씬 많다. 차이는 어디서 오는가.
문제는 도구가 아니라 '컨텍스트 설계'다
TracE 앱을 개발한 팀의 사례는 이 문제를 가장 선명하게 보여준다. Claude가 생성한 컴포넌트는 코드 자체는 깔끔했다. TypeScript도 맞고, 훅 구조도 정상이었다. 그런데 실제 앱에 붙이면 아무것도 작동하지 않았다. 이유는 단순했다. Claude가 만들어낸 코드는 이 팀의 앱이 아니라 '일반적인 앱'을 위한 코드였기 때문이다.
Claude는 표준 Authorization 헤더를 썼지만, 이 팀의 백엔드는 Catalyst 게이트웨이 충돌을 피하기 위해 X-TE-Token을 커스텀 헤더로 쓰고 있었다. Claude는 localStorage로 토큰을 저장했지만, 이 앱은 모바일과 웹을 동시에 지원해야 해서 플랫폼별 스토리지 래퍼를 따로 구현해둔 상태였다. 어느 것도 '틀린' 코드가 아니었다. 하지만 이 팀의 시스템에는 맞지 않는 코드였다.
이 팀이 찾은 해결책은 tracE.md—전체 스택 구조, 데이터베이스 스키마, 백엔드 라우트, 배포 워크플로우, 그리고 삽질로 배운 패턴들을 한 파일에 정리한 아키텍처 문서였다. 이걸 매 Claude 세션 시작 전에 컨텍스트로 넣었다. 결과는 즉각적이었다. 3~5번 주고받던 기능 구현이 첫 번째 응답에서 바로 맞아떨어지기 시작했다.
아키텍처 파일은 문서가 아니다. Claude의 워킹 메모리다.
도메인 전문성 없는 AI 코딩은 '아름다운 실패'를 만든다
FTIR 분석 플랫폼 개발 사례는 또 다른 실패 패턴을 보여준다. 개발자가 아닌 재료공학 연구자가 Claude와 함께 프로덕션 서비스를 구축했고, 코드의 70%는 AI가 작성했다. 그런데 흥미로운 건 나머지 30%다. 이 30%는 단순히 'AI가 못 한 부분'이 아니었다.
Claude가 생성한 피크 매칭 알고리즘은 유닛 테스트를 통과했다. 수학적으로도 맞았다. 하지만 실제 스펙트럼 데이터에서는 틀렸다. 피크 위치가 수치상으로는 매칭됐지만, FTIR 화학적으로는 불가능한 조합이었다. 도구의 문제가 아니라 도메인 지식의 문제였다. 첫 번째 알고리즘 설계안 세 개를 버린 것도, 프로덕션에서 터진 메모리 OOM과 Cloudflare 타임아웃을 잡은 것도, 모두 도메인 전문성을 가진 사람이 있었기에 가능했다.
같은 이유로, 컨텍스트 없이 AI를 쓰는 팀은 세 번째 레이어에서 무너진다. 인터페이스(UI)는 AI가 잘 만든다. 데이터 레이어는 점점 흔들린다. 그리고 인증, 배포, 멀티 디바이스 세션, 플랫폼별 동작 차이—이 프로덕션 레이어에 닿는 순간 컨텍스트 없이 쌓아온 기술 부채가 한꺼번에 터진다.
'취향'이라는 이름의 판단 능력
OpenAI Codex 팀이 독립적으로 도달한 결론이 있다. AI가 코드를 대량 생성하는 시대에 엔지니어의 가치를 가르는 것은 속도도, 지식의 양도, 경력도 아니라 '취향(taste)'—즉 무엇을 만들지 판단하는 평가 능력이라는 것이다.
이 취향은 세 가지 형태로 작동한다. 두 구현 중 왜인지 설명하기 전에 어느 쪽이 더 나은지 아는 인식(Recognition), 코드 한 줄 쓰기 전에 '이건 옳은 기능이 아니다'라고 말하는 나침반(Compass), 지금 좋은 것이 아니라 2년 뒤 중요해질 것을 아는 비전(Vision).
Boris Cherny가 Claude Code의 todo 리스트 기능을 이틀간 20개 프로토타입으로 만든 이유가 여기 있다. 느린 게 아니었다. AI로 빠르게 실험하면서 '필연적으로 느껴지는' 형태를 찾아가는 과정이었다. 8개 에이전트를 잘못된 문제에 돌리는 것보다 2개를 정확한 문제에 돌리는 쪽이 더 많은 가치를 만든다는 것—이게 취향이 가진 레버리지다.
팀 리빌딩 관점에서 보면
이 세 가지 사례가 함께 가리키는 지점은 하나다. AI-First 팀에서 실패하는 패턴은 도구 선택이나 모델 성능 문제가 아니라, 에이전트를 돌리기 전에 해야 할 설계를 건너뛴 것이다.
실전에서 내일 당장 적용할 수 있는 것으로 정리하면:
첫째, 아키텍처 문서를 Claude의 워킹 메모리로 설계하라. CLAUDE.md, AGENTS.md, 혹은 팀이 정한 어떤 이름이든—전체 스택 구조, 커스텀 패턴, 배포 워크플로우, 그리고 '삽질로 배운 것들'을 담은 파일이 없으면 매 세션마다 아키텍처를 처음부터 재발명하게 된다.
둘째, 도메인 전문성이 없는 영역에서는 AI 코드를 신뢰하지 마라. 테스트를 통과하고 깔끔해 보이는 코드가 도메인 관점에서는 틀릴 수 있다. AI가 생성한 코드의 30%를 프로덕션 이후에 다시 썼다는 사례가 우연이 아니다.
셋째, 품질 판단의 기준을 명시하라. Codex 팀이 쓰는 '30/70 규칙'—핵심 에이전트 코드는 반드시 인간 리뷰, 비핵심 코드는 AI 리뷰—처럼 어떤 코드에 인간의 눈이 필요한지를 팀 차원에서 합의해야 한다.
전망: '더 많이 생성'이 아니라 '더 잘 판단'
Vercel CTO Malte Ubl이 "소프트웨어 생산 비용이 0으로 수렴 중"이라고 했다. 코드 생성이 상품화되면 남는 것은 무엇을 만들지 결정하는 능력, 아키텍처 변경 시점을 감지하는 능력, 산출물이 '충분한지' 판단하는 능력이다.
AI로 코드를 70% 짜고도 실패하는 팀의 공통점은 결국 이것이다. 생성 속도는 높였지만 판단 구조는 바꾸지 않았다. 에이전트가 돌아가는 동안 팀이 해야 할 일—컨텍스트 설계, 도메인 검증, 품질 기준 정의—을 여전히 '나중에 할 일'로 미뤄두고 있다.
코드가 자동으로 생성되는 세상에서 가장 비싼 역량은 '잘 짜는 것'이 아니라 '무엇을 짜고, 무엇을 짜지 않을지 아는 것'이다. 그리고 그 판단을 AI에게 위임하는 순간, 팀은 빠르게 움직이면서도 아무 데도 도달하지 못하는 상태가 된다.