'AI 통합은 하루면 됐다. 나머지가 수 주 걸렸다.'
dev.to에 올라온 한 개발자의 고백이다. 그는 Flutter와 Supabase, OpenAI를 써서 AI 레시피 생성 앱 Simple Plate를 혼자 한 달 만에 출시했다. 핵심 API 호출 코드는 열 줄 남짓. 그런데 그게 전부였다면 일주일이면 끝났을 것이다. 실제로는 달랐다. Apple App Store 심사 8회 거절, 커스텀 SMTP 이메일 인증, Android 딥링크, RevenueCat 구독 설정, UTC 타임존 버그, 이미지 캐싱—이것들이 프로젝트 대부분의 시간을 잡아먹었다.
AI-First 팀이라면 이 경험을 단순한 개인 후기로 흘려보내면 안 된다. 여기엔 구조적 함의가 있다. AI 통합 자체는 빠르게 상품화됐다. GPT-4o-mini 호출, 스트리밍 응답, 프롬프트 체이닝—이 레이어의 난이도는 이미 낮아졌다. 문제는 그 이후다. 인증, 결제, 플랫폼 정책, 타임존 처리, 캐싱 전략—이것들은 AI가 대신해주지 않는다. 그리고 이 구간이 전체 배포 일정을 지배한다.
두 번째 시사점은 프롬프트 엔지니어링의 위치다. 이 개발자는 '프롬프트가 제품의 80%'라고 단언했다. 초기엔 막연한 결과물이 나왔고, 식단 제한을 추가하자 반복이 줄었으며, 최근 레시피 히스토리를 컨텍스트로 넣자 비로소 쓸 만한 수준이 됐다. 그는 UI를 먼저 다듬느라 프롬프트 설계를 늦게 시작한 것을 후회했다. AI-First 팀이라면 이 순서가 거꾸로 가는 경우가 많다. 'AI가 붙으면 좋아질 것'이라는 기대로 외형 설계부터 하다가, 실제 출력 품질이 기대에 못 미친다는 걸 나중에 발견한다.
velog의 AI 뉴스 자동화 수집 사례는 다른 각도에서 같은 문제를 보여준다. 6월 6일 자 AI 도구 업데이트 브리핑은 OpenAI, Anthropic, GitHub, Google의 공식 채널을 소스로 삼았지만, 실제로 '어떤 엔드포인트가 바뀌었는가', '마이그레이션 데드라인이 언제인가', '어느 플랜에 적용되는가' 같은 구체적 정보는 하나도 담지 못했다. 소스는 공식이었지만 내용은 비어 있었다. 자동화가 수집은 했지만 검증은 못 한 것이다. 팀이 이 브리핑을 그대로 믿고 런북이나 비용 추정을 수정했다면 잘못된 행동이 됐을 것이다.
두 사례는 같은 패턴을 공유한다. AI가 처리하는 부분—API 호출, 뉴스 수집, 콘텐츠 생성—은 빠르고 눈에 띈다. 반면 그 결과물이 실제로 '쓸 수 있는 상태'가 되기까지 필요한 비AI 구간—플랫폼 심사, 인증 설정, 출력 검증, 품질 게이트—은 느리고 눈에 잘 안 띈다. 팀이 속도를 착각하는 지점이 바로 여기다. AI 통합이 빠르게 완료됐으니 전체가 빠른 것처럼 보이지만, 실제 병목은 그 다음 구간에 있다.
AI-First 팀 빌딩 관점에서 이 문제는 설계 우선순위의 문제다. 지금 대부분의 팀은 'AI를 어떻게 붙일까'에 집중한다. 어떤 모델을 쓸지, 프롬프트를 어떻게 짤지, 응답을 어떻게 파싱할지. 그러나 실제 배포 일정을 지배하는 건 '그 다음 구간을 누가, 언제, 어떻게 처리할 것인가'다. 플랫폼 정책 검토 담당자가 있는가. 인증 플로우 설계를 언제 시작할 것인가. AI 생성 출력의 품질 게이트를 누가 운영할 것인가. 이것들이 설계 단계에서 명시되지 않으면, 개발 막판에 몰아서 처리하거나 출시 후 버그로 터진다.
프롬프트 설계도 마찬가지다. 팀이 AI를 도입할 때 프롬프트를 '나중에 다듬으면 되는 것'으로 취급하면, 나중에 아키텍처를 뜯어야 하는 상황이 온다. 출력 구조가 변하면 파싱 로직이 바뀌고, 파싱 로직이 바뀌면 연결된 모든 컴포넌트가 영향을 받는다. Simple Plate 개발자가 후회한 것처럼, 프롬프트는 UI보다 먼저 안정화해야 할 핵심 설계 자산이다.
앞으로 AI-First 팀에서 'AI 통합 완료'는 스프린트 완료가 아니라 시작 조건에 가까워질 것이다. 모델 호출이 쉬워질수록, 그 앞뒤의 비AI 인프라와 검증 설계가 팀 역량의 실제 차별점이 된다. 당장 내일 팀 스프린트 계획을 짠다면 물어볼 질문은 하나다. 'AI 연동 이후 어떤 비AI 병목이 배포를 막을 것인가'—그리고 그 답을 로드맵에 먼저 넣어야 한다.