Unity
기술은 가능한데 개발은 불가능할 수 있습니다
한*현··수정됨 2026.07.22
전시 콘텐츠 개발자는 왜 모든 기능을 수정할 수 없을까? : API와 SDK가 중요한 이유

API와 SDK가 중요한 이유
전시 프로젝트를 진행하다 보면 종종 이런 요청을 받게 됩니다.
"초상화를 그려주는 로봇이 있으니까 캐리커처도 그릴 수 있게 하면 안 되나요?"
발주처 입장에서 보면 충분히 가능한 이야기처럼 들립니다.
이미 사람 얼굴을 인식하고 그림을 그리는 로봇이 있으니, AI 모델만 살짝 바꾸면 될 것 같기 때문입니다. 실제로 기술적으로는 충분히 구현 가능한 일입니다. 하지만 개발자는 왜 바로 "가능합니다"라고 답하지 못할까요?
그 이유는 기술의 유무가 아니라, '그 기술에 우리가 접근할 수 있는가'에 달려 있기 때문입니다.
기술이 존재하는 것과 구현할 수 있는 것은 다르다
개발자의 관점에서 새로운 장비를 검토할 때 가장 먼저 확인하는 질문은 "우리가 그 기술을 제어할 수 있는가?"입니다.
초상화 로봇이 하나의 완성된 제품으로 판매된다고 가정해 봅시다. 우리는 이 제품을 구매하여 설치할 수 있습니다.
하지만 제품이 '블랙박스'처럼 내부가 완전히 닫혀 있다면 어떨까요? 냉장고의 냉각 방식을 우리가 마음대로 바꿀 수 없듯, 제조사가 외부 개발자에게 내부 알고리즘을 수정할 권한을 주지 않는다면 개발자가 할 수 있는 일은 극히 제한됩니다.
제품을 구매해서 사용하는 것과, 제품을 확장하여 새로운 콘텐츠를 만드는 것은 전혀 다른 문제입니다. 이때 개발자가 찾는 열쇠가 바로 API와 SDK입니다.

API와 SDK: '약속'과 '도구'
많은 분이 API와 SDK를 혼동하곤 합니다. 이 둘의 차이를 이해하면 개발자가 왜 장비 선정에 신중한지 알 수 있습니다.
1. API (Application Programming Interface): 대화의 규칙
API는 외부 프로그램이 장비와 통신할 수 있도록 마련된 '공식적인 창구'이자 '규칙'입니다.
비유하자면: 식당의 '메뉴판'과 같습니다. "이 메뉴(기능)를 주문하려면 이렇게 말(데이터)을 전달해야 하고, 그러면 이런 결과(응답)가 나온다"라는 약속입니다.
장점: 장비의 핵심 기능에 접근할 수 있게 해줍니다.
단점: 개발자가 통신 방식, 데이터 형식, 에러 처리 등을 밑바닥부터 직접 구현해야 합니다.
2. SDK (Software Development Kit): 개발을 위한 종합 선물 세트
SDK는 API를 더 쉽고 편리하게 쓰기 위해 제조사가 제공하는 '개발 도구 모음'입니다.
비유하자면: '밀키트(Meal Kit)'와 같습니다. 요리에 필요한 재료와 레시피가 모두 들어있어, 바로 조리(개발)를 시작할 수 있게 해줍니다.
포함 요소: 개발 라이브러리, 예제 코드, 샘플 프로젝트, 기술 문서 등.
장점: 연동 속도가 압도적으로 빠르고, 검증된 코드를 사용하므로 오류 발생 확률이 낮습니다.
구분
API (Interface)
SDK (Kit)
핵심 성격
서비스/장비의 기능 접근 규격 (규칙)
개발자를 위한 종합 도구 모음 (환경)
장점
가볍고 범용적임.
구현 속도가 빠름. 검증된 코드 사용.
단점
연동 코드를 처음부터 짜야 함 (높은 초기 비용).
특정 언어/플랫폼에 종속될 수 있음.

API와 SDK가 있으면 무조건 다 될까?
여기서 중요한 점은 'API와 SDK가 있다고 해서 모든 것을 수정할 수 있는 것은 아니다'라는 사실입니다.
제조사가 초상화 생성 기능만 API로 공개했다면, 우리는 초상화를 요청할 수는 있지만 캐리커처 생성 기능을 새로 만들 수는 없습니다.
즉, "어떤 기능까지 제어할 수 있게 공개되어 있는가"가 핵심입니다. API는 '연동의 최소 요건'을 마련해 주지만, 그 안에서 구현 가능한 기능의 한계는 제조사의 설계에 달려 있습니다.
전시 콘텐츠 개발은 연결의 작업이다
전시 콘텐츠 개발은 단순히 화면을 만드는 일이 아닙니다.
하나의 체험 콘텐츠 안에서도 다양한 장비와 시스템이 함께 동작합니다.
예를 들어 관람객이 체험을 시작하면 다음과 같은 과정이 동시에 이루어질 수 있습니다.
키오스크에서 사용자 정보를 입력한다.
카메라가 이미지를 촬영한다.
AI 서버가 데이터를 분석한다.
초상화 로봇이 그림을 생성한다.
결과가 대형 화면에 표시된다.
조명과 음향이 함께 반응한다.
관람객 입장에서는 하나의 체험처럼 보이지만, 개발자 입장에서는 여러 장비와 소프트웨어가 실시간으로 데이터를 주고받는 구조입니다.
그리고 이러한 연결의 대부분은 API와 SDK를 통해 이루어집니다.
그래서 개발자는 API 문서부터 찾는다
전시 프로젝트에서 새로운 장비를 검토할 때 개발자는 가장 먼저 다음과 같은 질문을 합니다.
API를 제공하는가?
SDK를 제공하는가?
어떤 기능까지 제어할 수 있는가?
기술 지원이 가능한가?
많은 사람들은 장비의 성능이나 가격을 먼저 떠올리지만, 개발자의 입장에서는 연동 가능 여부가 더 중요할 때가 많습니다.
아무리 뛰어난 기능을 가진 제품이라도 외부에서 접근할 방법이 없다면 프로젝트에 활용할 수 있는 범위가 크게 제한되기 때문입니다.
반대로 기능은 다소 단순하더라도 API와 SDK가 잘 제공되는 제품은 다양한 전시 콘텐츠로 확장할 수 있습니다.
마무리
전시 콘텐츠 개발은 단순히 새로운 기능을 만드는 작업이 아닙니다.
다양한 장비와 시스템을 연결하여 하나의 체험으로 완성하는 과정에 가깝습니다.
그래서 개발자는 새로운 기술이나 제품을 검토할 때 단순히 "무슨 기능이 있는가"만 보지 않습니다.
그보다 먼저 이런 질문을 던집니다.
"우리는 이 기능에 접근할 수 있는가?"
초상화를 그리는 기술이 존재하는 것과, 그 기술을 활용하여 새로운 전시 콘텐츠를 만드는 것은 전혀 다른 문제입니다.
그리고 그 차이를 결정하는 것이 바로 API와 SDK입니다.
전시 콘텐츠의 가능성을 결정하는 것은 기술 자체가 아니라, 그 기술과 연결될 수 있는 방법이 준비되어 있는지 여부일지도 모릅니다.
읽기 도구
약 6분 읽기
이 글이 도움이 되었나요?