주문 처리·백엔드

멀티채널 주문 수집·처리 파이프라인

역할

설계·구현 (2인 팀 메인 개발)

기간

2026

기술 스택

Node.jsExpressTypeScriptPythonSupabasePostgreSQLGCP
멀티채널 주문 수집·처리 파이프라인

※ 실제 관리 화면은 전 직장 저작권·기밀 유지 규정상 게재 불가. 기능을 재현한 목업(더미 데이터·익명화)으로 대체.

개요

여러 마켓플레이스에 동시 판매하는 사업자. 담당자가 채널마다 관리 사이트에 개별 로그인해 주문을 내려받고 수작업으로 정리하던 상태. 설계에서 먼저 정한 것은 '전부를 하나로 통일'이 아니라, 공통화의 경계를 어디에 한 번 그을지. 공통이어야 할 정책(Policy), 코어에 골격을 두고 차이는 어댑터로 주입하는 메커니즘(Mechanism), 일부러 통일하지 않는 확장점(Adapter)의 3층으로 분리. 채널마다 다른 API·인증·데이터 형식을 하나의 처리로 흡수. 비개발 상품기획팀과 정기 회의로 요건정의·사양 문서화 진행.

담당 업무

  • 01

    에이블리·지그재그·네이버 스마트스토어 오픈 API 직접 발급·연동. 플랫폼마다 다른 제휴 신청·심사 절차를 개발 이전 단계에서 직접 처리. 채널별 인증 방식과 응답 스키마를 공통 코어(collector-registry) 뒤 어댑터로 흡수해, API 연동·엑셀 업로드 두 경로를 단일 주문 양식으로 통일. 운영 25만 건 이상 처리.

  • 02

    마켓 API 사양 변경에 대응하는 failed_import 테이블 설계. 수집에 실패한 건을 원본 페이로드째 자동 적재해, 어느 채널이 무엇 때문에 깨졌는지 즉시 파악. 자동 재시도로 흘려보내지 않고 작업자가 건별로 판단·처리하는 구조.

  • 03

    합배송(동일 고객 주문 묶기)·주문분리(1리스팅 다중 상품)·오주문 등 예외를 신뢰도로 판별. 신뢰도 높은 건만 자동 처리하고 애매한 건은 리뷰 큐로 분기.

  • 04

    완전성 게이트는 어댑터가 누락을 정직하게 반환할 수 있을 때만 fail-closed 를 보증한다고 계약으로 명문화. '코어를 넣었으니 안전해졌다'로 보고하지 않고, 과거 주문 사일런트 누락 사고를 근본 원인부터 차단.

성과

채널을 오가던 수작업을, 경계를 의식한 공통 코어 위에서 예외까지 처리하는 자동 파이프라인으로 대체.