AI로 만든 앱이 첫 버전을 넘어설 때: 리팩터링이냐 재작성이냐

무언가를 출시했습니다. 사용자들이 좋아했습니다. 이제 사용자가 열 명이 됐는데, 그들은 원래 모양에 맞지 않는 기능을 원합니다. 당신은 갈림길에 서 있습니다: 새 용도에 맞게 앱을 기우거나, 아니면 첫 버전이 프로토타입이었음을 인정하고 제대로 짓거나. 이건 다른 어떤 것보다 더 많은 작은 프로젝트를 죽이는 질문입니다. 기술적인 답이 없고 — 비즈니스의 답만 있기 때문입니다.

앱이 성공했음을 깨닫는 순간

AI로 만든 앱은 대부분 한 가지로 시작해 다른 것이 됩니다. 코칭 사업을 위한 고객 접수 폼을 만들었더니, 이제 고객들이 지난 약속을 보고 스스로 일정을 다시 잡고 싶어 합니다. 리드 스코어링 도구를 만들었더니, 이제 영업팀이 요약을 자기 CRM으로 내보내고 싶어 합니다. 파일 정리 시스템을 만들었더니, 이제 사람들이 그 안에서 협업하고 싶어 합니다.

각 요청은 합당합니다. 각각이 앱을, 만들어진 본래 모습에서 조금씩 떼어 냅니다. 그리고 어느 시점에 — 6개월 차, 아니면 2개월 차, 때로는 2주 차에 — 당신은 마찰을 느낍니다. 추가하는 모든 게 토대와 싸웁니다. 새 기능마다 “아, 그 부분부터 먼저 재정리해야 해요”가 따라붙습니다. 앱이 느려집니다. 무언가를 바꾸는 데 더 오래 걸립니다.

그 느낌이, 이게 여전히 같은 앱인지, 아니면 당신이 그걸 넘어서 자랐는지 생각해 볼 신호입니다.

리팩터링이 사 주는 것과 그 대가

리팩터링이란 같은 앱을 유지하되, 그 위에 더 많이 지을 수 있도록 정리하는 것입니다. AI 빌더에게 코드를 재정리하거나, 지나치게 복잡해진 워크플로를 쪼개거나, 기능들의 잡동사니 창고가 된 화면을 다시 설계해 달라고 합니다. 몇 시간 걸립니다. 새 기능은 추가하지 않습니다. 그저 토대를 더 튼튼하게 만들 뿐입니다.

리팩터링이 통할 때, 그건 마법입니다. 앱과 싸우는 것 같던 느낌이 — 갑자기 사라집니다. 전에는 3주가 걸렸을 새 기능 세 개를 일주일에 추가합니다.

하지만 리팩터링은 문제가 가진 것의 모양일 때만 통합니다. 접수 폼을 만들었는데 사용자들이 더 빠른 접수 폼을 원한다면, 느린 부분을 리팩터링하는 건 한나절짜리입니다. 빠르면서 동시에 기록도 저장하는 접수 폼을 원한다면, 여전히 하나의 앱이고 리팩터링이 도움이 될 수 있습니다. 그런데 약속 기록, 캘린더 연동, SMS 알림, 그리고 청구까지 원한다면, 당신은 더 나은 접수 폼을 만드는 게 아닙니다 — 코칭 사업의 백오피스를 만드는 겁니다. 그건 다른 제품입니다.

재작성이 사 주는 것과 그 대가

재작성이란: 앱이 실제로 무엇이어야 하는지 배웠고, 그 지식을 가지고 처음부터 다시 짓겠다는 것입니다. 첫 버전을 버리지는 않습니다 — 사용자들이 여전히 거기 의지하니까요. 하지만 옛것이 가르쳐 준 바에 근거해 새 앱을 밑바닥부터 짓고, 준비되면 사용자를 옮깁니다.

재작성은 낭비처럼 느껴집니다. 무언가를 만들었는데, 이제 또 만들고 있으니까요. 그게 심리적 비용입니다. 실질적 비용은 시간입니다: 사용자를 옮길 준비가 되기까지 새 버전에 두 달에서 넉 달을 씁니다. 더는 첫 버전을 버팀목으로 쓸 수 없습니다 — 안전망 없이 앞으로 밀고 나가는 겁니다.

