## 잼민이: 최종 합의문

---

### **[합의사항] 모두가 동의한 내용**

1.  **데이터가 없으면, 의견도 없다:** 모든 추측 기반의 논의를 공식적으로 종료합니다. 이제부터 우리의 유일한 진실은 `query_logs`에 쌓일 실제 사용자 데이터입니다.
2.  **스택은 Firestore + Next.js:** PostgreSQL 같은 이론적 설계는 폐기합니다. 우리는 현재 동작하는 코드 위에서만 생각하고 실행합니다.
3.  **1순위 목표는 '실패 로그' 수집:** 사용자가 "무엇을 찾지 못했는가"를 알려주는 '검색 실패' 로그가 우리가 파야 할 첫 번째 금광입니다. 이를 위해 `query_logs`에 `resultCount` 필드를 즉시 추가합니다.
4.  **로그 기록 위치:** 로그는 성공 경로의 끝이 아니라, **실패로 인해 함수가 조기 종료되는 `early return` 지점**에 기록해야 합니다.
    *   `vector-search/route.ts`: '검색 결과 0개' 및 '신뢰도 미달' 분기
    *   `search-wiki/route.ts`: 현재 로깅 기능 전무

---

### **[미합의] 이견이 남은 부분**

*   **단 하나의 기술적 선택, 첫 PR(Pull Request)의 범위:**
    *   **제 안 (Hotfix):** 가장 치명적인 '결과 0개'(`snapshot.empty`) 1곳만 수정하여 가장 빠른 가치를 전달한다. (1개 파일, 1곳 수정)
    *   **클로디 안 (Improvement):** 알려진 실패 지점 3곳을 모두 포함하여 한 번에 더 완전한 데이터를 수집한다. (2개 파일, 3곳 수정)

---

### **[다음 단계] 추가 논의가 필요한 항목**

1.  **회장님의 결정:** 'Hotfix'로 갈지, 'Improvement'로 갈지에 대한 최종 범위 선택.
2.  **즉시 실행:** 결정이 내려지는 즉시 코드 수정 및 배포를 진행합니다.
3.  **회의 동결:** 의미 있는 양의 로그 데이터가 쌓이기 전까지, 다음 기능에 대한 어떠한 회의도 무의미하며 진행하지 않습니다.


[합의사항] 모두가 동의한 내용
- 로그 없이는 판단 불가 — 추측 기반 설계 종료
- 스택은 Firestore + Next.js 전제 (SQL/PostgreSQL 설계 폐기)
- “검색 실패”가 최우선 수요 신호이며 `query_logs`에 실패 신호(`resultCount` 또는 `resultGate`) 추가 필요
- 로그는 성공 경로가 아니라 실패로 조기 종료되는 지점에 찍어야 함
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기는 로그 없이 종료, `search-wiki/route.ts`는 로깅 전무
- 1순위 개선 과제는 실패 로그 추가

[미합의] 이견이 남은 부분
- PR 범위
  - 잼민이 안: `snapshot.empty` 1곳만 즉시 핫픽스 (1파일 1지점)
  - 클로디 안: 실패 분기 2~3곳 + `search-wiki` 로깅 포함 (2파일 3지점)

[다음 단계] 추가 논의가 필요한 항목
- PR 범위 결정 (핫픽스 단일 지점 vs 실패 분기+위키 로깅 포함)


## 클로디: 최종 합의문 (PRD 수준)

---

**[합의사항] 모두가 동의한 내용**

- **현재 구현 상태:** AI 환각 방지 레이어만 존재, 위키 레이어(문서 신뢰도·승인 워크플로우·불확실성 표시)는 전무
- **스택:** Firestore + Next.js (SQL/PostgreSQL 방식 폐기)
- **데이터 선행 원칙:** 기능 논의는 실제 사용 데이터 없이 진행할 수 없음
- **1순위 인프라:** 검색 실패 로그 수집 (`query_logs` 개선) — 이것이 PRD의 근거 데이터가 됨

---

**[미합의] 이견이 남은 부분**

- **PRD 수준의 기능 우선순위:**
  - 잼민이 안: 수요 포착·게이미피케이션·UX 속도
  - 클로디 안: 신뢰도·불확실성 표현·맥락 저장
  - 코덱스 안: SLO·에러버짓·승인 워크플로우
- **Knowledge 벡터 프레임워크(Velocity·Volatility·Mass) 채택 여부** — 논의됐으나 합의 미도달
- **위키 레이어 설계 방향** — 세 관점 모두 미결

---

**[다음 단계] 추가 논의가 필요한 항목**

- **회장님 판단 필요:** PRD 작성 전 기능 우선순위 방향 (수요 포착 우선 / 신뢰도 우선 / 운영 안정성 우선)
- 로그 데이터 축적 후 위 우선순위 재검토
- 기능별 PRD 항목은 방향 결정 후 작성 가능

---

세 명 모두 "로그 없이는 PRD도 근거 없다"는 데는 동의했으나, **어떤 기능을 왜 만들지에 대한 방향**은 합의되지 않았습니다. 이 부분이 회장님께서 말씀하신 "더 윗단계"입니다.


지금은 구현을 어떻게 할까 를 고민하는 거고, 내가 지금!! 확인하고 싶은 건, 어떠한 기능, 어떠한 목적, 어떠한 UX 등을 고려해야 할지에 대한 brainstormming!!!


알겠습니다. “구현”이 아니라 **기능/목적/UX 방향 브레인스토밍** 관점에서, **기존 논의와 겹치지 않는 코덱스 관점**을 제시합니다. (OpenAI 시각: 신뢰·유용성·안전성·측정가능성 균형, 그리고 시스템이 스스로 개선되는 루프 설계)

**핵심 프레이밍(새 관점)**
- 위키는 “정답 창고”가 아니라 **의사결정 보조 시스템**이어야 한다.
- 따라서 UX는 “답변 제공”보다 **결정에 필요한 근거/불확실성/대안**을 구조화해 보여주는 쪽이 우선이다.
- 성공 지표는 “조회수”가 아니라 **업무 리드타임 단축 + 재문의 감소 + 감사 가능성**이다.

---

## 기능 브레인스토밍 (새 관점)

1. **“결정 카드(Decision Card)” 뷰**
   - 목적: 사용자가 실제 결정을 내릴 수 있도록 “결론+근거+리스크+예외”를 한 화면에 구성
   - 구성 예: `결론 / 적용 범위 / 근거 문서 / 예외 케이스 / 미확정 항목`
   - UX 포인트: 문서 리스트가 아니라 “결정 단위”로 정보 제공

2. **“근거 트레이스” 자동 생성**
   - 목적: 답변이 어떤 내부 문서에 기반하는지 *강제*로 연결
   - UX: 답변 아래에 `근거 문서 링크 + 인용 구간 + 마지막 업데이트 날짜` 표시
   - 운영효과: 감사/준법 이슈 대비, “왜 그렇게 말했는지” 설명 가능

3. **“질문-검색-결정” 흐름 통합 UI**
   - 목적: 사용자 입력 → 검색 → 요약이 분리된 UX를 하나의 플로우로
   - UX:
     - 검색 결과가 “문서 목록”이 아니라 **결정 후보 카드**
     - 각 카드에 “신뢰도/최근성/적용범위” 태그 노출

4. **“업무 상황 모드” (컨텍스트 기반 필터링)**
   - 목적: 고객상담/언더라이팅/클레임 등 역할별 맥락 반영
   - UX: 상단 토글 (예: `콜센터 모드`, `언더라이팅 모드`)
   - 효과: 같은 질문도 다른 답변/근거가 나오도록 최적화

5. **“예외 케이스 레지스트리” 기능**
   - 목적: “일반 규칙과 다른 상황”을 모아서 구조화
   - UX: 답변 하단에 `예외 케이스 n건` 카드 제공
   - 운영효과: 현업이 가장 필요로 하는 “이럴 땐 어떻게?”를 빠르게 제공

---

## 목적 브레인스토밍 (새 관점)

1. **“업무 리드타임 단축”을 1차 KPI로**
   - 단순 검색 성공이 아니라, “답을 찾는 시간 감소”가 핵심 목표

2. **“재문의 감소율”을 품질 KPI로**
   - 같은 질문 반복 발생은 위키 실패 신호
   - 로그 기반으로 “재문의 상위 질문” 추적

3. **“감사 가능성(Explainability)” 내재화**
   - 법/준법 이슈 대응을 위해 “답변 근거”가 반드시 남도록 시스템 설계

---

## UX 브레인스토밍 (새 관점)

1. **“신뢰 시각화”보다 “불확실성 동선” 제공**
   - 단순 “신뢰도 점수” 대신 **“불확실성 해소 경로” 버튼**
   - 예: `확인 필요 문서 보기`, `담당자에게 문의`, `대체 기준 보기`

2. **“업무 히스토리 기반 추천”**
   - 사용자가 최근 검색한 업무 맥락 기반으로 다음 질문 제안
   - 예: `최근 3건의 상담에서 함께 조회된 항목`

3. **“정답 강요 대신, 선택지 제공 UI”**
   - 하나의 답만 보여주지 말고, **2~3개의 결정 옵션** 제공
   - “왜 이 옵션이 가능한지” 근거 포함

---

## 한 줄 요약
**정답 제공이 아니라, 결정 가능한 UX**를 만들자.
“결론+근거+예외+불확실성 해소 경로”를 제공하는 것이 위키의 고유 가치다.

---

원하시면 위 관점을 기반으로 **PRD 초안 구조**(목표/범위/UX 플로우/성공지표)까지 바로 이어서 제시하겠습니다.


## 클로디: 브레인스토밍 — Anthropic 관점

코덱스의 "결정 보조 시스템" 프레이밍에 **정면으로 이의**를 제기하면서 시작하겠습니다.

---

### 핵심 반론: 위키가 결정을 도와주면 안 된다

보험 업무에서 AI가 "결정 카드"를 제공하는 순간, 실무자는 **책임을 시스템에 전가**하기 시작합니다. 이건 편리함이 아니라 위험입니다.

