SDK

기능을 빌려 쓰는 방법이 규격 문서 하나뿐이던 시절이 있었습니다. 결제를 붙이려는 회사는 API, 곧 프로그램끼리 무엇을 어떻게 주고받기로 약속한 창구의 설명 문서를 받아 읽고 그 약속대로 통신하는 코드를 처음부터 썼습니다.

문제는 그 코드가 모든 회사에서 거의 똑같다는 점이었습니다. 주소를 붙이고, 열쇠 값을 헤더에 넣고, 요청이 실패하면 몇 초 뒤에 다시 보내고, 돌아온 결과를 자기 언어의 자료형으로 바꾸는 일입니다. 60쪽짜리 문서를 읽고 300줄을 써야 겨우 첫 결제가 통과했고, 그 300줄을 옆 회사도 똑같이 다시 썼습니다.

빌려주는 쪽도 손해였습니다. 지원 창구로 오는 질문이 매번 같았습니다. 서명을 어떻게 만드느냐, 실패했을 때 몇 번까지 다시 보내야 하느냐 같은 것들입니다. 같은 답을 100번 쓰고 나면 그 답을 코드로 만들어 배포하는 편이 싸다는 계산이 섭니다.

SDK는 그 반복되는 300줄을 공급하는 쪽이 미리 만들어 묶어 놓은 것입니다. 붙이는 회사는 그 묶음을 자기 제품에 설치하고 함수 몇 개를 부릅니다. 규격을 공개하는 데서 멈추지 않고 규격을 쓰는 코드까지 함께 주는 방식입니다.

같은 연동 코드를 고객사마다 처음부터 다시 쓰게 되는 낭비를 없앱니다. 묶음 안으로 들어가는 것은 다섯 가지입니다.

1. 통신과 인증 — 어느 주소로 보낼지, 열쇠 값을 어디에 넣을지, 만료된 토큰을 언제 갱신할지를 안쪽에서 처리합니다.
2. 재시도와 오류 처리 — 네트워크가 끊겼거나 요청이 한도를 넘겨 거절됐을 때 몇 초 뒤에 몇 번까지 다시 보낼지가 이미 정해져 있습니다.
3. 자료형 변환 — 오간 데이터를 그 언어에서 다루기 쉬운 형태로 바꿔 줍니다. 붙이는 쪽은 문자열을 뜯는 코드를 쓰지 않습니다.
4. 기기와 운영체제 차이 — 모바일 앱에 붙이는 묶음이면 안드로이드와 아이폰의 다른 점을 안쪽에서 흡수해 같은 함수 이름을 내줍니다.
5. 진단 — 무엇을 보내고 무엇을 받았는지 기록이 남고, 에러 트래킹 묶음처럼 예외를 모아 분류해 보내 주는 기능이 딸려 오는 경우도 많습니다.

효과는 시간으로 나타납니다. 문서 60쪽을 읽고 300줄을 쓰던 일이 다섯 줄로 줄어들면 붙이는 데 3주가 아니라 반나절이 걸립니다. 공급하는 쪽이 얻는 것도 큽니다. 같은 질문이 지원 창구에 쌓이지 않고, 잘못된 사용 방식이 애초에 막힙니다. 열쇠 값을 화면 쪽 코드에 그대로 적어 두는 실수처럼 위험한 사용법을 묶음이 구조로 차단할 수 있습니다.

같은 기능을 붙이는 길은 셋이 더 있습니다. 고르는 기준은 붙이는 쪽이 원하는 자유도와 들일 수 있는 시간입니다.

1. 규격만 받아 직접 호출하기 — 위의 300줄을 자기 손으로 쓰는 방식입니다. 가장 오래 걸리지만 묶음이 지원하지 않는 언어를 쓰거나 동작을 세밀하게 바꿔야 할 때는 이쪽뿐입니다.
2. 웹훅 — 사건이 생기면 상대 서버가 먼저 알려 주는 방식입니다. 결제가 끝났다는 사실만 받으면 되는 일에는 받는 주소 하나만 열어 두면 되고, 설치할 묶음이 없습니다.
3. 화면 조각을 그대로 끼워 넣기 — 공급자가 만든 화면을 자기 화면 안의 틀에 얹습니다. 붙이는 데 한 시간이면 되지만 모양과 문구를 거의 바꿀 수 없습니다.

SDK를 고르지 않는 이유는 대개 그 묶음이 상대의 제품 안에 함께 설치돼 돌아간다는 성질에서 나옵니다.

• 옛 버전이 남습니다. 서버 쪽은 고치면 그 순간 모두에게 적용되지만, 묶음은 고객사가 새 판으로 바꿔 주기 전까지 두 해 전 버전이 그대로 돕니다. 그래서 공급자는 시맨틱 버저닝처럼 변경의 성격을 숫자로 알리는 규칙을 쓰고, 기존 코드를 깨뜨리는 브레이킹 체인지를 되도록 미룹니다.
• 남의 집 살림에 얹힙니다. 묶음이 무거우면 상대 앱의 설치 용량과 실행 속도가 함께 나빠지고, 묶음에서 난 오류가 상대 앱의 오류로 보입니다.
• 언어마다 한 벌씩 필요합니다. 자바스크립트·파이썬·자바를 지원하기로 하면 만들 것도 셋이고 고칠 것도 셋입니다.

"SDK 붙이면 반나절이면 됩니다. 규격 보고 직접 붙이면 사나흘이에요."

연동 비용을 견줘 어느 길로 갈지 정하는 말입니다.

"3.2에서 4.0으로 올리면 호출 방식이 바뀝니다. 고객사 안내부터 보냅시다."

기존 코드를 깨뜨리는 변경이라 미리 알려야 한다는 뜻입니다.

"그 회사는 아직 2.1을 쓰고 있어요. 서버에서 옛 방식도 받아 줘야 합니다."

옛 버전 사용자가 남아 있어 두 방식을 함께 지원해야 한다는 상황 보고입니다.

페이지덱은 다른 회사 화면 안에 문서 편집기를 끼워 넣을 수 있는 묶음을 내놓기로 했습니다. 수아가 기업 고객 셋에서 같은 요청을 받아 온 것이 계기였습니다. 태오는 언어를 세 개만 지원하자고 했고 지현이 동의했습니다. 45명 회사에서 언어를 여섯 개로 벌리면 새 기능을 낼 때마다 여섯 벌을 고쳐야 하고, 그러면 묶음이 본 제품의 속도를 잡아먹습니다.

한 번 내놓으면 끝이라고 보는 경우가 많습니다. 코드를 한 벌 써서 올려 두는 일로 보이기 때문입니다. 하지만 남의 제품 안에 설치된 것은 회수할 수 없습니다. 2.1을 쓰는 고객사가 남아 있으면 서버는 옛 방식과 새 방식을 함께 받아 줘야 하고, 지원하는 판이 늘수록 시험할 조합도 늘어납니다. 이 부담을 계산하지 않고 내놓으면 3년 뒤에 네 개의 판을 동시에 떠받치는 상태가 됩니다.

언어를 하나 늘리는 일이 가볍다고 보는 오해도 흔합니다. 이미 만든 것을 옮겨 쓰면 되니 비용이 조금 붙을 것처럼 느껴집니다. 실제로는 언어마다 예제와 문서와 시험이 한 벌씩 따라붙고, 새 기능을 낼 때 그만큼이 곱해집니다. 세 언어를 지원하는 팀이 네 번째를 더하면 늘어나는 것은 4분의 1이 아니라 앞으로 나올 모든 변경의 3분의 1입니다.