2026-09-04-TAB-DR-002-프로젝트-진단-리포트

[TAB-DR-002] TAB 프로젝트 진단 리포트 (2026-09-04)

웹 리포트

https://turboairbrain.uk/reports/tab-dr-002-2026-09-04/ (한국어/中文/English) · 목록: https://turboairbrain.uk/reports/ · 직전 리포트: 2026-08-13-TAB-DR-001-프로젝트-진단-리포트

Thesis

지식 자산·데이터 정확성·라이브 시스템·보안 4개 축이 모두 강점 구간으로 올라서며 종합 81 → 87점 (B+ → A-) 로 개선됐다. DR-001의 최우선 리스크였던 “공유 비밀번호 하나뿐”이 Cloudflare Access Zero Trust로 실제로 해소됐고, 직원 채택도 가설이 아니라 Nathan·Myra·siwoo·Kevin 등 실사용 사례로 검증됐다. 남은 최대 과제는 여전히 “랩탑 1대에 전체 파이프라인이 의존”하는 구조적 SPOF이며, 이번 회차 동안 그 SPOF가 실제로 두 차례(8/26, 8/31) 장애를 일으켰다는 사실이 이를 뒷받침한다.

종합 스코어카드

#	평가 축	가중치	DR-001 (08-13)	DR-002 (09-04)	델타
1	지식 자산의 깊이·품질	20%	88	92	↑4
2	데이터 정확성 & 거버넌스	20%	90	92	↑2
3	라이브 시스템 & 접근성	20%	82	90	↑8
4	시스템 안정성 & 운영	15%	78	82	↑4
5	실행 연결성 & 직원 채택	15%	72	80	↑8
6	보안 & 접근제어	10%	62	76	↑14
	종합 (가중평균)	100%	81 · B+	87 · A-	↑6

Argument

1. 지식 자산의 깊이·품질 — 88 → 92

• Raw Sources 91 → 168(+84%), Wiki 51 → 70(+37%) — 3주 만에 규모가 거의 배가.
• K-Master(신규 저가형 브랜드)·TA Service(애프터서비스·부품판매)를 /drive-onboard 스킬로 온보딩 — Turbo Air 단일 브랜드 지식베이스에서 3개 사업영역을 포괄하는 구조로 확장.
• Stock/Serial/Product 3개 데이터 카탈로그 신규 작성 — 재고·유닛 단위 로그·SKU 마스터까지 커버, DR-001에는 없던 딜러·제품 드릴다운 분석의 데이터 기반 마련.
• Turbo Air 조직도, Internal Guide Book(Siwoo 작성) 인제스트로 내부 운영 지식도 편입.
• market-scan 스킬에 Step 0.5(내부 신호 기반 검색 타겟팅) 신설·첫 실행 — 실제 판매실적 이상신호(VIC 발주 -24%)와 경쟁사 추적 공백(Panasonic)을 근거로 검색해 3건 인제스트, 과대주장(HFC 규제 기사) 1건은 스스로 교정.

2. 데이터 정확성 & 거버넌스 — 90 → 92

• 신규 데이터 카탈로그 3종 모두 confidence/verificationStatus 체계 유지.
• 실제 데이터 오류가 거버넌스 루프로 실제 발견·수정된 사례 — Restaurant Equipment Online 답변 오류(8/26): /ask의 SALES_KEYWORDS가 한/영만 있고 중국어가 빠져 있어 중국어 질문엔 LIVE SALES DATA 자체가 주어지지 않았던 근본원인을 규명하고 3개국어 키워드를 보강 — “사이트가 3개 언어면 키워드 게이트도 3개 언어”라는 재사용 가능한 교훈 문서화.
• Inbox 오염(TA Service 온보딩 사고로 유입된 505개 잔해 파일) 정리 + 전체 lint 수행(9/2).
• market-scan 자기교정 사례(HFC 기사 과대주장 인지 및 정정)는 “확인된 사실/추정 엄격 구분” 원칙이 실제로 작동함을 보여줌.

3. 라이브 시스템 & 접근성 — 82 → 90

