서비스 채널: PC·웹·인프라를 여는 순서가 다른 이유

2016년, 피그마는 브라우저 안에서만 돌아가는 디자인 툴로 세상에 나왔습니다. 당시 업계를 장악한 스케치는 맥 전용 설치형 프로그램이었고, 브라우저에서 전문가용 그래픽 툴이 돌아간다는 것 자체가 상식 밖의 도박이었습니다. 딜런 필드와 에반 월러스는 첫 코드를 짜고 4년이 지나서야 제품을 냈습니다(Figma Blog).

채널을 여는 순서에 정답이 있다는 생각

가볍고 싼 채널부터 열고 무겁고 비싼 채널은 나중에 연다는 생각이 흔합니다. 웹으로 먼저 검증하고, 필요하면 데스크탑 앱을 내고, 정말 큰 고객이 요구하면 그때 온프레미스를 검토한다는 순서입니다. 저는 이 순서가 정답이 아니라 하나의 가능성일 뿐이라고 봅니다. 실제로 같은 시대에 정반대 순서로 시작해 성공한 회사들이 있습니다.

웹이 비어 있어서 웹을 먼저 연 경우

피그마가 브라우저를 고른 이유는 가벼워서가 아닙니다. 디자인 툴 시장에서 브라우저라는 채널 자체가 비어 있었기 때문입니다. 스케치가 데스크탑을 이미 장악한 상태에서 똑같은 데스크탑 앱을 하나 더 내면 승산이 없었습니다. 피그마는 아무도 손대지 않은 방식, 즉 여러 사람이 브라우저 하나로 동시에 편집하는 협업에 걸었고, 그 도박이 자리를 잡기까지 4년이 걸렸습니다.

인프라가 비어 있어서 인프라를 먼저 연 경우

깃랩은 정반대로 시작했습니다. 2011년 우크라이나에서 오픈소스 프로젝트로 출발했을 때, 첫 제품은 회사가 자기 서버에 직접 설치하는 온프레미스 버전이었습니다. 이유는 명확합니다. 깃허브와 애틀라시안이 이미 호스팅형(SaaS) 시장을 잡고 있었고, 반대로 자기 서버에 직접 설치하고 싶어 하는 수요는 그때까지 제대로 채워지지 않은 채 남아 있었습니다. 깃랩은 이 빈자리를 먼저 잡았고, 호스팅형 서비스는 그 뒤에야 냈습니다(Incredibuild).

피그마와 깃랩을 나란히 놓으면 같은 원리가 반대 방향으로 작동한 것을 볼 수 있습니다. 어느 채널을 먼저 여느냐는 채널 자체의 성숙도가 아니라 그 시점에 어느 채널이 비어 있느냐로 정해집니다. 고객이 누구인가를 다룬 글에서 다룬 질문이 여기서는 "이 채널에 아직 안 온 고객이 누구인가"로 다시 나타납니다.

채널이 기술적으로 준비되지 않아서 못 여는 경우

포토샵은 세 번째 경우를 보여줍니다. 1990년 맥용 데스크탑 프로그램으로 출시된 포토샵이 브라우저 버전을 낸 것은 2023년 9월입니다. 33년이 걸렸습니다(TechCrunch). 이 격차는 시장의 빈자리 문제가 아닙니다. 전문가용 이미지 편집이 요구하는 연산을 브라우저가 감당할 수 있게 된 것 자체가 최근 일입니다. GPU 가속 렌더링과 웹어셈블리가 실용적인 수준에 이르기 전까지, 웹이라는 채널은 열고 싶어도 열 수 없는 채널이었습니다.

저는 이 사례가 타이밍을 시장 쪽에서만 보면 안 되는 이유를 보여준다고 봅니다. 채널을 열 시점은 그 채널에 고객이 비어 있는가뿐 아니라, 그 채널이 우리 제품을 감당할 만큼 기술적으로 무르익었는가에도 달려 있습니다. 포토샵은 시장이 원해도 기술이 안 따라주면 채널을 열 수 없다는 것을, 피그마는 반대로 기술이 준비되면 아무도 안 가 본 채널에 먼저 갈 수 있다는 것을 보여줍니다.

네이티브 앱과 모바일 웹이 갈리는 조건

트위터는 모바일 웹에 걸었습니다. 인도, 필리핀처럼 저사양 기기와 비싼 데이터 요금이 흔한 시장에서 네이티브 앱은 그 자체로 진입 장벽이었습니다. 안드로이드 네이티브 앱은 설치에 23.5MB가 필요했지만, PWA인 트위터 라이트는 600KB로 시작할 수 있었습니다. 그 결과 세션당 페이지뷰가 65%, 보낸 트윗이 75% 늘고 이탈률은 20% 줄었습니다(web.dev 공식 사례 연구).

플립카트는 정반대 순서를 겪고서야 같은 답에 도달했습니다. 2015년 인도 최대 이커머스 플립카트는 모바일 웹을 아예 닫고 네이티브 앱만 남기는 승부수를 던졌습니다. 그런데 신흥 시장 사용자 상당수가 저장 공간이 빠듯한 저가 단말과 2G 회선을 쓰고 있었고, 앱 설치 자체가 장벽이 됐습니다. 결국 100KB 남짓한 PWA "플립카트 라이트"로 모바일 웹을 되살렸고, 신규 사용자 전환율이 70% 올랐습니다(web.dev 공식 사례 연구).

