'AI 도입했더니 생산성이 두 배 됐다'는 이야기는 넘쳐난다. 반면 'AI 도입했더니 예산이 두 배 됐다'는 이야기는 조용히 묻힌다. Microsoft가 수천 명 엔지니어의 Claude Code 라이선스를 Copilot으로 전환하고, Uber CTO가 2026년 AI 예산을 몇 달 만에 소진했다고 공개 선언한 것은 그 묻힌 이야기가 수면 위로 올라온 사건이다. 두 회사 모두 AI에 가장 공격적으로 투자하는 곳이다. 그들이 먼저 벽에 부딪혔다면, 우리 팀이 그 벽을 만나지 않을 것이라는 보장은 없다.
문제는 도구가 나쁜 게 아니다. Claude Code도, Cursor도, Copilot도 각자의 영역에서 실제로 잘 작동한다. 문제는 도구를 쓰기 전에 팀이 설계해야 할 것들을 건너뛰었다는 데 있다. 속도에 매혹되면 설계가 후순위가 된다. 그리고 그 순서가 뒤집히는 순간 AI는 팀을 돕는 도구가 아니라 팀의 복잡도를 빠르게 쌓아 올리는 기계가 된다. 내가 지금 '세 가지를 먼저 설계하라'고 말하는 이유다.
첫 번째: 워크플로우 구조
dev.to에 공개된 한 실전 사례가 흥미롭다. 저자는 12단계 AI 워크플로우로 2,500개 이상의 커밋을 출하했다. 숫자보다 중요한 건 그 구조다. 모든 작업은 CLARIFY → DESIGN → REVIEW → PLAN → BUILD → VERIFY → REVIEW → QC → POST-REVIEW → SESSION → COMMIT → RETRO 순서로 진행된다. 코드를 한 줄 쓰기 전에 스펙을 먼저 쓰고, 그 스펙을 인간이 승인하고, AI는 승인된 스펙 안에서만 코드를 생성한다.
이 구조에서 핵심은 '단계를 다 밟는 것'이 아니라 '스킵 패턴을 명시적으로 위반으로 정의하는 것'이다. AI 에이전트가 '이건 작은 변경이니 PLAN 없이 바로 BUILD'라고 판단하는 순간, 그건 효율이 아니라 체크포인트 붕괴다. 작업 크기를 사전에 분류하고(XS/S/M/L/XL), 크기에 따라 허용되는 스킵을 명시하고, 그 외의 스킵을 팀 차원에서 금지하는 것—이게 워크플로우 구조 설계의 실체다.
팀 리드 입장에서 이 구조가 중요한 이유는 하나다. AI가 생성한 diff를 리뷰할 때, 그 diff를 코드 대 코드로 비교하면 의미가 없다. 코드 대 요구사항으로 비교해야 한다. 요구사항이 사전에 문서화되어 있지 않으면 diff 리뷰는 형식적인 절차가 된다. 12단계 워크플로우가 강제하는 건 바로 이 '의도의 문서화'다.
두 번째: 컨텍스트 규칙
.cursorrules 파일을 최적화하는 것은 프롬프트 엔지니어링 취미 활동이 아니다. 이건 팀의 코딩 컨벤션을 AI에게 한 번만 설명하고 영구적으로 적용하는 구조 설계다. 10개 스택의 rules 파일을 직접 만들어본 한 개발자의 분석에 따르면, 나쁜 rules 파일과 좋은 rules 파일의 차이는 단 하나다: 프로젝트 특수성.
'클린 코드를 써라', '베스트 프랙티스를 따라라' 같은 규칙은 AI가 이미 알고 있는 것들이다. 아무 신호도 추가하지 못한다. 반면 'Next.js 14 App Router를 쓴다. use client는 이벤트 핸들러가 필요할 때만 붙인다. getServerSideProps는 Pages Router 패턴이므로 쓰지 않는다'는 규칙은 AI가 모를 수 있는 프로젝트 특수 정보다. 특히 버전 특이성이 중요하다. AI 모델의 학습 데이터에서 가장 많이 등장하는 패턴이 가장 오래된 패턴인 경우가 많기 때문에, 명시적으로 버전과 금지 패턴을 지정하지 않으면 Pydantic v1 문법이나 Pages Router 패턴이 자동으로 생성된다.
rules 파일은 500줄짜리 철학서가 되어서는 안 된다. 모든 것이 강조되면 아무것도 강조되지 않는다. 팀이 반복적으로 교정하는 실수, AI가 자주 틀리는 패턴, 프로젝트의 비자명적 구조—이 세 가지에만 집중하면 된다. 이걸 설계하지 않으면 팀원마다 AI에게 같은 설명을 반복하고, 그 반복 비용이 조용히 쌓인다.
세 번째: 비용 모델 인식
Microsoft와 Uber의 사례가 보여주는 것은 단순한 '비용 초과'가 아니다. 현재 AI 코딩 도구들의 비즈니스 모델 자체가 사용자의 이익과 구조적으로 충돌한다는 점이다. 토큰 기반 과금 모델에서 벤더의 수익은 사용자가 더 많은 토큰을 쓸수록 증가한다. 더 긴 세션, 더 넓은 컨텍스트 윈도우, 더 많은 도구 호출—모두 벤더에게 좋고 사용자 청구서에 나쁜 것들이다.
dev.to의 비용 구조 분석이 지적하는 핵심은 이것이다: 컨텍스트 윈도우를 키우는 것은 메모리가 아니라 '신용카드가 붙은 건망증'이다. AI가 매 세션마다 코드베이스 전체를 다시 읽는 구조는 실제 기억이 아니다. 진짜 메모리는 세션 간에 지속되고, 관련 정보만 선택적으로 불러오고, 토큰 비용을 줄이면서 품질을 높인다. 하지만 이 구조는 벤더의 수익과 역행하기 때문에 시장에서 만들어지지 않고 있다.
팀 레벨에서 이것이 의미하는 바는 실용적이다. 지금 쓰는 AI 도구가 '파킹 미터'인지 '파트너'인지를 구분해야 한다. 내가 더 많이 쓸수록 벤더가 더 버는 구조라면, 팀의 생산성 증가가 곧 비용 증가라는 뜻이다. 이 구조에서 벗어나려면 세션 범위를 제한하고, 불필요한 컨텍스트 로드를 줄이고, 작업 단위를 작게 유지하는 워크플로우 설계가 비용 관리의 핵심이 된다. 도구 선택 이전에 이 경제적 구조를 이해하지 못하면, 생산성 향상과 비용 폭발이 동시에 일어나는 상황을 피하기 어렵다.
세 가지가 연결되는 방식
이 세 가지—워크플로우 구조, 컨텍스트 규칙, 비용 모델 인식—는 독립적인 설계 항목이 아니다. 워크플로우 구조가 작업 단위를 작게 유지하면 토큰 비용이 자연스럽게 줄어든다. 컨텍스트 규칙이 잘 설계되어 있으면 AI가 프로젝트 맥락을 재확인하는 반복적인 토큰 소비가 줄어든다. 비용 모델을 이해하면 워크플로우와 컨텍스트 설계의 우선순위가 명확해진다.
속도를 먼저 추구하는 팀은 이 세 가지를 나중에 고친다. 그리고 나중에 고치는 비용은 처음에 설계하는 비용보다 항상 크다. Microsoft와 Uber가 그걸 증명했다. AI-First 팀이 실제로 돌아가려면, 첫 번째 커밋 전에 워크플로우를 설계하고, 첫 번째 세션 전에 컨텍스트 규칙을 문서화하고, 첫 번째 청구서 전에 비용 구조를 이해해야 한다. 이 순서가 바뀌면 AI는 팀을 구하는 도구가 아니라 팀을 빠르게 망가뜨리는 도구가 된다.