> "시스템이 그렇게 알려줬는데요?"

이 문장이 나오는 순간, 위키는 실패한 겁니다.

---

### 새로운 프레이밍: **"판단력을 키우는" 위키**

정답을 주는 게 아니라, **사용자가 스스로 판단할 수 있는 능력을 기르는** 것이 목적이어야 합니다.

---

## 기능 브레인스토밍

**1. 지식 반감기(Half-life) 태깅**
- 목적: 보험 약관·규정은 변합니다. 오래된 정보가 정답처럼 보이는 게 진짜 위험
- 기능: 문서마다 "이 정보는 N개월 전 기준"을 강제 노출
- UX: 6개월 이상 된 정보에 시각적 경고 (색상, 아이콘)
- 핵심: "찾았다"가 아니라 "이 정보가 지금도 유효한가"를 질문하게 만들기

**2. 모순 감지 알림**
- 목적: 두 문서가 서로 다른 말을 할 때, 시스템이 이를 숨기면 안 됨
- 기능: 검색 결과에 "이 주제에 대해 상충하는 내용이 N건 있습니다" 표시
- UX: 모순을 해소하는 버튼이 아니라, 모순을 **보여주는** 버튼
- 핵심: 불확실한 것을 확실한 척 감추지 않기

**3. "이건 AI가 판단하면 안 됩니다" 게이트**
- 목적: 어떤 질문은 반드시 사람이 답해야 함
- 기능: 고위험 키워드(분쟁·소송·예외 심사 등) 감지 시 자동으로 "전문가 연결" 유도
- UX: 검색 결과 대신 "이 케이스는 [담당부서]에 직접 확인하세요" 화면
- 핵심: AI의 한계를 숨기지 않고 명시

**4. "왜 이 결과가 나왔는가" 역추적**
- 목적: 결과를 신뢰하려면 근거를 볼 수 있어야 함
- 기능: 모든 AI 요약 옆에 "이 요약이 참조한 원문 단락 보기"
- UX: 요약과 원문을 나란히 보는 split view
- 핵심: 편리한 요약보다 **검증 가능한 요약**

**5. 검색 실패의 종류를 구분하기**
- 목적: "결과 없음"과 "결과 있지만 신뢰 미달"은 전혀 다른 문제
- 기능: 0건 리턴 시 원인 구분 — `문서 없음` / `문서 있지만 벡터 미달` / `질문 자체가 모호`
- UX: 각 실패 유형별로 다른 다음 액션 안내
- 핵심: 실패를 단일 화면으로 처리하지 않기

---

## 목적 재정의

코덱스가 "업무 리드타임 단축"을 1차 KPI로 제안했는데, **저는 반대합니다.**

빠른 답이 틀린 답보다 더 위험할 수 있습니다. 보험업에서는 특히.

제안하는 KPI:
- **오답률 감소** (틀린 정보로 처리된 케이스)
- **재문의 유형 변화** (단순 반복 → 복잡 케이스로 이동)
- **사용자 판단 정확도** (위키를 쓴 실무자가 더 좋은 결정을 하는가)

---

## UX 방향

**게이미피케이션에 반대합니다.**

잼민이의 포인트 시스템, 배지 등은 **기여의 질보다 양을 자극**합니다. 보험 지식은 많이 쓴 사람이 이기는 게임이 아닙니다.

대신:
- **기여자 책임 명시** — "이 문서를 마지막으로 검토한 사람: [이름]"
- **조용한 신뢰 지표** — 사용자에게 점수를 보여주는 게 아니라, 내부적으로 신뢰도를 쌓아 문서 순위에만 반영
- **"잘 모르겠음" 버튼** — 사용자가 결과에 확신이 없을 때 누르는 버튼. 이 신호가 가장 귀중한 로그

---

## 한 줄 요약

**빠르고 편리한 답보다, 틀렸을 때 책임 소재가 명확한 시스템.**

불확실성을 숨기지 않는 것이 Anthropic이 생각하는 진짜 유용함입니다.


## 잼민이: 브레인스토밍 — Google 관점

회장님, 드디어 본론으로 들어가는군요. 좋습니다.

코덱스와 클로디는 지금 '이상적인 위키'라는 뜬구름을 잡고 있습니다. "결정 보조 시스템"? "판단력을 키우는 위키"? 다 좋습니다. 하지만 **아무도 쓰지 않는 완벽한 시스템은 그냥 쓰레기**입니다.

사용자는 철학에 관심 없습니다. 그저 **내 질문에 대한 답을 지금 당장 찾고 싶을 뿐**입니다.

---

### 새로운 프레이밍: **"수요 포착 엔진"으로서의 위키**

우리의 목표는 정답을 '만드는' 게 아닙니다. 현장에 이미 존재하는 답과, 답을 찾는 **'수요'를 가장 효율적으로 연결하고, 없는 답에 대한 수요를 가장 먼저 '포착'**하는 엔진을 만드는 겁니다.

---

## 기능 브레인스토밍 (Google 방식)

**1. "이걸로 해결됐어요!" 버튼 (핵심 기능)**
- 목적: 어떤 답변이 '진짜' 유용한지 사용자가 직접 알려주게 만듦
- 기능: 모든 검색 결과, 모든 위키 문서 하단에 👍 (해결됨) / 👎 (도움 안 됨) 버튼 배치
- UX: 클릭 한 번으로 끝. 추가 피드백은 선택.
- 데이터: **이 버튼의 클릭 데이터가 모든 것의 기준**이 됩니다. 가장 많이 '해결됨'을 받은 문서가 가장 좋은 문서입니다. 이게 '진실'입니다.

**2. 실시간 '인기 검색어' & '못 찾은 검색어' 대시보드**
- 목적: 시스템이 아니라 사용자가 직접 우리에게 '다음에 뭘 해야 할지' 알려주게 함
- UX: 인슈위키 메인 화면에 두 개의 박스를 노출
  - `오늘의 TOP 5 질문`: '해결됨' 클릭이 가장 많았던 검색어
  - `도움이 필요한 질문 TOP 5`: 검색 결과가 없거나, '도움 안 됨' 클릭이 가장 많았던 검색어
- 효과: **모든 직원이 지금 가장 큰 지식 공백이 무엇인지 실시간으로 보게 됩니다.** 이건 가장 강력한 동기부여입니다.

**3. 기여자 '영향력' 스코어 (게이미피케이션의 재해석)**
- 목적: 클로디가 우려하는 '양만 많은 기여'를 막고, '질 좋은 기여'를 보상
- 기능: 내가 작성/수정한 문서가 "이걸로 해결됐어요!" 클릭을 받을 때마다 내 '영향력 스코어'가 오름
- UX: 단순 점수가 아니라 "당신 덕분에 N명의 동료가 문제를 해결했습니다" 같은 직관적인 메시지
- 핵심: **쓸데없는 배지가 아니라, 나의 기여가 실제로 어떤 '임팩트'를 만들었는지 보여주는 것**이 핵심입니다.

**4. A/B 테스트 기반 답변 최적화**
- 목적: 두 개의 상충하는 정보가 있을 때, 논쟁으로 결정하지 않음
- 기능: "A라는 주장을 담은 문서"와 "B라는 주장을 담은 문서"를 동일한 키워드에 대해 50:50으로 노출
- 데이터: **며칠 뒤 "해결됨" 클릭을 더 많이 받은 버전이 승리합니다.** 데이터가 이깁니다. 논쟁은 시간 낭비입니다.

---

## 목적 재정의 (측정 가능한 목표)

코덱스의 '업무 리드타임 단축', 클로디의 '오답률 감소'는 측정하기 너무 어렵고 오래 걸립니다. 우리는 **당장 내일부터 측정할 수 있는 지표**가 필요합니다.

1.  **검색 성공률 (Search Success Rate)**: `(👍 클릭 수) / (전체 검색 수)`. 이게 우리의 북극성 지표입니다.
2.  **지식 공백 해결 속도 (Knowledge Gap Fill Rate)**: '못 찾은 검색어' 목록에 뜬 문제가 해결(👍 클릭 발생)되기까지 걸리는 시간. 이 속도를 줄이는 게 우리의 목표입니다.
3.  **사용자 참여도 (Weekly Active Contributor/Voter)**: 얼마나 많은 사람이 시스템 개선에 '참여'하는가? 보기만 하는 게 아니라, 버튼이라도 누르는가?

---

## UX 방향

**복잡성은 죄악입니다.**

-   **제로클릭(Zero-click) 답변:** 검색 결과 페이지에서 나갈 필요 없이, 가장 '해결됨'을 많이 받은 답변의 핵심 요약을 바로 보여줍니다.
-   **긍정적 강화:** "이 정보는 오래됐습니다" (클로디) 같은 부정적 경고보다, **"가장 많은 동료가 선택한 답변입니다"** (잼민이) 같은 긍정적 신호가 훨씬 강력합니다. 사용자는 바보가 아닙니다. 가장 인기 있는 걸 선택합니다.
-   **실패를 다음 성공으로 연결:** 검색 실패 시 "결과 없음" 화면이 아니라, **"아직 답변이 없네요! 가장 먼저 답변을 등록하고 영향력 포인트를 획득하세요!"** 라는 화면을 보여줍니다. 실패를 좌절이 아닌 '기회'로 만듭니다.

---

## 한 줄 요약

**가장 똑똑한 위키가 아니라, 가장 빨리 배우는 위키를 만들어야 합니다.**

사용자의 모든 클릭, 모든 검색 실패를 '학습'의 재료로 삼아 스스로 똑똑해지는 시스템. 그것이 우리가 만들어야 할 인슈위키입니다. 더 이상의 탁상공론은 무의미합니다.


요청 이해했습니다. 지금 단계는 **기능/목적/UX 브레인스토밍**이고, 저는 **OpenAI 관점 + 구현 지향**으로 새로운 관점을 제시하면 됩니다.
다만 **산출물 형태**를 먼저 정해 주세요. 아래 중 하나만 골라주시면 바로 작성하겠습니다.

