메시징 플랫폼을 만든다는 건 생각보다 훨씬 복잡해요.
SMS, 알림톡, RCS 등 여러 채널을 한 서비스에서 안정적으로 보내야 하니까요.
그럼에도 센드온 개발팀은 이렇게 말합니다.
“결국 핵심은 두 가지예요.
얼마나 쉽게 쓸 수 있느냐, 그리고 얼마나 안정적이냐.”
이번 글에서는 센드온 개발팀과 함께
API와 SDK가 실제로 어떤 차이가 있는지,
그리고 센드온은 이 두 가지를 어떻게 설계했는지를 편하게 풀어보려고 합니다.
API는 “약속”, SDK는 “도구”
“API랑 SDK, 둘 다 많이 들어봤는데 뭐가 다른 거지?”
개발자분들 사이에서도 이런 질문을 자주 듣습니다.
센드온의 김종원 CTO는 이렇게 설명해요.
“API는 통신 규칙이에요.
‘이렇게 보내면 이렇게 응답할게’라는 약속이죠.”
즉, 외부 시스템이 센드온에 메시지를 발송하면,
센드온은 정해진 형태(JSON)로 응답을 되돌려주는 구조입니다.
반면 SDK는 조금 더 현실적인 도구죠.
“SDK는 그 규칙을 몰라도 쉽게 쓸 수 있게 만들어주는 도구예요.”
요청 파라미터를 하나하나 만들고, 응답값을 파싱하고…
이런 귀찮은 작업들을 SDK가 대신 처리해줍니다.
센드온 SDK(현재 TypeScript · Java 지원)를 설치하면
자동 완성과 함께 짧은 코드 한두 줄만으로 메시지를 보낼 수 있게 도와줍니다.
내부적으로는 API를 호출하고 있지만, 개발자는 복잡한 구조를 신경 쓸 필요가 없어요.
“통합보다 분리” — 조금 귀찮아 보여도, 결국 더 쉬운 길
센드온은 SMS, 친구톡/알림톡, RCS 등 다양한 채널을 지원합니다.
그런데 하나의 API로 묶지 않고 각 채널을 명확히 분리해두었어요.
“하나로 합치면 좋아 보이는데, 실제로는 더 헷갈려요.
메시지 구조와 필드가 전부 다르니까요.”
대신 중요한 건 ‘경험은 통합적으로 느껴지게 하는 것’입니다.
그래서 공통 필드는 모두 동일하게 유지했습니다.
예를 들면 from, to 같은 것들이죠.
덕분에 SMS를 쓰던 개발자가 RCS로 넘어가도 금방 익숙해집니다.
이런 정교한 설계가 가능한 이유는
처음부터 API 설계 문서와 팀 내 규칙을 매우 엄격하게 지켜왔기 때문입니다.
모든 API에 description과 parameter 설명을 붙이고,
문서화는 자동으로 생성되도록 만들었어요.
“문서가 팀의 언어”라는 생각으로 일해온 결과입니다.
문서가 곧 경쟁력
센드온은 API 문서를 단순 참고자료가 아니라, 개발자와의 소통 창구라고 생각합니다.
각자 선호하는 방식으로 정보를 확인할 수 있도록 두 가지 문서를 병행하고 있습니다.
예제가 중심이 되는 문서, ‘레시피’ 방식
센드온 문서의 가장 큰 특징은 예제가 많다는 점입니다.
“어떻게 쓰는지 보여주는 게 설명보다 빠르다”는 철학 때문이죠.
그래서 실제 코드 레시피를 그대로 가져다 써도 됩니다.
예를 들면:
MMS 이미지 업로드
예약 발송
발송 결과 조회
API 문서에는 구조 설명부터 실제 시나리오까지,
SDK 문서에는 복붙하면 바로 동작하는 코드까지 제공합니다.
우리가 지향하는 기술 경험
센드온이 참고한 글로벌 모델은 Twilio와 Sendbird입니다.
Twilio는 세계에서 가장 쉽다는 평가를 받는 문자 API
Sendbird는 문서 구조와 완성도가 매우 뛰어난 개발자 중심 서비스
센드온은 이 두 가지 방향성을 모두 목표로 합니다.
“문서 품질이 곧 서비스 신뢰입니다.
개발자가 ‘이 문서 잘 돼 있네’라고 느끼는 순간,
그게 바로 센드온의 경쟁력이죠.”
마무리하며
센드온의 API와 SDK는 단순한 연동 도구가 아닙니다.
개발자 경험 자체를 설계한 결과물입니다.
더 빠르게
더 쉽게
더 안정적으로
메시징 기능을 구현할 수 있도록,
개발자가 겪는 ‘시간 낭비’를 줄이는 데 집중하고 있습니다.
오늘도 센드온 기술팀은 같은 질문을 반복합니다.
“개발자 입장에서, 더 편한 방법은 무엇일까?”
그 질문이 센드온을 앞으로 계속 발전하게 만드는 힘이 되고 있습니다.