SDK와 API의 의미
서로 다른 언어를 하나로 잇는 다리
게임 QA를 진행하다 보면 사업팀에 자주 들려오는 말이 있습니다.
“SDK 오류로 로그인이 안 돼요”, “API 연결이 끊겼어요”
그럴 때마다 머릿속에 물음표가 떠오르죠.
“SDK? API? 도대체 뭐길래 게임이 멈추는 걸까?”
사실 SDK와 API는 단순한 기술 용어가 아닙니다.
서로 다른 언어와 시스템이 같은 목표를 향해 움직이게 만드는 연결 구조이자,
비즈니스 담당자와 개발자가 ‘같은 언어로 대화할 수 있게 해주는 협업의 언어’입니다.
ℹ️ 언어가 달라도 게임은 멈추지 않는다
하나의 게임을 만든다고 해도 여러 언어가 사용됩니다. 예를 들면 이렇게 말이죠.
클라이언트(화면): C++
서버(운영): Java
AI 기능(추천, 매칭, 분석): Python
언어가 이렇게 제각각인데도, 서비스는 하나처럼 작동합니다.
그 이유는, 각 언어가 직접 대화하지 않아도 ‘중간에서 통역해 주는 구조’가 있기 때문입니다.
그 역할을 하는 것이 바로 API(Application Programming Interface),
그리고 그 API를 쉽게 쓰게 해주는 SDK(Software Development Kit)입니다.
ℹ️ API –시스템 간의 ‘공용 대화 문법’
API는 서로 다른 프로그램이 약속된 규칙으로 대화할 수 있게 하는 인터페이스입니다.
“이 기능을 이렇게 요청하세요.”
“이 요청을 보내면 이런 결과를 돌려드릴게요.”
예를 들어 유저가 결제를 시도할 때,
클라이언트는 서버로 “결제 요청 API”를 보냅니다.
서버는 “성공” 또는 “실패”를 데이터 형태의 응답으로 되돌려줍니다.
ℹ️ SDK – 개발을 빠르고 정확하게 만드는 ‘도구 상자’
API가 ‘대화의 문법서’라면, SDK는 그 대화를 쉽게 구현하도록 도와주는 개발 키트입니다.
비유하자면,
API는 “요리 레시피”,
SDK는 “레시피 + 재료 + 조리 도구 세트”입니다.
로그인 기능을 직접 코드로 짜면 며칠이 걸리지만,
SDK에 포함된 로그인 모듈을 쓰면 몇 줄이면 충분합니다.
즉, SDK는 API뿐 아니라 라이브러리, 예제 코드, 문서, 인증 구조 등을 포함한
‘표준화된 도구 상자’로서 개발 속도와 품질을 함께 높여줍니다.
ℹ️ 언어가 달라도 대화가 가능한 이유
언어가 달라도 서로 대화할 수 있는 이유는 공통된 대화 규칙이 있기 때문입니다.
마치 사람이 언어가 달라도 ‘영어’라는 공용어로 소통하듯,
프로그램들도 데이터를 주고받을 때 공통 약속을 따릅니다.
이 약속을 통신 규칙(프로토콜)이라 부르고,
데이터를 주고받는 형식(서류 양식처럼 생긴 구조)을 데이터 형식 혹은 데이터 포맷이라고 합니다.
대부분의 시스템은 이때 HTTP라는 통신 규칙과 JSON이라는 데이터 형식을 사용합니다.
그래서 C++이든, Java든, Python이든 모두 같은 방식으로 요청을 보내고 응답을 받을 수 있는 거죠.
즉, API는 언어가 달라도 공통된 대화 체계를 만들어주는 ‘약속의 문서’입니다.
ℹ️ 조금 더 깊이 들어가 볼까요?
지금까지의 내용을 조금 더 구체적으로 정리하면 이렇습니다.
• API는 소프트웨어가 다른 소프트웨어의 기능을 사용하기 위해 거쳐야 하는 ‘중간 창구’입니다.
예를 들어 내 게임이 결제 기능을 직접 만들지 않고 다른 회사의 결제 시스템을 사용한다면, 그 회사가 제공하는 API를 통해 요청을 보내고 응답을 받게 됩니다.
• SDK는 이 API를 더 쉽게 다룰 수 있게 해주는 패키지형 도구 세트입니다.
특히 다른 회사(예: AWS, MS, 구글, 애플, 네이버 등)의 로그인과 같은 기능을 우리 게임에 연결하려면,
해당 회사에서 제공하는 SDK를 설치해 연동합니다.
즉, SDK는 외부 기술을 우리 서비스 안에 끌어들이는 다리입니다.
• JSON은 데이터를 담는 ‘주머니’ 같은 역할을 합니다.
게임 클라이언트가 서버에 “유저 A의 로그인 정보”를 보낼 때,
그 내용을 구조화된 형태로 포장해 전달하는 그릇이 JSON입니다.
서버는 같은 JSON 형식으로 결과를 응답하죠.
덕분에 서로 다른 언어(C++, Java, Python 등)라도 같은 구조로 대화할 수 있습니다.
ℹ️ CRUD 작업과 HTTP 상태 코드
API가 실제로 주고받는 대화는 데이터를 다루는 네 가지 기본 동작 'CRUD' (Create, Read, Update, Delete)과 이에 따른 네 가지 방식 (Method, 함수)로 구성됩니다.
각 요청의 결과는 아래와 같은 HTTP 상태 코드로 표현됩니다.
이렇게 정해진 규칙 덕분에,
클라이언트와 서버가 데이터를 주고받을 때 서로의 역할을 혼동하지 않고 일관된 방식으로 협업할 수 있습니다.
즉, API는 단순한 “데이터 송수신 통로”가 아니라,
요청과 응답을 통해 서로의 상태를 정확히 주고받는 정교한 대화 구조입니다.
ℹ️ 언어가 달라도 하나로 작동하는 구조
한 글로벌 MMORPG 프로젝트를 예로 들어보겠습니다.
클라이언트: C++
서버: Java
AI 매칭 시스템: Python
이 세 언어는 직접 대화할 수 없지만,
각각의 SDK와 REST API를 통해 매끄럽게 연결됩니다.
(1) C++ 클라이언트가 Java 서버의 REST API를 호출해 로그인 요청을 전송합니다
(2) Java 서버는 이를 처리하고 JSON 형태의 결과를 응답합니다
(3) Python 기반의 AI 매칭 시스템은 같은 API를 통해 데이터를 받아 학습하고,
결과를 다시 API 형태로 서버에 전달합니다
실제 운영 환경에서는 이 통신이 실시간이 아닌 비동기 구조(예: 메시지 큐, 데이터 스트림)로 이루어질 수도 있습니다.
하지만, 본질은 같습니다.
서로 다른 언어가 공통된 API 규칙을 통해 같은 시스템 안에서 협업한다는 점입니다.
*참고. REST API란 무엇일까?
우리가 일상적으로 말하는 대부분의 API는 사실 REST API를 뜻합니다.
REST(Representational State Transfer)는
웹 환경에서 서로 다른 시스템이 데이터를 주고받기 위해 만들어진 가장 보편적인 규칙 체계입니다.
쉽게 말해, “URL로 요청을 보내고, JSON 형식으로 결과를 받는 방식”입니다.
예를 들어 /user/login으로 요청을 보내면
서버가 {“result”: “success”} 같은 응답을 보내주는 식이죠.
REST API는 구조가 단순하고 호환성이 뛰어나,
오늘날 대부분의 게임 서버·클라우드·AI 시스템이 이 방식을 사용합니다
ℹ️ 왜 비즈니스 담당자에게 중요한가
비즈니스 담당자에게 SDK와 API를 이해하는 일은
‘팀이 어떤 구조로 연결되어 있는지 읽는 능력’을 갖는 것입니다.
SDK 기반 기능이라면 → 이미 표준화되어 있어 확장이 쉽습니다.
API 기반 연결이라면 → 수정 시 다른 기능에 영향을 줄 수 있습니다.
그래서 이렇게 말할 수 있습니다.
“이건 SDK 기반이라 바로 확장 가능해요.”
“이건 API 직접 연동 구조라 변경 시 조정이 필요해요.”
이 대화가 가능한 순간, 비즈니스 담당자는 단순히 요청하는 역할을 넘어
기술적 구조를 전략적으로 판단하는 파트너가 됩니다.
♻️ 마무리하며 …
다음 글에서는 SDK와 API가
클라우드와 AI 시대에 어떤 역할을 하고 있는지 살펴보겠습니다.
* 위 내용은 저자의 개인적인 의견이며, 본문에서 언급된 기업의 공식적인 입장과는 무관합니다