딸깍으로 만든 껍데기와 진짜 프로덕트의 차이
만드는 건 쉬워졌지만, 올바른 것을 만드는 건 여전히 어렵다
딸깍 한 번으로 앱이 생기는 시대
비전공자가 AI로 앱을 만들었다는 이야기가 넘쳐난다. 프롬프트 몇 줄로 로그인 화면이 나오고, 버튼 하나로 데이터베이스가 연결되고, 하루 만에 MVP가 완성됐다는 후기들. 나도 직접 해봤다. 실제로 된다. 화면이 나오고, 클릭이 되고, 그럴듯한 무언가가 만들어진다. 그런데 그것을 실제 사용자에게 내놓으려는 순간, 뭔가 이상하다는 걸 느끼기 시작했다.
딸깍으로 만들어지는 건 껍데기다. 화면이 있고 흐름이 있고 기능처럼 보이는 것이 있다. 하지만 그것이 프로덕트는 아니다. 프로덕트는 실제 사용자가 실제 문제를 해결하기 위해 반복적으로 쓰는 것이다. 그 기준으로 보면, AI가 빠르게 만들어주는 것들의 대부분은 데모다. 데모와 프로덕트 사이에는 생각보다 훨씬 넓은 간극이 있다.
데모는 쉽다, 프로덕션은 완전히 다른 레벨이다
AI로 만든 데모가 인상적인 이유는 단순하다. 혼자 쓰거나 소수가 보는 환경에서는 대부분 잘 작동한다. 데이터가 적고, 동시 접속자가 없고, 보안을 신경 쓸 필요가 없고, 장애가 나도 그냥 새로고침하면 된다. 이 조건에서는 AI가 생성한 코드가 충분히 돌아간다. 문제는 이 조건이 실제 서비스와 완전히 다르다는 것이다.
실제 서비스에는 동시에 수백 명이 접속한다. 그 순간 DB 커넥션이 터지거나 응답이 느려지면 사용자는 이탈한다. 캐싱이 없으면 같은 쿼리를 매번 날리고, 서버 비용이 폭발한다. 인증 로직에 구멍이 있으면 다른 사용자의 데이터가 노출된다. 배포 후 에러가 나면 롤백해야 하는데, 그 구조가 없으면 서비스 전체가 멈춘다. AI는 이 문제들을 코드로 해결해줄 수 있다. 하지만 어떤 문제가 있는지 먼저 알아야 물어볼 수 있다.
나는 이 포트폴리오 사이트를 직접 만들면서 이 간극을 몸으로 겪었다. 정적 사이트라 운영 복잡도가 낮은데도, 빌드 최적화, 이미지 처리, SEO 구조, 배포 파이프라인 같은 것들이 하나씩 문제로 올라왔다. 실제 트래픽이 붙는 서비스였다면 그 목록은 열 배는 길었을 것이다. 데모를 만드는 것과 서비스를 운영하는 것은 같은 선상에 있지 않다.
우리가 프로덕트를 못 만들어서 실패한 게 아니다
스타트업이 실패하는 이유를 분석한 자료들을 보면 공통적인 패턴이 있다. 기술 문제로 실패하는 경우는 생각보다 적다. 대부분은 시장이 없거나, 사용자가 원하지 않거나, 문제 자체를 잘못 정의했기 때문이다. 만드는 것 자체가 어려웠던 시절에도 그랬다. 지금은 만드는 비용이 거의 0에 수렴하고 있다. 그렇다면 실패의 이유가 줄어들어야 하는데, 실제로는 그렇지 않다.
만드는 게 쉬워졌다는 건 올바른 것을 만드는 것도 쉬워졌다는 뜻이 아니다. 오히려 반대다. 만드는 비용이 낮아질수록, 잘못된 것을 빠르게 만드는 것도 쉬워진다. 예전에는 잘못된 방향으로 가려면 시간과 돈이 많이 들었다. 그 비용이 자연스러운 제동 장치 역할을 했다. 지금은 그 제동 장치가 없다. 아이디어가 생기면 하루 만에 앱이 나온다. 그 앱이 아무도 원하지 않는 것이어도, 만드는 데 걸린 시간은 하루다.
내가 관찰한 패턴은 이렇다. AI 도구를 잘 쓰는 사람들이 빠르게 뭔가를 만들어낸다. 그런데 그 결과물이 실제로 쓰이는 경우는 드물다. 만드는 속도와 올바른 것을 만드는 능력은 별개다. 우리가 프로덕트를 못 만들어서 실패한 게 아니다. 올바른 것을 만들지 못해서 실패한 것이다. 그리고 이 문제는 AI가 해결해주지 않는다.
문제를 모르면 예쁜 쓰레기만 빠르게 만든다
AI를 쓸 때 가장 위험한 상태는 문제가 있는지조차 모르는 상태다. 이 상태에서 AI를 쓰면 결과물이 빠르게 나온다. 화면이 예쁘고, 흐름이 매끄럽고, 기능이 작동하는 것처럼 보인다. 그런데 그 결과물이 실제 사용자의 실제 문제를 해결하는지는 전혀 다른 질문이다. 문제를 정의하지 않은 채로 솔루션을 만들면, 아무리 잘 만들어도 쓰레기다. AI는 그 쓰레기를 더 빠르게, 더 예쁘게 만들어줄 뿐이다.
나는 이것을 직접 경험했다. 사용자 인터뷰 없이 내가 불편하다고 느낀 것을 기반으로 기능을 만든 적이 있다. AI 덕분에 빠르게 만들었다. 그런데 실제 사용자에게 보여줬을 때, 그들은 그 기능을 전혀 원하지 않았다. 내가 불편하다고 느낀 것이 그들에게는 문제가 아니었다. 빠르게 만든 것이 빠르게 버려졌다. 속도가 빨라진 것이 오히려 독이 됐다.
문제가 있는지 모르는 상태에서 AI를 쓰면 이 사이클이 더 빠르게 돌아간다. 아이디어 → 딸깍 → 데모 → "이거 어때요?" → 반응 없음 → 다음 아이디어. 이 루프가 빨라질수록 올바른 문제를 찾는 과정은 생략된다. 결국 예쁜 쓰레기를 빠르게 만드는 기계가 된다. 속도가 문제를 해결해주지 않는다. 방향이 맞아야 속도가 의미 있다.
기본기가 더 중요해진 역설
AI가 만드는 것을 쉽게 만들수록, 올바른 것을 만드는 능력의 가치가 올라간다. 이것이 역설이다. 도구가 강력해질수록 도구를 쓰는 사람의 판단력이 더 중요해진다. 도메인 지식, 서비스 운영 경험, 사용자 이해. 이것들은 AI가 대신해줄 수 없는 영역이다. AI는 내가 정의한 문제를 빠르게 풀어준다. 하지만 어떤 문제를 풀어야 하는지는 내가 알아야 한다.
다만 이 기본기는 책으로 쌓이지 않는다. 실제 서비스를 운영하면서, 사용자가 이탈하는 순간을 직접 보면서, 잘못 정의한 문제 때문에 팀 전체가 헛수고하는 경험을 하면서 쌓인다. 그 경험이 있는 사람이 AI를 쓰면, 도구가 강력한 만큼 결과도 달라진다. 경험이 없는 사람이 AI를 쓰면, 도구가 강력한 만큼 잘못된 방향으로 더 빠르게 달려간다. 결국 AI 시대에 가장 희소한 것은 도구를 잘 쓰는 능력이 아니라, 무엇을 만들어야 하는지 아는 능력이다.