디피AI Engineer (FDE)
4.6 (7)디피니트
경력근거: 고객의 업무와 데이터를 이해하고, 그 암묵지를 AI가 이해할 수 있는 구조로 만드는 역할입니다
65일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
공고가 FDE 를 '고객의 업무와 데이터를 이해하고, 그 암묵지를 AI가 이해할 수 있는 구조로 만드는 역할입니다' 로 정의하고, 회사가 마주한 문제로 어떤 회사에서는 매출이 반품을 뺀 금액이고 어떤 회사에서는 특정 사업부만 뜻한다는 예를 들었습니다. 그 갈림을 표로 세워 질문과 맞추는 것이 이 포트폴리오이고, 입사 후 과제로 적힌 '업무 규칙을 Ontology로 구조화' 와 'Text-to-SQL이 올바른 의미를 이해하도록 AI 로직 설계' 가 같은 자리를 가리킵니다. '실제 데이터로 검증하고 반복 개선' 도 정의가 창고 컬럼 위에서 성립하는지 보는 설계로 받았습니다. 이 포트폴리오가 보여주는 것은 업무 용어를 데이터로 두고 질문과 맞춰 풀림 여부를 가르는 기술이며, 제조·유통·공공 도메인 전문성이나 대규모 Text-to-SQL 운영 경험은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
'고객의 업무와 데이터를 이해하고, 그 암묵지를 AI가 이해할 수 있는 구조로 만드는 역할입니다'. 그 구조가 용어 정의표입니다.
'Text-to-SQL이 올바른 의미를 이해하도록 AI 로직 설계'. 쿼리를 짜기 전에 용어가 무엇을 가리키는지가 먼저 정해져야 합니다.
'실제 데이터로 검증하고 반복 개선'. 정의가 창고 컬럼 위에서 성립하는지까지 봐야 검증이 닫힙니다.
질문 속 용어가 정의대로 풀리는지 가릅니다. 고객사 용어 정의표와 데이터 창고 컬럼 목록을 두고 현업 질문과 맞춰, 정의가 하나로 정해지면 어느 컬럼으로 푸는지 내고 그렇지 않으면 정의 없음·정의 충돌·컬럼 없음·범위 미지정 중 어느 쪽인지 사유로 남깁니다. 정의된 용어가 문장에 없으면 질의로 보지 않고 뺍니다. 질문과 정의표는 실 고객사 자료 대신 지원자가 공개 ERP 샘플 스키마 위에 만든 것을 가정합니다.
고객사에 들어가 현업 질문을 AI 가 풀 수 있는 형태로 옮기는 자리에 앉는 FDE 입니다. 답이 틀렸다는 말을 들으면 모델이 틀렸는지 용어 정의가 갈렸는지를 매번 담당자를 붙잡고 되짚던 사람입니다.
용어마다 어느 컬럼을 쓰고 무엇을 포함·제외하며 어느 범위에 적용하는지를 표로 두고 질문과 맞추면, 풀리는 질문과 못 푸는 질문이 규칙으로 갈리고 못 푸는 이유가 근거로 남는다는 가정입니다. 정의가 둘 이상인 용어는 충돌로 빠지므로 회사 안에서 말이 갈리는 지점이 그대로 드러납니다.
현업 질문과 용어 정의표, 창고 컬럼 목록을 받아 질문마다 풀림·못 풀림을 판정하고, 못 풀면 정의 없음·정의 충돌·컬럼 없음·범위 미지정 중 어느 쪽인지 붙여 담당 조직별로 묶은 판정 리포트를 터미널과 Markdown 파일로 내는 CLI 가 도는 완결품입니다.
손으로 만든 현업 질문 120건에 정답 판정을 붙여 대조해 일치율을 내고, 정의 충돌이 몰리는 용어를 모아 회사 안에서 말이 갈리는 지점을 목록으로 냅니다.
정의가 하나로 정해진 질문에 대해 포함·제외 조건을 반영한 조회식 초안을 조립하고, 충돌한 용어는 담당자에게 보낼 확인 질문으로 갈라 내는 단계입니다.
FDE 가 현업 질문과 용어 정의표, 창고 컬럼 목록을 넣으면 질문마다 풀림 여부와 못 푼 사유가 담당 조직별로 묶여 나오는 과정을 시연합니다.
손으로 만든 현업 질문 120건과 정답 판정을 대조해 일치율을 냅니다. 단, 정답과 질문을 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
용어 표기가 흔들리거나 범위가 비었거나 정의표에 없는 용어가 섞인 입력 30종을 넣어도 출력 형식이 안 깨지고 사유별로 빠지는 비율을 보여줍니다.
정의표를 고쳤을 때 옛 판정이 어떻게 뒤집히는지 회귀로 확인합니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 작성자가 만든 질문의 자가채점이며, 실제 의미 정합은 디피니트 고객사의 실 업무 용어와 실 데이터 창고가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 붙였으니 잘 맞는 게 당연하므로, 정의 충돌과 범위 결측, 창고에 없는 컬럼을 일부러 섞어 쉬운 질문만 푸는 함정을 피합니다.
이 포트폴리오가 보여주는 것은 업무 용어를 데이터로 두고 질문과 맞춰 풀림 여부를 가르는 기술이며, 제조·유통·공공 도메인 전문성이나 대규모 Text-to-SQL 운영 경험은 주장하지 않습니다. 판정은 정의 대조가 하고 LLM 은 담당자가 읽을 사유 문장만 맡습니다.
정의가 하나로 정해졌다고 그 답이 현업의 뜻과 같다는 보장은 없어서, 판정에 포함·제외 조건을 함께 실어 담당자가 한 번 더 읽게 둡니다.
실제 도입 때는 고객사마다 용어와 조직 범위가 다르므로, 정의표를 새로 채우는 일을 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
현업이 사내 AI 에 던진 질문 원문입니다. 질문 번호와 본문, 물은 사람의 조직, 질문에 드러난 적용 범위, 물은 날짜를 한 행에 둡니다. 범위가 비어 있는 질문, 정의된 용어가 하나도 없는 인사말, 용어를 '매 출' 처럼 띄어 적은 질문을 일부러 섞어 두어 사유가 갈리게 둡니다.
| question_no | raw_text | asked_by | unit_name | asked_at |
|---|---|---|---|---|
| Q-1001 | 지난달 매출이 얼마인가요? | 영업기획 | 영업본부 | 2026-08-03 |
| Q-1002 | 이번 분기 영업이익이 왜 줄었나요? | 경영관리 | 전사 | 2026-08-04 |
| Q-1003 | 작년 대비 반품률이 늘었나요? | 품질관리 | 제조1본부 | 2026-08-05 |
| Q-1004 | 가동률이 가장 낮은 라인이 어디인가요? | 생산관리 | 제조1본부 | 2026-08-06 |
| Q-1005 | 매출이 목표에 얼마나 못 미치나요? | 경영관리 | — | 2026-08-07 |
아래 JSON Schema 를 그대로 만족하는 현업 질문 행을 120개 더 만들어 주세요. 정의표의 용어를 고루 섞되 2할은 범위를 비우고, 몇 줄은 용어를 '매 출' 처럼 띄어 적으며, 몇 줄은 정의된 용어가 하나도 없는 인사말로 둡니다. 풀림 여부나 사유는 넣지 마세요.
{"type": "object", "properties": {"question_no": {"type": "string"}, "raw_text": {"type": "string"}, "asked_by": {"type": "string"}, "unit_name": {"type": ["string", "null"]}, "asked_at": {"type": "string"}}, "required": ["question_no", "raw_text", "asked_by", "asked_at"]}{"type": "object", "properties": {"question_no": {"type": "string"}, "raw_text": {"type": "string"}, "asked_by": {"type": "string"}, "unit_name": {"type": ["string", "null"]}, "asked_at": {"type": "string"}}, "required": ["question_no", "raw_text", "asked_by", "asked_at"]}고객사 용어 정의표입니다. 용어 표기와 적용 컬럼, 포함·제외 조건, 적용 범위, 담당을 한 행에 둡니다. 같은 용어에 조직마다 다른 정의가 붙어 있어 충돌이 도출됩니다. 컬럼 표기는 담당자가 손으로 적어 'op_margin_rate'를 'op margin rate'처럼 밑줄 없이 적은 행이 섞여 있습니다. 조건이 비어 있는 행과 창고에 없는 컬럼을 가리키는 행도 일부러 넣어 둡니다.
| rule_no | term_raw | column_raw | include_note | exclude_note | scope_unit | owner_name |
|---|---|---|---|---|---|---|
| TR-1001 | 매출 | net_sales_amt | 확정 출고분만 셉니다. | 반품과 취소분은 뺍니다. | 영업본부 | 경영관리 |
| TR-1002 | 매출 | gross_sales_amt | 수주 기준 총액을 셉니다. | — | 전사 | 영업기획 |
| TR-1003 | 영업이익 | op_profit_amt | 판관비를 뺀 뒤 금액입니다. | 일회성 손익은 뺍니다. | 전사 | 경영관리 |
| TR-1004 | 반품률 | return_rate | 고객 반품 건만 셉니다. | 사내 이관은 뺍니다. | 제조1본부 | 품질관리 |
| TR-1005 | 가동률 | line_uptime_rate | 계획 정지는 분모에서 뺍니다. | — | 제조1본부 | 생산관리 |
아래 JSON Schema 를 그대로 만족하는 용어 정의 행을 40개 더 만들어 주세요. 몇몇 용어에는 조직이 다른 정의를 둘씩 붙여 충돌이 생기게 하고, 2할은 포함·제외 조건이나 적용 범위를 비웁니다. 컬럼 표기는 몇 행에서 밑줄 대신 띄어쓰기로 적어 표기가 흔들리게 두고, 몇 행은 창고 컬럼 목록에 없는 컬럼을 가리키게 두세요 — 컬럼 없음이 있어야 정의표의 구멍이 드러납니다. 판정 결과는 넣지 마세요.
{"type": "object", "properties": {"rule_no": {"type": "string"}, "term_raw": {"type": "string"}, "column_raw": {"type": "string"}, "include_note": {"type": ["string", "null"]}, "exclude_note": {"type": ["string", "null"]}, "scope_unit": {"type": ["string", "null"]}, "owner_name": {"type": "string"}}, "required": ["rule_no", "term_raw", "column_raw", "owner_name"]}{"type": "object", "properties": {"rule_no": {"type": "string"}, "term_raw": {"type": "string"}, "column_raw": {"type": "string"}, "include_note": {"type": ["string", "null"]}, "exclude_note": {"type": ["string", "null"]}, "scope_unit": {"type": ["string", "null"]}, "owner_name": {"type": "string"}}, "required": ["rule_no", "term_raw", "column_raw", "owner_name"]}데이터 창고에 실재하는 컬럼 목록입니다. 컬럼 번호와 표기, 테이블, 자료형을 한 행에 둡니다. 정의표가 가리키는 컬럼 중 일부는 일부러 넣지 않아 컬럼 없음이 도출되게 둡니다.
| column_no | column_raw | table_name | data_type |
|---|---|---|---|
| CL-1001 | net_sales_amt | fact_sales | decimal |
| CL-1002 | gross_sales_amt | fact_sales | decimal |
| CL-1003 | op_profit_amt | fact_pl | decimal |
| CL-1004 | return_rate | fact_quality | decimal |
| CL-1005 | line_uptime_rate | fact_line | decimal |
아래 JSON Schema 를 그대로 만족하는 창고 컬럼 행을 40개 더 만들어 주세요. 테이블을 서넛으로 나누고 자료형을 고루 씁니다. 정의표가 가리키는 컬럼 중 일부는 일부러 넣지 마세요 — 컬럼 없음이 있어야 정의표의 구멍이 드러납니다.
{"type": "object", "properties": {"column_no": {"type": "string"}, "column_raw": {"type": "string"}, "table_name": {"type": "string"}, "data_type": {"type": "string"}}, "required": ["column_no", "column_raw", "table_name", "data_type"]}{"type": "object", "properties": {"column_no": {"type": "string"}, "column_raw": {"type": "string"}, "table_name": {"type": "string"}, "data_type": {"type": "string"}}, "required": ["column_no", "column_raw", "table_name", "data_type"]}| Python | 질문에서 용어를 뽑아 정의표와 맞추고 충돌과 결측을 가르는 판정기를 맡습니다. |
| Ontology | 용어와 컬럼, 적용 범위를 잇는 정의표의 구조로 씁니다. 판정 자체는 규칙이 합니다. |
| Markdown | 담당 조직별로 묶은 판정 리포트와 확인 질문 목록을 파일로 냅니다. |
✗ fail → 정의 없음이 절반을 넘으면 정의표를 먼저 채웁니다.
✓ pass → 2주차 정답 대조로 넘어갑니다.
✗ fail → 어긋난 유형을 모아 포함·제외 조건 정의를 다시 봅니다.
✓ pass → 3주차 조회식 초안으로 넘어갑니다.
질문 하나와 용어 정의가 만나는 자리마다 정의대로 풀리는지 정합니다. 못 풀면 정의 없음·정의 충돌·컬럼 없음·범위 미지정 중 어느 쪽인지 싣고, 정의된 용어가 문장에 없으면 질의로 보지 않고 뺍니다. 화면과 리포트는 이 사유 코드로 묶습니다.
{"type": "object", "properties": {"verdict_no": {"type": "string"}, "question_no": {"type": "string"}, "term_raw": {"type": ["string", "null"]}, "rule_no": {"type": ["string", "null"]}, "column_raw": {"type": ["string", "null"]}, "bind_code": {"type": "string", "enum": ["bound", "term_undefined", "term_conflicting", "column_unmapped", "scope_missing", "no_term_found"]}, "rule_count": {"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", "question_no", "bind_code", "evidence", "summary"]}[
{
"verdict_no": "BV-001",
"question_no": "Q-1003",
"term_raw": "반품률",
"rule_no": "TR-1004",
"column_raw": "return_rate",
"bind_code": "bound",
"rule_count": 1,
"owner_name": "품질관리",
"evidence": [
{
"field": "term_raw",
"agg": null,
"value": "반품률"
},
{
"field": "column_raw",
"agg": null,
"value": "return_rate"
},
{
"field": "scope_unit",
"agg": null,
"value": "제조1본부"
}
],
"summary": "반품률 정의가 하나뿐이고 물은 본부와 적용 범위가 같아 return_rate 로 풉니다.",
"hedge": null
},
{
"verdict_no": "BV-002",
"question_no": "Q-1007",
"term_raw": "납기 준수율",
"rule_no": "TR-1007",
"column_raw": "otd_rate",
"bind_code": "bound",
"rule_count": 1,
"owner_name": "생산관리",
"evidence": [
{
"field": "term_raw",
"agg": null,
"value": "납기 준수율"
},
{
"field": "include_note",
"agg": null,
"value": "약속납기 당일까지를 준수로 봅니다."
}
],
"summary": "약속납기 당일까지를 준수로 보는 정의가 하나라 otd_rate 로 풉니다.",
"hedge": null
},
{
"verdict_no": "BV-003",
"question_no": "Q-1001",
"term_raw": "매출",
"rule_no": null,
"column_raw": null,
"bind_code": "term_conflicting",
"rule_count": 2,
"owner_name": null,
"evidence": [
{
"field": "term_raw",
"agg": null,
"value": "매출"
},
{
"field": "rule_no",
"agg": "count",
"value": 2
}
],
"summary": "매출 정의가 둘입니다. 반품을 뺀 확정 출고분과 수주 총액 중 어느 쪽인지 물어야 합니다.",
"hedge": "물은 사람이 영업본부라 확정 출고분 쪽이 유력하나 규칙만으로는 못 고릅니다."
},
{
"verdict_no": "BV-004",
"question_no": "Q-1010",
"term_raw": "업계 평균",
"rule_no": "TR-1012",
"column_raw": "peer_avg_margin",
"bind_code": "column_unmapped",
"rule_count": 1,
"owner_name": "경영관리",
"evidence": [
{
"field": "column_raw",
"agg": null,
"value": "peer_avg_margin"
},
{
"field": "column_no",
"agg": "count",
"value": 12
}
],
"summary": "정의가 가리키는 peer_avg_margin 이 창고 열두 컬럼에 없어 답을 만들 수 없습니다.",
"hedge": null
},
{
"verdict_no": "BV-005",
"question_no": "Q-1005",
"term_raw": "목표",
"rule_no": "TR-1011",
"column_raw": "sales_target_amt",
"bind_code": "scope_missing",
"rule_count": 1,
"owner_name": "영업기획",
"evidence": [
{
"field": "unit_name",
"agg": null,
"value": null
},
{
"field": "scope_unit",
"agg": null,
"value": "영업본부"
}
],
"summary": "정의가 영업본부 범위인데 질문에 본부가 없어 어느 범위인지 정하지 못합니다.",
"hedge": null
},
{
"verdict_no": "BV-008",
"question_no": "Q-1010",
"term_raw": "영업이익률",
"rule_no": "TR-1009",
"column_raw": "op margin rate",
"bind_code": "bound",
"rule_count": 1,
"owner_name": "경영관리",
"evidence": [
{
"field": "column_raw",
"agg": null,
"value": "op margin rate"
},
{
"field": "term_raw",
"agg": null,
"value": "영업이익률"
}
],
"summary": "정의표에 밑줄이 빠진 채 적혀 있으나 표기를 접으면 창고의 op_margin_rate 와 같아 그대로 풉니다.",
"hedge": null
},
{
"verdict_no": "BV-006",
"question_no": "Q-1006",
"term_raw": "재고자산 회전율",
"rule_no": "TR-1006",
"column_raw": "inv_turnover_ratio",
"bind_code": "bound",
"rule_count": 1,
"owner_name": "구매",
"evidence": [
{
"field": "term_raw",
"agg": null,
"value": "재고자산 회전율"
},
{
"field": "column_raw",
"agg": null,
"value": "inv_turnover_ratio"
}
],
"summary": "월평균 재고로 나누는 정의가 하나라 inv_turnover_ratio 로 풉니다.",
"hedge": null
},
{
"verdict_no": "BV-007",
"question_no": "Q-1009",
"term_raw": null,
"rule_no": null,
"column_raw": null,
"bind_code": "no_term_found",
"rule_count": null,
"owner_name": null,
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "수고하셨습니다."
},
{
"field": "term_raw",
"agg": "count",
"value": 12
}
],
"summary": "정의된 용어 열두 개 중 어느 것도 문장에 없어 질의로 보지 않습니다.",
"hedge": null
}
][자동 검증 · 코드가 판정합니다] 1. bind_code 가 enum 여섯 값 중 하나인지 확인합니다. 2. verdict_no·question_no·bind_code·evidence·summary 가 모두 채워졌는지 확인합니다. 3. question_no 가 질문 원문에 실재하는 번호인지 대조합니다. 4. rule_no 가 있으면 정의표에 실재하는 행 번호인지 대조합니다. 5. rule_no 가 있으면 column_raw·owner_name 이 그 정의 행의 값과 같은지 대조합니다. 6. term_raw 를 공백을 지워 접은 뒤 질문 본문에서 다시 찾아지는지 확인합니다. 7. bind_code 가 term_conflicting 이면 그 용어의 정의 행이 둘 이상인지 다시 셉니다. 8. bind_code 가 bound 이면 그 용어의 정의 행이 정확히 하나인지 다시 셉니다. 8-1. column_raw 를 공백·밑줄을 지워 접은 뒤 창고 컬럼과 맞는지 확인합니다. 9. bind_code 가 column_unmapped 이면 그 정의의 column_raw 가 창고 컬럼 목록에 없는지 대조합니다. 10. bind_code 가 scope_missing 이면 정의에 적용 범위가 있고 질문에는 없는지 확인합니다. 11. bind_code 가 no_term_found 이면 정의표의 어느 용어도 질문 본문에 없는지 전부 다시 훑습니다. 12. rule_count 가 그 용어의 정의 행 수와 같은지 다시 셉니다. 13. evidence 의 field 이름이 세 데이터셋에 실재하는 컬럼인지 대조합니다. 14. agg 가 없는 evidence 의 value 가 그 컬럼에 수록된 행 값과 같은지 확인합니다. 15. summary 가 존댓말로 끝나는지 확인합니다. [평가 러너 · 2주차] 손으로 만든 현업 질문 120건에 정답 판정을 붙여 대조해 일치율과 사유 코드별 분포를 내고, 정의 충돌이 몰리는 용어를 모아 회사 안에서 말이 갈리는 지점을 목록으로 냅니다. [수동 검증 · 사람이 봅니다] 1. 정의가 갈린 용어를 어느 쪽으로 정할지 담당 조직이 정합니다. 2. 정의가 하나로 정해진 답이 현업의 뜻과 같은지 담당자가 조건을 읽어 확인합니다.