SDK

SDK 는 남이 만든 플랫폼이나 서비스를 내 코드에서 바로 쓰게 해 줍니다. 그것을 만든 쪽이 필요한 라이브러리와 도구를 한 벌로 묶어 내놓습니다. 휴대폰 앱을 만드는 도구 묶음을 가리킬 때가 있습니다. 원격 서비스를 부르는 코드 묶음을 가리킬 때도 있습니다.

상세

조립식 책장을 사면 상자 안에 판자와 나사만 들어 있지 않습니다. 그 나사에 맞는 육각 렌치와 조립 설명서가 함께 들어 있습니다. 공구함을 뒤지지 않고 상자 하나로 조립을 끝냅니다.

SDK(Software Development Kit, 소프트웨어 개발 키트)는 그 상자에 해당합니다. 플랫폼이나 서비스를 만든 쪽이, 그것을 쓰는 프로그램을 짜는 데 드는 코드와 도구를 한 벌로 묶어 개발자에게 건넵니다. 그 한 벌을 만들어 내놓는 쪽을 공급자라고 부릅니다.

공급자가 만든 것은 둘 중 하나입니다. 하나는 플랫폼입니다. 플랫폼은 다른 프로그램이 그 위에서 돌도록 바탕을 깔아 줍니다. 휴대폰 운영체제나 게임기가 그렇습니다. 다른 하나는 네트워크 건너편에서 도는 서비스입니다.

한 벌에는 대개 라이브러리가 들어 있습니다. 라이브러리는 내 코드가 불러 쓰는 남의 코드 묶음입니다. 여기에 도구와 문서와 예제 코드가 붙습니다.

공급자가 이렇게 챙겨 주는 까닭은 그 플랫폼 위에서 돌거나 그 서비스를 부르는 방법을 공급자가 제일 잘 알기 때문입니다. 쓰는 쪽이 저마다 그 방법을 알아내 짜면 같은 코드를 쓰는 곳마다 새로 짭니다. 짠 코드마다 실수도 다르게 납니다.

SDK 가 가리키는 두 묶음

SDK 라는 말은 두 묶음을 가리킵니다. 둘은 내 코드가 무엇을 상대하느냐로 갈립니다. 플랫폼 SDK 로 만든 프로그램은 그 플랫폼 위에서 돕니다. 서비스 SDK 를 넣은 프로그램은 그 서비스를 부릅니다.

아래 표에서 두 묶음을 같은 질문으로 견줍니다.

플랫폼 SDK 는 그 플랫폼용 프로그램을 만드는 도구 전부입니다. 서비스 SDK 는 서비스 하나를 부르는 코드만 담습니다.

서비스 SDK 는 클라이언트 라이브러리라고도 부릅니다. 서버를 부르는 쪽인 클라이언트에 들어가는 라이브러리라는 뜻입니다. 둘은 같은 것을 가리킵니다. 공급자가 공식으로 내놓은 것에 SDK 라는 이름이 더 자주 붙습니다.

플랫폼 SDK 에 드는 도구

플랫폼 SDK 는 그 플랫폼에서 도는 프로그램을 처음부터 끝까지 만드는 데 필요한 것을 모읍니다. 휴대폰 앱을 만드는 모바일 개발이 대표적인 쓰임입니다. 한 벌에 드는 도구는 대개 이렇습니다.

이 도구들은 서로 버전이 맞아야 돕니다. 컴파일러가 만든 결과를 에뮬레이터가 못 읽으면 개발이 멈춥니다. 공급자가 한 벌로 묶어 내는 까닭이 여기 있습니다.

플랫폼 SDK 는 플랫폼의 버전을 따라 새로 나옵니다. 새 운영체제 버전에서 생긴 기능을 쓰려면 그 버전에 맞춘 SDK 가 있어야 합니다.

이름에 키트를 단 도구가 여기 속합니다. 안드로이드 앱을 만드는 Android SDK 가 그렇습니다. 자바 프로그램을 만드는 JDK(Java Development Kit, 자바 개발 키트)도 이름부터 개발 키트입니다.

서비스 SDK 가 대신 짜 주는 일

서비스 SDK 는 네트워크 건너편 서비스를 부르는 일을 내 언어의 함수 호출로 바꿉니다. 서비스가 무엇을 내놓는지부터 봅니다.

