서론
올해 초, 고객사에서 일 1000~2000건에 달하는 문서를 수동으로 분류해오고 있던 문제를 발견했습니다.
그동안 우리 프로그램은 물리적인 기록을 데이터로 남기는 것에 불과했고,
이런 부분을 프로그램을 활용하는 목적을 만들어주고 싶어서 만들었습니다.
이 문서는 아마존의 1-Pager 느낌으로 저의 고민과 의사결정을 기록하기 위해 남깁니다.
색다른 시도지만 꾸준히 이렇게 문서화를 통해 의사결정의 과정을 남겨보려 합니다.
1. 문제 정의 (The Problem)
- Context: 하루 2,000건 이상의 수입신청서 분류 업무를 인력이 수동으로 처리.
- Critical Issue: 잦은 휴먼 에러와 일일 3~4시간의 운영 리소스 낭비. 특히 비즈니스 정책 변경 시마다 분류하는 기준을 변경해야 하는데, 이 부분을 사용자가 유연하게 처리할 수 있도록 제공해주고 싶음
2. 해결 방안 (Proposed Solution)
- Core Concept: 사용자가 직접 필터 룰을 조립하고, 시스템이 이를 실시간으로 반영하는 '배포 없이 동작하는 룰 엔진' 구축.
- Architecture: Java Reflection과 전략 패턴(Strategy Pattern)을 결합하여, DB에 저장된 룰 메타데이터를 런타임에 동적으로 로드 및 실행하는 구조 설계.
3. 엔지니어링 의사결정 (Why Reflection?)
- 런타임 유연성 확보: 정책이 수시로 변하는 도메인 특성상, 정적 코드 대신 실행 시점에 로직을 재구성할 수 있는 리플렉션이 최적의 선택이라 판단.
- Fail-Safe 검증: 리플렉션의 고질적인 문제인 NoSuchFieldException 등을 방어하기 위해 실행 전 메타데이터 유효성 검증 레이어를 구축하여 시스템 안정성 확보.
4. 트레이드오프 (Trade-offs)
- Performance vs Agility: 리플렉션의 성능 오버헤드(JVM 최적화 불가 등) [1]를 인지했으나, 현재 트래픽(2,000건/일) 규모에서는 비즈니스 대응 속도 향상의 이득이 성능 저하보다 훨씬 크다고 판단.
- 문서를 받는 서버와 운영 서버는 별도로 동작. 따라서 문서를 받는 서버에서 JVM 수준에서 운영 서버에 영향이 없을 것이라 판단.
5. 결과 (The Impact)
- 정량 성과: 수동 분류 업무 90% 자동화, 일 평균 3시간의 가용시간 확보, 배포 없이 룰 반영 가능
---
[1] 리플렉션 성능 하락
리플렉션이 느린 이유는 크게 세 가지입니다.
- JVM 최적화 불가: 자바는 컴파일 시점에 코드를 최적화(JIT 컴파일 등)하는데, 리플렉션은 실행 시점에 결정되므로 이 최적화 과정을 거칠 수 없습니다.
- 보안 및 접근 체크: 호출할 때마다 "이 메서드에 접근할 권한이 있나?"를 매번 확인하는 오버헤드가 발생합니다.
- 이름 검색 비용: 클래스 메타데이터에서 문자열로 메서드나 필드 이름을 매번 찾아야 하므로 일반 호출보다 훨씬 무겁습니다.
