Claude에게는 더 많은 프롬프트가 아니라 추론의 규율이 필요합니다

대규모 언어 모델 (Large language models)은 구조적인 것처럼 들리는 데 능숙합니다. 하지만 그것이 구조적이라는 것과 동일하지는 않습니다.

AI 어시스턴트에게 "제1원칙 (first principles)을 사용하라"고 요청하면, 답변 상단에 "제1원칙"이라는 문구를 포함한 자신감 넘치는 답변을 내놓을 수 있습니다. "이 계획을 레드팀 (red-team)하라"고 요청하면 일반적인 리스크들을 나열할 수도 있습니다. "OODA를 적용하라"고 요청하면 가정, 제약 조건, 증거에 맞게 방향을 설정하는(orienting) 핵심적인 과정 없이 단순히 네 가지 제목만을 나열할 수도 있습니다.

이러한 실패 모드 (failure mode)는 답변이 책임감 있게 보이기 때문에 미묘합니다. 적절한 어휘를 사용하고, 적절한 형태를 갖추고 있습니다. 하지만 방법론이 실제로 분석을 제어하지는 못했습니다.

저는 그 간극을 겨냥하기 위해 methodology-toolkit을 구축했습니다.

목표는 Claude Code에 더 영리한 프롬프트를 추가하는 것이 아닙니다. 목표는 사소하지 않은 결정들 주변에 작은 규율 (discipline) 계층을 추가하는 것입니다. 즉, 문제를 분류하고, 적합한 방법론을 선택하며, 해당 방법론을 명시적으로 적용하고, 핵심적인 주장을 검증하며, 계획이 실행으로 굳어지기 전에 스트레스 테스트 (stress-test)를 수행하는 것입니다.

저장소 (Repository): https://github.com/gagharutyunyan1993/methodology-toolkit

문제점: 방법론 연극 (Methodology Theater)

방법론은 주의력을 제한해주기 때문에 유용합니다.

제1원칙 (First Principles)은 가정을 제거하고 기초적인 사실로부터 다시 구축할 것을 요구합니다. ACH는 선호하는 답변에 대한 확인을 수집하는 것이 아니라, 반증되는 증거를 통해 경쟁하는 가설들을 비교하도록 요구합니다. OODA는 편향과 맥락이 가장 큰 역할을 하는 방향 설정 (orientation) 단계와 가공되지 않은 관찰 (raw observation) 단계를 분리하도록 요구합니다. 사전 사후 분석 (Pre-mortem)은 낙관주의가 명백한 리스크를 걸러내지 않도록 계획이 이미 실패했다고 가정하도록 요구합니다.

AI 어시스턴트가 단순히 이러한 방법론들의 이름만 언급할 때, 여러분은 이득은 얻지 못한 채 비용만 지불하게 됩니다.

답변은 더 길어지고, 더 격식을 차리며, 더 설득력 있게 변하지만, 반드시 더 정확해지는 것은 아닙니다. 이는 짧고 직관적인 답변보다 더 나쁩니다. 구조가 잘못된 확신 (false confidence)을 만들어내기 때문입니다.

methodology-toolkit은 이를 핵심적인 안티 패턴 (anti-pattern)으로 취급합니다:

어떤 방법론에 이름이 붙여졌다면, 그 단계들을 반드시 수행해야 합니다.

힌트만 주거나 요약해서는 안 됩니다. 실제로 적용해야 합니다.

방법론 연극 (Methodology theater): 적절한 어휘는 사용하지만, 실제로는 방법론이 통제권을 갖지 못하는 상태.

두 번째 문제: 확신에 찬 오답 (Confident Wrongness)

또 다른 실패 모드는 운영적인 측면입니다. AI 에이전트들은 종종 기억이나 불완전한 문맥 (context)에 기반하여 핵심적인 주장을 펼칩니다.

코드베이스 (codebase) 내에서는 다음과 같은 모습으로 나타날 수 있습니다:

• 파일을 열어보지 않고 어떤 파일이 특정 동작을 담당하는지 가정함;
• 현재 코드 대신 오래된 문서 (stale docs)를 신뢰함;
• 눈에 보이는 가장 가까운 증상만을 패치 (patching)함;
• 생성된 타입 (types)이나 주석을 사실 (ground truth)로 취급함;
• 해당 아이디어를 반증할 수 있는 grep, 테스트

