Claude Code를 비서에서 전략가로 바꾸는 법: 반론·검증·대안 루틴 설계하기

AI한테 “PostgreSQL 쓸까, MongoDB 쓸까?” 물어보면 뭐라 하죠?

“프로젝트 요구사항에 따라 다릅니다.”

맞는 말인데, 도움은 안 됩니다.

진짜 필요한 건 이겁니다:

“PostgreSQL 채택 확률 65%, MongoDB 35%. PostgreSQL 숨은 가정: 조인 패턴이 3개 이상. 반대 시나리오: 스키마가 6개월 내 3번 이상 바뀌면 MongoDB가 유리.”

같은 질문인데, 답의 깊이가 완전 다르죠?

오늘은 AI 코딩의 진짜 병목이 뭔지, 그리고 이걸 해결하는 Stack Skills이라는 7개 메타 인지형 스킬 묶음을 소개합니다.


핵심 요약

항목내용
문제AI 코딩 도구는 “더 빨리 쓰기”에 집중, “더 잘 생각하기”는 부재
해결Stack Skills — 7개 메타 인지형 스킬 묶음
핵심 스킬adversarial-review (반론), creativity-sampler (대안 비교)
작동 원리답 1개 → 옵션·확률·숨은 가정·반대 시나리오 구조로 전환
호환성Claude Code + Codex 등 다른 환경에서도 사용 가능

빠른 AI와 좋은 AI는 왜 다른가

솔직히 저도 처음엔 몰랐어요.

Claude Code든 Copilot이든 Cursor든, AI 코딩 도구 써보면서 “와, 빠르다!” 감탄했거든요. 코드 생성은 빨라졌고, 보일러플레이트 의미 없어졌고, 반복 작업 줄었고.

근데 문제가 있었어요.

자꾸 틀려요.

코드 자체는 돌아가요. 문법 에러 없고, 빌드도 되고. 근데 아키텍처 결정이 틀렸거나확장성 고려 안 했거나3개월 뒤에 기술부채가 되는 코드.

이유를 생각해봤는데요.

기존 AI 코딩 스킬은 전부 속도 에 집중합니다:

  • “코드 더 빨리 써줘”
  • “보일러플레이트 자동 생성해줘”
  • “리팩토링 즉시 해줘”

근데 “이 설계가 맞는지 한번 따져봐” 는 없었어요.

비유하면 이래요:

택시 기사한테 “빨리 가주세요” 했더니 엄청 빨리 갔는데, 목적지가 틀렸다.

속도는 방향이 맞을 때만 의미 있습니다.


메타 인지형 스킬이 하는 일

그래서 등장한 게 Stack Skills 입니다.

@thestack_ai가 공개한 이 스킬 묶음의 핵심을 한 줄로 요약하면:

AI가 “답을 내기 전에 생각하게” 만든다.

일반적인 AI 코딩 스킬과 뭐가 다른지 비교해볼까요?

일반 AI 코딩 스킬Stack Skills (메타 인지형)
목적코드를 빨리 쓴다결정을 잘 내린다
출력완성된 코드 한 벌옵션 비교 + 확률 + 가정 + 반론
사고 방식“시키면 한다”“이게 맞는지 먼저 따진다”
비유비서전략 컨설턴트

7개 메타 인지형 스킬이 뭘 하는지 하나씩 볼게요.

7가지 스킬 개요

  1. adversarial-review — 만들어진 계획을 적극적으로 공격하고 약점 찾기
  2. creativity-sampler — 여러 아키텍처 대안을 확률과 트레이드오프로 비교
  3. assumption-surfacer — 숨겨진 전제를 명시적으로 드러내기
  4. risk-scenario-generator — 최악의 시나리오와 확률 도출
  5. decision-journal — 결정 이력과 근거를 구조화해 기록
  6. counter-argument-engine — 모든 추천에 반론을 자동 생성
  7. probability-calibrator — 주관적 확신 → 객관적 확률로 보정

핵심은 이겁니다: 답 하나를 찍는 대신, 대안과 전제를 같이 검토하게 만든다는 거.


creativity-sampler와 adversarial-review 예시 읽기

말로만 하면 감이 안 오니까 실제 예시 보겠습니다.

예시 1: creativity-sampler — 데이터베이스 선택

기존 방식으로 Claude에게 물으면:

Q: 우리 프로젝트에 PostgreSQL 쓸까요?
A: PostgreSQL은 관계형 데이터베이스로 ACID를 지원하며... (장점 나열)
   → 추천합니다.

끝. 대안 없음. 확률 없음. 가정 없음.

creativity-sampler 적용 후:

┌─────────────────────────────────────────────┐
│  Database Architecture Decision             │
├──────────┬──────────┬───────────┬───────────┤
│ Option   │ Fit (%)  │ 숨은 가정  │ 반대 시나리오│
├──────────┼──────────┼───────────┼───────────┤
│ Postgres │   65%    │ 조인 패턴  │ 스키마 변경 │
│          │          │ 3개 이상   │ 빈번 시 불리│
├──────────┼──────────┼───────────┼───────────┤
│ MongoDB  │   25%    │ 비정형 데이│ 트랜잭션   │
│          │          │ 터 비중 높 │ 필요 시 부담│
├──────────┼──────────┼───────────┼───────────┤
│ DynamoDB │   10%    │ AWS 락인  │ 멀티클라우드│
│          │          │ 감수 가능  │ 전환 시 비용│
└──────────┴──────────┴───────────┴───────────┘

