서비스 구축 체크리스트: 칸을 채우는 것과 검증하는 것

사업 기획 실무서를 펼치면 마지막 장에 늘 체크리스트가 나옵니다. 사업 아이디어, 기획 이유, 주요 고객, 핵심역량, 서비스 채널, 수익모델, 프로젝트 멤버. 칸을 채우면 계획이 완성된 것처럼 보입니다. 그런데 CB인사이트가 스타트업 실패 사례를 분석한 보고서를 보면, 이 칸을 다 채우고 서비스까지 낸 회사 중 42%가 "시장의 필요가 없었다"는 이유로 무너졌습니다. 자금 고갈이나 팀 문제보다 앞선 1위입니다(CB Insights 보고서).

이 숫자가 이상한 이유는, 저 실패한 회사들 대부분도 이 체크리스트와 비슷한 것을 한 번쯤 채워 봤을 것이기 때문입니다. 칸을 채우는 절차 자체는 잘 지켰는데 결과가 이럴 수 있다면, 문제는 절차가 아니라 그 칸에 뭐라고 적어야 정답인지를 판단하는 기준 쪽에 있습니다.

칸을 채우는 것과 검증하는 것은 다르다

저는 이 격차가 체크리스트의 형식 자체에서 나온다고 봅니다. 실무서의 칸은 전부 명사형 답을 요구합니다. 기획 이유는 한 문장, 핵심역량은 세 단어, 수익모델은 한 줄입니다. 칸을 채우면 검토가 끝난 것처럼 보이지만, 그 답이 왜 맞는지, 언제까지 맞는지, 무엇이 바뀌면 답이 달라지는지는 명사형 칸에 담기지 않습니다.

이 시리즈 열네 편이 각각 붙잡은 것이 그 나머지였습니다. SA 기획이 무엇을 정의하는지에서 시작해, 서비스와 마케팅과 운영 기획이 어떻게 갈리는지, 사업 기획의 빈틈은 어디서 나오는지, 수익모델과 채널과 팀 구성은 무엇으로 정해야 하는지, 그리고 그렇게 만든 것을 어떻게 넘기고 지키는지까지 이어졌습니다. 지금까지 다룬 내용을 원래 체크리스트의 순서에 겹쳐 놓으면, 같은 칸이라도 이 시리즈가 어디를 더 파고들라고 말했는지가 드러납니다.

1. 기획 이유는 당위성인가 벤치마크인가

기획 이유 칸에 가장 흔히 등장하는 문장이 "해외의 A 서비스가 성공했다"입니다. 당위성을 다룬 글에서 다룬 아이러브스쿨·프리챌·세이클럽·Quibi 넷 다 이 함정을 비켜 가지 못했습니다. 넷 다 인기를 모으는 데는 성공했지만 "누가 왜 돈을 내는가"에 답하지 못한 채 사람부터 모았습니다. 벤치마크의 성공은 그 시장이 존재한다는 근거일 뿐, 우리가 그 시장에서 돈을 벌 근거가 아닙니다. 앞서 언급한 CB인사이트의 42%가 바로 이 구분을 못 한 결과입니다.

Quibi가 가장 극단적인 사례입니다. 1.75조원을 투자받고 스타 파워까지 갖췄지만 6개월 만에 문을 닫았습니다. 창업자 제프리 카젠버그는 "단독으로는 이 비즈니스 모델이 더는 지속 가능하지 않다"는 말을 남겼습니다. 자본과 인지도로도 당위성 없는 사업을 살릴 수는 없다는 뜻입니다.

2. 주요 고객과 돈을 내는 고객이 같은가

당위성·고객·핵심요소를 다룬 글에서 다룬 슬랙의 사례가 이 구분을 보여줍니다. 슬랙은 원래 게임 '글리치'를 만들며 팀 내부용으로 쓰던 협업 도구였습니다. "사람들이 흩어진 채로 함께 일할 방법이 필요하다"는 당위성은 게임을 만들 때도 슬랙을 낼 때도 바뀌지 않았습니다. 바뀐 것은 고객이었습니다. 이 도구가 필요한 사람은 게임을 살 소비자가 아니라 팀 내부에서 매일 소통하는 사람들이었습니다. 당위성이 멀쩡해도 고객을 잘못 짚으면 3년, 수백만 달러를 엉뚱한 곳에 씁니다. 주요 고객 칸을 채울 때 "이 서비스를 쓰는 사람"과 "이 서비스에 돈을 낼 사람"을 같은 칸에 적어 버리면, 슬랙이 겪은 3년을 우리도 그대로 반복하게 됩니다.

