사이드 제품 여러 개를 병행하는 법 — 기능 말고 킬 조건

제품 여러 개를 동시에 굴리는 문제를 저는 오랫동안 시간 배분 문제로 봤습니다. 아니었어요.

노트북에 창이 여러 개 열려 있습니다. 한쪽은 회원가입 문구를 고치다 멈췄고, 다른 쪽은 결제 화면을 붙이는 중이고, 또 다른 쪽에는 새 기능 아이디어가 적혀 있어요. 가장 급한 일을 고르려고 탭을 오가다 보면 어느새 제일 쉬운 화면 하나를 다듬고 있고요.

저녁이 되면 많이 일한 것 같습니다. 그런데 질문 하나에 답이 막혀요.

"그래서 오늘 어떤 제품이 앞으로 갔어요?"

코드는 늘었고 화면은 예뻐졌지만, 출시해야 할 제품이 출시된 것도 아니고 실제로 돈을 낼 사람이 확인된 것도 아닙니다. 세 제품 모두 조금씩 좋아졌고, 어느 제품도 다음 판단에 도착하지 못했어요.

저도 이 문제를 시간표로 풀려고 했습니다. 요일을 나누고, 오전과 밤에 다른 제품을 배정하고, 할 일을 색으로 구분했어요. 일정은 정돈됐는데 미완성 제품이 정돈된 채로 늘어났습니다. 병행이 무너지는 건 시간이 똑같이 안 나뉘어서가 아니었어요. 각 제품에서 무엇을 확인하면 이번 단계가 끝나는지, 무엇이 나오지 않으면 멈출지가 없었기 때문입니다.

그래서 다시 세운 기준은 단순합니다. 제품마다 이번에 답할 질문 하나와, 답이 없을 때 닫을 조건 하나를 둔다.

일정표보다 제품의 경계를 먼저 긋습니다

제품이 여러 개면 화면 이름만 다른 게 아니에요. 사용자, 계정, 결제, 데이터, 배포 장소가 다를 수 있습니다. 그런데 만드는 사람 머릿속에서는 "내 제품들"로 뭉뚱그려져 있죠. 이때 편하다는 이유로 같은 설정과 장부를 공유하면 한 제품의 변경이 다른 제품까지 건드립니다.

비개발자인 저는 이 위험을 화면이 깨지는 일로만 생각했어요. 실제로 더 무서운 건 화면은 멀쩡한데 사용자 정보나 권한의 경계가 흐려지는 일이었습니다. 한 제품의 가입 규칙을 고쳤는데 다른 제품의 가입 방식이 달라지고, 결제 상품 이름을 바꿨는데 엉뚱한 화면에 뜨는 식이죠.

그래서 새 일을 시작하기 전에 종이에 경계를 적습니다.

• 이 변경은 어느 제품만을 위한 것인가
• 함께 쓰는 계정이나 데이터가 있는가
• 다른 제품의 가입·결제·삭제를 다시 확인해야 하는가
• 되돌릴 방법이 있는가

기술 용어를 몰라도 질문은 할 수 있어요. "이 버튼을 바꾸면 다른 제품 손님에게도 보이나요?"라고 물으면 되니까요. 비개발자가 처음 밟는 제품 함정은 화면보다 보이지 않는 경계를 먼저 확인해야 했던 장면을 다룹니다.

경계를 긋는다고 모든 걸 따로 만들라는 뜻은 아니에요. 같은 도구를 써도 됩니다. 다만 무엇을 공유하고 무엇을 분리했는지 알고 있어야 해요. 모른 채 공유하는 것과 이유를 알고 공유하는 건 완전히 다릅니다.

제품마다 이번 검증 질문은 하나만

한 제품은 "처음 보는 사람이 설명 없이 첫 행동을 끝낼 수 있는가"를 보고 있을 수 있어요. 다른 제품은 "실제로 돈을 내고 계속 쓰는 사람이 있는가"가 질문일 수 있고요. 또 다른 제품은 "민감한 표현 없이 가치를 전달할 수 있는가"를 먼저 봐야 할 수도 있습니다.

질문이 다른데 모두에게 "기능 완성"이라는 같은 목표를 주면 쉬운 기능이 이깁니다. 버튼을 하나 추가하면 완료한 느낌이 나지만, 결제 의향이나 반복 사용은 불편한 답을 주거든요.

그래서 작업 목록 맨 위에 기능이 아니라 질문을 적습니다.

"이번 주에 이 제품에서 무엇을 알아내면 다음 결정을 할 수 있나?"

