SDK vs API vs Framework vs Library?

개발 1-2년 차에 SDK, API, 프레임워크, 라이브러리에 대한 차이를 구분하지 못해서 찾아본 적이 있다. 

 

 

SDK(Software Development Kit)

- 소프트웨어 개발 키트

- 특정 운영 체제용 앱 개발을 위한 소프트웨어 개발 도구

 

API(Application Programming Interface)

- 응용프로그램 개발 인터페이스

- 프로그램 간 상호 통신을 하기 위한 형식 또는 인터페이스

 

Framework

- 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것

 

Library

- 특정 작업을 위해 쓰인 변수, 함수 등의 모음

 

 

대충 검색하면 이런 식으로 한두 줄로 정의를 내리고 있다. 근데 도대체 무슨 말인지 아무리 읽어봐도 이해가 가지 않았다. 심지어 지금 읽어봐도 잘 모르겠다. 그래서 현업에서 사용하면서 조금이라도 이해한 점을 비유와 허구 속 이야기를 통해 얘기해보려 한다. 아직도 정확하게 이해하고 있는지 모르겠지만 일단 개인적으로 이해한 만큼만 정리해놓도록 하겠다.

 

 

 

카페를 운영하고 싶은 개발자

개발자 김스타 씨는 반복적인 개발에 지쳐 회사를 그만두고 카페를 차리기로 했다. 그동안 차곡차곡 잘 저금하여 어느 정도 예산을 확보를 했지만 부지, 건물, 인테리어 등에 필요한 비용뿐만 아니라 어떻게 시작해야 될지 조차 갈피를 잡지 못하고 있던 중, 자신의 이름과 닮은 카페 프랜차이즈가 눈에 띄었다.

 

스타벅스

 

김스타 씨는 카페 운영을 전부 직접 시작하기보다 스타벅스와 계약을 맺어 스타벅스에서 제공하고 가이드하는 것에 따라서 운영하기로 했다. 근데 문득 개발자 시절 iOS를 개발하던 기억이 떠올랐다. 스타벅스 프랜차이즈 시스템을 통해 카페를 오픈하는 것이 마치 iOS SDK에서 제공된 툴을 이용하여 iOS 앱을 출시하는 것과 비슷하다는 생각이 들었다.

 

스타벅스를 통해 창업에 대한 교육을 받고 제공된 가이드라인을 따라 상권 분석 후 위치를 선정하고 인테리어 등을 진행했다. 이 모든 절차를 직접 하려면 몇 달 몇 년이 걸릴지 상상도 가지 않았는데 스타벅스와 함께 한 달 만에 카페 창업에 성공했다. 김스타 씨는 이러한 스타벅스 프랜차이즈 시스템을 이렇게 명하기로 했다.

 

스타벅스 SDK

 

* 스타벅스는 실제로는 개인이 운영하는 가맹점을 허용하지 않는다고 한다. 상기 및 이후 이야기는 전부 허구이므로 오해 금물.

 

 

스타벅스에서 제공한 운영 매뉴얼

스타벅스 SDK를 통해 성공적으로 카페를 창업한 김스타 씨는 '스타벅스 운영 매뉴얼'에 따라 스타벅스 운영에 필요한 전반적인 내용을 숙지하고 있었다. 특히 커피를 만드는데 필요한 재료를 주문하거나 직원을 고용하는 등은 철저히 매뉴얼에 따라야 된다는 점을 알게 됐다.

 

재고가 떨어지면 본사가 제공한 시스템을 통해 '재고 요청'을 양식에 맞게 제출하면 본사에서 빠르게 물품을 배송해줬다. 직원을 고용하거나 해고하는 것은 본사를 거쳐서 진행할 필요는 없지만 본사에서 제공한 '직원 관리 프로그램'을 통해 적합한 직원만을 뽑거나 해고해야 한 후 입력해야 한다. 해당 프로그램에는 직원의 자격요건이나 결격사유 등 자세히 매뉴얼화되어있고 적합하지 않은 직원을 등록하려고 하면 프로그램에서 자체적으로 에러를 호출하여 등록할 수 없도록 되어있었다.

 

