Palantir Technologies
경력근거: Wrangling massive-scale data and using AI to accelerate
※ 실제 산출물이 아닌 AI 예측 시안입니다.
Palantir의 이 자리는 고객 조직에 들어가 흩어진 데이터를 이어 운영을 움직이게 만드는 일이고, 공고는 공급망 분석을 그 예로 직접 듭니다. 남의 시스템 두 개를 잇는 자리에서는 분석보다 먼저 연결이 새는 지점을 보여 줘야 하는데, 그게 안 되면 뒤에 붙인 어떤 지표도 신뢰를 못 받습니다. 이 순서는 자기 데이터가 아니라 고객 데이터를 잇는 자리에서만 문제가 됩니다. 공고 업무는 아키텍처 결정부터 임원 대화까지 걸쳐 있는데 1주 범위에서 고를 수 있는 것은 하나라 연결 점검 축을 골랐습니다. 이 포트폴리오는 두 시스템을 키로 잇고 안 붙는 이유를 규칙으로 가르는 기술을 보여줍니다. 물류 운영이나 공급망 계획 자체의 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
대규모 데이터를 다루고 그걸로 중요한 운영을 가속하는 일이 핵심 업무로 적혀 있습니다. 두 시스템의 레코드를 잇는 일이 그 운영의 가장 앞 단계입니다.
전 세계 식량 공급망을 분석해 제때 원조를 전달하는 문제를 이 역할이 푸는 예로 직접 듭니다. 배송 이벤트와 주문을 잇는 일이 그 분석의 바닥입니다.
고객 요구에 맞춘 애플리케이션을 만들고 기술 담당자부터 임원까지 상대하는 일이 업무입니다. 무엇이 왜 안 붙는지 보여주는 화면이 그 대화의 자료가 됩니다.
운송사가 보내온 배송 이벤트와 사내 주문 원장을 주문번호로 이어, 어느 주문에도 붙지 않거나 시각과 상태가 어긋난 이벤트를 사유별로 나눠 보여주는 관리자 페이지입니다. 판정은 연결 키 존재와 시각 순서, 상태 조합을 원장과 견주는 대조로 정합니다.
고객사 물류 데이터를 한 화면에 모으러 들어간 파견 엔지니어입니다. 운송사 파일과 사내 원장을 붙였더니 이벤트 일부가 어느 주문에도 안 걸리는데, 키가 없는 건지 원장에 없는 건지 몰라 엑셀로 걸러 가며 원인을 나눕니다.
이벤트와 주문이 같은 키로 이어질 수 있으면, 무엇이 왜 안 붙는지는 사람이 걸러 보지 않아도 대조로 갈라집니다.
운송 이벤트 파일과 주문 원장 파일을 올리면 이벤트별 연결 판정을 사유별로 보여주는 관리자 페이지입니다. 운송사 API에 붙지 않고 내려받은 파일만 읽습니다.
주문을 누르면 붙은 이벤트를 시각 순으로 늘어놓아 어디서 끊겼는지 보여주는 화면입니다.
운송사 사전과 연결 키 규칙을 파일로 분리해 운송사마다 다른 참조 형식을 같은 판정으로 돌리고, 연결된 결과를 내보내 다음 분석이 받아 가게 합니다.
담당자가 이벤트 60행과 주문 원장을 올려 안 붙는 이벤트가 사유별로 나뉜 화면을 보는 것을 시연합니다.
결측·중복·미등록 운송사가 섞인 입력 30종을 올려도 화면이 깨지지 않고, 판정하지 못한 이벤트는 사유가 붙어 남습니다.
연결 키가 비어 있는 이벤트는 붙은 것으로 세지 않고 키 누락으로 따로 답니다. 잇지 못한 것을 연결로 만들지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 이벤트와 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 연결률은 Palantir 고객사의 실제 운송 이벤트와 실제 원장이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
운송사 표기가 파일마다 흔들린 건과 주문번호가 빈 건, 계약 목록에 없는 운송사를 이벤트에 일부러 넣었습니다. 붙는 건만 모아 두면 안 붙는 이유를 가르는 일 자체가 사라집니다.
안 붙는다고 해서 데이터가 잘못됐다고 단정할 수 없습니다. 원장에 아직 안 들어온 신규 주문일 수 있으므로, 판정은 지금 기준으로 안 붙는다는 사실까지만 읽어야 합니다.
실제 도입하면 운송사마다 참조 번호 형식과 이벤트 종류가 다릅니다. 키 규칙을 물류 담당자와 합의해 채우는 일이 도입 단계의 실제 과제입니다.
지연을 예측하거나 대안 경로를 제안하는 일은 이 도구의 범위 밖입니다. 데이터가 이어지는지까지만 보므로, 예측은 그다음 단계입니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
운송사가 보내온 배송 이벤트입니다. 운송사 표기가 파일마다 대소문자로 흔들리고, 사전에 없는 신규 운송사와 같은 이벤트 번호가 두 번 들어온 건, 주문번호가 비어 있는 행을 일부러 섞었습니다.
| event_no | carrier_raw | order_no | event_type | occurred_at | location_code |
|---|---|---|---|---|---|
| EV-001 | swiftlog | OD-1001 | picked_up | 2026-08-10T09:00 | ICN |
| EV-002 | SwiftLog | OD-1001 | in_transit | 2026-08-11T14:00 | SIN |
| EV-003 | SWIFTLOG | OD-1001 | delivered | 2026-08-13T10:00 | BKK |
| EV-004 | northline | OD-1002 | picked_up | 2026-08-11T08:00 | ICN |
| EV-005 | northline | OD-1002 | delivered | 2026-08-14T16:00 | HAN |
아래 JSON Schema에 맞는 운송 이벤트 행을 더 만들어 주세요. {"type":"object","properties":{"event_no":{"type":"string"},"carrier_raw":{"type":"string"},"order_no":{"type":["string","null"]},"event_type":{"type":"string","enum":["picked_up","in_transit","delivered","returned"]},"occurred_at":{"type":"string"},"location_code":{"type":"string"}},"required":["event_no","carrier_raw","order_no","event_type","occurred_at","location_code"]} 한 order_no에 이벤트가 두 건 이상 이어지도록 만들어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 carrier_raw가 사전에 없어 carrier_id가 null인 행, 둘째 표기흔들림으로 같은 운송사를 swiftlog와 SwiftLog와 SWIFTLOG처럼 대소문자만 다르게 적은 행, 셋째 중복으로 같은 event_no가 두 행에 있는 재적재 건, 넷째 결측으로 order_no가 null인 행, 다섯째 원장에 없는 order_no를 가리키는 행, 여섯째 경계극단으로 occurred_at이 주문의 약속일과 정확히 같은 행. 정상으로 붙는 이벤트가 전체의 절반쯤 되게 해 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 event_type에 enum 밖 값을 넣거나 occurred_at을 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"event_no":{"type":"string"},"carrier_raw":{"type":"string"},"order_no":{"type":["string","null"]},"event_type":{"type":"string","enum":["picked_up","in_transit","delivered","returned"]},"occurred_at":{"type":"string"},"location_code":{"type":"string"}},"required":["event_no","carrier_raw","order_no","event_type","occurred_at","location_code"]}사내 주문 원장입니다. 취소된 주문과 약속일이 아직 안 잡힌 주문을 일부러 섞었습니다.
| order_no | customer_name | created_at | promised_date | order_status | region |
|---|---|---|---|---|---|
| OD-1001 | 한빛무역 | 2026-08-09T10:00 | 2026-08-14 | closed | 동남아 |
| OD-1002 | 대성물산 | 2026-08-10T09:00 | 2026-08-15 | closed | 동남아 |
| OD-1003 | 정우상사 | 2026-08-11T11:00 | 2026-08-18 | shipped | 동남아 |
| OD-1004 | 삼진교역 | 2026-08-10T14:00 | 2026-08-16 | shipped | 동아시아 |
| OD-1005 | 미래해운 | 2026-08-12T09:00 | 2026-08-15 | cancelled | 동남아 |
아래 JSON Schema에 맞는 주문 원장 행을 더 만들어 주세요. {"type":"object","properties":{"order_no":{"type":"string"},"customer_name":{"type":"string"},"created_at":{"type":"string"},"promised_date":{"type":["string","null"]},"order_status":{"type":"string","enum":["open","shipped","closed","cancelled"]},"region":{"type":"string"}},"required":["order_no","customer_name","created_at","promised_date","order_status","region"]} customer_name과 region은 한글로 적어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 promised_date가 null인 약속일 미정 주문, 둘째 order_status가 cancelled인데 배송 이벤트가 붙을 수 있는 주문, 셋째 경계극단으로 created_at이 이벤트 시각보다 늦은 주문. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 order_status에 enum 밖 값을 넣거나 created_at을 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"order_no":{"type":"string"},"customer_name":{"type":"string"},"created_at":{"type":"string"},"promised_date":{"type":["string","null"]},"order_status":{"type":"string","enum":["open","shipped","closed","cancelled"]},"region":{"type":"string"}},"required":["order_no","customer_name","created_at","promised_date","order_status","region"]}고객사와 계약된 운송사 목록입니다. 계약이 끝난 곳과 파일 형식이 다른 곳을 함께 담았고, 목록에 없는 운송사가 파일을 보내오는 경우를 판정에서 가르기 위해 씁니다.
| carrier_id | carrier_name | contract_status | handoff_format |
|---|---|---|---|
| swiftlog | 스위프트로그 | active | csv |
| northline | 노스라인 | active | csv |
| seabridge | 씨브리지 | active | xlsx |
| krexpress | 케이알익스프레스 | active | csv |
| hanjin_line | 한진라인 | active | xlsx |
아래 JSON Schema에 맞는 carrier_master 행을 더 만들어 주세요. {"type":"object","properties":{"carrier_id":{"type":"string"},"carrier_name":{"type":"string"},"contract_status":{"type":"string"},"handoff_format":{"type":"string"}},"required":["carrier_id","carrier_name","contract_status","handoff_format"]} carrier_id는 영문 스네이크 표기이고 contract_status는 active·suspended·ended 중 하나입니다.{"type":"object","properties":{"carrier_id":{"type":"string"},"carrier_name":{"type":"string"},"contract_status":{"type":"string"},"handoff_format":{"type":"string"}},"required":["carrier_id","carrier_name","contract_status","handoff_format"]}| Python | 이벤트와 원장을 읽어 연결 판정을 돌리는 본체입니다. |
| 데이터 구조 | 두 표를 키로 맞추는 인덱스 구성이며, 건수가 커질 때 이 선택이 속도를 가릅니다. |
| 저장 시스템 | 원장과 이벤트를 쌓아 두고 날짜 구간으로 잘라 읽는 자리입니다. |
| 클라우드 인프라 | 고객사가 파일을 올려 두는 저장소 경로를 입력 위치로 받습니다. 계정 연결은 고객사 자격으로 합니다. |
| 프런트엔드 | 사유별로 나뉜 판정과 주문별 흐름을 담당자가 보는 화면입니다. |
| AI | 3주차 운송사 참조 형식 매핑에서 후보를 제시하는 보조로만 씁니다. 판정에는 쓰지 않습니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 주문 하나의 배송 흐름을 이어서 봅니다.
✓ pass → 흐름 보기까지가 한 덩어리입니다. 더 키우려면 운송사별 매핑 규칙을 분리하고 결과를 내보냅니다.
위 예측 UI 는 3주차까지 완주했을 때의 화면입니다. 1주차에 실제로 만드는 것은 아래 표시된 화면 하나입니다.
verdict사유 라벨 · event_no + 한 줄 요약(근거 수치 포함)화면·코드·면접에서 이 단어를 그대로 씁니다. 키는 출력 스키마의 enum 과 같습니다.
linked정상 연결order_not_found주문 없음order_no_missing연결 키 누락timeline_inverted시각 역전status_conflict상태 충돌carrier_unmapped운송사 미매핑duplicate_event이벤트 중복운송 이벤트 한 건이 주문에 제대로 붙는지의 판정 결과입니다. 안 붙거나 어긋나면 왜인지를 근거와 함께 담습니다.
{"type":"object","properties":{"event_no":{"type":"string"},"verdict":{"type":"string","enum":["linked","order_not_found","order_no_missing","timeline_inverted","status_conflict","carrier_unmapped","duplicate_event"]},"linked_order_no":{"type":["string","null"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"agg":{"type":["string","null"]},"value":{},"quote":{"type":["string","null"]}},"required":["field","value"]}},"next_action":{"type":"string"}},"required":["event_no","verdict","linked_order_no","evidence","next_action"]}[
{
"event_no": "EV-003",
"verdict": "linked",
"linked_order_no": "OD-1001",
"evidence": [
{
"field": "order_no",
"value": "OD-1001"
},
{
"field": "occurred_at",
"value": "2026-08-13T10:00"
},
{
"field": "created_at",
"value": "2026-08-09T10:00"
},
{
"field": "order_status",
"value": "closed"
}
],
"next_action": "주문에 붙고 시각과 상태도 맞습니다. 그대로 둡니다."
},
{
"event_no": "EV-012",
"verdict": "linked",
"linked_order_no": "OD-1006",
"evidence": [
{
"field": "order_no",
"value": "OD-1006"
},
{
"field": "occurred_at",
"value": "2026-08-16T12:00"
},
{
"field": "created_at",
"value": "2026-08-12T10:00"
},
{
"field": "order_status",
"value": "closed"
}
],
"next_action": "주문에 붙고 시각과 상태도 맞습니다. 그대로 둡니다."
},
{
"event_no": "EV-006",
"verdict": "order_not_found",
"linked_order_no": null,
"evidence": [
{
"field": "order_no",
"value": "OD-9999"
},
{
"field": "carrier_raw",
"value": "swiftlog",
"quote": "swiftlog"
}
],
"next_action": "원장에 없는 주문번호입니다. 신규 주문이 아직 안 들어왔는지 원장 담당자에게 확인합니다."
},
{
"event_no": "EV-007",
"verdict": "order_no_missing",
"linked_order_no": null,
"evidence": [
{
"field": "order_no",
"value": null
},
{
"field": "event_type",
"value": "in_transit"
}
],
"next_action": "연결 키가 비어 있습니다. 붙은 것으로 세지 않고 운송사에 참조 번호를 요청합니다."
},
{
"event_no": "EV-009",
"verdict": "timeline_inverted",
"linked_order_no": "OD-1004",
"evidence": [
{
"field": "occurred_at",
"value": "2026-08-09T10:00"
},
{
"field": "created_at",
"value": "2026-08-10T14:00"
}
],
"next_action": "주문이 생기기 전에 배송 완료가 찍혔습니다. 시각 기준이 서로 다른지 먼저 확인합니다."
},
{
"event_no": "EV-010",
"verdict": "status_conflict",
"linked_order_no": "OD-1005",
"evidence": [
{
"field": "event_type",
"value": "delivered"
},
{
"field": "order_status",
"value": "cancelled"
}
],
"next_action": "취소된 주문에 배송 완료가 붙었습니다. 취소 시점과 출고 시점을 맞춰 봅니다."
},
{
"event_no": "EV-008",
"verdict": "carrier_unmapped",
"linked_order_no": "OD-1003",
"evidence": [
{
"field": "carrier_raw",
"value": "pacific air",
"quote": "pacific"
}
],
"next_action": "사전에 없는 운송사입니다. 사전에 추가하기 전에는 운송사별 집계에서 빼 둡니다."
},
{
"event_no": "EV-006",
"verdict": "duplicate_event",
"linked_order_no": null,
"evidence": [
{
"field": "event_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 이벤트 번호가 두 번 적재됐습니다. 앞 건으로만 판정하고 뒤 건을 목록에서 뺍니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 일곱 값 안에 있는지 확인합니다. 2. event_no·verdict·linked_order_no·evidence·next_action이 모두 있는지 확인합니다. 3. event_type이 네 값 안에 있는지 확인합니다. 4. order_no가 null이면 verdict가 order_no_missing인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 carrier_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 운송사 표기은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 carrier_master의 carrier_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. 2. 같은 행 번호가 두 번 들어오면 앞 건만 남기고 뒤 건은 적재 단계에서 사유와 함께 뺍니다. [수동 검증] 1. 원장에 없는 주문번호가 신규 주문인지 오타인지 원장 담당자가 확인합니다. 2. EV-002·EV-003처럼 운송사 표기가 흔들렸지만 사전으로 맞춰진 이벤트는 미매핑 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 주문별로 이벤트를 시각 순으로 늘어놓아 흐름이 끊긴 주문이 몇 건인지 셉니다. 2. 이벤트와 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.
근거: Wrangling massive-scale data and using AI to accelerate