일본의 솔로 iOS 개발자 Kei는 앱 20개, 언어 최대 35개 조합으로 필요한 App Store 프리뷰 영상을 손으로 만들다가 포기했다. 계산해보니 영상 하나당 최소 한 시간, 총 수백 시간이 필요한 작업이었다. 그래서 그는 영상을 만드는 대신 영상을 만드는 공장을 만들기로 했다. Claude Code와 페어링해 Remotion 기반의 렌더 파이프라인과 Python 업로드 스크립트를 구축했고, 공장은 465개의 영상을 찍어냈다. 그리고 Apple은 전부 리젝했다.
리젝 사유는 Guideline 2.3.4. 앱 프리뷰 영상에 기기 프레임(device frame)을 넣으면 안 된다는 규칙이었다. 아이러니하게도 Kei가 가장 공들인 부분—폰 베젤 안에 앱 화면을 담은 세련된 목업—이 바로 위반 요소였다. 더 뼈아픈 건 스크린샷에서는 기기 프레임이 권장되기까지 한다는 사실이다. 수년간 '기기 프레임 = 전문적인 결과물'로 굳어진 습관이 영상이라는 다른 맥락에서 그대로 오작동했다. 두 번째 앱에서도 같은 실수를 반복해, 이미 업로드된 39개 영상을 전부 내리고 다시 제출해야 했다.
수정은 간단해 보였다. 폰 프레임을 제거하고 스크린샷을 전체 화면으로 채우면 됐다. 하지만 디테일은 잔인했다. 원본 스크린샷과 영상 캔버스의 종횡비가 0.26% 어긋나 상하 2.5픽셀씩 잘려나갔고, 전체 화면으로 확장하자 시각 정보가 늘어나면서 Apple의 비트레이트 상한을 언어별로 튀어넘기 시작했다. 토푸(□□□, 결측 글리프) 감지 스크립트는 버그 때문에 아무것도 감지하지 않은 채 항상 통과 신호를 내보냈고, 이미 박스 문자가 든 영상 두 편이 버젓이 배포됐다. 무음 영상을 무음으로 export했더니 Apple 업로더가 오디오 트랙이 없다며 거부했다—'무음'과 '오디오 없음'은 Apple에게 다른 개념이다. 그리고 App Store Connect는 프리뷰 영상 업로드 공식 API가 없어서, 사이트가 내부적으로 쓰는 비공개 엔드포인트를 역공학해 업로더를 직접 작성해야 했다.
Kei가 이 과정에서 건진 한 문장은 명확하다. "AI는 어려운 부분을 없애준 게 아니라 옮겨놨다." 에이전트는 수천 줄의 렌더링·업로드 코드를 혼자였다면 엄두도 못 낼 속도로 써냈다. 그건 진짜 혁신이었다. 하지만 Apple 가이드라인을 읽어주지 않았고, 안전망 스크립트가 아무것도 잡지 못하고 있다는 사실을 알아채지 못했으며, 자신이 가장 자랑스러워하는 것이 리젝의 원인이라는 걸 말해주지 못했다. 그 판단은 처음부터 끝까지 개발자의 몫이었다.
이 실패 사례가 홀로 서 있다면 단순한 경험담이다. 하지만 비슷한 시기에 등장한 두 편의 글이 같은 질문을 다른 각도에서 해부한다. 'Build Wide, Ship Narrow'라는 워크플로우를 제안한 Bruno Quaresma의 글(dev.to)은 AI 덕분에 코드 생성·설계·브랜치 분해 비용이 극적으로 낮아졌지만, 싸지지 않은 것이 두 가지 있다고 짚는다. 코드 리뷰의 판단 절반—이 변경이 여기 있는 게 맞는가, 이 엔드포인트 설계가 6개월 후에도 유효한가—과 프로덕트 검증이다. 에이전트가 PR을 승인해도 코드를 이해한 게 아니며, 직접 타이핑하지 않은 코드는 읽는 과정을 통해서만 소유권이 생긴다.
'Build Wide, Ship Narrow'의 핵심은 경계를 사전에 결정하는 비용이 사라졌으니, 그 비용을 피하기 위해 억지로 계획하지 말라는 것이다. 대신 설계를 먼저, 코드를 넓게, 브랜치 분해는 나중에—코드가 실제로 만들어진 뒤에야 자연스러운 경계가 보이기 때문이다. AI가 그 분해 작업을 프롬프트 한 번으로 처리해주는 지금, 인간이 집중해야 할 단계는 데모이고 검증이고 방향의 옳고 그름이다. 무엇을 지을지는 여전히 인간이 먼저 틀어쥐어야 한다.
세 번째 시각은 바이브 코딩 실체를 다룬 글(dev.to)에서 온다. '바이브 코딩'은 프롬프트로 코드를 생성하고 검토해 나가는 방식인데, 이 글의 저자가 명확히 선을 긋는 지점이 있다. "바이브 코딩은 모르는 사람에게는 작동하지 않는다." 코드가 뭘 하는지 모르면 깨졌을 때 고칠 수 없다. 아키텍처를 모르면 요구사항이 바뀔 때 확장할 수 없다. AI 생성 코드를 설명하지 못하면 면접도 통과하지 못한다. 이해 없는 바이브 코딩은 '복붙에 프롬프트를 추가한 것'에 지나지 않는다.
세 편의 글을 겹쳐 보면 하나의 윤곽이 드러난다. AI는 실행 비용을 낮춘다. 코드를 타이핑하는 비용, 브랜치를 분해하는 비용, 영상 465개를 렌더링하는 비용. 이 비용들이 0에 가까워졌다는 건 진짜다. 하지만 그 아래에 있는 것들—어느 맥락에서 어떤 규칙이 다르게 적용되는지 아는 것, 안전망이 실제로 작동하는지 확인하는 것, 만든 것이 옳은 것인지 판단하는 것—은 여전히 인간의 속도로 움직인다. AI가 공장을 세워주는 동안 공장이 뭘 찍어내야 하는지, 찍어낸 것이 쓸모 있는지는 개발자가 붙잡고 있어야 하는 질문이다.
465개짜리 영상 공장이 전량 리젝된 이유는 AI가 부족해서가 아니다. Guideline 2.3.4를 모른 건 개발자였고, 스크린샷 맥락의 습관을 영상에 그대로 옮긴 것도 개발자였다. AI는 지시받은 대로 완벽하게 공장을 돌렸다. 문제는 공장 바깥에 있었다. 이게 AI 코딩 에이전트가 프로덕트 개발에 깊숙이 들어온 지금 개발자가 반드시 손에 쥐고 있어야 할 것의 정확한 위치다—공장 안이 아니라, 공장이 작동하는 맥락 전체.