시장을 보는 눈 — 1인 개발자의 가벼운 검증과 '대체재' 측정법

이 글은 전자책 「혼자 만든 트립픽」 3장을 기술 블로그 톤으로 다시 풀어 쓴 글입니다. 책은 회고·내러티브 중심, 이 시리즈는 의사결정의 기술적 근거를 더 깊이 다룹니다.

1장에서 트립픽이 푸는 문제를 정의했고, 2장에서 "혼자"라는 제약이 아키텍처를 어떻게 지배했는지 봤어요. 이번 장의 질문은 더 근본적입니다.

"이거, 만들 가치가 있긴 한가?"

첫 번째 실패 — 레드오션 한구석 노리기

처음엔 교과서대로 했어요. 남들의 불편에서 아이디어를 찾는 것.

출발점은 어디선가 본 한 문장이었습니다. "1인 개발자는 레드오션의 한쪽 구석, 거인들이 미처 눈치채지 못하는 자리에서 살아남을 수 있다." 그래서 가장 레드오션이라는 영역을 골랐어요 — PDF 변환 + 데이터 분석·보고서 자동 생성 웹 서비스. 수요가 확실하고, 사람들이 분명히 돈을 쓰는 시장이었죠.

그런데 만드는 내내 "이게 맞나" 싶었어요. 이미 비슷한 서비스가 너무 많았고, 나는 내가 잘 모르는 분야의 불편을 머리로만 짐작하고 있었습니다.

좋아서 시작한 일이었는데, 어느 순간 직장에서 어쩔 수 없이 야근하는 것과 똑같이 느껴졌어요. 즐겁지가 않았습니다.

검증 질문을 바꾸다 — pain point가 아니라 happy point

그래서 마음을 정했어요. "비즈니스고 뭐고, 일단 내가 만들고 싶은 걸 하자." 다시 내가 만들면 신나는 것에서 출발하기로. 그게 제주의 변덕스러운 날씨와 즉흥적인 동선이었어요.

흔히 "남의 pain point를 풀어야 사업이 성공한다"고 하죠. 맞는 말이에요. 하지만 1인 개발자에겐 전제가 하나 더 필요합니다.

끝까지 살아남아 완성해야 성공이고, 즐겁지 않으면 끝까지 못 간다.

그래서 나는 의도적으로 내 happy point를 먼저 골랐어요. 사업적으로 정석이 아닐 수 있어요. 하지만 혼자 밤을 새우게 만드는 연료는 시장 분석이 아니라 "이거 만드는 게 재밌다"는 감각이었습니다.

이건 모두에게 권하는 공식이 아니라 혼자 오래 버텨야 하는 사람의 현실적 선택이에요. 동기가 끊기면 1인 프로젝트는 그냥 멈추니까요.

무거운 시장조사 대신, 공짜 신호 읽기

1인에게 수천만 원짜리 시장조사는 사치예요. 대신 공짜로 읽을 수 있는 신호를 모았어요.

• 검색의 흔적: "제주 비올 때", "제주 우천 코스", "제주 실내" 같은 검색이 꾸준한가. 사람들이 이미 답을 찾아 헤매고 있다면 시장이 있다는 증거.
• 커뮤니티의 푸념: 여행 카페에 "동선 어떻게 짜요?", "비 와서 일정 다 틀어졌어요" 같은 글이 반복되는가.
• 경쟁의 빈틈: 기존 앱은 장소 추천까지만 한다. 날씨 + 동선을 함께 푸는 곳은 드물었다.

신호는 "확신"을 주지 않아요. 다만 "이 방향으로 한 발 더 가도 된다"는 허락 정도는 줍니다. 1인 창업에서 필요한 건 100%의 확신이 아니라, 다음 한 걸음을 뗄 만큼의 근거예요.

진짜 경쟁자는 "그냥 직접 하기"였다

여기서부터가 기술적으로 중요해요. 트립픽의 진짜 경쟁자는 다른 여행 앱이 아니었어요. 블로그 검색 + 지도 앱 + 머릿속 계산이라는, 사람들이 지금 쓰는 공짜 조합이었습니다.

사용자는 "트립픽 vs 다른 앱"으로 고민하지 않아요. "트립픽을 쓸까, 그냥 블로그 보고 내가 짤까"로 고민합니다. 그래서 트립픽이 이겨야 할 상대는 경쟁사가 아니라 "그냥 직접 하기"의 번거로움이었어요.

