stress-test
작성자 alirezarezvanistress-test는 전략 수립, 투자 유치, GTM, 채용, 매출 관련 베팅 전에 비즈니스 가정을 압박 검증하는 Claude 경영진 멘토 skill입니다. /em:stress-test <assumption>를 사용하면 측정 가능한 주장으로 가정을 분리하고, 반대 증거를 검토하며, 계획이 어디에서 무너질 수 있는지 드러낼 수 있습니다.
이 skill의 점수는 74/100으로, 디렉터리에 등재하기에는 무리가 없지만 완성도 높은 도구형 패키지나 근거가 충분히 뒷받침된 패키지라기보다는 가벼운 자문 워크플로로 소개하는 편이 적절합니다. 디렉터리 사용자는 명확한 명령어와 충분한 방법론을 바탕으로 일반 프롬프트보다 덜 막연하게 에이전트가 비즈니스 가정을 stress-test하도록 만들 수 있습니다. 다만 repository에는 지원 참고 자료나 설치 안내 없이 단일 SKILL.md 파일만 제공되므로 도입성과 신뢰도에는 한계가 있습니다.
- 명확한 실행 방식과 사용 사례: frontmatter와 본문에서 계획을 확정하기 전에 검증되지 않은 비즈니스 가정을 테스트하는 용도로 `/em:stress-test <assumption>`를 지정합니다.
- 충실한 워크플로 콘텐츠: 7,559자 분량의 SKILL.md에 이름 붙은 방법론과 단계, 가정 유형, 제약 조건, 실무 비즈니스 예시가 포함되어 있습니다.
- 경영진·창업자 자문 용도에 잘 맞음: 매출 전망, 시장 규모, 경쟁 우위, 채용 속도, 리텐션 가정에 초점을 둡니다.
- 지원 파일, 참고 자료, 스크립트, 인용된 프레임워크가 포함되어 있지 않아 사용자는 SKILL.md 안내에만 의존해야 합니다.
- skill 경로에 설치 명령이나 repository 수준의 README가 없어, 이 skill 구조에 익숙하지 않은 사용자에게는 도입 과정이 다소 불명확할 수 있습니다.
stress-test skill 개요
stress-test의 용도
stress-test skill은 Claude 스타일의 임원 멘토링을 위한 비즈니스 가정 검증 워크플로입니다. “엔터프라이즈 구매자가 6개월 파일럿을 받아들일 것이다”, “우리 TAM은 €2.3B다”, “12월까지 $2M ARR에 도달할 수 있다”처럼 전략적 주장을 세운 뒤, 그 주장을 전제로 자본 투입, 채용, 로드맵, 투자자 메시지를 확정하기 전에 압력을 가해 검증하도록 돕습니다.
계획이 덜 완성된 것이 문제가 아니라, 매력적으로 보이는 하나의 가정이 계획 전체를 지나치게 떠받치고 있을 때 사용하기 좋습니다.
가장 잘 맞는 사용자와 의사결정
이 stress-test skill은 중요한 결정을 앞두고 더 날카로운 하방 분석이 필요한 창업자, 경영진, 제품 리더, 재무팀, 전략 담당자, 자문가에게 잘 맞습니다. 투자유치 계획, go-to-market 전략, 가격 변경, 시장 진입 베팅, 리텐션 전망, 채용 확대, 해자 주장, 이사회 내러티브 같은 작업에 적합합니다.
특히 stress-test for Strategic Planning으로 유용합니다. 낙관이 많이 섞인 계획상의 가정을 명시적이고 반증 가능한 주장으로 바꿔, 실제로 도전해볼 수 있게 해주기 때문입니다.
무엇이 다른가
일반적인 프롬프트는 AI에게 “리스크를 찾아달라”고 요청하는 수준에 그칠 수 있습니다. stress-test 워크플로는 더 좁고 선명합니다. 가정을 분리하고, 구체화하고, 반대 증거를 찾고, 계획이 어디서 무너지는지 드러냅니다. 이 초점이 중요한 이유는 모호한 가정은 반증하기 어렵기 때문입니다. “시장이 크다”는 약한 분석만 낳습니다. 반면 “독일의 중소기업이 18개월 안에 B2B 지출 관리 소프트웨어에 연간 €X를 지출할 것이다”는 모델이 검증할 수 있는 대상이 됩니다.
stress-test skill 사용 방법
stress-test 설치와 저장소 맥락
GitHub skill repository에서 사용하는 skill manager로 설치합니다. 예를 들면 다음과 같습니다.
npx skills add alirezarezvani/claude-skills --skill stress-test
이 skill의 위치는 다음과 같습니다.
c-level-advisor/executive-mentor/skills/stress-test
이 repository 항목은 자체 완결형으로 보입니다. 먼저 확인해야 할 핵심 파일은 SKILL.md입니다. 제공된 트리에서는 별도의 rules/, resources/, references/ 또는 script가 보이지 않으므로, 도입 여부는 주로 내장된 방법론이 팀의 기획 워크플로와 맞는지에 달려 있습니다.
skill에 필요한 입력
넓은 주제가 아니라 하나의 가정을 넣어 호출하세요.
/em:stress-test <assumption>
약한 입력:
/em:stress-test our enterprise strategy
더 나은 입력:
/em:stress-test enterprise buyers in regulated industries will tolerate a six-month unpaid pilot before procurement approval
강한 입력:
/em:stress-test 40% of qualified enterprise prospects in US healthcare will accept a six-month unpaid pilot, and at least 25% of those pilots will convert to $120k ACV contracts within one quarter
강한 버전에는 세그먼트, 행동, 시점, 전환 기대치, 상업적 결과가 들어 있습니다. 그래서 skill이 각 요소를 따로 공격적으로 검토할 수 있고, 일반적인 전략 리스크 목록보다 훨씬 유용한 결과를 얻을 수 있습니다.
추천하는 stress-test 사용 워크플로
계획이 이미 내부의 정설이 된 뒤가 아니라, 의사결정이 잠기기 전에 이 stress-test 가이드를 사용하세요.
- 낙관에 기대고 있는 계획을 찾습니다. 매출 전망, 시장 진입, 채용 모델, 리텐션 목표, 가격 변경, 자금 조달 일정, 해자 주장 등이 여기에 해당합니다.
- 틀렸을 때 계획을 가장 크게 훼손할 단 하나의 가정을 뽑아냅니다.
- 고객 세그먼트, 지역, 기간, 물량, 가격, 전환율, 비용 등을 포함해 측정 가능한 주장으로 다시 씁니다.
- 그 가정에 대해
/em:stress-test를 실행합니다. - 후속 질문을 던집니다. “이 가정을 가장 빨리 반증할 증거는 무엇인가?”, “어떤 선행지표를 봐야 하는가?”, “이 가정이 틀려도 살아남는 더 낮은 리스크의 계획은 무엇인가?”
이 방식은 경영진 리뷰에서 특히 잘 작동합니다. 확신과 증거를 분리해주기 때문입니다.
의존하기 전에 읽어야 할 파일
SKILL.md부터 시작하세요. 가정이 실패하는 이유, stress-test 방법론, 가정 분리, 반대 증거 찾기와 관련된 섹션을 특히 주의 깊게 보세요. 현재 보이는 skill에는 별도의 reference pack이나 automation이 없기 때문에, 시장 데이터를 가져오거나 숫자를 독립적으로 검증해줄 것이라고 기대해서는 안 됩니다. 구조화된 추론 보조 도구로 보고, 자체 사실관계, 벤치마크, 고객 증거, CRM 데이터, 재무 모델 가정, 투자자 제약 조건을 함께 가져와야 합니다.
stress-test skill FAQ
stress-test는 스타트업 전용인가요?
아닙니다. 예시는 창업자에게 친숙하지만, 불확실성 속에서 베팅하는 모든 조직에 적용할 수 있는 패턴입니다. 기업 전략팀도 시장 확장, 조달 가정, 영업 캐파 계획, 전환 프로그램, 제품 포트폴리오 의사결정에 사용할 수 있습니다. 핵심 조건은 검증 가능한 비즈니스 가정에 의존하는 의사결정이어야 한다는 점입니다.
Claude에게 리스크를 물어보는 것보다 무엇이 나은가요?
일반적인 리스크 프롬프트는 경쟁, 예산, 타이밍, 실행, 도입처럼 넓은 목록을 내놓는 경우가 많습니다. stress-test skill은 계획을 떠받치는 핵심 가정을 이름 붙이고, 그 가정을 직접 공격하도록 유도합니다. 그래서 분석이 의사결정과 더 밀접해집니다. “영업이 어려울 수 있다”가 아니라, “mid-market buyers will close in 45 days at $30k ACV without security review”라는 구체적 믿음에 압력을 가하게 됩니다.
언제 이 skill을 쓰지 말아야 하나요?
시장 조사, 법률 자문, 재무 감사, 고객 발견, 통계적 예측을 대체하는 용도로 사용하면 안 됩니다. 또한 가정이 아니라 슬로건을 입력하면 성능이 떨어집니다. 질문이 “어떤 사업을 만들어야 하는가?”처럼 탐색적이라면, 먼저 discovery나 strategy framing부터 시작하세요. 이미 면밀히 검토할 만한 주장이 있을 때 stress-test를 사용하세요.
stress-test는 초보자도 쓰기 쉬운가요?
네, 가정을 명확하게 쓸 수 있다면 충분히 사용할 수 있습니다. 초보자는 먼저 모델에게 모호한 계획을 여러 개의 후보 가정으로 바꾸게 한 다음, 그중 가장 위험한 것을 골라 /em:stress-test에 넣으면 도움을 얻는 경우가 많습니다. 경험 많은 운영자라면 처음부터 수치 기준, 알려진 증거, 제약 조건, 의사결정의 이해관계를 함께 제공하는 것이 좋습니다.
stress-test skill 개선 방법
가정을 더 반증 가능하게 만들기
stress-test 결과를 개선하는 가장 중요한 방법은 모호함을 없애는 것입니다. 누가, 무엇을, 어디서, 언제, 얼마나, 어떤 결과를 기준으로 판단할지 포함하세요.
다음처럼 쓰는 대신:
customers will love the product
이렇게 쓰세요:
at least 30% of finance teams at 200-1000 employee SaaS companies will switch from spreadsheets to our forecasting tool within 90 days if priced below $500/month
이렇게 하면 skill이 세그먼트, 긴급성, 전환 행동, 기간, 가격이라는 명확한 공격 지점을 갖게 됩니다.
증거와 제약 조건을 처음부터 추가하기
stress-test skill은 이미 존재하는 증거를 알수록 더 잘 추론할 수 있습니다. 고객 인터뷰, win/loss 메모, pipeline data, conversion rates, churn cohorts, sales cycle history, competitive alternatives, budget cycles, procurement friction, investor milestones를 포함하세요.
더 강한 프롬프트는 다음 내용을 덧붙일 수 있습니다.
Known evidence: 12 discovery calls, 3 verbal pilots, no signed LOIs, average procurement cycle 4-7 months, current runway 9 months.
이렇게 하면 출력이 모든 가능성을 같은 확률로 취급하는 일을 막을 수 있습니다.
흔한 실패 패턴 주의하기
가장 흔한 실패 패턴은 너무 넓거나, 너무 정치적이거나, 실제 의사결정과 너무 동떨어진 가정을 stress test하는 것입니다. 또 다른 흔한 문제는 도전이 아니라 검증을 요청하는 것입니다. 유용한 결과를 원한다면 프롬프트를 “이 계획이 잘된다는 것을 증명해줘”로 잡지 마세요. “우리가 이 가정에 의존하기 전에 깨뜨려줘”로 잡아야 합니다.
여러 가정을 하나의 명령에 묶는 것도 피하세요. 계획이 시장 규모, 지불 의향, 영업 사이클, 리텐션에 의존한다면 각각을 따로 테스트해야 합니다.
첫 stress-test 이후 반복하기
첫 결과를 받은 뒤에는 의사결정에 쓸 수 있는 수준으로 다듬어 달라고 요청하세요.
- “Rank the failure points by probability and severity.”
- “What evidence would change your view fastest?”
- “Design a two-week test for the riskiest assumption.”
- “Rewrite the plan so it still works if this assumption is 50% wrong.”
- “What board or investor question would expose this weakness?”
이렇게 하면 stress-test가 일회성 비평에 그치지 않고, 가정, 도전, 증거, 수정, 의사결정으로 이어지는 실질적인 기획 루프가 됩니다.
