복잡한 비즈니스 로직을 파이프라인으로 정리하기

카카오뱅크의 대출 심사처럼 단계가 많고 정책 변경이 잦은 로직은 하나의 거대한 함수로는 감당하기 어렵다. 공공 마이데이터로 수집한 문서를 가공하는 과정에서도 현직장·전직장 추출, 월별 소득 산출, 예외 처리 규칙이 한 함수에 쌓이며 코드가 500줄 가까이 커졌고, 중간 상태를 확인하거나 단위 테스트를 작성하기도 힘들어졌다.

이를 해결하기 위해 GitLab CI/CD 파이프라인에서 아이디어를 가져와, 비즈니스 로직을 Pipeline / Job / Store로 나눈 구조를 만들었다. Pipeline은 initJob → jobs → finishJob의 고정된 실행 흐름을 관리하고, Job은 문서 검증·현직장 추출·소득 계산처럼 하나의 책임만 맡는다. Store는 각 Job이 결과를 주고받는 공용 작업대로, 중간 결과를 명시적으로 보관해 흐름을 한눈에 드러낸다.

구조의 핵심은 다음 세 가지였다.

• 순차적으로 읽히는 흐름: 위에서 아래로 실행 순서가 자연스럽게 보인다.
• 교체 가능한 단계: 정책이 바뀌면 해당 Job만 새 구현으로 바꿀 수 있다.
• 테스트 친화성: 각 Job을 독립적으로 검증하고 중간 결과를 쉽게 확인할 수 있다.

예를 들어 기존에는 extractCurrentCompany와 그 결과를 사용하는 후속 로직이 한 덩어리로 얽혀 있었지만, 파이프라인에서는 ExtractCurrentCompany를 ExtractCurrentCompanyV2로 교체하는 식으로 대응할 수 있다. 직장가입자만 대상이던 정책이 지역가입자까지 확장되더라도, 전체 흐름을 다시 뜯어고칠 필요 없이 해당 Job만 바꾸면 된다.

이 방식의 효과는 명확했다. 정책 변경의 영향 범위가 Job 단위로 줄어들고, 수정 후 사이드 이펙트를 걱정하는 부담도 크게 낮아졌다. 테스트 역시 전체 파이프라인을 매번 돌리는 대신 특정 Job만 분리해 검증할 수 있어 피드백 사이클이 짧아졌다.

결국 복잡한 금융 도메인에서는 거대한 로직을 한 함수에 몰아넣기보다, 처리 단계를 작은 Job으로 쪼개고 흐름은 Pipeline이 책임지는 방식이 더 안정적이었다. 모든 상황의 정답은 아니지만, 빠르게 변하는 정책과 복잡한 규칙을 안전하게 다루기에는 충분히 실용적인 구조였다.