코리아포트원
경력근거: 결제/정산 도메인의 고객·현업 문제를 듣고
※ 실제 산출물이 아닌 AI 예측 시안입니다.
이 에이전트가 보여주는 것은 정산·매출 대조 파이프라인과 규칙 기반 불일치 탐지, Agentic 과 Deterministic Code 경계 설계 기술이며, 회계 감사나 세무 전문성을 주장하지 않습니다. 다만 이 사슬이 말이 되려면 코리아포트원 Commerce Ops 의 ‘매출 마감 자동화’ 라는 맥락, 즉 APR·달바·크레이버·티르티르 같은 K-뷰티 브랜드의 PG 정산 내역과 매출 기록을 건별로 대조해야 하는 문제가 있어야 의미가 있습니다. 연간 취급거래액 11조원, 약 3,000여 고객사 규모에서 정산 불일치를 사람이 눈으로 맞추던 일을 규칙과 에이전트 경계로 나누는 각도는 이 결제 인프라 도메인이라야 구체화됩니다. 실제 회계 마감 판단은 재무팀이 있어야 하고, 면접에서 모르는 부분은 모른다고 말하는 편이 낫습니다.
‘결제/정산 도메인의 고객·현업 문제를 듣고 이걸 AI 에이전트로 어떻게 풀 것인가를 설계 단계부터 판단’ 이 주요업무입니다. 매출 마감의 정산 대조를 에이전트로 푸는 설계·구현이 보여줄 대상입니다.
‘Agentic 접근 방식과 Deterministic Code 사이의 경계를 정의하고, Agent 구현에 적합한 시스템 디자인을 정의’ 를 요구합니다. 대조·금액 계산은 결정론 규칙이 맡고 애매한 판단만 에이전트에 넘기는 경계 설계가 핵심입니다.
‘레이턴시·정확도의 기준을 세우고 재현 가능한 실험·검증 체계를 만들어 에이전트의 품질을 끌어올린다’ 가 주요업무입니다. 판정 정확도와 응답 지연을 고정 세트로 재는 실험 체계가 필요합니다.
PG 정산 내역과 브랜드 매출 주문 기록을 받아, 주문번호로 건별 대조하고 금액·수수료·누락 불일치(금액 불일치·수수료 오차·정산 누락·매출 누락)를 규칙으로 찾아, 어떤 레코드가 근거인지 함께 묶어 매출 마감 리포트와 처리 제안을 만듭니다. 대조와 금액 계산은 결정론 규칙이 결정하고(Deterministic), 주문번호 표기가 흔들리거나 규칙으로 못 가르는 애매한 건만 에이전트(LLM)가 매핑 후보와 사유를 제안하되 단정하지 않고 사람 확인으로 넘깁니다. 더미데이터는 작성자가 만든 합성 정산·매출 레코드이고, 판정의 정답은 대조 규칙으로 결정됩니다. 1주차만으로 완성품이고, 판정 검증(2주차)·정산 규정 RAG(3주차)로 키웁니다. (근거는 채용공고 정렬입니다.)
코리아포트원 Commerce Ops 의 정산 마감 담당자입니다. APR·달바 같은 브랜드의 PG 정산 내역과 매출 기록을 스프레드시트에서 눈으로 맞추며 금액이 어긋난 건을 손으로 찾던 일을 끝내고, 규칙이 대조해 불일치를 근거와 함께 리포트로 받되 애매한 건은 단정 대신 확인 대상으로 받고 싶은 사람입니다.
정산 내역과 매출 기록을 주문번호로 규칙 대조하면, (a) 금액 불일치·수수료 오차·누락이 규칙으로 감지되고, (b) 어떤 레코드가 근거인지 함께 묶인 마감 리포트가 만들어지며, (c) 표기가 흔들리거나 규칙으로 못 가르는 건은 에이전트가 후보를 제안하되 단정하지 않고 사람 확인으로 남아, 마감 담당자가 신뢰하고 검토할 리포트를 만든다는 걸 보여줄 수 있습니다.
PG 정산 내역과 매출 주문을 주문번호로 대조해 금액·수수료·누락 불일치를 규칙으로 찾고, 근거 레코드와 함께 마감 리포트·처리 제안을 만드는 동작하는 에이전트입니다. 애매한 건은 에이전트가 후보를 제안하되 단정하지 않고 사람 확인으로 넘깁니다. PG 정산 파일은 표준 스키마로 들어온다고 가정합니다(실 PG 연동은 밖의 것).
재무 검토자 페르소나 2명이 각 불일치 판정이 맞는지, 과잉 표시(멀쩡한데 불일치로 잡음)와 놓친 불일치가 없는지 라벨링하고, 정밀도·재현율과 판정 지연(레이턴시)을 고정 세트로 대조하는 대시보드입니다.
PG별 수수료율·정산 주기 규정 문서를 RAG 로 붙여, 수수료 오차나 정산 지연이 규정 위반인지 규정 인용과 함께 판정하고, 규정에 없으면 단정하지 않고 확인 대상으로 남기는 단계입니다.
한 달치 정산·매출 레코드를 넣으면, 주문번호로 대조해 금액·누락 불일치를 판정하고 근거와 함께 마감 리포트·처리 제안을 만드는 걸 시연합니다
리포트의 근거 레코드가 전부 실재하고 금액 계산이 규칙과 일치하는지 자동 대조합니다. 근거 없는 판정은 차단되는 걸 보여줍니다
일부러 심은 불일치(금액 불일치·수수료 오차·orphan) 30종 중 규칙이 잡은 비율(재현율)과 멀쩡한데 표시한 과잉 표시(정밀도)를 보여줍니다
표기가 흔들리거나 주문번호가 빈 건은 에이전트가 단정하지 않고 확인 대상으로 넘기는 걸 보여줍니다. 내가 만든 정답 30건 중 판정·근거가 일치한 게 26건(87%)인데, 정답과 데이터를 모두 내가 만든 합성 기준이라 ‘성능 검증’ 이 아니라 ‘데모 조건 동작’ 임을 밝힙니다
위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정산 대조 정확도는 코리아포트원 실 PG 정산 데이터와 재무 검토자가 있어야 측정 가능합니다. 이 에이전트는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
이건 고객·실데이터 없이 혼자 만든 포트폴리오라, 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 ‘데모 동작 + 실검증 준비 상태’ 로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 주문번호 표기 흔들림·금액 결측·orphan 정산·경계 금액(0원 환불)을 더미에 일부러 섞어, 깔끔한 데이터만 다루는 게 아님을 보여줍니다
이 포트폴리오가 보여주는 것은 정산 대조 파이프라인과 Agentic·Deterministic 경계 설계 기술이지 회계 감사나 세무 전문성이 아닙니다. 회계 마감 판단은 재무팀이 있어야 하고, 면접에서 모르는 부분은 모른다고 말하는 편이 낫습니다
에이전트가 금액이나 매칭을 지어내면 정산 사고로 이어집니다. 매칭과 금액 계산은 규칙이 고정하고 에이전트는 표기 정규화 후보·사유·문장만 맡아, 판정 근거를 자동 대조해 지어낸 근거를 차단합니다
실제 도입 시 달라지는 것 명시합니다. 실 PG 정산 파일 포맷·수수료 규정·통화 처리는 더미와 다르므로 대조 규칙과 정규화를 다시 맞춰야 하고, 검토자도 재무 담당자로 교체해야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
PG 가 브랜드에 정산한 내역. 대조와 불일치 탐지의 한쪽 원천입니다. 주문번호 표기 흔들림(대소문자·구분자)·금액 결측·매출에 없는 orphan 정산·수수료 오차(net ≠ gross - fee)·경계 금액(0원)을 일부러 섞어, 규칙이 표기를 정규화하고 애매한 건은 확인 대상으로 넘기는지 보여줍니다.
| settle_id | order_ref_raw | pg | gross_amount | fee_amount | net_amount | currency | settled_at |
|---|---|---|---|---|---|---|---|
| S001 | ORD-1001 | nice | 120,000 | 3,600 | 116,400 | KRW | 2026-05-02T10:00:00 |
| S002 | ord_1002 | toss | 89,000 | 2,670 | 86,330 | KRW | 2026-05-02T10:00:00 |
| S003 | ORD-1003 | kcp | 250,000 | 7,500 | 240,000 | KRW | 2026-05-03T10:00:00 |
| S004 | ORD-1004 | nice | 55,000 | 1,650 | 53,350 | KRW | 2026-05-03T10:00:00 |
| S005 | — | inicis | 30,000 | 900 | 29,100 | KRW | 2026-05-04T10:00:00 |
아래 JSON Schema 에 맞는 PG 정산 내역 40행 JSON 배열로 생성합니다. PG 4종, 며칠치.
{"type":"object","properties":{"settle_id":{"type":"string"},"order_ref_raw":{"type":["string","null"]},"pg":{"type":"string","enum":["nice","toss","kcp","inicis"]},"gross_amount":{"type":["integer","null"]},"fee_amount":{"type":"integer"},"net_amount":{"type":"integer"},"currency":{"type":"string"},"settled_at":{"type":["string","null"]}},"required":["settle_id","pg","fee_amount","net_amount","currency"]}
쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) order_ref_raw 를 대소문자·구분자가 다르게 표기(ORD-1002 대 ord_1002)해 정규화가 필요한 건 2~3건, (2) order_ref_raw 나 gross_amount 가 null 인 결측 2~3건(주문번호 미기재·금액 미기입), (3) net_amount 가 gross_amount - fee_amount 와 어긋나는 수수료 오차 1~2건, (4) 매출 원장에 없는 orphan 주문번호 1~2건(missing_sales 로 잡혀야 함), (5) gross 0 원 환불 경계 1건, (6) settled_at 이 null 인 미정산 진행 건 1건. JSON 배열만.{"type":"object","properties":{"settle_id":{"type":"string"},"order_ref_raw":{"type":["string","null"]},"pg":{"type":"string","enum":["nice","toss","kcp","inicis"]},"gross_amount":{"type":["integer","null"]},"fee_amount":{"type":"integer"},"net_amount":{"type":"integer"},"currency":{"type":"string"},"settled_at":{"type":["string","null"]}},"required":["settle_id","pg","fee_amount","net_amount","currency"]}브랜드 매출 주문 기록. 대조의 다른 한쪽 원천입니다. 주문금액 결측·정산에 없는 주문(missing_settlement)·표기 흔들림·취소(0원)를 섞어, 규칙이 양쪽을 맞추고 정보 부족 시 단정하지 않는지 보여줍니다.
| order_id | order_id_raw | brand | order_amount | currency | ordered_at | status |
|---|---|---|---|---|---|---|
| ORD-1001 | ORD-1001 | APR | 120,000 | KRW | 2026-05-01T09:12:00 | paid |
| ORD-1002 | ord_1002 | 달바 | 89,000 | KRW | 2026-05-01T14:30:00 | paid |
| ORD-1003 | ORD-1003 | 크레이버 | 250,000 | KRW | 2026-05-02T11:05:00 | paid |
| ORD-1004 | ORD-1004 | 티르티르 | 50,000 | KRW | 2026-05-02T16:40:00 | paid |
| ORD-1005 | ORD-1005 | APR | 67,000 | KRW | 2026-05-03T10:20:00 | paid |
아래 JSON Schema 에 맞는 브랜드 매출 주문 40행 JSON 배열로 생성합니다. 브랜드는 APR·달바·크레이버·티르티르 등, 며칠치.
{"type":"object","properties":{"order_id":{"type":"string"},"order_id_raw":{"type":"string"},"brand":{"type":"string"},"order_amount":{"type":["integer","null"]},"currency":{"type":"string"},"ordered_at":{"type":"string"},"status":{"type":"string","enum":["paid","cancelled","refunded"]}},"required":["order_id","order_id_raw","brand","currency","ordered_at","status"]}
쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) order_id_raw 를 정규화된 order_id 와 표기가 다르게(구분자·공백) 2~3건, (2) order_amount 가 null 인 결측 2건(단정 보류 테스트), (3) 정산 원장에 없어 missing_settlement 로 잡혀야 하는 주문 2건, (4) status 가 refunded·cancelled 인 0원 경계 1~2건, (5) settlement 금액과 어긋나야 하는 amount_mismatch 짝 1건. JSON 배열만.{"type":"object","properties":{"order_id":{"type":"string"},"order_id_raw":{"type":"string"},"brand":{"type":"string"},"order_amount":{"type":["integer","null"]},"currency":{"type":"string"},"ordered_at":{"type":"string"},"status":{"type":"string","enum":["paid","cancelled","refunded"]}},"required":["order_id","order_id_raw","brand","currency","ordered_at","status"]}| Kotlin | 정산·매출 대조 엔진과 도메인 규칙을 타입 안전하게 구현하는 주력 언어(DDD Layered Architecture 반영) |
| Python | LLM 에이전트 오케스트레이션과 애매한 건 매핑 후보·사유 생성(자격요건의 Python·Agent·RAG 반영) |
| TypeScript | 마감 리포트·불일치 근거를 보여주는 콘솔 화면 |
| PostgreSQL | settlement_record / sales_order / recon_result 원장 저장소 |
| Google BigQuery | 대량 거래·정산 이력의 실험용 데이터 적재와 판정 재현 실험 |
| Kubernetes | 대조 배치와 에이전트 API 서버를 컨테이너로 운영 |
| AWS | 정산 대조 서비스 배포·운영 인프라 |
| REST API | 정산 수집·리포트 조회 엔드포인트(`POST /settlements`, `GET /recon/report`) |
| Claude Code | 대조 규칙·에이전트 프롬프트를 스킬·훅으로 빠르게 실험하는 개발 파이프라인 1급 시민 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정 검증)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(정산 규정 RAG)로 진행합니다.
정산 한 건에 대한 대조 판정. 판정 상태(status)·불일치 금액(diff)·근거 레코드(evidence)·처리 권고(recommendation)·단정 여부(is_definitive=false 유지)를 한 스키마에 담아, 규칙이 정한 매칭·금액을 에이전트가 바꾸지 않고 근거 약하면 확인 대상으로 남겼는지 객관 검증합니다.
{"type":"object","properties":{"settle_id":{"type":"string"},"matched_order_id":{"type":["string","null"]},"status":{"type":"string","enum":["matched","amount_mismatch","fee_error","missing_sales","missing_settlement","needs_review"]},"diff":{"type":["object","null"],"properties":{"expected":{"type":"integer"},"observed":{"type":"integer"},"delta":{"type":"integer"}}},"message":{"type":"string"},"evidence":{"type":"array","items":{"type":"string"}},"recommendation":{"type":"string","enum":["none","human_confirm","pg_inquiry","repost"]},"is_definitive":{"type":"boolean"}},"required":["settle_id","status","message","evidence","recommendation","is_definitive"]}[
{
"input_ref": "S001(ORD-1001, gross 120000, net 116400) ↔ ORD-1001(주문 120000) 정상 매칭",
"output": {
"settle_id": "S001",
"matched_order_id": "ORD-1001",
"status": "matched",
"diff": null,
"message": "주문 ORD-1001 과 정산이 금액·수수료 모두 일치합니다. 추가 조치가 없습니다.",
"evidence": [
"S001",
"ORD-1001"
],
"recommendation": "none",
"is_definitive": false
}
},
{
"input_ref": "S004(ORD-1004, gross 55000) ↔ ORD-1004(주문 50000) 금액 불일치",
"output": {
"settle_id": "S004",
"matched_order_id": "ORD-1004",
"status": "amount_mismatch",
"diff": {
"expected": 50000,
"observed": 55000,
"delta": 5000
},
"message": "정산 금액(55,000원)이 주문 금액(50,000원)보다 5,000원 많습니다. 부분 취소나 배송비 반영 여부를 확인 대상으로 넘깁니다.",
"evidence": [
"S004",
"ORD-1004"
],
"recommendation": "human_confirm",
"is_definitive": false
}
},
{
"input_ref": "S005(order_ref_raw null) 주문번호 결측 → 확인 대상 보류",
"output": {
"settle_id": "S005",
"matched_order_id": null,
"status": "needs_review",
"diff": null,
"message": "정산 건에 주문번호가 비어 있어 매칭할 대상을 규칙으로 특정할 수 없습니다. 에이전트가 후보를 제안하되 단정하지 않고 확인 대상으로 남깁니다.",
"evidence": [
"S005"
],
"recommendation": "human_confirm",
"is_definitive": false
}
},
{
"input_ref": "S006(ORD-9999) 매출 원장에 없는 orphan 정산",
"output": {
"settle_id": "S006",
"matched_order_id": null,
"status": "missing_sales",
"diff": null,
"message": "정산의 주문번호 ORD-9999 가 매출 원장에 없습니다. PG 정산 오류이거나 누락 주문일 수 있어 PG 문의가 필요합니다.",
"evidence": [
"S006"
],
"recommendation": "pg_inquiry",
"is_definitive": false
}
}
][자동 검증] 1. 출력이 스키마를 통과하는가(형식·필수 필드·enum). 2. matched_order_id 와 status 가 대조 규칙 결과와 일치하는가(에이전트가 매칭을 바꾸지 못함). 3. diff 의 expected/observed/delta 가 규칙 계산과 일치하는가(LLM 이 금액을 못 바꿈). 4. evidence 의 settle_id·order_id 가 원장에 실재하는가(지어낸 근거 차단). 5. is_definitive 가 항상 false 이고, 주문번호 결측·표기 흔들림 미해소면 status=needs_review 로 보류하는가. [수동 검증] 1. 재무 검토자 페르소나 2명이 판정 타당성 라벨링 → bootstrap Cohen’s κ(두 사람 답이 우연 이상으로 일치하는 정도, 0~1) 하한 ≥ 0.6. 2. 놓친 불일치·과잉 표시 5% 사람 점검.
포트폴리오가 “무엇을 만들지”라면, 시나리오 테스트는 “현장에서 어떻게 판단·소통할지” 입니다. 실제 이 채용공고 맥락의 대본을 읽고 무엇을 물어야 할지 직접 써봅니다.