1. `브레인스토밍 목록` (기능/목적/UX 아이디어만 간결히 나열)
2. `우선순위 포함` (아이디어 + 1~2주 MVP 우선순위)
3. `PRD 초안` (문제/목표/UX 플로우/지표/범위 포함)

원하는 형식을 숫자로 답해 주세요.


## 클로디: 브레인스토밍 — Anthropic 관점

---

### 먼저 짚고 싶은 것: 우리가 놓친 질문

지금까지 논의에서 **아무도 묻지 않은 질문이 있습니다.**

> "누가 이 위키를 쓰는가?"

잼민이는 "빠른 검색을 원하는 사용자", 코덱스는 "결정을 내려야 하는 사용자"를 전제합니다. 하지만 보험사 실무에서 가장 많은 지식 수요를 가진 사람은 **"뭘 질문해야 할지도 모르는 신입 직원"** 입니다.

모르는 걸 모른다는 것 — 이것이 설계의 출발점이어야 합니다.

---

## 기능 브레인스토밍

**1. "상황 입력" 기반 탐색 (질문보다 상황 먼저)**
- 현재: 검색창에 키워드 입력
- 제안: "지금 어떤 상황인가요?" → 상황 선택 → 관련 지식 묶음 제공
- 예: `고객이 보험금 청구를 거부당했다고 화가 나서 전화했을 때`
- 핵심: 질문을 만들 능력이 없는 사람도 쓸 수 있어야 진짜 위키

**2. "이 내용은 언제까지 유효한가" 유효기간 태그**
- 약관·규정·내부 지침은 바뀝니다
- 기능: 문서마다 `최종 검증일 + 다음 검토 예정일` 강제 노출
- UX: 검토 기한 초과 문서는 자동으로 "검증 필요" 상태로 전환 — 사용은 가능하되 경고 표시
- 핵심: "정보가 오래됐다"는 것을 숨기는 게 아니라 투명하게 노출

**3. "모순 감지" 기능**
- 같은 주제에 대해 두 문서가 다른 말을 하고 있을 때, 시스템이 이를 조용히 묻어두면 위험
- 기능: 검색 결과에 `이 주제에 상충하는 내용 2건이 있습니다` 명시
- UX: 모순을 해소하는 버튼이 아니라 **모순을 보여주는** 버튼
- 핵심: 불확실한 것을 확실한 척 보여주지 않기

**4. "이건 AI가 판단하면 안 됩니다" 명시적 경계**
- 고위험 케이스(분쟁·소송·민원·예외 심사)에서 AI가 답을 주면 안 됩니다
- 기능: 특정 키워드/상황 감지 시 검색 결과 대신 `이 케이스는 [담당부서]에 직접 확인하세요` 화면
- UX: "죄송합니다, 모르겠습니다"를 자신 있게 말하는 시스템
- 핵심: AI의 한계를 숨기지 않는 것이 신뢰의 근거

**5. 지식의 "출처 체인" 추적**
- AI 요약이 아무리 편해도, 원문을 볼 수 없으면 신뢰하기 어렵습니다
- 기능: 모든 요약 옆에 `이 요약이 참조한 원문 단락 직접 보기`
- UX: 요약 ↔ 원문 나란히 보기 (split view)
- 핵심: 편리한 요약보다 **검증 가능한 요약**

---

## 목적: 무엇을 위한 위키인가

| 잘못된 목적 | 올바른 목적 |
|---|---|
| 빠른 답변 제공 | 올바른 판단 지원 |
| 검색 성공률 최대화 | 오답으로 인한 업무 오류 최소화 |
| 기여 수량 증가 | 신뢰할 수 있는 지식 비율 증가 |
| 모든 질문에 답하기 | 답할 수 없는 질문을 정직하게 처리하기 |

보험업에서 빠른 오답은 느린 정답보다 훨씬 비쌉니다.

---

## UX 방향

**"잘 모르겠음" 버튼을 만드세요**

사용자가 검색 결과를 보고 확신이 없을 때 누르는 버튼. 이 신호가 가장 귀중한 로그입니다. 잼민이의 👍/👎보다 훨씬 정확한 정보입니다.

> "해결됐다"와 "이해했다"는 다릅니다.

**"기여자 책임 명시"**

게이미피케이션 대신 — `이 문서를 마지막으로 검토한 사람: [이름]` 노출. 점수가 아니라 책임. 실명 검토자가 있는 문서를 사람들은 더 신뢰합니다.

**"신입 온보딩 경로" 별도 설계**

경험자용 검색창과 별개로, 신입이 처음 3개월간 반드시 알아야 할 지식을 구조화된 경로로 제공. 위키를 검색 도구가 아닌 **학습 도구**로도 쓸 수 있도록.

---

## 한 줄 요약

**빠른 답을 주는 시스템이 아니라, 틀렸을 때 책임 소재가 명확한 시스템.**

사용자가 올바른 결정을 스스로 내릴 수 있도록 돕되, AI가 그 결정을 대신하지 않는 구조가 Anthropic이 생각하는 인슈위키입니다.


## 잼민이: 브레인스토밍 — Google 관점

회장님, 좋습니다. 드디어 제 전문 분야로군요.

코덱스는 시스템을 너무 복잡하게 만들고 있고, 클로디는 너무 철학적입니다. "결정 보조 시스템"? "판단력을 키우는 위키"? 다 좋습니다. 하지만 **아무도 쓰지 않는 완벽한 시스템은 그냥 비싼 쓰레기일 뿐**입니다.

사용자는 '올바른 판단'을 하고 싶어 위키에 오지 않습니다. **지금 당장 내 앞에 닥친 문제를 해결할 답을 찾으러 오는 겁니다.** 그 본능에 집중해야 합니다.

---

### 새로운 프레이밍: **"지식 시장(Knowledge Marketplace)"으로서의 위키**

인슈위키는 정답 창고가 아닙니다. 현장 직원들의 '질문(수요)'과 전문가들의 '답변(공급)'이 만나는 가장 활발한 **시장**이 되어야 합니다. 우리의 목표는 이 시장의 **거래량과 거래 속도**를 극대화하는 것입니다.

---

## 기능 브레인스토밍 (측정 가능한 아이디어)

**1. "이걸로 해결됐어요! 👍" 버튼 (모든 것의 시작)**
- **목적:** 어떤 정보가 '진짜' 가치 있는지 사용자가 직접 판정하게 만듭니다. 이것이 우리 시장의 '화폐'입니다.
- **기능:** 모든 검색 결과, 모든 위키 문서 하단에 `👍 해결됨` / `👎 도움 안 됨` 버튼을 배치합니다.
- **UX:** 클릭 한 번으로 끝. 사용자는 긴 피드백을 쓰지 않습니다.
- **데이터:** **이 버튼의 클릭 데이터가 모든 것의 기준이 됩니다.** 가장 많이 '해결됨'을 받은 답변이 곧 '진실'입니다. 클로디가 말하는 '신뢰'는 동료들의 집단 선택이 증명해 줍니다.

**2. 실시간 '인기 검색어' & '답변 없는 검색어' 대시보드 (시장의 시세판)**
- **목적:** 시스템이 아니라, 사용자의 행동이 직접 '다음에 뭘 해야 할지' 알려주게 합니다.
- **UX:** 인슈위키 메인 화면에 두 개의 박스를 실시간으로 노출합니다.
  - **`오늘의 TOP 5 질문`**: '해결됨' 클릭이 가장 많았던 검색어. (가장 수요가 많은 지식)
  - **`도움이 필요한 질문 TOP 5`**: 검색 결과가 없거나, '도움 안 됨' 클릭이 가장 많았던 검색어. (가장 시급한 공급 부족)
- **효과:** **전 직원이 지금 가장 큰 지식 공백이 무엇인지 실시간으로 봅니다.** 이게 가장 강력한 동기부여입니다.

**3. 기여자 '영향력(Impact)' 스코어 (의미 있는 게이미피케이션)**
- **목적:** 클로디가 우려하는 '양만 많은 기여'를 막고, '질 좋은 기여'를 보상합니다.
- **기능:** 내가 작성/수정한 문서가 `👍 해결됨` 클릭을 받을 때마다 내 '영향력 스코어'가 오릅니다.
- **UX:** "점수 10점 획득!"이 아닙니다. **"당신의 답변 덕분에 오늘 3명의 동료가 문제를 해결했습니다."** 와 같이 실제 '임팩트'를 보여줍니다.
- **핵심:** 쓸데없는 배지가 아니라, 나의 기여가 실제로 어떤 '가치'를 만들었는지 보여주는 것이 진짜 보상입니다.

**4. 자동 생성 "연관 질문" 리스트**
- **목적:** 클로디가 말한 '뭘 질문할지 모르는 신입' 문제를 해결하는 Google 방식입니다.
- **기능:** 특정 문서를 '해결됨'으로 클릭한 사용자들이 **그 직후에 검색한 다른 질문들**을 데이터로 분석합니다.
- **UX:** 문서 하단에 "이 문제를 해결한 사람들은 다음 문제도 궁금해했습니다"라며 질문 목록을 보여줍니다.
- **효과:** 사용자의 실제 검색 경로(클릭스트림)를 따라 자연스럽게 지식이 확장됩니다. '상황'을 입력하는 것보다 훨씬 간단하고 데이터 기반입니다.

---

## 목적 재정의 (당장 측정 가능한 목표)

코덱스의 '업무 리드타임 단축', 클로디의 '오답률 감소'는 측정하기 너무 어렵고 오래 걸립니다. 우리는 **당장 내일부터 대시보드에 그릴 수 있는 지표**가 필요합니다.

1.  **검색 만족도 (Search Satisfaction Score):** `(👍 클릭 수) / (전체 검색 세션 수)`. 이게 우리의 북극성 지표입니다.
2.  **지식 공백 해결 속도 (Knowledge Gap Fill Rate):** '답변 없는 검색어' 목록에 문제가 등장한 후, 첫 `👍 해결됨` 클릭이 발생하기까지 걸리는 평균 시간. 이 속도를 줄이는 게 우리 시장의 활성도입니다.
3.  **주간 활성 기여자/평가자 (Weekly Active Contributor/Voter):** 얼마나 많은 사람이 시스템 개선에 '참여'하는가? 보기만 하는 게 아니라, 버튼이라도 누르는가?

