Gency · API 개발자 센터 0→1, 제품을 플랫폼으로 확장
콘텐츠 생성 SaaS를 API 채널로 확장하고, 구서비스 고객사의 플랫폼 이관까지 만든 신규 채널 구축기
젠시의 콘텐츠 생성 기능을 외부 시스템에서 호출해 쓸 수 있는 API로 제공. 웹 SaaS를 플랫폼으로 확장하는 채널을 PRD 설계부터 운영 배포, 고객 이관까지 리드.
문제 정의
젠시는 웹 SaaS로 국내 검증을 마쳤지만, 자체 시스템(자사몰·백오피스·운영 툴)에 콘텐츠 생성을 임베드하려는 고객 세그먼트는 웹 UI로는 커버할 수 없음. 이 API 고객 세그먼트는 전사 리소스의 19%를 배분한 전략 트랙인데, 기술 기반이 없어 세그먼트 자체가 열리지 않는 상태였음.
UI 없는 제품을 팔려면 인증·과금·비동기 처리·문서까지 '개발자 경험' 전체를 하나의 제품으로 설계해야 함. 수십 초가 걸리는 AI 생성 작업을 어떤 API 계약으로 제공할지, 웹의 크레딧(젠) 과금을 API 호출 단위로 어떻게 일관되게 옮길지가 관건이었음.
해결 전략 · 어떻게 풀기로 했나
AI 생성의 레이턴시를 그대로 인정한 비동기 + Webhook 계약
AI 콘텐츠 생성은 동기 응답이 불가능한 작업. 폴링 부하 대신 '요청 접수 → 비동기 생성 → Webhook 콜백' 구조로 계약을 설계해 고객 시스템이 젠시의 생성 시간을 기다리지 않고 자기 워크플로우에 임베드할 수 있게 함.
웹과 API가 같은 화폐를 쓰는 단일 과금 체계
API 전용 플랜을 신설하는 대신 웹 SaaS의 크레딧(젠) 과금을 API 호출 단위에 그대로 이식. 채널이 늘어도 과금 체계는 하나로 유지해 정산·CS 복잡도를 막고, 웹과 API를 오가는 고객 여정(구서비스 이관 포함)의 기반을 만듦.
실행 · 내가 직접 한 일
각 카드의 태그는 자율 주도 · 이해관계자 · 본질 구조화 중 어떤 역량을 요구한 일이었는지 표시합니다.
REST API · 비동기 생성 · Webhook 아키텍처 PRD 설계
자율 주도생성 요청·상태 조회·결과 콜백의 API 계약과 크레딧 단위 과금 구조를 PRD로 직접 설계(2026.02). 기획 2개월 만인 2026.04에 운영 배포.
개발자 센터 웹과 공식 문서로 셀프서브 DX 완성
본질 구조화OAuth 인증과 API 키 관리를 갖춘 개발자 센터 웹, GitBook 공식 개발자 문서까지 갖춰 운영 런칭. 문서만 보고 연동을 끝낼 수 있는 셀프서브 개발자 경험을 기준으로 잡음.
위비스 이관, 구서비스 고객을 플랫폼으로
이해관계자자사 구서비스 '셀러캔버스'를 쓰던 패션 기업 위비스가 이 API를 이용해 젠시로 이관 진행 중. 고객사 안내와 전환 관리를 직접 수행. API 채널이 신규 수주 외에 기존 고객 자산을 신제품으로 옮기는 통로도 된다는 걸 확인.
성과 · 수치와 그 의미
2026.02 기획, 2026.04 운영 배포. 아키텍처·과금·DX를 PRD 단계에서 확정해 개발 사이클의 재작업을 최소화.
구서비스(셀러캔버스) 고객사가 API 기반으로 젠시 이관 진행. 플랫폼 확장이 실제 고객 이동으로 이어진 첫 사례.
자체 시스템에 생성을 임베드하려는 API 고객 세그먼트의 기술 기반 완성. 세그먼트 전략이 실행 가능한 상태가 됨.
사용한 도구·스킬
배운 점
제품의 API화는 결국 인증·과금·문서·지원까지 '개발자를 위한 제품' 하나를 새로 만드는 일이었다. 웹과 API가 같은 크레딧 화폐를 쓰게 한 결정 덕에 과금 복잡도가 늘지 않았고, 구서비스 고객 이관이라는 계획에 없던 성장 경로도 생겼다.