brunch

매거진 일과 썰

You can make anything
by writing

C.S.Lewis

by 황금별 Jan 25. 2024

[토스페이먼츠] 브랜드페이 연동/인터뷰 경험(2/2)

토스페이먼츠 DX팀분들과 개발자 인터뷰

1. 들어가기

 1부에서는 토스페이먼츠의 두 가지 API에 대한 설명과 토스페이먼츠를 선택한 이유, 개발 및 계약 과정에서 발생한 문제 해결, 그리고 운영계 릴리즈 과정에서 확인한 체크리스트를 정리해보았습니다. 이번 글에서는 토스페이먼츠 DX팀 분들과 토스페이먼츠 개발자 리뷰에 대한 경험과, 제가 느낀 토스페이먼츠의 장/단점에 대해 이야기해보고자 합니다.


2. 장점

 토스페이먼츠를 통해 결제 서비스를 개발하면서 느꼈던 장점은 크게 세 가지로 요약할 수 있겠습니다. `개발 친화적`인 여러 문서 제공과 `유연한 전환`이 가능하다는 점, 그리고 `빠른 기술 문의 및 대응`입니다. 각각의 내용을 아래에서 조금 자세히 이야기해보겠습니다.


개발 친화적인 문서

 개발과 개발 이후에 발생하는 이슈에 대해 확인하기 위해서는, 다음과 같은 문서가 필요로 합니다. 각각의 문서는 두 가지 의미에서 도움이 됩니다.


API 명세서 API 사용 방법 및 API Key 가이드
서비스 연동 가이드 (혹은 서비스 이용 플로우)
API 에러 코드


 API 명세서나 이용방법, 가이드 등 이러한 자료는 API 연결과 서비스 개발 단계에서 많은 정보를 제공해줄 수 있습니다. 이러한 정보가 어느정도로 제공되는지, 얼마나 자세하게 제공되는지에 따라 개발 기간을 빠르게 판단할 수 있고, 개발 방법을 어떻게 적용할지 적용하기 용이합니다. 또한 API 에러 코드의 경우 에러에 대해 판단할 수 있는 근거를 제공해주는 역할을 합니다. 특히 이러한 외부 API를 연동하여 서비스를 개발할 경우 적절한 에러 값을 받아 화면에 TOSS 할 수 있어, 에러 발생에 대해 의존할 수도 있습니다.



 에러 코드 페이지에서 제공되는 코드를 이용하여 백엔드 InterfaceHandler를 개발하였습니다. 이를 이용하여 고객 인증 만료 여부, 카드 관리, 여러 유효성 검증 이슈에 대한 대응이 가능했습니다. 특히 토스페이먼츠에 이러한 예외상황에 대해 의존할 수 있었습니다. 필요에 따라 Handler를 통해 방어로직을 개발하기 유용하고, 프론트엔드에 적절한 에러 메시지를 넘겨주는 것이 가능했습니다.


유연한 전환

 토스페이먼츠에서 API를 이용하기 위한 두 개의 키(클라이언트, 시크릿)는 테스트와 라이브가 동일하게 한 쌍으로 제공되는 것으로 예상되었습니다. 더욱이 개발자 센터에서 제공되는 여러 예제에서 아래와 같은 키를 이용하여 연동하는 방법을 안내하고 있습니다. 때문에 개발계에서 테스트를 충분히 마치고, 운영계로 전환할 시 두 키를 변경하는 것으로 충분할 것이라 판단하였습니다. 이는 실제로도 운영계 릴리즈에서 별도의 추가개발 없이 쉽게 릴리즈가 가능하였습니다.



빠른 기술 문의 및 대응

 이전 글에 작성한 것과 동일하게, Discord 채널로 개발 관련 기술문의를 할 수 있다는 장점이 있습니다. 문의가 가능한 시간은 정해져 있으나, Discord를 이용하여 문의내용을 남기고, 개발자분이 직접 확인하여 답변을 주시는 형태로 이루어지기 때문에 빠르고 정확한 답변을 받을 수 있었습니다.


3. 아쉬웠던 점

 이번에 개발한 결제 프로세스는 복잡하지 않은 단순한 구조였습니다. 때문에 기능 자체적으로는 만족스러웠습니다. 다만 개발 문서에서의 아쉬웠던 점이 있었습니다. API의 요청 및 응답에 필요한 구성과 그 설명은 친절했으나, API 요청 시 어떤 토큰이 필요하며, 이를 어떻게 이용할지 등 개요 설명이 앞서 설명되었어야 한다고 생각했습니다.   


