ai-diagnostic

name	ai-diagnostic
description	AI 기반 다차원 진단 분석 스킬. 기술, 프로세스, 사람, 비즈니스 4차원 병렬 진단을 통해 근본 원인을 식별하고 우선순위별 해결책을 제시합니다. 다음과 같은 요청 시 반드시 이 스킬을 사용하세요: - "시스템 진단", "문제 분석", "원인 파악", "diagnostic", "트러블슈팅" - "근본 원인", "현황 점검", "문제 해결", "시스템 이슈" - 복합적 원인이 의심되는 문제 상황 진단 - 성능 저하, 오류 원인, 병목 파악
user-invocable	true
version	2.27.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: 전략적 사고 프레임워크가 필요한 경우