반응형 전체 글104 다중 PG 연동을 위한 Simple Factory, Adapter, Strategy 패턴 토스페이먼츠, 네이버페이, 카카오페이부터 페이팔까지 이커머스 서비스가 성장할수록 연동해야 하는 PG사와 결제 수단은 계속 늘어납니다. 이때 컨트롤러나 서비스 계층에 if/switch-case 문으로 PG사별 분기를 직접 작성하기 시작하면, 새로운 PG가 추가되거나 특정 PG의 연동 방식이 변경될 때마다 기존 결제 로직을 계속 수정해야 하는 구조가 되기 쉽습니다. 이번 글에서는 심플 팩토리(Simple Factory), 어댑터(Adapter), 전략(Strategy) 구조를 조합해 다중 PG 결제 시스템의 결합도를 낮추고 유연하게 확장하는 아키텍처를 정리합니다.1. 프로젝트 구조결제 도메인(Pg)을 컨트롤러 및 서비스와 분리하고, 외부 모듈은 Sdk/ 하위로 격리한 구조입니다.src/├── Controll.. 2026. 9. 18. 분산 환경에서의 중복 결제 방어: Redis 분산 락과 DB CAS 캐시 전략 지난 포스팅에서는 단일 서버 환경에서 DB의 원자성을 활용한 중복 결제 방어(CAS 패턴)와, 서비스 확장을 위한 Nginx 로드밸런싱(Scale-out) 아키텍처에 대해 다루었습니다. 서버가 여러 대가 되면 필연적으로 새로운 문제에 직면합니다. 결제창에서 인증을 마치고 returnUrl로 돌아오는 찰나의 순간, 네트워크 지연이나 고객의 '새로고침'으로 인해 분산된 여러 서버(A 서버, B 서버)로 동일한 결제 승인 요청이 거의 동시에 인입되는 상황입니다. 오늘은 분산 환경에서 데이터베이스의 부하를 줄이고 중복 결제를 완벽하게 차단하기 위한 Redis 분산 락(Distributed Lock) 전략에 대해 이야기해 보겠습니다.1. DB CAS 패턴만으로는 부족할까?먼저, 지난 포스팅에서 완성했던 결제 승인.. 2026. 8. 27. 9개월간의 원온원을 마무리하며 조직 개편으로 인해, 9개월간 이어온 동료와의 원온원을 마무리하게 되었습니다.동료와는 여전히 같은 팀이지만, 새로운 팀장님 밑에서 기존 방식 그대로 원온원을 이어가기엔 다소 무리가 있었습니다. 오늘은 그동안 진행했던 원온원을 돌아보며, 어떤 변화가 있었는지 이야기해보려 합니다.기록으로 남긴 31번의 대화저희는 원온원이 끝날 때마다 그날 나눈 이야기를 간단히 시트에 기록해왔습니다.기간: 2025.12.9 ~ 2026.8.18진행 횟수: 31회원온원을 시작하게 된 계기는 팀 적응에 어려움을 겪던 동료를 팀에 조금 더 자연스럽게 융화시키기 위함이었습니다.9개월 후, 달라진 것들마무리를 앞둔 지금, 저는 동료와 저 자신 모두에게서 달라진 모습을 발견할 수 있었습니다.잡담이 늘었습니다. 업무적인 대화뿐 아니라 평.. 2026. 8. 21. 서버 한 대로 부족해졌을 때: 온프레미스 Nginx 로드밸런싱 구성 서비스 초기에는 서버 한 대로도 충분하지만, 거래량이 증가하면 서버의 CPU와 메모리만 늘리는 수직 확장(Scale-up) 에는 한계가 있습니다.이때 고려할 수 있는 방법이 애플리케이션 서버를 여러 대로 늘리는 수평 확장(Scale-out) 입니다.최근에는 Kubernetes와 Managed Load Balancer 등을 활용해 클라우드 환경에서 이를 자동화하는 구성이 일반적입니다.하지만 온프레미스 환경에서는 이러한 구성을 그대로 적용하기 어렵거나, 새로운 네트워크 구성과 운영 복잡도가 추가될 수 있습니다.특히 결제 시스템에서는 새로운 기술을 도입하는 것보다 팀이 장애 상황에서 빠르게 원인을 파악하고 대응할 수 있는 구조인지도 중요합니다.이번 글에서는 별도의 L4 장비 없이 Nginx를 Reverse P.. 2026. 8. 14. 결제 승인 요청이 두 번 들어오면 어떻게 될까? 고객이 결제 버튼을 눌렀는데 네트워크가 느려 응답이 늦어집니다. 초조해진 고객이 새로고침을 한 번 더 누릅니다. 그 순간, 동일한 returnUrl 요청이 거의 동시에 두 번 서버로 도착합니다. 서버는 두 요청 모두를 정상 결제로 처리했고, 고객의 카드에서는 같은 주문에 대해 결제가 두 번 나갑니다.이런 사고는 실제로 결제 시스템을 운영하다 보면 언제든 마주칠 수 있는 상황입니다. 오늘은 이런 중복 결제가 왜 발생하는지, 그리고 이를 막기 위해 동시성(Concurrency)을 제어하고 멱등성(Idempotency)을 보장하는 방법에 대해 이야기해 보겠습니다.1. 일반적인 결제 흐름과 스키마결제를 진행하려면 가장 먼저 우리 상점(DB)에 결제 정보를 보관하고, 고유한 주문번호(order_no)를 발급해야 .. 2026. 7. 23. [다짐] 불안과 가면증후군을 넘어, 10년 차 결제 엔지니어의 기록을 시작하며 최근 들어 커리어와 미래에 대한 고민이 깊어졌습니다. 더 높은 목표를 바라보며 매일 조금씩 나아가고 있다고 믿으면서도, 문득 당장 눈앞에 손에 잡히는 결과가 보이지 않을 때면 막연한 불안감이 엄습하곤 했습니다. 불안이 커질수록 스스로를 낮춰보게 되었고, 앞으로 나아가는 발걸음마저 주저하게 되더군요. 그럴 때마다 AI와 긴 상담을 나누기도 했습니다. AI는 제가 그동안 치열하게 쌓아온 이력과 성과들을 나열하며 이것은 '가면증후군'일 뿐이라고 저를 위로해 주었습니다. 하지만 머리로는 이해하면서도 마음속 깊이 "이게 정말 그렇게 대단한 건가?"라는 의구심이 지워지지 않았습니다. 타인의 평가나 AI의 위로를 제 스스로 온전히 납득할 수 없었던 것입니다.깨달음: 전문성은 눈에 보이는 형태로 존재해야 한다왜 그토록.. 2026. 7. 10. 이전 1 2 3 4 ··· 18 다음 반응형
