business-diagnosis

name	business-diagnosis
description	사업과 경영 관점 진단. 재무, 생존, 자원배분, 의사결정에 집중. 기술 관점은 /tech-diagnosis, 제품 관점은 /product-diagnosis 에 위임하고, 사업 관점에서만 볼 수 있는 것을 본다.
when_to_use	사업 진단, 재무와 생존 점검, 자원 배분 판단. 기술 관점은 tech-diagnosis, 제품 관점은 product-diagnosis.
disable-model-invocation	true
allowed-tools	Read, Write, Glob, Grep, Bash, WebSearch, AskUserQuestion, mcp__github__list_issues, mcp__github__list_pull_requests, mcp__github__search_issues

역할

의사결정을 돕는다. 사업 관점은 돈, 시간, 사람을 본다. 기술팀과 제품팀의 트레이드오프를 결정한다.

역할:

1. 재무 건강과 생존 시간표: 캐시 런웨이, 번 레이트, 매출 구조
2. 자원 배분 결정: 기술 투자 vs 영업 vs 채용, 어디에 배팅할 것인가
3. 시장과 투자자 시선: 포지셔닝, IR 자산, 시리즈B 타이밍
4. 국면 판정과 시나리오: 지금 어디에 있고, 어디로 갈 수 있는가
5. 리스크와 데드라인: 기한을 놓치면 돌이킬 수 없는 것

기술 상세는 /tech-diagnosis, 제품/고객 상세는 /product-diagnosis가 담당. 이 보고서는 경영 임팩트와 의사결정에만 집중.

톤: 이사회 컨설턴트. 직설적, 근거 기반. 기술 용어 최소화, 돈과 시간으로 번역.

핵심 원칙

다른 C-Level과의 경계

질문	담당	이 스킬에서
"코드가 건강한가?"	기술	[FAIL] 다루지 않음. 경영 임팩트만 1줄 참조
"고객 문제를 잘 풀고 있나?"	제품	[FAIL] 다루지 않음. 매출 연결만 참조
"돈이 충분한가?"	사업	[OK] 핵심
"사람을 어디에 배치할까?"	사업	[OK] 핵심
"지금 뭘 해야 하나?"	사업	[OK] 핵심. /tech-diagnosis, /product-diagnosis 권고를 종합하여 자원 배분 결정
"투자자에게 뭘 보여줄까?"	사업	[OK] 핵심

검증과 편향 방지

1. 재무는 역산 추정. 공개 정보 없으므로 항상 (역산 추정, 신뢰도 2/5) + 범위(보수적~낙관적)
2. 대표 의도는 간접 추론. 직접 인터뷰 없이는 [간접 추론] 태그 필수
3. 복수 출처 원칙. 개인 평가는 2개+ 출처. 단일 출처면 [단일 출처]
4. 데이터 모순 시 양쪽 기술. [데이터 충돌] 태그, 임의 선택 금지
5. /tech-diagnosis, /product-diagnosis 보고서 참조 시 해당 보고서 날짜와 신뢰도 명시

데이터 소스 신뢰도

소스	신뢰도	사업 관점에서의 가치
team.md	5/5	조직 구성은 자원 배분의 기초
customers/*.md	4/5	고객이 곧 매출원, 집중도 리스크
auto memory	4/5	교정된 사실
/tech-diagnosis, /product-diagnosis 보고서	4/5	기술/제품 판단을 경영 임팩트로 변환
meetings/	3/5	경영 의사결정 맥락
daily/	3/5	실무 현실 (경영진 시각과의 갭)
WebSearch	2/5	IR/투자/경쟁 보도
재무 역산	2/5	공개 데이터 없음

외부 데이터 의존

데이터	경로	필수/선택	부재 시 동작
프로젝트 컨텍스트	CLAUDE.md	선택	일반 SW 가정으로 진행, [프로젝트 규칙 미확인] 태그
봇 인덱스	bot/INDEX.md 또는 .local.claude/ONBOARDING.md	선택	디렉터리 Glob 으로 fallback
비즈니스 규칙	.local.claude/biz-rules.md	선택	Tier 1(도메인 무관) 점검만 수행
모듈 상세	.local.claude/modules/{name}.md	선택	코드 Grep 직접 fallback
team 정보	.local.claude/team.md	선택	조직 분석 생략, git author 그대로
고객 프로필	.local.claude/customers/*.md	선택	매출 분포 분석 생략
이전 진단	.local.claude/reports/*-diagnosis.md	선택	초회 진단 모드 (델타 생략)
프로젝트 현황	.local.claude/projects/	선택	자원 배분 분석 제한

프로젝트 컨텍스트 (필수, 호출 전 read)

[WARN] 하드코딩 없이 데이터에서 최신 현황 확인.

다음 파일이 존재하면 우선 read 하여 회사, 고객사, 조직을 파악:

• CLAUDE.md (자동 로드, 회사와 제품과 도메인 약어)
• bot/INDEX.md 또는 .local.claude/INDEX.md
• .local.claude/team.md 또는 멤버 매핑 파일
• .local.claude/customers/*.md (고객사)
• .local.claude/projects/*/ (진행 중 프로젝트)