서비스는 API(Application Programming Interface, 응용 프로그램 인터페이스)를 내놓습니다. API 는 무엇을 보내면 무엇이 돌아오는지를 정해 둔 약속입니다. 웹 서비스라면 그 약속은 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약) 요청과 응답으로 적힙니다.

많은 서비스는 요청마다 서명을 요구합니다. 서명은 이 요청을 누가 보냈는지 증명하는 값입니다. 서비스에게서 받아 둔 비밀 열쇠로 요청 내용을 계산해 만듭니다. 아래 코드의 secret_key 가 그 비밀 열쇠입니다.

SDK 없이 이 약속을 지키려면 요청 하나에 여러 일을 손으로 해야 합니다. 아래는 파일 하나를 올리는 요청을 직접 짠 모양입니다.

body = json.dumps({"name": "a.txt"})
sig = sign(secret_key, body)
res = http.post(url, body, headers(sig))
if res.status == 503:
    res = retry(res)
info = json.loads(res.text)

값을 글자로 바꾸기, 서명 붙이기, 실패하면 다시 보내기, 답을 풀어 읽기가 다 내 코드에 있습니다. 같은 일을 SDK 로 하면 두 줄이 됩니다. 돌아온 답은 셋째 줄처럼 객체의 필드로 바로 읽습니다.

client = Storage(secret_key)
info = client.upload("a.txt")
print(info.size)  # 1024

손으로 하던 일은 사라진 것이 아니라 SDK 안으로 들어갔습니다. SDK 가 속에서 하는 일은 대개 다섯입니다.

이 다섯이 한 번의 호출 안에서 어떤 순서로 도는지 그려 보면 이렇습니다. 첫 요청이 실패해 한 번 다시 보내는 경우입니다.

sequenceDiagram
    participant 코드 as 내 코드
    participant SDK
    participant 서비스
    코드->>SDK: upload("a.txt")
    Note over SDK: 직렬화하고 서명을 붙인다
    SDK->>서비스: 요청
    서비스-->>SDK: 잠깐 지나가는 실패
    Note over SDK: 조금 기다렸다 재시도
    SDK->>서비스: 같은 요청
    서비스-->>SDK: 응답
    Note over SDK: 역직렬화
    SDK-->>코드: info 객체

내 코드는 첫 호출과 마지막 결과만 봅니다. 가운데의 실패와 재시도는 SDK 안에서 끝납니다. 대신 안에서 무슨 일이 있었는지는 내 코드에서 안 보입니다.

약속인 API 와 코드인 SDK

API 는 약속입니다. SDK 는 그 약속을 지키는 코드입니다. 그래서 API 하나에 SDK 가 언어마다 따로 나옵니다.

자바로 짜는 팀과 파이썬으로 짜는 팀은 같은 서비스를 부릅니다. 그래도 쓰는 SDK 는 서로 다릅니다. 여러 SDK 는 모양이 달라도 끝에는 같은 API 를 부릅니다.

SDK 는 API 위에 얹힌 한 겹입니다. API 를 대신하지 않습니다. SDK 를 안 쓰고 API 를 바로 불러도 같은 일이 됩니다.

언어마다 SDK 를 손으로 짜면 API 가 바뀔 때마다 여러 벌을 같이 고쳐야 합니다. 그래서 API 를 적어 둔 설명 문서에서 SDK 코드를 기계로 뽑아내기도 합니다. 이 일을 코드 생성이라고 합니다.

아래 그림은 설명 문서 하나에서 언어별 SDK 가 뽑혀 나오는 모양입니다. 뽑힌 SDK 는 모두 같은 API 를 부릅니다.

flowchart TD
    D["API 설명 문서"] --> G["코드 생성"]
    G --> J["자바 SDK"]
    G --> P["파이썬 SDK"]
    G --> S["자바스크립트 SDK"]
    J --> A["서비스의 API"]
    P --> A
    S --> A

라이브러리 · 프레임워크와 가르는 기준

SDK 와 자주 섞여 쓰이는 이름이 둘 있습니다. 셋은 무엇을 담느냐와 누가 누구를 부르느냐로 갈립니다.

SDK 는 라이브러리를 품습니다. 서비스 SDK 처럼 라이브러리 하나만 담은 SDK 도 있습니다. 그래서 두 말이 겹쳐 쓰이는 일이 잦습니다.

프레임워크는 부르는 방향이 반대입니다. 흐름을 프레임워크가 쥡니다. 내 코드는 정해진 때에 불려 나옵니다. 이렇게 부르는 쪽이 뒤바뀌는 것을 제어의 역전이라고 합니다.