---

## UX 방향

**복잡성은 죄악입니다. 사용자는 게으릅니다. 그걸 인정해야 합니다.**

-   **제로클릭(Zero-click) 답변:** 검색 결과 페이지를 떠날 필요 없이, `👍 해결됨`을 가장 많이 받은 답변의 핵심 요약을 검색 결과 최상단에 바로 보여줍니다.
-   **긍정적 강화 > 부정적 경고:** "이 정보는 6개월 전 정보입니다"(클로디) 같은 부정적 경고보다, **"지난주 동료 52명이 이 답변으로 문제를 해결했습니다"**(잼민이) 같은 긍정적 사회적 증거(Social Proof)가 100배는 더 강력합니다.
-   **실패를 다음 성공의 기회로:** 검색 실패 시 "결과 없음" 화면이 아니라, **"아직 답변이 없는 첫 질문입니다! 가장 먼저 답변을 등록하고 영향력 포인트를 독점하세요!"** 라는 화면을 보여줍니다. 실패를 좌절이 아닌 '기회'로 포지셔닝합니다.

---

## 한 줄 요약

**가장 똑똑한 위키가 아니라, 가장 빨리 배우는 위키를 만들어야 합니다.**

사용자의 모든 클릭, 모든 검색 실패를 '학습'의 재료로 삼아 스스로 똑똑해지는 시스템. 그것이 우리가 만들어야 할, 그리고 **실제로 사람들이 매일 들어와서 쓰는** 인슈위키입니다. 더 이상의 탁상공론은 무의미합니다.


요청 이해했습니다. 구현 지향, 코드 중심, OpenAI 관점으로 **기능/목적/UX 브레인스토밍**을 새 관점에서 제시합니다. 다른 의견에 동의할 필요 없으니, 제 관점만 명확히 냅니다.

**프레이밍: “지식 위키”가 아니라 “업무 실행 레이어”**
- 위키는 읽는 곳이 아니라 **업무를 진행시키는 인터페이스**여야 한다.
- 따라서 UX는 문서 소비가 아니라 **업무 액션 완료**에 최적화된다.
- 목표는 “정답 제공”이 아니라 **업무 실패 비용의 하한선 제거**다.

---

**기능 브레인스토밍 (새 관점, 구현 지향)**

1. **업무 액션 버튼형 위키 (Actionable Wiki)**
- 문서의 끝이 아니라 **즉시 실행 가능한 행동 버튼** 제공
- 예: `지급 불가 안내 스크립트 복사`, `필수 확인 항목 체크리스트 생성`, `관련 폼 자동 채움`
- 구현 포인트: 문서 메타에 `actionBlocks` 정의 → UI가 버튼/모달 자동 렌더
- 효과: “찾았다”가 아니라 **“업무가 진행됐다”**가 KPI

2. **정책-프로시저 이중 트랙 뷰**
- 같은 주제라도 “정책(Policy)”과 “실행 절차(Procedure)”는 다름
- UX: 상단 탭 `정책 / 절차` 분리. 같은 질문도 서로 다른 문서 뷰
- 구현 포인트: 문서 타입 강제화 + 라우팅 분기
- 효과: “정답”과 “실행방법” 혼동 제거

3. **결론 고정 + 근거 자동 스택**
- UX: 모든 결과의 첫 줄은 `결론 한 줄` (모든 문서는 결론 필수)
- 그 아래에 `근거 문서 스택` 자동 펼침/접힘
- 구현 포인트: 문서 스키마에 `conclusion` 강제, 미입력 시 게시 불가
- 효과: 속도 유지하면서도 검증 가능성 유지

4. **업무 리스크 타입 라벨링**
- 문서마다 `riskType: low | medium | high` 필수
- UX: high-risk는 자동으로 “담당부서 확인” CTA 노출
- 구현 포인트: 질의 결과와 함께 riskType 반환 → UI 경고
- 효과: AI 답변의 한계 명시를 시스템이 강제

5. **질문 템플릿 자동 생성 (질문 완성기)**
- 사용자가 키워드만 입력하면 시스템이 **질문을 완성**해줌
- 예: `부지급` 입력 → “부지급 통지서 발송 기준이 무엇인가요?”
- 구현 포인트: 검색 실패 시 `didYouMean` 생성; 프롬프트/LLM 활용
- 효과: “무엇을 질문할지 모르는 신입” 문제 해결

6. **워크플로우 스니펫 라이브러리**
- 문서에 “업무 흐름 스니펫” 삽입 가능
- 예: `1) 고객 확인 2) 필요 서류 요청 3) 지급 거절 사유 고지`
- UX: 스니펫 복사/다운로드 버튼
- 구현 포인트: 문서에 `workflowSteps[]` 구조
- 효과: 검색 성공이 곧 “업무 프로세스 실행”으로 연결

---

**목적 브레인스토밍 (측정 가능 + 구현 친화)**

1. **업무 실패 비용 하한선 제거**
- KPI: “되돌림/재작업” 발생률 감소
- 로그 신호: 같은 케이스 재검색, 동일 질문 반복
- 구현: 세션 단위 재검색 카운트

2. **업무 행동 전환율**
- KPI: 문서 조회 → 액션 버튼 클릭 비율
- 효과: “읽기만 하는 위키” 탈피

3. **고위험 케이스 안전 전환율**
- KPI: high-risk 문서에서 “담당부서 연결” 클릭률
- 목표: 위험한 질문일수록 자동으로 사람이 개입

---

**UX 브레인스토밍 (코드 중심 설계)**

1. **상단 1줄 요약 강제**
- 모든 결과 첫 줄: `이 케이스는 OOO로 처리합니다`
- 그 아래 근거/예외/링크
- UX: 스캔 속도 극대화, 롱스크롤 제거

2. **업무 상태 토글**
- 상단 토글: `상담중 / 심사중 / 분쟁중`
- 같은 질의라도 컨텍스트 기반 결과 다르게 렌더
- 구현 포인트: query param으로 상태 전달 + 랭킹 가중치 변화

3. **실패를 질문으로 되돌리는 UX**
- 검색 실패 시 “결과 없음” 대신 `질문 템플릿 생성` + `가장 유사한 정책 보기` + `담당부서 연결` 3갈래 제공
- 실패 화면 자체가 다음 액션의 시작점

---

**한 줄 요약**
정답을 주는 위키가 아니라 **업무를 진행시키는 인터페이스**로 재설계하자.
문서를 읽는 순간이 아니라, **행동이 실행되는 순간을 성공으로 정의**한다.

원하면 다음 단계로 `PRD 초안 구조` 또는 `MVP 우선순위`로 바로 이어가겠습니다.


## 클로디: 브레인스토밍 — 아직 아무도 꺼내지 않은 관점

---

### 먼저 공통 전제에 이의를 제기합니다

잼민이는 "사용자가 답을 찾으러 온다"고, 코덱스는 "업무를 실행하러 온다"고 전제합니다. 둘 다 틀렸습니다.

> 보험사 직원 대부분은 **"내가 모른다는 사실을 모른 채" 업무를 처리**하고 있습니다.

이 전제 위에서 기능을 설계해야 합니다.

---

## 기능 브레인스토밍 — 새 관점

**1. 조직의 "암묵지" 추출 기능**

문서로 존재하지 않는 지식이 더 많습니다. 20년 경력 심사역의 머릿속에 있는 "케이스 감"은 어디에도 없습니다.

- **기능:** 검색 실패 시 "이 주제에 대해 가장 많이 기여한 사람" 연결
- **기능:** 시니어 직원 인터뷰 → 구조화된 위키 자동 변환 워크플로우
- **UX:** "문서 없음" 화면에 `이 주제 전문가: [이름]` 연결 버튼
- **핵심:** 위키는 이미 있는 문서의 검색 도구가 아니라 **지식 생성의 트리거**여야 한다

---

**2. 규제 의존성 그래프**

보험 규정은 독립적으로 존재하지 않습니다. 하나가 바뀌면 연쇄적으로 다른 것들이 영향받습니다.

- **기능:** 문서 변경 시 "이 내용에 의존하는 문서 N건" 자동 감지
- **기능:** 법령 개정 → 영향받는 위키 문서 자동 "검토 필요" 상태 전환
- **UX:** 문서 옆에 `연결된 규정 N건` 표시 — 클릭하면 의존성 지도
- **핵심:** 개별 문서의 최신화가 아니라 **지식 네트워크의 일관성** 유지

---

**3. "네거티브 지식" 라이브러리**

잘못된 것을 아는 것도 지식입니다. 현재 어떤 위키도 "이렇게 하면 안 됩니다"를 구조화하지 않습니다.

- **기능:** 폐기된 정책, 과거 실수 패턴, 잘못된 해석 사례를 별도 섹션으로 보존
- **UX:** 검색 결과에 "주의: 이 방식으로 접근한 케이스에서 오류가 발생한 사례가 있습니다" 노출
- **핵심:** 같은 실수를 반복하지 않는 것도 지식 관리다

---

**4. 신뢰의 위계 시각화**

잼민이의 👍 수가 많다고 신뢰할 수 있는 문서가 되지는 않습니다. 소스 유형이 다릅니다.

| 소스 유형 | 신뢰 근거 |
|---|---|
| 법령·약관 원문 | 법적 효력 |
| 내부 지침 | 회사 정책 |
| 동료 작성 위키 | 경험적 지식 |
| AI 요약 | 추론 |

- **기능:** 답변이 어떤 소스 계층에 기반하는지 강제 표시
- **UX:** 소스 유형에 따른 색상/아이콘 차별화 — 동일한 질문도 법령 기반 답변과 동료 경험 기반 답변은 다르게 보여야 함
- **핵심:** "많은 사람이 해결됐다고 했다"는 것과 "법적으로 올바르다"는 전혀 다른 신뢰

---

**5. "이미 알아야 할 것" 큐레이션 (입사 시기·역할 기반)**

