2개월, 1명의 엔지니어, 프로덕션 B2B 마켓플레이스. dev.to에 올라온 wentmarket.ru 구축 사례를 처음 봤을 때 반응은 솔직히 회의였다. '2개월 만에 혼자 만든 게 자랑이 아니라 레드플래그 아닌가?' 그런데 들여다볼수록 생각이 바뀌었다. 이건 과장 사례가 아니라, AI-First 워크플로우에서 역할 분담이 어떻게 작동하는지를 가장 구체적으로 보여주는 실증 데이터다.
수치부터 짚자. 584개 제품, 2,308개 변형 옵션, 7개 외부 시스템 연동(1C ERP, Bitrix24 CRM, 결제, 배송, 검색, 텔레그램 봇, DaData), 17개 엔지니어링 계산 엔진, 101개 Prisma 모델, 446개 테스트 파일. 이게 MVP가 아니라 실제 유료 고객이 사용하는 프로덕션이다. 저자가 체감한 생산성 향상은 '4인 팀 수준의 아웃풋'—약 3~4배다.
그런데 이 수치보다 중요한 건 어떻게 일을 쪼갰냐다. 저자가 담당한 것: 도메인 모델 설계, 데이터베이스 스키마, 연동 아키텍처, 성능 예산, 엣지 케이스 판단, 프로덕션 QA, 매출·데이터 무결성에 영향을 미치는 모든 결정. Claude Code가 담당한 것: CRUD 핸들러, 첫 번째 초안 테스트, 보일러플레이트 React 컴포넌트, 이메일 템플릿, 명확한 형태가 있는 리팩터링. 이 구분이 전부다. AI가 '작동하는 코드'를 쓰는 건 이미 가능하다. 문제는 언제나 'AI가 올바른 문제에 대한 코드를 쓰고 있냐'이고, 그 판단은 인간 몫으로 남는다.
이 역할 분담 구조는 CS 비전공자가 프로덕션 시스템을 혼자 운영하는 사례에서도 동일하게 확인된다. AI-Assisted Development 사례의 저자는 15년 경력의 전략/운영 임원 출신으로, 코딩 교육을 받지 않고 AI 도구만으로 WhatsApp·Telegram 멀티에이전트 시스템을 프로덕션에 올렸다. 그가 내린 결론이 흥미롭다. "나는 구현의 60%를 시스템 설계에 쓴다. 30%가 구현, 10%가 디버깅. 전통적인 개발이 20/60/20이라면, AI-First는 60/30/10이다." 코딩 시간이 줄어든 게 아니라, 설계 시간이 절대적으로 늘어난 구조다.
두 사례에서 공통적으로 나타나는 AI의 실패 패턴도 명확하다. 첫째, 컨텍스트 없는 생성. '좋은 코드'를 쓰지만 '우리 시스템에 맞는 코드'는 아니다. wentmarket 사례에서 HVAC 엔지니어링 테스트의 레퍼런스 데이터(팬 선택 기준치, ASHRAE 공차 범위)는 저자가 직접 디지털화해야 했다. AI가 테스트 스캐폴딩은 썼지만, 기준값 자체는 도메인 전문가만 판단할 수 있다. 둘째, 인프라 특이성. Oracle Cloud 사례에서 AI는 AWS 패턴을 Oracle API에 섞어 즉시 실패하는 코드를 생성했다. Redis pub/sub이 512KB 이상 페이로드에서 묵묵히 메시지를 드롭하는 문제도 AI가 아니라 실제 트래픽 로깅으로 발견됐다. AI는 일반적인 패턴에 강하고 특수한 실패 모드에 약하다.
그렇다면 프롬프트 전략은? Bolt·Lovable·Cursor를 위한 프롬프트 작성 가이드는 이 맥락에서 운영 매뉴얼로 읽힌다. 핵심은 단순하다. AI에게 빈칸을 남기지 말 것. 빈칸은 AI가 결정을 내리는 공간이고, AI의 결정은 당신의 시스템이 아니라 통계적 평균을 향한다. 스택과 버전 명시, 목표를 하나의 구체적 변경으로 좁히기, 데이터 형태와 엣지 케이스 제약 포함, 완료 기준 명시—이 네 가지가 '되는 프롬프트'와 '안 되는 프롬프트'를 가른다. wentmarket 저자가 "스펙을 명확하게 쓰는 규율에 대한 대가로 3배의 처리량을 얻는다"고 표현한 것과 정확히 같은 원리다.
이 세 사례를 붙여보면 AI-First 팀 리빌딩의 실질적 함의가 드러난다. AI가 코딩을 담당하면 팀에서 '코딩하는 사람'이 줄어드는 게 아니라, '설계하고 판단하는 사람'이 더 중요해진다. 지금 당장 위임할 수 없는 것들—도메인 모델 결정, 연동 계약 설계, 에러 처리 철학(빠른 실패 vs. 우아한 강등), 무엇을 만들지 않을 결정—은 전부 아키텍처 판단이다. 코드를 빠르게 쓰는 능력이 아니라, 시스템을 읽고 트레이드오프를 판단하는 능력이 AI-First 팀의 핵심 희소 자원이 된다.
팀 리빌딩 관점에서 실천적으로 짚을 것이 있다. AI-First 온보딩에서 '도구 사용법'보다 먼저 가르쳐야 할 건 'AI에게 무엇을 위임하고 무엇을 쥐어야 하는지의 판단 기준'이다. 도구는 익히는 데 며칠이면 된다. 하지만 '이 결정은 내가 내려야 한다'는 감각은 실제 프로젝트에서 실패를 몇 번 겪어봐야 생긴다. wentmarket의 AHU 컨피규레이터 UX가 대표적이다. 드래그앤드롭 캔버스로 처음 만들었다가 HVAC 엔지니어 3명에게 보여줬더니 30초 만에 이탈. 6주 작업을 버리고 재설계했다. AI는 이 판단을 대신할 수 없다. 유저와 도메인을 아는 사람만 할 수 있다.
3배 빠른 시대는 이미 와 있다. 문제는 그 속도를 쓸 수 있는 팀 구조가 아직 대부분 없다는 점이다. AI-First 리빌딩의 실체는 'AI 도구를 도입하는 것'이 아니라, 설계 판단을 담당할 사람을 식별하고, 그 판단을 빠르게 AI에게 전달하는 워크플로우를 팀 전체에 심는 것이다. 1인 팀이 4인 팀 속도를 낼 수 있다면, 4인 팀은 얼마의 속도를 낼 수 있을까. 그 계산을 지금 해봐야 할 때다.