발표 주제와 순서 소개
PaaS와 API 개발자 경험(DX)이 무엇이고 어떤 관계인지, 좋은 DX를 제공하는 방법, 그리고 토스트 노티피케이션의 실제 사례라는 세 축으로 발표를 진행하겠다고 안내하는 도입부다.
개발자 경험은 기술·라이브러리·SDK·API를 쓰며 얻는 종합 경험이며, API는 서비스 간 상호작용 접점, PaaS는 IaaS와 SaaS 중간의 개발 도구라고 정리한다. 세 개념이 어떻게 맞물려 개발 생산성으로 이어지는지 설명한다.
이커머스 회사가 메시징 기능을 직접 개발하려면 APNS·FCM·SMTP 등 풍부한 도메인 지식과 정보통신망법 이해가 필요함을 짚고, 클라우드 메시징 서비스 이용을 대안으로 제시한다. 나쁜 DX가 문의-대기-재개발의 악순환을 부르는 반면 좋은 DX는 신뢰와 생산적 소통의 선순환을 만든다고 대비한다.
풍부한 기능, 표준 준수, 빠른 대응, 안정적 성능·기능, 직관적 API라는 다섯 가지를 제시한다. 특히 사실상 표준인 REST에서 벗어나면 학습·유지보수 비용이 커지고, 직관적이지 않으면 문서 참조와 문의 같은 커뮤니케이션 비용이 늘어난다고 강조한다.
잦은 출시(2018년 12월 한 달 9회 점검)와 최대 6개 버전 동시 서비스 상황에서, 1.1 기능 추가가 1.0 응답 형식을 바꿔 기존 클라이언트가 응답을 해석하지 못하는 장애가 발생했다. 원인은 모든 API 버전이 같은 응답 객체를 공유한 것으로, 버전별 객체 분리를 결정한다.
지루하고 실수 잦은 버전별 객체 매핑을 위해 ModelMapper·MapStruct 등을 비교해 성능이 앞선 MapStruct를 채택한다. 인터페이스에 @Mapper를 붙이면 어노테이션 프로세서가 컴파일 타임에 매핑 코드를 생성하며, 롬복처럼 스프링 연동·기본 메서드로 비즈니스 로직 분리까지 가능함을 예제로 보여준다.
어떤 속성이 왜 잘못됐는지 알 수 없는 조악한 오류 응답이 문의를 유발한다는 문제를 구글 Apigee의 블랙박스 비유와 함께 설명한다. if문 흩뿌리기 대신 도메인 객체에 제약 어노테이션을 선언하는 Bean Validation으로 검증 로직의 분산·중복을 해결하고, @Valid와 예외 핸들러로 구체적 응답을 자동 생성한다.
커스텀 제약 어노테이션 정의, 여러 제약의 하나로 합성, 프로퍼티 파일 기반 다국어 동적 메시지 등 실무 기법을 소개한다. 이어 enum 검증 관련 Q&A를 다루고, 월 7억 건 발송 규모와 우아한형제들·쿠팡 등 외부 사용처를 언급하며 작은 노력이 큰 차이를 만든다는 슬로건으로 마무리한다.