Organizing Complex Business Logic into Pipelines

Logic with many steps and frequent policy changes, like KakaoBank's loan screening, is hard to handle with a single massive function. In the process of processing documents collected via public MyData, rules for extracting current/previous employer, calculating monthly income, and exception handling all piled up into one function, growing the code to nearly 500 lines, making it difficult to check intermediate states or write unit tests.

To solve this, the idea was borrowed from GitLab CI/CD pipelines, creating a structure that splits business logic into Pipeline / Job / Store. The Pipeline manages a fixed execution flow of initJob → jobs → finishJob, and each Job handles only one responsibility, such as document validation, current employer extraction, or income calculation. The Store is a shared workspace where each Job passes results back and forth, explicitly holding intermediate results so the flow is visible at a glance.

The core of the structure came down to three points:

• A flow that reads sequentially: the execution order naturally appears from top to bottom.
• Replaceable steps: when policy changes, only the relevant Job needs to be swapped for a new implementation.
• Test-friendliness: each Job can be verified independently, and intermediate results are easy to check.

For example, previously extractCurrentCompany and the subsequent logic that used its result were tangled together in one block, but in the pipeline, this can be handled by simply replacing ExtractCurrentCompany with ExtractCurrentCompanyV2. Even if a policy that originally targeted only employed insured persons expands to include regional insured persons, there's no need to overhaul the entire flow—only the relevant Job needs to change.

The effect of this approach was clear. The scope of impact from policy changes shrank to the Job level, and the burden of worrying about side effects after modifications was greatly reduced. Testing also became faster, as feedback cycles shortened since specific Jobs could be isolated and verified instead of running the entire pipeline every time.

Ultimately, in a complex financial domain, rather than cramming massive logic into a single function, splitting processing steps into small Jobs while letting the Pipeline handle the flow proved more stable. It's not the right answer for every situation, but it was a practical enough structure for safely handling rapidly changing policies and complex rules.