하나의 제품이 둘이 될 때: 처음부터 다시 시작하지 않고 AI로 만든 앱을 분리하는 법

당신은 하나의 아이디어로 시작했습니다. AI 앱 빌더에 설명하고, 화면이 생성되는 걸 지켜보고, 거친 부분을 다듬어 실제로 작동하는 무언가를 출시했습니다. 사람들이 쓰기 시작했습니다. 그러다 처음엔 천천히, 피드백 속에서 어떤 패턴이 드러났습니다: 사용자의 절반은 한 가지를 원하고, 나머지 절반은 다른 것을 원합니다. 같은 기능을 두고 다투는 게 아니었습니다. 그들은 서로 다른 두 개의 제품을 요청하고 있었습니다.

이 순간, 많은 창업자가 당황해서 두 번째 프로젝트를 맨바닥부터 다시 시작합니다. 그러지 마세요. 하나의 제품이 둘로 드러났을 때 AI 앱을 분리하는 더 깔끔한 방법이 있고, 그 방법은 보통 이미 만들어 놓은 대부분을 그대로 지킵니다. 이 글은 그 분리를 어떻게 알아차리고, 언제 실행하며, 분리가 흔히 띠는 세 가지 형태에 관한 것입니다.

두 개의 제품을 가지고 있다는 걸 어떻게 알게 되는가

신호는 기능 요청처럼 보이는 경우가 거의 없습니다. 마찰처럼 보입니다.

이 과정을 거치는 걸 제가 지켜본 어느 생산성 앱에는 분명한 이야기가 있었습니다. 그건 “개인 플래너”로 팔렸습니다. 사용자가 두 가지 유형으로 나타나기 시작했습니다. 한 무리는 자기 한 주를 계획하는 데 썼고 사적인 노트처럼 다뤘습니다. 다른 무리는 작은 팀을 운영하며 다른 사람에게 일을 할당하고 싶어 했습니다. 둘 다 같은 제품을 계속 쓸 만큼은 만족했지만, 모든 업데이트가 한 무리를 기쁘게 하고 다른 무리를 짜증 나게 했습니다. 팀은 자신들에게 기능 우선순위 문제가 있다고 생각했습니다. 사실은 브랜드 문제가 있었던 겁니다. 그들에게는 하나의 코드베이스, 하나의 홈페이지, 하나의 가격 페이지를 공유하는 개인용 앱과 팀용 앱이 있었습니다.

다음 중 하나가 사실이 되기 시작하면 그 선을 넘었다는 걸 알 수 있습니다:

• 두 청중이 같은 말을 믿지 않기 때문에, 랜딩 페이지가 실제 핵심 메시지를 두루뭉술한 표현 뒤에 숨겨야 한다.
• 모든 새 기능에 “그런데 다른 유형의 사용자에게는 다르게 작동해야 한다”는 단서가 붙는다.
• 고객 응대 답변이 갈라지기 시작한다: “혼자 쓰신다면…” 대 “팀을 관리하신다면…”
• 적지 않은 수의 사용자가 두 모드를 분리하려고 계정 두 개를 따로 유지한다.

이 중 둘 이상을 보고 있다면, 당신에게는 기능 문제가 있는 게 아닙니다. 일어나기를 기다리는 제품 분리가 있는 겁니다.

분리의 세 가지 형태

첫날에 형태를 정할 필요는 없습니다. 보통 가장 가벼운 것부터 시도하고 점차 키울 수 있습니다. 하지만 AI 빌더에 설명하기 전에 선택지를 알아 두면 유용합니다. 당신이 쓰는 단어가 생성되는 것을 좌우하기 때문이죠.

형태 1: 하나의 앱, 두 개의 문

가장 가벼운 버전. 코드베이스 하나를 유지합니다. 첫 실행 때 질문을 하나 추가합니다 — “혼자 쓰러 오셨나요, 팀을 위해 오셨나요?” — 그리고 그 답에 따라 다른 페이지 세트와 다른 내비게이션을 보여 줍니다. 같은 데이터 저장소. 같은 로그인. 같은 결제. 그저 다른 표면일 뿐입니다.

