금액 표시 규칙을 파이프라인으로 자동화
목차
생성 단계부터 발행 직전까지 금액 데이터를 정제하는 두 단계 파이프라인을 연결했다. 예전엔 생성 후 발행 직전에 데이터를 일일이 정제해야 했는데, 이제 규칙을 파이프라인에 넣어두니 수동 작업이 줄어들었다.
왜 2단계로 나눴는가
금액을 사람이 읽기 좋은 형식으로 변환하는 "humanizer" 기능을 운영하면서 느낀 문제가 있었다. 단순히 마지막 단계에서만 정제하면, 중간에 생성된 데이터가 일관되지 않아서 결국 발행 직전 단계에서 손을 많이 거쳐야 했다. 팀원이 발행 체크리스트를 확인할 때마다 "어? 이건 왜 이 포맷이지?" 하며 작은 실수들이 쌓였다.
이 문제를 해결하려면 생성 단계에서부터 규칙을 주입하는 게 맞다고 판단했다. 단, 발행 직전에는 최종 검증이 필요하다. 그래서 1층과 2층으로 나누기로 했다.
1층: 생성 단계에서 톤 규칙 주입
첫 번째 단계는 데이터를 생성할 때부터 톤(tone) 규칙을 적용하는 것이다. 여기서 "톤"이란 금액이 표시되는 방식의 기본 규칙을 말한다. 예를 들면:
- 자릿수 처리 (몇 자리까지 표시할 것인가)
- 단위 표기 (통화 기호는 어디에 붙을 것인가)
- 소수점 처리 (몇 번째 자리까지 보여줄 것인가)
생성 단계에서 이런 규칙들을 먼저 적용해두면, 모든 금액 데이터가 일관된 형태로 흘러간다. 팀원이 생성된 데이터를 보면 이미 원하는 포맷이 적용된 상태다.
2층: 발행 직전 데이터 정제(scrub)
두 번째 단계는 발행 직전의 최종 정제다. 여기서는 1층에서 적용된 규칙들이 제대로 유지되었는지, 혹은 특수한 케이스(음수, 0, 매우 큰 수 같은)가 올바르게 처리되었는지를 확인한다. "scrub"이라고 부르는 이유는 데이터를 한 번 더 닦아내는 느낌이기 때문이다.
예를 들어:
- 실제 발행 가능한 금액 범위인지 검증
- 텍스트 인코딩 문제는 없는지 확인
- 계산 오차나 반올림 누적이 있는지 재검증
이 단계는 1층에서 놓친 엣지 케이스나 외부 시스템과의 연동 과정에서 생긴 데이터 왜곡을 잡아내는 방어선 역할을 한다.
파이프라인 연결의 효과
두 단계를 명확하게 분리하고 연결하니 몇 가지 좋은 점이 생겼다:
| 측면 | 이전 | 지금 |
|---|---|---|
| 데이터 일관성 | 발행 직전 수동 정제 필요 | 생성 시점부터 규칙 적용 |
| 코드리뷰 | "왜 이 포맷?" 질문 반복 | 규칙이 코드에 명시적으로 드러남 |
| 휴먼 에러 | 누락되기 쉬운 케이스 있음 | 2단계 체크로 감지율 높음 |
| 변경 영향 | 여러 곳 손봐야 함 | 해당 층만 수정 |
회고: 이런 설계를 배운 점
처음엔 "발행 직전에만 정제하면 되지 않나?"라고 생각했다. 하지만 팀이 커지고 데이터 검증 요청이 늘어나면서 규칙이 분산되는 문제가 생겼다. 누구는 생성 단계에서 처리했고, 누구는 발행 단계에서만 했고…
이 경험에서 배운 건 "규칙은 첫 입구부터 명확하게 적용하되, 최종 출구에서 한 번 더 검증하라"는 원칙이다. 1층은 기본 규칙의 일관성을, 2층은 완성도를 책임진다. 이렇게 책임을 나누니 테스트도 쉬워졌고, 팀원이 코드를 이해하기도 더 수월해졌다.
만약 금액 표시 규칙을 바꿔야 하면? 이제는 generate.py에서 톤 규칙 한두 곳만 수정하면 된다. 1층과 2층이 명확하게 분리되어 있으니 변경 범위도 예측 가능하다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.