analyse-problem

analyse-problem 개요

analyse-problem의 용도

analyse-problem skill은 복잡하게 뒤엉킨 이슈를 구조화된 A3 문제 브리프로 바꿔 줍니다. 배경, 현 상태, 목표 상태, 근본 원인 분석, 대응책, 실행 계획, 후속 점검까지 한 번에 정리할 수 있습니다. 브레인스토밍보다 의사결정에 바로 쓸 수 있는 문제 진술이 필요할 때, 특히 Strategic Planning, ops, product, engineering 업무에 잘 맞습니다.

어떤 사람이 설치하면 좋은가

문제를 명확하게 설명해야 하거나, 이해관계자를 정렬해야 하거나, 증상에서 원인으로 넘어가야 하는 일이 잦다면 analyse-problem을 설치하는 편이 좋습니다. 장애 리뷰, 프로세스 개선, 프로젝트 병목, 기획 세션처럼 반복 가능한 형식이 필요한 사람에게 잘 맞습니다.

무엇이 다른가

핵심 가치는 “AI 글쓰기”를 더 많이 만드는 데 있지 않고, 제약을 거는 데 있습니다. analyse-problem은 모델이 문제를 한 페이지 안에 정리하고, 사실과 가정을 구분하고, 마지막에 실행과 검증으로 끝내도록 유도합니다. 그래서 Strategic Planning용 일반 프롬프트보다 더 유용합니다. 판단 프레임을 더 단단하게 잡아 주기 때문입니다.

analyse-problem skill 사용 방법

설치하고 실행하기

skills manager에서 설치 절차를 진행한 다음, 짧은 문제 진술과 함께 analyse-problem skill을 실행하세요. 저장소의 사용 패턴은 /analyse-problem [problem_description]이며, 기본적으로 선택적 문제 설명 입력과 마크다운 출력 지원을 전제로 합니다. 환경에서 skill 매핑 방식이 다르더라도 의도는 동일하게 전달하면 됩니다. 즉, 간결하고 구체적인 이슈 진술을 넣으면 됩니다.

올바른 입력을 넣기

좋은 입력은 문제, 범위, 근거를 함께 담습니다. 예를 들면: “이번 달 enterprise accounts에서 customer onboarding 완료율이 18% 떨어졌습니다. 원인을 분석하고 대응책을 제안해 주세요.” 반대로 “onboarding을 개선해 달라”처럼만 쓰면, 모델이 대상, 담당자, 성공 지표를 추측해야 합니다. analyse-problem 사용 시에는 다음을 포함하세요.

• 나타난 증상
• 영향을 받는 프로세스나 팀
• 데이터 포인트, 사례, 타임라인
• 원하는 결과나 제약 조건

먼저 확인할 repository 구성

먼저 SKILL.md를 보고, 이어서 README.md, AGENTS.md, metadata.json 안의 연결 지침을 확인하세요. rules/, resources/, references/, scripts/ 같은 폴더가 있으면 그것도 함께 살펴보면 좋습니다. 이 repo의 경우 핵심 소스가 plugins/kaizen/skills/analyse-problem에 모여 있어서, 추가로 따라가야 할 보조 구조는 많지 않습니다.

더 나은 출력을 위한 프롬프트 구성

좋은 analyse-problem guide prompt는 A3의 각 섹션을 채울 수 있을 만큼 구체적이어야 합니다. 예를 들어:
“Q2에 release delays가 증가한 이유를 analyse-problem으로 문서화해 주세요. 기준 지표, 가능한 근본 원인, 영향도와 노력도를 기준으로 순위를 매긴 3개의 대응책, 그리고 30일 후속 점검 계획을 포함해 주세요.”
이렇게 요청하면 모델이 정리할 사실과 지원해야 할 결정을 함께 받기 때문에, 막연하게 분석을 부탁하는 것보다 훨씬 실용적인 결과가 나옵니다.

analyse-problem skill FAQ

analyse-problem은 Strategic Planning에만 쓰이나요?

아닙니다. 문제를 프레임화하고, 조사하고, 실행 과제를 부여해야 하는 곳이라면 어디서든 유용합니다. product 이슈, 운영 병목, 팀 프로세스 실패, 전략 기획 리뷰 모두 해당됩니다. A3 형식 자체는 범용적이지만, 다른 사람과 공유할 결과물이 필요할 때 특히 가치가 큽니다.

일반 프롬프트와 무엇이 다른가요?

일반 프롬프트도 분석을 요청할 수는 있지만, analyse-problem skill은 재사용 가능한 구조와 출력 규율을 제공합니다. 근본 원인, 대응책, 후속 점검을 빠짐없이 일관되게 담아야 할 때 그 차이가 분명해집니다. 자유 서술형 설명보다 훨씬 안정적입니다.

초보자도 잘 사용할 수 있나요?

네, 입력만 구체적이면 가능합니다. 초보자는 보통 문제가 너무 모호할 때 어려움을 겪습니다. 따라서 관찰된 증상, 범위, 시점, 대략적인 목표를 가능한 한 알려 주세요. 이 skill은 아직 정리되지 않은 생각을 구조화하는 데는 도움이 되지만, 없는 사실을 안전하게 만들어 낼 수는 없습니다.

언제는 사용하지 않는 게 좋나요?

빠른 요약, 상태 업데이트, 창의적인 아이디어 세션만 필요할 때는 analyse-problem을 쓰지 않는 편이 좋습니다. 문제의 범위가 아직 안정되지 않았을 때도 적합하지 않습니다. 그런 경우에는 먼저 문제를 정의한 뒤 구조화된 분석을 요청해야 합니다.

analyse-problem skill 개선 방법

결론만 주지 말고 근거를 함께 넣기

가장 큰 품질 향상은 구체적인 입력에서 나옵니다. 지표, 사례, 장애 발생 시각, 사용자 인용, 프로세스 메모 같은 정보가 있으면 바로 넣으세요. 이미 원인을 의심하고 있더라도 사실로 단정하지 말고 가설로 표시해야 합니다. 그래야 분석이 그 가설을 검증하지, 그대로 되풀이하지 않습니다.

의사결정에 바로 쓰일 출력을 요청하기

analyse-problem에서는 팀이 행동으로 옮길 수 있는 내용을 요청하는 것이 좋습니다. 예를 들면 우선순위가 매겨진 원인, 원인에 연결된 대응책, 담당자, 의존성, 검증 계획입니다. Strategic Planning 관점의 가치를 원한다면 장황한 서술보다 영향도와 노력도의 tradeoff를 요청하세요.

자주 생기는 실패 패턴을 점검하기

가장 흔한 실패는 증상을 과하게 설명하고 목표 상태를 너무 적게 적는 것입니다. 또 하나는 서로 관련 없는 여러 문제를 한 페이지에 섞는 것입니다. 무관한 이슈는 분리하고, 하나의 분석은 하나의 결정, 하나의 담당자, 하나의 측정 가능한 결과에 집중시키세요.

첫 초안 뒤에 반드시 다듬기

첫 번째 결과물로 빠진 데이터, 약한 인과 연결, 근본 원인과 맞지 않는 조치를 확인하세요. 그다음 예산, 마감일, 팀 역량, 리더십 검토용 형식 같은 새로운 사실과 제약을 반영해 프롬프트를 다시 조정하면 됩니다.