• TAB 대시보드가 3탭 → 9탭(오늘의현황/실적종합/연도별비교/딜러딥다이브/리베이트/랭킹/서비스/부품판매/재고)으로 확장, 전 탭 3개국어 + 매시간 자동 동기화.
• K-Master Dashboard, TA Service Dashboard 신설 — 브랜드별 독립 라이브 시스템.
• DR-001이 지적한 “딜러·제품별 드릴다운 없음” 갭이 재고 탭(브랜치·카테고리·모델별 드릴다운) + Stock/Serial/Product 카탈로그로 상당 부분 해소.
• 로그인 이메일 캡처(whoami) + 질문/답변에 이메일 병기 + 답변 업데이트 시 자동 알림메일 — 익명 조회에서 “누가 무엇을 물었나”를 추적 가능한 구조로 전환.
• /ask 입력 글자수 제한 2,000→10,000자로 상향(실사용 피드백 반영).

4. 시스템 안정성 & 운영 — 78 → 82

개선된 것:

• 노트북 절전 중 예약 재빌드 누락 문제 — WakeToRun 활성화로 근본 수정(DR-001 “즉시” 항목 해소).
• 랩탑 고장 대비 재해복구 감사 수행 + rebuild-site.ps1 자동 git push(3개 저장소) + TAB 프로젝트 재해복구 런북 (랩탑 고장 대비) 신설(DR-001 “즉시” 항목 해소) — 감사 과정에서 “Google Drive에 동기화 중이라 믿었던 것이 실제로는 전혀 동기화되지 않고 있었다”는 심각한 오해도 함께 발견·시정.
• 빌드/테스트-실배포 분리(Cloudflare Pages staging 브랜치, -Environment production|staging) 도입.

여전히 리스크로 남은 것 (그리고 실제로 터진 것):

• 8/26 — 수동 배포와 정시 스케줄 재빌드가 동시에 content/·public/을 건드려 프로덕션이 몇 분간 488/1,352 파일(위키·답변 대부분 누락)로 노출된 사고 발생. rebuild.lock(OS 배타적 파일 락)으로 근본 수정.
• 8/31 — TA Service 드라이브 온보딩 시 “개별 티켓/사진 제외” 규칙이 자동 동기화 스크립트에 반영되지 않아, 매 실행마다 1,800여 개 파일을 재적재하며 rebuild.lock을 장시간 점유 → 프로덕션 자동배포가 약 4시간 중단. excludeFolderIds 지원 추가로 근본 수정.
• 두 사고 모두 당일 발견·근본원인 규명·재발방지 코드까지 완료된 점은 운영 성숙도의 증거이지만, 동시에 “노트북 1대 + 단일 프로세스”라는 구조적 SPOF가 자동화 범위가 커질수록 더 자주 부딪히는 벽이 되고 있음을 보여준다. DR-001의 “동기화를 상시 서버로 이전”(단기 항목)은 사용자가 이번 범위에서 명시적으로 제외해 여전히 미착수.

5. 실행 연결성 & 직원 채택 — 72 → 80

DR-001은 “채택 미검증”을 핵심 리스크로 꼽았다. 이번 회차엔 실사용 증거가 다수 확보됐다:

• Nathan(사장), Myra, siwoo(NSW 영업), Kevin이 실제 업무 질문을 /ask에 던진 기록이 다수 확인됨(딜러 침투 분석, 매출 조회, 피드백 등).
• /ask 결과물이 실제 사업 산출물로 이어진 사례 — Sushi Hub 전략적 파트너십 제안 PPT.
• Kevin의 실사용 중 발견된 버그(글자수 제한)가 즉시 수정으로 이어지는 피드백 루프가 실제로 작동.
• 답변 업데이트 시 질문자에게 자동 알림메일 — “한 번 묻고 끝”이 아니라 재방문을 유도하는 구조로 개선.

아직 없는 것: 사용량 집계 지표(질문 수·재방문율·요일/시간대 패턴 같은 대시보드)와 공식 온보딩 문서·팀 시연 — DR-001 “즉시” 로드맵 항목이었으나 이번 회차에도 착수 근거를 찾지 못함.

6. 보안 & 접근제어 — 62 → 76

DR-001의 최우선(critical) 항목이 가장 크게 개선됐다:

• Cloudflare Access(Zero Trust) 도입(8/25) — 기존 공유 Basic Auth를 완전히 대체, One-time PIN 이메일 로그인 + @turboairinc.com.au 도메인 제한. 향후 파트너사 도메인 추가도 정책 규칙만 늘리면 되는 구조.
• 로그인 이메일이 JWT claim에서 안정적으로 추출되도록 보강(getAccessEmail() 공용 헬퍼) — 인증뿐 아니라 “누가 로그인했는지”를 실제로 추적 가능.

