AI가 만든 첫 앱은 쉽다 — 진짜 시험은 20번째 변경이다

본문

AI 앱 빌더 덕분에 아이디어에서 동작하는 프로토타입까지 가는 시간은 이제 반나절이면 충분합니다. 원하는 것을 설명하면 AI가 UI를 만들고 로직을 연결해 실제 제품에 놀라울 만큼 가까운 결과물을 내놓습니다. 하지만 저자는 우리가 이런 도구를 잘못된 시점에서 측정하고 있다고 말합니다. 중요한 질문은 '첫 프롬프트로 무엇을 만들었는가'가 아니라 '변경 20번을 거친 뒤 이 프로젝트는 어떤 모습인가'라는 것입니다.

첫 버전은 이미 상품(commodity)이 됐다

'인증, 파일 업로드, 대시보드가 있는 클라이언트 포털을 만들어줘' 같은 프롬프트를 주면 요즘 AI 빌더 대부분은 금방 알아볼 수 있는 결과를 만들어냅니다. 예전에는 마법처럼 보였던 것이 이제는 거의 당연한 기능이 됐습니다. 문제는 그 다음에 시작됩니다. 고객이 새로운 역할(role)을 요구하고, 온보딩 플로우를 바꾸고, 데이터베이스 구조가 변경되고, 결제와 권한이 추가되면서 어느 순간 작은 요청 하나가 세 프롬프트 전에 잘 되던 기능을 망가뜨립니다. 이 시점에서 질문은 'AI가 코드를 얼마나 빨리 생성하는가'가 아니라 '제품이 반복(iteration)을 견딜 수 있는가'로 바뀝니다.

AI 빌더를 비교하는 더 나은 방법

저자는 빌더마다 다른 데모 프롬프트를 주는 대신, 똑같은 작은 애플리케이션을 만들게 한 뒤 의도적으로 귀찮게 굴어야 한다고 제안합니다. 사용자 역할을 추가하고, 데이터베이스 스키마를 바꾸고, 온보딩 일부를 교체하고, 외부 API를 붙이고, 권한을 변경하고, 기능을 제거했다가 다른 방식으로 되돌리는 식입니다. 그때 비로소 도구 간의 실제 차이가 드러납니다. 프로젝트가 여전히 이해 가능한 구조를 유지하는지, 한 곳을 바꿨을 때 다른 곳이 조용히 깨지는지, 무엇이 바뀌었는지 파악할 수 있는지, 잘못된 결정을 롤백할 수 있는지가 확인 대상입니다. 그리고 가장 중요한 질문은 '내 앱을 건드리는 게 두려워지지 않고 계속 개발할 수 있는가'입니다.

'작동한다'와 '유지보수 가능하다'는 다르다

이 문제는 실제 사용자가 들어오면 더 중요해집니다. 생성된 앱은 겉보기에 완성도가 높아도 아래에 문제를 숨기고 있을 수 있습니다. 인증이 정상 경로에서는 동작하지만 엣지 케이스에서 실패할 수 있고, UI가 다른 사용자의 데이터를 가려줘도 백엔드 권한이 실제로 보호하지 않을 수 있으며, 외부 API가 예상치 못한 응답을 반환하기 전까지만 통합이 완벽하게 보일 수 있습니다. 이런 문제들은 AI 데모 영상에서는 멋지게 보이지 않지만, 출시 이후 제품의 생존을 결정하는 요소입니다.

built.new에 대한 언급과 벤치마크 제안

저자는 자신이 이 분야의 도구인 built.new에 관여하고 있음을 밝히며 관점에 이해관계가 있음을 공개합니다. 그는 'AI가 내 앱을 만들었다'와 '내 앱을 계속 만들어갈 수 있다' 사이의 간극을 계속 고민하고 있다고 말합니다. 첫 버전을 빨리 생성하는 것은 가치 있지만, 이후 모든 변경이 불확실성을 더한다면 초반의 속도 이점은 사라집니다. 목표는 아이디어에서 첫 빌드까지의 시간을 줄이는 것뿐 아니라, 첫 빌드 → 피드백 → 변경 → 추가 피드백 → 실제 제품으로 이어지는 두 번째 루프의 마찰을 줄이는 것이어야 하며, 실제로 많은 제품이 이 두 번째 루프에서 만들어진다고 강조합니다. 그는 2026년의 더 나은 벤치마크로 '오늘 무언가를 만들고, 20번 바꿔도 여전히 작업하기 즐거운가'를 제시하며, AI로 생성한 프로젝트가 복잡해질 때 어떤 부분이 먼저 깨지는지 독자들에게 질문을 던집니다.

원문: dev.to / 번역·요약: Trawling