“두 모드 앱”이라고 설명하면 대부분의 AI 앱 빌더가 이걸 잘 처리합니다. 주의할 점은, 두 모드가 곳곳에서 조건부로 보였다 숨었다 하는 화면을 공유해서는 안 된다는 것입니다. 그러면 결국 둘인 척하는 하나의 어수선한 앱처럼 보입니다. 빌더에게 두 문이 분리되어 있다고 말하세요 — 다른 홈페이지, 다른 설정 페이지, 다른 빈 상태 화면. 정말로 겹치는 몇 안 되는 화면(계정 설정, 결제)은 공유해도 됩니다.

이게 통할 때: 두 청중이 다른 틀을 원하지만 그 아래의 같은 대상을 다룰 때. 플래너 대 팀 예시가 여기 들어맞습니다. 일정에 잡는 대상은 여전히 할 일이고, 할당·공유·알림에 관한 규칙만 달라집니다.

이게 통하지 않을 때: 두 청중이 완전히 다른 대상을 기대할 때. “고객 포털”과 “내부 관리 도구”는 같은 비즈니스에 관한 것처럼 보여도 겹치는 게 거의 없습니다.

형태 2: 두 개의 앱, 하나의 백엔드

중간 형태. 제품의 앞단을 두 개의 별도 앱으로 나눕니다 — 두 개의 URL, 두 개의 랜딩 페이지, 두 개의 온보딩 흐름, 두 개의 가격표 — 하지만 둘 다 아래에서는 같은 데이터베이스를 읽습니다. 한 고객이 둘 다에 계정을 가질 수 있습니다. 관리자는 양쪽 데이터를 모두 볼 수 있습니다.

이게 바로 이 블로그를 운영하는 회사가 최근에 한 일입니다. 우리에게는 두 청중을 모두 섬기려는 앱 하나가 있었습니다: 우리 에이전트 플랫폼을 평가하는 엔지니어들과, 우리 AI 앱 빌더를 쓰는 메이커들. 같은 백엔드, 같은 인증, 같은 데이터베이스 — 그런데 앞단이 머리가 둘로 자라났고, 메시지가 혼란스러웠습니다. 우리는 그것을 청중별로 하나씩, 두 개의 앞단 앱으로 분리했습니다. 백엔드는 그대로 두었습니다.

이 형태가 정답일 때:

• 두 청중이 서로 다른 이유로 구매한다.
• 그들이 다른 청중의 마케팅 문구를 보면 혼란스럽거나 거부감을 느낄 것이다.
• 그들이 관심 두는 데이터의 형태는 대체로 같지만 다르게 표현된다.
• 데이터베이스 둘이나 결제 설정 둘을 유지하고 싶지 않다.

AI 빌더에게 “기존 API를 공유하는 두 번째 앞단 앱”을 원한다고 말하세요. 대부분의 현대적 AI 빌더는 형제 프로젝트의 골격을 잡고 그것을 기존 백엔드에 연결할 수 있습니다. 피해야 할 함정: 첫 앱의 컴포넌트를 그대로 복사·붙여넣기 한 다음, 두 사본을 영원히 따로 수정하는 것. 빌더에게 공유되는 부분(인증 화면, 공통 폼 위젯)을 두 앱이 함께 쓰는 작은 라이브러리로 추출해 달라고 하세요. 나중에 중복 수정으로 보낼 몇 달을 아끼게 됩니다.

형태 3: 두 개의 앱, 두 개의 백엔드

가장 무거운 분리. 당신에게는 정말로 두 개의 제품이 있습니다. 데이터도, 사용자도 공유하지 않고, 로드맵도 공유해서는 안 됩니다. 옳은 수는 완전히 분리하는 것입니다: 별도 코드베이스, 별도 데이터베이스, 별도 도메인.

이건 사람들이 생각하는 것보다 옳은 수일 때가 드뭅니다. 깔끔하게 느껴져서 끌립니다. 현실은, 완전히 분리된 두 앱은 굴려야 할 모든 게 두 벌이라는 뜻입니다 — 배포 파이프라인 둘, 온콜 당번 둘, 결제 연동 둘, 도움말 문서 둘. 제품들이 정말로 겹치지 않는 게 아니라면 이 형태에 손대지 마세요. 좋은 시험: 제품 A의 사용자가 절대로 제품 B의 사용자가 되지 않을 거라면, 아마 형태 3이 필요합니다. 사용자 대부분이 둘 다 원할 법하다면, 거의 확실히 형태 2를 원하는 겁니다.