첫 번째는 methodology-driven-thinking (방법론 중심 사고) 기술입니다. 이는 아키텍처 결정, 우선순위 지정, 근본 원인 분석 (root-cause analysis), 전략, 불확실성 하에서의 계획 수립, 또는 트레이드오프 분석 (tradeoff analysis)과 같은 비사소한 (non-trivial) 작업에서 활성화될 수 있습니다. 이는 Cynefin을 디스패처 (dispatcher)로 사용하여 시작합니다. 즉, 명확한 작업은 직접적으로 답변해야 하며, 복잡한 (complicated), 난해한 (complex), 또는 혼돈스러운 (chaotic) 작업은 다르게 취급됩니다.

두 번째는 /methodology-toolkit:method 슬래시 명령 (slash command)입니다. 이는 사용자가 전체 프로토콜을 명시적으로 원하거나, 특정 방법론을 강제하고 싶을 때 수동으로 트리거할 수 있는 기능을 제공합니다.

/methodology-toolkit:method Q3 백로그의 우선순위를 어떻게 정해야 할까요?
/methodology-toolkit:method ACH+pre-mortem 폴링을 WebSocket으로 마이그레이션해야 할까요?
/methodology-toolkit:method red-team <방금 작성한 계획>

세 번째는 red-team-critic 서브에이전트 (subagent)입니다. 이 에이전트는 의도적으로 적대적 (adversarial)입니다. 긍정적인 측면의 균형을 맞추려 하지 않습니다. 이 에이전트의 역할은 하중을 지탱하는 가정 (load-bearing assumptions), 실패 모드 (failure modes), 공격 경로 (attack paths), 그리고 반증 증거 (disconfirming evidence)를 찾아내는 것입니다.

현재 공유 인덱스 (shared index)에는 Cynefin, OODA, PDCA, First Principles, 5 Whys, Porter, ADKAR, JTBD, Theory of Constraints, OKR, Minto, BATNA, ACH, Red Team, Pre-mortem, PMESII, SWOT/TOWS, SAT, 그리고 Quality of Information Check를 포함하여 29개의 방법론이 포함되어 있습니다.

숫자가 중요한 것이 아닙니다. 중요한 점은 각 방법론이 명시적인 use_when (사용 시기), avoid_when (회피 시기), steps (단계), 그리고 예상되는 출력 (expected output)을 가지고 있다는 것입니다. 에이전트는 기억에 의존하는 대신 해당 인덱스를 읽도록 지시받습니다.

디자인 선택 1: 적용하기 전에 분류하라

방법론을 오용하는 가장 쉬운 방법은 잘못된 유형의 문제에 적용하는 것입니다.

어떤 문제들은 명확합니다. 구문 (syntax) 질문에는 OODA가 필요하지 않습니다. 직접적인 명령에는 pre-mortem이 필요하지 않습니다. 작은 결정론적 (deterministic) 수정에는 세 가지 프레임워크와 리더십 메모가 필요하지 않습니다.

다른 문제들은 복잡합니다 (complicated): 답은 전문 지식과 분석을 통해 알 수 있습니다. 바로 그 지점에서 제1원칙 (First Principles), ACH, 5 Whys, 제약 이론 (Theory of Constraints), Porter, 또는 PMESII와 같은 방법론들이 도움이 될 수 있습니다.

어떤 문제들은 난해합니다 (complex): 원인과 결과는 사후에만 보입니다. 이러한 문제들은 탐침 (probes), 피드백 루프 (feedback loops), 그리고 반복 (iteration)이 필요합니다. OODA, PDCA, Double Diamond, 그리고 JTBD가 여기에 더 적합합니다.

어떤 문제들은 혼돈스럽습니다 (chaotic): 첫 번째 과업은 분석이 아니라 안정화입니다.

이것이 바로 기술이 Cynefin을 먼저 사용하는 이유입니다. 이는 플러그인이 모든 질문을 워크숍으로 바꿔버리는 프레임워크 기계 (framework machine)가 되는 것을 방지합니다.