하지만 재작성은 다른 무엇도 줄 수 없는 한 가지를 사 줍니다: 자유. 새 앱은 옛것의 모양에 매이지 않습니다. 원래가 단순한 폼이었고 새것이 완전한 백오피스여야 한다면, 처음부터 그걸 위해 설계합니다. 성능이 중요하다면, 그걸 위해 설계합니다. 보안이나 연동이나 워크플로가 중요하다면, 그것들은 나중에 덧댄 게 아니라 — 토대가 됩니다.

재구축 후 성공하는 앱들은 보통, 문제에 대한 팀의 이해가 원래 코드에서 너무 멀리 옮겨 가서, 기우는 것이 잘 안 맞는 옷을 입는 것 같았기 때문에 그렇게 합니다. 재작성은 자신들을 위해 짓는 것을 뜻했습니다.

둘 사이를 고르는 세 가지 질문

질문 1: 핵심 모양이 여전히 맞는가?

당신의 핵심 모양은 앱을 정의하는 한두 개의 주요 워크플로입니다. 코칭 접수 폼이라면, “고객이 접수를 작성하고, 코치가 검토하고, 코치가 일정을 잡는다”입니다. 다른 워크플로를 — 청구, 캘린더 관리, 고객 메시징을 — 추가하고 있다면, 핵심을 확장하는 게 아니라 곁가지 기능을 덧대는 겁니다. 그건 다른 제품을 만들고 있다는 신호이고, 재작성을 뜻합니다.

같은 핵심의 변형을 — “개인용 접수, 팀용 접수, 맞춤 필드가 있는 접수”를 — 추가하고 있다면, 여전히 같은 앱입니다. 리팩터링하고 확장하세요.

질문 2: 오늘 리팩터링하면, 마찰이 다시 닥치기까지 몇 달인가?

솔직하세요. 마찰이 6개월 동안 사라진다면, 리팩터링이 옳은 수입니다. 문제가 코드 모양이 아니라 토대 자체라서 2개월이면 다시 아파 온다면, 재작성이 두 번 기우는 거짓 절약을 면하게 해 줍니다. AI 빌더에게 물으세요: “이걸 정리하면, 다시 이걸 해야 하기까지 얼마나 걸려?” 답이 “아마 오래 안 걸려요”라면, 다시 지을 때입니다.

질문 3: 사용자들이 실제로 무엇에 의존하고 있는가?

v1에 활성 사용자가 셋인데 재구축을 생각 중이라면, 하루 이틀이면 옮길 수 있습니다. 현재 앱에 프로덕션으로 의존하는 사용자가 쉰이라면, 재작성은 몇 달 동안 두 버전을 다 굴려야 한다는 뜻이고, 그건 그 나름의 고통입니다.

보통 통하는 길

성공적으로 다시 짓는 창업자 대부분은 그것을 병행으로 합니다: 원래 앱을 계속 돌리면서, 남는 여력으로 새것을 짓습니다. 새것이 옛것과 기능이 같아지면, 일주일을 들여 데이터와 사용자를 옮기고, 끝냅니다.

보통 안 통하는 길: 리팩터링, 리팩터링, 리팩터링, 그러다 세 번째 리팩터링쯤에 아키텍처가 여전히 틀렸음을 깨닫는데, 이제는 “옛” 버전에 너무 많이 투자해서 인정하고 새로 시작할 수가 없는 상태가 되는 것.

결정할 적기

다음번에 마찰을 느끼거든, 스스로에게 물으세요: “나는 이 앱이 하기로 되어 있던 일을, 더 잘하게 만들고 있는 건가? 아니면 애초에 설계되지 않은 무언가가 되라고 요구하고 있는 건가?” 전자라면, 리팩터링하세요. 후자라면, 처음부터 그것이 마땅히 됐어야 할 것을 짓는 데 부끄러울 게 없습니다. 성공한 앱 대부분은 핵심의 버전 1이 아니라 버전 2에 가 있습니다.