멀티 제품 vs 한 제품 집중 — 내가 고른 균형

책상 앞에 앉아 오늘 할 일을 적다가 멈칫했다. 목록 맨 위엔 앱 버그 수정, 그 아래엔 블로그 글, 또 그 아래엔 다른 앱의 출시 준비가 있었다. 세 가지가 한 사람의 하루에 나란히 적혀 있었다.

그 순간 두 목소리가 동시에 들렸다. 하나는 *"한 우물만 파라"*고 했고, 다른 하나는 *"여러 베팅을 걸어라"*고 했다. 둘 다 어디선가 읽은 조언이었고, 둘 다 옳아 보였다. 그런데 이 둘은 정반대를 가리켰다. 나는 한쪽을 골라야 했다. 이 글은 그 선택에 대한 기록이다.

내가 지금 동시에 굴리는 것들

먼저 내 책상 위의 실상부터 적는다. 지금 나는 앱과 블로그를 합쳐 여러 개를 동시에 운영한다.

• 앱 — App Store에 라이브로 도는 GentleDo가 있고, 같은 결의 형제 앱 몇 개가 뒤를 따른다
• 블로그 — AI 도구를 다루는 채널, 이 글이 올라가는 저널, 그리고 한국 플랫폼용 에디션

이걸 왜 멀티라고 부르냐 하면, 각각이 별개의 시계로 돈다는 뜻이다. 앱은 앱대로 심사·업데이트 주기가 있고, 블로그는 블로그대로 발행·색인 주기가 있다. 하나를 멈춰도 나머지는 굴러간다. 어쩌다 보니 이렇게 됐다기보다, 역할을 의도적으로 나눈 결과다 — 이 분리의 사연은 3개 브랜드를 역할 기준으로 쪼갠 이유에 따로 적어뒀다.

문제는 이 구조가 공짜가 아니라는 것이다.

멀티의 장점 — 그리고 숨은 비용

여러 개를 굴려서 좋은 점은 분명하다.

첫째, 리스크가 분산된다. 한 채널이 검색 알고리즘이나 플랫폼 정책으로 흔들려도 나머지가 받쳐준다. 1인에게 채널 하나에 전부 거는 건 생각보다 위험하다. 둘째, 시너지가 있다. 앱을 만들며 배운 걸 글로 쓰고, 그 글이 다시 앱을 아는 사람을 데려온다. 한 작업의 부산물이 다른 작업의 재료가 된다.

그런데 이 장점들 밑에는 조용한 비용이 깔려 있다. 주의력의 분산이다.

시간은 쪼개면 그만이다. 오전은 앱, 오후는 글. 깔끔하게 나뉜다. 그런데 집중은 쪼개지지 않는다. 앱 버그를 고치다 글로 넘어가면, 머릿속엔 아직 그 버그가 떠다닌다. 전환할 때마다 맥락을 다시 쌓는 세금을 낸다. 하루를 세 토막 내면, 세 번 다 "처음으로 깊이 들어가는 그 순간"을 놓친다.

시간은 나눠지지만 주의력은 나눠지지 않는다 — 이게 멀티의 진짜 가격이다.

집중이 옳은 경우 vs 멀티가 옳은 경우

그래서 한참을 고민하다 내린 잠정 결론은, 둘 중 하나가 늘 옳은 게 아니라는 것이었다. 상황이 답을 정한다.

집중이 옳은 경우.

• 제품이 아직 검증되지 않았을 때 — 사람들이 정말 원하는지 모르는 단계에서 둘로 나누면, 둘 다 어중간하게 죽는다
• 한 제품이 막 불붙기 시작할 때 — 수요의 신호가 보이면 거기에 전부 부어야 한다. 이때 다른 데 눈 돌리는 건 죄에 가깝다
• 내가 그 분야를 아직 모를 때 — 깊이 없이 넓게 벌리면 어디서도 전문성이 안 쌓인다

멀티가 옳은 경우.

• 각 제품이 다른 역할을 할 때 — 하나는 검증용, 하나는 자산용처럼 목적이 갈리면, 합치는 게 오히려 어색하다
• 작업이 자산화될 때 — 글 한 편, 기능 하나가 시간이 지나도 계속 일하는 종류라면, 여러 개를 쌓아두는 복리가 크다
• 운영을 자동화로 깔아놨을 때 — 발행·배포·자산 생성이 파이프라인으로 묶여 있으면, 멀티의 운영비가 감당 가능한 수준으로 내려간다

마지막 조건이 핵심이다. 자동화 없이 제품만 늘리면, 운영비에 깔려 전부 방치된다. 멀티는 자동화를 전제로만 성립한다.

내가 지금 택한 균형

그래서 나는 순수한 한쪽을 고르지 않았다. 대신 층을 나눴다.

• 하루 안에서는 집중한다. 한 블록엔 한 가지만. 오전에 앱을 잡으면 오전엔 앱만, 글은 머릿속에서 지운다. 전환 세금을 줄이는 유일한 방법은 전환 횟수 자체를 줄이는 것이었다.
• 분기 안에서는 멀티로 굴린다. 길게 보면 앱도 블로그도 함께 자란다. 다만 동시에 무게를 싣지는 않는다. 한 시즌엔 하나가 주연, 나머지는 유지보수.

말하자면 시간 단위로는 집중, 분기 단위로는 멀티다. 이게 "한 우물"과 "여러 베팅" 사이에서 내가 찾은 절충이다. 두 조언 다 맞았다 — 다만 적용되는 시간 축이 달랐을 뿐이다. 한 우물은 하루에, 여러 베팅은 연에 적용된다.

이 균형이 가능한 이유는, 내가 무엇을 주연으로 둘지를 매번 명시적으로 고르기 때문이다. 그 선택의 기준은 SaaS 아이디어를 고르고 버리는 프레임워크에 정리해둔 것과 같다 — 지금 검증이 필요한 게 무엇인가를 묻고, 거기에 분기의 무게를 싣는다. 실제로 이 구조가 하루 단위로 어떻게 돌아가는지는 3개를 동시에 운영하는 하루에 시간표까지 적어뒀다.

다음 계획

지금의 균형이 정답이라고 생각하진 않는다. 솔직히 분기 단위 멀티조차 가끔 버겁다. 그래서 다음 분기엔 한 가지를 실험해볼 생각이다 — 주연을 더 과감하게 하나로 좁히는 것. 지금은 두세 개에 얕게 무게를 나누는데, 한 시즌 동안 하나에만 70%를 붓고 나머지는 완전한 유지보수로 내려보면 어떻게 되는지 보고 싶다.

그게 더 빨리 무언가를 터뜨리는지, 아니면 나머지가 방치돼 무너지는지 — 해봐야 안다. 1인 빌더의 답은 책이 아니라 내 책상 위에서 나오니까.

멀티냐 집중이냐를 고르던 그날의 나는 둘 중 하나를 찾고 있었다. 지금의 나는 둘을 어느 시간 축에 배치할지를 묻는다. 질문이 바뀌니 답이 보였다. 어쩌면 1인 빌더에게 필요한 건 정답이 아니라, 더 나은 질문 하나인지도 모른다.

그거면 일단 다음 분기는 굴러간다고, 오늘은 생각한다.