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