WoForward Deployed Engineer
0.0Wonderful
경력근거: Experience working across systems, integrations, and data flows
55일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
공고가 FDE 에게 'Experience working across systems, integrations, and data flows' 를 요구하고, 할 일로 'Build AI agents that integrate with customer systems and perform real tasks' 를 적었습니다. 에이전트가 고객사 시스템 위에서 실제 일을 하려면 같은 대상이 시스템마다 다르게 적힌 값 중 무엇이 참인지가 먼저 정해져야 하고, 이 포트폴리오는 그 결정을 우선순위 표와 규칙으로 옮깁니다. 'Test with real data, measure outcomes, and iterate based on results' 도 고른 값이 맞았는지 재는 자리를 만들라는 뜻으로 받았습니다. 이 포트폴리오가 보여주는 것은 우선순위를 데이터로 두고 레코드와 맞춰 쓸 값을 가르는 기술이며, 엔터프라이즈 CRM·ERP 운영 경험이나 고객사 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
'Experience working across systems, integrations, and data flows'. 여러 시스템에 흩어진 같은 값이 이 도구의 대상입니다.
'Build AI agents that integrate with customer systems and perform real tasks'. 에이전트가 일하려면 어느 값이 참인지가 먼저 정해져야 합니다.
'Test with real data, measure outcomes, and iterate based on results'. 고른 값이 맞았는지 재는 자리까지 이 도구가 만듭니다.
시스템마다 갈린 값 중 무엇을 쓸지 가릅니다. 필드별 우선 시스템 표에 순위와 허용 경과일을 두고 시스템 레코드와 맞춰, 값이 같으면 그대로 쓰고 갈리면 순위대로 고릅니다. 우선 시스템 값이 허용 경과일을 넘겨 묵었으면 고르지 않고 남기며, 두 시스템 모두 비었으면 채울 값이 없다고 표시하고, 표에 없는 필드는 미등록으로 남겨 순위를 먼저 정하게 합니다. 레코드는 실 고객사 시스템 대신 지원자가 공개 CRM·ERP 샘플 스키마로 만든 것을 가정합니다.
고객사 여러 시스템에 에이전트를 붙이는 자리에 앉는 FDE 입니다. 같은 거래처가 시스템마다 다른 이름과 조건으로 적혀 있어, 에이전트가 어느 값을 써야 하는지를 매번 담당자에게 물어 정하던 사람입니다.
필드마다 어느 시스템이 우선이고 얼마나 묵은 값까지 쓸지를 표로 두고 레코드와 맞추면, 쓸 값과 못 고를 값이 규칙으로 갈리고 못 고른 이유가 근거로 남는다는 가정입니다. 표에 없는 필드는 미등록으로 빠지므로 순위가 아직 없는 자리가 그대로 드러납니다.
시스템 레코드와 우선 시스템 표를 받아 거래처·필드마다 쓸 값을 고르고, 못 고르면 값 묵음·값 없음·필드 미등록·표기 불일치 중 어느 쪽인지 붙여 담당 조직별로 묶은 판정 리포트를 터미널과 Markdown 파일로 내는 CLI 가 도는 완결품입니다.
공개 샘플로 만든 레코드 300건에 손으로 붙인 정답 값과 대조해 일치율을 내고, 미등록이 몰리는 필드를 모아 순위가 없는 자리를 목록으로 냅니다.
확정된 값만 모아 에이전트가 읽을 단일 레코드로 조립하고, 못 고른 건은 담당자 확인 목록으로 갈라 내는 단계입니다.
FDE 가 시스템 레코드와 우선 시스템 표를 넣으면 거래처·필드마다 쓸 값과 못 고른 사유가 담당 조직별로 묶여 나오는 과정을 시연합니다.
공개 샘플로 만든 레코드 300건과 손으로 붙인 정답 값을 대조해 일치율을 냅니다. 단, 정답과 레코드를 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
값이 비었거나 시스템 표기가 흔들리거나 표에 없는 필드가 섞인 입력 30종을 넣어도 출력 형식이 안 깨지고 사유별로 빠지는 비율을 보여줍니다.
순위와 허용 경과일을 바꿨을 때 옛 판정이 어떻게 뒤집히는지 회귀로 확인합니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 작성자가 만든 레코드의 자가채점이며, 실제 값 정합은 wonderful 고객사의 실 시스템과 실 운영 규칙이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 붙였으니 잘 맞는 게 당연하므로, 값 결측과 묵은 값, 표에 없는 필드를 일부러 섞어 쉬운 건만 푸는 함정을 피합니다.
이 포트폴리오가 보여주는 것은 우선순위를 데이터로 두고 시스템 레코드와 맞춰 쓸 값을 가르는 기술이며, 엔터프라이즈 CRM·ERP 운영 경험이나 고객사 도메인 전문성은 주장하지 않습니다. 판정은 순위와 날짜 비교가 하고 LLM 은 담당자가 읽을 사유 문장만 맡습니다.
규칙이 고른 값이 현업이 쓰는 값과 다를 수 있어서, 판정에 갈린 값을 모두 실어 담당자가 한 번 더 보게 둡니다.
실제 도입 때는 고객사마다 시스템 구성과 우선순위가 다르므로, 순위표를 새로 채우는 일을 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 여러 시스템에서 받아 온 레코드입니다. 시스템 표기 원문과 거래처 키, 필드 표기, 값, 마지막 갱신일, 담당을 한 행에 둡니다. 시스템 표기는 연동마다 손으로 적어 'salesforce'와 'Sales Force'처럼 흔들립니다. 값이 비어 있는 행, 갱신일이 비어 있는 행, 우선 시스템 표에 없는 필드를 일부러 섞어 두어 사유가 갈리게 둡니다.
| record_no | system_raw | entity_key | field_raw | value_raw | updated_at | owner_name |
|---|---|---|---|---|---|---|
| RC-1001 | salesforce | ACC-2201 | legal_name | 대한정밀 주식회사 | 2026-08-18 | 영업 |
| RC-1002 | netsuite | ACC-2201 | legal_name | 대한정밀 주식회사 | 2026-08-17 | 재무 |
| RC-1003 | Sales Force | ACC-2202 | billing_email | ap@daehan.example.com | 2026-08-19 | 영업 |
| RC-1004 | netsuite | ACC-2202 | billing_email | finance@daehan.example.com | 2026-08-20 | 재무 |
| RC-1005 | salesforce | ACC-2203 | payment_terms | NET30 | 2026-07-02 | 영업 |
아래 JSON Schema 를 그대로 만족하는 시스템 레코드 행을 300개 더 만들어 주세요. 거래처마다 시스템 두셋에 같은 필드를 두고 그중 3할은 값이 갈리게 합니다. 시스템 표기는 몇 행에서 'Sales Force'처럼 띄어 적어 흔들리게 두고, 2할은 값이나 갱신일을 비우며, 몇 행은 우선 시스템 표에 없는 필드를 씁니다. 어느 값을 쓸지나 판정 결과는 넣지 마세요.
{"type": "object", "properties": {"record_no": {"type": "string"}, "system_raw": {"type": "string"}, "entity_key": {"type": "string"}, "field_raw": {"type": "string"}, "value_raw": {"type": ["string", "null"]}, "updated_at": {"type": ["string", "null"]}, "owner_name": {"type": ["string", "null"]}}, "required": ["record_no", "system_raw", "entity_key", "field_raw", "value_raw"]}{"type": "object", "properties": {"record_no": {"type": "string"}, "system_raw": {"type": "string"}, "entity_key": {"type": "string"}, "field_raw": {"type": "string"}, "value_raw": {"type": ["string", "null"]}, "updated_at": {"type": ["string", "null"]}, "owner_name": {"type": ["string", "null"]}}, "required": ["record_no", "system_raw", "entity_key", "field_raw", "value_raw"]}필드별 우선 시스템 표입니다. 필드 표기와 시스템 표기, 순위, 허용 경과일, 담당을 한 행에 둡니다. 같은 필드에 시스템이 순위별로 여러 행 붙어 있어 값이 갈렸을 때 어느 쪽을 쓸지가 정해집니다. 레코드에 나오는 필드 중 일부는 일부러 넣지 않아 미등록이 도출되게 둡니다.
| rule_no | field_raw | system_raw | rank | allow_stale_days | owner_name |
|---|---|---|---|---|---|
| SP-1001 | legal_name | netsuite | 1 | 30 | 재무 |
| SP-1002 | legal_name | salesforce | 2 | 30 | 영업 |
| SP-1003 | billing_email | netsuite | 1 | 14 | 재무 |
| SP-1004 | billing_email | salesforce | 2 | 14 | 영업 |
| SP-1005 | payment_terms | netsuite | 1 | 14 | 재무 |
아래 JSON Schema 를 그대로 만족하는 우선 시스템 행을 40개 더 만들어 주세요. 필드마다 시스템을 둘씩 붙여 1·2순위를 두고 허용 경과일을 필드 성격에 맞게 다르게 씁니다. 레코드에 나오는 필드 중 일부는 일부러 넣지 마세요 — 미등록이 있어야 표의 구멍이 드러납니다. 판정 결과는 넣지 마세요.
{"type": "object", "properties": {"rule_no": {"type": "string"}, "field_raw": {"type": "string"}, "system_raw": {"type": "string"}, "rank": {"type": "integer"}, "allow_stale_days": {"type": "integer"}, "owner_name": {"type": "string"}}, "required": ["rule_no", "field_raw", "system_raw", "rank", "allow_stale_days"]}{"type": "object", "properties": {"rule_no": {"type": "string"}, "field_raw": {"type": "string"}, "system_raw": {"type": "string"}, "rank": {"type": "integer"}, "allow_stale_days": {"type": "integer"}, "owner_name": {"type": "string"}}, "required": ["rule_no", "field_raw", "system_raw", "rank", "allow_stale_days"]}| Python | 레코드와 우선 시스템 표를 맞춰 값을 고르고 경과일을 계산하는 판정기를 맡습니다. |
| REST | 고객사 시스템에서 레코드를 받아 오는 연동 경로로 가정합니다. 판정 자체는 연동에 기대지 않습니다. |
| Markdown | 담당 조직별로 묶은 판정 리포트와 확인 목록을 파일로 냅니다. |
✗ fail → 미등록이 절반을 넘으면 표를 먼저 채웁니다.
✓ pass → 2주차 정답 대조로 넘어갑니다.
✗ fail → 어긋난 유형을 모아 순위와 허용 경과일을 다시 봅니다.
✓ pass → 3주차 단일 레코드 조립으로 넘어갑니다.
거래처와 필드가 만나는 자리마다 어느 시스템 값을 쓸지 정합니다. 못 고르면 값 묵음·값 없음·필드 미등록·표기 불일치 중 어느 쪽인지 싣습니다. 화면과 리포트는 이 사유 코드로 묶습니다.
{"type": "object", "properties": {"verdict_no": {"type": "string"}, "entity_key": {"type": "string"}, "field_raw": {"type": "string"}, "rule_no": {"type": ["string", "null"]}, "chosen_system_raw": {"type": ["string", "null"]}, "chosen_value_raw": {"type": ["string", "null"]}, "reconcile_code": {"type": "string", "enum": ["agreed", "conflict_resolved", "conflict_unresolved", "stale_primary", "value_missing", "field_unmapped"]}, "distinct_values": {"type": ["integer", "null"]}, "stale_days": {"type": ["integer", "null"]}, "owner_name": {"type": ["string", "null"]}, "evidence": {"type": "array", "items": {"type": "object", "properties": {"field": {"type": "string"}, "agg": {"type": ["string", "null"]}, "value": {}}, "required": ["field", "value"]}}, "summary": {"type": "string"}, "hedge": {"type": ["string", "null"]}}, "required": ["verdict_no", "entity_key", "field_raw", "reconcile_code", "evidence", "summary"]}[
{
"verdict_no": "RV-001",
"entity_key": "ACC-2201",
"field_raw": "legal_name",
"rule_no": "SP-1001",
"chosen_system_raw": "netsuite",
"chosen_value_raw": "대한정밀 주식회사",
"reconcile_code": "agreed",
"distinct_values": 1,
"stale_days": 1,
"owner_name": "재무",
"evidence": [
{
"field": "value_raw",
"agg": null,
"value": "대한정밀 주식회사"
},
{
"field": "system_raw",
"agg": "count",
"value": 2
}
],
"summary": "두 시스템의 값이 같아 다툴 것이 없고 우선 시스템 값을 그대로 씁니다.",
"hedge": null
},
{
"verdict_no": "RV-002",
"entity_key": "ACC-2206",
"field_raw": "ship_to_city",
"rule_no": "SP-1009",
"chosen_system_raw": "salesforce",
"chosen_value_raw": "창원",
"reconcile_code": "conflict_resolved",
"distinct_values": 2,
"stale_days": 0,
"owner_name": "영업",
"evidence": [
{
"field": "value_raw",
"agg": null,
"value": "창원"
},
{
"field": "rank",
"agg": null,
"value": 1
}
],
"summary": "'창원'과 '창원시'로 갈렸으나 이 필드의 1순위가 salesforce 라 그 값을 씁니다.",
"hedge": "표기 차이로 보이지만 규칙은 값이 다르면 갈린 것으로 셉니다."
},
{
"verdict_no": "RV-003",
"entity_key": "ACC-2202",
"field_raw": "billing_email",
"rule_no": "SP-1003",
"chosen_system_raw": "netsuite",
"chosen_value_raw": "finance@daehan.example.com",
"reconcile_code": "conflict_resolved",
"distinct_values": 2,
"stale_days": 0,
"owner_name": "재무",
"evidence": [
{
"field": "value_raw",
"agg": null,
"value": "finance@daehan.example.com"
},
{
"field": "updated_at",
"agg": null,
"value": "2026-08-20"
}
],
"summary": "청구 메일이 둘로 갈렸고 1순위인 netsuite 값이 기한 안이라 그 값을 씁니다.",
"hedge": null
},
{
"verdict_no": "RV-004",
"entity_key": "ACC-2203",
"field_raw": "payment_terms",
"rule_no": "SP-1005",
"chosen_system_raw": null,
"chosen_value_raw": null,
"reconcile_code": "stale_primary",
"distinct_values": 2,
"stale_days": 48,
"owner_name": "재무",
"evidence": [
{
"field": "updated_at",
"agg": null,
"value": "2026-07-02"
},
{
"field": "allow_stale_days",
"agg": null,
"value": 14
}
],
"summary": "결제 조건이 갈렸는데 2순위 값이 48일째 묵어 허용 14일을 넘겨 고르지 않습니다.",
"hedge": null
},
{
"verdict_no": "RV-005",
"entity_key": "ACC-2205",
"field_raw": "support_tier",
"rule_no": null,
"chosen_system_raw": null,
"chosen_value_raw": null,
"reconcile_code": "field_unmapped",
"distinct_values": 2,
"stale_days": null,
"owner_name": null,
"evidence": [
{
"field": "field_raw",
"agg": null,
"value": "support_tier"
},
{
"field": "rule_no",
"agg": "count",
"value": 12
}
],
"summary": "우선 시스템 표 열두 행에 이 필드가 없어 어느 값을 쓸지 정하지 못합니다.",
"hedge": null
},
{
"verdict_no": "RV-006",
"entity_key": "ACC-2204",
"field_raw": "tax_id",
"rule_no": "SP-1007",
"chosen_system_raw": null,
"chosen_value_raw": null,
"reconcile_code": "value_missing",
"distinct_values": 0,
"stale_days": null,
"owner_name": "재무",
"evidence": [
{
"field": "value_raw",
"agg": null,
"value": null
},
{
"field": "updated_at",
"agg": null,
"value": null
}
],
"summary": "두 시스템 모두 사업자번호가 비어 있어 채울 값 자체가 없습니다.",
"hedge": null
},
{
"verdict_no": "RV-007",
"entity_key": "ACC-2202",
"field_raw": "legal_name",
"rule_no": "SP-1001",
"chosen_system_raw": null,
"chosen_value_raw": null,
"reconcile_code": "conflict_unresolved",
"distinct_values": 2,
"stale_days": 0,
"owner_name": "재무",
"evidence": [
{
"field": "system_raw",
"agg": null,
"value": "Sales Force"
},
{
"field": "rank",
"agg": "count",
"value": 2
}
],
"summary": "시스템 표기가 'Sales Force'로 달리 적혀 1순위와 2순위 중 어느 쪽인지 규칙만으로 못 가릅니다.",
"hedge": "표기를 접으면 salesforce 지만 접기 규칙을 사람이 승인해야 자동 반영합니다."
}
][자동 검증 · 코드가 판정합니다] 1. reconcile_code 가 enum 여섯 값 중 하나인지 확인합니다. 2. verdict_no·entity_key·field_raw·reconcile_code·evidence·summary 가 모두 채워졌는지 확인합니다. 3. entity_key·field_raw 쌍이 레코드에 실재하는지 대조합니다. 4. rule_no 가 있으면 우선 시스템 표에 실재하는 행 번호인지 대조합니다. 5. rule_no 가 있으면 owner_name 이 그 규칙 행의 값과 같은지 대조합니다. 6. distinct_values 를 그 거래처·필드의 값 가짓수로 다시 셉니다. 7. reconcile_code 가 agreed 이면 distinct_values 가 1인지 확인합니다. 8. reconcile_code 가 conflict_resolved 이면 chosen_system_raw 가 그 필드의 rank 가 가장 작은 시스템인지 다시 확인합니다. 9. stale_days 를 마지막 갱신일에서 오늘까지의 일수로 다시 계산합니다. 10. reconcile_code 가 stale_primary 이면 stale_days 가 allow_stale_days 를 넘는지 다시 확인합니다. 11. reconcile_code 가 value_missing 이면 그 거래처·필드의 값이 모두 비었는지 확인합니다. 12. system_raw 를 공백을 지우고 대소문자를 접은 뒤 우선 시스템 표의 시스템과 맞는지 확인합니다. 13. field_raw 가 우선 시스템 표에 없으면 reconcile_code 가 field_unmapped 인지 확인합니다. 14. evidence 의 field 이름이 레코드와 우선 시스템 표에 실재하는 컬럼인지 대조합니다. 15. agg 가 없는 evidence 의 value 가 그 컬럼에 수록된 행 값과 같은지 확인합니다. 16. summary 가 존댓말로 끝나는지 확인합니다. [평가 러너 · 2주차] 공개 샘플로 만든 레코드 300건에 손으로 붙인 정답 값과 대조해 일치율과 사유 코드별 분포를 내고, 미등록이 몰리는 필드를 모아 순위가 없는 자리를 목록으로 냅니다. [수동 검증 · 사람이 봅니다] 1. 시스템 표기를 접는 규칙을 자동 반영할지 담당자가 승인합니다. 2. 값이 갈렸는데 순위로 고른 결과를 그대로 쓸지 담당 조직이 확인합니다.
근거: Experience working across systems, integrations, and data flows