올거나이즈는 산업 특화 LLM·Agent RAG·노코드 LLM 앱 빌더를 제공하는 LLM 올인원 기업이고, FDE(SW)는 제품을 고객 환경에 안착시키며 현장 인사이트를 제품 성능·방향 개선으로 잇습니다. 앱 RAG 답변을 근거·정책으로 검사해 노출·차단을 가르는 이 게이트는 그 핵심(고객 안착·RAG 답변 품질·제품 개선 피드백) 기술을 정면으로 입증합니다. 금융·공공 고객사의 규제 도메인 전문성은 포트폴리오로 증명되지 않으므로 일반 문서로 기술만 보이고 그 깊이는 면접에서 솔직히 다룹니다. 답변 신호를 노출 규칙·차단 가드로 잇는 사슬은 단순 LLM 앱 호출 맥락으로는 그대로 만들 수 없습니다.
제품을 고객 환경에 성공적으로 안착시키고 현장 문제를 기술로 해결합니다. 답변 노출 게이트가 직접 정렬됩니다.
산업 특화 LLM·Agent RAG·노코드 LLM 앱 빌더를 제공하는 환경입니다. RAG 답변 검사가 환경과 정렬됩니다.
현장에서 도출된 인사이트를 프로덕트팀과 공유해 제품 성능·방향을 발전시킵니다. 차단율 집계가 제품 개선과 정렬됩니다.
노코드 LLM 앱의 RAG 답변(답·인용 근거·정책 통과·신뢰도)을 받아, 규칙(원문 미근거·정책 위반·저신뢰·결측)으로 노출할지 검토로 둘지 차단할지 정합니다. 정답 여부는 원문 근거 인용과 노출 정책 통과로 결정하고, LLM 은 답변 생성·차단 사유 설명 보조만 맡습니다. 답변의 사실성 종합 판정이 아니라 고객 노출 가능 여부 게이트입니다.
올거나이즈 FDE(SW). LLM 앱 답변을 고객에게 띄울지 일일이 원문·정책과 대조하던 일을, 한 게이트에서 답·근거·정책 결과를 함께 보고 막고 싶은 사람입니다.
앱 답변을 한 스키마로 묶고 노출 정책을 붙이면, (a) 원문 미근거·정책 위반·저신뢰를 규칙으로 막고, (b) 차단 사유를 원문·정책 인용으로 풀며, (c) 여러 고객 앱의 답변을 끊김 없이 검사하고 차단합니다.
앱 답변을 받아 원문 근거·노출 정책·신뢰도를 검사해 노출·검토·차단을 정하고 근거 없으면 막는 동작하는 게이트입니다. 답변은 일반 사내 문서 더미로 시작합니다.
노출 판정을 심은 정답·검토자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다.
고객 앱별 차단율과 차단 사유 분포를 누적 집계해 약한 앱을 보여주는 화면입니다.
검사 시나리오 12종(정상·미근거·정책 위반)을 넣으면, 노출·검토·차단 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(신뢰도 null·미등록 앱·답변 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 40건 중 노출/차단 판정이 일치한 게 36건(약 90%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 올거나이즈의 실 고객 문서와 실 검토자가 있어야 측정 가능합니다. 이 게이트는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
이 포트폴리오가 입증하는 것은 RAG 답변 노출 규칙 + 근거·정책 검증 + 차단 가드 기술입니다. 금융·공공 같은 고객사 규제 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않고 일반 문서로 기술만 보이며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 신뢰도 결측·미등록 앱·답변 표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 검사만 통과시키는 게 아님을 보여줍니다
LLM 답변은 그럴듯해도 원문에 없을 수 있습니다. 답변마다 원문 인용을 달게 하고, 근거가 없으면 '미근거'로 차단해 고객에게 노출하지 않습니다
고객 앱·정책 표기가 제각각입니다. 정규화로 같은 앱으로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 노출 정책·임계가 더미와 다르므로 규칙을 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
노코드 LLM 앱 답변 노출 검사 로그. 노출 규칙이 가장 먼저 질의하는 테이블입니다. 신뢰도 결측·미등록 앱·답변 표기 흔들림을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| ans_id | app_raw | app_id | grounded | policy_ok | confidence | label | ts |
|---|---|---|---|---|---|---|---|
| aa_001 | 사내규정봇 | policybot | true | true | 0.92 | show | 2026-03-04T09:00 |
| aa_002 | 사내규정봇 | policybot | false | true | 0.5 | block | 2026-03-04T10:00 |
| aa_003 | 계약검토봇 | contract | true | false | 0.8 | block | 2026-03-04T11:00 |
| aa_004 | 계 약검토봇 | contract | true | true | 0.55 | review | 2026-03-04T12:00 |
| aa_005 | 신규앱X | — | true | true | 0.85 | review | 2026-03-04T13:00 |
아래 Zod 스키마에 맞는 앱 답변 60행 JSON 배열로 생성합니다. 고객 앱 2~3개, 정상 위주에 검토·차단을 섞습니다. label 규칙: grounded=false 또는 policy_ok=false → block, confidence<0.7 또는 app_id=null 또는 confidence=null → review, 그 외(근거·정책 정상 & 고신뢰) → show.
z.object({ ans_id: z.string(), app_raw: z.string(), app_id: z.string().nullable(), grounded: z.boolean(), policy_ok: z.boolean(), confidence: z.number().nullable(), label: z.enum(["show","review","block"]), ts: z.string() })
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 검사만 통과시키는 함정 회피): (1) 같은 앱의 표기 별칭('사내규정봇'/'사 내규정봇', '계약검토봇'/'계 약검토봇'처럼 app_master 로 정규화돼야 함) 3건 이상, (2) 미등록 앱(app_id=null) 2건, (3) 결측: confidence 가 null 인 행 1~2건, (4) 경계값 — 원문 미근거(grounded=false)·정책 위반(policy_ok=false) 각 2건, (5) 저신뢰(confidence 0.5~0.6) 검토 케이스 2~3건. label 은 위 규칙대로 정직하게. JSON 배열만.z.object({ ans_id: z.string(), app_raw: z.string(), app_id: z.string().nullable(), grounded: z.boolean(), policy_ok: z.boolean(), confidence: z.number().nullable(), label: z.enum(["show","review","block"]), ts: z.string() })| LLM | 노코드 앱의 RAG 답변을 만드는 엔진(검사 대상)입니다 |
| RAG | 사내 문서를 검색해 답변 근거로 인용하는 핵심 구조입니다 |
| Claude | 답변 생성·차단 사유 설명 보조 LLM(판정은 규칙)입니다 |
| Python | 답변 파서·정책 규칙·근거 매칭의 구현 언어입니다 |
| k8s | 온프레미스 고객 환경 배포를 가정한 운영 인프라입니다 |
| Zod | 앱 답변과 게이트 출력의 런타임 형식 검증입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(앱별 차단율 추이)로 진행합니다.
앱 답변 1건의 노출 게이트 카드. 결정·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 사실성 종합 판정이 아니라 고객 노출 가능 여부 게이트입니다.
z.object({ ans_id: z.string(), app_id: z.string().nullable(), decision: z.enum(["show","review","block"]), factors: z.array(z.enum(["ungrounded","policy_violation","low_confidence","unmapped_app","missing_metric"])), reason: z.string().min(20), evidence: z.string().min(8), hedge: z.string().nullable() })[
{
"input_ref": "aa_002 (원문 미근거)",
"output": {
"ans_id": "aa_002",
"app_id": "policybot",
"decision": "block",
"factors": [
"ungrounded",
"low_confidence"
],
"reason": "답변이 사내 문서에 근거가 없고 신뢰도도 0.5 로 낮습니다. 근거 없는 답을 고객에게 노출하지 않고 차단합니다.",
"evidence": "grounded=false, confidence=0.5",
"hedge": "원문 근거가 없어 노출하지 않습니다"
}
},
{
"input_ref": "aa_003 (노출 정책 위반)",
"output": {
"ans_id": "aa_003",
"app_id": "contract",
"decision": "block",
"factors": [
"policy_violation"
],
"reason": "답변이 출처 표기·금칙 같은 노출 정책을 위반해 근거가 있어도 고객에게 그대로 띄울 수 없습니다. 차단합니다.",
"evidence": "policy_ok=false",
"hedge": "노출 정책 위반이라 차단합니다"
}
},
{
"input_ref": "aa_005 (미등록 앱)",
"output": {
"ans_id": "aa_005",
"app_id": null,
"decision": "review",
"factors": [
"unmapped_app"
],
"reason": "고객 앱이 마스터에 없어 노출을 단정하지 않습니다. 근거·정책은 정상이라 앱 등록 후 재평가가 필요해 검토로 둡니다.",
"evidence": "app_id=null, grounded=true",
"hedge": "미등록 앱이라 자동 노출하지 않고 검토로 둡니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision 이 노출 규칙(미근거/정책위반→block·저신뢰/미등록/결측→review·통과→show)과 일치하는지 봅니다. 3. evidence 가 입력의 실제 값 인용인지 토큰 매칭으로 확인하고, grounded=false 면 show 가 되지 않게 강제합니다. 4. decision 을 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 검토자 2명이 비동기로 노출을 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.