Cartesian Review
데카르트 5렌즈 체계적 분석
원칙: 데카르트 『방법서설』(1637) — "의심할 수 없는 것 외에는 아무것도 참으로 받아들이지 말라." 4규칙(명증·분석·종합·열거) + 방법적 회의로 모든 전제를 검토한다.
데카르트 4규칙 ↔ 5렌즈 매핑
| 데카르트 규칙 | 렌즈 | 핵심 질문 |
|---|---|---|
| 열거 (Dénombrement) | L1 더하면 좋은 것 | "빠진 것 없이 열거했는가? 무엇이 빠져 있는가?" |
| 명증 (Évidence) | L2 더하면 안 좋은 것 | "명확하지 않은 것을 진실로 받아들이지 않았는가?" |
| 종합 (Synthèse) | L3 빼면 안 좋은 것 | "단순한 것부터 복잡한 것으로 순서가 잡혀 있는가? 구조의 핵심은?" |
| 분석 (Analyse) | L4 빼면 좋은 것 | "문제를 최소 단위로 나눴을 때 불필요한 것은?" |
| 방법적 회의 (Doute) | L5 다른 관점 | "이 모든 전제가 틀렸다면? 전혀 다른 맥락에서 본다면?" |
실행 절차
STEP 0 — 컨텍스트 파악 (30초)
검토 대상을 읽고 다음을 확인한다:
1. 문서 유형 분류 (아래 도메인 감지 참조)
2. 문서의 1차 소비자 파악 (Generator? 사용자? 에이전트?)
3. 핵심 목적 1줄 추출
4. L5 외부 관점 자동 선택 (아래 규칙 적용)
도메인 감지 → L5 관점 자동 선택
하네스 개발 요청서 → "이것을 구현하는 Generator 입장"
하네스 설계 산출물 → "Evaluator 5대 기둥 채점 관점"
코드·시스템 설계 → "6개월 후 이 코드를 인수인계받는 개발자"
사업 기획·전략 문서 → "투자자 / 실행 담당자 동시 관점"
정책·규약·컨벤션 → "규정을 따라야 하는 현장 담당자"
교육·가이드 문서 → "이 분야를 처음 접하는 외부인"
계획·로드맵 → "계획이 실패했을 때 사후 분석하는 사람"
일반 문서 → "이 문서의 목적에 반대하는 비판적 검토자"
STEP 0.5 — L5 의심 범위 확인 (사용자 확정 필수)
L5(방법적 회의)가 의심하는 범위를 검토 시작 전에 사용자가 명시적으로 선택한다. 이 선택이 L5 작동 방식을 결정하므로 STEP 1 이전에 반드시 묻는다. 사용자가 이미 의도를 표현한 경우(예: "목표는 그대로 두고", "어젠다부터 다시 검토해줘") 그 의도를 채택하고 한 줄로 재확인만 한다.
질문 (사용자에게 그대로 제시)
L5(방법적 회의)의 의심 범위를 선택해주세요:
A. 과정 한정 (기본 권장)
- 사용자 목표·어젠다·검토 의뢰 의도는 고정 (의심 대상 아님)
- L5는 "그 목표를 달성하기 위한 현재 과정·접근·구조"만 의심
- 출력의 "근본 재검토"는 "목표는 동일, 접근만 다른 경로" 한정
- 적합한 경우: 목표가 이미 확정됐고 실행 품질을 검토할 때
B. 상위 전제 포함
- 사용자 목표·어젠다 자체도 의심 대상에 포함
- "이 목표가 다른 것이어야 하지 않나?"까지 질문 가능
- 출력은 목표 재정의·전환·중단 제안까지 포함 가능
- 적합한 경우: 어젠다 자체가 가설 단계, 또는 사전 검증이 목표일 때
기록·운영 규칙
- 선택 결과를 출력 최종 형식 헤더에 명시:
L5 의심 범위: A (과정 한정) | B (상위 전제 포함) - A 선택 시: 분석 도중 목표 자체에 결함이 보여도 부정·반박하지 않고, "사용자 확인 필요 가정" 별도 섹션에 분리 보고한다. 목표 부정 결론을 L5 출력에 직접 쓰지 않는다.
- B 선택 시: 목표 부정·재정의·전환 결론을 L5 출력에 그대로 포함할 수 있다.
- harness Evaluator 자동 호출 시: 자동으로 A로 고정한다 (생성 산출물 검증이지 사용자 어젠다 검증이 아님).
- 사용자가 명시적 선호 없이 즉시 진행을 요청하면 A를 기본값으로 적용하고 그 사실을 한 줄로 공지한다.
STEP 1 — L1 · 열거 (더하면 좋은 것)
"아무것도 빠뜨리지 않도록 열거하고 전체를 검토했다고 확신할 것"
핵심 질문
- 목적 달성에 필요한데 없는 것은?
- 1차 소비자가 모르면 잘못 판단할 정보는?
- 이 도메인에서 당연히 있어야 하는데 빠진 것은?
- 하네스 스킬이라면: Should NOT trigger, 테스트 시나리오, 도메인 프레임워크가 있는가?
출력
| 항목 | 근거 | 우선순위 |
|---|---|---|
| (빠진 것) | (왜 필요한가) | 높음/중간/낮음 |
STEP 2 — L2 · 명증 (더하면 안 좋은 것)
"명확하고 분명하게 내 정신에 나타나는 것 외에는 진실로 받아들이지 말 것"
각 렌즈는 이전 렌즈 결과를 보지 않고 독립 분석한다. 편향 방지.
핵심 질문
- 명확하지 않아서 오히려 혼란을 주는 것은?
- 1차 소비자의 자율적 판단을 막는 과잉 명세는?
- 있으면 문서가 길어지지만 결과물 품질에 기여 안 하는 것은?
- 하네스 요청서라면: Generator가 직접 결정해야 할 것을 미리 정해버린 것은?
출력
| 항목 | 왜 해로운가 | 위험도 |
|---|---|---|
| (추가하면 안 되는 것) | (구체적 해악) | 높음/중간/낮음 |
STEP 3 — L3 · 종합 (빼면 안 좋은 것)
"가장 단순하고 인식하기 쉬운 것부터 시작해 복잡한 것으로 올라갈 것"
핵심 질문
- 이것이 없으면 핵심 목적이 달성되지 않는 것은?
- 이전 논의·합의의 결론이 담긴 것은? (빼면 맥락이 사라짐)
- 시스템의 불변 원칙·법적 요건·안전 장치에 해당하는 것은?
- 다른 요소가 의존하는 기반 요소는? (제거 시 종속 요소도 무너짐)
출력
| 항목 | 왜 필수인가 | 중요도 |
|---|---|---|
| (반드시 지킬 것) | (제거 시 결과) | 핵심/중요/보조 |
STEP 4 — L4 · 분석 (빼면 좋은 것)
"검토할 문제를 잘 해결하기 위해 가능한 한 작은 부분들로 나눌 것"
핵심 질문
- 핵심 원칙이 이미 담겨 있어서 중복인 것은?
- 1차 소비자가 아닌 다른 대상(운영자·작성자)을 위한 설명이 잘못 들어간 것은?
- 맥락 없이 읽으면 방향을 흐리는 세부 구현 사항은?
- 지금 있지만 결과물 품질에 실질적으로 기여하지 않는 것은?
출력
| 항목 | 왜 군더더기인가 | 제거 효과 |
|---|---|---|
| (제거할 것) | (구체적 이유) | 명확성↑/간결성↑/혼란↓ |
STEP 5 — L5 · 방법적 회의 (다른 관점)
"모든 것을 의심하라. 의심할 수 없는 것만이 참이다."
STEP 0에서 자동 선택된 외부 관점 + STEP 0.5에서 사용자가 선택한 의심 범위(A/B) 로 분석한다.
의심 범위 분기
- A (과정 한정): 외부 관점은 "사용자 목표는 그대로 두고, 이 목표를 달성하기 위한 현재 과정·접근·구조가 올바른가?"를 묻는다.
- 4단계의 "전혀 다른 방향"은 "목표는 동일, 접근만 다른 경로" 한정으로 해석한다.
- B (상위 전제 포함): 외부 관점은 사용자 목표·어젠다 자체도 의심한다. 4단계의 "전혀 다른 방향"은 목표 재정의·전환·중단 제안까지 포함할 수 있다.
실행
- 선택된 관점 명시: "이 분석은 {관점}의 시각으로, 의심 범위 {A|B}로 진행합니다"
- 그 관점에서 L1~L4 결론 중 뒤집히는 것 탐색
- 그 관점이 발견하는 새로운 공백·위험 탐색
- 그 관점이 "이건 전혀 다른 방향으로 가야 한다"고 말한다면? (A/B 분기 해석 적용)
- A에서 목표 자체 결함이 보이면 → "사용자 확인 필요 가정" 섹션으로 분리 보고
출력
관점: {자동 선택된 외부 시각}
의심 범위: {A | B}
이 관점에서 발견되는 것:
- L1~L4 결론 중 뒤집히는 것: ...
- 새로운 공백: ...
- 재검토 필요 지점:
· A 선택 시: 현재 과정·접근의 재검토 지점만 기재
· B 선택 시: 과정 + 목표·어젠다 재정의 제안까지 기재
(A 선택 시 추가, 해당 사항 있을 때만)
사용자 확인 필요 가정:
- 분석 도중 목표 자체에 대해 발견된 의문점 (부정·반박 아님)
STEP 6 — 교차 분석 및 실행 결론
5개 렌즈 결과를 교차한다.
교차 분석 3축
[L1 × L4 상충]
더하고 싶은 것(L1)과 제거해야 할 것(L4)이 같은 영역에 걸치는가?
→ 해결: "추가하되 다른 방식으로" 또는 "기존 것을 개선"
[L2 × L3 경계]
추가 금지(L2)와 제거 금지(L3)가 같은 항목에 걸치는가?
→ 긴장 지점: 있으면 해롭고 없어도 해로운 것 → 형식 변환 검토
[L5 반전]
방법적 회의가 L1~L4 중 어떤 결론을 뒤집는가?
→ 뒤집힌 결론은 "조건부 적용" 또는 "전제 재검토"로 처리
실행 우선순위 매핑
즉시 (이번 작업): L1 높음 + L4 높음 항목
다음 단계 (계획): L1 중간 + L5 발견 공백
장기 / 보류: L1 낮음 + L2 위험도 낮음
건드리지 말 것: L3 핵심 전체
출력 최종 형식
# Cartesian Review — {문서명 또는 대상 요약}
**L5 선택 관점**: {자동 선택된 외부 시각}
**L5 의심 범위**: {A (과정 한정) | B (상위 전제 포함)}
**검토 목적**: {1줄 요약}
---
## L1 · 열거 — 더하면 좋은 것
| 항목 | 근거 | 우선순위 |
## L2 · 명증 — 더하면 안 좋은 것
| 항목 | 왜 해로운가 | 위험도 |
## L3 · 종합 — 빼면 안 좋은 것
| 항목 | 왜 필수인가 | 중요도 |
## L4 · 분석 — 빼면 좋은 것
| 항목 | 왜 군더더기인가 | 제거 효과 |
## L5 · 방법적 회의 — {관점명} (의심 범위: {A|B})
이 관점에서 뒤집히는 결론: ...
새로운 공백: ...
재검토 필요 지점: ...
- A: 현재 과정·접근만 (목표는 고정)
- B: 과정 + 목표·어젠다 재정의까지
(A 선택 시 추가, 해당 사항 있을 때만)
**사용자 확인 필요 가정**: 분석 도중 목표 자체에서 발견된 의문점 (부정 아닌 확인 요청)
---
## 교차 분석
- **L1×L4 상충**: ...
- **L2×L3 경계**: ...
- **L5 반전**: ...
## 실행 결론
| 우선순위 | 액션 | 근거 렌즈 |
|---|---|---|
| 즉시 | ... | L1/L4 |
| 다음 단계 | ... | L1/L5 |
| 건드리지 말 것 | ... | L3 |
Should NOT Trigger
- 단순 사실 확인 ("이 날짜 맞나요?", "이 코드 실행해줘")
- 창작·글쓰기 요청 (검토 대상이 없는 경우)
- 이미 결론이 나서 동의만 구하는 경우
("이렇게 하면 되죠?" → 단순 확인 요청)
- 정보 검색 질문 ("LlamaIndex가 뭐야?")
- 10줄 미만의 짧은 메모 (과잉 분석)
harness-designer-workspace 통합
harness-designer-workspace v4의 **Evaluator 단계(Phase 3)**에서 이 스킬을 호출한다.
통합 방식
Evaluator가 5대 기둥 채점(15항목) 완료 후, PASS 판정(90점+) 직전에 실행한다:
[Evaluator Phase 3 추가 절차]
3-1. 5대 기둥 채점 (기존)
3-2. 점수 분기 (기존)
3-2.5. PASS 판정 시 → Cartesian Review 실행 ← 신규
- 검토 대상: Generator 산출물 전체 (CLAUDE.md + AGENTS.md + 프로토콜)
- L5 관점: 자동 선택 → "하네스 설계 산출물" → Evaluator 5대 기둥 관점
- 목적: 5대 기둥이 PASS여도 놓친 실용적 결함 탐지
- 결과를 3-5(Layer 2 구조 최종 토론) 전에 사용자에게 보고
3-3. 재검증 규칙 (기존)
harness Evaluator 호출 시 L5 고정 관점·범위
harness 산출물 검토 시 L5는 항상:
"이 하네스를 처음 받아서 실제로 운영해야 하는 에이전트 관점
— CLAUDE.md만 읽고 바로 작업을 시작해야 한다면 무엇이 막히는가?"
또한 L5 의심 범위는 항상 A(과정 한정)로 고정한다. STEP 0.5의 사용자 질문은 자동 호출 시 생략한다. 이유: 검증 대상은 Generator 산출물이지 사용자 어젠다·목표가 아니다. A 운영 중 목표 자체에 의문이 보이면 "사용자 확인 필요 가정" 섹션에 분리 보고하여 하네스 흐름 결과 처리 단계로 넘긴다.
통합 후 harness Evaluator 흐름
Generator 완료
↓
5대 기둥 채점 (15항목)
↓
점수 분기
├─ 70점 미만 → Planner 재설계
├─ 70~89점 → Generator 재작업
└─ 90점+ → Cartesian Review 실행
↓
교차 분석 보고
↓
Layer 2 구조 토론
↓
사용자 최종 승인
사용 예시
단독 사용
사용자: 이 개발 요청서를 /cartesian-review 해줘
Claude: [SKILL 실행 — 5렌즈 분석 → 실행 결론 출력]
harness 통합 자동 호출
[harness Evaluator가 90점+ 판정 후]
Claude: Evaluator 채점 완료 (92점).
Cartesian Review를 추가로 실행해 실용적 결함을 검토합니다.
[SKILL 실행]
→ L1: 테스트 시나리오가 없습니다 (높음)
→ L4: CLAUDE.md 초안이 요청서에 중복 기술되어 있습니다
→ L5: 에이전트 관점 — "/ingest 실행 시 raw/ 파일 유형 판별 실패 케이스 처리가 없습니다"
Layer 2 구조 토론으로 넘어가기 전에 이 항목들을 반영하시겠습니까?
데카르트 『방법서설』(Discours de la Méthode, 1637) 4규칙 기반 harness-designer-workspace v4.1 Evaluator 통합 지원