아직 남은 갭:

• Power BI Embedded 전환 미착수 — 여전히 완전 공개 “웹에 게시” 링크를 iframe으로 감싼 상태(DR-001 “즉시” 항목, 여전히 미해결).
• 역할 기반 접근제어(RBAC) 없음 — @turboairinc.com.au 도메인이면 전원 동일 권한. 재무(05_재무)·인사(07_인사) 데이터가 향후 편입되면 그대로 위험.
• 신규 발견(미해결): staging 브랜치 도입(8/26) 과정에서 *.pages.dev 도메인 전체(신규 고정 staging 별칭 포함)가 Cloudflare Access 인증 없이 그대로 노출된다는 사실을 발견 — Access의 Destination이 커스텀 도메인(turboairbrain.uk) 하나만 지정돼 있었기 때문. staging 도입으로 새로 생긴 문제는 아니지만(과거 프로덕션 해시 URL도 동일), 예측 가능한 고정 별칭이 생기며 노출 위험이 커졌다. 대시보드 조작(Access Application Destination에 와일드카드 추가)이 필요해 사용자 몫으로 남아 있다.

Counter-arguments / Bias Check

Bias Check

• 채점자 = 시스템 제작자: 이 리포트를 쓴 에이전트(Claude)가 지난 3주간 대부분의 변경을 직접 수행했다 — 자기 작업을 자기가 채점하는 구조적 이해상충이 있다. 완화책으로 이번 회차엔 실제 프로덕션 장애 2건을 “숨기지 않고” 안정성 축 점수에 직접 반영했고(78→82로 소폭 개선에 그침, 8점 이상 올리지 않음), 미해결 갭(Power BI, RBAC, staging 노출)을 로드맵에서 삭제하지 않고 그대로 이월했다.
• 가중치 자체의 자의성: 6축·가중치는 DR-001에서 그대로 유지했다(변경 사유 없음) — “보안 10%“가 실제 리스크 크기 대비 낮게 잡혀 있을 수 있다는 반론이 가능하다.
• “실사용 검증”의 표본 크기: 실행 연결성 축을 72→80으로 올린 근거인 Nathan/Myra/siwoo/Kevin 4인의 사용 사례는 정성적 일화이지 정량 지표가 아니다 — 이번 회차에도 사용량 집계 대시보드가 없어 “전사 채택률”은 여전히 추정치가 아니라 사실상 미측정 상태다.
• 데이터 공백: 이번 리포트의 모든 수치는 find | wc -l 실측·log.md 기록 대조로 확인했으나, 프로덕션 장애 2건의 “약 4시간”·“몇 분간” 같은 지속시간은 로그 타임스탬프 기반 추정치이며 정밀 측정은 아니다.

Gap → 앞으로 해야 할 일

이번 리포트는 이 섹션에 가장 많은 비중을 뒀다 (사용자 명시 요청)

아래 로드맵은 “영향 대비 난이도”뿐 아니라 DR-001 대비 무엇이 실제로 해소됐고, 무엇이 그대로 이월됐고, 무엇이 새로 발견됐는지를 항목마다 명시한다.

즉시 (0–1개월)

1. Power BI 완전공개 링크 → Embedded 전환 착수 — [이월 · DR-001부터 미착수] 3주 전과 동일하게 아직 스펙조차 확정되지 않은 유일한 즉시 항목. 사용 라이선스 등급 확인부터 시작해야 한다.
2. staging(*.pages.dev) 도메인을 Cloudflare Access 보호 범위에 포함 — [신규 발견, 8/26] Access Application의 Destination에 *.turboairbrain-wiki.pages.dev 와일드카드 추가. 대시보드 조작 5분이면 끝나는 작업인데 아직 방치돼 있다 — 우선순위 대비 노력이 가장 저렴한 항목.
3. 사용량 지표 최소 버전 착수 — 질문 수·활성 사용자·요일별 분포를 KV 로그에서 집계하는 간단한 카운터만이라도(정교한 분석 대시보드 이전 단계). 실행 연결성 축의 “정성적 일화 → 정량 지표” 전환의 첫 걸음.
4. 직원 온보딩 1페이지 + 팀 시연 — [이월 · DR-001부터 미착수] 실사용자는 늘었지만(Nathan/Myra/siwoo/Kevin) 이들 모두 자발적 발견이었지, 공식 안내를 거친 게 아니다. 사용자가 계속 늘고 있는 지금이 형식화할 적기.