같은 고객을 대하는 태도도 기획의 종류에 따라 갈립니다. 서비스 기획과 마케팅 기획을 다룬 글에서 짚었듯, 서비스 기획은 "무엇이 불편하세요"라고 묻는 데서 시작하고 마케팅 기획은 "이거 진짜 좋아요"라는 확신에서 시작합니다. 주요 고객 칸 하나에는 이 두 태도가 동시에 들어가야 하는데, 체크리스트는 한 줄만 요구합니다.

3. 핵심역량이 실제로 핵심 성공 요인인가

핵심역량 칸에는 대개 서너 개의 강점이 나열됩니다. 저는 이 나열 자체가 위험 신호라고 봅니다. 같은 글에서 다룬 존 F. 로카트의 핵심 성공 요인(Critical Success Factor) 이론의 핵심은 이 요인이 소수여야 한다는 데 있습니다. 1979년 하버드 비즈니스 리뷰 논문에서 그는 경영진 인터뷰를 통해 "이 일이 잘되려면 반드시 갖춰야 할 소수의 요소"만 뽑아내는 방법을 제시했습니다. 강점을 다섯 개, 여섯 개 나열한 계획일수록 정작 그중 무엇이 성패를 가르는지 아무도 모른다는 뜻입니다. 프리챌은 당위성도 고객도 있었지만, 핵심 성공 요인 하나, "공짜에 익숙해진 사용자를 이탈 없이 유료로 넘기는 방법"을 놓쳐 무너졌습니다. 2002년 전면 유료화를 밀어붙였다가 대규모 이탈을 겪었고, 7개월 만에 무료로 되돌렸지만 이미 떠난 사용자는 돌아오지 않았습니다.

이 요인을 찾는 일은 매뉴얼로 옮겨지지 않습니다. 여러 업종에서 여러 기성 조건에 부딪혀 본 사람만 지금 이 사업에서 소수의 요인이 무엇인지 즉시 짚어낼 수 있고, 이 판단을 주니어에게 맡기면 대개 두 방향으로 틀립니다. 이미 잘 처리되고 있는 부분에 힘을 쏟거나, 진짜 중요한 부분을 그냥 지나칩니다.

4. 표준의 빈틈을 찾았는가

ERP 시장의 빈틈을 다룬 글에서 다뤘듯, 기회는 표준을 이기는 게 아니라 표준이 안 닿는 경계에서 나옵니다. 이카운트나 위하고 같은 기성 ERP가 회계·세무·급여를 월 몇만원에 처리하는 상황에서, 그 범위를 다시 만들겠다는 제안은 시작 전에 무너집니다. 실제 기회는 발주가 들어오는 입구나 생산 현장처럼 표준이 손대지 않은 경계에 있었습니다. "이카운트는 API가 없어서 커스터마이징이 안 된다"는 말도 같은 글에서 짚었듯 틀린 말입니다. 표준이 실제로 어디까지 하고 어디서 멈추는지 정확히 모른 채 빈틈을 주장하면, 이미 표준이 잘 처리하는 영역에 새 기능을 제안하는 실수를 하게 됩니다. 사업 아이디어 칸을 채우기 전에 "이 시장에서 표준이 이미 잘하고 있는 부분이 어디인가"를 먼저 그려야, 남은 빈틈이 진짜인지 알 수 있습니다.

이 경계는 고객 규모에 따라서도 다시 그려집니다. 같은 글에서 다뤘듯 SAP나 더존 iCUBE 같은 대기업 ERP는 표준 자체를 그 회사에 맞게 다시 짜는 일이 이미 하나의 사업입니다. "표준을 건드리지 말라"는 원칙이 담당 부서와 분기 단위 예산이 있는 조직 앞에서는 뒤집힙니다. 사업 아이디어 칸에 적은 빈틈이 어느 규모의 고객을 향한 것인지에 따라, 같은 표준도 건드려야 할 대상이 되거나 피해야 할 대상이 됩니다.

5. 채널을 여는 순서에 근거가 있는가

서비스 채널 칸은 보통 "1차 웹, 2차 앱"처럼 순서를 정해 적습니다. PC·웹·인프라 순서를 다룬 글에서 피그마와 깃랩을 나란히 놓고 보면, 이 순서에 정답은 없습니다. 피그마는 브라우저라는 채널이 비어 있어 웹을 먼저 골랐고, 깃랩은 정반대로 온프레미스 시장이 비어 있어 그쪽을 먼저 골랐습니다. 트위터는 저사양 기기가 많은 시장에서 모바일 웹에 걸어 세션당 페이지뷰를 65% 늘렸고, 반대로 네이티브 앱만 강제했던 플립카트는 저장 공간이 빠듯한 사용자들에게 막혀 웹으로 되돌아가야 했습니다.