제공된 시스템을 이용해야 하고 정해진 양식을 꼭 지켜야 제대로 된 응답을 받을 수 있다는 점에 있어서 조금 빡빡하다는 생각도 들었지만 상세하게 제시된 매뉴얼만 정확하게 따르면 다른 세부적인 부분은 신경 쓸 필요가 없다고 생각하니 매우 효율적이고 편하다는 것을 깨달았다.

 

근데 문득 이미 추억이 되어버린 초보 개발자 시절 API 문서를 제대로 살펴보지 않고 개발하다가 제대로 된 응답을 받지 못해 며칠밤을 새던 기억이 새록새록 떠올랐다. 마침 직원 관리나 재고 요청도 그런 API들과 비슷하다는 생각이 들었다. 특히 재고 요청은 본사와 통신해야 한다는 점에서 RESTful API(혹은 HTTP API)처럼 동작하는 것 같다고 생각했다. 김스타 씨는 이러한 API 들을 되새기고 그날을 반성하며 이번에는 그런 실수를 하지 않겠다고 마음속으로 외쳤다.

 

직원 관리 API

재고 요청 API

 

 

 

에스프레소 머신에서 스무디는 못 뽑나요?

김스타 씨의 카페를 찾는 손님이 점점 많아져서 새로운 직원들을 몇 명 더 채용했다. 아직 직원들에 대한 교육이 조금 덜 됐지만 워낙 바빠서 일단 현장에 먼저 투입했다. 근데 멀리서 보니 한 직원이 무언가 쩔쩔매고 있는 것 같았다.

 

그 직원에게 가서 무슨 문제가 있냐고 물어보니 손님이 딸기 스무디를 주문했는데 이 에스프레소 머신에서는 스무디를 어떻게 만드는지 모르겠다고 허둥대고 있었다. 아뿔싸.. 에스프레소 머신에서 스무디를 만들려고 하는 직원을 보면서 약간 한심하다는 생각이 들긴 했지만 문득 초보 개발자 시절 자바의 스프링 프레임워크랑 파이썬의 장고 프레임워크를 구분하지 못해서 선배에게 혼났던 기억이 났다.

 

그래서 그 선배처럼 하지 말아야 한다는 생각으로 그 직원에게 에스프레소 머신은 커피를 만들고 저기 있는 스무디 머신에서 스무디를 만들 수 있다고 차근차근 설명해줬다. 다행히도 직원이 잘 알아듣고 스무디 머신에 있는 매뉴얼을 보며 차근차근 스무디를 잘 만들어서 직원에게 성공적으로 전달했다.

 

에스프레소 머신은 스무디를 만들도록 설계되지는 않았지만 에스프레소를 각종 원두에 따라 자동으로 적합하게 에스프레소를 추출하도록 그 자체로서도 거의 완성된 제품으로 동작한다. 원두를 넣거나 버튼을 누르는 등은 직원이 해야 하지만 실직적으로 에스프레소 머신이 요구하는 통제된 절차대로 버튼을 누르지 않으면 제대로 작동하지 않는다. 다만 에스프레소를 조금 묽게 뽑거나 진하게 뽑는 정도의 조절은 할 수 있는 등의 기능을 제공한다.

 

김스타 씨는 스타벅스에서 제공하는 전용 에스프레소 머신을 사용해야 한다. 스타벅스 규정상 다른 머신을 사용할 수 없기 때문이다. 옆 골목의 투썸 사장님도 투썸에서만 사용하는 에스프레소 머신을 써야 한다고 한다. 가끔 투썸 사장님은 투썸 머신이 에스프레소 뽑는 속도가 너무 느리다며 불평불만을 하곤 했다. 김스타 씨도 속으로는 스타벅스 에스프레소 머신에 불만이 약간 있었지만 제 얼굴에 침 뱉기라는 생각에 굳이 단점을 털어놓지는 않았다.

 

에스프레소 머신 Framework

 

 

 

바닥청소가 제일 쉬웠어요

아이고, 이번에는 서빙하던 직원이 실수를 저질렀다. 서빙하던 커피를 그만 바닥에 모두 쏟고 만 것이다. 순간적으로 큰 소리가 나올 뻔했지만 간신히 잘 참고 물걸레로 바닥을 청소하라고 직원에게 지시했다. 그런데 직원이 두리번거리며 어쩔 줄 몰라하는 것이 아닌가. 아참, 바닥청소에 대한 업무절차를 정의하지 않았구나.

 

바닥청소가 비록 아주 복잡한 업무는 아니지만 막상 절차적으로 나열해보면 생각보다 고려해야 할 것들이 꽤 있다. 일단 1) 물걸레가 어디 있는지 찾아야 하고 2) 물걸레를 가져와서 바닥이 끈적이지 않게 효율적으로 잘 닦아야 한다. 3) 잘 닦은 후 물걸레를 화장실에 가서 잘 빨아야 하며 4) 물기를 잘 짜준 후 건조대에 건조해야 한다.

 

별거 아닌 것 같아도 이러한 절차를 직접 하나하나 짜려고 하니 안 그래도 바빠 죽겠는데 약간 머리가 아파오기 시작했다. 그리고 혹시 지금 생각하고 있는 절차가 정말 효율적인가에 대한 의문도 들었다. 마침 옆 골목 투썸 사장님이 경력도 오래되었고 카페 운영 평판도 좋으니 전화해서 바닥청소는 어떤 식으로 하는지 물어보기로 했다.

 

투썸 사장님은 긴 말 없이 메일로 잘 정리한 세부 절차를 보내줬다. 김스타 씨는 아주 고마운 마음에 다음에 저녁이라도 사드리겠다고 했지만 투썸 사장님은 괜찮다며 그 절차는 오픈소스니까 자유롭게 사용하라는 말과 함께 허허허 너털웃음을 호탕하게 터뜨렸다.

 

엥.. 오픈소스? 어디서 많이 들어봤는데. 이제 거의 잊을뻔한 개발자 시절 용어를 들으니 정신이 번쩍 들었다. 마치 바닥청소 절차 문서가 개발자 시절 사용하던 라이브러리 같다는 생각이 들었다. 투썸 사장님이 보내주신 바닥청소 절차는 아주 효율적이고 군더더기 없었다. 많은 사람들이 오랜 기간 시행착오를 거쳐 완성했다는 느낌이 들었다. 꼭 카페에서만 국한되지 않고 범용적으로 다른 음식점이나 가정집에서도 충분히 사용할 수 있는 절차였다.

 

비록 바닥청소는 오픈소스로 투썸 사장님에게 무료로 받아서 쉽게 바닥청소에 대한 절차를 정립할 수 있었지만 그 외 다른 복잡한 업무들은 직접 고심해서 만들어야 했다. 특히 커피 위에 그림을 그리는 기술은 투썸 사장님에게 여쭤봐도 영업비밀이라며 절대 알려줄 수 없다고 하셨다. 본인도 10년 전 바리스타 학원에서 큰 비용을 지불하고 배운 기술이라고, 어차피 알려줘도 쉽게 바로 배울 수 없을 거라고 덧붙이셨다.

 

이런 어려운 기술은 결국 비용을 들여서 배워야 하는 경우도 있다. 김스타 씨는 며칠밤을 새우더라도 직접 인터넷에 검색하고 공부해서 기술을 익히리라고 다짐했다. 그리고 그 방법에 대해 간결하게 절차서를 작성해서 모든 직원이 쉽게 배울 수 있도록 해야겠다고 생각했다.

 

바닥청소 Library

커피 위에 그림 그리기 Library

 

 

 

여기까지 내가 이해하고 있는 SDK, API, 프레임워크, 라이브러리에 대해 카페 운영을 비유로 이야기를 만들어 봤다. 아마 정확하지 않은 부분도 있고 틀린 부분도 있을 것 같다는 생각이 든다. 애초에 이들의 개념이 서로 겹치는 경우도 있고 명확하게 선을 그어서 구분하기가 쉽지 않기도 하다. 그리고 현업에서는 특정 업무에 국한되는 프레임워크나 API 등을 사용하기 때문에 그보다 좀 더 근본적인 의미에 대해 차이가 있을지도 모르겠다.

 

어쨌든 일단 이 정도로 정리를 해놓고 앞으로도 계속해서 더욱 깊게 이해하도록 하는 노력이 필요할 것 같다.