제너[BBQ] AI Product Engineer
2.2 (700)제너시스비비큐
경력근거: 부서별 업로드 데이터의 자동 적재·인덱싱 체계 구축
41일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
제너시스BBQ는 사내 AI 포털과 에이전트를 운영하면서 부서별 업로드 데이터를 자동으로 적재하는 체계를 이 포지션에 맡깁니다. 프랜차이즈 본사는 구매와 발주, 상권분석, VOC처럼 부서가 나뉘어 있고 매장 운영 매뉴얼이 개정될 때마다 새 파일이 올라와, 지난 개정본이 검색에 걸리면 가맹점에 잘못된 기준이 나갑니다. 이 도구는 그 앞단을 봅니다. 공고 업무는 코드베이스 분석부터 에이전트 개발까지 걸쳐 있는데 1주 범위에서 적재 게이트 축을 골랐습니다. 이 포트폴리오는 문서를 규칙으로 걸러 지식베이스 품질을 지키는 기술을 보여줍니다. 임베딩 모델 학습이나 멀티모달 처리의 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
주요 업무에 부서별 업로드 데이터의 자동 적재와 인덱싱 체계 구축이 적혀 있습니다. 자동으로 넣으려면 넣어도 되는 문서인지 먼저 나눠야 합니다.
사내 문서 기반 지식 검색 체계 설계와 고도화가 업무입니다. 검색이 지난 개정본을 물어 오면 현업이 틀린 기준으로 일하게 되므로, 개정 관계를 적재 전에 정리해야 합니다.
전사 유관부서의 요구사항을 수집하고 구현 방향을 조율하는 일이 업무로 적혀 있습니다. 부서마다 문서 관리 방식이 달라 부서 구분을 원문 그대로 받아 표준 코드로 잇는 층이 필요합니다.
부서가 사내 포털에 올린 문서를 적재 규칙과 대조해, 지식베이스에 넣어도 되는 문서와 걸러야 할 문서를 나눠 보여주는 관리자 페이지입니다. 판정은 내용 해시와 개정 관계로 정합니다.
사내 AI 포털을 맡은 담당자입니다. 부서마다 문서를 올리는데 같은 매뉴얼이 이름만 바꿔 여러 번 올라오고 지난 개정본도 섞여 있어, 검색이 틀린 기준을 물어 오면 그제서야 원본을 찾아 지웁니다.
문서마다 내용 해시와 문서번호, 개정 차수가 남아 있으면, 넣어도 되는 문서인지는 적재 전에 규칙으로 갈라집니다.
업로드 목록과 부서 사전을 올리면 사유별로 나눠 보여주고 적재 대기열을 만드는 관리자 페이지입니다. 파일 본문을 읽지 않고 업로드 때 계산된 내용 해시를 그대로 쓰는 것을 전제로 시작합니다.
같은 문서번호의 개정 차수를 비교해 이전 판을 검색 대상에서 내리고 이력으로 남기는 처리입니다.
걸러진 문서와 사유를 올린 부서별로 묶어 포털 게시판에 알리는 알림 생성기입니다.
업로드 20건과 부서 사전을 올려 사유별로 갈라진 화면과 적재 대기열이 나오는 것을 시연합니다.
결측·중복·미등록 부서 표기·지원하지 않는 형식이 섞인 입력 30종을 넣어도 화면 형식이 깨지지 않고, 판정하지 못한 문서는 사유가 붙어 남습니다.
유효기간이 비어 있으면 만료로 단정하지 않고 확인 필요로 따로 답니다. 비어 있는 값을 지난 것으로 취급하지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 업로드 목록과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 판정 정확도는 제너시스BBQ 포털에 실제로 올라오는 문서와 실제 부서 운영 기준이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측·중복·미등록 부서 표기·지원하지 않는 형식을 더미에 일부러 섞어 쉬운 문제만 푸는 것을 피합니다.
내용 해시가 같다고 해서 하나를 지워도 된다고 단정할 수 없습니다. 부서마다 보존 의무가 다를 수 있어, 이 도구는 중복을 알리고 삭제 판단은 올린 부서가 합니다.
실제 도입하면 부서마다 문서번호 체계가 다릅니다. 개정 차수를 어떻게 읽을지 부서와 합의하는 일이 도입 단계의 실제 과제입니다.
1주차는 업로드 때 계산된 해시를 그대로 믿습니다. 내용이 거의 같지만 해시가 다른 문서는 이 단계에서 잡히지 않습니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
부서가 사내 포털에 올린 문서 목록입니다. 문서번호와 개정 차수, 내용 해시가 함께 있어 중복과 개정 관계를 대조합니다. 결측과 중복, 사전에 없는 부서 표기를 일부러 섞었습니다.
| doc_no | dept_raw | title | doc_hash | revision | file_type | effective_until |
|---|---|---|---|---|---|---|
| DOC-1001 | 구매팀 | 원부자재 발주 기준 | hA100 | 3 | 2027-12-31 | |
| DOC-1001 | 구매팀 | 원부자재 발주 기준 | hA099 | 2 | 2026-06-30 | |
| DOC-1002 | 물류팀 | 냉장 배송 온도 관리 | hB200 | 1 | 2027-06-30 | |
| DOC-1003 | 상권분석팀 | 신규 출점 상권 평가표 | hC300 | 2 | xlsx | — |
| DOC-1004 | VOC팀 | 고객 불만 응대 매뉴얼 | hD400 | 4 | docx | 2027-03-31 |
아래 JSON Schema에 맞는 포털 업로드 문서 행을 더 만들어 주세요. {"type":"object","properties":{"doc_no":{"type":"string"},"dept_raw":{"type":"string"},"title":{"type":"string"},"doc_hash":{"type":"string"},"revision":{"type":"integer"},"file_type":{"type":"string"},"effective_until":{"type":["string","null"]}},"required":["doc_no","dept_raw","title","doc_hash","revision","file_type","effective_until"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 effective_until이 null인 행, 둘째 중복으로 같은 doc_no가 개정 차수만 달리해 두 행에 있는 건과 서로 다른 doc_no인데 doc_hash가 같은 건, 셋째 미매핑으로 dept_raw가 사전에 없어 dept_id가 null인 행, 넷째 표기흔들림으로 같은 부서를 구매팀과 구매로 다르게 적은 행, 다섯째 경계극단으로 유효기간이 이미 지난 문서, 여섯째 포털이 받지 않는 형식의 파일. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 revision에 문자열을 넣거나 required 필드를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"doc_no":{"type":"string"},"dept_raw":{"type":"string"},"title":{"type":"string"},"doc_hash":{"type":"string"},"revision":{"type":"integer"},"file_type":{"type":"string"},"effective_until":{"type":["string","null"]}},"required":["doc_no","dept_raw","title","doc_hash","revision","file_type","effective_until"]}부서 원문 표기를 표준 코드로 잇는 사전입니다. 문서의 dept_raw가 이 사전에 없으면 미매핑으로 답니다. 신설 부서를 일부러 등록하지 않아 미등록 상황을 재현했습니다.
| dept_raw | dept_id | display_name | allowed_file_types | owner_role |
|---|---|---|---|---|
| 구매팀 | purchase | 구매팀 | pdf,xlsx,docx | manager |
| 구매 | purchase | 구매팀 | pdf,xlsx,docx | manager |
| 물류팀 | logistics | 물류팀 | pdf,xlsx,hwp | manager |
| 상권분석팀 | market | 상권분석팀 | pdf,xlsx | analyst |
| VOC팀 | voc | VOC팀 | pdf,docx | manager |
아래 JSON Schema에 맞는 부서 사전 행을 더 만들어 주세요. {"type":"object","properties":{"dept_raw":{"type":"string"},"dept_id":{"type":"string"},"display_name":{"type":"string"},"allowed_file_types":{"type":"string"},"owner_role":{"type":"string"}},"required":["dept_raw","dept_id","display_name","allowed_file_types","owner_role"]} 같은 dept_id에 팀을 붙인 표기와 뗀 표기를 함께 두어 흔들림을 흡수하게 하고, 업로드 목록에는 나오지만 사전에는 없는 신설 부서가 남도록 일부는 일부러 등록하지 말아 주세요. 부서마다 받을 수 있는 파일 형식을 다르게 해 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 required 필드를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"dept_raw":{"type":"string"},"dept_id":{"type":"string"},"display_name":{"type":"string"},"allowed_file_types":{"type":"string"},"owner_role":{"type":"string"}},"required":["dept_raw","dept_id","display_name","allowed_file_types","owner_role"]}| TypeScript | 판정 결과와 적재 대기열을 보여주는 관리자 화면입니다. |
| Python | 업로드 목록과 사전을 읽어 적재 규칙을 돌리는 판정 본체입니다. |
| RAG 지식베이스 | 적재 대상이 되는 저장소이며, 이 도구가 그 앞의 게이트 역할을 합니다. |
| Cloudflare D1 | 업로드 이력과 판정 결과, 개정 관계를 담는 저장소입니다. |
| LangGraph | 판정 단계를 나눠 각 단계의 출력 형식을 강제하는 흐름 구성에 씁니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 같은 문서번호의 지난 개정본을 검색에서 내립니다.
✓ pass → 개정 정리까지가 한 덩어리입니다. 더 키우려면 걸러진 사유를 부서에 돌려줍니다.
위 예측 UI 는 3주차까지 완주했을 때의 화면입니다. 1주차에 실제로 만드는 것은 아래 표시된 화면 하나입니다.
verdict사유 라벨 · doc_no + 한 줄 요약(근거 수치 포함)화면·코드·면접에서 이 단어를 그대로 씁니다. 키는 출력 스키마의 enum 과 같습니다.
ready적재 가능duplicate_content내용 중복superseded지난 개정본expired유효기간 지남dept_unmapped부서 미등록type_not_allowed형식 불가업로드 문서 한 건의 판정 결과입니다. 지식베이스에 넣어도 되는지, 안 되면 무엇 때문인지를 근거와 함께 담습니다.
{"type":"object","properties":{"doc_no":{"type":"string"},"verdict":{"type":"string","enum":["ready","duplicate_content","superseded","expired","dept_unmapped","type_not_allowed"]},"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":["doc_no","verdict","evidence","next_action"]}[
{
"doc_no": "DOC-1002",
"verdict": "ready",
"evidence": [
{
"field": "dept_raw",
"value": "물류팀"
},
{
"field": "file_type",
"value": "pdf"
},
{
"field": "effective_until",
"value": "2027-06-30"
}
],
"next_action": "적재 대기열에 넣습니다."
},
{
"doc_no": "DOC-1011",
"verdict": "ready",
"evidence": [
{
"field": "dept_raw",
"value": "품질관리팀"
},
{
"field": "file_type",
"value": "pdf"
},
{
"field": "revision",
"value": 2
}
],
"next_action": "적재 대기열에 넣습니다."
},
{
"doc_no": "DOC-1005",
"verdict": "duplicate_content",
"evidence": [
{
"field": "doc_hash",
"value": "hA100"
},
{
"field": "doc_hash",
"agg": "count",
"value": 2
}
],
"next_action": "DOC-1001과 내용이 같습니다. 올린 부서에 어느 쪽을 남길지 확인하고 하나만 적재합니다."
},
{
"doc_no": "DOC-1001",
"verdict": "superseded",
"evidence": [
{
"field": "revision",
"value": 2
},
{
"field": "effective_until",
"value": "2026-06-30"
}
],
"next_action": "같은 문서번호의 3차 개정본이 있습니다. 2차는 적재하지 않고 이력으로만 남깁니다."
},
{
"doc_no": "DOC-1007",
"verdict": "expired",
"evidence": [
{
"field": "effective_until",
"value": "2025-12-31"
},
{
"field": "dept_raw",
"value": "가맹운영팀"
}
],
"next_action": "유효기간이 지났습니다. 최신 위생 점검표를 다시 올리도록 부서에 알립니다."
},
{
"doc_no": "DOC-1006",
"verdict": "dept_unmapped",
"evidence": [
{
"field": "dept_raw",
"value": "教育팀",
"quote": "教育팀"
},
{
"field": "dept_raw",
"value": "教育팀"
}
],
"next_action": "사전에 없는 부서 표기입니다. 조직도와 맞춰 사전에 추가한 뒤 적재합니다."
},
{
"doc_no": "DOC-1018",
"verdict": "type_not_allowed",
"evidence": [
{
"field": "file_type",
"value": "zip"
},
{
"field": "allowed_file_types",
"value": "pdf,pptx"
}
],
"next_action": "마케팅팀이 올릴 수 있는 형식이 아닙니다. 압축을 풀어 개별 파일로 다시 올리도록 알립니다."
},
{
"doc_no": "DOC-1017",
"verdict": "superseded",
"evidence": [
{
"field": "revision",
"value": 3
},
{
"field": "doc_hash",
"value": "hD399"
}
],
"next_action": "같은 제목의 4차 개정본이 있습니다. 3차는 적재하지 않고 이력으로만 남깁니다."
},
{
"doc_no": "DOC-1003",
"verdict": "ready",
"evidence": [
{
"field": "effective_until",
"value": null
},
{
"field": "doc_no",
"value": "DOC-1003"
}
],
"next_action": "effective_until 이 비어 있어 판정하지 않았습니다. 값을 채운 뒤 다시 봅니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 여섯 값 안에 있는지 확인합니다. 2. doc_no·verdict·evidence·next_action이 모두 있는지 확인합니다. 3. revision이 1 이상인지 확인합니다. 4. dept_id가 null이면 verdict가 dept_unmapped인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 dept_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 부서 표기은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 dept_directory의 dept_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. [수동 검증] 1. 내용이 같다고 판정한 문서 중 어느 쪽을 남길지 올린 부서가 정합니다. 2. DOC-1003·DOC-1019처럼 유효기간이 비어 있는 문서를 만료로 보지 않는 것이 맞는지 부서와 확인합니다. [평가 러너 · 2주차] 1. 손으로 만든 정답표와 verdict를 맞춰 사유별로 어긋난 건을 셉니다. 2. 업로드 목록과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.