문제를 중심으로
모아보기.

06

분산시스템

• 매일 2,000건을 버리던 배치에 백프레셔 넣기06.05
• 세 서비스에 흩어진 분산락을 하나로 통일하기05.08
• 환급 배치를 사용자 단위로 쪼개고 멱등하게 만들기04.10
• 펌뱅킹 출금과 내부 원장을 맞추는 하루 단위 대사03.13
• 최종적 일관성을 검증하는 결제·정산 대사04.21
• 결제와 정산을 분리하면서 생긴 데이터 정합성 문제02.17

03

Architecture

• 흩어진 알림톡 발송을 서버 하나로 모으기01.13
• 227줄이 된 전역 예외 처리를 갈래별로 가르기08.18
• 모놀리식으로 만든 PG를 다시 MSA로 나눈 이유01.20

02

Database

• 결제 API 응답속도를 30% 개선하면서 배운 SQL 튜닝06.17
• 레거시 테이블 300개에서 옮길 것만 남기기05.06

04

DevOps

• 운영 업무 처리를 AI에게 맡기며 그은 선09.16
• 배포할 때마다 끊기던 지급 처리 떼어내기08.14
• 사내 설정 서버에 묶여 있던 테스트 떼어내기09.15
• 배포에 45분 걸리던 PG를 3분 만에 배포하기까지07.22

01

Kafka

• 실패한 메시지 하나가 파티션을 계속 막았다03.17

02

Observability

• 완주한 작업만 남기던 로그와 사라진 실패07.03
• 장애를 가장 먼저 알려주는 사람이 고객이었다08.19

05

PG 플랫폼

• PG 플랫폼을 두 번 갈아엎고 떠나며11.17
• 혹시나 해서 둔 배치에 진짜로 걸렸다10.20
• 월 15,000건 정기 결제의 중복 승인·과거 정산 변동·재시도 쏠림 막기06.16
• 연 3,000억 결제 시스템을 Spring Boot로 전환하며 세운 원칙05.20
• 레거시 PG 플랫폼을 Spring Boot로 전환하게 된 이유04.15

03

Security

• 목록 대신 Redis 만료로 동시 접속 세기07.21
• PG 시스템 보안 심사에서 마주친 104개의 보안 이슈10.21
• 무중단 개인정보 암호화와 함께 깨진 검색·정렬·조인09.09

01

Testing

• 실패와 Timeout까지 포함한 금융 결제 테스트 범위09.23