토스플레이스(Tossplace)는 외부 연동사(3rd-party)의 플러그인 앱 개발을 지원하기 위해 Toss Front SDK를 개발, 확장성 확보(Extensibility)를 목표로 함
SDK 사용 편의성 향상을 위해 퍼사드(Facade) 패턴을 적용, 복잡한 내부 로직을 추상화하여 사용자의 인지 부하를 줄임
고수준(High-level) 인터페이스와 저수준(Low-level) 인터페이스를 함께 제공하여 유연성(Flexibility)과 편의성(Convenience)의 균형을 추구함
휴먼 에러(Human Error)를 방지하고 SDK 안정성을 높이기 위해 자동화된 클린업(Cleanup) 로직과 리소스 관리(Resource Management)를 구현함
본문에서 SDK 설계 시 퍼사드(Facade) 패턴의 핵심은 기능 은닉이 아닌, 사용자의 의도(Intent)를 중심으로 인터페이스를 재구성하는 것이라고 강조한다.
복잡한 내부 로직: 인증, 재시도, 상태 관리, 클린업(Cleanup) 등을 사용자 모르게 처리
AWS CDK(Cloud Development Kit) L2 Construct: S3 버킷 생성 시, 직관적인 API(Intuitive API)를 제공하여 사용성을 향상시킴
결과: 사용자는 “서버 시작”, “파일 업로드”와 같은 자연스러운 목적(Natural Purpose)만 표현하도록 유도하여 개발자 경험(DX)을 개선한다.
저자는 좋은 SDK는 고수준 API와 저수준 API를 모두 제공해야 한다고 주장하며, 파레토 법칙(Pareto Principle)을 예시로 든다.
80% 유즈케이스: 고수준 Facade API를 통해 간편하게 처리
20% 특수 케이스: 저수준 API(Low-level API)를 통해 세밀한 제어 가능
장점: 단기적인 개발자 경험(DX) 향상과 더불어 SDK의 장기적인 호환성(Compatibility) 및 확장성(Extensibility)을 확보
결과적으로, 유연성과 편의성 사이의 균형을 유지하며, 다양한 사용 사례(Use Case)에 대응할 수 있는 구조를 설계한다.
퍼사드(Facade) 패턴 적용 시, 추상화 수준이 높아짐에 따라 발생하는 트레이드오프(Trade-off)를 인지하고, 이를 보완하기 위한 설계를 제시한다.
저수준 API의 필요성: 세밀한 제어가 필요한 경우, Facade의 추상화(Abstraction)로 인한 제약 발생 가능성
유지 보수 비용 증가: 내부 로직 복잡도 증가에 따른 SDK 유지 보수(Maintenance) 비용 증가
탈출구(Escape Hatch) 설계: 저수준 인터페이스를 제공하여 유연성(Flexibility) 확보
결론적으로, Facade 패턴은 DX(Developer Experience)를 개선하지만, 특정 상황(Edge Case)에 대한 유연성 확보를 위해 저수준 API를 함께 제공해야 한다.
Toss Front SDK는 Facade 패턴을 활용하여 안정적인 SDK(Stable SDK)를 구축하기 위해, 리소스 관리(Resource Management)와 클린업(Cleanup) 책임을 명확히 한다.
High-level API(start): 자동화된 오케스트레이션(Automated Orchestration)을 통해 서버 오픈, 연결, 리스너 등록/해제 관리
Low-level API: open, close, send, listen 등의 메서드를 제공하여 세밀한 제어(Fine-grained Control) 가능
단일 책임 원칙(SRP): “리소스를 만든 곳에서 닫는다”는 원칙을 통해 이벤트/리스너 누수(Event/Listener Leak) 방지
결과적으로, 사용자 실수로 인한 비효율적인 리소스 관리를 구조적으로 줄여, SDK의 안정성(Stability)을 향상시킨다.