화이트라벨

좋은 소프트웨어를 만들었는데 팔 곳이 없는 회사와, 고객은 잔뜩 있는데 그것을 만들 여력이 없는 회사가 늘 같이 있었습니다. 둘이 만나면 거래가 될 듯한데 매번 같은 자리에서 막혔습니다. 화면에 누구 이름이 뜨느냐였습니다.

상담 채팅 기능을 만든 열 명짜리 회사가 은행에 팔러 갑니다. 기능은 마음에 든다는 답이 오는데, 계약서를 쓰기 직전에 "우리 앱 안에 다른 회사 로고가 뜨는 건 안 됩니다" 라는 말이 나옵니다. 은행 쪽 사정에도 근거가 있습니다. 고객이 낯선 이름을 보면 이게 은행 서비스인지 의심하고, 사고가 났을 때 어디에 전화해야 하는지도 흐려집니다. 만든 쪽은 브랜드를 포기하기 싫고 쓰는 쪽은 남의 브랜드를 자기 화면에 들일 수 없으니, 제품이 사용자 앞까지 가지 못했습니다.

화이트라벨은 이 교착을 한쪽이 양보하는 방식으로 푼 이름입니다. 만든 쪽이 이름을 내려놓고, 대신 고객사가 이미 모아 둔 사용자 수백만 명 앞에 한 번에 서는 자리를 받습니다. 흰 라벨이라는 말 자체가 상표를 찍지 않은 빈 라벨을 붙여 넘기던 유통업 관행에서 왔습니다.

한 벌의 시스템을 그대로 돌리면서 브랜드로 보이는 겉면만 고객사별로 갈아 끼웁니다. 뒤를 건드리지 않는 것이 이 방식이 성립하는 조건입니다.

갈아 끼우는 자리는 보통 다섯 군데입니다.

1. 로고와 색, 서체. 고객사 브랜드 가이드라인에 적힌 값을 설정에 넣어 두고 화면을 그릴 때 꺼내 씁니다. 브랜드 가이드라인은 로고 여백부터 지정 색 코드까지 적어 둔 문서입니다.
2. 주소. pagedeck.com/bank 가 아니라 docs.은행.com 으로 보이게 고객사 도메인을 연결합니다. 주소창에 만든 쪽 이름이 남아 있으면 나머지 넷을 다 해도 들통납니다.
3. 발신 정보. 알림 메일의 발신자 이름과 주소, 문자의 발신 번호를 고객사 것으로 바꿉니다. 초대 메일 한 통이 낯선 발신자로 날아오면 사용자는 스팸으로 신고합니다.
4. 문서와 안내 문구. 약관, 도움말, 오류 메시지에 박힌 제품 이름을 고객사 것으로 바꿉니다.
5. 값을 받는 창구. 사용자는 고객사에 돈을 내고, 만든 쪽은 고객사에게서 받습니다. 결제 영수증에 만든 쪽 상호가 찍히면 안 됩니다.

바꾸지 않는 쪽도 정해져 있습니다. 서버와 데이터베이스는 멀티테넌시로 한 벌만 돌립니다. 여러 고객사가 같은 시스템을 나눠 쓰면서 데이터는 줄마다 붙은 고객사 번호로만 갈라 두는 구조입니다. 고객사가 서른 곳이어도 코드가 한 벌이라 기능 하나를 고치면 서른 곳에 같은 날 반영됩니다. 고객사마다 코드를 갈라 두기 시작하면 서른 벌을 따로 고쳐야 하고, 그 순간 원가는 싱글 테넌시 쪽으로 올라갑니다. 싱글 테넌시는 고객사마다 환경을 통째로 따로 띄워 주는 구조입니다.

세 자리에서 주로 쓰입니다.