문제는 — "번거로움을 이겼다"를 어떻게 아는가? 막연한 느낌이 아니라 측정 가능한 지표가 필요했어요. 그래서 이 추상적인 기준을 구체적인 이벤트로 쪼갰습니다.

// "직접 하기보다 편한가"를 측정 가능한 행동 신호로 분해
type FunnelEvent =
  | "course_generated"   // 코스를 만들었다 (최소한의 가치 도달)
  | "course_saved"       // 저장했다 = "이거 쓸 만하다" 신호
  | "course_shared"      // 공유했다 = 남에게 보여줄 만큼 만족
  | "pass_purchased"     // 결제했다 = 번거로움을 이긴 결정적 증거
  | "regenerated";       // 다시 생성 = 첫 결과가 불만족이었다는 신호

이 이벤트들을 EventLog 테이블에 쌓아두면, "직접 하기를 이겼는가"라는 질문이 전환율 숫자로 바뀝니다.

// 생성 → 저장 → 결제로 이어지는 깔때기를 숫자로 본다
async function conversionFunnel(from: Date, to: Date) {
  const events = await db.eventLog.groupBy({
    by: ["type"],
    where: { createdAt: { gte: from, lte: to } },
    _count: true,
  });
 
  const n = (t: string) =>
    events.find((e) => e.type === t)?._count ?? 0;
 
  const generated = n("course_generated");
  return {
    generated,
    saveRate: ratio(n("course_saved"), generated),     // 저장 전환
    payRate: ratio(n("pass_purchased"), generated),    // 결제 전환
    redoRate: ratio(n("regenerated"), generated),      // 불만족 신호
  };
}

saveRate가 낮으면 결과물이 직접 짠 것보다 안 낫다는 뜻이고, redoRate가 높으면 첫 코스 품질이 모자라다는 뜻이에요. 추상적인 "시장성"이 매일 들여다볼 수 있는 계기판이 됐습니다.

1인 개발에서 측정은 사치가 아니라 생존 도구예요. 사용자에게 일일이 물어볼 수 없으니, 행동이 대신 말하게 만들어야 합니다. 저장·결제·재생성 같은 행동 하나하나가 "직접 하기보다 편한가?"에 대한 사용자의 투표예요.

이 EventLog는 나중에 기능 우선순위를 정하는 나침반이 됩니다 — 직접 하기보다 확실히 편한가? 그렇지 않은 기능은 과감히 뺐어요(4장 예정).

작게, 그러나 돈 받는 구조로

검증의 마지막 조각은 "돈"이었어요. 무료면 다들 좋다고 합니다. 진짜 시장은 지갑이 열릴 때 확인돼요.

그래서 트립픽은 처음부터 결제 구조를 넣되, 제주 여행의 본질에 맞췄어요. 월 구독이 아니라 여행 기간만큼 쓰는 일회성 패스(1일/3일/7일). 단기 여행자에게 월 구독은 부담이지만, "여행 한 번에 900원부터"라면 부담 없이 질러볼 만한 제안이었죠. (이 결제 모델 설계는 11장 예정.)

위 깔때기에서 payRate 하나가, 다른 모든 신호를 종합하는 최종 판정선이에요. 저장도 공유도 결국 결제로 이어지지 않으면 "좋아하지만 돈은 안 내는" 시장이라는 뜻이니까요.

틀릴 수도 있다는 전제

솔직히 시장 판단은 지금도 진행형이에요. 베타로 내보내고, 실제 사용자 반응을 보고, 틀렸으면 고치는 것 — 그게 1인이 시장을 검증하는 가장 정직한 방법입니다. 책상 위의 확신보다, 세상에 내놓고 받는 한 번의 피드백이 더 정확해요. 그래서 EventLog를 처음부터 박아둔 거예요. 내 추측이 아니라 데이터가 판정하도록.

다음 장 미리보기

다음 장(4장 "MVP의 경계 긋기")에서는 이번 장의 나침반 — "직접 하기보다 확실히 편한가?" — 를 실제 기능 목록에 들이대는 이야기를 합니다. 무엇을 남기고 무엇을 과감히 뺐는지, 그 경계를 어떻게 그었는지를요.

💭 그때의 나에게: 너는 "확신이 서면 시작하자"고 했지. 근데 확신은 시작 전엔 절대 안 와. 작게 만들어 내보내야 그제야 시장이 대답을 해줘. 조사는 시작할 용기를 주는 정도면 충분했어. 그리고 — 즐겁지 않으면 넌 못 끝냈을 거야. happy point를 고른 건 도망이 아니라 전략이었어.