결제 SDK를 설계한다면, 다양한 가맹점의 요구사항을 충족하면서도 직관적이고 확장 가능한 인터페이스를 어떻게 설계하시겠습니까?

결제 SDK를 설계한다면 먼저 다양한 가맹점 유형(이커머스·구독·오프라인)이 공통으로 필요한 동작과 개별적으로 필요한 동작을 분리하는 것부터 시작하겠습니다. 요구사항 수집은 기존 연동 사례나 문의 로그를 보면 공통 패턴이 드러나는 경우가 많습니다. 인터페이스 설계에서는 가장 단순한 케이스에서 코드가 3줄 이내로 동작하는 것을 기준으로 잡겠습니다. 복잡한 옵션은 체이닝이나 옵션 객체로 확장하는 방식이, 초기 진입 장벽을 낮추면서도 유연성을 유지하는 데 효과적이라고 봅니다. 확장성 측면에서는 결제 수단별 구현을 Strategy 패턴으로 분리해 신규 PG사 추가 시 기존 코드 변경 없이 구현체만 추가되는 구조를 고려하겠습니다. 기술 스택으로는 타입 정보를 SDK에서 함께 제공하는 것이 가맹점 개발자 경험에 직접 영향을 주기 때문에 TypeScript 우선을 선택하겠습니다. 아직 실제 SDK를 처음부터 설계한 경험은 없지만, 오픈소스 결제 라이브러리 구조를 분석하면서 이 방향이 반복적으로 등장한다는 걸 확인했습니다.