데이[Day1 AI Deployment Company] Forward Deployed Engineer (FDE)
2.7 (795)데이원컴퍼니
경력근거: 사용률과 업무 성과를 측정하고 빠르게 반복 개선
35일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
데이원컴퍼니는 고객 현장에 상주해 AI 시스템을 붙이고 사용률과 업무 성과를 재서 반복 개선하는 것을 FDE 의 업무로 적었습니다. 그래서 배포 뒤 어느 팀이 겉도는지를 재는 일이 이 직무의 실제 업무 안에 있고, 배포로 계약이 끝나는 조직에서는 이 판정이 필요하지 않습니다. 다만 이 포트폴리오는 사용량 판정 규칙과 실행 결과를 보여줄 뿐, 고객사 업무 도메인의 전문성은 주장하지 않습니다.
고객사에 상주해 실제 업무 흐름과 데이터와 시스템을 파악하고 기술적 해결책을 정의하는 자리라, 산출물이 자사 코드가 아니라 고객사 현장에서 도는 것입니다.
사용률과 업무 성과를 측정하고 빠르게 반복 개선하는 것을 주요업무로 적었습니다. 배포로 끝이 아니라 쓰이는지를 재는 일이 업무에 들어 있습니다.
현장에서 검증된 패턴의 전사 자산화에 기여하는 자리라, 한 고객사에서 얻은 판정 기준이 다음 고객사로 옮겨 갈 수 있어야 합니다.
고객사에 배포한 에이전트의 호출 로그를 배포 때 합의한 목표와 견줘, 팀마다 목표에 닿았는지 겉돌고 있는지 판정해주는 CLI입니다.
고객사에 상주하는 FDE 엔지니어입니다. 다음 주 어느 팀부터 다시 붙을지 감으로 정하다가, 팀별로 실제 사용량과 수정량을 보고 정하고 싶습니다.
배포한 에이전트가 겉도는 것을 늦게 아는 이유는 사용 기록이 팀 단위로 묶여 있지 않아서입니다. 호출 로그를 팀과 작업 유형으로 묶어 합의한 목표와 견주면, 다시 붙을 팀이 먼저 좁혀집니다.
호출 로그와 배포 목표표를 넣고 명령을 한 번 실행하면 팀과 작업 유형 묶음 14건이 네 판정으로 나뉘어 터미널에 뜨고, 각 줄에 그 판정을 만든 수치가 붙는 CLI입니다. 로그는 지원자가 자기 에이전트를 며칠 돌려 만든 같은 모양의 호출 기록으로 시작합니다.
판정을 마크다운 보고서로 내보내, 다음 상주 주간에 붙을 팀 순서와 그 근거 수치를 한 장으로 정리합니다.
지난 주 판정을 함께 넣으면 판정이 바뀐 묶음만 골라 보여, 무엇이 좋아지고 무엇이 나빠졌는지 가려냅니다.
호출 로그와 목표표를 넣고 명령을 한 번 실행하면 묶음 14건이 네 판정으로 나뉘어 뜨고, 상주 엔지니어가 각 줄에서 근거 수치를 그대로 읽습니다.
수정량이 비었거나 호출 수가 목표와 정확히 같거나 팀 코드 표기가 흔들린 로그를 섞은 입력 30종을 넣어도 출력 형식이 안 깨집니다.
팀 코드 표기를 정규화한 뒤 목표표에 붙는 묶음 비율을 실행 결과에 냅니다. 단, 정답과 데이터를 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건에서의 동작입니다.
위 수치는 더미데이터 자가채점이며, 실제 배포 상태 판정의 정확도는 데이원컴퍼니가 실제로 붙인 고객사 로그와 현장 확인이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모가 도는 상태와 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 그래서 수정량 결측, 목표와 정확히 같은 경계, 팀 코드 표기 흔들림을 로그에 일부러 섞었습니다.
호출이 적다고 그 팀에서 쓸모가 없는 것은 아닙니다. 업무 자체가 주 몇 건뿐인 팀이 있으므로, 목표 수치는 현장에서 팀과 합의한 값이어야 합니다.
실제 도입에서는 고객사마다 팀 체계와 작업 유형 이름이 다르고 로그 형식도 갈립니다. 목표 축을 사용량이 아닌 것으로 바꿔야 하는 고객사가 있어, 판정 코드를 다시 잡는 일이 도입 단계 과제입니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사에 배포한 에이전트가 남긴 호출 기록입니다. 읽기 좋게 한 주 분량으로 줄였고, 수정량 결측과 팀 코드 표기 흔들림을 일부러 섞었습니다. team_code 는 도구가 team_code_raw 를 정규화해 채우는 칸이라 비워 두었습니다. 지원자가 자기 에이전트를 며칠 돌리면 같은 모양의 기록이 나옵니다.
| run_id | deployment_id | team_code_raw | task_type | invoked_at | accepted | edit_chars | output_chars |
|---|---|---|---|---|---|---|---|
| RUN-0101 | DPL-114 | ops_sales | 제안서초안 | 2026-08-31T01:12:00Z | true | 120 | 2,400 |
| RUN-0102 | DPL-114 | OPS_SALES | 제안서초안 | 2026-08-31T04:40:00Z | true | 210 | 2,600 |
| RUN-0103 | DPL-114 | ops_sales | 제안서초안 | 2026-09-01T00:20:00Z | true | 90 | 2,100 |
| RUN-0104 | DPL-114 | ops_sales | 제안서초안 | 2026-09-01T06:05:00Z | false | — | 1,900 |
| RUN-0105 | DPL-114 | ops_sales | 제안서초안 | 2026-09-02T02:30:00Z | true | 150 | 2,500 |
다음 JSON Schema 에 맞는 호출 기록 행을 더 만듭니다. {"type":"object","properties":{"run_id":{"type":"string"},"deployment_id":{"type":"string"},"team_code_raw":{"type":"string"},"team_code":{"type":["string","null"]},"task_type":{"type":"string"},"invoked_at":{"type":"string"},"accepted":{"type":"boolean"},"edit_chars":{"type":["integer","null"]},"output_chars":{"type":"integer"}},"required":["run_id","deployment_id","team_code_raw","task_type","invoked_at","accepted","output_chars"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 수정량을 기록하지 못해 edit_chars 가 null 인 행 1~2건, 한 팀의 주간 호출 수가 목표와 정확히 같아지는 경계 묶음 1건, team_code_raw 에 대문자나 앞뒤 공백이 섞여 정규화가 필요한 행 1~2건. invoked_at 은 한 주 안에 흩어 놓고 팀마다 호출 수를 다르게 둔다. 그리고 accepted 에 문자열을 넣거나 invoked_at 을 비우는 형식 깨뜨리기 시도 3건을 따로 낸다. run_id 는 행마다 다른 값으로 쓴다.{"type":"object","properties":{"run_id":{"type":"string"},"deployment_id":{"type":"string"},"team_code_raw":{"type":"string"},"team_code":{"type":["string","null"]},"task_type":{"type":"string"},"invoked_at":{"type":"string"},"accepted":{"type":"boolean"},"edit_chars":{"type":["integer","null"]},"output_chars":{"type":"integer"}},"required":["run_id","deployment_id","team_code_raw","task_type","invoked_at","accepted","output_chars"]}배포할 때 고객사 팀과 합의한 주간 목표입니다. 판정의 기준값은 전부 이 표에서 오고 호출 기록에는 들어 있지 않습니다. 로그에 한 건도 없는 팀을 찾아내는 기준 목록이기도 합니다.
| deployment_id | team_code | task_type | target_weekly_runs | max_edit_ratio | agreed_at |
|---|---|---|---|---|---|
| DPL-114 | ops_sales | 제안서초안 | 4 | 0.3 | 2026-08-24 |
| DPL-114 | ops_cs | 문의답변 | 5 | 0.25 | 2026-08-24 |
| DPL-114 | ops_quote | 견적검토 | 3 | 0.3 | 2026-08-24 |
| DPL-114 | ops_hr | 채용공고 | 3 | 0.35 | 2026-08-24 |
| DPL-114 | ops_legal | 계약검토 | 2 | 0.2 | 2026-08-24 |
다음 JSON Schema 에 맞는 배포 목표 행을 더 만듭니다. {"type":"object","properties":{"deployment_id":{"type":"string"},"team_code":{"type":"string"},"task_type":{"type":"string"},"target_weekly_runs":{"type":"integer"},"max_edit_ratio":{"type":"number"},"agreed_at":{"type":"string"}},"required":["deployment_id","team_code","task_type","target_weekly_runs","max_edit_ratio","agreed_at"]} 쉬운 데이터만 만들지 말 것. 팀마다 목표와 허용 수정 비율이 실제로 갈리게 만든다. 문안을 그대로 쓰는 작업은 허용 수정 비율을 낮추고, 초안만 받아 사람이 크게 고치는 작업은 올린다. 팀마다 task_type 이 별표인 기본 행을 하나씩 두고, 로그에 한 건도 안 나오는 팀을 최소 하나 남겨 미사용 판정이 실제로 걸리게 한다. 그리고 target_weekly_runs 에 문자열을 넣거나 team_code 를 비우는 형식 깨뜨리기 시도 3건을 따로 낸다.{"type":"object","properties":{"deployment_id":{"type":"string"},"team_code":{"type":"string"},"task_type":{"type":"string"},"target_weekly_runs":{"type":"integer"},"max_edit_ratio":{"type":"number"},"agreed_at":{"type":"string"}},"required":["deployment_id","team_code","task_type","target_weekly_runs","max_edit_ratio","agreed_at"]}| Python | 호출 로그를 주 단위로 묶고 목표와 견주는 판정 규칙을 씁니다. |
| LLM | 판정 사유를 상주 엔지니어가 읽을 한 줄로 줄여 적습니다. 판정 자체에는 개입하지 않습니다. |
| 에이전트 | 고객사에 배포한 에이전트가 남기는 호출 기록의 모양을 정하고 그 기록을 입력으로 받습니다. |
| 데이터 | 팀과 작업 유형이라는 두 축으로 로그를 묶고, 목표표와 붙일 키를 설계합니다. |
| 클라우드 | 판정 명령을 고객사 환경에서도 같은 결과가 나오게 컨테이너 하나로 묶어 실행합니다. |
| JSON Schema | 호출 로그와 목표표의 모양을 고정해, 열이 빠진 파일을 넣었을 때 판정 대신 어느 줄이 왜 걸렸는지 알려 줍니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 판정을 주간 보고서로 내보내 상주 주간 계획에 그대로 씁니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 지난 주 판정과 견줘 달라진 묶음만 골라 봅니다.
팀과 작업 유형 묶음마다 어떤 판정이 나왔고 그 판정을 만든 수치가 무엇인지 담습니다.
{"type":"object","properties":{"deployment_id":{"type":"string"},"team_code":{"type":"string"},"task_type":{"type":"string"},"week":{"type":"string"},"verdict":{"type":"string","enum":["on_target","under_target","over_edit","no_usage"]},"weekly_runs":{"type":"integer","description":"invoked_at 이 그 주에 든 호출 수입니다"},"edit_ratio":{"type":["number","null"],"description":"accepted 인 호출의 edit_chars 합을 output_chars 합으로 나눈 값입니다. 수정량이 모두 비면 null 입니다"},"reason":{"type":"string"},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"agg":{"type":"string"},"value":{}},"required":["field","value"]}}},"required":["deployment_id","team_code","task_type","week","verdict","weekly_runs","evidence"]}[
{
"deployment_id": "DPL-114",
"team_code": "ops_sales",
"task_type": "제안서초안",
"week": "2026-W36",
"verdict": "on_target",
"weekly_runs": 5,
"edit_ratio": 0.06,
"reason": "대문자와 공백이 섞인 팀 코드를 정규화해 한 묶음으로 모았고, 호출 수가 합의한 목표를 넘고 수정 비율도 허용치 안입니다.",
"evidence": [
{
"field": "invoked_at",
"agg": "count",
"value": 5
},
{
"field": "target_weekly_runs",
"value": 4
}
]
},
{
"deployment_id": "DPL-114",
"team_code": "ops_hr",
"task_type": "채용공고",
"week": "2026-W36",
"verdict": "on_target",
"weekly_runs": 3,
"edit_ratio": 0.07,
"reason": "호출 수가 합의한 목표와 정확히 같아 경계에서 도달로 봅니다. 수정량이 비어 있는 호출은 수정 비율 계산에서 뺐습니다.",
"evidence": [
{
"field": "invoked_at",
"agg": "count",
"value": 3
},
{
"field": "target_weekly_runs",
"value": 3
}
]
},
{
"deployment_id": "DPL-114",
"team_code": "ops_cs",
"task_type": "문의답변",
"week": "2026-W36",
"verdict": "under_target",
"weekly_runs": 2,
"edit_ratio": 0.07,
"reason": "호출 수가 합의한 목표에 못 미쳐 이 팀부터 다시 붙습니다.",
"evidence": [
{
"field": "invoked_at",
"agg": "count",
"value": 2
},
{
"field": "target_weekly_runs",
"value": 5
}
]
},
{
"deployment_id": "DPL-114",
"team_code": "ops_quote",
"task_type": "견적검토",
"week": "2026-W36",
"verdict": "over_edit",
"weekly_runs": 4,
"edit_ratio": 0.64,
"reason": "호출 수는 목표를 넘었지만 받은 결과를 사람이 크게 고쳐 쓰고 있어, 문안 자체를 다시 잡아야 합니다.",
"evidence": [
{
"field": "edit_chars",
"agg": "sum",
"value": 2960
},
{
"field": "max_edit_ratio",
"value": 0.3
}
]
},
{
"deployment_id": "DPL-114",
"team_code": "ops_legal",
"task_type": "계약검토",
"week": "2026-W36",
"verdict": "no_usage",
"weekly_runs": 0,
"edit_ratio": null,
"reason": "합의한 목표는 있는데 이번 주 호출이 한 건도 없어, 도입 자체가 멈춘 팀으로 봅니다.",
"evidence": [
{
"field": "invoked_at",
"agg": "count",
"value": 0
},
{
"field": "target_weekly_runs",
"value": 2
}
]
},
{
"deployment_id": "DPL-114",
"team_code": "ops_fin",
"task_type": "정산확인",
"week": "2026-W36",
"verdict": "no_usage",
"weekly_runs": 0,
"edit_ratio": null,
"reason": "정산확인 작업에 합의한 목표가 있지만 호출 기록이 없어, 다음 방문에서 도입 단계를 다시 확인합니다.",
"evidence": [
{
"field": "invoked_at",
"agg": "count",
"value": 0
},
{
"field": "target_weekly_runs",
"value": 4
}
]
}
][자동 검증 · 형식과 재계산] 1. verdict 는 on_target, under_target, over_edit, no_usage 네 값 안에 있습니다. 2. deployment_id, team_code, task_type, week, verdict, weekly_runs, evidence 일곱 필드가 모두 있습니다. 3. weekly_runs 는 0 이상이고 edit_ratio 는 0 이상 1 이하이거나 null 입니다. 4. weekly_runs 는 team_code_raw 를 소문자로 바꾸고 공백을 지워 묶은 뒤 그 주에 든 invoked_at 의 개수와 같습니다. 5. evidence 의 field 값은 agent_usage 또는 rollout_targets 에 실재하는 컬럼명입니다. 집계 항목은 agg 를 적습니다. 6. evidence 의 집계가 아닌 value 는 두 표의 수록된 행에 있는 값 그대로입니다. 7. verdict 가 under_target 이면 weekly_runs 가 target_weekly_runs 미만입니다. 8. verdict 가 over_edit 이면 edit_ratio 가 max_edit_ratio 를 초과합니다. 9. verdict 가 no_usage 이면 weekly_runs 가 0 이고 rollout_targets 에 그 묶음이 있습니다. 10. 모든 한국어 문장은 존댓말로 끝납니다. [정상으로 처리한 하드 케이스] 1. RUN-0104 는 받아들이지 않은 호출이라 수정 비율 계산에서 빠지고, 호출 수에는 그대로 셉니다. 2. RUN-0402 는 수정량이 비어 있어 수정 비율 계산에서만 빠지고 팀 판정은 도달 그대로입니다. [평가 러너 · 2주차] 1. 다음 주 실제 호출 수와 견줘 미달 판정이 실제로 늘었는지 팀별로 셉니다. 2. 수정 과다로 판정한 묶음의 문안을 고친 뒤 수정 비율이 내려갔는지 주 단위로 견줍니다.