AI 코딩의 역설: 빠를수록 더 많이 돌아온다
'AI로 코딩하면 빠르다'는 말에 토를 다는 사람은 드물다. 그런데 빠르다는 게 정확히 무슨 의미인지 물어보면 답이 흐려진다. 타이핑이 빠른 건지, 피처 완성이 빠른 건지, 아니면 그냥 뭔가 하고 있다는 느낌이 빠른 건지.
Cursor Labs가 실제 프롬프트 체인을 추적한 내부 연구(Yeager 2024)는 이 질문에 꽤 선명한 답을 내놓는다. 실패하는 테스트를 먼저 작성한 뒤 AI에게 프롬프트를 넣는 개발자는 그렇지 않은 개발자보다 37% 적은 반복으로 피처를 완성한다. 피처 복잡도와 무관하게 이 격차는 유지됐다.
왜 테스트가 먼저여야 하는가—'컴파일된 스펙'의 논리
이 숫자가 왜 나오는지는 구조적으로 설명된다. AI 모델에게 산문으로 기능을 설명하면 모델은 검색 공간이 열려 있다. 에지 케이스가 뭔지, 응답 포맷이 어떠해야 하는지, 어디까지가 범위인지—모델이 추정해야 한다. 그 추정이 어긋날 때마다 수정 프롬프트가 하나씩 추가된다.
반면 실패하는 테스트를 먼저 건네면 모델에게 컴파일된 스펙을 주는 것과 같다. 정확한 계약, 엣지 케이스, 어설션 형태가 이미 코드로 명시돼 있다. 모델이 투기적 추상화로 흘러갈 여지가 없다. 실제 사례로, middleware/rateLimit.ts의 checkRateLimit 함수를 구현할 때 버스트 허용, 윈도우 리셋, 429 헤더 세 케이스를 Jest로 먼저 짠 뒤 Cursor에 넘겼더니 첫 번째 컴플리션이 세 테스트를 모두 통과했다. 같은 기능을 산문으로 설명했을 때는 오프-바이-원 오류와 헤더 누락을 수정하는 데만 다섯 번의 반복이 필요했다.
패턴은 단순하다. test-first, prompt-second.
속도의 이면: MIT 연구가 포착한 인지 비용
그런데 여기서 멈추지 않고 한 발 더 들어가야 한다. 37% 효율 향상은 반가운 숫자지만, AI 코딩에는 생산성 계기판에 잡히지 않는 비용이 있다.
2025년 6월 MIT Media Lab의 Nataliya Kosmyna 팀은 54명에게 EEG 장비를 달고 에세이를 쓰게 했다. ChatGPT를 사용한 그룹의 83%는 방금 완성한 에세이에서 문장 하나도 인용하지 못했다. 반면 도구 없이 작성한 그룹의 실패율은 11%였다. 뇌파 데이터는 행동 결과와 일치했다. ChatGPT 그룹은 내부 집중과 관련된 알파·베타 파대에서 신경 연결 강도가 가장 낮았다.
이건 에세이만의 문제가 아니다. 개발자가 AI가 생성한 코드를 리뷰하고 y를 누르는 순간, 코드는 눈을 통해 들어와 승인 결정으로 빠져나간다. 손이 타이핑하지 않았으니 운동 기억(motor memory)도 남지 않는다. 인지과학에서 '생성 효과(generation effect)'라고 부르는 것—직접 만들 때 더 강하게 인코딩된다는 원리—이 AI 코딩에서는 작동하지 않는다.
두 도구, 다른 역할—JetBrains AI vs. Copilot 실전 분류
이 맥락에서 .NET 9 레거시 마이그레이션 현장에서 JetBrains AI Assistant(Claude Sonnet 4.6)와 GitHub Copilot을 Rider에서 병행 사용한 비교 경험은 실용적 시사점을 제공한다.
초기 실수는 두 도구를 호환 가능한 '전지전능한 오라클'로 취급한 것이었다. AuditLogService를 추가해달라고 했더니 DI 설정, appsettings.json 컨벤션, ILogger 패턴을 전혀 모르는 껍데기 클래스가 나왔다. Copilot은 _dbContext가 주입되기 전에 사용하는 코드를 제안해 NullReferenceException을 만들어냈다.
시행착오 끝에 정착한 분업 구조는 이렇다. Copilot은 좁고 빠른 작업—인라인 컴플리션, 보일러플레이트, 단일 메서드 단위 리팩터링—에 쓴다. 컨텍스트가 현재 파일 내에 있을 때 효율이 높다. JetBrains AI Assistant는 넓고 깊은 작업—레거시 클래스 전체를 채팅에 붙여넣고 CQRS 패턴 전환 전략을 묻는 식의 멀티턴 대화—에 쓴다. 프롬프트에 더 많은 노력이 들지만 복잡한 문제에서 산출물 품질이 확연히 다르다.
이 분류는 결국 TDD-First 접근과 같은 원리로 귀결된다. 컨텍스트를 명시적으로 설계하지 않으면 AI는 추정으로 채운다.
팀에 당장 적용 가능한 세 가지 원칙
세 가지 연구와 실전 사례를 종합하면 AI-First 워크플로우에서 팀 단위로 적용할 수 있는 원칙이 보인다.
1. 테스트를 스펙으로 먼저 작성한다. 다음 피처를 시작할 때 feature.spec.ts 하나를 만들고 의도적으로 실패하는 어설션부터 쓴다. 그런 다음 AI에게 넘긴다. 37% 반복 감소는 이 순서 하나에서 나온다.
2. AI 산출물을 손으로 한 번 통과시킨다. MIT와 Shen·Tamkin(2026) 연구 모두 같은 방향을 가리킨다. AI 그룹이 작업을 더 빨리 끝내더라도 이해도는 17% 낮았다. 학습을 보존한 패턴은 단순했다—AI 산출물을 수동적으로 받지 않고 적극적으로 개입하는 것. 코드를 받자마자 y를 누르는 루프가 쌓이면 디버깅 세션에서 자기 코드를 처음 보는 사람처럼 읽게 된다.
3. 도구별 컨텍스트 범위를 명시적으로 설계한다. JetBrains AI vs. Copilot 사례처럼, 도구의 강점은 컨텍스트 범위에 따라 갈린다. 팀 온보딩 문서에 '어떤 도구를 어떤 상황에 쓴다'는 분류를 명시하지 않으면 각자 다른 방식으로 AI와 싸우게 된다.
전망: '순서 설계'가 AI-First 팀의 핵심 역량이 된다
AI 코딩 도구의 경쟁은 모델 성능 차이가 좁혀지면서 점점 '어떻게 쓰느냐'의 싸움이 되고 있다. 프롬프트를 잘 쓰는 것도 중요하지만, 그 이전에 무엇을 먼저 준비하느냐—순서를 설계하는 역량이 팀의 생산성을 가르는 변수가 될 것이다.
TDD-First 접근은 그 순서 설계의 가장 검증된 형태다. 이걸 팀 전체의 디폴트 워크플로우로 정착시키는 게 단기적으로 투자할 수 있는 가장 ROI 높은 AI-First 온보딩이다. 내일 당장 팀원 한 명에게 '다음 피처 시작 전에 테스트 파일 하나만 먼저 만들어봐'라고 시켜볼 수 있다. 그게 시작이다.