코어뱅킹 정산 자동화 개발기

코어뱅킹 팀은 기존의 월별 정산 방식이 가진 중복 정산, 오정산, 과거 데이터 추적의 어려움, 긴 지급 시간 문제를 해결하기 위해 일별 정산 체계로 전환했다. 한 달에 한 번 정산 종류별로 수동 처리하던 방식에서 벗어나, 매일 전날의 데이터를 기준으로 기록·지급·지급 확인·출금의 4단계 모듈로 정산을 분리했다.

정산을 모듈화한 이유는 명확했다. 오류가 나면 어느 단계에서 문제가 생겼는지 빠르게 찾을 수 있고, 필요한 단계만 수동으로 재처리할 수 있으며, 각 단계의 실행 결과를 눈에 보이게 관리할 수 있기 때문이다.

자동화는 Celery 기반의 분산·비동기 구조를 활용해 구현했다. 처음에는 순서대로 한 번씩 호출하는 방식을 생각했지만, 순서가 어긋나면 오정산이 생기고 실패 시 수동 복구가 필요하다는 문제가 있었다. 그래서 정산 모듈을 순서에 상관없이 하루에 여러 번 호출하되, 각 모듈이 스스로 중복 실행을 막는 방향으로 설계했다.

멱등성을 확보하기 위해 네 가지 장치를 두었다.

• 모든 모듈에 검증 단계를 두고, 조건을 만족해야만 작업을 수행한다.
• 이미 완료된 작업은 검증에서 실패하게 만들어 반복 실행을 막는다.
• 같은 모듈이 동시에 돌지 않도록 모듈별 lock을 적용한다.
• 모듈 내부 작업은 transaction으로 묶어 부분 성공을 없앤다.

지급 최적화에서는 도메인 제약이 중요했다. 농협 지급 API는 돈을 10만 원 단위로 나눠 호출해야 하므로, 예를 들어 25만 원은 10만 원, 10만 원, 5만 원으로 쪼개 여러 번 호출해야 한다. 이 작업은 CPU보다 외부 API 응답 속도에 영향을 받는 I/O-bound 작업이어서, 서버 성능을 높이기보다 분산화와 병렬 처리가 더 적합했다.

병렬 처리의 전제는 각 작업이 서로 독립적이어야 한다는 점이었다. 상품별 태스크와 지급 API 태스크가 서로 의존하지 않기 때문에 병렬화가 가능했고, 작업 분할과 스케줄링에 따른 오버헤드가 늘더라도 전체 수행 시간은 줄어들었다.

비동기 지급이 모두 성공했는지는 지급 태스크가 DB에 남긴 결과를 나중에 폴링해서 확인했다. 동시에 같은 작업이 두 번 실행되는 문제는 애플리케이션이 공유하는 DB에 advisory_lock을 걸어 방지했다.

결과적으로 일별 정산은 월별 방식보다 당일 추적과 수정이 쉬워졌고, I/O 작업을 병렬화해 지급 속도는 최대 4배 빨라졌다. 멱등성으로 중복 정산을 막았고, 정산 모듈을 주기적으로 자동 호출하는 구조까지 갖추면서 운영 안정성과 자동화를 함께 확보했다.