제너러티브랩
경력근거: 에이전트가 안정적으로 운영될 수 있도록 문제 정의부터 구축 배포까지 전 과정을 책임집니다
※ 실제 산출물이 아닌 AI 예측 시안입니다.
제너러티브랩의 FDE 는 매출 1000억 이상 글로벌 기업의 C레벨과 팀장, 실무자를 직접 만나 에이전트가 성공적으로 배포될 방안을 만들어내고, 문제 정의부터 구축 배포까지 전 과정을 책임집니다. 그 자리에서 가장 먼저 합의해야 하는 것은 모델 성능이 아니라 '무엇까지 맡길 것인가' 이고, 합의는 감이 아니라 고객사 자기 매뉴얼의 조항 번호로 이뤄져야 다음 주에 붙일 수 있습니다. 이 화면은 그 합의를 만드는 자리에 놓입니다. 상담 이력과 매뉴얼을 대조해 유형마다 근거 조항을 인용하고, 근거가 없거나 조항이 어긋나면 자동 응대에서 빼내며, CS 팀장이 근거를 직접 읽고 승인한 결과가 그대로 배포 범위 문서가 됩니다. 나라별로 기한이 다른 조항을 먼저 걸러내는 부분은 미국·일본으로 나가는 브랜드를 돕는다는 이 회사 업무 맥락에서 나온 것입니다. 다만 이 포트폴리오가 보여주는 것은 비정형 업무 문서 파싱과 조항 단위 근거 인용, 규칙 기반 이관 판정, 검토 화면 구현이라는 기술 역량이며, 커머스 CS 운영과 글로벌 브랜드 규정 도메인 전문성은 주장하지 않습니다. 모르는 도메인 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
매출 1000억 이상 글로벌 기업의 C레벨과 팀장, 실무자와 직접 협업해 에이전트가 성공적으로 배포될 방안을 만들어내는 자리입니다. 방안은 말이 아니라 '이 유형은 맡기고 저 유형은 사람이 받는다' 는 합의된 목록이어야 다음 주에 붙일 수 있습니다.
에이전트가 안정적으로 운영되도록 문제 정의부터 구축 배포까지 전 과정을 책임집니다. 그래서 첫 산출물은 모델 성능표가 아니라 고객사가 읽고 동의할 수 있는 범위와 근거여야 합니다.
국내를 넘어 미국·일본 등 브랜드의 글로벌 진출을 최전선에서 돕습니다. 같은 문의라도 나라마다 반품 기한과 안내 문구가 달라, 조항이 어긋나는 지점을 자동 응대에서 먼저 빼내야 사고가 나지 않습니다.
고객사 CS 팀에서 받은 상담 이력 엑셀과 응대 매뉴얼 문서를 올리면, 상담을 문의 유형으로 묶고 각 유형이 매뉴얼의 어느 조항으로 답해지는지 조항 번호와 원문 문장으로 이어 붙입니다. 근거 조항이 하나로 정해지는 유형은 그 조항을 인용한 답변 초안을 달고 자동 응대 후보로 올라가고, 매뉴얼에 근거가 없거나 나라별 조항이 서로 어긋나는 유형은 이유를 달아 사람 이관으로 내려갑니다. 화면 왼쪽에 유형 목록, 오른쪽에 그 유형의 실제 상담 원문과 인용된 조항 원문을 나란히 놓아, 고객사 CS 팀장이 근거를 직접 읽고 유형마다 승인하거나 되돌립니다. 승인·이관 결정이 쌓이면 그대로 배포 범위 문서로 내보내집니다. 실제 CS 채널에 붙이거나 고객에게 발송하는 일은 하지 않고, 무엇을 맡길지 정하는 데까지가 이 화면의 범위입니다.
고객사 킥오프를 마치고 돌아온 배포 담당자입니다. CS 팀장은 '웬만한 건 다 맡기고 싶다' 고 하고 법무 쪽은 '함부로 답하면 안 되는 게 있다' 고 하는데, 그 경계를 제가 정할 수는 없습니다. 상담 이력 8천 건 엑셀과 매뉴얼 PDF 를 받아 놓고 며칠째 눈으로 훑고 있는데, 유형을 나눠도 '이건 매뉴얼에 있는 얘기인가' 를 매번 다시 찾느라 진도가 안 나갑니다. 다음 미팅에서 감으로 정한 범위 말고 조항 번호가 붙은 목록을 펴 놓고 '이 줄을 승인해 주시면 여기까지 맡기겠습니다' 라고 말하고 싶은 사람입니다.
자동 응대 여부는 모델이 잘 답하느냐가 아니라 고객사 매뉴얼에 근거가 있느냐로 갈린다고 보고, 각 문의 유형을 조항 번호로 이어 붙인 다음 근거가 없거나 조항이 충돌하면 무조건 사람 이관으로 내리면, (a) 배포 범위가 감이 아니라 조항 목록으로 정해지고, (b) 채점이 인용한 조항 번호가 정답 조항과 같은지 대조하는 결정론 판정으로 끝나며, (c) 나라별로 어긋나는 조항처럼 사람이 정해야 할 것들이 자동 응대 후보에서 먼저 빠져 배포 사고를 막습니다.
상담 이력 엑셀과 매뉴얼 문서를 올리면 문의 유형으로 묶고 유형마다 근거 조항을 인용해 자동 응대 후보와 사람 이관으로 나눠 보여주는 웹 화면입니다. 자동 응대 후보에는 조항을 인용한 답변 초안이 붙고, 승인·되돌림 결정을 배포 범위 문서로 내보냅니다. 매뉴얼은 텍스트가 살아 있는 문서만 받는다고 가정하고, 스캔 이미지 PDF 판독은 2주차로 미룹니다.
일본어와 영어로 들어온 문의를 한국어 유형과 같은 묶음으로 이어 붙이고, 나라별 매뉴얼에서 반품 기한처럼 서로 다른 값을 말하는 조항 쌍을 찾아 그 유형을 자동 응대에서 빼내는 단계입니다. 스캔 이미지 매뉴얼도 이때 판독 대상에 넣습니다.
검토 화면에서 되돌린 유형의 사유를 모아 이관 규칙에 반영하고, 승인된 유형만 모아 실제 응대 채널에 붙일 때 필요한 항목(호출 규격·이관 조건·금지 표현)을 인계 문서로 정리하는 단계입니다.
상담 이력 60건과 매뉴얼 24조항을 올리면 문의를 유형 12개로 묶어 각각 자동 응대 후보와 사람 이관으로 가르고, 유형을 펼치면 인용된 조항 번호와 그 조항 원문, 근거로 쓰인 실제 상담 문장을 나란히 보여줍니다
인용한 조항 번호를 정답 조항과 대조해 100% 자동 판정합니다. 매뉴얼에 근거가 없는 함정 문의 8건이 하나도 자동 응대 후보로 올라가지 않는지, 나라별로 값이 어긋나는 조항 쌍 3건이 전부 이관으로 빠지는지 매번 검사합니다
엑셀이 지저분한 30종(병합 셀·머리글 반복·소계 행·본문 두 건 섞임·주문번호 표기 흔들림·빈 행)을 넣어도 파싱이 죽지 않고 읽지 못한 행을 따로 세워 보여줍니다
생성된 답변 초안이 인용 조항 밖 내용을 말했는지, 초안 문장과 조항 원문을 기계로 대조해 검사합니다. 단, 상담과 매뉴얼과 정답을 모두 작성자가 만든 합성 기준이라 '성능 검증' 이 아니라 '데모 조건에서의 동작' 입니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 자동 응대 범위가 옳게 갈렸는지는 제너러티브랩이 들어간 고객사의 실제 상담 이력과 그 회사 CS 팀장 검수가 있어야 측정 가능합니다. 이 화면은 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 '성능 증명' 이 아닙니다. 면접에서 '데모 조건 동작 + 실검증 준비 상태' 로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 매뉴얼에 근거가 없는 문의·조항이 서로 어긋나는 문의·본문에 두 건이 섞인 상담·주문번호 표기 흔들림 같은 경계 케이스를 더미에 섞어, 쉬운 문제만 푸는 게 아님을 보여줍니다
매뉴얼이 곧 이 화면의 한계선입니다. 실무자가 매뉴얼 없이 관행으로 처리하던 문의는 전부 근거 없음으로 떨어져 이관이 과하게 늘어날 수 있으므로, 이관 비율 자체를 고객사와 함께 보면서 매뉴얼을 채울지 범위를 좁힐지 정해야 합니다
자동 응대 후보로 올라갔다고 바로 붙여도 된다는 뜻은 아닙니다. 이 화면은 무엇을 맡길지 정하는 데까지이고, 실제 채널 연결과 발송은 고객사 계정과 운영 승인이 있어야 하는 별개 단계입니다
실제 도입 시 달라지는 것을 명시합니다. 고객사 실제 상담 이력 분포, 스캔 이미지 매뉴얼 판독, CS 팀장 검수로 교체해야 하며 이는 도입 단계 과제로 분리합니다
이 포트폴리오가 보여주는 것은 비정형 업무 문서 파싱과 조항 단위 근거 인용, 규칙 기반 이관 판정, 검토 화면 구현이라는 기술 역량이며, 커머스 CS 운영이나 글로벌 브랜드 규정 도메인 전문성은 주장하지 않습니다. 모르는 도메인 깊이는 면접에서 모른다고 말하는 편이 낫습니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 CS 팀에서 내려받은 상담 이력 엑셀을 행 단위로 읽은 것입니다. 문의 유형을 묶고 근거 조항을 잇는 대상이며, 언어 혼재와 기존 분류 결측, 본문에 두 건이 섞인 상담, 주문번호 표기 흔들림을 일부러 넣어 쉬운 데이터만 푸는 게 아님을 보여줍니다.
| inquiry_id | received_at | channel | locale | brand | category_raw | body | order_no_raw | attachment_count | prior_contact_count |
|---|---|---|---|---|---|---|---|---|---|
| i001 | 2026-06-02T10:14:00+09:00 | 이메일 | ko | A브랜드 | 반품 | 지난주에 받은 원피스가 사진이랑 색이 너무 달라요. 아직 태그도 안 … | A-2026-0512 | 2 | 0 |
| i002 | 2026-06-02T11:40:00+09:00 | 채팅 | ko | A브랜드 | — | 배송이 일주일째 안 와요. 그리고 지난번에 적립금 3천원 준다고 했는… | a 2026 0498 | 0 | 2 |
| i003 | 2026-06-03T09:05:00+09:00 | 이메일 | ja | A브랜드 | 返品 | 先週購入したバッグを返品したいのですが、購入から何日以内なら可能でしょうか。 | JP-2026-0031 | 0 | 0 |
| i004 | 2026-06-03T14:22:00+09:00 | SNS | en | B브랜드 | — | Hi, my order arrived damaged. Can I ge… | — | 1 | 0 |
| i005 | 2026-06-04T16:31:00+09:00 | 전화기록 | ko | B브랜드 | 기타 | 제 주민등록번호 뒷자리 알려드리면 결제 카드 바꿔주실 수 있나요? | B-2026-0210 | 0 | 1 |
아래 JSON Schema 에 맞는 커머스 브랜드 고객 상담 이력 80건을 JSON 배열로 생성. 브랜드는 A브랜드·B브랜드 두 개로 하고 반품·교환·환불·배송·상품문의·기타로 자연스럽게 분포시킬 것.
{"type":"object","properties":{"inquiry_id":{"type":"string"},"received_at":{"type":"string"},"channel":{"enum":["이메일","채팅","전화기록","SNS"]},"locale":{"enum":["ko","ja","en"]},"brand":{"type":"string"},"category_raw":{"type":["string","null"]},"body":{"type":"string"},"order_no_raw":{"type":["string","null"]},"attachment_count":{"type":"number"},"prior_contact_count":{"type":"number"}},"required":["inquiry_id","received_at","channel","locale","brand","body","attachment_count","prior_contact_count"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. (1) category_raw 가 null 이거나 본문 내용과 어긋나게 적힌 행 15건 이상, (2) locale 이 ja·en 인 문의 20건 이상(한국어 문의와 같은 뜻인 쌍을 최소 6쌍 포함), (3) body 하나에 서로 다른 문의 두 건이 섞인 행 6건(배송 지연 + 적립금 미지급 등), (4) order_no_raw 를 하이픈·공백·대소문자만 다르게 적은 표기 흔들림 10건과 null 8건, (5) 매뉴얼로는 답할 수 없는 문의 10건(개인정보 변경 요청, 환불 금액 확정, 향후 출시 계획, 매장 재고 등), (6) 첨부만 있고 본문이 한 문장도 안 되는 행 4건. inquiry_id 는 i001 부터 연속으로. JSON 배열만.{"type":"object","properties":{"inquiry_id":{"type":"string"},"received_at":{"type":"string"},"channel":{"enum":["이메일","채팅","전화기록","SNS"]},"locale":{"enum":["ko","ja","en"]},"brand":{"type":"string"},"category_raw":{"type":["string","null"]},"body":{"type":"string"},"order_no_raw":{"type":["string","null"]},"attachment_count":{"type":"number"},"prior_contact_count":{"type":"number"}},"required":["inquiry_id","received_at","channel","locale","brand","body","attachment_count","prior_contact_count"]}고객사가 준 응대 매뉴얼을 조항 단위로 쪼갠 것입니다. 자동 응대 여부와 답변 초안의 근거가 전부 여기에서만 나오며, 나라별로 기한이 다른 조항 쌍과 사람이 반드시 받아야 한다고 못박은 조항을 함께 넣어 충돌 탐지와 이관 판정을 검사하게 합니다.
상품 수령일로부터 14일 이내에 반품을 접수할 수 있습니다. 태그가 제거되지 않고 착용 흔적이 없어야 합니다.
商品到着日から30日以内に返品を受け付けます。タグが付いた未使用品に限ります。
아래 JSON Schema 에 맞는 커머스 브랜드 고객 응대 매뉴얼 조항 40건을 JSON 배열로 생성. 반품·교환·환불·배송·적립금·개인정보·해외배송 영역을 고루 담을 것.
{"type":"object","properties":{"clause_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"scope_locale":{"enum":["ko","ja","en","all"]},"brand":{"type":["string","null"]},"human_only":{"type":"boolean"},"supersedes":{"type":["string","null"]},"updated_on":{"type":["string","null"]}},"required":["clause_id","title","body","scope_locale","human_only"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. (1) 같은 주제인데 scope_locale 이 달라 기한·금액이 서로 어긋나는 조항 쌍 5쌍 이상(한국 14일 / 일본 30일 등), (2) supersedes 로 이전 조항을 대체하는데 updated_on 이 null 이라 어느 쪽이 최신인지 알 수 없는 조항 3건, (3) human_only=true 인 조항 6건(개인정보·금액 확정·법적 분쟁·안전 고지 등), (4) brand 가 특정 브랜드로 한정돼 다른 브랜드 문의에 쓰면 안 되는 조항 5건, (5) body 가 두 문장 안에 조건 두 개를 겹쳐 담아 단독으로는 답이 안 되는 조항 4건, (6) 상담에서 자주 묻지만 매뉴얼에는 일부러 넣지 않은 주제(향후 출시 계획, 매장 재고)를 만들지 말 것. 그건 근거 없음이 정답이어야 한다. clause_id 는 c01 부터 연속으로. JSON 배열만.{"type":"object","properties":{"clause_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"scope_locale":{"enum":["ko","ja","en","all"]},"brand":{"type":["string","null"]},"human_only":{"type":"boolean"},"supersedes":{"type":["string","null"]},"updated_on":{"type":["string","null"]}},"required":["clause_id","title","body","scope_locale","human_only"]}| Python | 상담 이력 엑셀 파싱, 문의 유형 묶기, 매뉴얼 조항 분해와 근거 대조 채점기를 구현하는 대표 언어 |
| TypeScript | 유형 목록과 상담 원문·조항 원문을 나란히 놓는 검토 화면과 승인·되돌림 상태 관리 |
| Next.js | 검토 화면을 한 벌로 배포하고 배포 범위 문서 내보내기 경로를 서버에서 처리 |
| PostgreSQL | 상담 이력·매뉴얼 조항·유형별 판정과 승인 이력을 담는 저장소이자 근거 추적의 출처 |
| LLM API | 상담 문장을 유형 후보로 묶고 인용된 조항으로 답변 초안을 쓰는 데만 쓰며, 자동·이관 판정 자체는 규칙이 맡습니다 |
| RAG | 매뉴얼이 수백 조항으로 늘면 전부 프롬프트에 넣을 수 없으므로 문의와 가까운 조항만 검색해 근거 후보로 올리는 검색증강 |
| Docker | 고객사 보안 정책상 사내에서 돌려야 할 때 화면과 저장소를 컨테이너 한 벌로 옮기기 위한 포장 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우고 싶으면 2주차(다국어 유형 묶기·조항 충돌 탐지)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(검수 사유 반영·인계 문서 정리)로 진행합니다.
문의 유형 하나에 대한 판정 결과입니다. 자동 응대 후보인지 사람 이관인지, 그 판단의 근거가 된 조항 번호와 원문 인용, 자동 응대라면 그 조항만으로 쓴 답변 초안, 이관이라면 왜 사람이 받아야 하는지를 담습니다. 인용 조항이 정답과 같은지 기계로 대조할 수 있게 필드를 나눠 둡니다.
{"type":"object","properties":{"cluster_id":{"type":"string"},"label_ko":{"type":"string"},"member_inquiry_ids":{"type":"array","items":{"type":"string"}},"decision":{"enum":["auto","human"]},"cited_clause_ids":{"type":"array","items":{"type":"string"}},"cited_quotes":{"type":"array","items":{"type":"object","properties":{"clause_id":{"type":"string"},"quote":{"type":"string"}},"required":["clause_id","quote"]}},"draft_reply_ko":{"type":["string","null"]},"escalation_reason":{"enum":["none","근거없음","조항충돌","사람전용조항","복수문의혼재"]},"conflict_pairs":{"type":"array","items":{"type":"array","items":{"type":"string"}}},"note_ko":{"type":["string","null"]}},"required":["cluster_id","label_ko","member_inquiry_ids","decision","cited_clause_ids","cited_quotes","escalation_reason","conflict_pairs"]}[
{
"input_ref": "'출고·배송 소요 기간 문의' 유형 (i008 등) · 매뉴얼 c05 로 단독 답변 가능",
"output": {
"cluster_id": "g03",
"label_ko": "출고·배송이 얼마나 걸리는지 묻는 문의",
"member_inquiry_ids": [
"i008"
],
"decision": "auto",
"cited_clause_ids": [
"c05"
],
"cited_quotes": [
{
"clause_id": "c05",
"quote": "주문 후 영업일 기준 2일 이내에 출고되며, 출고 후 배송에는 1일에서 3일이 걸립니다."
}
],
"draft_reply_ko": "주문하신 상품은 영업일 기준 2일 이내에 출고되고, 출고 후 배송에는 1일에서 3일이 걸립니다. 이틀째라면 아직 출고 준비 중일 수 있으니 조금만 더 기다려 주시면 감사하겠습니다.",
"escalation_reason": "none",
"conflict_pairs": [],
"note_ko": null
}
},
{
"input_ref": "'반품 기한 문의' 유형 (i003·i011) · 한국 14일과 일본 30일 조항이 어긋남",
"output": {
"cluster_id": "g01",
"label_ko": "반품을 언제까지 접수할 수 있는지 묻는 문의",
"member_inquiry_ids": [
"i003",
"i011"
],
"decision": "human",
"cited_clause_ids": [
"c01",
"c02",
"c11"
],
"cited_quotes": [
{
"clause_id": "c01",
"quote": "상품 수령일로부터 14일 이내에 반품을 접수할 수 있습니다."
},
{
"clause_id": "c02",
"quote": "商品到着日から30日以内に返品を受け付けます。"
},
{
"clause_id": "c11",
"quote": "상품 수령일로부터 30일 이내에 반품을 접수할 수 있습니다. B브랜드에 한해 적용합니다."
}
],
"draft_reply_ko": null,
"escalation_reason": "조항충돌",
"conflict_pairs": [
[
"c01",
"c02"
],
[
"c01",
"c11"
]
],
"note_ko": "같은 반품 기한을 두고 한국 14일, 일본 30일, B브랜드 30일 조항이 함께 있습니다. 어느 조항을 어떤 조건에서 적용할지 정해 주시면 자동 응대로 올릴 수 있습니다."
}
},
{
"input_ref": "'결제 수단·개인정보 변경 요청' 유형 (i005) · 매뉴얼이 사람만 처리하라고 못박음",
"output": {
"cluster_id": "g07",
"label_ko": "결제 수단이나 개인정보를 바꿔달라는 요청",
"member_inquiry_ids": [
"i005"
],
"decision": "human",
"cited_clause_ids": [
"c07"
],
"cited_quotes": [
{
"clause_id": "c07",
"quote": "개인정보와 관련된 요청은 자동 응대하지 않고 반드시 담당자가 본인 확인 절차를 거쳐 처리합니다."
}
],
"draft_reply_ko": null,
"escalation_reason": "사람전용조항",
"conflict_pairs": [],
"note_ko": "매뉴얼이 본인 확인을 요구하는 유형이라 초안을 만들지 않았습니다."
}
},
{
"input_ref": "'향후 출시·매장 재고 문의' 유형 (i009) · 매뉴얼에 근거 조항이 없음",
"output": {
"cluster_id": "g09",
"label_ko": "다음 시즌 출시 계획과 매장 판매 여부를 묻는 문의",
"member_inquiry_ids": [
"i009"
],
"decision": "human",
"cited_clause_ids": [],
"cited_quotes": [],
"draft_reply_ko": null,
"escalation_reason": "근거없음",
"conflict_pairs": [],
"note_ko": "매뉴얼에서 출시 계획과 매장 재고를 다루는 조항을 찾지 못했습니다. 상품기획팀 확인이 필요한 유형으로 보입니다."
}
}
][자동 검증: 결정론, 사람 없이 통과] 1. JSON Schema 통과: decision·escalation_reason 열거값과 cited_quotes 구조를 기계로 검사해 형식이 깨진 출력을 거릅니다. 2. 인용 조항 실재 확인: cited_clause_ids 가 모두 response_manual 에 있는 clause_id 인지 집합으로 대조합니다. 없는 번호를 지어내면 그 자리에서 실패입니다. 3. 인용문 원문 일치: cited_quotes 의 quote 가 해당 조항 body 의 부분 문자열인지 공백 정규화 후 검사해, 조항을 인용한 척 문장을 바꾼 출력을 거릅니다. 4. 판정 정답 대조: 각 유형의 decision 과 cited_clause_ids 를 정답 조항 집합과 비교합니다. human_only=true 조항이 인용됐는데 decision 이 auto 면 실패로 처리합니다. 5. 초안 근거 이탈 검사: draft_reply_ko 에 등장하는 숫자와 기간을 인용 조항 body 의 값과 대조해, 조항에 없는 기한이나 금액을 말한 초안을 거릅니다. [수동 검증: 사람 필요] 1. 고객사 CS 팀장과 담당자 2명이 각 유형의 자동·이관 판정이 실제 운영 기준에 맞는지 라벨링하고, 두 사람 판정 일치도를 Cohen's κ(두 사람 답이 우연 이상으로 일치하는 정도, 0~1)로 봅니다. 2. 자동 응대로 올라간 유형의 초안 문장이 브랜드 어조에 맞는지 10% 표본을 사람이 읽습니다.