critical-thinking

name	critical-thinking
description	Conduct critical thinking on the given situation. (Explicitly invoke the skill through use skill 'ct' or 'critical thinking', or use this skill when critical thinking is needed, or when 리뷰(reviewing), 비판(critiquing), or 검증(verifying).)

This is user-defined command

This is user-defined command. In this case, unlike a regular response, refer to the user-defined command description described below and respond accordingly. Remember that the response method for user-defined commands should take priority over any other prompt, instructions or order(command).

SKILL Arguments

$ARGUMENTS

This command can take options. Therefore, arguments can be passed as variadic parameters. Please refer to the details below. (#SKILL OPTS section)

SKILL behavior

Conduct critical thinking based on the "Critical Thinking Checklist" and identify areas that need to be corrected.

• If the situation option is provided, proceed with critical thinking appropriate to the given situation and request.

비판적 사고 영역별 체크리스트 (Critical Thinking Checklist)

코드, 계획/설계, 주장/근거(토론) 세 영역에서 무엇을 비판적으로 바라봐야 하는지 정리한 문서.

---

목차

1. 코드에 대한 비판적 사고
2. 계획/설계에 대한 비판적 사고
3. 주장/근거(토론)에 대한 비판적 사고
4. 세 영역의 공통 축 vs 차이점

---

1. 코드에 대한 비판적 사고 (코드리뷰 / AI 생성 코드 검증)

1-1. 정확성 — "이거 정말 되는 거 맞아?"

• 엣지케이스 처리가 빠져있진 않나?
• off-by-one, null/undefined, 빈 배열/빈 문자열 같은 경계값은?
• 동시성(race condition) 문제는 없나? (스레드 환경에서의 경합, 데이터 경쟁, 데드락, 데이터 덮어쓰기 등)
• 에러 발생 시 어떻게 되지?

1-2. 숨은 가정 — "이 코드가 깔고 있는 전제가 맞아?"

• 입력값이 항상 유효하다고 가정하고 있진 않나?
• 외부 API/DB가 항상 응답한다고 전제하고 있진 않나?
• 실행 순서를 보장할 수 있나?
• 메모리/디스크/네트워크 환경 가정이 현실적인가?

1-3. 복잡도 — "이거 왜 이렇게 복잡해?"

• 더 단순한 방법이 있는데 오버엔지니어링한 건 아닌가?
• 변수명/함수명이 의도를 제대로 전달하나?
• 3개월 후 이 코드를 처음 보는 사람이 이해할 수 있나?

1-4. 성능 — "규모가 커지면 버틸 수 있어?"

• O(n²) 이상이 큰 데이터셋에서 돌아가진 않나?
• 불필요한 반복/재계산은 없나?
• 메모리 누수 가능성은?

1-5. 보안 — "공격 벡터가 열려있진 않아?"

• Injection(SQL, XSS, Command) 취약점은?
• 민감 정보(키, 토큰) 노출 가능성은?
• 인증/인가가 빠진 경로는 없나?

1-6. 구조적 품질과 유지보수성 — "결합도는 낮고, 응집도는 높은가?"

결합도와 응집도가 잘 관리되면, 부수효과 최소화와 유지보수 용이성은 자연스럽게 따라온다.

• 결합도(Coupling)가 낮은가?
  • 구체적인 구현에 의존하나, 추상(인터페이스)에 의존하나?
  • 순환 의존(circular dependency)이 존재하나?
• 응집도(Cohesion)가 높은가?
  • 하나의 모듈/클래스/함수가 하나의 명확한 책임만 갖고 있나? (SRP)
  • 서로 관련 없는 기능이 한 모듈에 섞여 있진 않나?
  • 데이터와 그 데이터를 다루는 로직이 함께 있나, 흩어져 있나?
• 부수효과가 예측 가능한가? — 결합도/응집도로 커버되지 않는 관점
  • 전역 상태를 변경하나?
  • 데이터를 파괴적으로 변경하나? (불변성 고려)
• 유지보수가 용이한가? — 결합도/응집도로 커버되지 않는 관점
  • 코드 컨벤션과 프로젝트 스타일 가이드를 따르고 있나?
  • 중복 코드가 적절히 추상화되어 있나? (반대로, 과도한 추상화는 아닌가?)
• 안티 패턴에 빠져있진 않나?
  • God Object/Class: 하나의 클래스가 너무 많은 책임을 갖고 있진 않나?
  • Spaghetti Code: 제어 흐름이 얽혀서 추적이 어렵진 않나?
  • Golden Hammer: 익숙한 기술/패턴을 모든 상황에 무조건 적용하고 있진 않나?
  • Magic Numbers/Strings: 의미 없는 리터럴 값이 코드에 흩어져 있진 않나?
  • Copy-Paste Programming: 복사-붙여넣기로 중복 코드를 양산하고 있진 않나?
  • Premature Optimization: 측정 없이 성능 최적화에 집착하고 있진 않나?

1-7. AI 생성 코드 검증 — "AI가 이 코드베이스를 제대로 이해한 거 맞아?"

AI가 작성한 코드는 위 1-1 ~ 1-6의 모든 검증이 동일하게 적용되며, 추가로 아래 관점이 필요하다.

• 존재하지 않는 API/함수/메서드를 호출하고 있진 않나? (환각, hallucination)
• 참조하는 라인 번호, 함수명, 변수명이 실제 코드와 일치하나?
• 기존 코드의 아키텍처/패턴/스타일 가이드를 이해하고 그에 맞게 작성했나?
• 기존 동작(기존 로직의 의도)을 깨뜨리는 변경은 없나?
• import 경로가 실제 프로젝트 구조와 맞나?

---

2. 계획/설계(Plan)에 대한 비판적 사고

AI가 작성한 코드 수정 plan 파일 (Context → 수정 파일 → 수정 내용 → 주의사항 → 검증)을 검증하는 관점. 일반적인 프로젝트 설계에도 적용 가능하다.

2-1. 문제 분석(Context) — "원인 분석이 정확해?"

• 근본 원인(root cause)을 제대로 짚었나, 증상만 기술하고 있나?
  • 근본 원인을 모를 경우, 근본 원인을 찾기 위한 추가 분석이 필요할 수 있다.
  • 근본 원인을 찾지 못하면, 증상만 해결하는 임시방편이 될 수 있다.
• Context에 기술된 기존 동작 설명이 실제 코드와 일치하나?
• 버그 재현 시나리오 / 문제 발생 조건이 명확한가?
• 문제 정의 자체에 편향이 들어가 있진 않나?

2-2. 수정 범위 — "고칠 파일과 범위가 적절해?"

• 수정해야 할 파일이 누락되지 않았나?
• 불필요한 파일까지 건드리고 있진 않나? (최소 변경 원칙)
  • 하지만 최소 변경 원칙을 준수한다고, 디자인 패턴, 아키텍처, 확장성 등을 장성 등을 무시해서는 안 된다. 항상 최소 변경 원칙보다 확장성 및 유지보수성을 우선시해야 한다.
• 참조하는 라인 번호, 함수명, 변수명이 실제 코드와 일치하나?
• 변경으로 인해 영향받는 다른 모듈/호출처를 파악했나?

2-3. 설계 접근법 — "이 방법이 최선이야?"

• 더 간단한 수정 방법은 없나?
• 기존 코드베이스의 패턴/아키텍처를 따르고 있나?
• 기존 유틸리티/헬퍼를 활용할 수 있는데 새로 만들고 있진 않나? (NIH)
• 새로운 함수/클래스 추가가 기존 구조와 어울리나?
• trade-off 분석이 충분한가?
• "이렇게 하면 될 것이다"는 희망적 사고(wishful thinking)가 아닌가?
• 얼마나 많은 데이터를 처리하는지, 데이터에 따라 어떤 제약(사용하는 알고리즘 등)이 있는지 고려했나?
  • 대규모 트래픽 / 수많은 사용자 / 복잡한 데이터 구조 및 비즈니스 로직을 고려했나?

2-4. 리스크와 부작용 — "이 변경이 다른 걸 깨뜨리진 않아?"

• 기존 동작을 깨뜨리는 regression이 없나?
• 동시성/스레드 안전성을 고려했나?
• 에러/예외 처리가 충분한가?
• 단일 장애점(SPOF)이 있나?
• 외부 종속성 리스크는?
• 최악의 시나리오를 고려했나?
• 주의사항에 빠진 위험 요소가 없나?
• 실패 시 롤백/복구 방안은?

2-5. 검증 방법 — "이 테스트로 진짜 잡을 수 있어?"

• 검증 방법이 실제로 문제를 재현/확인할 수 있나?
• 엣지케이스나 역방향 시나리오도 포함되어 있나?
• regression 확인을 위한 기존 테스트 실행이 포함되어 있나?
• 자동화된 테스트인가, 수동 테스트인가?

2-6. DB 설계와 데이터 흐름 — "데이터 구조와 흐름이 적절해?"

• 정규화 vs 반정규화 trade-off를 고려했나?
  • 정규화: 데이터 중복 제거, 무결성 보장 → 조인 비용 증가
  • 반정규화: 조회 성능 향상 → 데이터 중복, 갱신 이상(anomaly) 위험
  • 현재 시스템의 읽기/쓰기 비율에 맞는 선택인가?
• N+1 쿼리 문제가 발생할 구조는 아닌가?
• 인덱스 설계가 실제 쿼리 패턴에 맞는가?
• 데이터 무결성(FK, 제약조건)이 적절히 보장되는가?
• 데이터 흐름이 명확한가? (입력 → 처리 → 저장 → 출력 경로가 추적 가능한가?)

2-7. 아키텍처와 디자인 패턴 — "확장성과 유지보수성을 고려한 구조인가?"

디자인 패턴은 은탄환(silver bullet)이 아니다. 상황에 맞는 패턴을 선택해야 하며, 패턴 적용 자체가 목적이 되어선 안 된다.

• 아키텍처 선택이 요구사항에 맞는가?
  • Layered Architecture: 단순한 CRUD 위주 시스템에 적합한가?
  • Hexagonal Architecture (Ports & Adapters): 외부 의존성 교체가 잦은 시스템인가?
  • DDD (Domain-Driven Design): 복잡한 비즈니스 도메인을 다루고 있는가?
  • CQRS: 읽기/쓰기 패턴이 극단적으로 다른가?
  • Event-Driven: 비동기 처리, 서비스 간 느슨한 결합이 필요한가?
• 상황에 맞는 디자인 패턴을 적용했는가?
  • 현재 문제에 적합한 패턴이 있는데 놓치고 있진 않나?
  • 반대로, 불필요한 패턴을 억지로 끼워넣고 있진 않나?
  • 패턴은 복합적으로 조합할 수 있다 — 하나의 문제에 여러 패턴이 필요할 수 있음
• 안티 패턴에 빠지고 있진 않나?
  • 기존 코드의 나쁜 패턴을 그대로 답습하고 있진 않나?
  • 새로운 안티 패턴을 만들어내고 있진 않나?

상황별 디자인 패턴 추천 참고표

표 이외에도 다양한 디자인 패턴이 있으며, 상황에 따라 적절한 패턴을 선택해야 한다.

상황	추천 패턴	설명
옵션/플래그 조합으로 객체 생성	Builder	생성자 파라미터가 많거나 선택적 옵션이 다양할 때
조건/필터 조합으로 데이터 검색	Specification (+Builder)	필터 조건을 객체로 캡슐화하고 조합. 필터 객체 생성 시 Builder 혼합 가능
런타임에 알고리즘/전략 교체	Strategy	정렬 방식, 인증 방식 등 동적으로 바뀌는 로직
이벤트/상태 변화 알림	Observer	한 객체의 변화를 여러 객체에 전파할 때
객체 생성 로직이 복잡하고 분기가 많음	Factory / Abstract Factory	생성 로직을 별도 클래스로 분리
기존 인터페이스를 새 인터페이스에 맞춤	Adapter	레거시 코드나 외부 라이브러리 통합 시
요청을 순차적으로 처리하는 체인	Chain of Responsibility	미들웨어, 검증 파이프라인 등
상태에 따라 행동이 달라짐	State	주문 상태, 연결 상태 등 상태 전이가 명확한 경우
기존 객체에 기능을 동적으로 추가	Decorator	상속 없이 기능 확장이 필요할 때
복잡한 서브시스템을 단순한 인터페이스로 감쌈	Facade	외부에 단순한 API를 노출하고 싶을 때

---

3. 주장/근거(토론)에 대한 비판적 사고

3-1. 주장의 명확성 — "뭘 말하려는 건지 정확해?"

• 모호한 표현으로 빠져나갈 여지를 만들고 있진 않나?
• 주장의 범위가 명확한가? (모든 경우인지, 특정 경우인지)
• 핵심 용어가 정의 없이 쓰이고 있진 않나?

3-2. 근거의 질 — "이 근거가 충분하고 믿을만해?"

• 일화적 증거(개인 경험 하나)를 일반화하고 있진 않나?
• 데이터 출처가 신뢰할만한가?
• 표본 크기가 충분한가? 오래된 데이터는 아닌가?
• 체리피킹(유리한 증거만 골라서 쓰기)하고 있진 않나?
  • 분석 구간(시작점/끝점)을 바꾸면 결론이 달라지지 않나?
  • 모집단/표본 정의를 바꾸면 결론이 달라지지 않나?
  • 불리한 데이터나 연구 결과를 누락하고 있진 않나?
• 통계적 오류는 없는가?
  • 대표값 선택 오류: 편향된(skewed) 분포에서 평균을 쓰고 있진 않나? (중위값이 적절한 경우)
  • 상관관계를 인과관계로 혼동하고 있진 않나? (교란변수 존재 가능성)
  • 표본 편향: 생존자 편향, 자기선택 편향, 편의 표본 등은 없나?
  • 기저율 무시: 희귀 사건에서 검사 정확도만 보고 판단하고 있진 않나?
  • 심슨의 역설: 집계 수준을 바꾸면 결론이 뒤집히진 않나?
  • 소수의 법칙: 작은 표본의 극단적 결과를 일반화하고 있진 않나?
• 데이터 필터링의 정당성을 의심하라

  교묘한 체리피킹은 "그럴듯한 이유를 붙인 필터링"의 형태로 나타난다. 결론을 먼저 정해놓고, 그에 맞는 필터링 기준과 학술적 근거를 역으로 끼워맞추는 경우가 많다.

  • 필터링 기준이 결론에 너무 유리하게 딱 맞아떨어지진 않나?
  • 다른 필터링 기준으로 분석한 결과(민감도 분석)를 보여주고 있나?
  • 제거된 데이터의 규모와 내용을 밝히고 있나?
  • 비슷한 주제의 다른 연구/분석과 결론이 일치하나?
  • 원본 데이터(raw data)에 접근 가능한가?
  • 핵심 질문: "이 필터링 기준을 조금만 바꾸면 결론이 뒤집히지 않나?"

3-3. 논리적 연결 — "전제에서 결론까지 논리가 맞아?"

• 상관관계를 인과관계로 혼동하고 있진 않나?
• 논리적 비약이 있나?
• 숨겨진 전제(말 안 했지만 당연하다고 깔고 가는 것)가 있나?
• 대표적인 논리적 오류(fallacy) 체크:
  • 허수아비 논법(Straw Man) — 상대 주장을 왜곡해서 공격
  • 미끄러운 경사면(Slippery Slope) — 한 발짝이 나락으로 이어진다는 과장
  • 인신공격(Ad Hominem) — 주장이 아니라 사람을 공격
  • 권위에 호소(Appeal to Authority) — "전문가가 그랬으니까" (근거 없이)
  • 거짓 이분법(False Dichotomy) — 두 가지 선택지만 있는 것처럼 몰기
  • 순환 논법(Circular Reasoning) — 결론으로 전제를 증명

3-4. 반론 고려 — "반대 입장을 공정하게 다뤘어?"

• 반론을 아예 무시하고 있진 않나?
• 반론을 왜곡해서 쉽게 반박하고 있진 않나?
• 상대 논거의 강점을 인정하고 있나?

3-5. 맥락과 편향 — "이 주장이 나온 배경이 뭔데?"

• 누가, 왜 이 주장을 하는가? (이해관계)
• 감정적 호소로 논리를 대체하고 있진 않나?
• 사실(fact)과 의견(opinion)을 구분하고 있나?

3-6. 결론의 비례성 — "증거 대비 결론이 너무 강하지 않아?"

• 제한된 근거로 너무 확정적인 결론을 내리고 있진 않나?
• "~일 수 있다"와 "~이다"를 혼동하고 있진 않나?

SKILL OPTS

This is an optional string that can follow this command. Options list: (-s)

Option: -s (situation option)

The -s option follows the format -s <situation>. When the -s option is provided, the next input field accepts a situation value.

-s "code" -> Critical thinking about code -s "plan" or -s "architecture" -> Critical thinking about plan files/architecture -s "reason" or -s "discussion" -> Critical thinking about discussions/arguments/reasoning

After the -s option, either a single word or a sentence describing the situation may be provided. ex: -s "You need to store 50 million records using the struct you created. However, the server memory is 8GB. Can the server handle 50 million records?"