네 서비스를 나란히 놓으면 순서를 가른 기준이 보입니다.

서비스	먼저 연 채널	비어 있던 자리
피그마	웹(브라우저)	협업 디자인 툴이 브라우저에 없었다
깃랩	온프레미스	자체 호스팅 코드 관리가 비어 있었다
트위터	모바일 웹	저사양 기기 시장에 네이티브 앱 대안이 없었다
플립카트	네이티브 앱 → 웹으로 복귀	저장 공간이 빠듯한 사용자를 앱이 밀어냈다

넷 다 "웹이 먼저다" 또는 "앱이 먼저다" 같은 일반 규칙을 따르지 않았습니다. 그 시장에서 어느 채널이 비어 있었는지가 매번 달랐을 뿐입니다.

포토샵의 사례는 여기에 세 번째 축을 더합니다. 1990년 데스크탑으로 나온 포토샵이 브라우저 버전을 낸 것은 2023년입니다. 33년이 걸린 이유는 시장이 원하지 않아서가 아니라 브라우저가 전문가용 이미지 편집을 감당할 만큼 무르익지 않았기 때문입니다. 채널 순서는 그 채널에 고객이 비어 있는지, 그리고 그 채널이 기술적으로 지금 가능한지 둘 다로 정해야지, "다들 웹부터 시작하니까" 같은 관행으로 정하면 안 됩니다.

인프라(온프레미스) 채널은 여기에 신뢰라는 세 번째 조건이 하나 더 붙습니다. 고객사 서버에 직접 설치하게 하려면 그 벤더가 사라지거나 문제를 일으키지 않을 것이라는 확신이 먼저 있어야 하고, 이 신뢰는 트랙 레코드 없이는 안 생깁니다. 웹이나 앱과 달리 온프레미스는 채널을 열 수 있다고 곧바로 열어도 되는 채널이 아닙니다.

6. 수익모델이 요구하는 조건을 갖췄는가

수익모델 칸에 "구독" 또는 "광고"라고 한 줄 적는 것으로는 부족합니다. IT 수익모델을 다룬 글에서 다뤘듯, 모델마다 성립 조건이 다릅니다. 구독은 이용 빈도가 늘어도 원가가 거의 안 올라야 하고, 광고는 체류 시간이 길고 광고 저항이 낮아야 합니다. 무비패스는 이 조건을 확인하지 않고 구독 모델을 골라, 이용자가 영화를 한 편 더 볼 때마다 회사가 적자를 봤습니다. 월 9.95달러에 무제한 관람을 내걸었는데 당시 평균 티켓값이 9.11달러였으니, 이용자가 한 달에 두 편만 봐도 손해였습니다. 서비스가 잘될수록 회사가 더 빨리 망하는 구조였고, 실제로 가입자가 폭증한 뒤 파산했습니다. 모델 이름을 적는 순간이 아니라 그 모델이 요구하는 조건을 우리 서비스가 만족하는지 확인하는 순간이 진짜 검토입니다.

7. 팀을 나눌지 통합할지 판단했는가

프로젝트 멤버 칸은 기획자·디자이너·퍼블리셔·개발자를 나열하고 끝나는 경우가 많습니다. 프로젝트 멤버 통합을 다룬 글에서 다룬 브룩스의 법칙, 인원이 늘수록 소통 비용이 n(n-1)/2로 늘어난다는 공식이 이 나열의 숨은 비용을 보여줍니다. 개발자 50명이면 소통 경로가 1,225개까지 불어납니다. SA 기획을 다룬 글에서 다룬 인쇄기 롤러 프로젝트가 이 공식을 작게나마 실측으로 보여줍니다. 분석과 구현을 한 사람이 맡자 설계서와 코드 사이의 간극이 거의 사라졌고, 사진에서 옮긴 규격이 맞는지도 코드가 직접 검사했습니다. 소통 경로가 하나도 없으니 애초에 어긋날 일이 없었던 셈입니다. 반대 방향의 증거도 있습니다. 네덜란드의 개발자 피터 레벨스는 기획·디자인·개발·마케팅을 전부 혼자 처리하며 포트폴리오 연매출 약 300만 달러를 냅니다. 오픈AI의 샘 올트먼은 테크 업계 CEO들과의 모임에서 "1인 기업이 나오는 첫해가 언제일지"를 두고 내기를 하고 있다고까지 말했습니다. 인원을 나열하기 전에, 이 일이 정말 여러 사람을 필요로 하는지부터 물어야 합니다.