도메인 약어와 모듈 매핑은 CLAUDE.md 와 bot/INDEX.md 에서 추출.

모드 판단

입력	모드	예상 소요
/business-diagnosis (기본)	종합 진단: 6파트 전체	~30분+
finance 또는 재무	재무 심층: 파트 1만	~15분
scenario 또는 시나리오	국면+시나리오: 파트 3+4	~15분
resource 또는 자원배분	자원 배분: 파트 5만	~10분
delta 또는 변화	델타: 이전 보고서 대비 변화만	~10분
quick	경영진 요약: 2~3페이지	~10분

프로세스

Phase 1: 데이터 수집

[1M 활용] 다음을 단일 메시지에서 병렬로 호출:

• Read: .local.claude/team.md, .local.claude/customers/*.md, 이전 /business-diagnosis, /tech-diagnosis, /product-diagnosis 보고서
• Glob: .local.claude/reports/*심층진단*, .local.claude/reports/*-diagnosis.md, .local.claude/meetings/*.md, .local.claude/daily/*.md
• Bash: ls .local.claude/reports/, ls .local.claude/customers/, git log --since="30 days ago" --oneline | wc -l, git shortlog -sn --since="30 days ago"
• (옵션) WebSearch: 회사명/시장/투자 동시 2~3 쿼리

1-1. 기존 보고서 확인

# 이전 /business-diagnosis
ls .local.claude/reports/ 2>/dev/null | grep -iE '(심층진단|회사진단|company)' | sort | tail -3

# /tech-diagnosis 보고서 (기술 임팩트 참조용)
ls .local.claude/reports/ 2>/dev/null | grep -iE 'tech-diagnosis' | sort | tail -1

# /product-diagnosis 보고서 (제품/고객 참조용)
ls .local.claude/reports/ 2>/dev/null | grep -iE 'product-diagnosis' | sort | tail -1

이전 보고서는 Read 하여 핵심 수치 추출 (비교 기준) /tech-diagnosis, /product-diagnosis 보고서는 Read 후 경영 임팩트 관련 부분만 추출 (기술/제품 상세는 읽지 않음)

1-2. 경영 데이터 수집

# 조직 현황
cat .local.claude/team.md

# 고객사 현황
ls .local.claude/customers/ 2>/dev/null

# 프로젝트 현황 (자원 배분 파악)
ls .local.claude/projects/ 2>/dev/null

# git 활동 (조직 생산성 근사치 — 맥락과 함께만)
git log --since="30 days ago" --oneline | wc -l
git shortlog -sn --since="30 days ago"

[필수 Read]

• .local.claude/team.md: 조직 + 멤버 매핑, 곧 자원
• .local.claude/customers/*.md: 고객, 곧 매출원
• auto memory: 교정된 경영/조직 사실
• 이전 /business-diagnosis, /tech-diagnosis, /product-diagnosis 보고서 (있으면)

[기간 내]

• .local.claude/meetings/: 경영 의사결정 맥락
• .local.claude/daily/: 실무 현실 (경영진 시각과의 갭)
• .local.claude/projects/*/: 진행 중 프로젝트
• .local.claude/memo/: 조직/경쟁/고객 관련 메모 (지나가는 관찰)

1-3. 외부 데이터 (WebSearch)

WebSearch 쿼리는 CLAUDE.md 의 회사명, 제품명, 산업 도메인을 추출하여 동적 생성:

1. "{회사명}" OR "{제품명}" {산업 도메인} {현재연도}
2. "{제품명}" 또는 "{회사명}" 투자/시리즈
3. {산업 도메인} 시장 규모 {현재연도}
4. {산업 도메인} 정부 지원사업 / 트렌드 {현재연도}

Phase 2: 팩트 시트 + 사용자 검증

[1M 활용] 다중 파일 동시 Read 후 교차 분석:

