연동 파트너

한 회사가 고객의 업무 전부를 자기 제품 안에서 끝내려던 시절이 있었습니다. 문서도 우리 것으로 쓰고, 회의도 우리 것으로 하고, 알림도 우리 것으로 받게 만들면 고객이 떠나지 않을 것이라는 계산이었습니다. 그런데 고객의 하루는 처음부터 여러 도구에 걸쳐 있었습니다. 기획서는 문서 도구에, 대화는 메신저에, 일정은 캘린더에 있고 사람은 그 사이를 하루에 수십 번 오갑니다.

그래서 같은 내용을 옮겨 붙이는 일이 업무의 일부가 됐습니다. 문서에서 결정된 사항을 복사해 메신저에 다시 붙이고, 회의 링크를 만들어 문서 맨 위에 붙여 넣는 식입니다. 옮기는 과정에서 빠뜨리면 팀의 절반이 바뀐 결정을 모른 채 일합니다.

영업 자리에서 이 문제는 늘 같은 질문으로 나타났습니다. "저희는 메신저를 쓰는데 문서가 수정되면 거기로 알림이 가나요?" 안 된다고 답하면 검토 자체가 끝났고, 된다고 답하려면 그 메신저 회사가 만든 창구를 우리 쪽에서 불러 쓸 수 있어야 했습니다. 기능 하나를 직접 만드는 문제가 아니라 상대 회사와 관계를 맺어야 하는 문제였던 셈입니다.

연동 파트너는 이 관계를 가리키는 이름입니다. 대신 팔아 주는 파트너와 다릅니다. 상대는 우리 제품을 팔지 않고, 우리도 상대 제품을 팔지 않습니다. 각자 자기 제품을 계속 팔면서, 두 제품이 고객의 화면 안에서 이어져 있다는 사실 자체를 서로의 이점으로 삼습니다.

두 제품이 서로의 API를 호출하는 것으로 이어집니다. API 는 프로그램끼리 무엇을 어떤 형식으로 주고받을지 미리 약속해 둔 창구인데, 이 약속이 공개돼 있어야 상대 회사 개발자가 우리 제품을 건드릴 수 있습니다.

실제로는 네 단계를 밟습니다.

1. 무엇을 잇는지 정합니다. 두 제품이 겹치는 지점 하나를 고르는 일입니다. 문서가 수정되면 메신저에 알림을 보내는 것, 문서 안에서 화상 회의를 바로 여는 것처럼 사용자가 오가던 구간을 잡습니다.
2. 권한을 넘기는 방법을 정합니다. 사용자가 비밀번호를 상대에게 알려 주지 않고도 "이 앱이 내 메신저에 글을 쓰도록 허용" 만 내줄 수 있어야 합니다. OAuth가 그 표준이고, 대부분의 연동이 이 절차 위에서 돌아갑니다.
3. 사건이 생겼을 때 알리는 방법을 정합니다. 상대가 우리에게 계속 물어보게 하는 대신, 우리 쪽에서 일이 생긴 순간 상대 서버로 먼저 알림을 쏘는 웹훅을 씁니다.
4. 사용자가 켜는 자리를 만듭니다. 설정 화면의 연결 버튼 하나면 충분할 때도 있고, 상대 회사가 운영하는 앱 목록에 우리 앱을 올려야 할 때도 있습니다.

붙이고 나면 유지가 시작됩니다. 상대가 규격을 바꾸면 우리 기능이 멈추는데, 기존 방식이 더는 통하지 않게 되는 변경을 브레이킹 체인지라고 부릅니다. 고객은 어느 쪽 잘못인지 구분하지 않고 우리에게 먼저 연락하므로, 상대의 공지 채널을 계속 지켜보는 담당자를 정해 두는 편이 낫습니다.

