빠른 건 맞다. 그런데 그다음이 문제다
AI 코딩 도구를 처음 팀에 붙이면 다들 비슷한 반응을 보인다. "이거 진짜 빠르다." 1주일 안에 AI 토론 플랫폼을 혼자 런칭한 사례가 이미 나왔고, 100개 AI 페르소나에 배지 72종, i18n, 크론잡, 어드민 패널까지 다 들어갔다. Vibe Coding—원하는 것을 말하면 AI가 짜주는 방식—이 이런 속도를 가능하게 한 건 사실이다.
그런데 커밋 60번을 넘어가면서부터 다른 이야기가 시작된다. dev.to에 공개된 100+ 커밋 실전 후기는 이렇게 정리한다. "빌딩은 10배 빠르다. 유지보수와 디버깅은 0.5배로 느려진다—능동적으로 보완하지 않으면."
AI가 만드는 부채의 구조
문제의 핵심은 AI가 '전체 시스템'이 아니라 '당신이 묘사한 시나리오'에 최적화된 코드를 쓴다는 점이다. Supabase RLS 정책이 로컬 테스트를 완벽하게 통과하고도 프로덕션에서 터진 이유가 여기 있다. AI는 봇 러너가 어떻게 동작하는지 몰랐고, 그걸 물어보지도 않았다.
Vibe Coding은 또한 본질적으로 '추가(additive)' 방향으로 움직인다. 기능이 필요하면 붙이고, 버그가 나면 패치한다. 결과적으로 같은 Supabase 인증 체크가 세 가지 패턴으로 코드베이스에 흩어지고, API 라우트 80%가 거의 동일한데 한 번도 추상화되지 않은 상태가 된다. AI에게 "이거 정리해줘"라고 하면 보여준 파일 하나만 고친다. 나머지 네 개는 그대로다.
가장 뼈아픈 부분은 디버깅이다. 코드가 어떻게 동작하는지 모르는 상태에서 AI에게 증상을 설명하면, AI는 그럴듯한 수정안을 계속 내놓는다. 그 각각이 다른 무언가를 망가뜨리면서 1시간이 사라진다. 같은 후기에서 결론은 명확하다. "AI 없이 디버그할 수 없다면, 그 코드는 당신 것이 아니다."
도구마다 강점이 다르다—30일 실전 비교가 말해주는 것
그러면 어떤 도구를 써야 하나. 30일간 Claude Code, Cursor, GitHub Copilot을 실제 프로덕션 작업에 번갈아 사용한 백엔드 엔지니어의 비교 기록이 흥미로운 기준을 제시한다.
Claude Code는 터미널 기반으로 작동하며, 파일을 건드리기 전에 계획을 먼저 제안하는 습관이 있다. 600줄짜리 서비스 파일 분해 작업에서 모듈 경계와 공유 상태 처리 방안을 먼저 정리해준 뒤 작업에 들어갔고, 예상 1일 작업이 2시간으로 줄었다. 6주 동안 간헐적으로 터진 504 에러도 "태스크 큐 클라이언트 타임아웃 설정이 뭔가요?"라는 질문 두 개로 개발자 스스로 원인을 찾게 유도해 20분 만에 해결됐다. 백엔드 작업 평점 8.5/10. 단, 프론트엔드 시각적 반복 작업엔 6/10.
Cursor는 VS Code 포크답게 이미 IDE에서 살고 있는 팀에게 전환 비용이 거의 없다. 인라인 생성 속도와 코드베이스 인덱싱이 강점이다. 새 보고 API 엔드포인트 세트를 3일 예상에서 1일로 줄였고, 5년 된 Django 레거시 코드 탐색에도 "이 함수를 호출하는 곳이 어디야?" 수준의 질문이 통했다. 그린필드 9/10, 레거시 7/10. 단, 코드를 외부 API로 전송하는 구조상 민감한 비즈니스 로직이 있는 팀은 보안팀과 먼저 협의해야 한다.
결론적으로 도구 선택은 작업 유형과 팀 환경에 따라 달라진다. 깊은 백엔드 리팩토링과 복잡한 디버깅엔 Claude Code, IDE 통합과 그린필드 개발 속도엔 Cursor가 우위를 보였다.
어떤 도구를 써도 반드시 먼저 세팅해야 할 것
도구 선택보다 더 근본적인 문제가 있다. AI 에이전트에게는 메모리가 없다는 것. 매 세션이 백지에서 시작한다. 지난주에 내린 47가지 결정을 AI는 기억하지 못한다.
이를 해결하는 가장 실용적인 방법이 기계가 읽는 문서다. 앞서 소개한 Vibe Coding 실전 후기에서는 CLAUDE.md와 history.md 두 파일로 이 문제에 대응했다. CLAUDE.md는 "지금 프로젝트가 어떻게 돌아가는가"—스택 규칙, 아키텍처 결정, 배포 규칙, DB 마이그레이션 방법, 알려진 함정들. history.md는 "무엇을 왜 결정했는가"의 기록. 세션 시작 시 AI가 두 파일을 읽게 하자 모순된 제안이 눈에 띄게 줄었다고 한다.
여기서 한 걸음 더 나간 실천법이 있다. AI 아키텍트 Amit Raz가 공개한 /document-project 커맨드는 휴식을 취하러 자리를 뜰 때마다 에이전트가 전체 레포를 스캔해 AGENTS.md와 폴더별 README.md를 자동으로 갱신한다. 결과물은 빌드 커맨드, 기술 스택, 레이아웃 맵, "알려진 함정(known footguns)"으로 구성된 기계 지향 문서다. "Android 알람은 에뮬레이터 말고 실기기에서 테스트", "Hive 모델 변경 후에는 build_runner 실행" 같은 것들. 텍스트 벽이 아니라 에이전트가 빠르게 방향을 잡기 위한 최소한의 지도다.
세션마다 컨텍스트를 수동으로 재설명하는 시간을 없애는 것—이것이 AI 코딩 도구의 실질적인 생산성 레버다.
테크 리드가 지금 당장 해야 할 세 가지
이 세 가지 실전 경험을 종합하면 팀 도입 전에 먼저 자리를 잡아야 할 것들이 보인다.
첫째, 작업 유형별로 도구를 분리하라. 도구 하나로 모든 걸 해결하려고 하지 말고, 복잡한 리팩토링·디버깅과 그린필드 개발·IDE 통합을 분리해서 각 강점을 쓰는 체계를 만들어라.
둘째, 컨텍스트 문서를 코드와 함께 버저닝하라. AGENTS.md든 CLAUDE.md든 이름은 중요하지 않다. 중요한 것은 아키텍처 결정과 알려진 함정이 에이전트가 읽을 수 있는 형태로 레포에 존재해야 한다는 것. 이 파일을 최신 상태로 유지하는 것도 팀의 개발 프로세스 일부로 넣어야 한다.
셋째, AI가 짠 코드를 소유하는 구조를 만들어라. 빠르게 만들수록 나중에 본인이 이해하지 못하는 코드가 쌓인다. AI가 작성한 코드도 리뷰하고 이해하는 기준을 팀 내에 세워야 한다. 특히 초기 아키텍처 결정—AI는 "지금 동작하게" 최적화하지 "3개월 후에도 바꾸기 쉽게" 설계하지 않는다는 점을 팀 전체가 인식해야 한다.
도구는 빠르게 진화하고, 팀의 습관은 느리게 바뀐다
Claude Code, Cursor, Copilot 모두 올해 안에 컨텍스트 유지와 멀티파일 이해 능력이 더 좋아질 것이다. 하지만 도구가 진화해도 팀이 컨텍스트를 관리하는 습관과 AI 생성 코드를 검증하는 구조가 없으면 같은 문제는 반복된다.
AI 코딩 도구를 팀에 심는 것은 빠른 개발자를 채용하는 것과 다르다. 방향을 잡아주고, 시스템을 이해하고, 결정의 맥락을 기록하는 구조를 함께 설계하지 않으면—AI는 속도를 주는 동시에 부채를 쌓는 도구로만 작동한다. 속도는 그다음 문제다.