코딩을 전혀 모르는 문과생이 Claude와 함께 디펜스 게임을 완성했다. 인벤의 '바이브 코딩 AI 게임 개발기 ②'가 전하는 이 사실은, 단순한 성공담이 아니다. 그 안에는 AI 코딩 도구가 가져온 패러다임 전환의 핵심이 고스란히 담겨 있다.
필자가 처음 실패한 이유는 명확했다. "클리커형 게임을 만들어줘"라는 단 몇 줄짜리 프롬프트로 시작했기 때문이다. AI는 그럴듯해 보이는 결과물을 뱉었지만, 문을 열고 들어가면 배수 시설도 전기 배선도 없는 껍데기 집이었다. 버그를 고쳐달라는 무한 루프만 반복됐고, 결국 프로젝트를 포기 직전까지 몰았다. 반전은 '게임 기획서'를 먼저 작성하면서 시작됐다. Claude에게 디펜스 게임 장르 정보를 넘기고 기획서를 만들게 한 뒤, 그것을 토대로 구현을 요청했더니 처음부터 제법 작동하는 게임이 나왔다. 기획서 유무의 차이가, 그만큼 컸다.
이 경험은 dev.to에 게재된 'Specification Is a Compile Target'이 이론적으로 정리한 명제와 정확히 맞닿아 있다. 필자 Nick은 이렇게 선언한다. "구현은 더 이상 병목이 아니다. 스킬은 위로 올라갔다. 무엇을 만들지 결정하고, 기계가 나머지를 처리할 수 있을 만큼 정밀하게 기술하는 것—그것이 남은 유일한 인간의 영역이다." AI 에이전트가 정밀한 명세를 받아 몇 분 안에 작동하는 구현체를 만들어내는 지금, 명세는 더 이상 인간 개발자에게 전달하는 '참고 문서'가 아니다. 컴파일러에 입력하는 소스 아티팩트다.
컴파일러는 관대하지 않다. "API가 이미 이 필드를 반환한다", "이건 UI 변경일 뿐이다"—명세 안에 담긴 이런 현실 주장들은 실제 코드베이스에 대해 참이거나 거짓이다. 인간 개발자가 구현을 맡을 때는 코딩 중에 오류를 발견하고 머릿속에서 명세를 패치했다. 하지만 에이전트는 명세를 그대로 신뢰한다. 명세가 틀렸다면, 자신 있게 틀린 시스템이 빠르게 만들어진다. 검증되지 않은 주장이 명세를 타고 구현으로 직행하는 것, 이것이 'AI 시대의 새로운 버그 유입 경로'다.
두 사례를 겹쳐 읽으면 시사점이 선명해진다. 바이브 코딩 필자가 배운 교훈—좋은 기획서가 있어야 좋은 게임이 나온다—은 사실 "명세의 품질이 구현의 품질을 결정한다"는 원칙의 체험판이다. 기획서라는 명세가 충분히 구체적이고 검증 가능했을 때, AI는 비로소 제 역할을 했다. 반대로 막연한 한 줄짜리 요청은, 아무리 좋은 AI 모델을 써도 껍데기 집을 양산할 뿐이었다. 이것은 프롬프트 엔지니어링의 문제가 아니라 명세 설계의 문제다.
현재 시장의 스펙 주도 개발 도구들—GitHub의 Spec Kit, AWS의 Kiro, Tessl—은 명세의 일관성과 완결성을 검증하는 '코히어런스 오라클'을 갖추고 있다. 명세가 자기 모순 없이 잘 쓰였는지를 확인하는 것이다. 하지만 Nick이 지적하듯, 아직 아무도 '트루스 오라클'을 만들지 않았다. 명세 안의 주장이 실제 코드베이스에 대해 참인지를 구현 전에 차단하는 게이트다. 이 방은 비어 있다. 그리고 구현 자동화가 성숙할수록, 시니어 엔지니어들은 모두 이 방으로 밀려 올라오게 될 것이다.
프론트엔드 개발자 관점에서 이 흐름은 즉각적인 실천 의제를 던진다. 오늘 당장 Claude나 Cursor에게 컴포넌트 하나를 만들어달라고 할 때, 당신이 건네는 프롬프트가 얼마나 검증 가능한 주장으로 채워져 있는지 돌아볼 필요가 있다. "기존 디자인 시스템 토큰을 사용해"는 참인가 거짓인가? "이 API 응답 구조를 따라해"의 구조는 실제로 지금도 그 형태인가? 명세 안의 현실 주장들이 검증되지 않으면, AI는 틀린 전제 위에 빠르게 건물을 올린다. 속도는 오히려 부채를 키운다.
결국 'AI 시대의 개발 실력'은 재정의되고 있다. 코딩 0점 문과생이 게임을 완성할 수 있는 세상에서, 코드를 타이핑하는 능력은 더 이상 희소 자원이 아니다. 희소한 것은 무엇을 만들어야 하는지를 판단하고, 그 판단을 AI가 컴파일할 수 있을 만큼 정밀하게 명세로 변환하는 능력이다. 기획서를 잘 짜는 법이 곧 개발 실력인 시대—이 전환은 이미 조용히 완료됐다.