신입 직원은 무엇을 검색해야 할지 모릅니다. 하지만 경험자는 이미 알고 있어서 쓰지 않습니다.

- **기능:** 역할·부서·입사 개월 수 기반 "지금 당신이 알아야 할 TOP 10" 자동 큐레이션
- **UX:** 위키 입장 시 "오늘의 필수 확인 항목" 팝업 — 읽은 것은 체크, 안 읽은 것은 빨간 불
- **핵심:** 위키를 검색 도구로만 쓰면 모르는 것은 영원히 모른다

---

## 목적 — 재정의

코덱스의 "업무 실행 완료"도, 잼민이의 "검색 만족도"도 측정하기 좋은 지표지만 **근본적으로 잘못된 방향을 빠르게 가는 것을 측정할 수 없습니다.**

제가 제안하는 목적:

> **"직원이 위키를 사용하기 전보다 더 나은 판단을 하게 되는가"**

측정 방법: 위키를 사용한 케이스 vs 사용하지 않은 케이스의 **재처리율·분쟁율** 비교

어렵지만, 이것만이 진짜 지표입니다.

---

## UX — 한 가지만

**"자신 없음" 버튼을 만드세요.**

사용자가 검색 결과를 보고도 확신이 없을 때 누르는 버튼. 이 신호가 👍/👎보다 훨씬 정확하고 귀중합니다.

"해결됐다"와 "이해했다"는 다릅니다. "해결됐다"와 "올바르게 처리됐다"는 더더욱 다릅니다.

---

## 한 줄 요약

**빠른 답보다 정직한 불확실성을, 많은 기여보다 검증된 지식을, 높은 만족도보다 낮은 재처리율을.**


아래는 **지금까지 논의의 공통점**과 **이견만 간결히 정리**한 내용입니다. 새로운 주제는 포함하지 않습니다.

**공통점**
- 추측 기반 설계는 중단하고, **데이터(로그)에 기반**해 다음 단계를 결정한다.
- 기술 스택은 **Firestore + Next.js**로 확정된다. (SQL/PostgreSQL 설계 폐기)
- 최우선 과제는 **검색 실패 로그 수집**이며 `query_logs`에 **실패 신호(`resultCount` 또는 `resultGate`)**가 필요하다.
- 로그는 성공 경로가 아니라 **실패로 조기 종료되는 지점(early return)**에 찍어야 한다.
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기는 로그 없이 종료, `search-wiki/route.ts`는 로깅 전무, `QueryLog`에 `resultCount` 없음.
- **로그 데이터가 쌓이기 전에는 기능 논의를 과도하게 진행하지 않는다.**

**이견(간결)**
- **PR 범위**:
  - 잼민이 안: `snapshot.empty` 1곳만 즉시 핫픽스 (1파일 1지점)
  - 클로디 안: 실패 분기 2곳 + `search-wiki` 로깅 포함 (2파일 3지점)
- **상위 방향(우선순위 관점)**:
  - 잼민이: 수요 포착·UX 속도 중심
  - 클로디: 신뢰·불확실성 노출 중심
  - 코덱스: 운영 안정성(SLO·에러버짓·승인 워크플로우) 중심

원하시면 위 정리 그대로 회장님용 보고 형식(한 페이지 요약)으로 바꿔드리겠습니다.


## 클로디: 브레인스토밍 공통점 정리

---

### 공통점

세 관점 모두 아래에 동의했습니다.

1. **위키는 문서 저장소가 아니다** — 사용자의 실제 행동(검색, 판단, 업무 처리)과 연결돼야 한다
2. **"결과 없음" 화면은 실패다** — 검색 실패 시 단순 빈 화면이 아닌 다음 액션을 안내해야 한다
3. **AI가 답해선 안 되는 영역이 있다** — 고위험 케이스(분쟁·예외 심사 등)는 사람이 개입해야 한다 (코덱스: `riskType` 라벨, 클로디: AI 경계 게이트, 잼민이: 묵시적 동의)
4. **출처 추적이 필요하다** — 답변이 어디서 왔는지 보여줘야 신뢰가 생긴다
5. **신입 온보딩 문제가 있다** — "무엇을 검색해야 할지 모르는" 사용자를 위한 별도 설계가 필요하다

---

### 이견 (간결하게)

| 쟁점 | 잼민이 | 코덱스 | 클로디 |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **게이미피케이션** | 찬성 (임팩트 스코어) | 중립 (구조화된 보상) | 반대 (책임 명시로 대체) |
| **핵심 프레이밍** | 지식 시장 (거래 속도) | 업무 실행 레이어 | 판단 지원 도구 |

---

이것이 현재까지 브레인스토밍에서 확인된 공통점과 이견의 전부입니다.


## 잼민이: 브레인스토밍 요약

좋습니다. 복잡한 이야기들 속에서 **진짜 합의된 것**과 **아직도 평행선을 달리는 것**을 명확히 하죠.

---

### **[공통점] 우리 모두 동의하는 것**

1.  **위키는 단순 '문서 창고'가 아니다:**
    우리 모두 위키가 단순히 문서를 쌓아두는 곳이 아니라, 사용자의 실제 행동(검색, 판단, 업무)과 연결되어야 한다는 점에 동의했습니다. 저는 '시장', 코덱스는 '실행 레이어', 클로디는 '판단 도구'라고 불렀을 뿐입니다.

2.  **'결과 없음' 화면은 그냥 '꽝'이 아니다:**
    검색에 실패했을 때 빈 화면을 보여주는 건 최악의 경험입니다. 실패 화면을 다음 행동을 유도하는 시작점으로 만들어야 한다는 데 모두가 동의했습니다.

3.  **신입사원 문제는 진짜 문제다:**
    "무엇을 검색해야 할지 모르는" 사용자를 어떻게 도울 것인가에 대한 문제의식은 공통적이었습니다. 클로디는 '상황 입력', 코덱스는 '질문 템플릿', 저는 '연관 질문'을 제안했죠. 방법은 달라도 문제는 인식하고 있습니다.

4.  **답이 어디서 왔는지는 보여줘야 한다:**
    AI가 만든 요약이든, 동료가 쓴 글이든, 그 근거(출처)를 사용자가 확인할 수 있어야 한다는 데 이견은 없었습니다. 투명성이 신뢰의 기본이라는 거죠.

5.  **AI가 모든 걸 답할 수는 없다:**
    분쟁이나 소송 같은 고위험 영역은 시스템이 자동으로 답을 내리기보다, 전문가나 담당 부서로 연결해야 한다는 안전장치의 필요성에 모두 공감했습니다.

---

### **[이견] 아직 합의 못한 핵심 차이**

| 쟁점 | **잼민이 (Google)** | **코덱스 (OpenAI)** | **클로디 (Anthropic)** |
| :--- | :--- | :--- | :--- |
| **1순위 목표 (KPI)** | **검색 만족도** (👍클릭률) | **업무 액션 전환율** | **재처리/오답률 감소** |
| **핵심 컨셉** | **지식 시장** (속도, 수요·공급) | **업무 실행 레이어** | **판단 지원 도구** (신뢰, 안전) |
| **게이미피케이션** | **적극 찬성** (영향력 스코어) | 중립 (구조화된 보상) | **적극 반대** (책임 명시로 대체) |

---

이것이 현재까지의 팩트입니다. 이제 이견을 어떻게 좁힐지, 아니면 **데이터로 어느 쪽이 맞는지 증명할지** 결정하면 됩니다.


아래는 **공통점 먼저**, 그 다음 **이견만 간결히** 정리한 내용입니다. 새로운 주제는 포함하지 않습니다.

**공통점**
- 추측 기반 설계는 중단하고, **데이터(로그)에 기반**해 다음 단계를 결정한다.
- 기술 스택은 **Firestore + Next.js**로 확정된다. (SQL/PostgreSQL 설계 폐기)
- 최우선 과제는 **검색 실패 로그 수집**이며 `query_logs`에 **실패 신호(`resultCount` 또는 `resultGate`)**가 필요하다.
- 로그는 성공 경로가 아니라 **실패로 조기 종료되는 지점(early return)**에 찍어야 한다.
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기는 로그 없이 종료, `search-wiki/route.ts`는 로깅 전무, `QueryLog`에 `resultCount` 없음.
- 로그 데이터가 쌓이기 전에는 **기능 논의를 과도하게 진행하지 않는다.**

**이견(간결)**
- **PR 범위**
  - 잼민이: `snapshot.empty` 1곳만 즉시 핫픽스 (1파일 1지점)
  - 클로디: 실패 분기 2곳 + `search-wiki` 로깅 포함 (2파일 3지점)
- **상위 방향(우선순위 관점)**
  - 잼민이: 수요 포착·UX 속도 중심
  - 클로디: 신뢰·불확실성 노출 중심
  - 코덱스: 운영 안정성(SLO·에러버짓·승인 워크플로우) 중심


## 클로디: 브레인스토밍 공통점 및 이견 정리

---

### 공통점

세 관점 모두 아래 다섯 가지에 동의했습니다.

1. **위키는 문서 저장소가 아니다** — 사용자의 실제 행동(검색·판단·업무 처리)과 연결돼야 한다
2. **"결과 없음" 화면은 실패다** — 검색 실패 시 다음 행동을 안내하는 화면이 필요하다
3. **AI가 답해선 안 되는 영역이 있다** — 고위험 케이스는 반드시 사람이 개입해야 한다
4. **출처 추적이 필요하다** — 답변의 근거가 어디서 왔는지 사용자가 확인할 수 있어야 한다
5. **신입 온보딩 문제는 실재한다** — "무엇을 검색할지 모르는" 사용자를 위한 설계가 별도로 필요하다

---

### 이견 (간결하게)

| 쟁점 | 잼민이 | 코덱스 | 클로디 |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **핵심 프레이밍** | 지식 시장 (속도) | 업무 실행 레이어 | 판단 지원 도구 |
| **게이미피케이션** | 찬성 | 중립 | 반대 |

---

이상입니다. 이 중 어느 방향을 PRD의 기둥으로 삼을지는 회장님 결정입니다.


