빌드-바이-파트너

필요한 기능이 생기면 만드는 것이 기본값이던 시절이 있었습니다. 결제도 직접 붙이고, 메일 발송도 직접 짜고, 화상 통화까지 직접 만들었습니다. 만들 줄 아는 사람이 모여 있으니 만드는 쪽이 자연스러웠고, 밖에서 사오는 것은 왠지 돈 쓰는 일처럼 보였습니다.

그래서 회의는 늘 한 가지만 물었습니다. "그거 우리가 만들면 얼마나 걸려요?" 기획자가 묻고 개발자가 "석 달이요" 하고 답하면 석 달을 잡아 두고 시작했습니다. 같은 일을 하는 완성품이 밖에 얼마에 나와 있는지, 그것을 붙이면 2주 만에 끝나는지는 아무도 묻지 않았습니다. 그렇게 만든 결제 기능은 여섯 달이 걸렸고, 나온 결과는 밖에서 파는 것보다 쓰기 불편했습니다.

반대쪽으로 기울어도 문제였습니다. 있는 것을 다 붙여 빨리 만든 제품은 여섯 달 만에 화면을 띄웠지만 어느 부분이 우리 것인지 답할 수 없었고, 경쟁사도 같은 부품을 살 수 있으니 따라잡히는 데 오래 걸리지 않았습니다.

빌드-바이-파트너는 이 물음을 두 갈래가 아니라 세 갈래로 벌려 놓고 같은 기준으로 비교하게 만든 틀입니다. 만들기, 사기, 손잡기를 나란히 올려 두면 "얼마나 걸리나" 하나로 정하던 자리에 다른 질문이 들어옵니다. 이 기능이 우리가 잘해야 하는 일인가 하는 질문입니다.

판단은 기능 하나를 놓고 다섯 단계로 굴립니다. 제품 전체가 아니라 기능 단위여야 비교가 됩니다.

1. 무엇이 필요한지 한 줄로 적습니다. "결제" 가 아니라 "카드로 월 구독료를 자동으로 걷고 실패하면 다시 시도한다" 처럼 적어야 세 안의 견적이 같은 물건을 가리킵니다.
2. 이 기능이 차별화 요소인지 확인합니다. 차별화 요소는 경쟁 제품이 따라 하기 어려운 강점을 말합니다. 고객이 우리를 고른 이유에 이 기능이 들어 있으면 직접 만들고, 없으면 사거나 붙입니다. 이 한 줄이 나머지 네 단계를 대개 결정합니다.
3. 세 안의 값을 같은 단위로 적습니다. 직접 만들면 개발자 두 명이 여섯 달이니 인건비로 1억 5천만 원, 사오면 연 4천만 원, 붙여 쓰면 거래액의 2.5퍼센트입니다. 여기에 유지 비용을 더합니다. 직접 만든 것은 만든 뒤에도 매년 손이 갑니다.
4. 되돌리는 값을 셉니다. 3년 뒤 상대가 값을 두 배로 올리거나 서비스를 접으면 갈아타는 데 얼마가 드는지 적어 둡니다. 우리 데이터가 상대 쪽에 쌓이는 구조면 이 값이 특히 큽니다.
5. 고른 이유와 다시 볼 시점을 문서에 남깁니다. "지금은 사서 쓰고, 이 기능이 매출의 3할을 넘기면 직접 만드는 쪽을 다시 본다" 처럼 적습니다.

세 갈래의 성격은 서로 다릅니다. 만들기는 시간이 가장 많이 드는 대신 원하는 대로 고칠 수 있습니다. 사기는 돈으로 시간을 사는 쪽이고, 대개 API로 연결합니다. 프로그램끼리 주고받기로 약속한 창구가 API인데, 이 창구가 얼마나 열려 있느냐가 나중에 손볼 수 있는 범위를 정합니다. 손잡기는 파트너십이라고 부르는 쪽으로, 돈 대신 고객이나 채널을 주고받습니다. 비용은 가장 적게 들지만 상대가 응해야 성립하므로 우리가 혼자 정할 수 없습니다.

