IT업계에 종사하는 사람이라면 한 번쯤은 인프런에서 강의를 들어봤을텐데요. 인프런을 만드는 회사가 바로 인프랩이에요. 인프랩은 지난해 4분기 흑자를 달성하며 꾸준히 성장하는 모습을 보여주고 있어요.이렇게 성장하는 프로덕트와 연결된 기존 결제 시스템을 바꾸는 일이 어떻게 가능했을까요? 인프랩 CTO 동욱 님을 만나 결제 시스템을 안정적으로 변경한 인프랩의 노하우를 자세히 들어봤습니다.
이번 포스트에서는 인프랩의 기술적 방향성과 결제 시스템을 바꾼 과정을 먼저 알아볼게요.
개발자를 고려한 API와 SDK라 선택했어요
“결제를 다루고 있는 회사들을 보면 내부 기술에 대해 말을 잘 안해주거든요. … 토스페이먼츠는 이런 기술적인 내용과 결정을 외부로 계속 공유하는 것을 보며 신뢰할 수 있다는 생각을 했어요.”
CTO님은 이전 회사에서도 결제 관련 업무를 하셨다고 들었어요. 그래서 PG사를 고를 때도 기준이 높았을 것 같아요. 어떤 기대를 가지고 토스페이먼츠로 바꾸셨나요?
토스페이먼츠 도입은 저희 개발팀이 추구하려는 방향과 관련된 결정이에요. 과거 일부 PG사들이 제공하는 API는 요즘 개발 트렌드에 맞는 현대적인 API 스펙, 연동 과정과 조금 차이가 있어요. 아주 간단한 예를 들어 볼게요. 필드를 만들 때 요즘은 전부 카멜 표기법(Camel case)를 쓰죠. 하지만 서비스를 시작한지 오래된 PG사들은 스네이크 표기법(Snake case)를 써요. 변수명이 직관적이지 않거나, API 주소가 좀 이상하게 되어 있어서 이해하기 힘들 때도 있죠. 정말 다양한 케이스들이 있어요. 이런 스펙을 가진 서비스를 도입하게 되면 저희 코드 방향성과 맞지 않는 API 응답을 중간에서 교정하는 작업을 해야 해요.
이와 반대로 JSON 스펙에 맞춰 정확하게 정리가 되어 있는 게 토스페이먼츠 API/SDK였어요. 교정하는 레이어가 필요 없게끔 잘 만들어져 있더라고요. 요즘 개발자들이 어떤 지향점을 갖고 있고, 어떤 식의 고려를 하고 있고, 어떤 어려움을 겪을 법한지가 잘 고려되어 있어서 개발자를 위한 API/SDK라고 생각했어요.
토스페이먼츠의 개발 스펙 정보는 어떻게 얻으셨나요?
개발자센터를 봤고요. 예전에 SLASH21에서 토스페이먼츠는 어떤 식으로 API와 SDK를 설계했는지 발표하신 걸 보고 신뢰도가 확 높아졌어요. 왜냐하면 결제를 다루고 있는 회사들을 보면 내부 기술에 대해 말을 잘 안 해주거든요. 사용하는 입장에서는 결제가 잘못되면 큰일나기 때문에 PG사의 결제 시스템이 기술적으로 얼마나 잘 구축되어 있고, 얼마나 많은 고민했는지가 궁금해요. 그런데 토스페이먼츠는 이런 기술적인 내용과 결정을 외부로 계속 공유하는 것을 보며 신뢰할 수 있다고 생각했어요.
결제는 토스페이먼츠에 맡기고 프로덕트에 집중해요
“결제 시스템 변경은 단순히 기술적인 개선이 아니라, 우리가 서비스를 제공하는 방식 자체를 개선한 거라고 생각해요.”
그럼에도 PG사 변경은 사실 쉽지 않은 결정이라는 생각이 들어요. 특별히 결제 시스템을 바꾸게 된 계기가 있으신가요?
타 결제 서비스를 이용할 때, 큰 이벤트의 가장 중요한 마지막 날에 장애가 발생했어요. 결제가 아예 안 됐는데 고객센터조차 전화를 안 받았어요. 그때의 경험을 계기로 더 안정적인 결제 시스템을 사용해야겠다고 결정했어요.
토스페이먼츠로 전환하기로 했을 때도 물론 이전과 똑같은 장애 문제가 생길 수 있다는 걱정이 있었죠. 하지만 토스 페이먼츠의 안정성과 장애율을 깊이 조사해 보니 신뢰할 수 있다고 판단했어요. 이전 직장에서의 경험 때문에 장애율이 꾸준히 개선된 것도 이미 알고 있었어요.
근데 이건 하방선을 높인 거라고 할 수 있어요. 저희가 더 중요하게 생각한 건 PG 서비스를 통해 ‘프로덕트에만 집중할 수 있는 환경’을 제공할 수 있느냐는 거였어요. 예를 들어 회사에 결제 시스템을 구축하고 안정적으로 유지하기 위해서는 개발자와 기획자가 여러 명으로 구성된 고도화된 결제 플랫폼 팀이 필요한데요. 많은 인력을 들여서 직접 결제 시스템을 직접 운영하는 것과, 토스페이먼츠 결제위젯처럼 이미 잘 구축된 시스템을 사용하는 것 사이에는 큰 차이가 있어요. 직접 운영하면 장애가 발생했을 때 고객센터에 문의가 폭주하고, 긴급하게 문제를 해결하기 위해 추가 작업을 해야 하죠. 반면에 토스페이먼츠 결제위젯 같은 제품은 짧은 기간 동안 연동만 마치면 그런 고민을 더 할 필요가 없었어요. 훨씬 효율적이죠. 그래서 토스페이먼츠를 도입하는 게 인프랩의 방향성과 훨씬 더 잘 맞았다고 봐요.
이번에 토스페이먼츠가 제공하는 브랜드페이로 자체 간편결제 서비스를 연동하셨는데요. 인프랩같이 개발팀이 강력한 IT 회사는 직접 간편결제 서비스를 구축할 수도 있다고 생각했거든요. 그럼에도 토스페이먼츠 브랜드페이 서비스를 선택하신 이유가 있을까요?
현재 인프랩의 주요 프로덕트는 강의, 커뮤니티, 채용이에요. 그런데 이런 프로덕트에는 결제나 정산과 같은 플랫폼적인 요소가 당연히 필요하잖아요. 만약 저희가 직접 구축하기로 했다면 3~4개월 정도의 시간을 들이고, 수수료 비용을 줄일 수 있었을 거예요. 그런데 이렇게 해서 절감한 수수료와 제품에 집중해서 얻는 이득 중 어느 게 더 크냐라고 했을 때 저는 후자가 더 크다고 생각했어요.
왜냐면 저희는 핵심 KPI가 매출이 아니거든요. 저희 강의를 들으신 분들, 혹은 저희 채용 서비스 쓴 분들이 얼마만큼 커리어적인 성장을 했느냐가 KPI에요. 즉, 핵심 KPI가 매출이 아닌데 거기에 개발 리소스를 몇 개월씩 투자해서 직접 구축한다는 결정을 하긴 어렵죠. 핵심 지표를 위한 일이 아닌 다른 일에 자꾸 시간을 뺏길 수도 있었던 것이 브랜드페이를 통해 완전히 개선됐어요. 그런 것들이 하나하나 프로덕트에 집중할 수 있는 환경을 지원하고 있다고 생각해요.
결과적으로 팀은 주요 제품 개발에 더 집중할 수 있게 되었고, 결제 시스템의 안정성이 높아져 내부 리소스를 효율적으로 활용할 수 있게 됐어요. 그래서 저는 결제 시스템 변경은 단순히 기술적인 개선이 아니라, 우리가 서비스를 제공하는 방식 자체를 개선한 거라고 생각해요.
결제 시스템을 안정적으로 바꾼 인프랩의 기술 전략들
“시스템에 큰 변화가 있을 때 가장 중요한 일은 롤백 시나리오(Rollback Scenario)를 먼저 작성하는 거에요.”
오래 버텨온 많은 스타트업이 비슷할 텐데요. 특히 까다로운 결제 서비스를 레거시 코드가 있는 환경에서 변경하신 노하우가 있다면 어떤 건가요?
일단 API가 잘 구성되어 있어서 토스페이먼츠 연동 자체는 그렇게 어렵지 않았어요. 하지만 기존의 결제 시스템 로직을 새 시스템으로 교체하는 것이 주된 과제였죠. 이렇게 시스템에 큰 변화가 있을 때 가장 중요한 일은 롤백 시나리오(Rollback Scenario)를 먼저 작성하는 거예요. 시스템을 변경한 후에 갑작스럽게 지표가 떨어지거나, QA 과정에서 발견되지 않았던 에러가 많이 발생하는 상황이 생길 수 있잖아요? 이럴 때 신속하게 시스템을 롤백할 수 있는 능력이 굉장히 중요해요. 특히 데이터가 이미 분리된 상황에서는 새로운 시스템에서 이루어진 결제 데이터를 롤백 후 원래 시스템으로 돌아갔을 때 어떻게 적재하고 사용할 수 있을지가 큰 문제거든요.
💡 롤백 시나리오(Rollback Scenario)란?
롤백 시나리오는 컴퓨터나 소프트웨어에서 문제가 생겼을 때, 이전에 잘 작동하던 상태로 돌아가는 방법을 말해요. 마치 컴퓨터에 문제가 생겨서 '되돌리기'를 누르는 것처럼, 시스템을 안전하고 문제없이 작동하던 이전 상태로 복구시키는 거죠. 새로운 업데이트나 변경사항이 문제를 일으킬 때, 문제를 빠르게 해결하기 위해 중요합니다.
그래서 저희는 시스템을 오픈한 후에도 일주일 이내에 언제든지 롤백할 수 있는 환경을 만드는 것을 항상 강조해요. 여기서 롤백은 단순히 코드를 다시 배포하는 수준을 넘어서, 데이터 자체도 원상태로 돌릴 수 있어야 한다는 걸 의미해요.
또, 기능 플래그(Feature Flag)라는 시스템이 저희한테 매우 중요했어요. 기능 플래그 시스템을 통해, 어드민 상에서 버튼만 클릭하면 새로운 결제 모드로 바뀌고 문제가 발생하면 다시 원래 모드로 빠르게 전환할 수 있는 환경을 구축했어요. 데이터도 기존에 사용하던 테이블에 그대로 적재되도록 설정했어요.
💡 기능 플래그(Feature Flag)란?
특정 기능을 켜거나 끌 수 있는 설정을 의미합니다. 이 설정을 통해 개발자들은 새로운 기능을 조금씩 사용자에게 배포하거나, 필요에 따라 쉽게 기능을 비활성화할 수 있습니다.
결제 연동과 관련해 가장 난이도가 높았던 작업이 있다면 무엇인가요?
가장 난이도가 높았던 작업은 새로운 데이터 포맷으로 전환하면서 필요한 검증 작업이었어요. PG사를 바꿀 때 가장 큰 도전은 같은 주문 데이터가 서로 다른 스펙으로 들어오는 거잖아요. 그래서 중간에서 다양한 교정 작업을 거쳐 원래 사용하던 테이블에 데이터를 적재하고요.
특히 할인이 적용되거나 쿠폰이 사용된 경우처럼 다양한 결제 시나리오에서 발생하는 다양한 데이터 필드를 처리하는 부분이 까다로웠어요. 예를 들어, 4월 1일에는 이전 결제 시스템을 사용하여 결제가 이루어졌고, 4월 5일에는 토스페이먼츠로 결제가 되기 시작했어요. 그런데 4월 7일에 4월 1일에 이루어진 결제의 취소 요청이 들어오면, 이미 변경된 결제 시스템을 통해 어떻게 처리할지 같은 상황이 어려웠죠.
인프랩에서는 PG사의 응답이 돌어오면 데이터베이스로 들어가기 전에 데이터 교정 작업을 하는 어댑터 레이어를 하나 거치게 되어 있는데요. 결제 시스템을 토스페이먼츠로 변경하기 위해 토스페이먼츠 응답에 맞는 어댑터도 만들었습니다. 이 레이어에서는 원본 데이터를 임시 테이블에 저장하고, 이를 새로운 포맷으로 변환해서 기존 테이블에 적용하는 과정을 거칩니다. 이 과정에서 언제든 문제가 발견되면 원본 데이터와 결과를 비교해 볼 수 있어서 문제 원인을 빠르게 파악할 수 있었어요.
혹시 이런 작업의 정확도를 높이기 위해 추가로 하셨던 작업이 있을까요?
요즘 장바구니 구조 개편을 하고 있는데, 이때 정합성을 위해 트래픽 셰도잉(Traffic Shadowing)을 도입하려고 해요. 트래픽 셰도잉은 하나의 결제가 발생할 때마다 새롭게 만든 API와 기존 API에 모두 요청을 보내고, 두 API의 응답이 일치하는지를 계속해서 검증하는 후속 프로세스를 뜻합니다. 예를 들어, 사용자에게는 기존 테이블을 사용하는 API의 결과만 보여주지만, 동시에 새로운 테이블을 사용하는 API에도 트래픽을 보내서 두 결과가 같은지를 검증합니다. 이 과정에서 오류가 일정 수준 이상 발생하면 알람을 받게 되는 시스템을 구축하고 있어요. 이렇게 하면 테이블 구조가 어떻게 변하든지 간에, 두 결과가 동일한지를 실시간 트래픽으로 지속적으로 검증할 수 있고, 사용자에게는 기존 API 결과를 계속 제공하여 영향을 최소화할 수 있어요.
인프랩 서비스와 개발자의 성장 및 교육에 대한 아티클이 이어집니다.
Interview 한주연, 이기문 Edit 한주연 Photo 김세희, 김예솔
토스페이먼츠 Twitter를 팔로우하시면 더욱 빠르게 블로그 업데이트 소식을 만나보실 수 있어요.
재밌게 읽고 갑니다!