SDK 란 무엇인가.
sdk와 api에 대한 비교는 마치 수육을 먹기위해 마트에서 고기를 사는것과 수육용 밀키트를 사는것의 차이라고 할 수 있다.
sdk는 밀키트 처럼 수육을 만들고자 한다면, 좀 더 상세하고 사용자가 수육을 만들기 쉽게 (소스, 조리 시간 등등..) 미리 준비해서 최대한 준비해주는 것이다. 그러나 api는 소스도 본인이 만들고 , 불의 강약도 스스로 조절하며 수육을 만들어야한다.
대충 감을 잡고 위의 예시를 개발자 언어로 바꾸자면... sdk는 소프트웨어 개발자 키트의 줄임말이고 같은 api 콜을 한다고해도 일반 api 콜과는 달리 에러 컨트롤, 로그 분석 등 백오프 기능을 포함해 사용자가 사용하기 편한 모든 정보와 기능의 꾸러미라고 할 수 있다.
일반적인 sdk는 관련 문서와 코드 및 구현(시나리오) 샘플, 사용자 가이드, 제한 사항 등등의 추가 제품이 포함되어있어야 한다.
Best Practices in SDK
sdk든 api든 사용자가 실제로 사용할 수 있는 경우에만 가치가 있다. 바꿔 말하자면, 아무도 안먹는 음식을 제공하는 가게는 망하게 된다. 그렇다면 sdk 개발시 고려해야할 점들은 어떤게 있을까?
Simple
당연하겠지만 지나치게 복잡한 코드, 방법론은 사용자를 방해해 sdk를 사용하는 이유인 효율성을 해쳐서는 안된다. 이를 위해서는 모든 단계에서 단순성을 보장해야한다.
🙋♂️ 단순성을 보장하는게 무슨 뜻이냐?
🤖 일반적으로 클래스나 메서드의 우선 순위를 지정하는 것을 의미합니다.
🙋♂️ 그건 또 무슨 의미냐..?
🤖 실제로 사용할 수 없는 메서드나 기능으로 옵션을 난독화 하지 않고 사용자가 사용하는 기능만 표시할 수 있어야한다는 것을 의미합니다.
😡 그니까 그게 무슨 뜻이냐고
🤖 후...특정 기능을 수행하는데 필요한 매개변수만 사용해서 최대한 적은 수 의 매개변수를 사용한다고
Usable
사용자의 사용성을 높이기 위해 설계 뿐만아니라 문서로 허들을 낮출 필요가 있다.
🙋♂️ 그걸 어떻게 낮추냐?
🤖 입문서, 예제를 통해 사용 가이드를 제공하면 코드 접근 방식의 복잡성과 특성을 소개하는데 큰 도움이 될 수 있음.
🙋♂️ 그 기준은 어떻게 측정하냐?
🤖 해당 코드베이스의 언어에 익숙하다고 가정하면, 사용자는 5-10분 내에 SDK를 사용할 수 있어야 함.
Endpoints Correctly
api와 마찬가지로 엔드포인트의 매핑을 정확히 해야 의도한 기능과 예상되는 응답이 무엇인지 명확하게 알 수 있다. 이는 곧 sdk가 지속적으로 업데이트 되는지를 의미합니다. 기능을 서비스 개발에 발 맞춰 진행하고 문서의 추가도 잊지 않아야한다.
