허니문이 끝난 뒤가 진짜 테스트다
AI 코딩 어시스턴트를 처음 쓸 때의 흥분은 누구나 안다. 프롬프트 한 줄에 기능이 튀어나오고, 'AI가 개발을 바꿨다'는 확신이 온다. 문제는 2주차다. dev.to에 올라온 두 편의 장기 실사용 리뷰—2주 집중 비교와 3개월 사용기—는 공통적으로 같은 지점을 짚는다. 허니문이 끝나면 진짜 생산성 지표가 드러난다. 임포트가 이유 없이 바뀌고, 건드리지 않은 파일이 수정되고, 버그 하나 잡으려다 14개 파일이 리팩토링된다. 이 시점에서 중요한 건 코드 생성 속도가 아니라 얼마나 빠르게 나쁜 코드를 걸러내는가다.
세 도구, 세 가지 다른 실패 모드
세 도구를 실제 프로덕션 프로젝트에 써본 결과는 흥미롭게도 각각 다른 방향으로 무너진다.
Cursor는 가장 안전한 데일리 드라이버다. diff 리뷰 UX가 탁월하고, 잘못된 코드를 거부하는 속도가 빠르다. 설정 페이지, API, 대시보드 같은 일반적인 피처 개발에서는 안정적이다. 단, 레포가 커지면 '컨텍스트 터널 비전'이 생긴다. 최근에 열어본 파일의 패턴을 맥락과 무관하게 과잉 적용하기 시작하고, .cursorrules 없이는 AI가 스스로 아키텍처 결정을 내리기 시작한다.
Windsurf는 대규모 리팩토링에서 예상을 넘는 능력을 보여준다. API 마이그레이션에서 관련 타입·참조·의존성을 자동으로 처리하는 장면은 진짜 협업처럼 느껴진다. 문제는 '너무 도우려는' 성향이다. 작은 린트 이슈를 잡으러 들어갔다가 연쇄적으로 파일을 수정하며 아키텍처 방향을 잃어버리는 루프에 빠진다. 코딩 피로가 아닌 AI 사고 읽기 피로가 온다.
Claude Code는 범주 자체가 다르다. IDE 도구가 아니라 자율 터미널 에이전트에 가깝다. Docker 디버깅, Terraform, CI/CD, 셸 스크립트에서는 탁월하다. 반면 프론트엔드 작업은 시각적 피드백 부재로 고통스럽다. 'AI에게 루트 권한을 주고 좋은 결정을 내리길 기다리는' 경험이라는 표현이 정확하다.
진짜 생산성 지표는 '청소 시간'이다
두 리뷰가 공통으로 강조하는 핵심이 있다. 생성에 20초 걸려도 수정에 2시간 들면 의미없다. 기존 비교 기사들이 '어느 모델이 더 스마트한가', '벤치마크 점수가 얼마인가'에 집중하는 동안, 실제 사용자들은 다른 지표로 수렴한다—AI가 생성 이후에 만들어내는 클린업 작업량이 얼마인가.
이건 팀 리드에게 직접적인 시사점이다. 도구 도입 ROI를 측정할 때 'PR 수'나 '코드 라인'보다 리뷰어가 AI 결과물을 검토하는 데 쓰는 시간을 먼저 봐야 한다. 내가 '리뷰 딥스(review depth)'라고 부르는 지표인데, AI 도구가 좋을수록 이 숫자가 낮아진다.
그리고 여기서 '컨텍스트 부채'라는 개념이 등장한다. AI 도구는 기술 부채를 제거하지 않는다. 증폭한다. 이름 규칙이 불일치하고, 아키텍처 경계가 흐릿하고, 폴더 구조가 중구난방인 레포에서 AI는 그 혼돈을 즉각 흡수해버린다. 데모 프로젝트에서 마법처럼 느껴지고 오래된 프로덕션 시스템에서 덜 마법 같은 이유가 여기 있다.
AI-First 워크플로우에서 언어 선택 기준이 바뀐다
도구 선택 문제는 여기서 한 층 더 깊어진다. geeknews에 소개된 분석이 제기하는 질문이 있다: "AI가 코드를 쓴다면, 왜 Python을 쓰는가?"
기존 언어 선택 기준은 '사람이 빠르게 작성할 수 있는가'였다. Python과 TypeScript가 기본값이 된 이유다. Rust, Go, C++는 성능을 10~100배 줄 수 있었지만 학습 비용, 좁은 인재 시장, 복잡한 빌드 시스템이 발목을 잡았다.
AI 에이전트가 이 계산을 바꾸고 있다. Rust의 컴파일러 오류 메시지는 AI 모델의 실시간 자기수정을 돕는 피드백 신호가 된다. AI가 Rust를 C++보다 더 잘 쓰는 이유가 메모리 안전성이나 성능이 아니라 '컴파일러 피드백 루프'에 있다는 분석이 설득력 있다. 이미 실제 사례들이 나오고 있다—Anthropic 연구자가 16개의 Claude 에이전트를 병렬 조율해 Rust로 C 컴파일러(10만 줄, $20,000 미만)를 만들었고, Ladybird의 JavaScript 엔진이 C++에서 Rust로 2주 만에 포팅됐다. 손으로 했다면 수개월 걸렸을 작업이다.
팀 리드 입장에서 이 흐름이 중요한 이유는 명확하다. 기술 스택 선택 회의에서 '팀이 이 언어를 얼마나 빨리 쓸 수 있는가'보다 '에이전트가 이 언어로 만든 결과물을 우리 팀이 얼마나 빠르게 검증할 수 있는가'를 물어야 하는 시점이 오고 있다.
팀 리드의 실용적 판단 기준
두 리뷰를 종합하면 실제 워크플로우 배치 전략이 나온다.
- Cursor → 데일리 피처 개발: 낮은 러닝 커브, 탁월한 diff UX, 빠른 거부 판단.
.cursorrules는 필수. - Windsurf → 대규모 리팩토링·마이그레이션: 멀티파일 컨텍스트 능력을 쓰되, 루프에 빠지는 타이밍을 팀이 인지해야 한다.
- Claude Code → 인프라·터미널 디버깅: DevOps 작업에 특화. 프론트엔드 팀에 강제 배포하면 역효과.
도구별 배치보다 더 중요한 건 팀 온보딩 기준을 재정의하는 것이다. AI 도구 도입 초기에 물어야 할 질문은 '이 도구가 얼마나 좋은 코드를 만드는가'가 아니다. '이 도구가 잘못된 방향으로 갈 때 우리 팀이 얼마나 빨리 알아채는가'다. AI가 생성한 코드를 읽고 무엇이 빠졌는지, 어떤 실패 모드를 고려 안 했는지 파악하는 능력—리뷰 역량이 팀의 핵심 스킬이 되고 있다.
다음 18개월, 팀 리드가 준비해야 할 것
3개월 사용기 저자의 관찰이 인상 깊다. IDE 개발 워크플로우의 본질이 '내가 주 저자, 도구는 수동 보조'에서 '에이전트가 1차 초안, 나는 검토자'로 이미 이동했다는 것. 이게 특정 작업 유형에서는 돌이킬 수 없는 전환이다.
앞으로 주목할 신호는 두 가지다. 첫째, 언어 생태계가 'Rust 기반 래퍼 의존'에서 'Rust 직접 작성'으로 이동하는 속도다. Python 검증 코어 pydantic이 이미 Rust 라이브러리이고, pandas 대안 Polars가 Rust다. 에이전트가 이 작업을 맡기 시작하면 '우리 팀이 이 언어를 모른다'는 장벽의 무게가 달라진다. 둘째, 팀에서 'AI 결과물 검토 역량'을 어떻게 측정하고 성장시키는가다. 코드를 빠르게 치는 사람보다 AI가 놓친 아키텍처 결함을 빠르게 포착하는 사람이 더 희귀하고 더 가치 있어지는 국면이 오고 있다.
도구 선택은 결국 팀이 어디서 시간을 아끼고 어디서 판단을 유지할지의 설계 문제다. 그리고 그 설계는 AI가 아직 못 하는 일이다.