제품 형태

소프트웨어가 CD에 담겨 팔리던 시절에는 이 말이 필요하지 않았습니다. 제품은 PC에 설치하는 프로그램 하나였고, 그것 말고 다른 모습은 없었습니다. "우리 제품" 이라고 하면 모두가 같은 것을 떠올렸으니 형태를 따로 부를 이유도 없었습니다.

인터넷에 접속해 쓰는 방식이 자리를 잡고 스마트폰이 뒤따라오면서 같은 기능이 여러 껍데기로 나뉘기 시작했습니다. 문서를 함께 편집하는 기능 하나를 두고 브라우저에서 여는 화면, 휴대폰에 설치하는 앱, 다른 회사 시스템이 불러 쓰는 통로가 각각 따로 존재하게 된 겁니다. 이때부터 "무엇을 만들까" 와 "그것을 어떤 껍데기에 담을까" 가 서로 다른 질문이 됐습니다.

이 구분이 없으면 회의가 헛돕니다. 태오가 "그건 앱에서 안 됩니다" 라고 말했을 때 지현이 기능이 어렵다는 뜻으로 알아듣고 요구를 줄이는 일이 생깁니다. 실제로 태오가 말한 것은 기능이 아니라 껍데기의 제약이었습니다. 휴대폰에 설치되는 앱은 바꿀 때마다 앱 장터의 심사를 거쳐야 해서, 급한 수정 하나에 사흘이 걸립니다. 브라우저에서 여는 화면이었다면 같은 수정이 30분 만에 반영됩니다. 이 차이를 가리키는 이름이 없으면 같은 대화가 매번 처음부터 반복됩니다.

형태를 고르는 일이 무거운 이유는 그 선택이 제품 바깥까지 정해 버리기 때문입니다. 어떤 껍데기를 고르느냐에 따라 사용자에게 닿는 경로가 달라지고, 고쳐서 내보내는 주기가 달라지고, 결제 대금에서 떼어 가는 몫이 달라지고, 뽑아야 하는 개발자의 전공이 달라집니다. 만들기 시작한 뒤에 형태를 바꾸는 것은 기능 하나를 바꾸는 것과 비용이 다릅니다. 상위 분야인 제품에서 이 갈래를 제품 구조 쪽에 두는 까닭도 여기 있습니다. 이것은 이번 분기에 무엇을 만들지가 아니라 제품이 어떤 틀 위에 서 있는지를 정하는 판단입니다.

이름이 겹치는 자리가 하나 있습니다. 완성 전에 작게 만들어 보는 시험용 물건, 곧 최소 기능 제품이나 프로토타입을 묶어 부를 때도 제품 형태라는 말을 씁니다. 여기서 다루는 것은 그쪽이 아니라 사용자에게 실제로 닿는 껍데기입니다.

제품 형태 아래 묶인 용어는 여덟이고 모두 한 갈래, 곧 형태입니다. 나뉘는 기준은 사용자가 이 제품과 만나는 자리입니다. 앞의 넷은 사람이 직접 보는 화면을 가지고, 다음 둘은 화면 없이 다른 소프트웨어 안쪽에서 쓰이며, 마지막 둘은 남의 제품이나 남의 거래를 자기 위에 얹습니다.

