통합 마켓플레이스 — 우리가 *처음에 안 만든* 결정과, *지금 만든* 이유

CollabOps 첫 9개월에 한 결정 — 통합 마켓플레이스 안 만든다. 첫 launch 의 8개 기능을 4개로 줄일 때 마켓플레이스가 첫 cut 대상. 이유는 단순했다 — 고객이 요구하지 않았음.

12개월차, 그 결정을 뒤집었다. 마켓플레이스를 3분기 안에 출시 결정. 무엇이 바뀌었나.

처음 안 만든 4 이유

1. 사용자 < 100 — 마켓플레이스의 가치는 N×M (사용자×통합) 으로 자람. N 이 작으면 marketplace 가치 ≈ 0
2. 첫 통합 8개를 우리가 직접 만들 수 있음 — Slack, GitHub, GitLab, JIRA, PagerDuty, Datadog, Sentry, OpenTelemetry. 8개로 80% 의 사용 케이스 커버
3. 3rd party 통합의 책임 모호 — 통합이 깨졌을 때 우리 책임? 통합 작성자 책임? 답이 명확해야
4. API stability 가 부족 — 우리 API 가 분기마다 변경 중. marketplace 통합이 우리 API 변경마다 업데이트 필요 = 운영 부담

12개월차 뒤집은 4 이유

1. 사용자 ~150 — N 이 임계점 도달
2. 8개 통합을 우리가 직접 만든 후, 9~30번째 통합은 우리 비용 > 가치 — 작은 vendor 통합 (예: 한국 특정 monitoring 도구) 까지 우리가 짜면 시간 낭비
3. 고객사가 직접 통합 을 원함 — 고객사 SI 또는 internal team 이 자기 사내 도구와 통합 짜려는 요구 등장
4. 우리 API 가 상대적 안정 됨 — 분기 1회 변경 → 연 1회 변경. marketplace 도입의 premise 가 처음으로 만족

마켓플레이스의 3 결정

뒤집기로 결정한 후의 세부 결정:

결정 1 — 무엇이 marketplace 에 올라가나

선택 — 통합 만 (CollabOps ↔ 다른 도구). 다른 종류 (template, agent skill, theme) 는 별도 위치. 이걸 명확히 안 정하면 marketplace 가 모든 것을 담는 그릇 으로 진화.

결정 2 — who can publish

선택 — 3 단계:

• Verified — 우리가 직접 검증, 우리 도메인에서 호스팅
• Partner — 우리 파트너 회사가 만듦, 별도 호스팅 가능
• Community — 누구나 등록, unverified 라벨

각 단계의 약속 이 다름. Verified 는 24시간 응답 SLA, Community 는 as-is.

결정 3 — 수익 분배

선택 — 처음 12개월 무료. 그 후 유료 통합 출시 시 결정. 처음에 수익 모델 박으면 생태계 형성 자체 가 막힐 위험.

marketplace 의 진짜 KPI

marketplace 의 KPI 는 통합 개수 가 아니다. 통합 개수가 늘면 자동으로 KPI 가 따라온다고 가정하는 게 흔한 실수.

진짜 KPI:

• 각 통합의 활성 사용자 수 — 통합 100개 중 90개가 사용자 0 이면 의미 X
• 통합 → 계약 전환 — 이 통합이 있어서 계약된 비율
• 통합 운영 SLA 준수 — verified 통합의 응답 시간

그래서 마켓플레이스는 언제 만들어야 하나

통합 마켓플레이스는 처음부터 만들지 말고, 4 조건 — 사용자 N 임계점, 직접 만들 수 있는 통합의 소진, 3rd party 책임 모델, API 안정성 — 이 모두 풀린 후 에 만들어야 한다. 우리 기준으로는 사용자 ~150, 직접 만든 통합 8개 이후였다. 마켓플레이스를 만들지 말지 결정 중인 product 리드라면 이 4 조건부터 점검. 처음부터 만들면 비어 있는 marketplace 가 역효과 다.