단기 (1–3개월)

1. 랩탑 SPOF 완화(전면 이전이 아니라 완화부터) — [일부 진행, 완전 해소는 아님] WakeToRun으로 절전 문제는 고쳤고 파일 락으로 동시 실행 충돌도 막았지만, 이번 회차에만 랩탑/스케줄러 원인 장애가 2건 발생했다. 전면 클라우드 이전은 사용자가 별도 프로젝트로 명시적으로 미루기로 했으므로(런북 §7), 그 전 단계로 장애 발생 시 Slack/이메일 알림(현재는 “우연히 발견”에 의존)만이라도 붙이는 게 비용 대비 가치가 크다.
2. 역할 기반 접근제어(RBAC) 설계 착수 — [이월 · DR-001부터 미착수] 재무(05_재무)·인사(07_인사) 데이터가 아직 위키에 본격 편입되지 않은 지금이 설계하기 가장 쉬운 시점 — 데이터가 더 쌓인 뒤 소급 적용하는 것보다 훨씬 저렴하다.
3. 딜러 재활성화 실행 추적 루프 — Query Result에 이미 축적된 우선순위 딜러 리스트(NSW/VIC Grow·Maintain·Recover·Dormant 세그먼트)가 실제 영업 행동으로 이어졌는지 추적하는 장치가 없다. “분석은 있는데 실행 폐루프가 없다”는 다음 단계의 채택 갭이 될 가능성.
4. 전략 플레이북 수치 1차 출처 검증 — [이월 · DR-001부터 미착수] NotebookLM 합성치 그대로 남아 있음.

중기 (3–6개월)

1. 운영 2인 이상 체제 — [미착수] bus factor 1은 3주 전과 동일. 재해복구 런북이 “문서화된 절차”까지는 갔지만 “실제로 다른 사람이 그 절차를 밟아본 적”은 없다.
2. 랩탑 → 상시 서버/클라우드 완전 이전 — [사용자가 명시적으로 이번 범위 제외, 런북 §7] 근본 해법이지만 별도 프로젝트로 다뤄질 예정. 8/26·8/31 두 사고가 이 항목의 긴급도를 실증했으므로, 다음 진단(TAB-DR-003) 전에는 최소 킥오프라도 필요.
3. 재고/서비스/부품 데이터의 신뢰도 굳히기 — 재고 탭의 배수/임계치 컬럼, 컨테이너 스케줄 활용법이 아직 실험적(v3~v8 반복 개선 중) — 운영 의사결정에 쓰기 전 확정판 필요.
4. claimType//verify 검증 백로그 착수 — [이월 · DR-001부터 미착수] 위키 규모가 51→70페이지로 늘면서 검증 백로그도 비례해 커졌다.

직원 실전 팁 (신규/변경분만)

DR-001의 8개 팁은 여전히 유효하다. 이번 회차에 새로 생긴 것만 추가:

• 로그인 이메일이 질문에 자동으로 남는다 — 별도로 이름·연락처를 안 적어도 답변이 업데이트되면 알림메일이 온다.
• 재고 현황도 이제 대시보드에서 바로 조회 가능 — 사이드바 → 📊 TAB 대시보드 → “재고” 탭. 브랜치·카테고리·모델별로 드릴다운된다.
• 부품·서비스 질문은 “부품”/“AS”/“수리” 등을 명시해야 TA Service 데이터가 조회된다 — 명시 안 하면 완제품(TAB) 매출만 본다.
• K-Master 관련 질문은 “K-Master”를 명시 — 안 그러면 기본은 Turbo Air 본브랜드로 간주된다.

References

• 2026-08-13-TAB-DR-001-프로젝트-진단-리포트 — 직전 회차, 델타 비교 기준선
• TAB 프로젝트 재해복구 런북 (랩탑 고장 대비)
• Cloudflare Pages Function + Claude API로 Wiki 기반 Q&A 봇 만들기
• Obsidian 볼트를 Cloudflare Pages로 웹 발행하기
• log.md (2026-08-13 ~ 2026-09-03 구간 전체 대조)