위밋모빌리티 FDE 는 SAP·ERP·메시징 등 외부 시스템과의 API·웹훅 수신/발신 연동을 재시도·멱등성·정합성·관측성까지 프로덕션 수준으로 완성하고, 표준 기능으로 안 풀리는 고객 요구를 구조화해 코어 팀에 재사용 가능한 형태로 전달합니다. 화주마다 다른 주문 페이로드를 표준 스키마로 정규화해 LIO·ROOUTY 경로최적화 입력 전에 거르는 이 수신 게이트는 그 핵심(연동 경계 멱등성·정합성·마스터 참조 검증·요구 구조화)을 정면으로 입증합니다. 다만 물류·SCM 최적화 도메인 전문성이나 실제 화주 주문 분포는 포트폴리오로 증명되지 않으므로 주장하지 않고, 일반 물류 더미로 기술만 보이며 경로최적화 엔진 자체는 만들지 않습니다. 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다. 수신을 정규화·규칙·마스터 참조로 잇는 이 사슬은 단순 이벤트 적재 맥락으로는 그대로 만들 수 없습니다.
SAP·ERP·메시징 API·웹훅 수신/발신 연동을 멱등성·정합성·관측성까지 프로덕션 수준으로 완성합니다. 주문 수신 게이트가 이 경계와 직접 정렬됩니다.
인덱스·실행계획·락/트랜잭션 근거의 관계형 DB 운영과 입력검증·권한 격리를 다룹니다. 마스터 참조 정합성 규칙이 이 환경과 정렬됩니다.
고객 특화 요구를 구조화해 코어 팀에 재사용 가능한 형태로 전달합니다. 비표준 주문을 표준 스키마로 정규화하는 축이 여기에 정렬됩니다.
화주 고객사가 API·웹훅으로 보내는 주문(배송 요청) 이벤트를 연동 경계에서 받아, 표준 주문 스키마로 정규화한 뒤 규칙(스키마 위반·제약 위반·멱등성 중복·마스터 미참조·결측)으로 적재할지 보류할지 거부(DLQ)할지 정합니다. 라우팅 정답은 스키마·제약·멱등성·화주/차량 마스터 참조 규칙이 결정하고, LLM 은 비표준 페이로드의 표준 필드 매핑과 거부 사유 문장화 보조만 맡습니다. LIO·ROOUTY 경로최적화 엔진 자체가 아니라 그 입력 전 정합성 게이트입니다.
위밋모빌리티 FDE(고객사 연동 담당). 화주마다 제각각인 주문 페이로드를 받아 미등록 코드·제약 위반·중복 재전송을 일일이 눈으로 걸러 적재하던 일을, 한 게이트에서 정규화·검증·라우팅 결과를 함께 보고 싶은 사람입니다.
수신 주문을 표준 스키마로 묶고 화주/차량 마스터를 붙이면, (a) 스키마 위반·제약 위반·멱등 중복·미등록 화주를 규칙으로 걸러 DLQ 로 격리하고, (b) 거부 사유를 원문 필드값 인용으로 풀며, (c) 여러 화주의 비표준 주문을 끊김 없이 표준 스키마로 정규화합니다.
고객사 주문 이벤트를 받아 표준 스키마로 정규화하고 스키마·제약·멱등성·마스터 참조를 검사해 적재/보류/거부(DLQ)로 라우팅하는 동작하는 게이트입니다. 화주·주문·마스터는 일반 물류 더미로 시작하고 수신 엔드포인트는 사내 API 가정으로 둡니다.
라우팅 판정을 심은 정답 라벨·운영자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면이고, 이때부터 AWS 로 배포·운영합니다.
화주·거부 사유별 라우팅 정합성과 멱등 중복률·DLQ 사유 분포를 누적 집계해 약한 연동을 보여주는 화면입니다.
정상·제약위반·멱등중복·미등록화주 주문 시나리오 12종을 넣으면, 정규화·검증·라우팅 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 주문 30종(좌표 결측·미등록 화주 코드·중량 음수·주소 표기 흔들림·중복 재전송)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 라우팅 40건 중 적재/보류/거부 판정이 일치한 게 36건(약 90%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 위밋모빌리티의 실 화주 주문 데이터와 실 운영자가 있어야 측정 가능합니다. 이 게이트는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 미등록 화주·중량 음수·좌표 결측·화주명 표기 흔들림·중복 재전송 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 주문만 통과시키는 게 아님을 보여줍니다
LLM 이 정규화한 표준 필드는 그럴듯해도 원문 페이로드에 없을 수 있습니다. 정규화 값마다 원문 필드값 인용을 달게 하고, 근거가 없으면 '미매핑'으로 표시해 추측 적재를 막습니다
화주마다 주문 표기가 제각각입니다. 정규화로 표준 코드에 묶고, 못 묶으면 추측하지 말고 '미매핑'으로 보류에 둡니다. 실제 도입 시 화주별 실 양식·마스터가 더미와 다르므로 표준 스키마를 다시 맞춰야 합니다(도입 단계 과제로 분리)
이 포트폴리오가 입증하는 것은 연동 경계 수신·정규화·멱등성·마스터 참조 정합성 검증 기술입니다. LIO·ROOUTY 경로최적화나 물류·SCM 최적화 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 경로최적화 엔진 자체는 만들지 않습니다. 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 수신 주문 이벤트 로그. 정합성 규칙이 가장 먼저 질의하는 테이블입니다. 미등록 화주·중량 음수·좌표 결측·화주명 표기 흔들림·중복 재전송을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| order_id | shipper_raw | shipper_id | pickup_ts | deliver_ts | lat | lng | weight_kg | idem_key | idem_seen | schema_ok | constraints_ok | master_hit | label | ts |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ord_001 | 씨제이대한통운 | cj | 2026-03-04T08:00 | 2026-03-04T15:00 | 37.5 | 127 | 12.5 | u-1001 | false | true | true | true | load | 2026-03-04T08:00 |
| ord_002 | 씨제이대한통운 | cj | 2026-03-04T14:00 | 2026-03-04T09:00 | 37.5 | 127 | 8 | u-1002 | false | true | false | true | reject | 2026-03-04T09:10 |
| ord_003 | 엘엑스판토스 | lx | 2026-03-04T10:00 | 2026-03-04T18:00 | 35.1 | 129 | 20 | u-1001 | true | true | true | true | reject | 2026-03-04T10:05 |
| ord_004 | 무등록화주Z | — | 2026-03-04T11:00 | 2026-03-04T17:00 | 36.3 | 127.4 | 5 | u-1003 | false | true | true | false | hold | 2026-03-04T11:00 |
| ord_005 | CJ 대한통운 | — | 2026-03-04T12:00 | 2026-03-04T19:00 | 37.4 | 126.9 | 9.5 | u-1004 | false | true | true | false | hold | 2026-03-04T12:00 |
아래 Zod 스키마에 맞는 수신 주문 60행 JSON 배열로 생성합니다. 화주 2~3개, 정상 위주에 보류·거부를 섞습니다. label 규칙: schema_ok=false 또는 constraints_ok=false 또는 idem_seen=true → reject, master_hit=false 또는 shipper_id=null → hold, 그 외(스키마·제약·멱등·마스터 모두 정상) → load.
z.object({ order_id: z.string(), shipper_raw: z.string(), shipper_id: z.string().nullable(), pickup_ts: z.string(), deliver_ts: z.string().nullable(), lat: z.number().nullable(), lng: z.number().nullable(), weight_kg: z.number(), idem_key: z.string(), idem_seen: z.boolean(), schema_ok: z.boolean(), constraints_ok: z.boolean(), master_hit: z.boolean(), label: z.enum(["load","hold","reject"]), ts: z.string() })
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 주문만 통과시키는 함정 회피): (1) 같은 화주의 표기 별칭('씨제이대한통운'/'CJ 대한통운', '엘엑스판토스'/'엘엑스 판토스'처럼 shipper_id 로 정규화돼야 함) 3건 이상, (2) 미등록 화주(shipper_id=null, master_hit=false) 2건, (3) 결측: lat/lng=null 또는 deliver_ts=null 인 행 2~3건, (4) 경계값: 중량 0·음수(constraints_ok=false)·픽업 시각이 배송 시각보다 늦은 제약 위반 각 2건, (5) 멱등 중복: 앞 행과 같은 idem_key 에 idem_seen=true 2건. label 은 위 규칙대로 정직하게. JSON 배열만.z.object({ order_id: z.string(), shipper_raw: z.string(), shipper_id: z.string().nullable(), pickup_ts: z.string(), deliver_ts: z.string().nullable(), lat: z.number().nullable(), lng: z.number().nullable(), weight_kg: z.number(), idem_key: z.string(), idem_seen: z.boolean(), schema_ok: z.boolean(), constraints_ok: z.boolean(), master_hit: z.boolean(), label: z.enum(["load","hold","reject"]), ts: z.string() })| Node.js | 주문 수신 워커·정규화·규칙 엔진·출력 스키마를 구동하는 서버 백엔드입니다 |
| TypeScript | 정규화 파서·검증 규칙·출력 스키마의 구현 언어입니다 |
| API·웹훅 수신 | 고객사 주문 이벤트를 받는 인바운드 연동 경계입니다 |
| 멱등성 키 | 같은 주문의 재전송을 중복 적재 없이 한 번만 처리하는 열쇠입니다 |
| 메시지 큐(DLQ) | 규칙 위반·거부 주문을 죽은편지큐로 격리해 재처리 대상과 분리합니다 |
| 관계형 DB | 화주·차량 마스터 참조 정합성 검증과 적재 저장소이며 인덱스·트랜잭션을 씁니다 |
| 이벤트 기반 아키텍처 | 주문 이벤트 단위로 수신·정규화·검증·라우팅이 흐르는 골조입니다 |
| 관측성(APM·로그·트레이스) | 수신·거부·지연을 추적하는 지표·로그·트레이스입니다 |
| AWS | 2주차부터 수신 워커·큐·DB 를 배포·운영합니다 |
| Kubernetes | 수신 워커와 큐 소비자를 컨테이너로 배포·확장합니다 |
| 입력검증·시큐어코딩 | 수신 페이로드 스키마 검증과 화주 데이터 권한 격리입니다 |
| LLM | 화주별 비표준 주문 페이로드를 표준 스키마로 정규화·매핑하고 거부 사유를 문장화합니다 |
| Claude | 정규화·사유 문장화 LLM 입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(라우팅이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(화주별 정합성 추이)로 진행합니다.
수신 주문 1건의 라우팅 결정 카드. 결정·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 경로최적화 판정이 아니라 연동 경계 정합성 게이트입니다.
z.object({ order_id: z.string(), shipper_id: z.string().nullable(), decision: z.enum(["load","hold","reject"]), factors: z.array(z.enum(["schema_violation","constraint_violation","idempotent_duplicate","master_miss","missing_field"])), reason: z.string().min(20), evidence: z.string().min(8), hedge: z.string().nullable() })[
{
"input_ref": "ord_002 (제약 위반)",
"output": {
"order_id": "ord_002",
"shipper_id": "cj",
"decision": "reject",
"factors": [
"constraint_violation"
],
"reason": "픽업 시각이 배송 시각보다 늦어 배차 제약을 위반합니다. 경로최적화 입력으로 넘기지 않고 거부해 DLQ 로 격리합니다.",
"evidence": "pickup_ts=2026-03-04T14:00, deliver_ts=2026-03-04T09:00",
"hedge": "제약을 위반해 적재하지 않습니다"
}
},
{
"input_ref": "ord_003 (멱등 중복)",
"output": {
"order_id": "ord_003",
"shipper_id": "lx",
"decision": "reject",
"factors": [
"idempotent_duplicate"
],
"reason": "이미 처리한 멱등키와 같은 재전송 주문이라 중복 적재하면 배차가 두 번 잡힙니다. 한 번만 처리하도록 거부합니다.",
"evidence": "idem_key=u-1001, idem_seen=true",
"hedge": "재전송 중복이라 적재하지 않습니다"
}
},
{
"input_ref": "ord_004 (미등록 화주)",
"output": {
"order_id": "ord_004",
"shipper_id": null,
"decision": "hold",
"factors": [
"master_miss"
],
"reason": "화주 코드가 마스터에 없어 표준 화주로 잇지 못합니다. 마스터 등록 후 재평가가 필요해 보류로 돌립니다.",
"evidence": "shipper_raw=무등록화주Z, master_hit=false",
"hedge": "마스터에 없는 화주라 적재하지 않고 보류로 둡니다"
}
}
][자동 검증] 1. 스키마 parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision 이 정합성 규칙(스키마 위반/제약 위반/멱등 중복→reject·미등록 화주/결측 노드→hold·통과→load)과 일치하는지 봅니다. 3. evidence 가 입력 주문의 실제 필드값 인용인지 토큰 매칭으로 확인하고, constraints_ok=false 면 load 가 되지 않게 강제합니다. 4. decision 을 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 운영자 2명이 비동기로 라우팅을 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.