---
name: ai-diagnostic
description: |
  AI 기반 다차원 진단 분석 스킬. 기술, 프로세스, 사람, 비즈니스 4차원 병렬 진단을 통해 근본 원인을 식별하고 우선순위별 해결책을 제시합니다.

  다음과 같은 요청 시 반드시 이 스킬을 사용하세요:
  - "시스템 진단", "문제 분석", "원인 파악", "diagnostic", "트러블슈팅"
  - "근본 원인", "현황 점검", "문제 해결", "시스템 이슈"
  - 복합적 원인이 의심되는 문제 상황 진단
  - 성능 저하, 오류 원인, 병목 파악
user-invocable: true
version: 2.13.0
---

# ai-diagnostic

AI 기반 다차원 진단 분석 스킬입니다. Supervisor 패턴으로 기술, 프로세스, 사람, 비즈니스 4차원을 병렬 진단합니다.

## 개요

단순한 증상 기반 해결을 넘어 근본 원인(Root Cause)을 식별하기 위한 체계적인 진단 프레임워크를 제공합니다. 4개 차원(기술, 프로세스, 사람, 비즈니스)을 동시에 분석하고 결과를 통합하여 전체적인 진단 보고서를 생성합니다.

### 핵심 기능

- **다차원 병렬 진단**: 기술, 프로세스, 사람, 비즈니스 4차원 동시 분석
- **근본 원인 식별**: 5 Whys, Fishbone Diagram, Iceberg Model 기법 활용
- **가설 기반 진단**: 검증 가능한 가설 수립과 우선순위 부여
- **실행 가능한 해결책**: 우선순위별 Action Items과 ROI 추정

## 트리거 키워드

- 진단, diagnostic, 문제 분석, 트러블슈팅, 원인 분석
- 근본 원인, 시스템 진단, 현황 점검, 문제 해결
- 성능 저하, 오류 원인, 병목 파악, 이슈 분석

## 워크플로우

### 1단계: 문제 수집

증상과 컨텍스트를 체계적으로 수집합니다:
- 증상 파악: 오류 메시지, 성능 지표, 사용자 불만
- 영향도 파악: 영향받는 사용자 수, 비즈니스 영향, 긴급성
- 타임라인: 문제 발생 시점, 변화 추이, 패턴
- 환경 정보: 시스템 사양, 구성, 최근 변경사항

### 2단계: 가설 생성

증상을 바탕으로 검증 가능한 가설을 생성합니다:
- 차원별 가설: 기술, 프로세스, 사람, 비즈니스 차원별 가능성
- 우선순위 부여: 발생 가능성과 영향도 기반 정렬
- 검증 방법 수립: 각 가설을 검증할 방법론 정의

### 3단계: 병렬 진단

4개 차원을 병렬로 진단합니다:

**차원 1: 기술 진단**
- 인프라: 서버, 네트워크, 데이터베이스, 서드파티 API
- 코드: 버그, 성능 병목, 리소스 누수, 예외 처리
- 아키텍처: 확장성, 가용성, 복잡도, 기술 부채
- 보안: 취약점, 권한 관리, 데이터 보호

**차원 2: 프로세스 진단**
- 워크플로우: 업무 프로세스, 승인 체계, 핸드오버
- 자동화: 반복 작업 자동화 여부, CI/CD 파이프라인
- 모니터링: 로그, 알림, 대응 절차
- 문서화: Runbook, 장애 보고서, 지식 베이스

**차원 3: 사람 진단**
- 역량: 기술 스택, 도메인 지식, 문제 해결 능력
- 커뮤니케이션: 팀 협업, 정보 공유, 의사결정
- 워크로드: 번아웃, 리소스 배분, 온콜 부담
- 문화: 책임감, 학습 문화, 실패 허용

**차원 4: 비즈니스 진단**
- KPI: 성과 지표, SLA, 목표 달성률
- 비용: 인프라 비용, 개발 비용, 기회 비용
- 고객: NPS, 이탈률, 불만 사항
- 전략: 비즈니스 목표와 기술 목표 정렬성

### 4단계: 근본 원인 식별

다양한 기법을 활용하여 근본 원인을 도출합니다:
- **5 Whys**: "왜?"를 5번 반복하여 근본 원인 도달
- **Fishbone Diagram**: 원인을 카테고리별로 분류 (Man, Machine, Material, Method, Environment)
- **Iceberg Model**: 수면 아래 잠재적 원인 탐색

### 5단계: 해결책 제안

근본 원인별 실행 가능한 해결책을 제시합니다:
- **단기 조치**: 즉시 실행 가능한 완화 조치 (24-72시간)
- **중기 해결**: 근본 원인 해결을 위한 구조적 개선 (1-4주)
- **장기 예방**: 재발 방지를 위한 시스템적 개선 (1-3개월)
- **우선순위**: ROI (투자 대비 효과)와 긴급성 기반 정렬

## 사용 예시

### 예시 1: 웹 서비스 응답 시간 저하 진단

