옴니채널 OMS는 자사몰·네이버/쿠팡 마켓·오프라인 POS·B2B EDI 등 주문 입수 경로별로 서로 다른 데이터 모델·결제 흐름·반품 정책을 단일 파이프라인에서 흡수하는 시스템이다. 채널마다 필드명·통화·세금·할인 구조가 달라 raw_order를 그대로 후속 단계(라우팅·EDD·반품)로 넘기면 분기 코드가 폭발적으로 늘어난다.

RT-O6은 ChannelAdapter 패턴으로 raw_order를 표준 OrderRequest 객체로 정규화하고, 채널 코드(channel_type)를 메타로 보존해 후속 라우팅·EDD·반품 로직에 일관된 인터페이스를 제공한다. 이렇게 하면 RT-O1(DOM Score Engine)·RT-O3(EDD)·RT-O5(반품) 모두 채널 무관한 동일한 인터페이스로 호출 가능하여, 신규 채널이 추가되어도 어댑터 파일 1개만 추가하면 되는 O(1) 확장성을 확보한다.

class ChannelAdapter:
    def __init__(self):
        self.parsers = {
            "mall": MallParser(),
            "marketplace": MarketplaceParser(),
            "pos": PosParser(),
            "edi": EdiX12Parser(),
        }

    def normalize(self, raw_order, channel_type):
        # 채널별 어댑터 dispatch
        parser = self.parsers[channel_type]
        std_order = parser.to_standard_order(raw_order)
        std_order.meta["channel"] = channel_type
        return std_order   # 표준 OrderRequest 객체로 변환

예) 자사몰 webhook 1건은 field_match=0.96, schema_valid=1, conflict=0 → unify_score 0.98로 즉시 표준화. EDI 850 파일은 50라인 아이템에서 conflict=0.3이 발생하여 별도 워커 풀에서 재시도된다.

마켓플레이스가 일일 11,800건으로 가장 큰 트래픽을 차지하지만, 파싱 latency 자체는 EDI(540ms)가 압도적으로 높다. EDI 비중이 1.5%에 불과하더라도 동일 워커 풀에서 처리하면 전체 p95를 끌어올리는 long-tail 원인이 되므로 4월부터 별도 워커 풀로 격리했다.