Rails로 가능한 예외 업무에 처리 흔적을 남기지 않는 설정 패턴

예외 업무의 본질과 어려움

• 사카노 토추의 야채 배송 사업은 겉보기에는 단순하지만, 실제로는 수많은 생산자, 조합, 물류 회사, 재포장, 다양한 판매처를 거치는 복잡한 유통 경로를 가집니다.

• 쉽게 상하고 날씨에 영향을 받는 야채의 특성상 ‘불확실성과의 싸움’이며, 이로 인해 요일별 배송 경로, 알레르기 고객 대체품, 동일 대체품 중복 방지 등 잦은 예외 상황과 현장의 노하우가 축적됩니다. 이러한 현장의 지혜가 바로 ‘예외 업무’입니다.

• 개별 기능을 구현하는 것은 어렵지 않으나, 운영 과정에서 업무 담당자 변경, 시스템 간 충돌, 시스템 외부(Excel 등)에서 별도 관리 등의 문제로 ‘거대한 진흙 덩어리(Big Mud Ball)’가 되어 변경 영향 범위를 파악하기 어렵게 만듭니다. 모든 예외를 엔지니어가 개발하고 파악하는 것은 한계가 있으므로, ‘설정화(設定化)’를 통해 역할 분담을 하는 것이 중요합니다.

• 설정화의 핵심은 ‘설정의 이해 용이성’을 높여 복잡성을 줄이고, 최소한의 설명으로 사용자가 활용할 수 있도록 하는 것입니다.

예외 업무 처리를 위한 6가지 설정 패턴

발표자는 “슈퍼 체인 A/B/B 매장에 다른 납품서 출력”이라는 기능을 예시로 6가지 구현 패턴을 제시합니다.

1. 코드에 직접 작성: YAGNI 원칙에 따라 초기에는 하드코딩하고, 매직 넘버를 피하는 수준으로 시작합니다.

2. 공통 설정 테이블: 향후 변경 가능성이 있는 항목을 관리자 화면에서 변경할 수 있도록 Config 테이블을 만듭니다. 변경 빈도가 낮은 경우에 적합합니다.

3. 비고란 활용: 사용자가 관리 화면에서 설정하고 싶을 때 비고(remark) 필드를 활용합니다. 사용자 관점에서 대화하기 용이하며, 추후 요구사항 변경 시 유연하게 대응할 수 있습니다.

4. 독립된 컬럼에 정의: 납품서 포맷이 늘어날 경우, DB에 0, 1, 2 대신 ‘Normal’, ‘Special’과 같이 이름을 부여한 구분 값을 독립된 컬럼에 정의하여 데이터 분석 시 매직 넘버를 방지합니다.

5. 값 객체(Value Object) 이용: 복잡한 설정(예: 금액 계산 방식)의 경우 Struct를 활용한 값 객체로 고정값을 정의하여 변경 조합 패턴을 줄이고 ‘조합 폭발’을 방지합니다.

6. 전용 관리 화면: 예외 업무가 일반적인 업무 설정이 될 정도로 복잡해지면 전용 관리 화면을 구축합니다.

• 이 모든 패턴에서 검색 범위와 판정 로직은 변하지 않고 모델 정의만 변경되었다는 점이 중요합니다. 이는 개발 초기 작은 투자가 회수된 결과입니다.

설정 패턴 선택 기준 및 운영 노하우

• 선택 기준: ‘변경 빈도’와 ‘설정의 복잡성’을 기준으로 1번(직접 코딩)부터 6번(전용 관리 화면)까지의 패턴을 선택합니다. 복잡한 설정은 5, 6번, 변경 빈도가 적으면 1번도 가능합니다.

• 운영 노하우:

  • 화면상 올바른 표시: 매직 넘버는 코드뿐 아니라 업무 담당자에게도 혼란을 주므로, 이름 붙인 설정은 화면에도 명확히 표시하고 비고란 사용 시 태그를 활용하여 오타를 방지합니다.
  • 영향 범위 명확화: 변경 시 영향 범위를 알 수 없으면 아무도 변경하지 않으므로, 사용자에게 이해하기 쉬운 일관된 이름을 사용하고 화면에 영향 범위를 명시합니다. ‘설정 복사 기능’은 사용 편의성을 크게 높이며 구현 비용도 낮습니다.
  • 이력 관리 및 복원: Audits Gem 등을 활용하여 변경 이력을 남기고 사용자에게도 열람 가능하게 하여 안심감을 주고 문제 원인 조사에 도움을 줍니다.
  • 예외 업무 자체를 없애기: 근본적으로 예외 업무를 줄이는 노력이 필요하며, 엔지니어가 먼저 단순화를 제안하는 것이 중요합니다.