설계 선택 2: 방법론을 명시적으로 적용하기

이 툴킷에는 엄격한 규칙이 있습니다:

방법론의 단계를 거치지 않고 단순히 이름만 언급하지 마십시오.

만약 답변이 OODA를 사용한다면, 사용자는 관찰 (Observe), 방향 설정 (Orient), 결정 (Decide), 실행 (Act)을 확인해야 합니다. 만약 ACH를 사용한다면, 사용자는 상충하는 가설 (competing hypotheses), 증거 (evidence), 그리고 반증 논리 (disconfirming logic)를 확인해야 합니다. 만약 사전 사후 분석 (Pre-mortem)을 사용한다면, 답변은 실패를 상상하고 그 원인으로 역추적해야 합니다.

이는 답변을 길게 만들기 위함이 아닙니다. 실패를 가시화하기 위함입니다.

구조가 가시화되면 사용자는 이를 검토할 수 있습니다:

• 에이전트가 실제 병목 구간 (bottleneck)을 건너뛰었는가?
• 가설을 반증하려 하기보다 선호하는 가설을 확인(confirm)하기만 했는가?
• 2차 자료를 사실로 취급했는가?
• 방향 설정 (Orient) 단계에서 실제 가정 (assumptions)을 명시했는가?
• 사전 사후 분석 (pre-mortem)이 구체적인 실패 모드 (failure modes)를 드러냈는가, 아니면 막연한 걱정만을 나열했는가?

가시적인 구조는 분석을 디버깅 가능하게 (debuggable) 만듭니다.

설계 선택 3: 비판자 분리하기

자기 검토 (Self-review)는 유용하지만 약점이 있습니다. 첫 번째 답변을 만들어낸 것과 동일한 맥락이 검토 과정에서도 해당 답변을 정당화하는 경우가 많다는 점입니다.

red-team-critic 하위 에이전트 (subagent)는 더 날카로운 두 번째 검토 과정을 만들기 위해 존재합니다. 이 에이전트는 오직 비판만을 위해 설계되었습니다. 계획을 실패하게 만드는 요소가 무엇인지, 상대방이 무엇을 악용할 것인지, 어떤 가정이 가장 큰 비중을 차지하는지, 그리고 어떤 증거가 결정을 바꿀 것인지를 탐색합니다.

이 과정은 모든 작업에 대해 의도적으로 조용히 실행되지 않습니다. 독립적인 비판에는 비용이 따르기 때문입니다. 툴킷 (toolkit)은 결정이 되돌리기 어렵거나, 돈, 인증 (auth), 데이터 무결성 (data integrity), 보안 (security)과 관련되어 있거나, 첫 번째 답변이 검증된 증거에 기반하지 않았을 때 이 과정을 권장합니다.

red-team-critic은 긍정적인 측면과 균형을 맞추지 않습니다. 그것이 바로 핵심입니다.

예시: 아키텍처 결정 (Architecture Decision)

질문이 다음과 같다고 가정해 봅시다:

폴링 (polling)을 WebSocket으로 마이그레이션해야 할까요?

일반적인 AI의 답변은 WebSocket이 더 현대적이고 실시간처럼 들리기 때문에 흔히 WebSocket 쪽으로 기울곤 합니다. 지연 시간 (latency), 복잡성 (complexity), 확장성 (scaling), 브라우저 지원 (browser support), 서버 부하 (server load)와 같이 익숙한 장단점을 나열할 것입니다.

그것이 쓸모없는 것은 아니지만, 피상적입니다.

툴킷을 사용하면 분석의 형태가 다음과 같이 바뀌어야 합니다:

• Cynefin은 이 결정을 명확한 (clear) 것이 아니라 복잡한 (complicated) 또는 난해한 (complex) 것으로 분류합니다.
• 제1원리 (First Principles)는 실제로 어떤 실시간 속성이 요구되는지 묻습니다.
• ACH는 폴링 (polling), SSE, WebSocket을 각 옵션을 부정할 수 있는 증거와 비교합니다.
• 사전 부검 (Pre-mortem)은 출시 후 마이그레이션이 어떻게 실패할 것인지 묻습니다.

이를 통해 더 좁고 정교한 답변을 얻을 수 있습니다:

