스킬 diagnosing-bugs
📦

diagnosing-bugs

낮은 위험 🌐 네트워크 접근⚙️ 외부 명령어

어려운 소프트웨어 버그 진단 및 수정

복잡한 버그 디버깅은 종종 정렬되지 않은 시행착오로 시간 낭비를 초래합니다. 이 스킬은 피드백 루프를 구축하고, 문제를 재현하며, 효율적으로 문제를 해결하기 위한 체계적인 단계별 방법론을 제공합니다.

지원: Claude Codex Code(CC)
🥉 74 브론즈
1

스킬 ZIP 다운로드

2

Claude에서 업로드

설정 → 기능 → 스킬 → 스킬 업로드로 이동

3

토글을 켜고 사용 시작

테스트해 보기

"diagnosing-bugs" 사용 중입니다. 로그인 버튼이 클릭해도 아무 반응이 없습니다

예상 결과:

  • Phase 1 완료: 클릭 핸들러에 console.log를 추가하여 피드백 루프를 구축했습니다. 클릭 이벤트는 발생하지만 API 호출이 이루어지지 않는 것을 확인했습니다.
  • Phase 2: 버그를 일관되게 재현했습니다. 인증 서비스의 누락된 import로 최소화했습니다.
  • Phase 3~5: 3개의 가설을 생성했습니다. 주요 가설이 순환 의존성으로 확인되었습니다. 수정 사항이 적용되었고 회귀 테스트가 추가되었습니다.

"diagnosing-bugs" 사용 중입니다. 어제 배포 이후 검색 결과 로딩이 너무 오래 걸립니다

예상 결과:

  • 기준선 측정 수립: 콜드 캐시에서 검색에 8.4초 소요됨.
  • 회귀를 새로운 데이터베이스 인덱스로 이분 탐색했습니다. 인덱스로 인해 검색 테이블을 잠그는 느린 쓰기 작업이 발생합니다.
  • 인덱스 쿼리 최적화로 수정 사항을 적용했습니다. 이제 검색이 300ms 이내에 결과를 반환합니다. 성능 회귀 테스트가 추가되었습니다.

보안 감사

낮은 위험
v1 • 6/24/2026

All 13 static analysis findings were evaluated as FALSE POSITIVES. The 'Ruby/shell backtick execution' detections (9 instances) are Markdown inline-code backticks in SKILL.md - not actual shell execution. The 'Weak cryptographic algorithm' detections (2 instances) matched on YAML front matter and a checklist item - no cryptographic code exists. The 'Hardcoded URL' points to http://localhost:3000 in a user-editable template script. The 'System reconnaissance' detection is a human-in-the-loop debugging question. The skill is a debugging methodology document and a bash template for structured user interaction. No malicious intent, data exfiltration, or obfuscation detected.

2
스캔된 파일
177
분석된 줄 수
2
발견 사항
1
총 감사 수
감사자: claude

품질 점수

45
아키텍처
100
유지보수성
87
콘텐츠
50
커뮤니티
90
보안
91
사양 준수

만들 수 있는 것

프로덕션 회귀 수정

최근 배포 이후 웹 애플리케이션이 실패하기 시작했습니다. 이 스킬은 AI가 재현 루프를 구축하고, 변경 사항을 이분 탐색하며, 회귀 테스트와 함께 수정 사항을 생성하도록 안내합니다.

느린 데이터베이스 쿼리 최적화

스키마 변경 이후 기능이 사용할 수 없게 되었습니다. 이 스킬은 성능 기준선을 설정하고, 쿼리 플랜을 측정하며, targeted 계측을 통해 병목 지점을 식별하는 데 도움을 줍니다.

간헐적인 UI 버그 디버깅

UI 컴포넌트가 때때로 잘못된 상태로 렌더링됩니다. 이 스킬은 더 높은 재현률로 루프를 구축하고, 타이밍 윈도우를 좁히며, 불안정한 버그를 디버깅 가능하게 만드는 조건을 주입하는 데 도움을 줍니다.

이 프롬프트를 사용해 보세요

단순한 버그 진단
내 웹사이트에서 폼을 제출할 때 오류가 발생합니다. 폼이 데이터베이스에 데이터를 저장하지 않습니다. 이 문제를 진단하고 수정하는 데 도움을 줄 수 있나요?
성능 회귀 디버깅
내 앱의 검색 기능은 이전에 200ms 이내에 결과를 반환했지만 이제 5초 이상 걸립니다. 변경 사항이 어제 배포되었습니다. 회귀의 원인을 식별하는 데 도움을 줄 수 있나요?
복잡한 다단계 버그 조사
사용자들이 결제 중 세션이 무작위로 만료된다고 보고합니다. 이 오류는 프로덕션에서만 나타나며 로컬에서 재현할 수 없습니다. 피드백 루프를 구축하고 근본 원인을 진단하는 데 도움을 주세요.
전체 디버깅 워크플로우
지난 한 주 동안 CI 파이프라인이 간헐적으로 실패해 왔습니다. 실패는 실행 간에 일관성이 없습니다. 안정적인 재현을 구축하고, 근본 원인을 식별하며, 적절한 회귀 테스트와 함께 수정 사항을 구현하기 위한 체계적인 접근 방식이 필요합니다.

모범 사례

  • 버그의 근본 원인에 대한 가설을 세우기 전에 먼저 피드백 루프를 구축
  • 가설 생성 단계로 넘어가기 전에 재현 케이스를 핵심 요소만 남을 때까지 최소화
  • 모든 디버깅 계측에 고유 접두사를 태그하여 정리가 체계적이고 철저하도록 함

피하기

  • 작동하는 재현 피드백 루프를 구축하기 전에 바로 가설로 뛰어넘기
  • 조사 계측 단계에서 여러 변수를 한꺼번에 변경하기
  • 코드베이스에 축적되어 정리되지 않는 태그 없는 디버그 로그 추가하기

자주 묻는 질문

디버깅에서 가장 중요한 단계는 무엇인가요?
버그를 안정적으로 재현할 수 있는紧密한 피드백 루프를 구축하는 것이 가장 중요한 단계입니다.
프로덕션에서만 발생하는 버그는 어떻게 디버깅하나요?
프로덕션에서 트레이스, HAR 파일 또는 로그 덤프를 캡처해 보세요. 그것이 불가능하다면 임시 프로덕션 계측을 요청하세요.
버그를 재현할 수 없다면 어떻게 해야 하나요?
피드백 루프 작업을 계속하세요. 간헐적 버그의 재현률을 높이거나 최소 하네스를 구축하는 등 다양한 접근 방식을 시도해 보세요.
테스트하기 전에 몇 개의 가설을 생성해야 하나요?
테스트하기 전에 3~5개의 우선순위가 매겨진 가설을 생성하세요. 이렇게 하면 첫 번째 그럴듯한 아이디어에 집착하는 것을 방지할 수 있습니다.
피드백 루프와 재현 케이스의 차이점은 무엇인가요?
피드백 루프는 버그를 감지하는 메커니즘입니다. 재현 케이스는 루프가 실패를 보여주도록 만드는 최소 입력입니다.
비결정적 버그는 어떻게 처리해야 하나요?
완벽한 재현이 아니라 더 높은 재현률을 목표로 하세요. 트리거를 100회 반복하고, 병렬화하고, 타이밍 윈도우를 좁히세요.

개발자 세부 정보

파일 구조