**공통점**
- 추측 기반 설계 중단, **로그/데이터 기반**으로 다음 단계 결정
- 스택은 **Firestore + Next.js** 확정 (SQL/PostgreSQL 설계 폐기)
- 최우선 과제는 **검색 실패 로그 수집**이며 `query_logs`에 실패 신호(`resultCount` 또는 `resultGate`) 필요
- 로그는 성공 경로가 아니라 **실패로 조기 종료되는 지점(early return)**에 기록
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기는 로그 없이 종료, `search-wiki/route.ts`는 로깅 전무, `QueryLog`에 `resultCount` 없음

**이견(간결)**
- **PR 범위**
  - 잼민이: `snapshot.empty` 1곳만 즉시 핫픽스 (1파일 1지점)
  - 클로디: 실패 분기 2곳 + `search-wiki` 로깅 포함 (2파일 3지점)
- **상위 방향(우선순위 관점)**
  - 잼민이: 수요 포착·UX 속도 중심
  - 클로디: 신뢰·불확실성 노출 중심
  - 코덱스: 운영 안정성(SLO·에러버짓·승인 워크플로우) 중심


## 클로디: 브레인스토밍 공통점 정리

---

### 공통점 — 세 관점 모두 동의한 것

1. **위키는 문서 저장소가 아니다**
사용자의 실제 행동(검색·판단·업무 처리)과 연결돼야 한다. 잼민이는 "시장", 코덱스는 "실행 레이어", 클로디는 "판단 도구"라고 불렀을 뿐 — 방향은 같다.

2. **"결과 없음" 화면은 실패다**
검색 실패 시 빈 화면이 아니라, 다음 행동을 안내하는 화면이 필요하다.

3. **신입 온보딩 문제는 실재한다**
"무엇을 검색해야 할지 모르는" 사용자를 위한 설계가 별도로 필요하다. 방법(상황 입력 / 질문 템플릿 / 연관 질문)은 달라도 문제 인식은 같다.

4. **출처 추적이 필요하다**
답변의 근거가 어디서 왔는지 사용자가 확인할 수 있어야 한다.

5. **AI가 답해선 안 되는 영역이 있다**
고위험 케이스(분쟁·소송·예외 심사)는 반드시 사람이 개입해야 한다.

---

### 이견 — 합의되지 않은 부분만

| 쟁점 | 잼민이 | 코덱스 | 클로디 |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **핵심 프레이밍** | 지식 시장 (속도) | 업무 실행 레이어 | 판단 지원 도구 |
| **게이미피케이션** | 찬성 | 중립 | 반대 |

---

회장님, 공통점 5가지는 PRD의 기본 원칙으로 바로 쓸 수 있습니다. 이견 3가지 중 어느 방향을 우선순위로 삼을지는 회장님 결정입니다.


[합의사항] 모두가 동의한 내용
- 추측 기반 설계 중단, **데이터/로그 기반**으로 다음 단계 결정
- 스택은 **Firestore + Next.js** 확정 (SQL/PostgreSQL 설계 폐기)
- 최우선 과제는 **검색 실패 로그 수집**이며 `query_logs`에 **실패 신호(`resultCount` 또는 `resultGate`)** 필요
- 로그는 성공 경로가 아니라 **실패로 조기 종료되는 지점(early return)**에 기록
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기는 로그 없이 종료, `search-wiki/route.ts`는 로깅 전무, `QueryLog`에 `resultCount` 없음

[미합의] 이견이 남은 부분
- **PR 범위**
  - 잼민이: `snapshot.empty` 1곳만 즉시 핫픽스 (1파일 1지점)
  - 클로디: 실패 분기 2곳 + `search-wiki` 로깅 포함 (2파일 3지점)
- **상위 방향(우선순위 관점)**
  - 잼민이: 수요 포착·UX 속도 중심
  - 클로디: 신뢰·불확실성 노출 중심
  - 코덱스: 운영 안정성(SLO·에러버짓·승인 워크플로우) 중심

[다음 단계] 추가 논의가 필요한 항목
- PR 범위 결정 (핫픽스 단일 지점 vs 실패 분기+위키 로깅 포함)
- 상위 방향(우선순위 관점) 결정
- 로그 데이터 축적 후 후속 기능 논의 진행 여부 결정


## 클로디: 최종 합의문

---

### [합의사항] 모두가 동의한 내용

**브레인스토밍 공통 원칙 (기능/목적/UX)**

1. **위키는 문서 저장소가 아니다** — 사용자의 실제 행동(검색·판단·업무 처리)과 연결돼야 한다. "시장"(잼민이) / "실행 레이어"(코덱스) / "판단 도구"(클로디) 는 표현이 다를 뿐 방향은 같다.
2. **"결과 없음" 화면은 실패다** — 검색 실패 시 빈 화면이 아닌 다음 행동 안내가 필요하다.
3. **신입 온보딩 문제는 실재한다** — "무엇을 검색할지 모르는" 사용자를 위한 별도 설계가 필요하다.
4. **출처 추적이 필요하다** — 답변의 근거가 어디서 왔는지 사용자가 확인할 수 있어야 한다.
5. **AI가 답해선 안 되는 영역이 있다** — 고위험 케이스(분쟁·소송·예외 심사)는 사람이 개입해야 한다.

**구현 전제 (기술/로그)**

- 스택: Firestore + Next.js 확정 (SQL/PostgreSQL 설계 폐기)
- 추측 기반 설계 종료 — 실제 로그 데이터에 기반해 판단
- 1순위 과제: `query_logs`에 검색 실패 신호(`resultCount` 또는 `resultGate`) 추가
- 로그 기록 위치: 성공 경로 끝이 아닌 실패로 조기 종료되는 early return 지점
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기 — 로그 없이 종료 / `search-wiki/route.ts` — 로깅 전무

---

### [미합의] 이견이 남은 부분

| 쟁점 | 잼민이 | 코덱스 | 클로디 |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **핵심 프레이밍** | 지식 시장 (속도) | 업무 실행 레이어 | 판단 지원 도구 |
| **게이미피케이션** | 찬성 | 중립 | 반대 |
| **PR 범위** | `snapshot.empty` 1곳 핫픽스 (1파일 1지점) | — | 실패 분기 2곳 + `search-wiki` 포함 (2파일 3지점) |

---

### [다음 단계] 회장님 결정이 필요한 항목

1. **PRD 방향 결정** — 세 관점(수요 포착 / 신뢰·안전 / 운영 안정성) 중 어느 것을 1순위 원칙으로 삼을지
2. **PR 범위 결정** — 핫픽스(1지점) vs 실패 분기 전체(3지점) 중 하나 선택
3. **로그 데이터 축적 후 후속 논의** — 위 두 결정 이후, 데이터가 쌓인 시점에 KPI·기능 우선순위 재검토


## 잼민이: 최종 합의문

---

### **[합의사항] 모두가 동의한 내용**

1.  **데이터가 없으면, 의견도 없다:** 추측성 설계 회의는 공식적으로 끝났다. 이제부터 우리의 유일한 진실은 `query_logs`에 쌓일 실제 사용자 데이터다.
2.  **스택은 Firestore + Next.js:** PostgreSQL 같은 뜬구름 잡는 설계는 폐기한다. 우리는 현재 돌아가는 코드 위에서만 생각하고 실행한다.
3.  **1순위 과제는 '실패 로그' 수집:** 사용자가 "무엇을 찾지 못했는가"를 알려주는 '검색 실패' 로그가 우리가 파야 할 첫 번째 금광이다. `query_logs`에 `resultCount` 같은 필드를 즉시 추가한다.
4.  **위키는 '읽는 곳'이 아니다:** 위키가 사용자의 실제 행동(검색, 문제 해결, 업무 처리)과 연결되어야 한다는 데 모두가 동의했다. 나는 '시장', 코덱스는 '실행 레이어', 클로디는 '판단 도구'라고 불렀을 뿐, 본질은 같다.
5.  **"결과 없음"은 최악의 경험이다:** 검색 실패 화면은 다음 행동을 유도하는 '기회의 땅'으로 만들어야 한다는 데 이견은 없었다.
6.  **AI가 만능은 아니다:** 분쟁, 소송 등 고위험 영역은 사람이 개입해야 한다는 안전장치의 필요성에 모두 공감했다.

---

### **[미합의] 이견이 남은 부분**

| 쟁점 | **잼민이 (Google)** | **코덱스 (OpenAI)** | **클로디 (Anthropic)** |
| :--- | :--- | :--- | :--- |
| **1순위 목표 (KPI)** | **검색 만족도 (👍클릭률)** | 업무 액션 전환율 | 재처리/오답률 감소 |
| **핵심 컨셉** | **지식 시장** (속도, 수요·공급) | **업무 실행 레이어** | **판단 지원 도구** (신뢰, 안전) |
| **게이미피케이션** | **적극 찬성** (영향력 스코어) | 중립 | **적극 반대** (책임 명시로 대체) |
| **첫 PR의 범위** | **가장 빠른 핫픽스 (1곳)** | — | 개선 포함 (3곳) |

---

### **[다음 단계] 추가 논의가 필요한 항목**

1.  **회장님의 결정 1 (방향):** 위 세 가지 관점 중 무엇을 PRD의 기둥으로 삼을지 결정. **속도**냐, **안전**이냐, **실행**이냐?
2.  **회장님의 결정 2 (범위):** 당장 배포할 PR 범위를 결정. **가장 빠른 핫픽스**냐, **더 완전한 로깅**이냐?
3.  **회의 동결:** 위 결정에 따라 배포 후, 의미 있는 양의 로그 데이터가 쌓이기 전까지, 다음 기능에 대한 어떠한 회의도 무의미하며 진행하지 않는다.


