Wonderful
경력근거: Use real-world data to measure performance, accuracy, and business outcomes
※ 실제 산출물이 아닌 AI 예측 시안입니다.
Wonderful은 고객사 업무 흐름을 에이전트로 옮기고 그 성과를 실제 데이터로 재는 일을 업무 문장에 함께 적어 두었습니다. 처리 건수만 세는 자동화율은 현업이 뒤에서 손보는 순간 무너지는데, 그 손봄이 기록에 남아야 숫자를 고칠 수 있습니다. 이 문제는 남의 업무를 대신 처리하는 에이전트를 붙인 자리에서만 생깁니다. 공고 업무는 고객 발굴부터 운영 안정화까지 걸쳐 있는데 1주 범위에서 고를 수 있는 것은 하나라 성과 교정 축을 골랐습니다. 이 포트폴리오는 두 기록을 이어 실제 자동화된 것만 세는 기술을 보여줍니다. 고객사 업무 도메인 자체의 전문성은 주장하지 않습니다. 어떤 처리가 업무상 옳은지는 면접에서 모른다고 말하는 편이 낫습니다.
실제 데이터로 성능과 정확도, 비즈니스 성과를 재고 운영 중에 계속 개선하는 일이 업무로 적혀 있습니다. 되돌려진 건을 빼고 세는 것이 그 측정의 첫 교정입니다.
진행 상황과 위험, 성과를 고객 현업과 기술팀, 의사결정자에게 전달하는 일이 업무입니다. 자동화율을 어떻게 셌는지가 그 보고에서 가장 먼저 나오는 질문입니다.
고객의 핵심 업무 흐름을 이해해 그것을 운영에서 도는 에이전트로 옮기는 일이 이 자리의 시작입니다. 되돌림 사유는 그 흐름의 어디가 덜 맞는지를 알려 줍니다.
에이전트가 자동으로 처리한 기록과 그 뒤 사람이 손을 댄 기록을 대조해, 되돌려지거나 고쳐진 건을 사유별로 나눠 보여주고 그것을 뺀 자동화율을 함께 내는 관리자 페이지입니다. 판정은 개입 종류와 시각 순서를 규칙과 견주는 대조로 정합니다.
고객사에 에이전트를 붙여 놓고 월간 성과 회의를 준비하는 파견 엔지니어입니다. 처리 건수만 세면 자동화율이 높게 나오는데, 현업이 그중 상당수를 나중에 손봤다고 말하면 그 자리에서 숫자를 다시 댈 근거가 없습니다.
에이전트 처리와 사람 개입이 같은 건 번호로 이어지면, 실제로 자동화된 것이 무엇인지는 사람이 표를 뒤지지 않아도 대조로 갈라집니다.
에이전트 처리 기록과 사람 개입 기록을 올리면 되돌려진 건을 사유별로 보여주고 교정된 자동화율을 함께 내는 관리자 페이지입니다. 고객사 시스템에 붙지 않고 내려받은 기록만 읽습니다.
업무 유형별로 되돌림 비율을 세어 어느 유형이 아직 자동화에 못 미치는지 보여주는 화면입니다.
개입 사유 사전을 파일로 분리해 고객사마다 다른 업무 분류를 같은 판정으로 돌리고, 교정된 지표를 보고 도구가 받아 가게 내보냅니다.
담당자가 처리 기록 60건과 개입 기록을 올려 되돌려진 건이 사유별로 나뉜 화면과 교정된 자동화율을 보는 것을 시연합니다.
결측·중복·미등록 유형이 섞인 입력 30종을 올려도 화면이 깨지지 않고, 판정하지 못한 건은 사유가 붙어 남습니다.
개입 시각이 비어 있는 건은 자동 처리로 세지 않고 시각 누락으로 따로 답니다. 확인하지 못한 것을 성공으로 만들지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 기록과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 자동화율은 Wonderful 고객사의 실제 처리 기록과 실제 개입 이력이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
업무 유형 표기가 시스템마다 흔들린 건과 개입 시각이 빈 건, 목록에 없는 유형을 처리 기록에 일부러 넣었습니다. 깨끗한 기록만 세면 자동화율은 언제나 높게 나옵니다.
사람이 손봤다고 해서 에이전트가 틀렸다고 단정할 수 없습니다. 업무 규칙이 그사이 바뀐 것일 수 있으므로, 판정은 되돌려졌다는 사실까지만 읽어야 합니다.
실제 도입하면 고객사마다 개입을 기록하는 방식이 다릅니다. 무엇을 개입으로 셀지 현업과 합의하는 일이 도입 단계의 실제 과제입니다.
에이전트를 어떻게 고칠지의 판단은 이 도구의 범위 밖입니다. 어디서 되돌려지는지까지만 보여주므로, 개선 설계는 그다음 단계입니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
에이전트가 자동으로 처리한 건 기록입니다. 업무 유형 표기가 시스템마다 대소문자로 흔들리고, 사전에 없는 신규 유형과 같은 건 번호가 두 번 들어온 건을 일부러 섞었습니다.
| case_no | task_type_raw | handled_at | agent_action | confidence |
|---|---|---|---|---|
| CS-001 | invoice_match | 2026-08-10T09:00 | approved | 0.95 |
| CS-002 | Invoice_Match | 2026-08-10T10:00 | approved | 0.62 |
| CS-003 | INVOICE_MATCH | 2026-08-10T11:00 | approved | 0.91 |
| CS-004 | ticket_routing | 2026-08-11T09:00 | routed | 0.88 |
| CS-005 | ticket_routing | 2026-08-11T10:00 | routed | 0.55 |
아래 JSON Schema에 맞는 에이전트 처리 행을 더 만들어 주세요. {"type":"object","properties":{"case_no":{"type":"string"},"task_type_raw":{"type":"string"},"handled_at":{"type":"string"},"agent_action":{"type":"string","enum":["approved","routed","replied","posted"]},"confidence":{"type":"number"}},"required":["case_no","task_type_raw","handled_at","agent_action","confidence"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 task_type_raw가 사전에 없어 task_type_id가 null인 행, 둘째 표기흔들림으로 같은 유형을 invoice_match와 Invoice_Match와 INVOICE_MATCH처럼 대소문자만 다르게 적은 행, 셋째 중복으로 같은 case_no가 두 행에 있는 재적재 건, 넷째 경계극단으로 confidence가 0.5인 낮은 건과 1.0인 확신 건. 사람이 손대지 않은 정상 처리가 전체의 절반쯤 되게 해 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 agent_action에 enum 밖 값을 넣거나 handled_at을 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"case_no":{"type":"string"},"task_type_raw":{"type":"string"},"handled_at":{"type":"string"},"agent_action":{"type":"string","enum":["approved","routed","replied","posted"]},"confidence":{"type":"number"}},"required":["case_no","task_type_raw","handled_at","agent_action","confidence"]}에이전트 처리 뒤 사람이 손을 댄 기록입니다. 개입 시각이 비어 있는 건과 처리보다 이른 시각에 찍힌 건을 일부러 섞었습니다.
| intervention_no | case_no | intervened_at | intervention_kind | reason_note | operator |
|---|---|---|---|---|---|
| IV-001 | CS-002 | 2026-08-10T14:00 | reverted | 공급사 코드가 달라 승인 취소 | 김하늘 |
| IV-002 | CS-005 | 2026-08-11T15:00 | edited | 담당 팀을 물류로 바꿈 | 박정우 |
| IV-003 | CS-007 | 2026-08-12T16:00 | edited | 문구를 규정 문장으로 교체 | 이서연 |
| IV-004 | CS-009 | 2026-08-13T11:00 | confirmed | 확인만 하고 그대로 둠 | 김하늘 |
| IV-005 | CS-013 | 2026-08-15T14:00 | reverted | 잘못된 팀으로 배정 | 박정우 |
아래 JSON Schema에 맞는 사람 개입 행을 더 만들어 주세요. {"type":"object","properties":{"intervention_no":{"type":"string"},"case_no":{"type":"string"},"intervened_at":{"type":["string","null"]},"intervention_kind":{"type":"string","enum":["reverted","edited","confirmed","escalated"]},"reason_note":{"type":["string","null"]},"operator":{"type":"string"}},"required":["intervention_no","case_no","intervened_at","intervention_kind","reason_note","operator"]} reason_note와 operator는 한글로 적어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 intervened_at이나 reason_note가 null인 행, 둘째 처리 기록에 없는 case_no를 가리키는 행, 셋째 intervened_at이 처리 시각보다 이른 행, 넷째 intervention_kind가 confirmed라 되돌림이 아닌 행. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 intervention_kind에 enum 밖 값을 넣거나 operator를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"intervention_no":{"type":"string"},"case_no":{"type":"string"},"intervened_at":{"type":["string","null"]},"intervention_kind":{"type":"string","enum":["reverted","edited","confirmed","escalated"]},"reason_note":{"type":["string","null"]},"operator":{"type":"string"}},"required":["intervention_no","case_no","intervened_at","intervention_kind","reason_note","operator"]}에이전트에 열어 준 업무 유형 목록입니다. 아직 자동화 대상이 아닌 유형을 함께 담아, 목록에 없는 유형으로 찍힌 처리 기록을 판정에서 가르는 데 씁니다.
| task_type_id | task_type_label | target_system | is_automatable |
|---|---|---|---|
| invoice_match | 청구서 대조 | ERP | true |
| ticket_routing | 문의 배정 | 헬프데스크 | true |
| customer_reply | 고객 회신 | 헬프데스크 | true |
| order_entry | 주문 입력 | ERP | true |
| refund_review | 환불 검토 | ERP | false |
아래 JSON Schema에 맞는 task_type_catalog 행을 더 만들어 주세요. {"type":"object","properties":{"task_type_id":{"type":"string"},"task_type_label":{"type":"string"},"target_system":{"type":"string"},"is_automatable":{"type":"boolean"}},"required":["task_type_id","task_type_label","target_system","is_automatable"]} task_type_id는 영문 스네이크 표기이고 task_type_label은 한국어 명사구입니다.{"type":"object","properties":{"task_type_id":{"type":"string"},"task_type_label":{"type":"string"},"target_system":{"type":"string"},"is_automatable":{"type":"boolean"}},"required":["task_type_id","task_type_label","target_system","is_automatable"]}| Python | 처리 기록과 개입 기록을 읽어 대조 판정을 돌리고 지표를 계산하는 본체입니다. |
| AI 에이전트 | 판정 대상이 되는 처리의 주체이며, 그 처리 기록이 이 화면의 입력입니다. |
| API | 고객사 업무 시스템에서 개입 기록을 받아 오는 입력 경로로 두되, 1주차에는 내려받은 파일만 읽습니다. |
| 백엔드 | 판정과 지표 계산을 화면에서 떼어 내 같은 결과를 보고 도구에도 주는 자리입니다. |
| 프런트엔드 | 사유별 되돌림과 교정된 자동화율을 담당자가 보는 화면입니다. |
| AWS | 2주차부터 판정과 화면을 AWS로 배포해 운영합니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 되돌림이 몰리는 업무 유형을 짚습니다.
✓ pass → 유형 분해까지가 한 덩어리입니다. 더 키우려면 사유 사전을 고객사별로 분리합니다.
위 예측 UI 는 3주차까지 완주했을 때의 화면입니다. 1주차에 실제로 만드는 것은 아래 표시된 화면 하나입니다.
verdict사유 라벨 · case_no + 한 줄 요약(근거 수치 포함)화면·코드·면접에서 이 단어를 그대로 씁니다. 키는 출력 스키마의 enum 과 같습니다.
automated자동 처리 유지reverted_by_human사람이 되돌림edited_by_human사람이 고침escalated사람에게 넘어감intervention_time_missing개입 시각 누락case_not_found처리 기록 없음task_type_unmapped업무 유형 미매핑duplicate_case건 번호 중복에이전트가 처리한 건 하나가 실제로 자동화로 끝났는지의 판정 결과입니다. 되돌려졌다면 어떻게 되돌려졌는지를 근거와 함께 담습니다.
{"type":"object","properties":{"case_no":{"type":"string"},"verdict":{"type":"string","enum":["automated","reverted_by_human","edited_by_human","escalated","intervention_time_missing","case_not_found","task_type_unmapped","duplicate_case"]},"agent_action":{"type":["string","null"]},"intervention_kind":{"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":["case_no","verdict","agent_action","intervention_kind","evidence","next_action"]}[
{
"case_no": "CS-001",
"verdict": "automated",
"agent_action": "approved",
"intervention_kind": null,
"evidence": [
{
"field": "handled_at",
"value": "2026-08-10T09:00"
},
{
"field": "confidence",
"value": 0.95
}
],
"next_action": "사람 손이 닿지 않았습니다. 자동화 건으로 셉니다."
},
{
"case_no": "CS-009",
"verdict": "automated",
"agent_action": "approved",
"intervention_kind": "confirmed",
"evidence": [
{
"field": "intervention_kind",
"value": "confirmed"
},
{
"field": "reason_note",
"value": "확인만 하고 그대로 둠"
}
],
"next_action": "사람이 확인만 하고 결과를 바꾸지 않았습니다. 자동화 건으로 셉니다."
},
{
"case_no": "CS-002",
"verdict": "reverted_by_human",
"agent_action": "approved",
"intervention_kind": "reverted",
"evidence": [
{
"field": "intervention_kind",
"value": "reverted"
},
{
"field": "reason_note",
"value": "공급사 코드가 달라 승인 취소",
"quote": "공급사 코드"
},
{
"field": "confidence",
"value": 0.62
}
],
"next_action": "승인이 취소됐고 확신도도 낮았습니다. 확신도 기준선을 올릴지 검토합니다."
},
{
"case_no": "CS-007",
"verdict": "edited_by_human",
"agent_action": "replied",
"intervention_kind": "edited",
"evidence": [
{
"field": "intervention_kind",
"value": "edited"
},
{
"field": "reason_note",
"value": "문구를 규정 문장으로 교체",
"quote": "규정 문장"
}
],
"next_action": "답변 문구가 고쳐졌습니다. 규정 문장을 프롬프트에 넣을지 검토합니다."
},
{
"case_no": "CS-008",
"verdict": "escalated",
"agent_action": "posted",
"intervention_kind": "escalated",
"evidence": [
{
"field": "intervention_kind",
"value": "escalated"
},
{
"field": "task_type_raw",
"value": "stock_adjust",
"quote": "stock_adjust"
}
],
"next_action": "사람에게 넘어갔습니다. 자동화로 세지 않고 유형별 비율에 넣습니다."
},
{
"case_no": "CS-008",
"verdict": "intervention_time_missing",
"agent_action": "posted",
"intervention_kind": "escalated",
"evidence": [
{
"field": "intervened_at",
"value": null
},
{
"field": "handled_at",
"value": "2026-08-13T09:00"
}
],
"next_action": "개입 시각이 비어 있어 순서를 확인하지 못했습니다. 자동화로 세지 않고 기록을 다시 받습니다."
},
{
"case_no": "CS-999",
"verdict": "case_not_found",
"agent_action": null,
"intervention_kind": "reverted",
"evidence": [
{
"field": "case_no",
"value": "CS-999"
},
{
"field": "operator",
"value": "박정우"
}
],
"next_action": "처리 기록에 없는 건입니다. 사람만 처리한 건인지 확인하고 분모에서 뺍니다."
},
{
"case_no": "CS-002",
"verdict": "duplicate_case",
"agent_action": "approved",
"intervention_kind": "reverted",
"evidence": [
{
"field": "case_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 건 번호가 두 번 적재됐습니다. 앞 건으로만 판정하고 뒤 건을 분모에서 뺍니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 여덟 값 안에 있는지 확인합니다. 2. case_no·verdict·agent_action·intervention_kind·evidence·next_action이 모두 있는지 확인합니다. 3. confidence가 0.0 이상 1.0 이하인지 확인합니다. 4. intervened_at이 null이면 verdict가 intervention_time_missing인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 reason_note 또는 task_type_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 업무 유형 표기은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 task_type_catalog의 task_type_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. 2. 같은 행 번호가 두 번 들어오면 앞 건만 남기고 뒤 건은 적재 단계에서 사유와 함께 뺍니다. [수동 검증] 1. 되돌려진 건이 에이전트 실수인지 업무 규칙 변경인지 현업 담당자가 확인합니다. 2. CS-002·CS-003처럼 유형 표기가 흔들렸지만 사전으로 맞춰진 건은 미매핑 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 업무 유형별 되돌림 비율을 세어 어느 유형이 아직 자동화에 못 미치는지 나눕니다. 2. 기록과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.
근거: Use real-world data to measure performance, accuracy, and business outcomes