'동작하는 데모'와 '살아있는 서비스'는 다른 물건이다
CNBC 기자들이 Anthropic의 에이전트 툴링으로 Monday.com 스타일의 프로젝트 관리 앱을 한 시간 안에 만들어낸 실험은 많은 것을 증명했다. 그런데 정확히 무엇을 증명했는가? AI 코딩이 '프론트엔드와 기본 플로우까지의 시간'을 제로에 가깝게 압축한다는 사실이다. 이것은 대단한 일이다. 하지만 그 클론이 증명하지 못한 것도 있다—처음 10명의 사용자가 UI에 감탄하는 동안, 다음 100명은 권한 관리와 감사 로그를 요청하고, 1,000명째 사용자는 레이스 컨디션으로 태스크가 사라지는 버그를 발견한다는 것.
dev.to의 분석이 짚어낸 핵심 명제는 하나다. 클론은 움직이는 스크린샷이고, 프로덕트는 현실을 버텨내는 시스템이다. 불안정한 네트워크, 지저분한 데이터, 악의적인 입력, '어제는 됐는데요'—이 모든 것을 견뎌야 비로소 프로덕션이라 부를 수 있다. AI가 이 갭을 자동으로 메워주지 않는다. 그 갭을 의식하고 설계하는 것이 여전히 개발자의 몫이다.
프로토타입이 현실과 부딪히는 다섯 지점
실제로 'AI로 만든 프로토타입이 프로덕션 단계에 접어들 때' 반복적으로 나타나는 병목이 있다. 이것은 추상적인 경고가 아니라 체크리스트다.
데이터 모델링: 초기 프로토타입은 단일 테이블에 모든 걸 쑤셔넣는다. '워크스페이스 지원을 추가해줘', '보드를 공유 가능하게 해줘'—이런 프롬프트를 치기 시작하는 순간, 토이 모델에서 실제 관계형 설계가 필요한 영역으로 진입한 것이다.
인증과 권한: AI 도구는 로그인 페이지를 뚝딱 만들어준다. 하지만 패스워드 리셋, 세션 핸들링, 소셜 로그인 연동, 'Google로 가입했는데 이메일 로그인으로 전환하고 싶어요' 시나리오는 다른 문제다. 인증이 한 번 깨지면 사용자는 앱을 신뢰하지 않는다. OWASP API Security Top 10이 반복해서 경고하듯, 권한은 'admin 불리언 플래그' 수준이 아니라 오브젝트 레벨 접근 제어로 설계해야 한다.
백그라운드 잡과 실시간 동기화: '이메일을 연결하면 자동으로 프로젝트로 변환'—이런 자동화 기능은 매시간 실행되는 잡, 실패 시 재시도, 상태 퍼시스턴스를 필요로 한다. 실시간 업데이트는 UX의 핵심처럼 느껴지지만, 재연결 로직과 부분 실패 처리를 인프라 수준에서 다루지 않으면 가장 먼저 사용자 불만을 만드는 지점이 된다.
파일 스토리지와 푸시 알림: 사용자가 파일을 첨부하는 순간 CDN, 서명 URL, 접근 제어, 데이터 전송 비용이 등장한다. 푸시 알림은 '추가하기 쉽고 잘 하기 어려운' 대표적 기능이다. 관련 없는 알림 하나가 사용자를 알림 비활성화로 유도한다.
아키텍트로서의 역할 전환: '에디터'가 되어야 한다
beyond the hype를 다룬 dev.to의 실전 가이드는 AI 코딩 시대 개발자의 역할 변화를 명확히 정리한다. 코드 작성자에서 코드 아키텍트로. 병목은 더 이상 타이핑 속도나 API 시그니처 암기가 아니다—프롬프트를 설계하고, 출력을 검증하고, AI가 안정적으로 거주할 수 있는 시스템을 설계하는 것이 핵심 역량이 됐다.
실용적으로는 두 가지 패턴이 유효하다. 첫째, 인터페이스 경계를 먼저 정의하고 AI에게 구현을 위임하는 AI-Optimized Module 접근. 박스의 테두리를 날카롭게 그려줄수록 AI는 박스 안을 잘 채운다. 둘째, 개발자가 제어 흐름과 핵심 비즈니스 로직의 스켈레톤을 직접 작성하고, 헬퍼 함수·UI 컴포넌트·데이터 변환기 같은 '살'을 AI에게 생성시키는 Skeleton & Flesh 방식. 시스템의 모양은 내가 쥐고, 구현 디테일은 AI와 협업한다.
Claude Code Skills: 인프라 갭을 메우는 실전 전략
여기서 Anthropic이 내부적으로 수백 개를 운용하며 축적한 Claude Code Skills 노하우가 구체적인 다리 역할을 한다. Skills는 '그냥 마크다운 파일'이 아니다. 스크립트, 에셋, 데이터를 포함하는 폴더 구조이며, 에이전트가 탐색하고 조작할 수 있는 확장 포인트다.
9가지 카테고리 중 프로덕션 배포 현실과 직접 맞닿는 것들이 눈에 띈다. Product Verification 스킬은 Playwright와 tmux를 결합해 가입→이메일 인증→온보딩 플로우를 헤드리스 브라우저로 검증하고, Stripe 테스트 카드로 결제 UI를 구동해 인보이스 상태를 확인한다. AI가 생성한 코드가 '돌아가는 것처럼 보이는' 것과 '실제로 돌아가는 것' 사이의 거리를 좁히는 데 가장 직접적인 투자가 여기다—Anthropic 엔지니어가 일주일을 투자해서라도 검증 스킬을 제대로 만들 가치가 있다고 강조하는 이유가 여기 있다.
CI/CD & Deployment 스킬 카테고리는 더 흥미롭다. deploy-service 스킬은 빌드→스모크 테스트→점진적 트래픽 롤아웃→에러율 비교→회귀 감지 시 자동 롤백까지를 하나의 흐름으로 묶는다. babysit-pr은 PR을 모니터링하다가 flaky CI를 자동 재시도하고 머지 충돌을 해결한다. 이것은 단순한 자동화가 아니라, AI 에이전트가 배포 파이프라인의 실질적 참여자가 되는 구조다.
스킬 작성에서 가장 높은 신호 가치를 갖는 것은 Gotchas 섹션이다. Claude가 이 스킬을 사용할 때 반복적으로 마주치는 실패 지점들을 축적하고 계속 업데이트하는 것—이것이 시간이 지날수록 팀의 AI 활용 품질을 높이는 복리 자산이 된다. 프론트엔드 디자인 스킬의 예시처럼, 'Inter 폰트와 보라색 그라디언트 같은 전형적 패턴을 피하라'는 식으로 AI의 기본 편향을 교정하는 맥락 정보가 일반론보다 훨씬 값지다.
프로토타입→프로덕션 워크플로우의 실용적 순서
이 모든 것을 종합하면 하나의 워크플로우가 도출된다.
- AI로 인터페이스와 기본 플로우를 빠르게: 아이디어 검증과 사용자 피드백 수집까지는 에이전트에게 최대한 위임한다. 이 단계의 코드 품질에 과투자하지 않는다.
- 데이터 모델과 인증·권한은 일찍 잠근다: '워크스페이스 추가해줘'라는 프롬프트를 치기 전에 관계형 설계를 확정하라. 프로덕션 부채는 여기서 쌓이기 시작한다.
- 검증 스킬에 선투자한다: 배포 전에 AI가 생성한 코드를 검증하는 Product Verification 스킬을 구축한다. 일주일의 투자가 이후 수십 번의 프로덕션 인시던트를 막는다.
- 배포 파이프라인을 Skills로 구조화한다: 점진적 롤아웃, 에러율 모니터링, 자동 롤백을 에이전트가 실행할 수 있는 Skills로 정의하면, 배포는 반복 가능한 프로세스가 된다.
전망: '인프라 갭'을 이해하는 개발자가 레버리지를 갖는다
AI 코딩 에이전트의 진화 방향은 명확하다—프로토타이핑 속도는 이미 충분히 빠르고, 앞으로의 차별화는 프로덕션 품질을 얼마나 빠르게 확보하느냐에 있다. 이 경쟁에서 레버리지를 갖는 개발자는 AI가 잘 못하는 영역—데이터 모델 설계, 권한 아키텍처, 검증 파이프라인—을 정확히 이해하고, 에이전트가 그 갭을 메울 수 있도록 Skills와 컨텍스트를 설계하는 사람이다.
'90% AI 생성 코드'의 미래는 개발자를 위협하지 않는다. 다만 가치의 무게중심을 옮긴다. 타이핑에서 설계로, 구현에서 검증으로, 코드 작성에서 시스템 아키텍처로. AI가 한 시간 만에 클론을 만들어줄수록, 그 클론을 현실에서 살아남는 시스템으로 만드는 판단력과 설계 역량의 희소성은 오히려 높아진다.