AI 빌더로 이걸 할 때 가장 쉬운 수는, 두 번째 것의 출발점으로 기존 프로젝트를 복사하는 것입니다. 그다음 빌더에게 어울리지 않는 기능은 제거하고 어울리는 기능은 추가해 달라고 하세요. 두 번째 프로젝트를 빈 화면에서 시작하지 마세요. 첫 번째를 만들며 이미 많이 배웠고, 당신이 허락하면 AI 빌더가 그 맥락을 이어받습니다.

무언가를 분리하기 전에 할 일

AI 빌더에게 분리를 설명하기 전에, 작은 일 세 가지를 하세요. 들리는 것보다 값어치가 큽니다.

첫째, 양쪽 각각의 새 홈페이지를 쓰세요. 각각 두 문단씩. 핵심 메시지, 청중, 그들이 해 주길 바라는 한 가지. 서로 다른 홈페이지 두 개를 못 쓰겠다면, 아직 진짜로 두 개의 제품이 있는 게 아닙니다 — 하나의 제품의 두 세그먼트가 있을 뿐이며, 그건 아키텍처가 아니라 메시지로 풀어야 합니다.

둘째, 어떤 화면이 공유되고 어떤 화면이 안 되는지 적으세요. 솔직하게요. “로그인은 공유. 온보딩은 다름. 대시보드는 다름. 설정은 대부분 공유. 결제는 공유.” 이 목록이 AI 빌더에게 건넬 브리프가 됩니다. 오가는 수고를 많이 덜어 줍니다.

셋째, 아래에서 무엇이 같은지 정하세요. 같은 사용자? 같은 데이터? 같은 결제? “예”가 하나씩 늘 때마다 형태 1이나 2 쪽으로 당겨집니다. “아니오”가 하나씩 늘 때마다 형태 3 쪽으로 당겨집니다. 정답은 없습니다 — 당신 제품이 실제로 작동하는 방식에 맞는 답만 있을 뿐입니다.

분리 후에 달라지는 것

두 가지는 쉬워지고 한 가지는 어려워집니다.

마케팅이 쉬워집니다. 각 앱이 자기만의 분명한 핵심 메시지를 갖습니다. 각 랜딩 페이지가 얼버무리지 않고 한 청중에게 말할 수 있습니다. 전환율은 보통 적어도 한쪽에서, 때로는 양쪽 모두에서 올라갑니다.

온보딩이 쉬워집니다. 처음 온 사용자가, 모두에 관한 것이 되려는 페이지가 아니라, 자기에 관한 페이지에 도착합니다.

어려워지는 것은 공유 부분을 동기화 상태로 유지하는 일입니다. 로그인 흐름의 버그를 고치면, 두 앱 모두에서 고쳐지길 바랍니다. 결제 화면의 모양을 바꾸면, 두 앱 모두에 반영되길 바랍니다. 필요한 규율은 — 이건 AI 빌더로 바이브 코딩을 하든 사람 개발자 팀으로 만들든 똑같이 참인데 — 공유 부분을 진짜로 공유 상태로 유지하는 것입니다. 복제하지 마세요. 분기시키지 마세요. 공유 화면을 두 앱이 함께 쓰는 작은 라이브러리로 추출하든가, 아니면 진짜로 분리된 두 개의 앱을 가졌음을 받아들이고 그걸 책임지든가 하세요.

끝맺으며 던지는 작은 질문

지금 앱의 핵심 메시지를 낯선 사람 다섯에게 들려줬는데 다들 서로 다르게 — 그러나 두 개의 또렷한 묶음으로 — 묘사한다면, 당신은 아마 이미 그 분리와 함께 살고 있는 겁니다. 유일한 질문은, 혼란스러운 하나의 제품이라는 세금을 계속 낼 것이냐, 아니면 둘이라는 사실에 정직해지는 수고를 할 것이냐입니다.

오늘 결정할 필요는 없습니다. 하지만 다음번에 AI 앱 빌더가 “다음으로 뭘 만들까요?”라고 묻거든, 가장 유용한 답이 새 기능이 아닐 수도 있다는 걸 떠올려 보세요. 새로운 정문일지도 모릅니다.

이 글이 와닿았다면, 앞서 쓴 팀을 위한 제작 vs 고객을 위한 제작 글도 마음에 드실 수 있습니다 — 같은 결의 결정이지만, 제품의 삶에서 한 단계 더 앞선 이야기입니다.