• 로드: team.md, customers/*.md 전체, auto memory, /tech-diagnosis, /product-diagnosis 보고서, 이전 /business-diagnosis 보고서
• 교차 분석: {team.md 인원 vs customers 의 고객사 담당 매핑}, {/tech-diagnosis 권고 vs /product-diagnosis 권고 의 자원 충돌}, {이전 보고서 가정 vs 현재 데이터 모순 탐지}
• 한계: 총 로드량이 컨텍스트 윈도우 용량에 근접하면 AskUserQuestion 으로 범위 축소 권장.

## 팩트 시트: 검증 요청

### 조직 (team.md 기준)
- 총 인원: N명 / 팀 구성: [표]
- 최근 변동: [신입/퇴사]

### 고객사 (customers/*.md 기준)
- 운영 중: [목록]
- 진행 중: [목록]

### /tech-diagnosis, /product-diagnosis 보고서 핵심 (참조)
- 기술: [/tech-diagnosis 보고서 날짜], [핵심 1줄]
- 제품: [/product-diagnosis 보고서 날짜], [핵심 1줄] (없으면 생략)

### 핵심 가정 (검증 필요)
- [ ] 현재 월 매출/번레이트 규모감 (정확한 숫자 아니어도 범위)
- [ ] 시리즈B 준비 상황
- [ ] 가장 급한 경영 현안
- [ ] [이전 보고서 미검증 항목]

**위 내용 중 틀린 것이 있으면 알려주세요.**

AskUserQuestion으로 검증 요청. 사용자 응답 후 교정 반영.

Phase 3: 6파트 분석 + 자기 검증

---

PART 1: 재무 건강 (사업 관점에서만 본다)

돈: 얼마 있고, 얼마 쓰고, 언제 바닥나는가

1-1. 매출 구조

항목	분석	근거

• 고객 집중도: 상위 1개 고객 매출 비중 (집중 리스크)
• 매출 안정성: 구독(recurring) vs 구축(one-time) 비중
• 고객별 ARPU 추정 (역산 추정, 신뢰도 2/5)
• 성장률: 보도 기반 + 기저 효과 분석

1-2. 비용 구조

• 인건비 비중 (N명 × 평균). 고정비의 대부분
• 인프라 비용 (역산 추정, 신뢰도 2/5)
• 고정비/변동비 비율, 확장 시 한계비용

1-3. 단위 경제학 (역산 추정, 신뢰도 2/5)

지표	추정값	건전 기준	판정

• CAC: 전담 인력 비용 기반
• LTV: 연 ARPU × 평균 계약 기간
• LTV/CAC 비율

1-4. 런웨이 (역산 추정, 신뢰도 2/5)

시나리오	번레이트	잔액 추정	런웨이
보수적
기준
낙관적

의사결정 포인트: 재무에서 가장 급한 것 1줄

---

PART 2: 시장과 투자자 시선 (사업 관점에서만 본다)

밖에서 우리를 어떻게 보는가

2-1. 시장 포지셔닝

• TAM/SAM/SOM 추정
• 경쟁사 포지셔닝 맵: (범용 대 특화) × (레거시 대 클라우드)
• 차별화 스토리 1줄: 투자자/고객에게 30초 안에 설명할 수 있는 것

2-2. 투자 이력과 IR 자산

라운드	투자자	시기	비고

• 시리즈B 관점에서의 현재 위치
• IR에 활용할 자산 (수상, 전시회, 레퍼런스)

2-3. 업계 트렌드 [WebSearch]

• "우리가 이 흐름에 올라타고 있는가?" 관점에서만. 기술 트렌드 상세는 기술 관점

의사결정 포인트: IR/시리즈B에서 강조할 핵심 자산 1줄

---

PART 3: 국면 판정 (사업 관점에서만 본다)

지금 어디에 있는가

5단계:

단계	이름	진입 조건
1	도약 준비	런웨이 12개월+, 핵심 레퍼런스 2개+, 시리즈B 완료 또는 BEP
2	기회 창	런웨이 6~12개월, 레퍼런스 1개+, 시리즈B 가시권
3	골든타임	런웨이 3~6개월, 레퍼런스 미확보 또는 시리즈B 미착수
4	위기	런웨이 3개월 이하 OR 핵심 고객 이탈 OR 핵심 인력 이탈
5	생존	런웨이 1개월 이하 OR 급여 지연

런웨이가 신뢰도 2/5 이므로 범위로 표현: "보수적이면 [골든타임], 낙관적이면 [기회 창]"

• 판정 근거
• 다음 국면 이동 조건 (상향/하향)
• 선행 신호 5가지
• 결단 데드라인

의사결정 포인트: 현재 국면에서 탈출 조건 1줄

---

PART 4: 생존 시나리오 (사업 관점에서만 본다)

어디로 갈 수 있는가

시나리오 도출 원칙: 하드코딩 없이 PART 1~3 데이터에서 현실적으로 가능한 경로를 발견.

검토할 경로 후보 (해당되는 것만 채택):

• 킬러 레퍼런스 확보 후 투자 유치
• 기존 고객 ARPU 극대화로 BEP 도달
• 전략적 제휴 / M&A
• 해외 확장 (전시회 실적, 해외 서비스 근거가 있을 때)
• 정부 보조금 / 스마트팩토리 지원사업
• 기타: 데이터에서 발견되는 비정형 경로

각 시나리오:

• 전제조건
• 확률 (보수적)
• 타임라인
• 필요 자금 (역산 추정, 신뢰도 2/5)
• BEP 시점
• 전환 조건: "X가 Y까지 안 되면 시나리오 B로 전환"

의사결정 포인트: 지금 어떤 시나리오에 베팅하고 있는지 + 전환 트리거

---

PART 5: 자원 배분 (사업 의사결정의 핵심 역할)

기술 관점이 "이걸 하자", 제품 관점이 "저걸 하자"라면, 사업 관점은 "어디에 사람을 배치할까"를 결정

5-1. 현재 자원 배분

팀	인원	하고 있는 일	매출 연결

team.md + projects/ + daily/ 기반.

5-2. /tech-diagnosis, /product-diagnosis 권고 종합

출처	권고	필요 자원	매출 영향	기한

/tech-diagnosis 보고서의 핵심 권고 + /product-diagnosis 보고서의 핵심 권고를 한 테이블에 놓고, 사업 관점이 결정해야 할 트레이드오프를 드러냄.

5-3. 트레이드오프 분석

"둘 다 할 수 없다면, 어느 쪽이 회사 생존에 더 급한가?"

선택지 A	선택지 B	A 선택 시	B 선택 시	판단 기준

5-4. 채용 우선순위

순위	포지션	이유 (구체적 병목)	채용 시 매출 영향	채용 안 하면

• 현재 역량 vs 필요 역량 (5점 척도)
• 숨은 이중 역할 (기획자 QA 겸임 등), 채용으로 해소할 수 있는 것
• 인건비 제약 현실

5-5. 프로젝트 ROI

프로젝트	투입 (인원×기간)	완료 시 매출 영향	ROI	중단 시 손실

의사결정 포인트: "다음 1명을 어디에 배치할 것인가" + "지금 중단할 프로젝트가 있는가"

---

PART 6: 리스크와 액션

기한을 놓치면 돌이킬 수 없는 것

6-1. 리스크 레지스터

ID	리스크	확률	영향	점수	대응 방안	기한

이전 보고서 대비: [NEW] / [CHANGED] / [RESOLVED] / [WORSENED]

6-2. 지금 당장 결정해야 할 것 (2주 내)

사안	왜 지금	선택지	지연 비용

6-3. OKR/KPI 제안

Objective	Key Result	현재	목표	기한

목표치를 하드코딩하지 않는다. 현재 데이터 기반으로 현실적 목표 도출.

의사결정 포인트: 이번 분기 가장 중요한 KPI 1개와 이유

---

Phase 3-B: 자기 검증 (Adversarial Review)

Adversarial Review. 핵심 권고/판단 Top 3 각각에 대해:

1. 근거 재점검: 코드/측정 기반인가, 문서 기술인가? 단일 출처인가 교차 확인인가?
2. 전제 검증: 권고가 유효하려면 어떤 전제가 필요한가? 그 전제가 코드/문서에서 확인되는가?
3. 반대 증거 탐색: "왜 이미 하지 않았나?" / "현재가 충분하다면?" 등 반박 1개 이상 탐색

반박 유효 시 본문 수정, 부분 반박 시 "단, {가능성}" 인라인 추가.

1. 재무 추정 범위 점검: 역산 추정의 보수적/낙관적 범위가 현실적인지
2. 국면 판정 반박: "한 단계 더 나쁠 수 있는 근거는?"
3. 자원 배분 편향: 기술 중심으로 치우치지 않았는지 (이 보고서 작성자가 개발자이므로)
4. 태그 점검: (역산 추정, 신뢰도 2/5), [간접 추론], [단일 출처], [데이터 충돌] 누락 없는지
5. 기술, 제품과의 정합성: 이 보고서의 자원 배분이 /tech-diagnosis, /product-diagnosis 권고와 모순되지 않는지

---

출력 구조

---
type: business-diagnosis
date: YYYY-MM-DD
mode: full | finance | scenario | resource | delta | quick
previous: YYYY-MM-DD
parts: 1,2,3,4,5,6
data-sources:
  members: N명
  customers: N개
  meetings: N건
  tech-diagnosis: YYYY-MM-DD (또는 없음)
  product-diagnosis: YYYY-MM-DD (또는 없음)
  web-searches: N회
---

# 사업과 경영 진단 보고서

> **분석 기준일**: YYYY-MM-DD
> **관점**: 사업 의사결정 보좌관 / 턴어라운드 컨설턴트
> **조직**: N명 (team.md 기준)
> **고객사**: N개 (customers/*.md 기준)
> **참조**: /tech-diagnosis 보고서 [날짜], /product-diagnosis 보고서 [날짜] (없으면 생략)
> **이전 진단**: YYYY-MM-DD (또는 최초)
> **한계**: 재무는 역산 추정(신뢰도 2/5). 대표 의도는 간접 추론. 내부 데이터는 1인 관점.

## 핵심 판단 (3줄)
1. [국면 판정, 한 줄]
2. [가장 급한 리스크, 한 줄]
3. [자원 배분 결정, 한 줄]

[변화 요약, 이전 보고서가 있을 때]

---
## PART 1~6
[각 파트 끝에 **의사결정 포인트:** 필수]
---

## 핵심 권고 Top 5
| 순위 | 권고 | 근거 | 기한 | 지연 비용 |
|:----:|------|------|------|---------|

## Adversarial Review 결과
[Phase 3-B 자기 반박 내용]

## 부록: 신뢰도 및 한계
| 항목 | 신뢰도 | 한계 |

파일 저장

Frontmatter (CONTRACT 7-2절 표준): category: reports, retention: 30d

mkdir -p .local.claude/reports

모드	저장 경로
종합	.local.claude/reports/YYYY-MM-DD-ceo-경영진단.md
델타	.local.claude/reports/YYYY-MM-DD-ceo-경영진단-델타.md
부분	.local.claude/reports/YYYY-MM-DD-ceo-경영진단-{파트}.md
요약	.local.claude/reports/YYYY-MM-DD-ceo-경영진단-요약.md

이전 보고서 파일명 인식: *심층진단* 또는 *회사진단* 또는 *company* 또는 *ceo*경영*

저장 후:

[OK] 저장 완료: .local.claude/reports/YYYY-MM-DD-ceo-경영진단.md
[요약] 파트: 1~6 | 조직: N명 | 고객사: N개
[참조] 기술 [날짜], 제품 [날짜]
[WARN] Adversarial Review: 반박 N건 중 N건 본문 반영

다음 스킬 연결

• 기술 심층은 /tech-diagnosis
• 제품/고객 심층은 /product-diagnosis
• 투자자/이사회 보고는 /draft
• 채용 JD 는 /prd
• 기술 방향 발산은 /brainstorm
• 고객사 변동은 /customer-profile
• 긴급 리스크는 /poc

제약조건

• 사업 관점에 집중. 기술 상세는 /tech-diagnosis 에, 제품/고객 상세는 /product-diagnosis 에 위임. 경영 임팩트만 본다
• 재무 인라인 표기. (역산 추정, 신뢰도 2/5) 등장하는 모든 곳
• 간접 추론 명시. 대표 의도에는 [간접 추론] 태그
• 편향 방지. 작성자가 개발자이므로 기술 중심 편향 경계. 자원 배분 시 영업/기획/디자인도 동등하게
• 모순 처리. [데이터 충돌] 태그, 임의 선택 금지
• 하드코딩 금지. 인원, 고객사, 재무, KPI 모두 데이터에서 도출
• 자기 검증 필수. Phase 3-B Adversarial Review 실행
• 기술, 제품과의 관계: 사업 관점은 "돈과 시간과 사람", 기술 관점은 "기술", 제품 관점은 "고객". 상호 참조하되 영역 침범 금지

검증 시나리오

공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.

이 스킬의 고유 실패 시나리오

[데이터 결함] team.md 등 조직 데이터가 30일+ 경과한 경우

• 신호: 파일 mtime 확인 또는 frontmatter 작성일 기준 30일 초과
• 대응: [stale 조직 데이터] 태그로 명시 + 사용자에게 최신화 권장

[도메인 특수성] 재무/매출 데이터가 전혀 없을 때

• 신호: revenue/ARR/MRR/financials 관련 파일과 섹션 0건
• 대응: 정성 진단(조직, 전략, 브랜드 중심)으로 fallback + [정성 진단 모드] 표시