SDK 를 쓸 때 치르는 값

SDK 는 일을 덜어 주는 만큼 내 프로젝트에 짐을 하나 더 얹습니다. 짐은 네 갈래로 옵니다 — 딸려 오는 의존성, 숨은 기본값, 버전 교체, 앱 안의 남의 코드입니다.

딸려 오는 의존성. 내 프로젝트가 기대어 도는 바깥 코드를 의존성이라고 부릅니다. SDK 를 넣으면 SDK 자신이 기대는 라이브러리도 같이 들어옵니다.

그렇게 들어온 라이브러리가 내 프로젝트가 이미 쓰던 것과 버전이 어긋날 수 있습니다. 이렇게 버전이 어긋나는 것을 의존성 충돌이라고 합니다. 한쪽 버전에 맞추면 다른 쪽이 깨질 수 있습니다.

숨은 기본값. SDK 는 재시도 횟수와 타임아웃을 자기 기본값으로 정해 둡니다. 타임아웃은 답을 얼마나 기다렸다 포기할지 정한 시간입니다. 서버가 느려질 때 요청이 왜 오래 매달리는지 보려면 그 기본값부터 찾아야 합니다.

버전 교체. 공급자는 SDK 의 옛 버전 지원을 언젠가 끊습니다. 그 전에 새 버전으로 옮겨야 합니다. 옮기다 보면 함수 이름이나 인자가 바뀐 곳을 고쳐야 합니다.

새 버전이 옛 버전을 쓰던 코드를 깨뜨리지 않는 성질을 하위 호환이라고 합니다. 하위 호환이 깨진 곳마다 내 코드를 고쳐야 합니다.

앱 안의 남의 코드. 앱에 넣는 SDK 는 내 앱 안에서 내 앱과 같은 권한으로 돕니다. 그 코드가 무엇을 하는지는 내가 짠 코드처럼 들여다보기 어렵습니다. 넣는 SDK 가 늘수록 앱의 설치 파일도 커집니다.

SDK 를 고르는 기준

서비스 SDK 는 쓸지 말지를 고를 수 있습니다. 안 쓰면 API 를 바로 부릅니다. HTTP 클라이언트로 API 에 요청을 직접 보낸다는 뜻입니다. 이때 요청을 보내는 곳이 엔드포인트, 곧 API 가 요청을 받으려고 열어 둔 주소 하나하나입니다.

부를 엔드포인트가 한두 개뿐이면, SDK 가 덜어 주는 일보다 SDK 가 끌고 오는 의존성이 더 짐이 될 수 있습니다. 흔한 경우마다 어느 쪽을 고르는지 아래 표에 적었습니다.

플랫폼 SDK 는 고를 일이 드뭅니다. 그 플랫폼의 기기 기능은 대개 SDK 를 거쳐야만 부를 수 있습니다. 그 플랫폼용 앱을 만든다면 SDK 가 출발점입니다.

관련 항목

SDK 한 벌을 이루는 구성 요소

라이브러리 · 컴파일러 · 빌드 도구 · 에뮬레이터 · 디버거 · 헤더 파일 · API 문서 · 예제 코드

SDK 가 겨누는 플랫폼

플랫폼 · 운영체제 · Android · 모바일 개발 · 웹 브라우저 · 클라우드 컴퓨팅 · 임베디드 시스템

SDK 가 감싸서 부르는 원격 인터페이스

API · 엔드포인트 · HTTP · REST · gRPC · OpenAPI · 코드 생성 · API 버전 관리

서비스 SDK 가 속에서 대신하는 처리 단계

직렬화 · 역직렬화 · 인증 · 요청 서명 · 재시도 · 지수 백오프 · 타임아웃 · 페이지네이션 · 예외

SDK 와 역할이 겹치는 호출 코드

클라이언트 · 클라이언트 라이브러리 · HTTP 클라이언트 · 스텁 · 래퍼

SDK 와 맞세워지는 코드 묶음

라이브러리 · 프레임워크 · 툴킷 · 표준 라이브러리 · 제어의 역전

SDK 를 이름에 단 제품

Android SDK · Android NDK · JDK · AWS SDK · SDKMAN

SDK 를 들이면 따라오는 관리 부담

의존성 · 의존성 충돌 · 패키지 관리자 · 시맨틱 버저닝 · 하위 호환 · 사용 중단 · 공급망 공격