[TAB-DR-003] TAB 2단계 전략 — 직원 채택과 실용화 (2026-09-07)
웹 리포트
https://turboairbrain.uk/reports/tab-dr-003-2026-09-07/(한국어/中文/English) · 목록:https://turboairbrain.uk/reports/· 직전 리포트: 2026-09-04-TAB-DR-002-프로젝트-진단-리포트
이 리포트의 성격
DR-001·DR-002가 “무엇이 구축됐는가”를 6축으로 채점한 진단이었다면, DR-003은 “왜 직원이 쓰지 않는가”를 규명하고 그 원인을 실제로 제거한 처방·실행 리포트다. 같은 날 트랙 A를 구현·배포했으므로 진단과 조치가 한 문서에 함께 담긴다.
Thesis
TAB의 1단계는 “지식을 모으는 프로젝트”로 성공했다. 그러나 직원 채택은 2026-08-19 정점 이후 사실상 멈췄다 — 원인은 기능 부족이 아니라 신뢰 상실이고, 그 신뢰를 무너뜨린 것은 봇이 볼트의 238개 문서 중 55개만 볼 수 있다는 단일 아키텍처 제약에서 비롯된 60% 답변 실패율이다.
이번 회차에 그 병목(트랙 A)을 실제로 제거해 봇이 접근하는 문서를 55개 → 225개로 넓혔다. 동시에 DR-002가 80점을 부여한 “실행 연결성·직원 채택” 축이 과대평가였음을 확인해 68점으로 정정한다.
시스템은 나아졌지만, 채택은 아직 나아지지 않았다. 이 구분이 이 리포트의 핵심이다.
종합 스코어카드
| # | 평가 축 | 가중치 | DR-002 (09-04) | DR-003 (09-07) | 델타 |
|---|---|---|---|---|---|
| 1 | 지식 자산의 깊이·품질 | 20% | 92 | 92 | → |
| 2 | 데이터 정확성 & 거버넌스 | 20% | 92 | 92 | → |
| 3 | 라이브 시스템 & 접근성 | 20% | 90 | 95 | ↑5 |
| 4 | 시스템 안정성 & 운영 | 15% | 82 | 82 | → |
| 5 | 실행 연결성 & 직원 채택 | 15% | 80 | 73 | ↓7 |
| 6 | 보안 & 접근제어 | 10% | 76 | 84 | ↑8 |
| 종합 (가중평균) | 100% | 87 · A- | 87 · A- | → |
이 표는 하루 안에 두 번 갱신됐다
오전 진단 시점의 점수는 86점(축3 93 · 축5 68 · 축6 76)이었다. 같은 날 트랙 A에 이어 트랙 B 전체와 Power BI 제거, 주간 다이제스트 자동화까지 완료되면서 축 3·6이 올랐고, 축 5도 측정·온보딩 인프라가 갖춰져 68→73으로 일부 회복했다. 아래 「트랙 B 완료 보고」 참고. 진단과 조치가 같은 날 이뤄진 리포트라 점수도 그 결과를 반영한다.
채택 축을 내린 이유 — 정직한 정정
종합은 87로 같지만 축 5(실행 연결성·직원 채택)를 80 → 73으로 내렸다. 시스템이 나빠져서가 아니다. DR-002가 “실행 연결성·직원 채택”에 준 80점이 근거 부족이었음이 이번 전수 조사로 드러났기 때문이다. DR-002는 Nathan·Myra·siwoo·Kevin의 실사용 “사례”를 근거로 80점을 줬지만, 30건 전수 분석 결과 (a) 9월 들어 질문 0건, (b) 8/19 이후 신규 사용자 유입 사실상 0, (c) 답변 실패율 60%가 확인됐다. 사례는 있었지만 지속·확산은 없었다. 점수를 유지하는 것보다 정정하는 것이 이 시리즈의 가치를 지킨다. (당일 오후 측정·온보딩 인프라가 갖춰지며 68 → 73으로 일부 회복했으나, 실제 질문 수가 늘었다는 증거는 아직 없다 — 그건 다음 회차에 확인할 사안이다.)
Argument — 진단
1. 채택은 정점 후 멈췄다
30. Queries/ 전수 조사(30건):
| 시점 | 질문 수 | 고유 사용자 |
|---|---|---|
| 8월 3~14일 | 10건 | 3명 (David 중심) |
| 8월 19일 (정점) | 7건 | 6명 (Nathan·jin·Siwoo Lee·siwoo·Myra·Han) |
| 8월 20~31일 | 9건 | 5명 |
| 9월 1~7일 | 0건 | 0명 |
8월 19일 하루에 6명이 몰린 것은 시연·홍보 효과로 보이며, 이후 신규 사용자 유입이 없고 재방문도 거의 없다. 이는 “쓰다가 줄었다”가 아니라 **“한 번 써보고 안 돌아왔다”**는 패턴이다.
첫 사용자들의 후속 기록이 없다:
- Han — 단종품 부품 대응 프로세스 질문 → “근거 없음” → 이후 기록 없음
- jin — 경쟁사 보증기간 질문 → 부분 답변 → 이후 기록 없음
Key Insight
첫 경험이 실패면 두 번째 방문은 없다. 채택 곡선이 꺾인 지점과 실패 답변이 집중된 지점이 정확히 겹친다.
2. 실패율 60% — 원인은 “지식이 없어서”가 아니었다
30건 중 **18건(60%)**이 “근거 없음 / 데이터 부재 / 근거 부족”을 포함했다. 결정적인 것은 실패한 질문 상당수의 답이 이미 볼트 안에 있었다는 사실이다. Han의 질문에 대한 봇의 답변:
“2026-07_제품마스터스펙_TA_Master_Specs Raw Source에 ‘단종/보류 모델 부록’이 존재한다는 언급은 있으나, 그 부록의 실제 내용은 이번 컨텍스트에 포함되어 있지 않습니다.”
봇은 **“자료가 있다는 건 알지만 읽을 수 없다”**고 스스로 진단했다. 지식의 부재가 아니라 접근의 부재였다.
3. 근본 원인 — 봇의 뇌가 55개 파일뿐이었다
rebuild-site.ps1 2.6 스텝의 컨텍스트 번들 로직: 20. Wiki + 30. Queries 중 tab-project 태그를 가진 것만, site-ask 제외 → 55개 파일 583KB.
봇이 볼 수 없던 것: 10. Raw Sources 168개 전부(1,418KB) — 제품 마스터스펙·가격표·제품 카탈로그(26), TA Service 서비스/사용자 매뉴얼(58), K-Master(6), 외부 기사(78).
4. 아키텍처가 성장의 벽에 부딪혀 있었다
583KB(≈239K 토큰)를 매 질문마다 통째로 주입하는 구조는 (1) 확장 불가 — Raw Source 추가 시 컨텍스트 초과, (2) 정확도 저하 — 55개 중 관련 문서는 보통 2~3개, (3) 비용 낭비를 동시에 안고 있었다.
5. 내부 지식이 절반 이상 비어 있다
13개 부서 폴더 중 7개가 README만 있고 문서 0개(재무·운영물류·인사·고객CRM·프로세스SOP·전략기획·컴플라이언스). 그런데 직원 질문이 정확히 이 빈 곳을 향했다 — Han은 09_프로세스_SOP, siwoo의 출고 질문은 06_운영_물류, Nathan의 신규업체 리스트는 08_고객_CRM이다.
6. 직원이 원한 것은 “지식”이 아니라 “결과물”이었다
| 의도 유형 | 건수 | 대표 사례 | 성공률 |
|---|---|---|---|
| 산출물 요청형 | 6건 | ”제안 PPT 작성”(Kevin), “신규 업체 리스트”(Nathan), “셀링포인트”(Sean) | 낮음 |
| 데이터 조회형 | 12건 | ”이번주 출고 수량”, “Restocked 통계” | 중간 |
| 지식 질의형 | 12건 | ”HFC 규제 수치”, “경쟁사 보증기간” | 높음 |
가장 잘 답한 것은 지식 질의형(위키가 강한 영역)이고, 가장 못 답한 것은 직원이 실제로 가장 원한 산출물 요청형이다.
Key Insight — 이 프로젝트 최대 성과가 말해주는 것
Kevin 사장님이
/feedback으로 요청한 것은 조회가 아니라 **“Sushi Hub 전략적 파트너십 제안 PPT”**였고, 실제로 10슬라이드 PPTX + 3개국어 웹 제안서가 만들어졌다. 최고 의사결정자가 스스로 증명한 진짜 수요는 “산출물 생성”이다.
트랙 A 완료 보고 (2026-09-07 구현·배포)
진단 즉시 최우선 병목인 트랙 A를 구현해 프로덕션에 배포했다.
A1. search_wiki / read_wiki_doc 도구 신설 — 병목 제거
functions/api/_wiki-search.js신규. KV에rawdoc:{id}(문서 전문) +rawindex:v1(제목·폴더·frontmatter·본문 앞 1200자) 구조로 적재하고 도구 호출로 검색·열람한다.rebuild-site.ps1스텝 2.65 신설 — 225개 문서 인덱싱 완료(Raw Sources 155 + Wiki 70). 제외된 13개는 내용이 없는README.md스텁으로, 실제 지식 손실은 없다.- 봇이 접근하는 문서: 55개 → 225개 (4.1배)
- 전량 주입을 키우지 않고 검색으로 전환한 이유: 583KB가 이미 매 질문 ≈239K 토큰이라 1.4MB를 더하면 컨텍스트를 초과하고, 관련 문서 2~3개가 200개 사이에 묻힌다.
- 콘텐츠 해시 매니페스트로 변경분만 업로드 — 배포 직후 실행에서
0 changed, no upload needed확인. 매시간 예약 실행에 부담이 없다. - 한국어 교착어 대응으로 어간 접두어 매칭(길이비율 가중)을 구현하고, 무관 문서 유입을 막기 위해 검색어 절반 이상 매칭 + 최고점 25% 이상 2단 관련성 하한선을 적용했다.
A2. 회귀 테스트셋 — 18/18 통과
scripts/test-wiki-search.mjs신규. 실제 실패 질문 16건을 케이스화하고, 여기에 “볼트에 없어야 정상”인 지식공백 2건(인사 정책, 재무제표)을 함께 넣었다.- 후자를 넣은 이유: 검색이 느슨해져 무관한 문서를 물어오면 A3의 정직성 경로가 무너지기 때문이다. 실제로 이 2건이 초기 스코어링에서 “정책” 한 단어로 8건을 반환하던 문제를 잡아냈다.
- 실측 검증: Han이 “근거 없음”을 받았던 질문을 실제 KV 인덱스로 재실행하니
2026-07_제품마스터스펙_TA_Master_Specs가 1순위로 나온다 — 봇이 “존재는 아는데 못 읽는다”고 했던 바로 그 문서다.
A3. “근거 없음”을 막다른 길에서 다음 행동으로
- 시스템 프롬프트 규칙 16·17 신설: 근거 없음을 선언하기 전
search_wiki최소 1회 호출 필수. - 그래도 근거가 없으면 (a) 어떤 검색어로 무엇을 확인했는지, (b) 어떤 자료가 볼트에 추가되면 답할 수 있는지, (c) 질문자가 지금 대신 확인할 경로를 답변에 적고, 방문자에게 보이지 않는 블록으로 필요 자료를 기록한다.
- 그 블록은 관리자에게 자동 메일로 발송되고 KV 레코드에
knowledgeGap으로 남는다 → 실패가 지식 수집 요청으로 자동 전환되어 볼트가 스스로 성장한다. - 메일에는 “볼트 검색을 실제로 수행했는지” 여부도 함께 실려, 규칙 16을 건너뛴 경우를 사후에 잡아낼 수 있다.
A4. 답변 평가 루프
functions/api/rate.js신규 +ask.html에 👍/👎 바(3개국어). 👎는 한 줄 사유를 받아 답변 레코드에rating/ratingReason으로 기록하고stats:ratings집계 키를 갱신한다.- 지금까지 답변 품질은 손으로 문서를 읽어야만 알 수 있었다. 이제 주 단위로 볼 수 있는 1차 지표가 생겼다.
부수 작업 — 답변보기 정비
- 신규 주제
시스템·IT추가, 카테고리 미지정 21건 전부 분류(sales 10·strategy 6·market 6·product 3·kpi 2·process 2·system 1·regulation 1) → “기타” 표시 문서 0건. - 질문 미리보기 번역 19건, 본문 zh/en 번역 2건 신규 작성 → 31개 문서 전부 카테고리·제목·질문·본문 번역 결손 0건.
구현 중 발견·수정한 버그 2건
- PowerShell 5.1의
ConvertTo-Json이 최상위 배열에서 실패 — 항목 2개짜리로도 재현되며 파이프·-InputObject,[ordered]·[pscustomobject]모두 동일. 중첩 배열은 정상이라 항목별 직렬화 후 조립하는 방식으로 우회했다. Get-Content -Raw가 문자열에 PSObject 속성을 덧붙여 JSON이"value":{"value":"..."}형태로 중첩됨 → wrangler가 파일 전체를 거부했다.[string]캐스팅으로 해결. 두 버그 모두 코드에 사유를 주석으로 남겼다.
트랙 A의 한계 (정직한 유보)
- 봇의 종단 응답 품질은 아직 미검증이다. staging preview 환경에
ANTHROPIC_API_KEY시크릿이 없어 실제 봇 호출 테스트를 하지 못했고, 프로덕션은 Cloudflare Access 뒤에 있어 자동 검증이 막힌다. 검증 범위는 검색 경로(실제 KV 인덱스 기준 회귀 6/6, 로컬 18/18)와 문서 조회 경로까지다. - 따라서 축 3의 상승(+3)은 “봇이 접근할 수 있는 지식이 4.1배로 늘었고 그 경로가 실측 검증됐다”는 사실에 근거한 것이지, “답변 품질이 개선됐다”는 검증에 근거한 것이 아니다. 다음 회차에 실사용 데이터로 확인해야 한다.
트랙 B 완료 보고 + Power BI 제거 + 주간 다이제스트 (같은 날 오후)
트랙 A 배포 후, 같은 날 트랙 B 전체(B1~B3)와 3회차 연속 이월돼 있던 보안 갭, 그리고 트랙 C의 첫 항목까지 처리했다.
B1. 사용자 식별 표준화 — 측정의 전제조건
static-pages/people.json신설(정본 명부 8명). 조사 시점에 30건의 질문이 13가지 이름 표기로 흩어져 있어(Nathan 매니저/매니져, siwoo/Siwoo/Siwoo Lee, KEVIN/Kevin 사장님) 사용량 측정 자체가 불가능했다.- 입력 경로를 고쳤다 —
ask.html의 하드코딩 3인 드롭다운을 명부 기반 동적 생성으로 바꾸고, Cloudflare Access 로그인 이메일로 본인을 자동 선택하게 했다. 이름을 타이핑하는 구조 자체가 분산의 원인이었다. - 과거 기록은
aliases매핑으로 렌더 시점에 통합 — 볼트 원본은 수정하지 않았다. 기록은 불변, 표시할 때만 정본 이름을 쓴다. - 결과: 13가지 표기 → 8명으로 정상 병합.
B2. 사용량 대시보드 — /usage
- 이 리포트가 손으로 세야 했던 숫자(30건 / 60% / 9월 0건)를 매 빌드마다 자동 집계한다. 첫 실행이 이 리포트의 수치를 그대로 재현했다.
- 지표: 누적 질문 · 고유 사용자 · 답변 실패율 · 최근 30일 + 월별 추이 · 사용자별 · 주제별 · 답하지 못한 질문 목록(지식 보강 대상) · 최근 질문.
- 월별 차트는 빈 달도 표시하도록 만들었다 — 9월 공백이 바로 이 대시보드가 드러내야 할 신호이기 때문이다.
- 원천은 KV가 아니라 볼트다:
sync-queries.ps1이query:*레코드를 10분마다 볼트로 옮기고 삭제해 KV에는 이력이 남지 않는다(실측 0건).
B3. 부서별 온보딩 — /start
- DR-001부터 3회차 연속 미착수였던 “직원 온보딩 1페이지”를 해소했다. 영업 / 서비스·부품 / 물류·재고 / 경영 4개 탭에 실제 질문 예시 26개, 트랙 A로 새로 답할 수 있게 된 8개는
NEW배지로 구분. - 홈 네비 최상단에 “시작하기”를 넣어 첫 방문자 동선을 만들었다. 지금까지 모든 사용자가
/ask를 스스로 발견했지 안내를 받은 게 아니었다.
Power BI 대시보드 제거 — DR-001부터 3회차 이월된 최대 보안 갭 해소
- David 판단으로 Power BI 페이지를 사이트에서 완전히 제거했다(TAB·K-Master 대시보드가 같은 보고를 대체). 파일·빌드 스텝·문구를 모두 정리하고 스테이징에서 404를 확인했다.
- 이로써 “완전공개 웹에 게시 링크를 URL 비공개에만 의존해 노출”하던 갭이 닫혔다. DR-001의 최우선 즉시 항목이 DR-002·DR-003까지 이월돼 있었는데, Embedded 전환이 아니라 제거로 해소된 것이다 — 더 이상 지킬 필요가 없는 자산을 지키려 애쓰는 대신 없앤 쪽이 옳았다.
- 대시보드 허브의 3번째 카드를 사용 현황으로 교체해 3칸 그리드를 유지했다.
- 과거 답변과 발행된 진단 리포트 안의 Power BI 언급은 역사 기록이므로 수정하지 않았다.
트랙 C 착수 — 주간 동향 자동 발행 (/digest)
DR-003 로드맵의 단기(트랙 C) 항목 중 **“시장 인텔리전스 발행”**을 먼저 구현했다. /market-scan이 이미 주 단위로 자료를 모으는데 볼트에만 쌓이고 직원은 볼 수 없다는 게 지적 사항이었다.
- 아키텍처 — 에이전트는 마크다운 1개만 쓴다. 주 52회 반복되므로 렌더·배포를 전부 자동화했다:
weekly-metrics.mjs(KPI 규칙을 코드에 고정한 실적 집계) → 에이전트가 마크다운 작성 →generate-digests.ps1렌더 → 배포. - 실적을 에이전트가 계산하지 않는다 — 매주 사람이나 AI가 시트를 재해석하면 드리프트가 생기고, 그게 2026-08 매출 인식 규칙 분쟁이 났던 경로다. 발주 중단·신규 활성 딜러 탐지도 스크립트가 자동 수행한다.
- 마켓스캔
digest모드 신설 — 최근 7일 하드 윈도우, 5축, Inbox 파일 없음(주 52회면 연 260~520건이 미처리로 남는다 — 2026-08-31에 505건 방치로 실제 겪은 실패 모드), 항목마다 “우리에게 주는 의미” 필수. - 예약 실행: 매주 월 09:00 → 헤드리스
claude -p "/weekly-digest"→ 새 다이제스트 확인 시에만 프로덕션 배포. 별도 API 키 없이 기존 Claude Code 인증 재사용. - 1호 발행 완료(TAB-WD-001, 8/31~9/6): 매출
171,376(전주 -34.2%), **exQLD82,488(-54.3%)**, 수주 95건(-8.7%·전년 +58.3%). 발주 중단 딜러 8곳 자동 탐지. 경쟁사 축은 “이번 주 확인된 새 동향 없음”으로 정직 기록.
같은 날 발생·수정한 UI 버그 3건
배포 속도를 낸 대가로 프로덕션에 UI 버그가 3건 나갔고, 모두 David의 스크린샷 제보로 당일 수정했다. 셋 다 같은 뿌리 — 새 페이지를 만들며 기존 공유 자산의 계약을 확인하지 않은 것이다.
| 버그 | 근본 원인 |
|---|---|
/usage 전체 무스타일 | 공유 $css가 순수 CSS가 아니라 <link>+<style> 포함 head 조각인데 <style>로 한 번 더 감쌌다 → :root 토큰 블록이 CSS 파서 오류 복구에 통째로 폐기 |
| 홈 브랜드 2줄 깨짐 | .brand가 flex인데 텍스트가 익명 flex 항목이라 축소 허용. 내가 네비를 6→7개로 늘리며 1080px 고정 폭에서 밀려남 |
| ”지표·KPI” 칩만 큰 박스 | 주제 칩은 class="topic kpi"인데 usage 지표 카드에 **전역 .kpi**를 정의 → 칩이 카드 스타일을 덮어씀 |
이 3건이 드러낸 검증의 허점
세 번 모두 배포 전 검사(HTTP 200, 정규식 지표 추출, 구조 검증)를 통과했다. 값이 HTML 안에 있다는 것과 화면에 제대로 그려진다는 것은 다른 문제다. 이후 검증에 “style 블록 중첩 없음 ·
:root토큰 생존 · 본문 CSS 유출 없음 · 클래스 충돌 없음”을 추가했지만, 에이전트가 렌더링을 직접 볼 수 없다는 근본 제약은 남는다 — UI 변경은 사람 확인이 필요하다는 것이 이 리포트의 실전 교훈이다.
정책 — 이름만 표시
David 지시로 부서명·직급명을 사용자 대면 화면에 표시하지 않는다(명시 요청 시 예외). people.json의 dept는 데이터로 유지하되 렌더에 쓰지 않고, 과거 기록의 직급 표기는 렌더 시점에 정본 이름으로 정규화한다. 단, 매니저 최종확인(Confirmed)(업무 용어), Sushi Hub 사장님(고객사 임원) 같은 본문 내용은 일괄 치환하지 않았다 — 전역 치환했다면 함께 훼손됐을 것이다.
Counter-arguments
Bias Check
- 표본이 작다 — 9월 무질문 7일을 “채택 정지”로 단정하는 것은 과할 수 있다. 성수기·휴가·단순히 물어볼 일이 없었을 가능성도 있다. 다만 신규 사용자 유입이 8/19 이후 사실상 0이라는 사실은 표본 크기와 무관하게 유효하다.
- 실패율 60%의 해석 — “근거 없음”이 포함됐다고 전부 실패는 아니다. 일부는 답변의 일부 항목만 근거가 없었다. 다만 직원 체감상 “일부라도 모른다”는 답은 실패로 인식된다는 점에서 유효한 대리지표다.
- 자기 평가의 한계 — 이 분석을 쓴 에이전트가 트랙 A를 직접 구현했다. 자기 작업을 자기가 채점하는 이해상충이 있으므로, 축 3의 상승폭을 +3으로 보수적으로 잡고 미검증 범위를 위에 명시했다. 반대로 축 5는 자신이 이전 회차에 준 점수를 스스로 12점 내렸다.
- 검색 전환의 잔여 위험 — 전량 주입은 “항상 모든 문서를 본다”는 일관성을 보장했다. 검색 실패 시 오히려 더 나쁜 답이 나올 수 있어, 핵심 위키 55개는 상주시키고 원본만 검색하는 하이브리드로 구성했다.
Gap → 앞으로 해야 할 일
즉시 (0–1개월) — 트랙 B (당일 완료)
사용자 식별 표준화→ ✅ 당일 완료.people.json정본 명부 + 로그인 이메일 자동 선택. 13가지 표기 → 8명.사용량 대시보드→ ✅ 당일 완료./usage— 질문 수·고유 사용자·실패율·월별 추이·답하지 못한 질문 목록.부서별 온보딩 카드→ ✅ 당일 완료./start4개 부서 탭·예시 26개.[DR-001부터 3회차 이월분 해소]팀 시연은 David 몫으로 남음.Power BI Embedded 전환 착수→ ✅ 당일 해소(제거로).[DR-001부터 3회차 이월분 해소]전환이 아니라 페이지 자체를 제거해 노출을 없앴다.- staging(
*.pages.dev) 도메인을 Access 보호 범위에 포함 —[DR-002 신규 발견, 여전히 미해결]Cloudflare 대시보드 조작이라 David 몫. 5분 작업. - 팀 시연 —
/start페이지는 만들어졌지만 실제로 직원들에게 보여주는 일은 남아 있다. 페이지가 있는 것과 사람들이 아는 것은 다르다.
단기 (1–3개월) — 트랙 C (1개 항목 당일 완료)
- 보고서·발표자료 생성기 — Sushi Hub 성공 패턴의 제품화. 목적·대상·기간 선택 → 데이터 조회 → 초안 생성 → 웹 슬라이드(3개국어) + PPTX.
html-ppt스킬과 제안서 발행 경로가 이미 있어 조립에 가깝다. - 데이터 셀프서비스 — 자연어 → 표 → CSV/Excel 다운로드.
- 딜러 360 뷰 — 딜러명 하나로 매출추이·주문이력·리베이트 잔여·서비스 이력·재고·경쟁사 취급·신용 리스크를 한 화면에. 영업사원이 미팅 5분 전에 여는 화면.
시장 인텔리전스 발행→ ✅ 당일 완료./digest주간 동향 보고서 — 매주 월 09:00 자동 생성·배포, 1호 발행 완료. 다만 헤드리스 에이전트 실행은 9/14 첫 실전 검증이 남았다.- 랩탑 SPOF 완화 — 전면 이전 전 단계로 장애 자동 알림(Slack/이메일)부터.
[DR-002 이월] - 역할 기반 접근제어(RBAC) 설계 착수 — 재무·인사 데이터 편입 전인 지금이 가장 저렴하다.
[DR-001부터 이월]
중기 (3–6개월) — 트랙 D + 조직
- 내부 지식 채우기 — 직원 질문이 향한 순서로:
09_프로세스_SOP→08_고객_CRM→06_운영_물류→03_제품과서비스심화(원본 이미 보유, 컴파일만 필요). 재무·인사는 RBAC 이후. - 운영 2인 이상 체제 — bus factor 1은 3회차 연속 동일.
- 랩탑 → 상시 서버 완전 이전 — 사용자가 별도 프로젝트로 미룬 항목이나, DR-002의 두 차례 장애가 긴급도를 실증했다.
- 전략 플레이북 수치 1차 출처 검증 —
[DR-001부터 이월]
새 아이디어 (검토 대상)
| 아이디어 | 설명 | 난이도 | 임팩트 |
|---|---|---|---|
| 경쟁 입찰 Battle Card | 경쟁사명 → 우위/열위/대응 논리 자동 생성 | 낮 | 높음 |
| 고객 미팅 1분 브리핑 | 딜러명 → 미팅 전 알아야 할 것 요약 | 낮 | 높음 |
| 딜러 이탈 조기경보 | 발주 패턴 급감 딜러 자동 감지 → 담당자 알림 | 중 | 높음 |
| 제품 추천 엔진 | 고객 요구(용량·용도·예산) → 모델 추천 + 재고 확인 | 중 | 높음 |
| 재고-수요 매칭 알림 | 과잉 재고 모델을 최근 수요 딜러와 매칭 | 중 | 중 |
| 이메일 초안 작성 | 딜러 응대·클레임 답변·프로모션 안내 초안 | 낮 | 중 |
| 가격 시뮬레이터 | 할인·리베이트 적용 시 마진 즉시 계산 | 중 | 중 |
| 서비스 품질 리포트 | TA Service 로그 기반 모델별 고장 패턴 분석 | 중 | 중 |
| 모바일 최적화 점검 | 영업사원은 현장에서 폰으로 쓴다 — 현재 미검증 | 낮 | 중 |
직원 실전 팁 (이번 회차 신규)
트랙 A로 물어볼 수 있는 범위가 크게 넓어졌다. 이전에 “근거 없음”을 받았던 주제도 다시 시도해볼 가치가 있다.
- 제품 스펙·단종 모델·부품 호환을 물어봐도 된다 — 제품 마스터스펙 원본을 이제 봇이 직접 읽는다.
- 서비스·부품 매뉴얼 내용을 물어봐도 된다 — TA Service 매뉴얼 58건이 검색 대상에 들어왔다. 단 질문에 “부품”/“서비스”/“AS” 등을 명시해야 한다.
- 가격표·제품 카탈로그·조직도·사내 가이드북도 검색된다.
- 답변이 아쉬우면 👎를 눌러 한 줄만 남겨달라 — 이것이 다음 개선의 우선순위가 된다.
- “근거 없음”을 받아도 그냥 닫지 말 것 — 이제 봇이 “어떤 자료가 있으면 답할 수 있는지”를 함께 알려주고, 그 요청이 관리자에게 자동으로 전달된다.
성공 지표 (2026-12-07 시점 목표)
| 지표 | 현재 | 목표 |
|---|---|---|
| 월간 질문 수 | 9건(8월) → 0건(9월) | 60건 이상 |
| 월간 고유 사용자 | 최대 6명 | 10명 이상, 3개월 연속 |
| 답변 실패율 | 60% | 20% 이하 |
| 생성된 업무 산출물 | 1건(Sushi Hub) | 월 4건 이상 |
| 봇 접근 가능 문서 | 55 → 225 (달성) | 신규 자료 상시 반영 |
| 사용량 측정 가능 여부 | 불가(이름 13가지) → 가능(/usage, 달성) | 주 단위 모니터링 |
| 온보딩 경로 | 없음 → /start (달성) | 팀 시연 완료 |
| 주간 동향 발행 | 없음 → 매주 월 09:00 자동 (1호 발행) | 12주 연속 무중단 |
References
- 2026-09-04-TAB-DR-002-프로젝트-진단-리포트 — 직전 회차 87/100, 축별 델타 비교 기준선
- 2026-08-13-TAB-DR-001-프로젝트-진단-리포트 — 최초 진단 81/100
30. Queries/전수 30건 — 채택 곡선·실패율·의도 분류의 원천quartz-site/functions/api/_wiki-search.js·scripts/test-wiki-search.mjs— 트랙 A 구현·검증quartz-site/rebuild-site.ps1스텝 2.6/2.65 — 컨텍스트 번들과 신설 검색 인덱스- Cloudflare Pages Function + Claude API로 Wiki 기반 Q&A 봇 만들기
10. Raw Sources/19. TAB Project/00_TAB_프로젝트_선언문.md— 원래 목표 대비 진척 비교 기준