이 질문은 특정한 방식으로 등장합니다. "AI 빌더를 써야 할까"가 아닙니다 — 그건 다른 글이고, 보통 다른 사람이 묻는 질문입니다. 이 질문은 실제로 성과를 내고 있는 빌드를 6개월, 8개월, 12개월째 진행 중인 사람에게서 나옵니다. 실제 사용자, 실제 매출, 그리고 이 도구가 감당하지 못하는 벽에 곧 부딪힐 것 같다는 찜찜한 느낌. 아래는 사람들이 실제로 제게 묻는 질문들을, 대체로 묻는 순서대로 정리한 것입니다.
정말로 AI 빌더의 한계를 넘어설 수 있나요, 아니면 사람들이 스스로에게 하는 이야기일 뿐인가요?
둘 다 일어나고, 겉보기엔 똑같아 보입니다. 진짜 성장의 한계는 구체적입니다: 세 당사자 간 분할 정산이 있는 결제 흐름이 필요하거나, 규제 기관이 실제로 읽을 감사 추적이 있는 컴플라이언스 워크플로우가 필요하거나, 계산적으로 특이한 작업을 하고 있는 경우입니다 — 실시간 영상 처리, 물리 시뮬레이션, 자체 데이터로 학습한 맞춤형 추천 모델 등. 이런 것들은 아키텍처 문제이지, 프롬프트 문제가 아닙니다.
가짜 버전은 아직 써보지 않은 프롬프트입니다. "빌더가 커서 페이지네이션 방식의 무한 스크롤을 못 만든다"는 건 보통 아무도 그것을 제대로 설명하지 않았다는 뜻입니다 — 누군가 "페이지네이션 추가해줘"를 한 번 시도해보고 결과가 마음에 들지 않아 두 번째 시도 대신 조용히 한계로 기록해버린 겁니다. "한계에 부딪혔다"는 대화의 4분의 3 정도는 재구축이 아니라 더 나은 프롬프트로 해결될 거라고 생각합니다.
제가 겪은 게 진짜인지 가짜인지 어떻게 구별하나요?
| 한계에 도달한 것처럼 느껴짐 | 보통 실제로 그런 경우 | 보통 아닌 경우 |
|---|---|---|
| "X를 못 한다" | X가 플랫폼이 전혀 노출하지 않는 인프라를 요구함(맞춤형 TCP 프로토콜, GPU 학습 작업, HIPAA 감사 데이터 흐름 등) | X가 충분히 구체적으로 설명되지 않았거나, 반복 시도 없이 한 번에 요청됨 |
| "규모가 커지면 너무 느리다" | 생성된 코드와 표준 호스팅 등급이 실제 부하를 견디지 못하는 지점을 이미 넘어섬 | 아직 겪어보지도 않은 부하를 추측하고 있음 |
| "내게 없는 통제권이 필요하다" | 특정 수정을 위해 채팅 루프 밖에서 생성된 코드를 직접 수정해야 함 | 더 많은 맥락을 담아 수정을 다시 요청해보지 않았음 |
| "우리 팀이 코드를 직접 다뤄야 한다" | 엔지니어를 채용했고 그들에게 일반적인 git 워크플로우가 필요함 | 혼자서 다루고 있으며 단지 좀 더 "진짜"처럼 느끼고 싶을 뿐임 |
솔직히 말하면, 구체적인 기술 요구사항을 명시할 수 있는지, 아니면 그냥 느낌을 설명하고 있는지가 핵심입니다. "지수 백오프와 데드레터 큐가 있는 웹훅 재시도가 필요하다"는 요구사항입니다. "이제 내 것이 필요한 느낌이다"는 느낌이고, 느낌은 보통 마이그레이션이 아니라 더 나은 프롬프트로 해결됩니다.
떠나기로 결정하면 실제로 무엇을 소유하게 되나요?
이건 사람들이 가장 불안해하는 질문이면서, 가장 깔끔한 답을 가진 질문이기도 합니다: 자신의 도메인에 배포된 것과 데이터를 소유합니다. 자신이 통제하는 도메인에 배포했다면 — SFTP를 통해서든, 자신의 등록기관을 통해서든 — 그 서버에 있는 파일은 여러분이 빌린 어떤 서버의 코드든 마찬가지로 여러분 것입니다. 누구도 그걸 회수할 수 없습니다. Search Console과 Analytics 연동은 여러분이 인증한 Google 계정이며, 빌더 연결을 끊어도 Google 시스템에 있는 과거 데이터는 영향받지 않습니다. 애초에 그건 빌더의 데이터가 아니었으니까요. 그건 여러분의 계정이고, 그저 필터링되어 보였을 뿐입니다.
자동으로 얻지 못하는 것은 채팅 기록, 계획 문서, 검증 기록, 그리고 빌더가 가지고 있던 프로젝트에 대한 내부 모델 — 빠른 반복을 가능하게 했던 부분입니다. 그게 진짜로 플랫폼에 묶여 있는 부분이고, 대부분의 사람들이 새 도구로 그 맥락을 손수 재구축하기 전까지는 그 가치를 과소평가하는 부분이기도 합니다.
락인이 있는 건가요, 아니면 제가 과민한 건가요?
락인이 무슨 뜻이냐에 따라 다릅니다. "내 사이트를 인질로 잡을 수 있는가"를 뜻한다면 — 아닙니다, 처음부터 자신의 도메인에 배포했다면요. 그게 바로 서브도메인에서 영원히 운영하는 대신 도메인을 소유하는 이유입니다. "떠나면 몇 달간의 반복 작업으로 누적된 가치를 잃게 되는가"를 뜻한다면 — 네, 그렇습니다. 하지만 이건 진짜 락인이 아니라, 시간을 투자한 어떤 도구를 바꾸는 것과 똑같은 매몰 비용일 뿐입니다. 모든 에디터, 모든 프레임워크, 모든 CRM이 이런 성질을 가지고 있습니다. 문제는 전환 비용이 존재하느냐가 아니라, 그것이 인위적인가(계약 조건, 데이터 인질 잡기) 자연스러운 것인가(어딘가에서 추진력을 쌓았고 옮기려면 그걸 다시 쌓아야 함)입니다. 인위적인 락인은 위험 신호입니다. 자연스러운 전환 비용은 그냥 "도구에 능숙해진다"는 것의 의미일 뿐입니다.
프롬프트를 하나 더 쓰는 대신 엔지니어를 고용하는 게 실제로 타당한 때는 언제인가요?
세 가지 상황이 있고, 제가 자주 보는 순서대로 나열하면:
- 컴플라이언스 사유로 사람이 필요한 경우 — 일부 규제 프레임워크는 아무리 좋은 커밋이라도 AI가 생성한 커밋의 감사 추적이 아니라, 지명된 책임 엔지니어를 요구합니다.
- 진짜 새로운 기술적 문제가 있는 경우 — "마켓플레이스를 만들어주세요"처럼 이미 많이 다뤄진 것이 아니라, 독점 데이터로 튜닝한 커스텀 매칭 알고리즘처럼 가치가 참신함 자체에 있는 경우, 원하는 결과만 설명하는 게 아니라 구체적인 수식을 이해하고 추론할 수 있는 사람이 필요합니다.
- "작동하는 생성 코드"와 "정확한 트래픽 패턴에 맞게 프로파일링되고 튜닝된 생성 코드"가 갈라지는 규모를 넘어선 경우 — 이건 실제로 있는 일이지만, 대부분 사람들이 생각하는 것보다 훨씬 더 먼 얘기입니다. "빌더에게 너무 크다"고 느끼는 많은 앱들은 실제로 월간 활성 사용자가 낮은 5자리 수 정도이고, 이는 잘 짜인 생성 코드에게 실제로 규모 문제가 되지 않습니다.
이 목록에 없는 것에 주목하세요: "더 많은 통제권을 원한다." 더 많은 통제권을 원하는 건 선호이지 요구사항이 아닙니다. 자신이 느끼는 게 어느 쪽인지 솔직하게 인식할 필요가 있습니다.
엔지니어를 영입한다면, AI가 만든 코드를 확장해야 하나요, 아니면 처음부터 다시 시작해야 하나요?
거의 항상 확장하세요. 팀들이 "AI가 생성한 거니까 어차피 임시로 쓰는 거였다"는 이유로 기본값으로 "처음부터 다시 작성"을 택했다가 잘못되는 경우를 잘된 경우보다 더 많이 봤습니다. 그건 평가가 아니라 편견입니다. 먼저 실제 코드를 읽어보세요. 계획과 검증 단계를 배포 전에 보여주는 빌더는 보통 일관성 있는 코드를 만들어냅니다. 일관된 계획이 일관된 코드를 만들기 때문입니다 — 그리고 코드가 합리적으로 구조화되어 있다면, 가장 빠른 길은 보통 평범한 엔지니어가 평범한 코드베이스를 이어받는 것입니다. 완전한 재작성은 비싼 선택이니, 코드가 어디서 왔는지 때문이 아니라 다가올 것을 진짜로 감당할 수 없을 때를 위해 아껴두세요.
빌더에서 "졸업"한 지 6개월 후 사람들이 실제로 겪는 실패 패턴은 무엇인가요?
그것들은 반복 루프를 없애버리지만 대신할 무언가를 마련해주지는 않습니다. 대부분의 사람들에게 빌더의 진짜 가치는 결코 "코드를 작성해준다"는 것이 아니었습니다 — 코드를 작성하는 도구는 이미 많습니다. 진짜 가치는 제안 → 검증 → 배포 → 측정이라는 흐름이, 매 단계마다 사람이 병목이 되지 않고 빠르게 돌아간다는 데 있었습니다. 도구를 떠나면서 이에 상응하는 루프 — CI, 스테이징, 모니터링, 아이디어에서 배포까지 이어지는 빠른 경로 — 를 다시 구축하지 않는 팀은 결국 빌더를 처음 쓰기 시작한 날보다도 더 느리게 배포하게 되며, 대개 코드베이스가 여전히 더 "진짜"처럼 느껴지기 때문에 몇 달 동안은 이 사실을 알아채지 못합니다. 진짜라는 것과 빠르다는 것은 같은 성질이 아닙니다. 도구를 벗어날 계획이라면, 단지 더 많은 파일을 직접 소유하게 되는 것이 아니라 떠나온 프로세스만큼, 혹은 그보다 더 촘촘한 프로세스로 성장해 나가야 합니다.
"우리는 한계를 넘어섰다"의 정직한 버전은 보통 "우리는 그것이 다루지 못하는 구체적이고 이름 붙일 수 있는 요구사항으로 성장했다"입니다. 그 요구사항을 이름 붙일 수 없다면, 아마 아무것도 넘어서지 못한 것입니다 — 그저 반복을 멈춘 것뿐입니다.
