본사·유럽법인 Oligo 주문등록 구조 개선 및 동시성 위험 제거

배경과 문제

Oligo 주문등록 Service는 주문번호·고객 국가·저장 목록·메일 데이터를 멤버 변수에 두고 메서드 시작 시 다시 초기화했습니다. 단일 요청에서는 정상처럼 보이지만 Singleton Bean을 여러 요청이 공유하므로 처리 중 다른 요청의 값으로 바뀔 수 있었습니다.

소스 분석으로 동시 요청에서 주문 데이터가 섞일 가능성을 확인해, 운영 장애로 이어지기 전에 공유 가변 상태를 제거했습니다.

역할과 책임 범위

• 본사·유럽법인 주문등록 Service의 상태 보관 방식과 호출 흐름 분석
• 요청 상태 지역 변수화와 5개 주문 유형의 공통 인터페이스 설계·구현
• 각 시스템의 상이한 업무 규칙 보존과 회귀 시나리오 검증

확인한 증거와 원인 분석

• 요청마다 바뀌는 주문·배송·메일용 값이 Singleton Service 멤버 변수에 선언된 구조 확인
• Custom·Duplex·Plate·Premade·RAPD 분기에서 변환·집계·저장 로직이 반복되는 구간 확인
• 본사와 유럽법인이 같은 개선 방향을 필요로 하지만 CES 연계·견적·메일 등 업무 분기가 다른 점 대조

검토한 대안과 선택 기준

• 멤버 변수에 synchronized를 적용하거나 Prototype Scope로 바꾸지 않고 Service를 무상태 구조로 전환
• 주문 유형별 차이를 한 메서드에 합치지 않고 공통 동작만 인터페이스로 정의
• 한쪽 법인의 코드를 복사하지 않고 공통 원칙과 시스템별 업무 규칙을 분리해 각각 반영

설계 및 구현

• 요청별 주문·배송·메일 데이터와 집계값을 메서드 파라미터·지역 변수로 이동
• 5개 주문 모델이 공통 주문 정보 변환 메서드를 구현하도록 인터페이스 구성
• 시퀀스 정규화·주문 속성·단가와 Invoice 처리를 별도 유틸리티·서비스로 분리
• 본사 CES 합성 Primer·배송·할인 규칙과 유럽 견적·메일·아웃소싱 분기를 각각 보존

테스트와 검증

• 5개 주문 유형의 신규 등록과 유형별 저장 데이터 확인
• Custom·Duplex·Plate 등록 후 주문접수 화면 수정과 Premade·RAPD 재고성 주문 검증
• 본사 동일 11개 시나리오를 3자 테스트와 사용자 테스트 두 단계에서 반복해 운영 반영 기준 확인

운영 반영 결과

사용 기술