1. 웹앱 — 브라우저에서 주소를 열면 바로 쓰는 형태입니다. 설치가 없으니 링크 하나로 사람을 데려올 수 있고, 고친 코드를 올리면 그 순간 모든 사용자가 새 버전을 씁니다. 업무용 도구가 이 형태로 몰리는 이유가 이 두 가지입니다. 약점은 인터넷이 끊기면 멈춘다는 것과 휴대폰 화면에서 쓰기 불편하다는 것입니다.
2. 모바일 앱 — 휴대폰에 설치해 쓰는 형태입니다. 카메라와 위치와 알림처럼 기기에 붙은 기능을 쓸 수 있고, 첫 화면에 아이콘이 남아 다시 열릴 확률이 높습니다. 대신 앱 장터의 규칙을 따라야 합니다. 새 버전마다 심사를 받아야 하고 결제 금액의 일부를 장터에 떼어 줘야 하며, 사용자가 업데이트를 미루면 반년 전 버전을 쓰는 사람이 남습니다.
3. 데스크톱 앱 — PC에 설치해 쓰는 형태입니다. 기기의 성능을 온전히 쓰고 하드디스크의 파일을 직접 다룰 수 있어, 영상 편집이나 코드 작성처럼 무거운 작업에 남아 있습니다. 운영체제마다 따로 만들고 따로 배포해야 하는 부담이 가장 큽니다.
4. 브라우저 확장 — 브라우저에 덧붙어 남의 웹사이트 위에서 동작하는 프로그램입니다. 사용자가 이미 일하고 있는 화면 안으로 들어간다는 점이 특이합니다. 다른 회사 화면 옆에 버튼 하나를 띄워 두는 식이라 진입 문턱이 낮지만, 브라우저 회사가 규칙을 바꾸면 하루아침에 동작이 막힙니다.
5. API 제품 — 화면 없이 다른 프로그램이 호출해 쓰는 형태입니다. 주소로 요청을 보내면 결과를 돌려주는 통로만 있고, 사용자가 보는 것은 그 결과를 받아 쓰는 남의 화면입니다. 고객이 개발자라서 팔리는 방식도 다릅니다. 광고보다 문서의 품질이 결정적이고, 한번 붙으면 상대의 코드에 박히니 잘 떠나지 않습니다. 대신 한 번의 장애가 그 위에 얹힌 모든 서비스로 번집니다.
6. SDK — 남의 제품 안에 끼워 넣어 쓰도록 만든 개발 도구 묶음입니다. 이름은 소프트웨어 개발 키트를 줄인 말입니다. 결제나 지도나 오류 수집 기능을 직접 만들지 않고 몇 줄로 붙일 수 있게 포장한 것이라고 보면 됩니다. API가 밖에서 불러 쓰는 통로라면 이쪽은 상대의 앱 안에 함께 설치돼 돌아갑니다. 그래서 버전을 올려도 사용자가 그것을 새로 붙여 주기 전까지는 옛 버전이 남습니다.
7. 플랫폼 — 다른 서비스가 그 위에 얹혀 돌아가는 기반 제품입니다. 남이 만든 기능을 붙일 수 있는 자리를 열어 두고, 그 자리에 붙은 것들이 늘어날수록 제품의 값어치가 커집니다. 회사가 혼자 만드는 속도보다 바깥이 붙이는 속도가 빨라지는 시점이 이 형태의 목표입니다. 다만 남의 코드가 내 제품 위에서 도니 심사와 권한 관리가 따라붙고, 붙은 개발사가 적으면 열어 둔 자리는 관리 비용만 남깁니다.
8. 마켓플레이스 — 파는 쪽과 사는 쪽을 연결하고 거래에서 수수료를 받는 형태입니다. 한쪽만 모아서는 굴러가지 않는다는 점이 다른 일곱과 결정적으로 다릅니다. 파는 사람이 없으면 사는 사람이 안 오고, 사는 사람이 없으면 파는 사람이 떠납니다. 그래서 초기에는 한쪽을 손해 보면서 채우는 방식으로 시작합니다.

여덟 중 하나를 고르는 것이 아니라 여러 개를 함께 쓰는 경우가 훨씬 많습니다. 같은 제품이 브라우저에도 있고 휴대폰에도 있고 다른 회사가 불러 쓰는 통로도 열어 두는 식입니다. 여기서 실제로 정해야 하는 것은 순서입니다. 무엇을 먼저 내고 무엇을 나중에 낼지, 그리고 뒤에 내는 것이 앞의 것과 같은 수준으로 관리될 수 있는지입니다. 형태가 하나 늘면 고쳐야 할 곳과 시험해야 할 곳과 장애가 날 수 있는 곳이 함께 늘어납니다. 개발자 다섯 명인 팀이 웹과 앱을 동시에 굴리면 한쪽은 두 달째 손을 못 대는 상태가 되기 쉽습니다. 같은 기능을 껍데기 둘에 내려면 만드는 시간이 두 배가 아니라 두 배 남짓입니다. 두 벌을 만드는 시간에 두 곳의 동작을 맞추는 시간과 어긋났을 때 찾아내는 시간이 더 붙기 때문입니다.

무엇을 먼저 고를지는 취향이 아니라 사용자가 그 일을 하는 자리가 정합니다. 문서를 쓰고 표를 다루는 일은 대개 책상 앞에서 벌어지니 브라우저가 앞에 서고, 이동 중에 확인하고 답하는 일이 많으면 휴대폰이 앞에 섭니다. 사용자가 사람이 아니라 다른 시스템이면 화면 자체가 필요 없습니다. 판단이 헷갈릴 때는 지금 쓰는 사람들이 어디서 접속하는지를 세어 보는 편이 빠릅니다. 접속의 열에 아홉이 PC 브라우저에서 들어오는데 휴대폰 앱을 먼저 만들기로 했다면, 그 결정은 사용자가 있는 자리가 아니라 만들고 싶은 것을 따라간 것입니다.