8. 반복되는 절반을 모듈화했는가

핵심역량 칸에 "빠른 구축"을 적는 팀은 많지만, 그 속도가 어디서 나오는지는 대개 안 적혀 있습니다. SI 모듈화를 다룬 글에서 다뤘듯, 로그인 화면이나 관리자 CRUD처럼 어느 프로젝트에나 등장하는 절반과 그 고객만의 절반은 따로 다뤄야 합니다. 듀오랩스의 DEUX(디자인 시스템)와 PAGE(패턴 킷)가 이 공통 절반을 실제로 담당합니다. 화면 하나가 패턴으로 등록될 때 이름·태그·소스·데모·문서 ID가 같이 붙고, 다음 프로젝트가 비슷한 화면을 필요로 할 때 처음부터 그리는 대신 여기서 골라 시작합니다. 이렇게 미리 모듈로 만들어 두면, 그 시간을 고객만의 문제에 쓸 수 있습니다. 이 재사용은 견적에도 그대로 쓸 수 있습니다. 화면 열 개짜리 프로젝트에서 여섯 개가 기존 패턴으로 시작할 수 있다면, 그 여섯 개의 견적 시간은 처음부터 짜는 시간이 아니라 수정하는 시간으로 계산합니다. 이 구분 없이 매번 처음부터 짜면 "빠른 구축"은 이번 한 번의 우연이지 반복 가능한 핵심역량이 아닙니다.

9. 운영이 문서가 아니라 시스템으로 넘어가는가

원본 체크리스트에는 운영 인수인계 항목 자체가 없습니다. PDF 매뉴얼의 역발상을 다룬 글에서 인용한 연구에 따르면, 문서화가 부실한 프로젝트는 초기 개발 공수 대비 약 47%의 추가 유지보수 노력과 48%의 추가 비용을 냅니다. PDF 매뉴얼은 화면이 바뀌는 순간 낡기 시작하고, 낡았다는 사실조차 아무도 모릅니다. 화면 안에 사는 가이드처럼, 운영 지식을 화면 자산에 붙여 두면 화면이 바뀔 때 낡음이 조용히 숨지 않습니다.

이 문제를 푸는 방식도 결국 8번 질문과 같은 자산화입니다. 화면이 패턴으로 등록될 때 "이 화면을 어떻게 쓰는가"라는 설명 한 항목을 같이 붙이면, 그 설명은 독립된 문서가 아니라 화면 자산의 일부가 됩니다. 화면이 패턴에서 벗어나게 고쳐지면 그 사실 자체가 "이 설명은 확인이 필요합니다"라는 신호로 남고, 문서를 쓰는 사람이 부지런한지와 무관하게 낡음이 조용히 숨지 않습니다.

이 글에서도 숫자 하나를 조심스럽게 다뤘습니다. 인앱 도움말이 문의를 얼마나 줄이는지에 대해 벤더가 발표한 수치(30~60%)와 독립 조사 수치(10~25%) 사이에 세 배 가까운 차이가 있었고, 그 격차 자체를 밝히는 편을 골랐습니다. 서비스를 만드는 계획에는 있지만 서비스를 넘기는 계획에는 없는 항목이 대개 이것이고, 그 항목을 채울 때 쓰는 숫자도 같은 의심을 받아야 합니다.

10. 기획자가 사람을 읽는 판단을 했는가

마지막 칸은 표에 아예 없습니다. 기획자의 스킬을 다룬 글에서 인용한 도널드 노먼의 말처럼, 디자인은 소통 행위이고 소통하려면 상대를 깊이 이해해야 합니다. UI/UX라는 표현 도구는 HCI라는 이해의 학문에서 갈라져 나온 것이지 그 반대가 아닙니다. 노먼은 1993년 애플에서 자신의 직함을 User Experience Architect로 바꾸며 이 말을 처음 썼는데, Human Interface나 usability라는 말이 산업 디자인부터 물리적 조작까지 사람이 시스템과 겪는 경험 전체를 담기엔 너무 좁다고 봤기 때문입니다. 앞선 아홉 개 칸을 아무리 정교하게 채워도, 그 답을 만든 사람이 사용자가 실제로 무엇을 불편해하는지 판단하는 능력이 없다면 칸은 그럴듯한 문장으로만 남습니다.