연결되는 자리는 대체로 네 갈래입니다. 로그인, 알림, 데이터, 결제입니다. 로그인은 회사 계정 하나로 여러 도구에 들어가게 하는 싱글 사인온 연동이고, 알림은 한쪽에서 생긴 일을 다른 쪽 화면에 띄우는 연동입니다. 데이터는 양쪽의 명단이나 기록을 같은 상태로 맞춰 두는 것이고, 결제는 구독료를 상대의 청구 시스템에서 함께 걷는 형태입니다.

규모가 커진 제품은 연동을 하나씩 맺는 대신 자리를 열어 둡니다. 다른 서비스가 그 위에 얹혀 돌아가도록 설계된 제품을 플랫폼이라고 하고, 그 위에 올라온 연동을 모아 보여 주는 목록을 마켓플레이스라고 합니다. 이 단계가 되면 연동 파트너는 일일이 계약하는 상대가 아니라 규격을 지키면 누구나 들어올 수 있는 집단이 됩니다.

대가를 주고받지 않는 경우가 많다는 점도 다른 파트너 형태와 갈립니다. 리셀러는 판 금액의 일부를 수수료로 가져가지만, 연동은 양쪽 모두 자기 제품이 더 쓰이길 바라서 하는 일이라 돈이 오가지 않는 쪽이 보통입니다. 대신 개발 인력과 유지보수 시간이 비용으로 들어갑니다. 연동 하나를 붙이는 데 개발자 한 명이 3주를 쓰고, 그 뒤로도 분기마다 손보는 일이 생긴다고 잡으면 크게 틀리지 않습니다.

"그 메신저는 연동 파트너라 알림 기능은 이번 분기에 나갑니다."

이미 기술적 연결과 협의가 되어 있어 일정만 잡으면 되는 상대라는 뜻입니다.

"연동 파트너는 맞는데 마켓플레이스 등재는 아직이에요."

기능은 붙었지만 상대 회사의 앱 목록에 오르지 않아 그쪽 고객이 우리를 발견할 경로는 없다는 말입니다.

"저쪽 API 버전이 올라가서 연동 파트너 담당자랑 일정 맞추고 있어요."

상대 규격 변경으로 우리 기능이 멈출 수 있어 대응 시점을 조율 중이라는 뜻입니다.

페이지덱에서 이 이야기는 영업 회의에서 먼저 나옵니다. 수아가 잃은 거래 다섯 건 중 세 건에서 같은 이유가 나왔다고 보고하면, 규원이 그 상대 회사와 이야기를 열지 결정합니다. 결정이 나면 태오가 상대의 개발 문서를 읽고 3주짜리 일감으로 잡습니다.

관계가 만들어진 뒤에도 일은 남습니다. 상대가 구버전 창구를 6개월 뒤 닫는다고 공지하면 태오가 그 일정을 팀 달력에 옮겨 적습니다. 우리 계획이 아니라 상대 계획에 우리 일정이 끌려간다는 점이 이 관계의 성격을 잘 보여 줍니다.

연동 파트너를 맺는 일을 계약 문제로 보는 경우가 가장 많습니다. 다른 파트너 형태가 대부분 문서에 서명하는 것으로 시작하니 자연스러운 오해입니다. 하지만 연동은 대개 계약보다 개발이 먼저입니다. 상대 창구가 공개돼 있으면 허락을 구하지 않고 붙일 수 있고, 계약이 필요해지는 것은 그쪽 앱 목록에 오르거나 서로 이름을 같이 쓸 때입니다. 이 순서를 뒤집으면 몇 달 동안 담당자를 찾아 메일을 보내는 사이 경쟁사는 이미 기능을 내보냅니다.

한 번 붙이면 끝이라는 생각도 자주 봅니다. 기능이 동작하는 순간 일이 끝난 것처럼 보이기 때문입니다. 실제로는 상대가 규격을 바꿀 때마다 우리 쪽에 일이 생기고, 그 일정은 우리가 정하지 못합니다. 유지 담당을 두지 않으면 어느 아침에 고객 문의로 고장을 알게 되고, 그 사이 고객은 우리 제품이 고장 났다고 기억합니다.