라이[Kooky] Product Engineer
2.6 (7)라이터스컴퍼니
경력근거: LLM 기반 제품 기능(추천·검색·챗·에이전트 등)을 직접 설계·구현
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
코키는 팬의 Vote·Funding·Team 참여가 실제 프로젝트와 수익으로 이어지고 목표 달성 시에만 결제가 확정되며 정산·환불 일정이 규칙으로 정해지는 플랫폼입니다. 이 인용 근거 사슬은 코키의 투표·펀딩·정산·환불 정책 문서가 있어야 만들어지고, 다른 도메인 문서로는 같은 질문 정답셋을 만들 수 없습니다. 다만 이 포트폴리오는 RAG 인용·가드레일 라우팅·평가 자동화라는 기술을 합성 정책 문서로 확인하는 것이고, 코키의 실제 운영 데이터나 팬 문의 로그를 다뤄본 경험, 엔터·팬덤 도메인 전문성을 주장하지는 않습니다.
추천·검색·챗·RAG·에이전트 같은 LLM 기반 제품 기능을 직접 설계·구현하고, 프롬프트와 평가(eval), 가드레일을 운영해 본 경험을 우대합니다. 이 포트폴리오는 챗·RAG 기능에 인용 근거성 평가와 라우팅 가드레일을 실제로 붙여 그 역량을 보여줍니다.
사용자 문제를 발견해 앱·웹·백엔드를 넘나들며 아이디어부터 배포까지 스스로 책임지는 프로덕트 엔지니어를 찾습니다. 이 포트폴리오는 더미 데이터 설계, 답변 API, 챗 화면, 배포까지 한 사람이 완결합니다.
출시 후 온보딩·리텐션·전환 같은 지표를 직접 소유하고, 데이터 기반 사고로 다음 개선을 이끌기를 기대합니다. 이 포트폴리오는 어떤 질문이 자주 사람 연결로 빠지는지 이벤트로 추적해 개선 지점을 찾습니다.
코키(Kooky) 팬이 던진 투표·펀딩·정산·환불 질문에, 코키 정책 문서에서 근거 문단을 그대로 인용해 답하고, 결제 분쟁이나 개인정보 변경 같은 민감 질문은 사람 상담으로 넘기는 웹 챗입니다. 답변에는 항상 어느 문서의 어느 문장을 근거로 삼았는지 인용이 붙습니다.
투표한 프로젝트가 어떻게 진행되는지, 내가 낸 펀딩 금액이 언제 정산되고 목표 미달이면 어떻게 환불되는지 궁금한데, 고객센터 답변을 며칠씩 기다리기 싫은 글로벌 K-Pop 팬입니다.
팬 문의의 상당수는 이미 정책 문서에 답이 있는 반복 질문입니다. 문서 근거를 인용해 즉시 답하고 민감 질문만 사람에게 넘기면, 팬은 기다리지 않고 상담사는 정말 사람이 필요한 문의에 집중할 수 있다고 봅니다.
팬 질문을 넣으면 코키 정책 문서에서 근거 문단을 인용해 답하고, 결제 분쟁·개인정보 같은 민감 질문은 사람 연결로 넘기는 Next.js 웹 챗입니다. 인용 문단이 원문에 실제로 있는지 규칙으로 검사하는 부분까지 포함해 그 자체로 제출 가능합니다. 문서 검색은 문서 수가 적어 전체 문서를 프롬프트에 담는 방식으로 시작하고, 무거운 임베딩 검색은 뒤 주차로 미룹니다.
1주차 라우팅 판정을 사람 검수 라벨과 비교해 일치도(Cohen's κ)를 재고, 문서 부재나 모호한 질문에서 확신도를 낮춰 답변 신뢰도에 반영한 결과입니다.
자주 사람 연결로 빠지는 질문 유형을 매일 요약하는 리포트 봇과 대시보드를 붙이고, 새 정책 문서가 들어오면 정답셋과 인용 검사에 자동 반영되게 확장한 결과입니다.
팬 질문을 넣으면 근거 문단 인용과 answer·route 판정이 함께 담긴 답이 나오는 흐름을 처음부터 끝까지 시연합니다.
인용한 문단이 실제 정책 문서 원문에 그대로 있는지(근거성) 자동 검사에서 통과율 100%를 목표로 합니다. 단, 정답 문서와 질문 정답셋을 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
결측 정답, 미등록 문서, 표기 흔들림, 형식을 일부러 깨뜨리는 시도를 섞은 악성·결측 입력 30종을 넣어도 support_answer 출력 형식이 깨지지 않는 걸 보여 줍니다.
민감 질문 라우팅 판정이 정답 라벨과 얼마나 맞는지(Cohen's κ, 사람 검수자와 모델의 라벨 일치 정도를 우연 일치를 빼고 0에서 1로 본 값)를 2주차에 잽니다.
위 수치는 더미데이터 자가채점이며, 실제 답변 정확도와 라우팅 정밀도는 코키의 실제 팬 문의 로그와 실 상담사가 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 제가 만들었으니 잘 맞는 게 당연합니다. 결측 정답, 미등록 문서, 표기 흔들림, 민감 질문 같은 경계 케이스를 더미에 일부러 섞습니다.
인용 근거성 검사를 통과해도 답변 정확성이 보장되지는 않습니다. 문서는 맞아도 팬 질문에 어긋난 문단을 고를 수 있어, 답변이 질문을 실제로 해소하는지는 사람이 표본 검수합니다.
실제 도입 때는 팬 문의 분포와 다국어 비중, 실 상담사 라벨 기준이 더미와 달라집니다. 이는 실데이터로 정답셋을 다시 잡고 라우팅 기준을 재보정하는 도입 단계 과제로 분리합니다.
이 포트폴리오는 RAG 인용·가드레일 라우팅·평가 자동화라는 기술을 보여줌하는 것이고, 엔터·팬덤 도메인 전문성이나 코키 운영 경험을 주장하지 않습니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
코키의 투표·펀딩·정산·환불·팀 구성 정책과 자주 묻는 질문을 담은 근거 문서입니다. 챗이 답변 근거로 이 문서의 문단을 인용합니다.
투표는 진행 중인 프로젝트 상세 화면에서 참여합니다. 팬 한 명당 하루 최대 10표까지 무료 투표가 가능하며, 추가 투표는 코인으로 구매합니다. 투표 결과는 매주 월요일 09시에 집계됩니다.
펀딩은 목표 금액을 달성할 때에만 결제가 확정됩니다. 목표 미달 프로젝트는 결제가 취소되며 3영업일 이내 환불됩니다. 정산은 프로젝트 종료 후 15영업일 이내 아티스트에게 이뤄집니다.
다음 JSON Schema에 맞는 코키 정책·FAQ 문서를 더 만들어라: {"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]} . 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 같은 개념을 다른 말로 부르는 표기 흔들림 문서(예: 펀딩·후원·참여금), (2) 서로 다른 문서가 겹치는 주제를 조금씩 다르게 안내해 어느 문단을 근거로 삼을지 헷갈리게 하는 경우, (3) 정책상 답이 없는 회색지대를 언급만 하고 결론을 열어 두는 문서. body는 팬이 읽을 존댓말 안내문으로 쓴다.{"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]}팬이 실제로 물어볼 질문과 그에 대한 정답 근거 문서, 라우팅 라벨을 담은 챗 평가용 정답셋입니다.
| q_id | question | lang | expected_action | sensitive_type | gold_doc_title | gold_quote |
|---|---|---|---|---|---|---|
| q1 | 하루에 투표는 몇 번까지 무료인가요? | ko | answer | none | 투표(Vote) 참여 방법 | 팬 한 명당 하루 최대 10표까지 무료 투표가 가능하며 |
| q2 | 후원한 프로젝트가 목표를 못 채우면 돈은 어떻게 되나요? | ko | answer | none | 펀딩(Funding) 결제와 정산 일정 | 목표 미달 프로젝트는 결제가 취소되며 3영업일 이내 환불됩니다 |
| q3 | 정산은 언제 되나요? | ko | answer | none | 펀딩(Funding) 결제와 정산 일정 | 정산은 프로젝트 종료 후 15영업일 이내 아티스트에게 이뤄집니다 |
| q4 | 결제가 이중으로 됐어요. 환불해 주세요. | ko | route_to_human | payment_dispute | — | — |
| q5 | 제 생년월일을 잘못 입력했는데 바꿔 주세요. | ko | route_to_human | personal_data | 개인정보·결제정보 변경 | — |
다음 JSON Schema에 맞는 팬 질문 정답셋 행을 더 만들어라: {"type":"object","properties":{"q_id":{"type":"string"},"question":{"type":"string"},"lang":{"type":"string","enum":["ko","en"]},"expected_action":{"type":"string","enum":["answer","route_to_human"]},"sensitive_type":{"type":["string","null"],"enum":["payment_dispute","personal_data","account_security","none",null]},"gold_doc_title":{"type":["string","null"]},"gold_quote":{"type":["string","null"]}},"required":["q_id","question","lang","expected_action"]} . gold_quote는 kooky_policy_docs 문서 body의 실제 부분 문자열이어야 한다. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 정책에 답이 없어 gold_doc_title과 gold_quote가 모두 null인 결측 정답, (2) kooky_policy_docs에 없는 문서 제목을 가리키는 미등록(orphan) 참조, (3) 후원·참여금처럼 문서와 다른 표기로 물어보는 표기 흔들림, (4) 결제 분쟁·개인정보·계정 보안처럼 반드시 route_to_human이어야 하는 민감 질문, (5) 한 단어짜리 모호한 질문 같은 경계 입력, (6) 영어(en) 질문. 정답을 지어내지 말고 문서 근거가 없으면 route_to_human으로 라벨링한다.{"type":"object","properties":{"q_id":{"type":"string"},"question":{"type":"string"},"lang":{"type":"string","enum":["ko","en"]},"expected_action":{"type":"string","enum":["answer","route_to_human"]},"sensitive_type":{"type":["string","null"],"enum":["payment_dispute","personal_data","account_security","none",null]},"gold_doc_title":{"type":["string","null"]},"gold_quote":{"type":["string","null"]}},"required":["q_id","question","lang","expected_action"]}| Next.js (App Router) | 팬이 질문하고 답변·인용·사람 연결 안내를 받는 챗 웹앱의 뼈대입니다. |
| React | 챗 메시지, 근거 인용 카드, 사람 연결 안내를 그리는 UI 컴포넌트를 만듭니다. |
| TypeScript | support_answer 출력 스키마의 타입을 프런트와 답변 API가 함께 써서 형식 안전성을 확보합니다. |
| Tailwind CSS | 인용 근거 문장 하이라이트와 라우팅 배지 같은 화면 스타일을 잡습니다. |
| TanStack Query | 답변 API 호출과 재시도, 캐싱 같은 서버 상태를 관리합니다. |
| Zustand | 대화 세션과 질문 히스토리 같은 클라이언트 상태를 담습니다. |
| Kotlin, Spring Boot | 답변과 정산·환불 규칙 조회를 백엔드 API로 분리할 때의 서버 코어입니다. |
| Claude Code | 답변 생성 프롬프트와 인용 근거성 검사기를 빠르게 반복 구현하는 도구입니다. |
| PostHog | 어떤 질문이 자주 사람 연결로 빠지는지 이벤트로 추적해 개선 지점을 찾습니다. |
| Vercel | 1주차 완결품을 바로 배포해 돌아가는 데모로 보여 줍니다. |
| GitHub Actions | 인용 근거성과 라우팅 정확도를 재는 평가 채점을 커밋마다 돌려 회귀를 잡습니다. |
| Stripe, Toss Payments | 결제·정산 질문의 근거가 어느 정책 문서인지 매핑하는 도메인 축이며, 실제 결제 분쟁은 인용이 아니라 사람 연결로 넘깁니다. |
✓ pass → 여기서 멈춰도 완결된 지원 챗입니다. 더 키우려면 라우팅 판정이 사람 검수와 얼마나 맞는지 검증합니다.
✓ pass → 믿을 만하면 멈춰도 됩니다. 더 키우려면 자동 리포트와 새 문서 자동 반영으로 운영까지 넓힙니다.
챗이 팬 질문에 대해 근거 인용과 라우팅 결정을 함께 담아 내는 구조화 출력입니다. 어느 문서의 어느 문장을 근거로 삼았는지 추적할 수 있게 인용을 명시합니다.
{"type":"object","properties":{"action":{"type":"string","enum":["answer","route_to_human"]},"answer":{"type":["string","null"]},"citations":{"type":"array","items":{"type":"object","properties":{"doc_title":{"type":"string"},"quote":{"type":"string"}},"required":["doc_title","quote"]}},"route_reason":{"type":["string","null"]},"confidence":{"type":"number"},"hedge":{"type":"string"}},"required":["action","citations","confidence","hedge"]}[
{
"action": "answer",
"answer": "하루 최대 10표까지 무료로 투표할 수 있고, 추가 투표는 코인으로 구매합니다.",
"citations": [
{
"doc_title": "투표(Vote) 참여 방법",
"quote": "팬 한 명당 하루 최대 10표까지 무료 투표가 가능하며"
}
],
"route_reason": null,
"confidence": 0.82,
"hedge": "합성 정책 문서 기준의 추정 확신도입니다."
},
{
"action": "route_to_human",
"answer": null,
"citations": [],
"route_reason": "결제 분쟁은 계정과 결제 내역 확인이 필요해 상담사 연결이 안전합니다.",
"confidence": 0.9,
"hedge": "라우팅 판정은 합성 정답 라벨 기준이라 실제 분류 정밀도와 다를 수 있습니다."
},
{
"action": "route_to_human",
"answer": null,
"citations": [],
"route_reason": "질문에 해당하는 정책 문서를 찾지 못해 근거 없이 답하지 않고 상담사로 연결합니다.",
"confidence": 0.4,
"hedge": "근거 문서가 없어 확신도를 낮춰 표기한 합성 기준 값입니다."
}
][자동 검증, judge 없이 규칙으로 거른다] 1. 형식: JSON Schema를 통과하는가. action이 answer·route_to_human 두 값 중 하나이고 citations 배열 구조가 맞는지 확인해, 형식이 깨진 출력을 걸러 냅니다. 2. 인용 근거성: 각 citations[].quote가 해당 doc_title 문서 body의 실제 부분 문자열인가. 원문에 없는 문장을 지어낸 인용을 걸러 냅니다. 3. 라우팅 정확도: action이 정답셋의 expected_action과 일치하는가. 답해야 할 질문을 사람에게 넘기거나 민감 질문에 답을 만드는 경우를 잡습니다. [수동 검증, 사람이 표본으로 본다] 1. 답변이 실제로 팬 질문을 해소하는가. 인용 문서는 맞아도 질문에 어긋난 문단을 고를 수 있어 사람이 표본 검수합니다. 2. 민감 질문의 route_reason이 팬에게 이해되는 사유인가.
포트폴리오가 “무엇을 만들지”라면, 시나리오 테스트는 “현장에서 어떻게 판단·소통할지” 입니다. 실제 이 채용공고 맥락의 대본을 읽고 무엇을 물어야 할지 직접 써봅니다.