이 틀이 잘 듣는 자리는 남이 이미 잘 만들어 둔 물건이 있는 영역입니다. 결제, 로그인, 메일 발송, 화상 통화, 지도처럼 요구사항이 회사마다 비슷한 기능이 여기 들어갑니다. 반대로 우리 고객만 겪는 문제를 푸는 기능은 살 물건이 없어서 이 판단을 돌릴 일이 없습니다.

한계는 숫자가 한쪽으로 기운다는 데 있습니다. 비용과 기간만 표에 올리면 거의 항상 사는 쪽이 이깁니다. 표에 안 잡히는 것이 셋 있기 때문입니다. 첫째는 상대에게 묶이는 정도입니다. 값을 올려도 옮길 수 없는 상태가 되면 그때부터 가격은 상대가 정합니다. 둘째는 우리 서비스가 상대 서비스만큼만 안정적이 된다는 점입니다. 상대가 멈추면 우리도 멈추는데, SLA에 적힌 보상은 대개 그달 이용료 수준이라 잃은 고객을 되돌려 주지는 않습니다. 셋째는 고객 데이터가 남의 서버에 쌓이는 문제입니다.

시점도 한계입니다. 쓰는 양이 열 배가 되면 사서 쓰던 비용이 직접 만드는 비용을 넘어서고, 그때는 답이 뒤집힙니다. 그래서 4단계의 되돌리는 값과 5단계의 재검토 시점을 안 적어 두면 틀이 헛돕니다.

"이거 빌드-바이-파트너로 한번 정리해 주실 수 있어요?"

세 안을 같은 표에 올려 비용과 기간과 이탈 비용을 비교해 달라는 요청입니다.

"그건 우리 차별화가 아니니까 사서 씁시다."

직접 만들 이유가 없다는 판단이고, 동시에 그 영역의 개선 요청을 앞으로 받지 않겠다는 선언이기도 합니다.

"파트너 쪽이 제일 싼데, 상대가 우리랑 할 이유가 있나요?"

제휴는 우리가 정하는 것이 아니라 상대의 동의가 필요하다는 지적입니다.

페이지덱이 기업 고객용 결제를 붙이던 분기의 장면입니다. 지현이 세 안을 한 장에 올렸습니다. 직접 만들면 개발자 두 명이 여섯 달, 결제 대행사를 쓰면 거래액의 2.5퍼센트, 회계 서비스와 손잡으면 수수료는 없지만 우리 고객 명단을 상대와 나눠야 했습니다.

규원이 고른 것은 두 번째였습니다. 이유는 값이 아니라 순서였습니다. 결제가 늦어지면 유료 전환 자체가 열 달 밀리는데, 그 열 달에 잃는 매출이 수수료보다 컸습니다. 대신 월 거래액이 10억 원을 넘으면 수수료가 직접 만드는 비용을 넘어서니 그때 다시 본다는 줄을 문서에 남겼습니다.

한 번 고르면 끝나는 결정으로 읽는 경우가 가장 많습니다. 표를 만들고 회의를 열어 결론을 냈으니 마무리된 것처럼 보이기 때문입니다. 하지만 세 안의 값은 규모에 따라 움직입니다. 거래액이 열 배가 되면 수수료도 열 배가 되지만 직접 만드는 비용은 그대로라, 작년에 맞던 답이 올해는 틀립니다. 재검토 시점을 안 적어 두면 아무도 다시 꺼내지 않고, 수수료만 몇 년 더 나갑니다.

싸게 끝내는 방법을 고르는 틀로 읽는 것도 흔합니다. 세 안 중 당장 돈이 덜 드는 쪽을 고르는 일처럼 보이니 그럴듯합니다. 그런데 이 틀이 실제로 묻는 것은 어디에 우리 시간을 쓸 것인가입니다. 직접 만들기로 한 영역은 앞으로 몇 년간 사람을 붙이겠다는 뜻이고, 사기로 한 영역은 그만큼 손을 떼겠다는 뜻입니다. 싼 쪽만 좇다 보면 고칠 수 있는 영역이 하나도 안 남고, 경쟁사와 같은 부품으로 같은 제품을 만들게 됩니다.