이 갈래를 옆의 두 용어와 섞지 않는 편이 좋습니다. SaaS는 설치 없이 구독료를 내고 쓰는 판매와 제공 방식을 가리키는 말이고, 사업 유형은 개인에게 파는지 기업에 파는지를 가르는 말입니다. 셋은 같은 제품을 서로 다른 각도에서 부르는 이름이라 겹쳐서 성립합니다. 기업에 구독으로 파는 웹앱이라는 문장 하나에 세 가지가 모두 들어 있습니다.

"이번 기능은 웹에만 먼저 내고 앱은 다음 분기에 붙이죠."

두 껍데기를 동시에 맞추면 출시가 밀리니 반영이 빠른 쪽으로 먼저 내보내자는 제안입니다.

"여기서 앱으로 가면 심사 때문에 긴급 수정이 하루 만에 안 나갑니다."

기능의 난이도가 아니라 배포 경로의 제약을 지적하는 말입니다.

"고객사가 화면은 필요 없고 데이터만 가져가고 싶다는데요."

일반 사용자용 화면 대신 다른 시스템이 호출할 통로를 열어 달라는 요청입니다.

페이지덱은 브라우저에서 여는 문서 도구로 시작했습니다. 첫 2년 동안 형태는 하나뿐이었고, 그래서 아침에 고친 것을 점심에 내보낼 수 있었습니다. 기업 고객이 늘면서 두 가지 요청이 동시에 들어왔습니다. 수아가 받아 온 것은 이동 중에 문서를 확인하고 승인만이라도 하게 해 달라는 요청이었고, 태오에게 들어온 것은 사내 인사 시스템에서 문서를 자동으로 만들게 해 달라는 요청이었습니다.

지현은 두 요청을 같은 줄에 놓지 않았습니다. 앞의 것은 휴대폰에 설치하는 껍데기가 필요했지만 필요한 기능은 읽기와 승인 두 가지뿐이었고, 뒤의 것은 화면이 아예 필요 없는 대신 안정성과 문서가 중요했습니다. 결정은 뒤의 것을 먼저 여는 쪽이었습니다. 개발자 두 명이 6주면 통로를 열 수 있었고, 앱은 같은 인원으로 넉 달이 걸리는 데다 그 뒤로도 매달 유지 인력이 붙어야 했기 때문입니다. 규원이 회의에서 정리한 기준은 하나였습니다. 형태를 늘리는 결정은 만드는 비용이 아니라 그다음 3년 동안 유지할 수 있는지로 판단한다는 것이었습니다.

형태는 많을수록 좋다고 보는 경우가 가장 흔합니다. 웹도 있고 앱도 있고 데스크톱도 있으면 제품이 커 보이니 자연스러운 생각입니다. 그런데 형태 하나는 만들 때 한 번 드는 비용이 아니라 매달 나가는 고정비에 가깝습니다. 기능 하나를 추가하면 껍데기 수만큼 만들고, 그 수만큼 시험하고, 장애가 나면 그 수만큼 확인해야 합니다. 형태가 셋인 팀은 같은 기능을 내는 데 세 배 가까운 시간을 씁니다. 그대로 두면 가장 사용자가 적은 껍데기부터 방치되는데, 그쪽을 쓰던 사람들은 제품이 고장 났다고 느끼고 떠납니다. 형태를 하나 늘리는 것은 기능을 하나 늘리는 것이 아니라 제품을 하나 더 맡는 일에 가깝습니다.

우리 제품을 플랫폼이라고 부르는 것도 자주 어긋납니다. 규모가 커 보이고 투자 설명에도 어울리니 쓰고 싶어지는 말입니다. 하지만 이 형태를 가르는 기준은 크기가 아니라 남이 그 위에 무언가를 올리는지입니다. 기능이 아무리 많아도 전부 내부에서 만든 것이라면 그것은 기능이 많은 제품이고, 바깥의 개발사가 붙인 것이 실제로 돌고 있어야 이 이름이 성립합니다. 이 구분이 흐려지면 실무에서 손해가 납니다. 이름만 앞서 붙여 두면 외부 개발사가 붙을 자리를 열고 문서를 쓰고 심사 규칙을 만드는 일이 뒤로 밀리고, 그러는 사이 붙으려던 회사들은 다른 곳으로 갑니다.