```
증상:
- 지난 2주간 API 평균 응답 시간 200ms → 800ms로 악화
- 오후 2시~4시에 심각 (최대 3초)
- 사용자 불만 50건/일 접수

컨텍스트:
- 2주 전 신규 기능 배포 (검색 엔진 변경)
- AWS, RDS MySQL 사용
- 온콜 엔지니어 1명, 번아웃 위험
```

**진단 결과 개요**:
- **기술**: 신규 검색 엔진 N+1 쿼리 발생, DB CPU 95%, 캐시 미스율 45%
- **프로세스**: 성능 테스트 없이 배포, 알림 미설정, 대응 매뉴얼 부재
- **사람**: 온콜 1명으로 24/7 불가, 지식 승계 부족, 성능 최적화 역량 부족
- **비즈니스**: 이탈률 2.1% 증가, SLA 위반, 신규 가입 전환율 15% 하락

**근본 원인**: 품질 프로세스(성능 테스트, 코드 리뷰) 부재와 인력 부족 복합 작용

**해결책**:
- [긴급] 신규 검색 엔진 롤백, RDS scale-up, connection pool 증설
- [중기] N+1 쿼리 최적화, 성능 테스트 파이프라인 구축, 온콜 2명 증원
- [장기] 코드 리뷰 문화 정착, Runbook 작성, 모니터링 강화

### 예시 2: 스타트업 팀 생산성 저하 진단

```
증상:
- 분기별 기능 릴리스 5개 → 2개로 감소
- 스프린트 완료율 60% (이전 85%)
- 팀원 사기 저하, 퇴사 2명 발생

컨텍스트:
- 시리즈 A 투자 유치로 팀 10명 → 25명으로 급성장
- PO 3명, 각자 다른 우선순위
- 기술 부채 누적, 재택근무 전환
```

**진단 결과 개요**:
- **기술**: 기술 부채 40%, CI/CD 느림, 코드 리뷰 2.5일 대기
- **프로세스**: 스프린트 범위 계속 변경, 데일리 45분으로 길어짐
- **사람**: 온보딩 프로그램 없음, 멘토링 시간 소모, 고립감 증가
- **비즈니스**: 투자자 기대치 관리 실패, 채용 속도 느림, 매출 목표 70% 달성

**근본 원인**: 급격한 조직 성장에 따른 프로세스·문화·인프라 업그레이드 지연

**해결책**:
- [긴급] PO 단일 우선순위 확립, 스프린트 범위 동결, 데일리 15분
- [중기] 온보딩 프로그램 구축, CI/CD 최적화, 코드 리뷰 SLA
- [장기] Engineering Manager 채용, 문서화 문화, 팀 빌딩 활동

## 출력 형식

진단 보고서는 다음 섹션들을 포함합니다:

### 필수 섹션

1. **증상 요약**: 관찰된 증상의 간결한 요약, 영향도, 시간적 패턴
2. **가설 목록**: 검증 가능한 가설 리스트, 우선순위, 검증 방법
3. **차원별 진단 결과**: 4차원 분석 결과, 발견된 이슈와 증거
4. **근본 원인 분석**: 5 Whys/Fishbone 기법 적용, 근본 원인 식별
5. **해결책 우선순위**: 단기/중기/장기 해결책, 담당자, 예상 기간, 효과
6. **실행 계획**: 타임라인 기반 실행 로드맵, 마일스톤

### 선택적 섹션

- 위험도 평가: 해결책 실행 리스크와 완화 방안
- 대안 비교: 여러 해결책의 장단점 비교
- 모니터링 계획: 성공 추적을 위한 지표와 알림

## 주의사항

### 진단 시 유의사항

1. **증상과 원인의 구분**: 관찰된 현상(증상)과 근본 원인을 명확히 구분
2. **편견 방지**: 확인 편향(Confirmation Bias)을 피하고 데이터에 기반
3. **다차원 사고**: 한 차원에만 집중하지 않고 4차원 모두 고려
4. **검증 가능성**: 가설은 반드시 검증 가능한 형태로 수립
5. **우선순위**: 모든 것을 한 번에 해결하려 하지 말고 영향력 순으로 접근

### 흔한 실수 피하기

- 증상만 해결: 근본 원인을 해결하지 않고 임시 조치만 반복
- 단일 차원 편중: 기술 문제만 보고 프로세스/사람/비즈니스 무시
- 데이터 부족: 근거 없이 직관에만 의존한 진단
- 너무 많은 가설: 실행 가능한 수준으로 가설을 한정하고 우선순위 부여
- 실행 가능성 무시: 리소스와 역량을 고려하지 않은 이상적인 해결책 제안

## 관련 스킬

- **moai-workflow-spec**: 문제의 구조적 분석이 필요한 경우
- **moai-workflow-project**: 프로젝트 컨텍스트 이해가 필요한 경우
- **moai-foundation-thinking**: 전략적 사고 프레임워크가 필요한 경우