디피FDE (AI Engineer)
4.6 (7)디피니트
경력근거: 고객 인터뷰를 통해 업무 규칙과 암묵지를 발견
65일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
공고는 고객 인터뷰로 업무 규칙과 암묵지를 발견하고 Text-to-SQL이 올바른 의미를 이해하도록 만드는 일을 담당 업무로 둡니다. 이 포트폴리오는 그 앞단을 골조로 씁니다. 용어 체계를 설계하는 것은 여러 사람의 합의가 있어야 존재하는 결과물이라 혼자 만들 수 없으므로, 대신 정의가 갈리는 자리를 데이터에서 찾아 질문으로 바꾸고 답을 규칙으로 굳히는 데까지 만듭니다. Python과 RAG, LLM은 그 안에서 각각 규칙 판정과 근거 문서 인용, 질문 문장 작성을 맡습니다. 다만 보여주는 것은 데이터 대조와 질의 검증 기술이며 제조·유통 회계 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
공고가 첫머리에서 어떤 회사의 매출은 반품을 제외한 금액이고 어떤 회사는 특정 사업부만 뜻한다고 말합니다. 사람은 당연하게 아는 규칙을 AI가 모른다는 것이 이 회사가 정의한 문제이므로, 그 어긋남을 찾아내는 일이 제품의 첫 단계가 됩니다.
담당하게 될 일의 첫 줄이 고객 인터뷰를 통해 업무 규칙과 암묵지를 발견하는 것입니다. 현장에서 받는 자료가 잘 정리된 API가 아니라 ERP에서 내려받은 파일이므로, 그 파일에서 물어볼 거리를 뽑아내는 도구가 실제 업무와 겹칩니다.
Text-to-SQL이 올바른 의미를 이해하도록 AI 로직을 설계하고 실제 데이터로 검증해 반복 개선하는 것이 담당 업무입니다. 질의를 만드는 것보다 그 질의가 회사의 정의를 따르는지 확인하는 쪽에 무게가 실립니다.
고객사 자료와 현업 질문 기록을 나란히 놓고 같은 지표가 다르게 계산된 자리를 찾아, 담당자가 예 아니오로 답할 수 있는 질문으로 바꿔 줍니다. 답이 정해지면 그 정의를 규칙으로 남겨 다음 질문부터 같은 뜻으로 계산됩니다.
저는 고객사에 나가 있는 엔지니어입니다. 현업은 매출을 물어보는데 재무팀 숫자와 영업팀 숫자가 다릅니다. 어느 쪽이 맞는지 물으면 둘 다 맞다고 하고, 무엇이 다른지는 아무도 문서로 갖고 있지 않습니다. 저는 그 차이를 찾아 물어볼 목록부터 만들어야 합니다.
용어 체계를 먼저 세우려 하면 합의가 끝날 때까지 아무것도 못 만듭니다. 반대로 데이터에서 정의가 갈리는 자리를 먼저 찾아 물어보면, 합의는 그 질문에 답하는 형태로 조각씩 쌓이고 그때마다 질의가 정확해집니다.
매출 자료와 질문 로그를 올리면 같은 지표가 다르게 계산된 자리를 찾아 무엇을 물어야 하는지 목록으로 냅니다. 각 질문에는 지금 규칙으로 만들면 나올 SQL을 함께 붙여, 정의가 정해지기 전과 후의 질의가 어떻게 달라질지 미리 보입니다. 1주차 탐지 범위는 기준상이·지표명상이·미등록조직·값결측 네 가지이고, 범위상이와 판정불가는 2주차로 미룹니다.
확인 질문에 답을 넣으면 그 정의가 규칙으로 등록되고, 같은 질문의 SQL이 등록 전후로 어떻게 달라지는지 나란히 비교됩니다. 탐지 범위에 범위상이와 판정불가를 더해 여섯 가지를 모두 다룹니다.
정의를 고쳤을 때 이미 답했던 질문들의 숫자가 어떻게 달라지는지 목록으로 내고, 영향이 큰 질문부터 재확인 대상으로 표시합니다.
재무 기준과 영업 기준이 섞인 매출 자료와 질문 로그를 올려 뜻이 갈리는 자리를 잡고, 각 건을 예 아니오로 답할 수 있는 질문과 현재 규칙 기준 SQL로 함께 냅니다.
확인 질문에 답을 넣으면 같은 질문의 SQL이 등록된 정의대로 바뀌는 것을 전후로 나란히 보여 줍니다.
컬럼이 비었거나 지표 이름이 흔들리거나 사업부 코드가 마스터에 없는 자료 30종을 넣어도 대조가 끝까지 돌고 판정 불가 건이 따로 표시됩니다.
충돌 80건에 사람이 매긴 정답을 붙여 놓친 건과 잘못 잡은 건을 유형별로 냅니다. 단, 정답과 데이터를 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
위 수치는 더미데이터 자가채점이며, 실제 탐지율은 디피니트가 맡은 고객사의 실 ERP 자료와 현업 담당자의 답변이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측 컬럼과 경계 금액, 마스터에 없는 사업부 코드, 지표 이름 흔들림을 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
데이터에 흔적이 남지 않은 암묵지는 이 방식으로 못 잡습니다. 마감을 며칠 당겨 잡는 관행이나 특정 거래처만 빼는 예외처럼 숫자가 어긋나지 않는 규칙은 대조로 드러나지 않으므로, 인터뷰로만 나오는 영역이 남는다는 것을 전제로 씁니다.
숫자가 다르다고 해서 어느 한쪽이 틀린 것은 아닙니다. 목적이 다른 두 집계가 공존하는 경우가 흔하므로 산출물을 오류 판정이 아니라 확인 질문으로 두고 사람이 닫게 합니다.
정의를 규칙으로 등록하는 순간 그 회사의 합의처럼 보이지만 실제로는 한 사람의 답일 뿐입니다. 누가 그 정의를 정할 권한을 갖는지는 도구가 정할 수 없으므로, 등록 시 답변자와 시점을 함께 남기고 승인 절차는 도입 단계 과제로 분리합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 ERP에서 내려받은 형태의 매출 자료입니다. 같은 기간 같은 사업부가 서로 다른 기준으로 두 번 집계된 행을 의도적으로 포함합니다.
| row_id | period | division_raw | division_id | metric_name | basis | amount | includes_return | source_sheet |
|---|---|---|---|---|---|---|---|---|
| r_001 | 2026-06 | 모빌리티사업부 | d_10 | 매출 | 재무기준 | 8,420,000,000 | false | 재무_월마감 |
| r_002 | 2026-06 | 모빌리티 사업부 | d_10 | 매출 | 영업기준 | 8,910,000,000 | true | 영업_실적보고 |
| r_003 | 2026-06 | 부품사업부 | d_20 | 매출액 | 재무기준 | 5,120,000,000 | false | 재무_월마감 |
| r_004 | 2026-06 | 부품 | d_20 | 매출 | 미표기 | 5,480,000,000 | — | 영업_실적보고 |
| r_005 | 2026-06 | 신사업TF | — | 매출 | 영업기준 | 210,000,000 | true | 영업_실적보고 |
아래 JSON Schema에 맞는 ERP 매출 자료 행을 60건 더 만들어라. {"type":"object","properties":{"row_id":{"type":"string"},"period":{"type":"string"},"division_raw":{"type":"string"},"division_id":{"type":["string","null"]},"metric_name":{"type":"string"},"basis":{"type":"string","enum":["재무기준","영업기준","미표기"]},"amount":{"type":["number","null"]},"includes_return":{"type":["boolean","null"]},"source_sheet":{"type":"string"}},"required":["row_id","period","division_raw","metric_name","basis","source_sheet"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) amount와 includes_return이 null인 결측 행 10건, (2) amount가 0이거나 조 단위인 경계값 5건, (3) division_id가 null인 미등록 조직 6건, (4) 같은 사업부를 "모빌리티사업부"·"모빌리티 사업부"·"모빌리티"로 다르게 적은 표기 흔들림 10건, (5) 같은 기간 같은 사업부인데 basis만 다르고 금액이 어긋나는 쌍 8건과, 금액이 우연히 같아 충돌이 아닌 쌍 3건. (6) metric_name을 "매출"·"매출액"·"순매출"로 흔들어 지표 이름 자체가 갈리는 행 6건.{"type":"object","properties":{"row_id":{"type":"string"},"period":{"type":"string"},"division_raw":{"type":"string"},"division_id":{"type":["string","null"]},"metric_name":{"type":"string"},"basis":{"type":"string","enum":["재무기준","영업기준","미표기"]},"amount":{"type":["number","null"]},"includes_return":{"type":["boolean","null"]},"source_sheet":{"type":"string"}},"required":["row_id","period","division_raw","metric_name","basis","source_sheet"]}현업이 실제로 던진 질문 기록입니다. 어떤 지표가 어떤 맥락에서 불리는지 보여 주며, 충돌 탐지의 우선순위를 정하는 근거가 됩니다.
| q_id | asked_on | asker_role | question | mentioned_metric | mentioned_division_raw | answered_amount | answer_source |
|---|---|---|---|---|---|---|---|
| q_01 | 2026-07-01 | 영업기획 | 6월 모빌리티 매출 얼마야? | 매출 | 모빌리티 | 8,910,000,000 | 영업_실적보고 |
| q_02 | 2026-07-01 | 재무 | 6월 모빌리티사업부 매출 확정치 주세요 | 매출 | 모빌리티사업부 | 8,420,000,000 | 재무_월마감 |
| q_03 | 2026-07-03 | 경영지원 | 부품 쪽 매출이 전월 대비 늘었나요? | 매출 | 부품 | — | — |
| q_04 | 2026-07-05 | 영업기획 | 신사업TF 매출도 전사 합계에 들어가나요? | 매출 | 신사업TF | — | — |
| q_05 | 2026-07-07 | 재무 | 물류 순매출이랑 매출 차이가 뭐죠? | 순매출 | 물류사업부 | 1,240,000,000 | 재무_월마감 |
아래 JSON Schema에 맞는 현업 질문 기록을 50건 더 만들어라. {"type":"object","properties":{"q_id":{"type":"string"},"asked_on":{"type":"string"},"asker_role":{"type":"string"},"question":{"type":"string"},"mentioned_metric":{"type":"string"},"mentioned_division_raw":{"type":["string","null"]},"answered_amount":{"type":["number","null"]},"answer_source":{"type":["string","null"]}},"required":["q_id","asked_on","asker_role","question","mentioned_metric"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) answered_amount와 answer_source가 null인 미해결 질문 12건, (2) mentioned_division_raw가 null이라 어느 조직인지 안 적힌 질문 6건, (3) 같은 사람이 같은 지표를 다른 이름("매출"·"매출액"·"순매출")으로 부른 질문 8건, (4) 같은 질문에 부서별로 다른 숫자가 답으로 달린 쌍 6건, (5) 질문 문장에 기간이 안 적혀 어느 달인지 모르는 건 4건. 질문 문장은 실제 사내 메신저처럼 짧고 생략이 많게 쓰라.{"type":"object","properties":{"q_id":{"type":"string"},"asked_on":{"type":"string"},"asker_role":{"type":"string"},"question":{"type":"string"},"mentioned_metric":{"type":"string"},"mentioned_division_raw":{"type":["string","null"]},"answered_amount":{"type":["number","null"]},"answer_source":{"type":["string","null"]}},"required":["q_id","asked_on","asker_role","question","mentioned_metric"]}| Python | 자료 정규화와 정의 충돌 탐지 규칙, 질의 생성 흐름을 잇는 본체입니다. |
| LLM | 찾아낸 충돌을 현업이 답할 수 있는 질문 문장으로 바꾸는 일을 맡습니다. 무엇이 충돌인지는 규칙이 정합니다. |
| RAG | 고객사 업무 문서에서 그 지표를 언급한 대목을 찾아 질문에 근거로 붙입니다. 2주차부터 붙습니다. |
| Claude | 확인 질문 문장과 정의 요약을 쓰는 데 씁니다. 긴 문서에서 정의 대목을 잡아내는 데도 씁니다. |
| ChatGPT | 같은 프롬프트로 질문 문장을 교차 생성해 표현이 한쪽으로 치우치지 않는지 견줍니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 답을 규칙으로 등록해 질의에 반영되는 단계로 넘어갑니다.
✓ pass → 여기까지도 완결입니다. 더 키우려면 정의 변경이 과거 답에 미치는 영향을 계산해 재확인 대상을 뽑는 단계로 확장합니다.
확인 질문 목록 한 줄에 해당합니다. 어떤 지표가 어떻게 갈렸는지, 무엇을 물어야 하는지, 답이 정해지면 어떤 규칙이 등록되는지를 담습니다.
{"type":"object","properties":{"conflict_id":{"type":"string"},"conflict_type":{"type":"string","enum":["기준상이","지표명상이","범위상이","미등록조직","값결측","판정불가"]},"metric":{"type":"string"},"observed":{"type":"array","items":{"type":"object","properties":{"row_id":{"type":"string"},"basis":{"type":"string"},"amount":{"type":["number","null"]}},"required":["row_id","basis","amount"]}},"gap":{"type":["number","null"]},"ask":{"type":"string"},"options":{"type":"array","items":{"type":"string"}},"rule_if_answered":{"type":["string","null"]},"hedge":{"type":["string","null"]}},"required":["conflict_id","conflict_type","metric","observed","ask","options"]}[
{
"conflict_id": "c_001",
"conflict_type": "기준상이",
"metric": "매출",
"observed": [
{
"row_id": "r_001",
"basis": "재무기준",
"amount": 8420000000
},
{
"row_id": "r_002",
"basis": "영업기준",
"amount": 8910000000
}
],
"gap": 490000000,
"ask": "6월 모빌리티사업부 매출을 물었을 때 어느 숫자를 답으로 봐야 하나요? 두 자료의 차이는 반품 포함 여부입니다.",
"options": [
"재무기준(반품 제외)을 기본으로 한다",
"영업기준(반품 포함)을 기본으로 한다",
"질문자가 속한 부서 기준을 따른다"
],
"rule_if_answered": "metric=매출 조회 시 basis=재무기준 행을 기본 선택하고, 영업기준 값은 참고로 함께 표시합니다.",
"hedge": null
},
{
"conflict_id": "c_002",
"conflict_type": "지표명상이",
"metric": "매출액",
"observed": [
{
"row_id": "r_003",
"basis": "재무기준",
"amount": 5120000000
},
{
"row_id": "r_009",
"basis": "재무기준",
"amount": 1240000000
}
],
"gap": null,
"ask": "매출과 매출액, 순매출을 같은 지표로 봐도 되나요? 자료에 세 이름이 섞여 있고 계산 범위가 달라 보입니다.",
"options": [
"매출과 매출액은 같고 순매출만 다르다",
"셋 다 다른 지표다",
"부서마다 다르게 쓴다"
],
"rule_if_answered": "지표명 별칭표에 매출=매출액을 등록하고 순매출은 별도 지표로 분리합니다.",
"hedge": "두 행의 사업부가 달라 금액 차이만으로는 범위 차이를 단정할 수 없습니다. 합성 기준 추정입니다."
},
{
"conflict_id": "c_003",
"conflict_type": "미등록조직",
"metric": "매출",
"observed": [
{
"row_id": "r_005",
"basis": "영업기준",
"amount": 210000000
}
],
"gap": null,
"ask": "신사업TF 매출을 전사 합계에 넣어야 하나요? 조직 마스터에 코드가 없어 자동 집계에서 빠지고 있습니다.",
"options": [
"전사 합계에 포함한다",
"별도로 표시하고 합계에서 제외한다",
"정식 사업부 등록 전까지 보류한다"
],
"rule_if_answered": "division_id가 null인 조직은 합계 대상에서 제외하되 목록에 별도 행으로 표시합니다.",
"hedge": "현업 질문 q_04에서 같은 것을 이미 물었으나 답이 남아 있지 않습니다."
}
][자동 검증 — 사람 없이 매번 돌립니다] 1. observed의 row_id가 실제 자료에 있는 행인지, amount가 그 행의 값과 같은지 대조합니다. 어긋나면 그 항목을 버립니다. 2. gap이 있는 항목은 observed의 두 amount 차이와 일치하는지 계산해 확인합니다. 결측이 섞인 경우 gap은 null이어야 합니다. 3. options가 두 개 이상이고 서로 배타적인지 확인합니다. 하나뿐이면 질문이 아니라 통보이므로 반려합니다. 4. conflict_type이 판정불가이거나 값결측인 항목은 rule_if_answered가 null인지 확인합니다. 답이 정해지지 않았는데 규칙을 미리 쓰면 안 됩니다. 5. 사람이 매긴 정답이 있는 충돌은 conflict_type이 일치하는지 비교하고 놓친 건과 잘못 잡은 건을 유형별로 셉니다. [수동 검증 — 사람이 봐야 합니다] 1. ask 문장이 현업이 예 아니오나 보기 선택으로 바로 답할 수 있는 크기인지, 배경 설명만 길지 않은지 봅니다. 2. rule_if_answered가 그 답 하나로 실제 질의에 반영될 만큼 구체적인지, 다시 해석이 필요한 문장은 아닌지 봅니다.