why

why skill 개요

why skill은 증상을 원인 연쇄로 풀어낸 뒤, 바로 실행할 수 있는 수정안까지 연결하는 데 초점을 둔 Five Whys 분석 도구입니다. UX Audit, 제품 이슈, 버그, 프로세스 붕괴처럼 why skill이 필요한 상황이라면, 무엇이 일어났는지와 왜 그런 일이 일어났는지를 분리해 보는 데 도움이 됩니다.

why skill은 무엇에 쓰는가

why는 “사용자가 이탈했다”, “빌드가 실패했다”, “팀이 마감일을 놓쳤다”처럼 가장 먼저 떠오르는 설명이 너무 얕아 보일 때 쓰기에 좋습니다. 이 skill은 눈에 보이는 증상에서 멈추지 않고, 표면적 현상이 아니라 시스템적 원인에 도달할 때까지 분석을 이어가도록 설계되어 있습니다.

why skill에 가장 잘 맞는 사용자

이 why 가이드는 프레임워크를 처음부터 만들지 않고도 구조화된 근본 원인 분석 경로가 필요한 운영 담당자, 분석가, 엔지니어, UX 검토자에게 가장 잘 맞습니다. 이미 구체적인 문제 정의가 있고, 그것을 엄격하게 검토할 방법이 필요한 사람에게 적합합니다.

why skill이 유용한 이유

핵심 가치는 속도와 집중도입니다. 반복해서 쓸 수 있는 질문 형태, 기본 깊이, 그리고 원인이 정말 증상을 설명하는지 검증하는 단계가 있어, 막연한 브레인스토밍에서 같은 답만 맴도는 상황을 줄여 줍니다. 그래서 why install은 일반적인 아이디어 회의가 늘 뻔한 답으로 돌아갈 때 특히 가치가 있습니다.

why skill 사용법

why skill 설치하고 실행하기

why skill을 skills workflow에 설치한 다음, 막연한 주제가 아니라 구체적인 증상으로 호출하세요. 예를 들면 /why checkout conversion fell 18% after the redesign 또는 /why CI failures spike on main branch처럼 시작하면 좋습니다.

이론이 아니라 문제 진술을 넣기

이 skill은 하나의 관찰 가능한 이슈, 그것이 나타나는 맥락, 그리고 이미 알려진 제약 조건을 함께 줄 때 가장 잘 작동합니다. 좋은 입력 예: 새 검증 규칙이 배포된 뒤 모바일 사용자가 signup form의 2단계에서 이탈한다; 현재 UX flow에서 root causes를 분석해라. 나쁜 입력 예: 왜 UX가 별로지?

먼저 중요한 소스 파일부터 읽기

분석 흐름을 이해하려면 먼저 SKILL.md를 읽고, 이어서 환경에 존재한다면 README.md, AGENTS.md, metadata.json, 그리고 rules/, resources/, references/, scripts/ 폴더를 확인하세요. 이 repository에서는 SKILL.md가 핵심 source of truth이므로, 적용하기 전에 분석 단계와 예시를 먼저 읽는 것이 가장 빠른 경로입니다.

분석을 작업 세션처럼 진행하기

why를 가이드형 체인으로 사용하세요. 증상을 먼저 적고, 각 “why”에 증거로 답한 다음, 원인이 근본적이고 검증 가능해지는 지점에서 멈추면 됩니다. 원인이 여러 개라면 하나로 억지 통합하지 말고 분기해서 다루고, 마지막에는 증상을 가리는 대신 root cause를 제거하는 변경안을 제시하세요.

why skill FAQ

why skill은 기술 디버깅에만 쓰는가?

아닙니다. why skill은 실제 증상을 설명할 수만 있다면 UX Audit, 운영, 제품, 지원, 팀 프로세스 문제에도 사용할 수 있습니다. 핵심은 인과관계로 추적 가능한 문제여야 한다는 점입니다.

매번 꼭 다섯 번 반복해야 하나?

꼭 그렇지는 않습니다. 다섯 번은 기본 깊이일 뿐이고, 더 나은 기준은 “설명이 실행 가능하고 안정적인 지점에서 멈추는 것”입니다. 이미 세 단계 안에 진짜 root cause에 도달했다면, 두 번을 더 억지로 붙이는 것은 보통 잡음만 늘립니다.

why skill은 일반 프롬프트와 어떻게 다른가?

일반 프롬프트는 종종 아이디어를 묻지만, why는 엄격한 인과관계를 묻습니다. root-cause analysis, 교정 조치, 또는 원인에서 증상까지 역추적해 검증할 수 있는 리뷰가 필요할 때 더 적합합니다.

언제는 why skill을 쓰지 말아야 하나?

열린 발상의 아이데이션, 넓은 범위의 전략, 또는 관찰 가능한 증상이 없는 문제에는 쓰지 마세요. 원인 체인을 테스트할 만큼 이슈를 명확하게 정의할 수 없다면, why skill은 얕은 추측만 만들어 냅니다.

why skill 개선하기

더 선명한 증상으로 시작하기

why 출력 품질은 첫 문장에 크게 좌우됩니다. 무엇이 망가졌는지, 누가 영향을 받았는지, 언제 바뀌었는지, 그리고 어떤 환경에서 일어났는지를 함께 넣으세요: 새 onboarding copy 이후 iOS에서만 first-time activation이 떨어졌다. 이런 식의 입력이 activation is down보다 훨씬 좋습니다.

결론이 아니라 증거를 더하기

로그, 사용자 인용, funnel step, 스크린샷, 타임스탬프, release marker가 있다면 함께 주세요. 증거가 있으면 why가 상관관계와 원인을 구분하기 쉬워지고, 가장 그럴듯한 첫 설명에 분석이 멈추는 것도 막을 수 있습니다.

체인을 거꾸로 검증하기

좋은 why 결과는 root cause에서 위로 올라가며 증상을 설명해야 합니다. 마지막 원인이 앞 단계들을 분명하게 만들어내지 못한다면, 실행하기 전에 체인을 다듬거나 분기해서 나누세요.

발견한 내용을 하나의 수정 가능한 액션으로 바꾸기

가장 좋은 why 결과는 배포하거나 문서화하거나 측정할 수 있는 변경으로 끝납니다. 실제로 통제할 수 있는 원인에 후속 조치를 집중하고, 수정 후에는 skill을 다시 실행해 증상이 예상한 방향으로 움직이는지 확인하세요.