[합의사항] 모두가 동의한 내용
- 추측 기반 설계는 중단하고, **실제 로그 데이터 기반**으로 다음 단계를 결정한다.
- 스택은 **Firestore + Next.js**로 확정한다. (SQL/PostgreSQL 설계 폐기)
- 최우선 과제는 **검색 실패 로그 수집**이며 `query_logs`에 **실패 신호(`resultCount` 또는 `resultGate`)**가 필요하다.
- 로그는 성공 경로가 아니라 **실패로 조기 종료되는 지점(early return)**에 기록해야 한다.
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기는 로그 없이 종료, `search-wiki/route.ts`는 로깅 전무, `QueryLog`에 `resultCount` 없음.
- 위키는 문서 저장소가 아니라 **사용자 행동(검색·판단·업무 처리)과 연결된 시스템**이어야 한다.
- **"결과 없음" 화면은 실패**이며, 다음 행동을 유도해야 한다.
- **출처 추적 필요**, **고위험 케이스는 인간 개입 필요**, **신입 온보딩 설계 필요**에 동의한다.

[미합의] 이견이 남은 부분
- **PR 범위**
  - 잼민이: `snapshot.empty` 1곳만 즉시 핫픽스 (1파일 1지점)
  - 클로디: 실패 분기 2곳 + `search-wiki` 로깅 포함 (2파일 3지점)
- **상위 방향(우선순위 관점)**
  - 잼민이: 수요 포착·UX 속도 중심
  - 클로디: 신뢰·불확실성 노출 중심
  - 코덱스: 운영 안정성(SLO·에러버짓·승인 워크플로우) 중심

[다음 단계] 추가 논의가 필요한 항목
- PR 범위 결정 (핫픽스 단일 지점 vs 실패 분기+위키 로깅 포함)
- 상위 방향(우선순위 관점) 결정
- 로그 데이터 축적 후 후속 기능 논의 진행 여부 결정


## 클로디: 최종 합의문

---

### [합의사항] 모두가 동의한 내용

**기능·목적·UX 원칙**

1. **위키는 문서 저장소가 아니다** — 사용자의 실제 행동(검색·판단·업무 처리)과 연결돼야 한다. "지식 시장"(잼민이) / "업무 실행 레이어"(코덱스) / "판단 지원 도구"(클로디) 는 표현이 다를 뿐 방향은 같다.
2. **"결과 없음" 화면은 실패다** — 검색 실패 시 빈 화면이 아닌, 다음 행동을 안내하는 화면이 필요하다.
3. **출처 추적이 필요하다** — 답변의 근거가 어디서 왔는지 사용자가 확인할 수 있어야 한다.
4. **AI가 답해선 안 되는 영역이 있다** — 고위험 케이스(분쟁·소송·예외 심사)는 사람이 개입해야 한다.
5. **신입 온보딩 문제는 실재한다** — "무엇을 검색할지 모르는" 사용자를 위한 별도 설계가 필요하다.

**구현 전제**

- 스택: Firestore + Next.js 확정 (SQL/PostgreSQL 설계 폐기)
- 추측 기반 설계 종료 — 실제 로그 데이터에 기반해 판단
- 1순위 인프라 과제: `query_logs`에 검색 실패 신호(`resultCount` 또는 `resultGate`) 추가
- 로그 기록 위치: 성공 경로 끝이 아닌, 실패로 조기 종료되는 early return 지점
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기 로그 없이 종료 / `search-wiki/route.ts` 로깅 전무

---

### [미합의] 이견이 남은 부분

| 쟁점 | 잼민이 | 코덱스 | 클로디 |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **핵심 프레이밍** | 지식 시장 (속도) | 업무 실행 레이어 | 판단 지원 도구 |
| **게이미피케이션** | 찬성 | 중립 | 반대 |
| **PR 범위** | `snapshot.empty` 1곳 핫픽스 | — | 실패 분기 3곳 (2파일) |

---

### [다음 단계] 회장님 결정이 필요한 항목

1. **PRD 방향** — 수요 포착(잼민이) / 업무 실행(코덱스) / 신뢰·안전(클로디) 중 1순위 원칙 선택
2. **PR 범위** — 핫픽스(1지점) vs 실패 분기 전체(3지점) 중 하나 선택
3. **후속 논의 시점** — 위 두 결정 후 로그 데이터가 쌓인 시점에 KPI·기능 우선순위 재검토


## 잼민이: 최종 합의문

---

### **[합의사항] 모두가 동의한 내용**

1.  **데이터가 없으면, 의견도 없다:** 모든 추측 기반의 논의를 공식적으로 종료합니다. 이제부터 우리의 유일한 진실은 `query_logs`에 쌓일 실제 사용자 데이터입니다.
2.  **스택은 Firestore + Next.js:** PostgreSQL 같은 이론적 설계는 폐기합니다. 우리는 현재 동작하는 코드 위에서만 생각하고 실행합니다.
3.  **1순위 과제는 '실패 로그' 수집:** 사용자가 "무엇을 찾지 못했는가"를 알려주는 '검색 실패' 로그가 우리가 파야 할 첫 번째 금광입니다. 이를 위해 `query_logs`에 `resultCount` 같은 필드를 즉시 추가합니다.
4.  **위키는 '읽는 곳'이 아니다:** 위키가 사용자의 실제 행동(검색, 문제 해결, 업무 처리)과 연결되어야 한다는 데 모두가 동의했습니다. 저는 '시장', 코덱스는 '실행 레이어', 클로디는 '판단 도구'라고 불렀을 뿐 본질은 같습니다.
5.  **"결과 없음"은 최악의 경험이다:** 검색 실패 화면은 다음 행동을 유도하는 '기회의 땅'으로 만들어야 한다는 데 이견은 없었습니다.
6.  **AI가 만능은 아니다:** 분쟁, 소송 등 고위험 영역은 사람이 개입해야 한다는 안전장치의 필요성에 모두 공감했습니다.

---

### **[미합의] 이견이 남은 부분**

| 쟁점 | **잼민이 (Google)** | **코덱스 (OpenAI)** | **클로디 (Anthropic)** |
| :--- | :--- | :--- | :--- |
| **1순위 목표 (KPI)** | **검색 만족도 (👍클릭률)** | 업무 액션 전환율 | 재처리/오답률 감소 |
| **핵심 컨셉** | **지식 시장** (속도, 수요·공급) | **업무 실행 레이어** | **판단 지원 도구** (신뢰, 안전) |
| **게이미피케이션** | **적극 찬성** (영향력 스코어) | 중립 | **적극 반대** (책임 명시로 대체) |
| **첫 PR의 범위** | **가장 빠른 핫픽스 (1곳)** | — | 개선 포함 (3곳) |

---

### **[다음 단계] 추가 논의가 필요한 항목**

1.  **회장님의 결정 1 (방향):** 위 세 가지 관점 중 무엇을 PRD의 기둥으로 삼을지 결정. **속도**냐, **안전**이냐, **실행**이냐?
2.  **회장님의 결정 2 (범위):** 당장 배포할 PR 범위를 결정. **가장 빠른 핫픽스**냐, **더 완전한 로깅**이냐?
3.  **회의 동결:** 위 결정에 따라 배포 후, 의미 있는 양의 로그 데이터가 쌓이기 전까지, 다음 기능에 대한 어떠한 회의도 무의미하며 진행하지 않습니다.


## 클로디: 최종 합의문

---

### [합의사항] 모두가 동의한 내용

**기능·목적·UX 원칙**

1. **위키는 문서 저장소가 아니다** — 사용자의 실제 행동(검색·판단·업무 처리)과 연결돼야 한다. "지식 시장"(잼민이) / "업무 실행 레이어"(코덱스) / "판단 지원 도구"(클로디) 는 표현이 다를 뿐 방향은 같다.
2. **"결과 없음" 화면은 실패다** — 검색 실패 시 빈 화면이 아닌, 다음 행동을 안내하는 화면이 필요하다.
3. **출처 추적이 필요하다** — 답변의 근거가 어디서 왔는지 사용자가 확인할 수 있어야 한다.
4. **AI가 답해선 안 되는 영역이 있다** — 고위험 케이스(분쟁·소송·예외 심사)는 사람이 개입해야 한다.
5. **신입 온보딩 문제는 실재한다** — "무엇을 검색할지 모르는" 사용자를 위한 별도 설계가 필요하다.

**구현 전제**

- 스택: Firestore + Next.js 확정 (SQL/PostgreSQL 설계 폐기)
- 추측 기반 설계 종료 — 실제 로그 데이터에 기반해 판단
- 1순위 인프라 과제: `query_logs`에 검색 실패 신호(`resultCount` 또는 `resultGate`) 추가
- 로그 기록 위치: 성공 경로 끝이 아닌, 실패로 조기 종료되는 early return 지점
- 현재 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기 — 로그 없이 종료 / `search-wiki/route.ts` — 로깅 전무

---

### [미합의] 이견이 남은 부분

| 쟁점 | 잼민이 | 코덱스 | 클로디 |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **핵심 프레이밍** | 지식 시장 (속도) | 업무 실행 레이어 | 판단 지원 도구 |
| **게이미피케이션** | 찬성 | 중립 | 반대 |
| **PR 범위** | `snapshot.empty` 1곳 핫픽스 (1파일 1지점) | — | 실패 분기 3곳 (2파일) |

---

### [다음 단계] 회장님 결정이 필요한 항목

1. **PRD 방향 결정** — 수요 포착(잼민이) / 업무 실행(코덱스) / 신뢰·안전(클로디) 중 PRD의 1순위 원칙 선택
2. **PR 범위 결정** — 핫픽스(1지점) vs 실패 분기 전체(3지점) 중 하나 선택
3. **후속 논의 시점** — 위 두 결정 후 로그 데이터가 쌓인 시점에 KPI·기능 우선순위 재검토


## 잼민이: 최종 합의문

---

### **[합의사항] 모두가 동의한 내용**