그 아래에는 그 질문에 필요한 최소 행동만 둡니다. 사용자가 첫 화면에서 막히는지 보려면 새 기능이 아니라 관찰과 수정이 필요해요. 결제를 확인하려면 무료 기능을 늘리는 대신 실제 제안과 결제 동선을 점검해야 하고요.

기능보다 중요한 것과 결제를 붙이며 배운 것을 보면, 기능이 보인다고 신뢰와 결제가 끝난 게 아니라는 점이 이어집니다.

킬 조건은 제품을 미워하는 문장이 아닙니다

킬 조건이라고 하면 냉정하게 제품을 버리는 기준처럼 들려요. 그래서 만들기 전에 정하지 않으면, 애정을 쏟은 뒤에는 계속 미루게 됩니다.

"조금만 더 다듬으면 반응이 올 거야."

"홍보를 제대로 안 했으니 아직 실패는 아니야."

"이 기능이 없어서 결제를 안 한 걸 수도 있어."

전부 가능성은 있어요. 문제는 가능성에 끝이 없다는 겁니다. 그래서 킬 조건에는 기간만 쓰지 않고 무엇을 시도할지도 같이 적어요. 누구에게 어떤 제안을 몇 번 했는지 같은 숫자를 공개 원칙으로 만들 필요는 없지만, 내부에서는 시험 범위가 있어야 합니다. 시도하지 않고 기다린 시간을 검증 기간으로 부르면 안 되니까요.

그리고 결과는 "삭제"만이 아니에요. 동결, 범위 축소, 다른 기능에 흡수, 유지보수만 하기, 다시 검증할 조건을 정하고 닫기처럼 여러 상태가 있습니다. 접은 기능들과 이유에는 접는 일이 실패 보고가 아니라 다음 집중을 만드는 과정이라고 적어 뒀어요.

저는 킬 조건을 제품의 가치를 판결하는 문장으로 쓰지 않습니다. 지금 가진 시간과 유통 능력으로 이 가설을 계속 시험할 이유가 있는지 결정하는 문장으로 써요. 나중에 조건이 달라지면 다시 열 수 있고요. 다만 다시 여는 조건도 적어 두지 않으면 "언젠가"라는 이름으로 계속 머릿속 자리를 차지합니다.

병행을 두고 흔히 하는 말들

"여러 제품을 병행하면 위험이 분산된다." 한 제품이 안 될 때 다른 제품이 기회를 준다는 점에서는 맞을 수 있어요. 서로 다른 시장을 시험하며 배울 수도 있고요. 하지만 혼자 관리하는 자원과 관심은 함께 쪼개집니다. 모든 제품이 같은 유통 부족, 같은 검증 회피, 같은 운영 실수를 공유한다면 위험이 분산된 게 아니라 복제된 거예요. 제품 수만으로 포트폴리오가 되지는 않습니다. 말할 수 있는 데까지 줄이면, 서로 다른 가설을 작은 비용으로 시험할 때 병행의 의미가 있고 검증 없이 기능만 늘릴 때는 미완성만 늘어납니다.

"요일만 나누면 집중할 수 있다." 요일 분리는 전환 비용을 줄여 줍니다. 오늘 무엇을 열지 고민하는 시간도 줄여 주고요. 저도 여전히 일정 구분을 씁니다. 다만 일정표는 우선순위를 만들지 못해요. 월요일 제품의 킬 조건이 없으면 월요일 내내 쉬운 작업을 하게 됩니다. 그래서 달력에는 제품 이름보다 이번 판단을 적는 편이 나았어요. "가입 완료 확인", "실결제 제안", "삭제 흐름 재검증"처럼요. 일정 관리 자체가 목적이 되는 장면은 바쁜 일로 하루가 끝나는 이유와도 이어집니다.

"유료 고객이 없으면 기능이 부족한 것이다." 정말 핵심 기능이 빠져서일 수 있어요. 하지만 고객을 만나 제안하지 않았거나, 누구 문제를 푸는지 전달하지 못했거나, 결제 과정이 믿기 어려워서일 수도 있습니다. 이유를 듣지 않고 기능 부족으로 번역하면 만드는 일만 끝없이 계속돼요. 그렇다고 고객 말 한마디에 방향을 전부 바꾸라는 뜻은 아닙니다. 말보다 실제 사용과 결제 행동을 함께 봐야 해요. 다음 제품에서 다르게 할 것은 확인 전의 낙관을 완료로 세지 않는 태도를 다룹니다.

