'AI로 코드를 짤 수 있다'는 사실은 이제 증명이 필요 없다. 진짜 질문은 다음 단계에 있다. AI가 구현을 전담할 때, 인간은 정확히 무엇을 해야 하는가. 그리고 그 구조를 설계하지 않으면 어떤 비용이 청구되는가.
최근 세 개의 실전 사례가 이 질문에 정면으로 답한다. 각각 규모도 맥락도 다르지만, 가리키는 방향은 놀랍도록 일치한다.
3,662턴이 남긴 진짜 교훈
Noor Azeez는 32일 만에 Claude만으로 멀티테넌트 SaaS를 구축했다. AWS EC2·RDS·S3, JWT 인증, Stripe 빌링, SSE 스트리밍까지—코드 한 줄 직접 작성하지 않고 실제 유료 고객을 확보했다. $500 툴링 비용으로 $67/월 단가의 B2B 서비스를 만든 것이다.
숫자만 보면 AI-First의 성공 사례다. 그런데 그가 논문으로 정리한 핵심 발견은 정반대 지점에 있다. 3,662번의 모델 턴을 거치며 반복적으로 나타난 실패 패턴 네 가지다.
- Configuration Blindness: 모델은 자신이 볼 수 없는 환경에 맞춰 코드를 쓰고, 현실에서 점점 이탈한다
- Fragmentation: 세션마다 로컬 최적화를 반복하다 전체 구조가 뒤틀린다
- Accumulation without Consolidation: 코드는 쌓이지만 리팩터는 운영자가 강제하지 않으면 일어나지 않는다
- Scope Creep: 모델은 언급된 모든 것을 기꺼이 만들어낸다—만들지 말아야 할 것까지
그의 결론은 냉정하다. "이 네 가지는 더 나은 프롬프트로 해결되지 않는다. 아키텍처 판단, 불변 조건 설정, 거절할 줄 아는 능력, '완료'의 정의—이것이 전부 엔지니어링 역량이었고, 그것이 내 유일한 역할이었다."
컨텍스트를 잡지 않으면 에이전트는 표류한다
Fragmentation과 Accumulation 문제는 사실 워크플로우 설계로 상당 부분 통제할 수 있다. Copilot-cli를 실전에서 운용하는 한 개발자는 이를 세 레이어 구조로 해결했다.
첫 번째는 RFC 선행 작성이다. rfc-cli로 아키텍처·목표·변경 범위를 문서화하고 draft → review → accepted → implemented 상태 머신을 강제한다. 에이전트가 코드를 쓰기 전에 이미 '무엇을 왜 만드는지'가 레포 안에 고정되어 있다. 모델이 요청 앞에만 최적화하는 Fragmentation을 구조적으로 차단하는 방식이다.
두 번째는 세션 간 메모리 유지다. mem-cli를 MCP 서버로 연결해 "포트 8080 고정