첫째는 이미 사용자를 많이 가진 회사의 화면 안으로 들어가는 자리입니다. 은행 앱의 상담 채팅창, 통신사 멤버십 앱의 예약 기능이 그렇습니다. 광고로 사용자 한 명을 데려오는 데 3천 원을 쓰던 회사라면, 사용자 200만 명이 있는 앱에 들어가는 계약 한 건이 그 비용을 건너뛰게 해 줍니다.

둘째는 대신 팔아 주는 파트너를 두는 자리입니다. 리셀러는 우리 제품을 자기 고객에게 파는 파트너인데, 지역 총판처럼 영업망을 이미 가진 곳은 자기 브랜드로 팔기를 원합니다. 이때는 가격 책정을 파트너에게 맡기고 만든 쪽은 정해진 공급가만 받는 구조가 흔합니다.

셋째는 대기업 사내 시스템에 얹히는 자리입니다. 엔터프라이즈 계약에서는 임직원 3만 명이 쓰는 사내 포털의 메뉴 하나로 들어가 달라는 요구가 나옵니다. 사내 도구가 회사 이름으로 통일돼 있어야 문의받는 쪽이 헷갈리지 않기 때문입니다.

값을 받는 방식은 둘로 갈립니다. 고객사가 사용자 수에 맞춰 정액을 내거나, 고객사가 사용자에게서 거둔 매출을 나눕니다. 앞쪽은 예측이 쉽고 뒤쪽은 고객사가 열심히 팔 때 같이 커집니다.

"이 건은 화이트라벨로 가야 합니다. 저쪽 앱에 우리 로고는 못 넣습니다."

계약을 따려면 브랜드 노출을 포기해야 한다는 판단입니다.

"화이트라벨 지원 범위가 로고 교체까지인가요, 도메인까지인가요?"

겉면을 어디까지 갈아 끼울 수 있는지 묻는 질문입니다. 범위가 넓어질수록 작업량이 크게 달라집니다.

"화이트라벨 고객이 늘면 SLA를 누가 지는지부터 정리해야 합니다."

장애가 났을 때 사용자에게 사과하는 쪽과 실제로 고치는 쪽이 다르다는 문제 제기입니다. SLA 는 응답 시간과 가동률을 계약으로 못 박은 약속입니다.

페이지덱에서는 수아가 보험사 한 곳을 끌고 오면서 이 말이 처음 회의에 올라왔습니다. 임직원 8천 명이 쓰는 사내 포털 안에 문서 도구를 넣되 페이지덱이라는 이름은 어디에도 보이면 안 된다는 조건이었습니다. 태오는 화면과 도메인, 발신 메일까지는 두 주면 된다고 답했고 약관과 도움말은 손댈 곳이 많아 따로 셌습니다.

규원이 물은 건 다른 쪽이었습니다. 계약이 성사되면 매출은 오르지만 사용자 8천 명 중 아무도 페이지덱이라는 이름을 알지 못합니다. 그래서 화이트라벨은 최소 계약 규모를 정해 두고 그 아래로는 받지 않기로 정리했습니다.

로고 파일만 바꿔 끼우면 끝나는 작업으로 보는 경우가 가장 많습니다. 데모 화면에서는 로고 하나만 바꿔도 다른 회사 제품처럼 보이니 그렇게 느낄 만합니다. 그런데 사용자가 끝까지 눈치채지 못하게 하려면 초대 메일 발신자, 오류 메시지 안의 제품 이름, 영수증 상호, 도움말 링크 주소까지 전부 따라가야 합니다. 하나만 남아 있어도 사용자는 그 지점에서 낯선 이름을 보고 고객사 상담 창구에 문의를 넣습니다. 로고 교체를 한 주짜리 일로 잡고 시작한 팀이 두 달째 문구를 찾아다니는 일이 그래서 생깁니다.

브랜드를 내주는 대신 무엇을 잃는지도 자주 빠집니다. 화이트라벨로 나간 사용자는 만든 쪽의 사용자가 아니라 고객사의 사용자입니다. 계약이 끝나면 그 사용자도 함께 사라지고, 그동안 쌓인 평판은 고객사 이름으로 남습니다.