결제 플랫폼 토픽 풀 확장으로 30일 중복 제거 병목 해소

결제 플랫폼의 토픽 풀 크기를 28에서 100으로 확장하면서 30일 중복 제거 로직의 성능 병목을 풀어낸 작업이다.

토픽 풀 확장의 배경

내부 메시지 큐 시스템에서 TOPIC_POOL은 동시에 처리할 수 있는 독립적인 토픽 인스턴스의 개수를 의미한다. 원래 28로 설정되어 있었는데, 30일 중복 제거 로직(이하 "30d dedup")에서 풀 크기가 병목이 되고 있었다. dedup 작업이 토픽별로 순차 처리되는 구조였기 때문에, 풀이 작을수록 큐 대기 시간이 길어지는 악순환이었다.

이 문제는 처음엔 간단해 보였지만, 실제로는 몇 가지 의사결정 포인트가 있었다. 풀 크기를 무작정 늘리면 메모리 압박이 생기고, 동시 처리 스레드 수가 늘어나면서 락 경합(lock contention)이 증가할 수 있다. 그래서 팀 내에서 28→100이 적절한지 검증하는 과정을 거쳤다.

generate.py에서의 구체적 변경

generate.py는 토픽 풀을 초기화하고 워커 스레드를 생성하는 부트스트랩 코드다. 여기서 풀 크기 상수를 28에서 100으로 변경했다. 한 줄짜리 변경처럼 보이지만, 이 파일에는 풀 생성 로직, 워커 할당, 메모리 예비 계산 같은 여러 영향 지점이 있다.

실제로 코드 리뷰를 받을 때 다음 부분들을 함께 점검했다:
- 풀 크기 상수가 하드코딩되지 않았는지 (설정 파일로 빼야 하는가)
- 메모리 예비 계산이 100 기준으로 재평가되었는지
- 테스트 환경에서 먼저 부하 테스트를 돌렸는지

30d dedup 병목 해소의 의미

30일 중복 제거는 금융 거래 시스템에서 매우 중요한 기능이다. 같은 거래를 실수로 두 번 처리하는 것을 방지하기 위해, 최근 30일간의 거래 ID를 캐시하고 중복 여부를 체크한다. 이 작업이 토픽별로 한 번에 하나씩만 실행되면, 높은 트래픽 시간대에 검증 큐가 쌓인다.

토픽 풀을 28에서 100으로 늘리면, dedup 작업을 병렬로 처리할 수 있는 슬롯이 72개 추가된다. 물론 이게 선형으로 처리량을 증가시키는 건 아니지만(I/O 대기, 캐시 미스 등의 변수가 있음), 평시 평균 처리 지연을 상당히 줄일 수 있다.

비슷한 패턴을 다른 큐 기반 시스템에서도 자주 본다. 예를 들어:
- 이메일 발송 큐의 워커 수 조정
- 로그 수집기의 파티션 수 확대
- 분석 데이터 파이프라인의 병렬 처리 도수 증가

모두 동일한 트레이드오프를 갖는다: 처리량 증대 vs. 리소스 사용량 / 복잡도 증가.

이 작업으로 배운 점

한 번에 한 파일, 한 줄짜리 변경이지만, 그 배경을 팀에 설득하는 과정이 중요했다. 단순히 "풀을 100으로 늘리자"라고 하면 누군가는 "왜 100? 50은 안 되나? 200은?" 질문이 나온다.

그래서 사전에 모니터링 대시보드를 들었다. dedup 큐의 평균 대기 시간, P99 지연, 메모리 증가 추세를 함께 봤다. 데이터가 있으면 의사결정이 훨씬 선명해진다.

또 하나는, 설정값을 코드에 하드코딩하지 않는 습관이다. 이번엔 generate.py에 상수로 들어갔지만, 다음엔 환경 변수나 설정 파일로 뺄 계획이다. 프로덕션 이슈가 급하게 터졌을 때 재배포 없이 풀 크기를 조정할 수 있어야 한다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 노트북 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.