7개의 토끼굴, 3개의 나라
혼자서 그리는 지도
오늘도 퇴근 후 노트북을 열었다. 터미널의 검은 화면이 반긴다.
몇 달 전에는 이 화면이 낯설었다. 검은 바탕에 흰 글씨가 깜빡이는 것을 보면서 "내가 여기서 뭘 할 수 있는 거지?"라고 생각했다. 지금은 여전히 코드를 읽지 못하지만, 이 화면이 무섭지는 않다. 빨간 글씨가 나와도 당황하지 않는다. 당황하지 않는다는 것은, 그 글씨가 무엇을 말하고 있는지 알기 때문이 아니라, 그 글씨를 누군가에게 보내면 답이 온다는 걸 알기 때문이다.
하나의 서비스를 만드는 데 몇 주가 걸렸다. 설계문서를 쓰는 데 며칠, V2를 만드는 데 며칠, V2의 구조가 잘못됐다는 걸 알게 되는 데 며칠, V3를 다시 만드는 데 또 며칠. 배포하고, 에러를 고치고, 결제를 연동하고. 그 사이에 용어를 배우고, 도구 조합을 정하고, AI에게 일을 시키는 방법을 익혔다.
그런데 내가 만들고 싶은 서비스는 이것 하나가 아니다.
내 앞에 7개의 서비스가 놓여 있다. 그리고 각각을 한국, 일본, 영어권 세 나라에 내놓아야 한다. 7곱하기 3은 21이다. 논리적으로는 스물한 번의 론칭이 필요하다.
이 숫자를 처음 마주했을 때, 솔직히 비현실적으로 느껴졌다. 하나를 만드는 데 이렇게 시간이 걸렸는데, 스물한 개를 만든다고?
하지만 마스터 플랜을 AI와 함께 짜면서, 숫자만큼 비현실적이지는 않다는 걸 알게 됐다.
핵심은 — 첫 번째 서비스를 만들면서 배운 것들이 두 번째부터는 처음부터 적용된다는 것이다.
V2→V3 리팩터링에서 배운 교훈이 여섯 개 있다. 데이터베이스 테이블 누락, 모듈 간 인터페이스 불일치, 사용자 ID 부재, 설정값 하드코딩, 인증 설정 누락, 환경변수 불일치. 이 여섯 개는 다음 서비스를 만들 때 처음부터 체크리스트에 들어간다. 같은 실수를 두 번 할 필요가 없다.
"관제탑 + 빌더" 워크플로우도 이미 정립됐다. 새 서비스를 시작할 때마다 이 구조를 그대로 쓰면 된다. 설계는 관제탑에서, 실행은 빌더에서.
비용 모델링 방법론도 있다. AI 모델별 토큰 가격, 언어별 토큰 배수(일본어는 영어의 약 2배), 사용자 수 단계별 비용 시뮬레이션. 이걸 새 서비스에 그대로 적용할 수 있다.
이것들을 모아서 "개발 플레이북"이라는 문서를 만들었다. 새 서비스를 시작할 때 따라야 할 절차서. Phase 0에서 코드 한 줄 쓰기 전에 7개 질문에 먼저 답하라, Phase 1에서 설계문서 5종을 만들어라, Phase 2에서 핵심 모듈부터 순서대로 빌드하라. StackTube를 만들면서 겪은 삽질이 이 플레이북의 재료다.
마스터 플랜 문서는 751줄이 됐다. AI와 함께 하루 만에 작성했다. 7개 서비스 각각의 정의, 수익 구조, 기술 스택, 비용 시뮬레이션, 3개국별 차별화 포인트, 론칭 순서, 킬 크라이테리아.
킬 크라이테리아 — 이건 프로젝트를 중단할 기준선이다. "12주 내 100명 사용자 또는 월 $200 수익 미달 → 프로젝트 중단." 이 기준을 감정 없이 설정했다. 아직 론칭도 안 한 서비스에 중단 기준을 미리 정하는 게 이상해 보일 수 있다. 하지만 이걸 미리 정하지 않으면, 실패한 프로젝트에 끝없이 시간을 쏟게 된다. 저녁 시간밖에 없는 사람에게 시간은 가장 비싼 자원이다.
AI에게 에이전트 하네스 구조라는 걸 적용할 수 있는지도 물어봤다. AI가 스스로 계획하고, 생성하고, 검증하는 3단계 자동화 구조. 관제탑이 답했다. "가능하지만 지금은 과잉입니다. 론칭 전에 자동화를 과도하게 구축하면, 자동화를 디버깅하는 데 시간을 쓰게 됩니다."
AI의 이 조언을 수용했다. AI가 "하지 마라"고 할 때 듣는 것도 PM의 역할이다.
이제 되돌아보면, 이 여정에서 배운 건 코딩이 아니었다.
에러는 실패가 아니라 힌트다. 토글 하나, URL 하나, 설정 하나 — 대부분은 이 수준이다. 계획이 코드보다 먼저다. V2→V3 리팩터링에서 뼈저리게 배웠다. AI는 유능한 신입이지 마법사가 아니다. 잘 시키면 빠르지만, 전체 그림은 내가 잡아야 한다. AI의 답이 맞는지도 내가 확인해야 한다.
그리고 시간이 적으면 실수할 여유도 적다. 그래서 저녁 시간밖에 없는 사람은 오히려 더 전략적이 된다.
이 여정의 첫 번째 결과물은 StackTube라는 이름을 갖게 됐다. Stack은 쌓는다는 뜻, Tube는 유튜브. 흩어진 영상 지식을 쌓아올리는 파이프라인이다. 1편에서 내가 원했던 것 — "지난 2주간 내가 이 주제에 대해 뭘 배웠지?"에 답하는 도구 — 이 그것이다.
완벽하진 않다. 디자인이 AI가 만든 티가 난다. 에러 처리가 매끄럽지 않은 부분이 있다. 하지만 핵심 기능은 작동한다. 관심 채널을 등록하면 새 영상이 올라올 때마다 자동으로 분석하고, 여러 영상의 지식을 교차 분석한다.
만들었으면 내놓아야 한다. 완벽한 제품보다 론칭한 제품이 낫다 — 는 말은 어디서 많이 들었지만, 실제로 론칭 버튼을 누르는 건 다른 문제다. 내가 만든 것을 누군가에게 "써볼래?"라고 묻는 건, 처음 해보는 종류의 용기다.
누군가 물었다. "언제까지 할 거야?"
글쎄, 나도 모르겠다. 하지만 매일 저녁 9시에 터미널을 열 때마다, 어제보다는 조금 덜 삽질하고 있다는 걸 느낀다.
그리고 그게 꽤 괜찮은 진전이라고 생각한다.
🔧 이 에피소드의 기술 용어 해설
MRR (Monthly Recurring Revenue) 매달 반복적으로 들어오는 수익. 구독 모델의 핵심 지표. "이번 달 매출"이 아니라 "매달 안정적으로 들어오는 돈"을 뜻한다.
킬 크라이테리아 (Kill Criteria) 프로젝트를 중단할 기준선. 감정이 아닌 숫자로 미리 정해둔다. "12주 내 100명 못 모으면 접는다"처럼. 미리 정하지 않으면 실패한 프로젝트에 끝없이 시간을 쏟게 된다.
플레이북 (Playbook) 반복 가능한 실행 매뉴얼. 미식축구에서 온 용어로, "이 상황에선 이렇게 한다"는 규칙 모음. StackTube 경험을 플레이북으로 만들어두면 다음 서비스에서 같은 실수를 반복하지 않는다.
에이전트 하네스 (Agent Harness) Planner(계획) → Generator(생성) → Evaluator(검증)로 구성된 AI 자동화 구조. 현재는 사람이 Planner와 Evaluator를 겸하고 있지만, 궁극적으로는 AI가 세 역할을 모두 수행하는 구조를 지향한다.
토큰 (Token, AI 비용 맥락) AI가 텍스트를 처리하는 최소 단위. 대략 한국어 한 글자가 1~2토큰, 영어 한 단어가 약 1토큰. AI API 사용료는 처리한 토큰 수에 비례한다. 일본어는 영어 대비 약 2배의 토큰을 소모한다.
SSO (Single Sign-On) 한 번 로그인하면 여러 서비스에 모두 접속되는 구조. 구글 계정으로 Gmail, YouTube, Drive에 동시 로그인되는 것과 같다.