두 사례를 보면 네이티브 앱과 모바일 웹의 우열은 정해져 있지 않습니다. 저는 이 선택이 사용자의 기기·네트워크 조건에 달려 있다고 봅니다. 저사양 기기와 느린 회선이 흔한 시장에서는 설치 없이 바로 쓸 수 있는 가벼운 웹이 이기고, 고사양 기기와 빠른 네트워크가 기본인 시장에서는 카메라·푸시 알림·오프라인 저장 같은 기기 기능을 쓸 수 있는 네이티브 앱이 더 크게 작동합니다.

웹만 냈을 때와 앱까지 냈을 때, 효과가 갈리는 지점

그렇다고 네이티브 앱이 항상 손해는 아닙니다. 스타벅스는 실적 발표 때마다 미국 매장 거래 중 앱으로 들어온 비중을 공개하는데, 2023년 4분기 기준 31%까지 올라왔습니다. 2015년 20% 수준이던 것이 8년에 걸쳐 꾸준히 늘어난 결과입니다(GeekWire).

스타벅스 앱이 만드는 것은 웹으로 흉내 내기 어려운 흐름입니다. 매장에 도착하기 전에 미리 주문하고 결제하고, 그 결제에 리워드가 자연스럽게 붙습니다. 한 번 조회하고 끝나는 방문이 아니라 하루에도 여러 번 반복되는 습관적 행동이고, 이런 반복 구매·로열티 구조에서는 홈 화면에 아이콘 하나로 항상 떠 있는 네이티브 앱이 유리합니다.

저는 이 차이가 웹만 냈을 때와 앱까지 냈을 때의 효과를 가르는 기준이라고 봅니다. 한 번 들어와 정보를 찾고 나가는 서비스라면 웹만으로 충분하고 앱을 더하는 비용은 낭비에 가깝습니다. 반대로 하루에 몇 번씩 돌아오는 반복이 핵심이라면, 그 반복을 홈 화면에 고정하는 앱이 웹만 냈을 때보다 뚜렷하게 낫습니다.

네 채널을 가르는 조건

채널	배포·운영 부담	요구되는 신뢰 수준	열기 좋은 시점
웹(모바일 웹 포함, SaaS)	낮음. URL 하나로 즉시 씀, 설치 없음	낮음. 무료 체험으로 신뢰를 대신할 수 있음	빠른 검증과 넓은 도달, 저사양 기기·저속 네트워크 사용자가 많을 때
모바일 앱(네이티브)	중간. 스토어 심사·업데이트 배포가 필요	낮음~중간. 스토어 평판이 신뢰를 어느 정도 대신함	반복 방문·습관적 사용이 핵심이거나, 카메라·푸시 등 기기 기능이 필요할 때
PC(데스크탑 설치형)	중간. 설치·업데이트 배포가 필요	중간. 로컬 파일·자원 접근을 허용해야 함	브라우저가 못 하는 성능이나 통합이 필요할 때
인프라(온프레미스)	높음. 고객사 서버에 설치·운영 인력이 필요	매우 높음. 보안·컴플라이언스 심사를 통과해야 함	그 세그먼트가 비어 있거나, 이미 검증된 벤더로 인정받았을 때

이 표에서 인프라 쪽 신뢰 수준이 유독 높은 이유는 IT 수익모델을 다룬 글에서 다룬 오픈소스·엔터프라이즈 모델과 같습니다. 고객사 서버에 직접 설치하게 하려면, 그 벤더가 사라지거나 문제를 일으키지 않을 것이라는 확신이 먼저 있어야 합니다. 트랙 레코드 없이 온프레미스부터 열면, 정작 온프레미스가 필요한 고객군(대기업, 금융, 공공)에게는 오히려 신뢰를 증명 못 한 채 문을 여는 셈이 됩니다.

순서를 정하기 전에 먼저 재야 할 것

이 넷을 놓고 저라면 두 가지를 먼저 확인하겠습니다. 첫째, 지금 우리가 노리는 고객이 이미 어느 채널에서 서비스를 받고 있는지, 그리고 그 채널에 만족하지 못하는 지점이 있는지를 봅니다. 만족하는 채널에 똑같은 걸 하나 더 내면 피그마 이전의 실패한 브라우저 디자인 툴들처럼 묻힙니다. 둘째, 우리가 열려는 채널이 기술적으로 지금 가능한지를 봅니다. 아이디어가 옳아도 채널 자체가 아직 안 여물었으면 포토샵처럼 기다려야 합니다.

두 조건을 다 확인하지 않고 "다들 웹부터 시작하니까"라는 이유만으로 순서를 정하면, 깃랩이 잡은 것 같은 빈자리를 그냥 지나칠 수 있습니다. 반대로 시장이 비어 있다고 기술 준비 없이 먼저 뛰어들면 포토샵이 30년 넘게 기다려야 했던 이유를 무시하는 셈이 됩니다.