이 능력은 하나가 아니라 여러 개이고, 서로를 대신하지 못합니다. 카피라이팅을 잘하는 사람이 꼭 심리학을 잘 아는 것은 아니고, 커뮤니케이션을 잘하는 사람이 꼭 데이터를 잘 읽는 것도 아닙니다. 한 축이 강하다고 다른 축이 따라오지 않고, 약한 축 하나가 전체 결과물의 병목이 됩니다. 열 번째 칸이 사실은 아홉 개가 아니라 아홉 곱하기 여러 개인 이유입니다.

체크리스트는 한 번 채우고 끝나는 문서가 아니다

열 가지를 표로 정리하면 이렇습니다.

번호	원래 칸	이 시리즈가 다시 묻는 것	참고 글
1	기획 이유	당위성인가, 벤치마크인가	기획의 본질
2	주요 고객	쓰는 사람과 돈 내는 사람이 같은가	세 가지 질문
3	핵심역량	진짜 핵심 성공 요인은 몇 개인가	세 가지 질문
4	사업 아이디어	표준의 빈틈이 진짜인가	ERP 빈틈
5	서비스 채널	여는 순서에 근거가 있는가	채널 순서
6	수익모델	모델이 요구하는 조건을 갖췄는가	IT 수익모델
7	프로젝트 멤버	나눌지 통합할지 판단했는가	멤버 통합
8	핵심역량	반복되는 절반을 모듈화했는가	SI 모듈화
9	원본에 없음	운영이 문서가 아니라 시스템으로 넘어가는가	PDF 매뉴얼
10	원본에 없음	사람을 읽는 판단을 했는가	기획자 스킬

표를 보면 공통점이 드러납니다. 원래 체크리스트는 전부 명사형 답을 요구하고, 이 시리즈는 매번 그 답 뒤에 "그런데 이게 왜 맞는가"를 붙였습니다. 당위성은 왜 이 사업이 필요한지가 아니라 왜 우리가 돈을 벌어도 되는지를 묻고, 고객은 누가 쓰는지가 아니라 누가 돈을 내는지를 묻고, 채널은 무엇을 낼지가 아니라 언제 낼지를 묻고, 수익모델은 무엇으로 벌지가 아니라 그 모델이 요구하는 조건이 지금도 성립하는지를 묻습니다.

이 물음표들에는 공통된 방향이 있습니다. 전부 명사 하나를 조건 하나로 바꾸는 일입니다. "구독"이 아니라 "이용 빈도가 늘어도 원가가 안 오르는 구독"으로, "핵심역량 세 가지"가 아니라 "이 중 진짜 성패를 가르는 하나"로, "기획자 한 명"이 아니라 "소통 비용이 발생하지 않는 기획자 한 명"으로. 체크리스트의 칸이 명사인 것은 잘못이 아닙니다. 그 명사 뒤에 조건을 안 붙이고 멈추는 것이 문제입니다.

이 시리즈를 쓰는 동안 저 자신도 이 원칙을 지키려 했습니다. 인터넷에 도는 "10곳 중 7곳이 수기로 입력한다", "명확한 고객이 있으면 이탈률이 준다" 같은 숫자들을 몇 번 마주쳤고, 그때마다 원 출처까지 추적했습니다. 추적이 안 되는 숫자는 논지에 아무리 잘 맞아도 빼고, 대신 실제로 확인 가능한 사례나 재현 가능한 공식으로 바꿔 썼습니다. 통찰력이 좋은 아이디어를 떠올리는 능력이라면, 그 아이디어를 뒷받침하는 근거를 스스로 걸러내는 것도 같은 능력의 일부라고 저는 봅니다. 체크리스트를 채우는 사람에게도 같은 태도가 필요합니다. 그럴듯한 숫자와 검증된 숫자는 다르고, 그 둘을 가르는 습관이 계획서의 나머지 모든 칸의 신뢰도를 정합니다.

체크리스트는 시작하기 전에 한 번 채우고 끝내는 문서가 아니라, 답이 여전히 맞는지 주기적으로 되돌아가 다시 채워야 하는 문서라고 저는 봅니다. 고객이 바뀌면 핵심요소도 다시 물어야 하고, 채널을 하나 더 열면 수익모델의 조건도 다시 확인해야 합니다. 이 시리즈를 마치며 남기고 싶은 결론은 이것 하나입니다. 칸을 채우는 순간이 아니라 그 답을 의심하는 순간이 기획의 실제 작업입니다.