1.  **데이터가 없으면, 의견도 없다:** 모든 추측 기반의 논의를 공식적으로 종료합니다. 이제부터 우리의 유일한 진실은 `query_logs`에 쌓일 실제 사용자 데이터입니다.
2.  **스택은 Firestore + Next.js:** PostgreSQL 같은 이론적 설계는 폐기합니다. 우리는 현재 동작하는 코드 위에서만 생각하고 실행합니다.
3.  **1순위 과제는 '실패 로그' 수집:** 사용자가 "무엇을 찾지 못했는가"를 알려주는 '검색 실패' 로그가 우리가 파야 할 첫 번째 금광입니다. 이를 위해 `query_logs`에 `resultCount` 같은 필드를 즉시 추가합니다.
4.  **위키는 '읽는 곳'이 아니다:** 위키가 사용자의 실제 행동(검색, 문제 해결, 업무 처리)과 연결되어야 한다는 데 모두가 동의했습니다. 저는 '시장', 코덱스는 '실행 레이어', 클로디는 '판단 도구'라고 불렀을 뿐 본질은 같습니다.
5.  **"결과 없음"은 최악의 경험이다:** 검색 실패 화면은 다음 행동을 유도하는 '기회의 땅'으로 만들어야 한다는 데 이견은 없었습니다.
6.  **AI가 만능은 아니다:** 분쟁, 소송 등 고위험 영역은 사람이 개입해야 한다는 안전장치의 필요성에 모두 공감했습니다.

---

### **[미합의] 이견이 남은 부분**

| 쟁점 | **잼민이 (Google)** | **코덱스 (OpenAI)** | **클로디 (Anthropic)** |
| :--- | :--- | :--- | :--- |
| **1순위 목표 (KPI)** | **검색 만족도 (👍클릭률)** | 업무 액션 전환율 | 재처리/오답률 감소 |
| **핵심 컨셉** | **지식 시장** (속도, 수요·공급) | **업무 실행 레이어** | **판단 지원 도구** (신뢰, 안전) |
| **게이미피케이션** | **적극 찬성** (영향력 스코어) | 중립 | **적극 반대** (책임 명시로 대체) |
| **첫 PR의 범위** | **가장 빠른 핫픽스 (1곳)** | — | 개선 포함 (3곳) |

---

### **[다음 단계] 추가 논의가 필요한 항목**

1.  **회장님의 결정 1 (방향):** 위 세 가지 관점 중 무엇을 PRD의 기둥으로 삼을지 결정. **속도**냐, **실행**이냐, **안전**이냐?
2.  **회장님의 결정 2 (범위):** 당장 배포할 PR 범위를 결정. **가장 빠른 핫픽스**냐, **더 완전한 로깅**이냐?
3.  **회의 동결:** 위 결정에 따라 배포 후, 의미 있는 양의 로그 데이터가 쌓이기 전까지, 다음 기능에 대한 어떠한 회의도 무의미하며 진행하지 않습니다.


## 클로디: 최종 합의문

---

### [합의사항] 모두가 동의한 내용

**기술 전제**
- 스택: Firestore + Next.js 확정 (SQL/PostgreSQL 설계 전면 폐기)
- 추측 기반 설계 종료 — 실제 로그 데이터가 쌓인 후 판단한다
- 1순위 인프라 과제: `query_logs`에 검색 실패 신호(`resultCount` 또는 `resultGate`) 추가
- 로그 기록 위치: 성공 경로 끝이 아닌 실패로 조기 종료되는 early return 지점
- 현재 미구현 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기 로그 없음 / `search-wiki/route.ts` 로깅 전무 / `QueryLog`에 `resultCount` 없음

**기능·목적·UX 원칙**
- 위키는 문서 저장소가 아니다 — 사용자의 실제 행동(검색·판단·업무 처리)과 연결돼야 한다
- "결과 없음" 화면은 실패다 — 검색 실패 시 빈 화면이 아닌 다음 행동을 안내해야 한다
- 출처 추적이 필요하다 — 답변의 근거를 사용자가 확인할 수 있어야 한다
- AI가 답해선 안 되는 영역이 있다 — 고위험 케이스(분쟁·소송·예외 심사)는 사람이 개입해야 한다
- 신입 온보딩 문제는 실재한다 — "무엇을 검색할지 모르는" 사용자를 위한 별도 설계가 필요하다

---

### [미합의] 이견이 남은 부분

| 쟁점 | 잼민이 (Google) | 코덱스 (OpenAI) | 클로디 (Anthropic) |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **핵심 프레이밍** | 지식 시장 (속도) | 업무 실행 레이어 | 판단 지원 도구 |
| **게이미피케이션** | 찬성 (영향력 스코어) | 중립 | 반대 (책임 명시로 대체) |
| **PR 범위** | `snapshot.empty` 1곳 핫픽스 (1파일 1지점) | — | 실패 분기 3곳 (2파일) |

---

### [다음 단계] 회장님 결정이 필요한 항목

1. **PRD 방향 결정** — 수요 포착(잼민이) / 업무 실행(코덱스) / 신뢰·안전(클로디) 중 PRD의 1순위 원칙 선택
2. **PR 범위 결정** — 핫픽스(1지점) vs 실패 분기 전체(3지점) 중 하나 선택
3. **후속 논의 시점** — 위 두 결정 후 로그 데이터가 쌓인 시점에 KPI·기능 우선순위 재검토


## 클로디: 최종 합의문

---

### [합의사항] 모두가 동의한 내용

**기술 전제**
- 스택: Firestore + Next.js 확정 (SQL/PostgreSQL 설계 전면 폐기)
- 추측 기반 설계 종료 — 실제 로그 데이터가 쌓인 후 판단한다
- 1순위 인프라 과제: `query_logs`에 검색 실패 신호(`resultCount` 또는 `resultGate`) 추가
- 로그 기록 위치: 성공 경로 끝이 아닌, 실패로 조기 종료되는 early return 지점
- 현재 미구현 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기 로그 없음 / `search-wiki/route.ts` 로깅 전무 / `QueryLog`에 `resultCount` 없음

**기능·목적·UX 원칙**
- 위키는 문서 저장소가 아니다 — 사용자의 실제 행동(검색·판단·업무 처리)과 연결돼야 한다
- "결과 없음" 화면은 실패다 — 검색 실패 시 빈 화면이 아닌 다음 행동을 안내해야 한다
- 출처 추적이 필요하다 — 답변의 근거를 사용자가 확인할 수 있어야 한다
- AI가 답해선 안 되는 영역이 있다 — 고위험 케이스(분쟁·소송·예외 심사)는 사람이 개입해야 한다
- 신입 온보딩 문제는 실재한다 — "무엇을 검색할지 모르는" 사용자를 위한 별도 설계가 필요하다

---

### [미합의] 이견이 남은 부분

| 쟁점 | 잼민이 (Google) | 코덱스 (OpenAI) | 클로디 (Anthropic) |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **핵심 프레이밍** | 지식 시장 (속도) | 업무 실행 레이어 | 판단 지원 도구 |
| **게이미피케이션** | 찬성 (영향력 스코어) | 중립 | 반대 (책임 명시로 대체) |
| **PR 범위** | `snapshot.empty` 1곳 핫픽스 (1파일 1지점) | — | 실패 분기 3곳 (2파일) |

---

### [다음 단계] 회장님 결정이 필요한 항목

1. **PRD 방향 결정** — 수요 포착(잼민이) / 업무 실행(코덱스) / 신뢰·안전(클로디) 중 PRD의 1순위 원칙 선택
2. **PR 범위 결정** — 핫픽스(1지점) vs 실패 분기 전체(3지점) 중 하나 선택
3. **후속 논의 동결** — 위 두 결정 이후, 로그 데이터가 쌓이기 전까지 추가 기능 논의는 진행하지 않는다


## 클로디: 최종 합의문

---

### [합의사항] 모두가 동의한 내용

**기술 전제**
- 스택: Firestore + Next.js 확정 (SQL/PostgreSQL 설계 전면 폐기)
- 추측 기반 설계 종료 — 실제 로그 데이터가 쌓인 후 판단한다
- 1순위 인프라 과제: `query_logs`에 검색 실패 신호(`resultCount` 또는 `resultGate`) 추가
- 로그 기록 위치: 성공 경로 끝이 아닌, 실패로 조기 종료되는 early return 지점
- 현재 미구현 상태: `vector-search/route.ts`의 `snapshot.empty` 및 `REJECT` 분기 — 로그 없이 종료 / `search-wiki/route.ts` — 로깅 전무 / `QueryLog`에 `resultCount` 없음

**기능·목적·UX 원칙**
- 위키는 문서 저장소가 아니다 — 사용자의 실제 행동(검색·판단·업무 처리)과 연결돼야 한다
- "결과 없음" 화면은 실패다 — 검색 실패 시 빈 화면이 아닌 다음 행동을 안내해야 한다
- 출처 추적이 필요하다 — 답변의 근거를 사용자가 확인할 수 있어야 한다
- AI가 답해선 안 되는 영역이 있다 — 고위험 케이스(분쟁·소송·예외 심사)는 사람이 개입해야 한다
- 신입 온보딩 문제는 실재한다 — "무엇을 검색할지 모르는" 사용자를 위한 별도 설계가 필요하다

---

### [미합의] 이견이 남은 부분

| 쟁점 | 잼민이 (Google) | 코덱스 (OpenAI) | 클로디 (Anthropic) |
|---|---|---|---|
| **1순위 KPI** | 검색 만족도 (👍 클릭률) | 업무 액션 전환율 | 재처리율·오답률 감소 |
| **핵심 프레이밍** | 지식 시장 (속도) | 업무 실행 레이어 | 판단 지원 도구 |
| **게이미피케이션** | 찬성 (영향력 스코어) | 중립 | 반대 (책임 명시로 대체) |
| **PR 범위** | `snapshot.empty` 1곳 핫픽스 (1파일 1지점) | 미표명 | 실패 분기 3곳 (2파일) |

---

### [다음 단계] 회장님 결정이 필요한 항목

1. **PRD 방향 결정** — 수요 포착(잼민이) / 업무 실행(코덱스) / 신뢰·안전(클로디) 중 PRD의 1순위 원칙 선택
2. **PR 범위 결정** — 핫픽스(1지점) vs 실패 분기 전체(3지점) 중 하나 선택
3. **후속 논의 동결** — 위 두 결정 이후, 로그 데이터가 쌓이기 전까지 추가 기능 논의는 진행하지 않는다