차이 보이시죠?

하나를 추천하는 대신, 세 가지를 놓고 각각의 전제와 리스크까지 보여줍니다.

이걸 보면 “아, Postgres 65%인 이유는 조인 패턴이 3개 이상이라는 가정 때문이구나. 우리 프로젝트는 조인이 1개뿐이니까 MongoDB도 재고해봐야겠다” — 이런 판단이 가능해져요.

예시 2: adversarial-review — 마이크로서비스 전환 계획

📋 원래 계획: 모놀리스 → 마이크로서비스 전환

🔴 adversarial-review 결과:

[공격 1] 팀 규모 부족
  현재 3인 팀으로 마이크로서비스 운영 가능?
  → 숨은 가정: 각 서비스별 온콜 담당자 확보
  → 현실: 3명이 8개 서비스 온콜 = 번아웃 확정

[공격 2] 네트워크 비용 과소평가
  서비스 간 gRPC 호출 비용 계산됐나?
  → 월 예상: $0 → 실제: 서비스당 월 $200~500
  → 8개 서비스 시 $1,600~4,000 추가

[공격 3] 배포 파이프라인 복잡도
  CI/CD 파이프라인 8개 관리할 역량?
  → 현재 1개 파이프라인도 가끔 깨지는 상황

💡 대안 제안: 모듈러 모놀리스로 시작 → 추출 필요한 
   서비스만 점진적 분리

이거 처음 봤을 때 소름 돋았어요.

“마이크로서비스 전환하자”고 하면 보통 AI가 “좋습니다! 이렇게 하세요!” 하잖아요.

근데 adversarial-review는 일부러 반대편에 서서 공격합니다. “정말 이게 맞아?” 라고.

진짜 좋은 컨설턴트가 이래요. YES맨이 아니라, 불편한 질문을 던지는 사람.


확률·가정·반론을 프롬프트에 넣는 실전 방법

“Stack Skills 설치 안 해도 비슷하게 할 수 있나요?”

네, 핵심 원리만 알면 지금 당장 적용 가능합니다.

방법 1: 4칸 템플릿

아무 결정을 내리기 전에 이 4칸을 채워달라고 요청하세요.

지금 [결정 사항]에 대해 아래 4칸 형식으로 분석해줘:

1. 옵션: 최소 3가지 대안
2. 확률: 각 옵션별 적합도 %
3. 숨은 가정: 각 옵션이 성립하려면 참이어야 하는 전제
4. 반대 시나리오: 각 옵션이 실패하는 구체적 상황

이걸 CLAUDE.md나 프롬프트에 넣어두면, 모든 기술 결정에 자동으로 적용됩니다.

방법 2: 반론 먼저 규칙

# CLAUDE.md에 추가

## 사고 규칙
- 기술 결정 제안 시, 반드시 반론을 먼저 작성한 뒤 최종 추천한다.
- 최소 2개 대안을 비교표로 제시한다.
- 모든 추천에 "이 추천이 틀릴 수 있는 경우"를 명시한다.

저도 실제로 이걸 넣었는데요.

체감 효과가 확실합니다.

예전에는 Claude가 “Redis 쓰세요”라고 하면 “오케이” 하고 바로 구현했는데, 지금은 “Redis 추천 확률 70%, 숨은 가정: 데이터 만료 정책이 명확, 반대 시나리오: 영속성 필요 시 Redis는 부적합” 이런 식으로 나와요.

한 번 더 생각하게 되니까 삽질이 줄어요.

방법 3: Stack Skills 직접 설치

가장 간단한 방법은 직접 설치하는 겁니다.

# Claude Code에서 한 줄이면 끝
claude install stack-skills

이러면 7개 메타 인지 스킬이 한 번에 설치됩니다. Claude Code뿐 아니라 Codex 같은 다른 환경에서도 쓸 수 있다고 합니다.

💡 참고: Stack Skills는 특정 도구에 묶이는 게 아니라, 작업 방식 자체를 바꾸는 접근입니다. 그래서 다른 AI 코딩 도구에서도 핵심 원리를 그대로 적용할 수 있어요.


내 작업 루틴에 맞는 사고 보조 스킬 만드는 법

Stack Skills가 좋긴 한데, 모든 사람에게 딱 맞지는 않을 수 있어요.

자기 작업 패턴에 맞는 메타 인지 스킬을 직접 만드는 게 최고입니다.

Step 1: 지난 1주일 재작업 로그 분석

지난 1주일 동안 “이거 다시 해야 돼” 했던 순간을 적어보세요.

예시:
- 월: API 설계 → 3일 후 스키마 변경으로 재작업
- 화: 캐시 전략 선택 → 운영 후 메모리 부족으로 변경
- 수: 라이브러리 선택 → 2주 후 유지보수 안 되는 걸 발견