"킬 조건을 걸면 큰 비전을 못 만든다." 비전은 오래 볼 방향을 주고 킬 조건은 지금 단계의 비용을 제한합니다. 둘은 반대가 아니에요. 오히려 작은 검증을 통과하지 못한 제품에 큰 비전을 계속 얹으면, 비전이 현실을 안 보는 핑계가 됩니다. 물론 이걸 단기 수익이 없는 모든 제품을 버리라는 말로 읽으면 안 돼요. 신뢰, 안전, 기반 작업처럼 시간이 필요한 것도 있으니까요. 그래서 킬 조건은 제품마다 달라야 하고, 지금 수익이 아니라 다음 검증 단계에 도착했는지로 판단할 수도 있습니다.

새 기능보다 열린 문을 먼저 닫습니다

제품을 병행하다 보면 완료하지 않은 운영 문이 늘어납니다. 테스트 결제, 문의 답변, 개인정보 삭제, 앱 심사, 오류 확인처럼 사용자가 이미 만나고 있는 문들이에요. 새 기능은 재미있지만 열린 문을 방치하면 기존 사용자가 먼저 다칩니다.

그래서 새 기능을 시작하기 전에 이미 열린 문을 적어요. 실제 사용자가 들어오는가, 돈이 오가는가, 민감한 정보가 있는가, 다른 제품과 연결되는가. 위험이 큰 문부터 닫습니다. AI에게 코딩을 시킬 때 어려운 것도 "만들었다"와 "끝났다" 사이에 검증 문장이 필요하다는 이야기였어요.

제품을 잠시 동결할 때는 상태를 남깁니다. 마지막으로 확인한 것, 남은 문제, 다시 열 조건, 사용자에게 약속한 운영. 기억 속에만 동결하면 몇 달 뒤 같은 조사를 다시 하고 같은 함정을 또 밟아요.

그리고 한 제품의 실험을 다른 제품의 근거로 자동 복사하지 않습니다. 한 시장에서 통했던 가격이나 문구가 다른 사용자에게도 맞는다고 볼 수 없으니까요. 공유할 수 있는 건 검증 방식이지 결과 자체가 아닙니다.

제품마다 한 장씩 두는 병행 카드

• 지금 답할 질문
• 이번에 할 가장 작은 시험
• 사용자에게 이미 한 약속
• 다른 제품과 맞닿은 경계
• 멈추거나 동결할 조건
• 다시 열 수 있는 조건

작업 목록은 이 카드 아래에만 만듭니다. 질문과 연결되지 않는 기능 아이디어는 별도 보관함으로 옮겨요. 버린 건 아니지만 이번 단계의 일은 아니니까요.

현장이 있는 사람이 도구를 만들 때처럼 아이디어가 계속 생기는 환경에서는 특히 이 구분이 필요합니다. 현장의 불편 하나를 발견할 때마다 새 제품으로 만들면 제품 수가 문제 수만큼 늘어나거든요. 기존 제품 안에서 해결할지, 운영으로 풀지, 정말 별도 제품이어야 하는지 먼저 물으세요.

병행의 기술은 모든 제품을 조금씩 전진시키는 기술이 아니었습니다. 이번에 답하지 않을 질문을 닫고, 답이 나오지 않은 제품을 멈추고, 이미 열린 제품의 약속을 지키는 기술에 더 가까웠어요.

짧은 문답

결국 한 제품에만 집중해야 하나요?

항상 그렇다고 말할 수는 없습니다. 다만 제 경험으로는 혼자 관리할 때 동시에 진행 중인 제품이 두 개를 넘어가면, 셋째 제품부터는 그 주의 검증 질문에 하나도 답을 못 낸 채 넘어가는 일이 잦았어요. 몇 개까지가 맞는지는 사람마다 다르겠지만, 늘려 보고 답이 막히는 지점을 직접 찾아보시길 권합니다.

킬 조건은 언제 정해야 하나요?

기능을 더 붙이기 전, 아직 제품에 대한 애정과 비용이 커지기 전에 정하는 편이 낫습니다. 이미 운영 중이라면 지금까지의 시도를 적고 다음 시험 한 번에 대한 종료 조건부터 만들 수 있어요.

동결한 제품의 사용자는 어떻게 하나요?

동결은 방치가 아닙니다. 이미 약속한 기능, 결제, 데이터 보관과 삭제, 문의 대응을 어떻게 유지할지 먼저 정해야 해요. 그 책임을 다룰 수 없다면 신규 유입을 더 받지 않는 판단도 필요합니다.