양방향 저지연 상호작용이 실제로 필요한 경우에만 WebSocket을 사용하십시오. 서버가 주로 클라이언트에 업데이트를 푸시하는 경우에는 SSE를 사용하십시오. 최신성 요구사항이 느슨하거나, 운영 범위 (operational surface)를 작게 유지해야 하거나, 현재의 병목 현상 (bottleneck)이 다른 곳에 있다면 폴링을 유지하거나 조정하십시오.

이 방법이 정답을 보장하지는 않습니다. 다만 정답으로 가는 경로를 개선합니다.

예시: 코드베이스 진단 (Codebase Diagnosis)

사용자에게 프로필이 없을 때 페이지가 충돌(crash)한다고 가정해 봅시다.

빠른 어시스턴트라면 다음과 같이 컴포넌트를 패치(patch)할 수도 있습니다:

user?.profile?.name

이것이 정답일 수도 있습니다. 하지만 실제 결함(defect)을 숨길 수도 있습니다.

툴킷(toolkit)을 사용할 때, 5 Whys(5번의 왜?)는 인과 관계(causal chain)가 기계적으로 유지되는 동안에만 적절합니다:

1. 왜 페이지가 충돌했는가? 렌더링(Rendering) 과정에서 누락된 필드에 접근했다.
2. 왜 필드가 누락되었는가? API가 프로필 객체를 반환하지 않았다.
3. 왜 API가 프로필을 반환하지 않았는가? 세션(session)이 부분적으로 만료되었다.
4. 왜 그 상태가 UI에 도달했는가? 인증 갱신(auth refresh) 경로가 응답을 정규화(normalize)하지 않았다.

이 시점에서 패치는 컴포넌트가 아니라 인증/데이터 계층(auth/data layer)에 위치해야 할 수도 있습니다.

여기서 정보 품질 확인(Quality of Information Check)이 중요합니다. 에이전트(agent)는 수정 사항이 어디에 적용되어야 할지 결정하기 전에 컴포넌트를 읽고, 호출자(callers)를 grep으로 찾고, API 매퍼(API mapper)를 조사하며, 관련 테스트를 실행해야 합니다.

이것이 해결하지 못하는 것

이 플러그인이 AI의 추론(reasoning)을 마법처럼 올바르게 만들어주는 것은 아닙니다.

이것은 도메인 전문 지식(domain expertise)을 대체하지 않습니다. 테스트를 실행하거나, 운영 텔레메트리(production telemetry)를 조사하거나, 사용자와 대화하거나, 비즈니스를 이해해야 할 필요성을 제거하지도 않습니다. 또한 모든 답변이 방법론적인 연습(methodology exercise)이 되어야 한다는 의미도 아닙니다.

사실, 규칙 중 하나는 문제가 명확하고 단순할 때는 종료하는 것입니다.

가치는 더 좁고 실용적입니다. 즉, AI 보조 작업에서 예측 가능한 몇 가지 실패 모드(failure modes)를 줄여줍니다.

• 프레임워크 이름을 장식용으로 사용하는 것을 어렵게 만듭니다.
• 가설(assumptions)을 검사하기 쉽게 만듭니다.
• 확신에 찬 주장 이전에 일차적 증거(primary evidence)를 권장합니다.
• 중대한 계획(high-stakes plans)에 대해 적대적 재검토(adversarial second pass)를 제공합니다.
• "더 깊이 생각하라"를 반복 가능한 프로토콜(repeatable protocol)로 바꿉니다.

사용해 보기

다음 마켓플레이스에서 설치하세요:

/plugin marketplace add gagharutyunyan1993/methodology-toolkit
/plugin install methodology-toolkit@methodology-toolkit

또는 로컬에서 실행해 보세요:

claude --plugin-dir /path/to/methodology-toolkit/plugins/methodology-toolkit

그런 다음 까다로운 질문을 던지거나, 메서드 명령(method command)을 직접 호출해 보세요:

/methodology-toolkit:method 이 모듈을 다시 작성해야 할까요, 아니면 점진적으로 안정화해야 할까요?
/methodology-toolkit:method ACH+pre-mortem 이번 주에 이 마이그레이션 (migration)을 출시해야 할까요?