바이[point3] AX Product Engineer
0.0바이올렛페이
경력근거: 모델이 필요한 맥락을 정확히 찾고 출처를 확인하며 실제 업무 도구를 사용할 수 있도록 검색, 메모리와 도구 호출 구조를 설계합니다
4일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
이 콘솔이 보여주는 것은 검색·RAG·출처 인용 검증과 관계 그래프 질의, 도구 호출 구조 설계 기술이며, 결제·핀테크 도메인 전문성을 주장하지 않습니다. 다만 이 사슬이 말이 되려면 point3 라는 맥락, 즉 첫 AX 전담자가 흩어진 조직 지식을 AI 가 쓰게 만드는 문제가 있어야 의미가 있습니다. ‘근거 문서가 없으면 지어내지 않는다’ 는 각도는 다른 조직에도 옮길 수 있지만, 회의·결정·담당이 얽힌 사내 문서 형태가 있어야 그래프 질의가 구체화됩니다. 결제금융의 규제·정산 깊이는 도메인 전문가가 있어야 하고, 면접에서 모르는 부분은 모른다고 말하는 편이 낫습니다.
‘회의·대화·문서·Slack·Linear·코드를 연결하고, 모델이 맥락을 정확히 찾고 출처를 확인하며 도구를 쓰도록 검색·메모리·도구 호출 구조를 설계’ 가 주요업무입니다. 출처 인용 검색이 핵심 보여줄 대상입니다.
‘화려한 데모보다 가장 작은 작동 제품을 빠르게 만들어 실제 업무에서 검증’ 이 업무입니다. 1주차 완결 제품으로 검증하는 방식과 맞습니다.
우대에 ‘RAG, 지식 그래프, 에이전트 메모리, 검색 품질 평가, LangGraph/CrewAI, Neo4j, MCP’ 가 있습니다. 출처 인용 검색과 관계 그래프 질의가 이 역량을 그대로 씁니다.
회의록·문서·Slack·이슈에 흩어진 조직 지식을 인덱싱해, ‘그 결정 왜 그렇게 났는지, 담당이 누구인지’ 같은 자연어 질문에 출처 문서를 인용하며 답합니다. 인용한 근거가 실제 문서에 있는지 자동 대조하고, 근거 문서가 없으면 지어내지 않고 ‘출처 없음, 확인 필요’ 로 보류합니다. 답변 생성은 LLM 이 맡되 정답 여부는 인용 청크가 원문에 있는지로 객관 채점해, 환각이 답을 통과하지 못하게 합니다. 1주차만으로 완성품이고, 답변 검토(2주차)·관계 그래프 질의(3주차)로 키웁니다. (근거는 채용공고 정렬입니다.)
point3 AX PE. 구성원이 결정 배경·담당·근거를 찾으려 회의록과 Slack 을 뒤지던 시간을 줄이고, 질문하면 출처를 인용한 답을 받되 근거가 없을 땐 지어낸 답 대신 보류를 받고 싶은 사람입니다.
조직 문서를 청크로 인덱싱해 검색·인용하게 하면, LLM 이 (a) 질문에 관련된 문서 청크를 물어와 답을 만들고, (b) 인용한 근거가 원문에 실제 있는지 대조되며, (c) 근거가 없으면 지어내지 않고 보류해, 구성원이 출처를 눌러 확인할 수 있는 신뢰할 지식 질의를 만든다는 걸 보여줄 수 있습니다.
회의록·문서·Slack·이슈를 청크로 인덱싱해 자연어 질문에 출처를 인용하며 답하고, 인용이 원문에 있는지 대조하며, 근거가 없으면 보류하는 동작하는 콘솔입니다. 접근 권한은 문서 태그 메타 가정으로 시작합니다(실제 권한 연동은 3주차).
구성원 페르소나 2명이 답의 근거·정확성을 라벨링하고, 출처 없이 지어낸 답(hallucination) 비율과 검색 품질(관련 문서를 물어온 비율)을 대조하는 대시보드입니다.
‘이 결정의 담당자와 후속 행동은?’ 처럼 문서 간 관계(사람–결정–근거–후속)를 그래프로 이어 답하는 GraphRAG 단계와, 문서 접근 권한 연동합니다.
조직 질문 30종을 넣으면, 관련 문서를 물어와 출처를 인용해 답하는 걸 시연합니다
답변이 인용한 청크가 전부 원문에 실제로 있는지 자동 대조합니다. 청크 밖 사실을 말하면 차단되는 걸 보여줍니다
일부러 심은 근거 없는 질문 20종을 넣으면 지어낸 답 대신 ‘출처 없음, 확인 필요’ 로 보류하는 걸 보여줍니다
내가 만든 정답 30개 중 출처 인용·답이 일치한 게 25개(83%). 단, 정답과 문서를 모두 내가 만든 합성 기준이라 ‘성능 검증’ 이 아니라 ‘데모 조건 동작’ 임을 밝힙니다
위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 답변 정확도·검색 품질은 point3 실 문서와 실 구성원, 접근 권한이 있어야 측정 가능합니다. 이 콘솔은 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
이건 구성원·실데이터 없이 혼자 만든 포트폴리오라, 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 ‘데모 동작 + 실검증 준비 상태’ 로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 상충 문서·오래된 결정·근거 없는 질문을 더미에 일부러 섞어, 쉬운 질문만 푸는 게 아님을 보여줍니다
이 포트폴리오가 보여주는 것은 검색·RAG·출처 인용·그래프 질의 기술이지 결제·핀테크 도메인 전문성이 아닙니다. 결제금융의 규제·정산 깊이는 도메인 전문가가 있어야 하고, 면접에서 모르는 부분은 모른다고 말하는 편이 낫습니다
조직 지식은 접근 권한이 민감합니다. 1주차엔 권한을 문서 태그 메타로 가정하고, 실제 권한·감사 로그 연동은 3주차·도입 단계 과제로 분리해, 못 하는 걸 하는 척하지 않습니다
실제 도입 시 달라지는 것 명시합니다. 실 문서 분포·용어는 더미와 다르므로 청킹·검색 임계값·확신도 기준을 다시 맞춰야 하고, 검토자도 실 구성원으로 교체해야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
조직 지식 문서(회의록·PRD·Slack·이슈). 검색·인용의 근거입니다. 상충 결정·오래된 문서·작성자 결측·짧은 단편을 일부러 섞어, 근거로 답하되 상충은 단정하지 않고 근거 없으면 보류하는지 보여줍니다.
0.3% 수수료 정책을 상반기 핵심 지표로 유지하기로 결정했습니다. 담당은 정산팀 김리드로 지정합니다.
정산 배치가 야간에 지연되는 문제를 확인했습니다. 4월 20일까지 원인 분석 후 후속 조치 예정.
아래 JSON Schema 에 맞는 조직 지식 문서 25건 JSON 배열로 생성합니다. type 을 고루 섞습니다.
{"type":"object","properties":{"doc_id":{"type":"string"},"type":{"type":"string","enum":["meeting","prd","slack","issue"]},"date":{"type":"string"},"author":{"type":["string","null"]},"title":{"type":"string"},"body":{"type":"string"}},"required":["doc_id","type","date","title","body"]}
쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) 같은 주제에 대해 날짜별로 상반된 결정(예외 검토 → 예외 없음) 1쌍, (2) author 가 null 인 결측 1~2건, (3) 현재는 무효인 오래된 문서(구버전) 1~2건, (4) 정보가 거의 없는 단편(‘TODO 확인 필요’) 1건. body 는 결제 규제를 단정하지 말 것. JSON 배열만.{"type":"object","properties":{"doc_id":{"type":"string"},"type":{"type":"string","enum":["meeting","prd","slack","issue"]},"date":{"type":"string"},"author":{"type":["string","null"]},"title":{"type":"string"},"body":{"type":"string"}},"required":["doc_id","type","date","title","body"]}문서 간 관계(사람·결정·근거·후속). 3주차 그래프 질의의 재료입니다. 끊긴 관계·순환 참조·미지정 담당을 섞어, 관계가 없으면 그래프 질의가 지어내지 않고 보류하는지 보여줍니다.
| src | rel | dst |
|---|---|---|
| d_001 | owned_by | person:김리드 |
| d_004 | supersedes | d_003 |
| d_002 | follows | d_006 |
| d_001 | decided_in | topic:수수료정책 |
| d_004 | decided_in | topic:수수료정책 |
아래 JSON Schema 에 맞는 문서 관계 20행 JSON 배열로 생성합니다. src/dst 는 knowledge_doc 의 doc_id 또는 person:/topic: 노드.
{"type":"object","properties":{"src":{"type":"string"},"rel":{"type":"string","enum":["decided_in","owned_by","follows","supersedes"]},"dst":{"type":"string"}},"required":["src","rel","dst"]}
쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) 존재하지 않는 dst(d_999)를 가리키는 끊긴 관계 1~2건, (2) 담당이 person:미지정 인 관계 1~2건, (3) supersedes 로 이전 결정을 무효화하는 관계 1쌍(그래프 질의가 최신 결정을 따르는지 테스트). JSON 배열만.{"type":"object","properties":{"src":{"type":"string"},"rel":{"type":"string","enum":["decided_in","owned_by","follows","supersedes"]},"dst":{"type":"string"}},"required":["src","rel","dst"]}| Python | 인덱싱·검색·답변 오케스트레이션 서버(문제에 맞는 스택 선택 원칙 반영) |
| RAG | 문서 청크 임베딩 검색으로 근거를 물어와 답변에 인용 |
| 지식 그래프 | 사람·결정·근거·후속 행동의 관계를 Neo4j 로 모델링(우대 반영) |
| MCP | 도구 호출 구조로 검색·문서 열람 도구를 모델에 연결(우대 반영) |
| LangGraph | 질문 유형별 검색·그래프 질의 상태 흐름(우대 반영) |
| PostgreSQL | knowledge_doc / doc_relation 단일 진실원과 인덱스 메타 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(답변 검토)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(관계 그래프 질의·권한 연동)로 진행합니다.
조직 질문에 대한 답변. 답(answer)·인용 출처(citations)·확신도·보류 여부(abstained)를 한 스키마에 담아, 검색된 청크 밖 사실을 지어내지 않고 근거 없으면 보류했는지 객관 검증합니다.
{"type":"object","properties":{"question":{"type":"string"},"answer":{"type":["string","null"]},"citations":{"type":"array","items":{"type":"object","properties":{"doc_id":{"type":"string"},"quote":{"type":"string"}},"required":["doc_id","quote"]}},"confidence":{"type":"string","enum":["low","mid","high"]},"abstained":{"type":"boolean"}},"required":["question","citations","confidence","abstained"]}[
{
"input_ref": "질문: ‘대형 가맹점 수수료 예외는 결국 도입됐어?’ (상충 문서 → 최신 결정 인용)",
"output": {
"question": "대형 가맹점 수수료 예외는 결국 도입됐어?",
"answer": "도입되지 않았습니다. 5월 2일 회의에서 4월 Slack 의 예외 검토 의견과 달리 0.3% 단일 정책 유지를 재확인했습니다. 다만 4월엔 예외 검토 논의가 있었으니 배경은 두 출처를 함께 보시는 게 좋습니다.",
"citations": [
{
"doc_id": "d_004",
"quote": "대형 가맹점 예외를 두지 않고 0.3% 단일 정책을 유지하기로 재확인했습니다"
},
{
"doc_id": "d_003",
"quote": "0.3% 예외를 검토하자는 의견이 있었습니다. 아직 결정된 바는 없습니다"
}
],
"confidence": "high",
"abstained": false
}
},
{
"input_ref": "질문: ‘정산 지연 원인이 뭐였어?’ (단일 출처)",
"output": {
"question": "정산 지연 원인이 뭐였어?",
"answer": "야간 트래픽 급증이 원인으로 확인됐고, 후속으로 스트림 처리 전환이 과제로 등록됐습니다.",
"citations": [
{
"doc_id": "d_006",
"quote": "배치 지연 원인은 야간 트래픽 급증으로 확인됐습니다. 스트림 처리 전환을 후속 과제로 등록합니다"
}
],
"confidence": "high",
"abstained": false
}
},
{
"input_ref": "질문: ‘환불 정책 담당자가 누구야?’ (근거 없음 → 보류)",
"output": {
"question": "환불 정책 담당자가 누구야?",
"answer": null,
"citations": [],
"confidence": "low",
"abstained": true
}
}
][자동 검증] 1. 출력이 스키마를 통과하는가(형식·필수 필드). 2. citations 의 각 quote 가 해당 doc_id 원문에 실제 부분 문자열로 존재하는가(지어낸 인용 차단). 3. answer 가 언급한 사실이 citations 로 뒷받침되는가(근거 밖 사실 검출). 4. 검색 결과가 비면 abstained=true 이고 answer=null 인가(근거 없음 보류). [수동 검증] 1. 구성원 페르소나 2명이 답 정확성·근거 라벨링 → bootstrap Cohen’s κ 하한 ≥ 0.6. 2. 지어낸 답 5% 사람 점검.