디지털 유배 속 데이터 인프라

Source: Dev.to

우리가 실제로 해결하고 있던 문제

데이터 엔지니어로서 나는 고성장 비즈니스를 지원하기 위한 데이터 인프라를 수년간 구축해 왔다. 하지만 이번 최신 프로젝트는 달랐다: 제한된 국가에서 고객에게 스톡 사진을 판매하려고 했는데, 일반적인 결제 게이트웨이인 PayPal, Stripe, Gumroad, Payhip이 전혀 작동하지 않았다.

초기 우회 방법

• 기프트‑카드 해킹: 고객이 지원되는 국가에서 기프트 카드를 구매하고, 우리가 수동으로 자금을 제한된 국가 계좌로 이체했다.
• 현지 결제 프로세서: 현지 결제 프로세서와 연동을 시도했지만, API가 제한적이고 수수료가 터무니없이 높았다.

두 접근 방식 모두 총알이 박힌 상처에 밴드‑에이드를 붙이는 느낌이었다—투박하고 오류가 잦으며 확장성이 없었다.

맞춤형 결제‑게이트웨이 집계기 구축

수 주간의 조사와 프로토타이핑 끝에 우리는 제한된 국가에서 운영되는 대체 결제 프로세서를 통합하는 데 집중했다. 주요 과제는 다음과 같았다:

• 문서가 거의 없거나 직접 만든 문서.
• 다양한 결제 흐름과 환율을 처리할 맞춤형 집계기 개발 필요.
• 새로운 프로세서마다 수동으로 온보딩해야 하며, 운영 복잡성이 증가.

이러한 장애물에도 불구하고 우리는 여러 현지 프로세서를 지원하는 견고한 시스템을 제공했다.

결과 및 재엔지니어링

서비스를 시작했을 때 거래량은 급증했지만, 수동 온보딩과 복잡한 흐름 때문에 결제 성공률이 급락했다. 우리는 다음과 같이 대응했다:

• 실시간 오류 처리 구현.
• API 모니터링 추가.
• 온보딩 프로세스 자동화.

여러 차례 반복 후:

• 결제 성공률이 **95 %**로 향상.
• 평균 거래 시간이 30 분에서 5 분으로 단축.
• 운영 비용이 30 % 감소하여 제한된 국가에서 지속 가능한 비즈니스를 구축하는 데 자원을 집중할 수 있게 됨.

교훈

• 처음부터 결제‑게이트웨이 집계기 개발을 우선시했더라면 수 주간의 노력을 절감하고 운영 복잡성을 크게 줄일 수 있었을 것이다.
• 강력하고 다중 프로세서 결제 API를 조기에 탐색했더라면 초기 기술적인 밴드‑에이드를 피할 수 있었을 것이다.

돌이켜 보면, 선제적인 아키텍처 결정이 첫 날부터 더 나은 결과를 가져왔을 것이다.