공통점이 보이죠? “결정 시점에 충분히 따지지 않아서” 재작업이 발생한 겁니다.

Step 2: 나만의 체크 스킬 설계

재작업 패턴을 분석했으면, 그걸 방지하는 스킬을 설계합니다.

# .claude/skills/my-decision-check/SKILL.md

## 스킬명: 기술 결정 체크
## 트리거: "이거 쓸까", "뭐가 좋을까", "어떤 방식이"

작동 규칙:
1. 결정 사항이 감지되면 자동으로 Decision Card 작성
2. Decision Card 구조:
   - 옵션 최소 3개
   - 각 옵션 적합도 (%)
   - 숨은 가정 (최소 2개씩)
   - 6개월 후 후회 시나리오
   - 되돌리기 비용 (시간·돈)
3. Decision Card 없이 구현으로 넘어가지 않는다

Step 3: 1주일 실험 → 결과 비교

실험 설계:
- 1주차: 기존 방식 (AI 추천 → 바로 구현)
- 2주차: Decision Card 의무화

측정 항목:
- 재작업 횟수
- 결정 후 변경까지 걸린 시간
- 총 작업 시간

저도 이거 해봤는데, 1주차에 재작업 4번이던 게 2주차에 1번으로 줄었어요.

Decision Card 쓰느라 10분씩 더 들지만, 재작업 한 번에 2~3시간이니까 압도적으로 남는 장사입니다.


정리: 체크리스트

□ AI한테 "추천해줘"가 아니라 "비교해줘"로 물어보고 있나?
□ 기술 결정에 숨은 가정을 확인하고 있나?
□ 최소 2개 대안을 보고 결정하고 있나?
□ 반대 시나리오를 미리 점검하고 있나?
□ 재작업 패턴을 로그로 추적하고 있나?
□ CLAUDE.md에 사고 규칙을 넣어뒀나?

솔직히 이거 전부 하고 있는 사람은 거의 없을 겁니다.

근데 하나만 시작해보세요. 4칸 템플릿이요.

다음 기술 결정할 때 “옵션·확률·가정·반대 시나리오” 4칸 채워달라고만 해보세요.

“아, AI가 이렇게도 생각할 수 있었구나” 느끼실 겁니다.


FAQ

Q1. Stack Skills는 무료인가요?

공개 미리보기 기준으로 무료 설치 가능합니다. 오픈소스 기반이라 커스터마이징도 자유로워요.

Q2. Claude Code에서만 쓸 수 있나요?

아닙니다. Codex 같은 다른 AI 코딩 환경에서도 사용 가능하다고 공식 언급되어 있어요. 핵심 원리(반론·확률·가정)는 어떤 AI 도구에서든 프롬프트로 적용할 수 있습니다.

Q3. 메타 인지 스킬 쓰면 토큰이 더 많이 드나요?

네, 분석 과정이 추가되니까 토큰은 더 씁니다. 하지만 재작업이 줄어서 총 토큰 소모는 비슷하거나 오히려 적어질 수 있어요. Stack Skills 개발자도 이 부분을 1주일 정도 로그로 확인해보라고 권장합니다.

Q4. 모든 결정에 이 프로세스를 적용해야 하나요?

아닙니다. 되돌리기 비용이 큰 결정에만 적용하세요. 변수 이름 짓기 같은 건 그냥 빠르게 결정하는 게 낫습니다. 데이터베이스 선택, 아키텍처 패턴, 프레임워크 선택 같은 구조적 결정에 집중하세요.

Q5. 4칸 템플릿 외에 다른 방법은 없나요?

“반론 먼저” 규칙만 넣어도 효과 있어요. CLAUDE.md에 "모든 기술 추천에 반대 의견을 먼저 작성" 한 줄만 추가해도 답변 품질이 달라집니다.

Q6. 팀에서 이거 도입하려면 어떻게 하나요?

CLAUDE.md에 사고 규칙을 추가하고 Git으로 공유하세요. PR 리뷰 때 “Decision Card 있나?” 체크하는 것만으로도 팀 전체 결정 품질이 올라갑니다.


결론: 도구는 속도를 주고, 스킬은 방향을 준다

AI 코딩 도구는 이미 충분히 빨라졌습니다.

근데 빠르게 잘못된 방향으로 가는 건 느리게 맞는 방향으로 가는 것보다 나쁩니다.

핵심 3가지:

  1. 답 하나 대신 옵션 비교를 요구하라
  2. 숨은 가정과 반대 시나리오를 항상 확인하라
  3. 재작업 패턴을 추적해서 나만의 사고 스킬을 만들어라

AI를 비서에서 전략가로 바꾸는 건, 코드를 짜는 방식이 아니라 질문하는 방식을 바꾸는 겁니다.

오늘 당장 해보세요.
다음 기술 결정에 “옵션·확률·가정·반론” 4칸 채워달라고.

“아, 이래서 다르구나” 느끼실 거예요.


참고 자료

🏷️ 태그: #ClaudeCode #StackSkills #AI코딩 #메타인지 #프롬프트엔지니어링 #사고력 #개발생산성