AI 기반 다차원 진단 분석 스킬. 기술, 프로세스, 사람, 비즈니스 4차원 병렬 진단을 통해 근본 원인을 식별하고 우선순위별 해결책을 제시합니다.
다음과 같은 요청 시 반드시 이 스킬을 사용하세요:
- "시스템 진단", "문제 분석", "원인 파악", "diagnostic", "트러블슈팅"
- "근본 원인", "현황 점검", "문제 해결", "시스템 이슈"
- 복합적 원인이 의심되는 문제 상황 진단
- 성능 저하, 오류 원인, 병목 파악
Installs into .claude/skills of the current project.
Are you the author of Ai Diagnostic?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/modu-ai-ai-diagnostic-56c76456)
---
name: ai-diagnostic
description: |
AI 기반 다차원 진단 분석 스킬. 기술, 프로세스, 사람, 비즈니스 4차원 병렬 진단을 통해 근본 원인을 식별하고 우선순위별 해결책을 제시합니다.
다음과 같은 요청 시 반드시 이 스킬을 사용하세요:
- "시스템 진단", "문제 분석", "원인 파악", "diagnostic", "트러블슈팅"
- "근본 원인", "현황 점검", "문제 해결", "시스템 이슈"
- 복합적 원인이 의심되는 문제 상황 진단
- 성능 저하, 오류 원인, 병목 파악
version: "1.1.2"
---
# ai-diagnostic
기술·프로세스·사람·비즈니스 관점에서 문제를 살피는 진단 스킬입니다. 실제 병렬 실행은 현재 호스트가 지원하고 해당 작업에 필요할 때만 사용합니다.
## 개요
증상과 가능한 원인을 구분하고 확인 방법을 정하는 진단 틀을 제공합니다. 근본 원인은 로그·측정·당사자 확인 등으로 검증한 경우에만 확정합니다. 관련 자료가 없는 관점은 추정하지 않습니다.
### 핵심 기능
- **다차원 진단**: 문제와 관련된 기술, 프로세스, 사람, 비즈니스 관점 조사
- **원인 검증**: 필요한 경우 5 Whys, Fishbone Diagram 등의 기법 활용
- **가설 기반 진단**: 검증 가능한 가설 수립과 우선순위 부여
- **실행 가능한 해결책**: 근거 있는 우선순위와, 비용·효과 자료가 있을 때만 ROI 추정
## 트리거 키워드
- 진단, diagnostic, 문제 분석, 트러블슈팅, 원인 분석
- 근본 원인, 시스템 진단, 현황 점검, 문제 해결
- 성능 저하, 오류 원인, 병목 파악, 이슈 분석
## 워크플로우
### 1단계: 문제 수집
증상과 컨텍스트를 체계적으로 수집합니다:
- 증상 파악: 오류 메시지, 성능 지표, 사용자 불만
- 영향도 파악: 영향받는 사용자 수, 비즈니스 영향, 긴급성
- 타임라인: 문제 발생 시점, 변화 추이, 패턴
- 환경 정보: 시스템 사양, 구성, 최근 변경사항
### 2단계: 가설 생성
증상을 바탕으로 검증 가능한 가설을 생성합니다:
- 차원별 가설: 기술, 프로세스, 사람, 비즈니스 차원별 가능성
- 우선순위 부여: 발생 가능성과 영향도 기반 정렬
- 검증 방법 수립: 각 가설을 검증할 방법론 정의
### 3단계: 병렬 진단
관련된 차원을 조사합니다. 도구나 팀 자료에 접근할 수 없으면 확인할 항목으로 남깁니다:
**차원 1: 기술 진단**
- 인프라: 서버, 네트워크, 데이터베이스, 서드파티 API
- 코드: 버그, 성능 병목, 리소스 누수, 예외 처리
- 아키텍처: 확장성, 가용성, 복잡도, 기술 부채
- 보안: 취약점, 권한 관리, 데이터 보호
**차원 2: 프로세스 진단**
- 워크플로우: 업무 프로세스, 승인 체계, 핸드오버
- 자동화: 반복 작업 자동화 여부, CI/CD 파이프라인
- 모니터링: 로그, 알림, 대응 절차
- 문서화: Runbook, 장애 보고서, 지식 베이스
**차원 3: 사람 진단**
- 역량: 기술 스택, 도메인 지식, 문제 해결 능력
- 커뮤니케이션: 팀 협업, 정보 공유, 의사결정
- 워크로드: 번아웃, 리소스 배분, 온콜 부담
- 문화: 책임감, 학습 문화, 실패 허용
**차원 4: 비즈니스 진단**
- KPI: 성과 지표, SLA, 목표 달성률
- 비용: 인프라 비용, 개발 비용, 기회 비용
- 고객: NPS, 이탈률, 불만 사항
- 전략: 비즈니스 목표와 기술 목표 정렬성
### 4단계: 근본 원인 식별
필요한 기법으로 원인 가설을 구체화하고, 실제 자료로 반증·확인합니다:
- **5 Whys**: 원인을 더 묻되 반복 횟수만으로 근본 원인을 확정하지 않음
- **Fishbone Diagram**: 원인을 카테고리별로 분류 (Man, Machine, Material, Method, Environment)
- **Iceberg Model**: 수면 아래 잠재적 원인 탐색
### 5단계: 해결책 제안
근본 원인별 실행 가능한 해결책을 제시합니다:
- **완화 조치**: 현재 증상의 영향을 줄이는 방법
- **원인 해결**: 검증된 원인에 대한 수정 방법
- **재발 예방**: 관측·운영·검증 절차 개선
- **우선순위**: 영향, 긴급성, 실행 비용을 확인해 정렬
## 사용 예시
### 예시 1: 웹 서비스 응답 시간 저하 진단
```
증상:
- 지난 2주간 API 평균 응답 시간 200ms → 800ms로 악화
- 오후 2시~4시에 심각 (최대 3초)
- 사용자 불만 50건/일 접수
컨텍스트:
- 2주 전 신규 기능 배포 (검색 엔진 변경)
- AWS, RDS MySQL 사용
- 온콜 엔지니어 1명, 번아웃 위험
```
**확인 가능한 사실**: 응답 시간과 고객 문의가 늘었고, 검색 엔진 변경 시점과 겹친다.
**가설과 확인 방법**:
- 검색 쿼리 증가: 배포 전후 쿼리 수·실행 계획·DB 지표 비교
- 캐시 영향: 캐시 적중률과 검색 경로 로그 비교
- 운영 영향: 해당 시간대의 요청량·알림·당직 기록 확인
**조치 후보**: 실제 지표에서 배포와 성능 저하의 인과관계를 확인한 뒤 롤백이나 쿼리 개선을 선택한다. 고객 이탈률, SLA 위반, 인력 부족은 별도 자료 없이는 판정하지 않는다.
### 예시 2: 스타트업 팀 생산성 저하 진단
```
증상:
- 분기별 기능 릴리스 5개 → 2개로 감소
- 스프린트 완료율 60% (이전 85%)
- 팀원 사기 저하, 퇴사 2명 발생
컨텍스트:
- 시리즈 A 투자 유치로 팀 10명 → 25명으로 급성장
- PO 3명, 각자 다른 우선순위
- 기술 부채 누적, 재택근무 전환
```
**확인 가능한 사실**: 출시 수와 완료율이 낮아졌고, 팀 규모·PO 수가 늘었다. 동시에 기술 부채와 재택 전환이 있었다.
**가설과 확인 방법**:
- 우선순위 충돌: 스프린트 중 요구 변경 기록과 PO별 결정권 확인
- 대기 시간 증가: 코드 리뷰·배포 대기 시간과 실패율 측정
- 온보딩 영향: 입사 시점별 업무 시작 시간과 팀원 면담 확인
**조치 후보**: 우선순위 결정 방식과 병목 지표를 확인한 뒤 범위 조정·온보딩·배포 개선을 선택한다. 투자자 기대, 매출 목표, 채용 속도는 입력에 없으므로 결과로 단정하지 않는다.
## 출력 형식
진단 보고서는 다음 섹션들을 포함합니다:
### 필수 섹션
1. **증상 요약**: 관찰된 증상의 간결한 요약, 영향도, 시간적 패턴
2. **가설 목록**: 검증 가능한 가설 리스트, 우선순위, 검증 방법
3. **차원별 진단 결과**: 4차원 분석 결과, 발견된 이슈와 증거
4. **원인 분석**: 가설별 근거·반증·미확인 항목, 확인된 경우에만 근본 원인
5. **해결책 우선순위**: 영향·비용·선행 조건, 담당자가 정해졌다면 담당자
6. **실행 계획**: 우선순위와 확인 기준, 합의된 일정이 있다면 일정
### 선택적 섹션
- 위험도 평가: 해결책 실행 리스크와 완화 방안
- 대안 비교: 여러 해결책의 장단점 비교
- 모니터링 계획: 성공 추적을 위한 지표와 알림
## 주의사항
### 진단 시 유의사항
1. **증상과 원인의 구분**: 관찰된 현상(증상)과 근본 원인을 명확히 구분
2. **편견 방지**: 확인 편향(Confirmation Bias)을 피하고 데이터에 기반
3. **다차원 사고**: 한 차원에만 집중하지 않고 4차원 모두 고려
4. **검증 가능성**: 가설은 반드시 검증 가능한 형태로 수립
5. **우선순위**: 모든 것을 한 번에 해결하려 하지 말고 영향력 순으로 접근
### 흔한 실수 피하기
- 증상만 해결: 근본 원인을 해결하지 않고 임시 조치만 반복
- 단일 차원 편중: 기술 문제만 보고 프로세스/사람/비즈니스 무시
- 데이터 부족: 근거 없이 직관에만 의존한 진단
- 너무 많은 가설: 실행 가능한 수준으로 가설을 한정하고 우선순위 부여
- 실행 가능성 무시: 리소스와 역량을 고려하지 않은 이상적인 해결책 제안
## 관련 스킬
- **moai-workflow-spec**: 문제의 구조적 분석이 필요한 경우
- **moai-workflow-project**: 프로젝트 컨텍스트 이해가 필요한 경우
- **moai-foundation-thinking**: 전략적 사고 프레임워크가 필요한 경우
### 후처리 체인 (진단 보고서·근본 원인 분석·해결책 서술 등 서술형 산출물)
진단 보고서의 서술형 본문은 관측값·가설·미확인 사항을 원문과 대조하고, 과장·번역투·모호한 표현을 직접 검수한다. 현재 앱에 아래 스킬이 노출돼 있으면 추가로 적용한다. 별도 플러그인이 없어도 진단 보고서를 완성한다.
- **moai-coworker:ai-slop-reviewer**: 노출된 경우 AI 티 나는 표현·과장·상투구 추가 검수
- **moai-writer:korean-humanize**: 별도 설치돼 노출된 경우 한국어 문장 추가 윤문. 수치·근거·미확인 표시는 유지