API키는 무엇인가

API 통신 과정에서 어떤 인증 과정이 있는가

SDK에서 redirectUrl은 어떻게 등록하고 관리할 수 있는가

자동결제 API와 자동결제(빌링) API의 차이는 무엇인가


 코어 API와 브랜드페이 API, 그리고 SDK를 설명하기 앞서 위와 같은 부가적인 내용이 먼저 소개됐어야 한다고 생각했습니다. 이러한 요소를 개요에 내용을 추가할 경우 개발 문서 수정이 크게 일어나지 않으면서 API 문서를 읽을 때 전반적인 이해력을 높일 수 있을 것이라 생각했습니다.


4. 토스페이먼츠 DX 팀 인터뷰

 우연히 토스페이먼츠 공식 Discord 채널 공지사항에 게시된 개발자 인터뷰 글을 확인하게 됐습니다. 6개월 이내 토스페이먼츠 결제 연동을 진행한 개발자 대상으로 구글밋으로 진행하는 인터뷰였습니다. 4개월 조금 넘는 기간동안 프로젝트를 진행하며 스쿼드 멤버들과 고민하고 개발했던 경험을 리뷰하고 나름의 피드백을 드릴 수 있지 않을까, 라는 기대를 가지고 신청을 넣었습니다.


토스페이먼츠 개발 경험 피드백

 인터뷰에서는 앞서 위에서 소개드렸던 장점과 단점에 대해 피드백을 드렸습니다. 또, 위에서 소개드리지 않은 피드백을 간단히 나열하면 다음과 같습니다.


개발 과정에서 문서 자체는 친절하나, 추측하여 개발하는 경우도 더러 있었음

테스트 과정에서 계정별 테스트 키 쌍이 제공되는 것을 나중에 알게 됨

accessToken과 refreshToken의 유효 기간은 API 문서가 아닌 다른 페이지를 참조 해야 했음


 간단히 나열해보자니 피드백을 드린 내용이 얼마 안 되는 것 같다는 생각이 듭니다.(허허) 피드백과 더불어 인터뷰 담당자 두 분께서 별도로 몇 가지 안에 대한 개발자의 의견을 물어보시기도 했습니다.


API 문서 변경점 피드백

 가장 인상깊게 기억하는 피드백 요청은 `API 테스트 기능이 각 API 소개글 옆에 내재시키는 건 어떻게 생각하는가?` 였습니다. 다시 말해, 제공되는 API 문서의 요청 및 응답 예시 값을 표시하는 영역에 테스트가 가능하도록 기능을 업데이트 하게 되면 고객경험에 긍정적인 영향이 생길 것인지에 대해 피드백을 받고 싶은 것이라 이해했습니다. 이에 대해 두 가지로 구분하여 피드백을 드렸던 것 같습니다.


만약 요청/응답 설명을 지우고 테스트 기능을 넣는다면, 오히려 이해하는데 어려움을 줄 수 있을 것 같다.

만약 요청/응답 설명을 그대로 두고, 테스트 기능을 추가하게 되면 문서를 보는 사람이 불편할 수 있을 것 같다.


 피드백을 드리며 느꼈던 점은, ‘다양한 방향으로 개발문서를 보는 이용자(고객)에게 더 좋은 경험을 제공할 수 있을지 고민하고 있구나’ 였습니다. 현재 완성되어 있는 작업물에 그치지 않고, 그 너머에 더 좋은 경험을 제공할 방법을 찾는 과정에 작은 도움이 됐기를 바랐습니다.


5. 마무리

 토스페이먼츠를 이용하여 결제 프로세스를 개발한 경험과 더불어 개발자 인터뷰를 경험해보았습니다. 과거 Banking as a Service, 증권사 API 연동 등을 경험해보았으나, 토스페이먼츠에서 제공되는 개발 문서는 문화충격과 비슷한 충격을 받았던 것 같습니다. 개발에 필요한 내용이 직관적이고 구체적으로 제공되기에 개발 과정에서 겪는 모호함을 최소화 해주었습니다. 또한 개발자 인터뷰는 제게 ‘개발자센터를 보다 견고하고 완성도를 높이기 위해 멈추지 않는구나’ 라는 신선함을 경험하게 해주었습니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari