メニュー
두 방향이 양립 불가능해 보일 때 대립 해소 다이어그램(Evaporating Cloud)으로 숨겨진 전제를 찾아 돌파구(Injection)를 도출한다. "A vs B", "이러지도 저러지도", "트레이드오프", "딜레마", "양립 불가", "/conflict", "$conflict" 등을 말할 때 사용. 옹호자 A/B 서브에이전트로 양쪽 전제를 각각 최대한 강하게 세운 뒤, 중재자가 깨지는 지점을 찾는다.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | conflict |
| description | 두 방향이 양립 불가능해 보일 때 대립 해소 다이어그램(Evaporating Cloud)으로 숨겨진 전제를 찾아 돌파구(Injection)를 도출한다. "A vs B", "이러지도 저러지도", "트레이드오프", "딜레마", "양립 불가", "/conflict", "$conflict" 등을 말할 때 사용. 옹호자 A/B 서브에이전트로 양쪽 전제를 각각 최대한 강하게 세운 뒤, 중재자가 깨지는 지점을 찾는다. |
이론적 기반: Eliyahu Goldratt, TOC Thinking Processes — Evaporating Cloud 양립 불가능해 보이는 두 방향 사이에서, "둘 중 하나를 포기"하는 대신 숨겨진 전제를 깨서 양립 가능하게 만든다.
대립은 보통 "A냐 B냐"로 보이지만, 실제로는 전제가 만든 착시인 경우가 많다. Cloud의 각 화살표에는 "왜 이게 필수인가?"라는 전제가 숨어 있고, 그 전제 하나만 깨지면 충돌이 증발(evaporate)한다.
[A: 공통 목표]
/ \
① ②
/ \
[B: 필요조건] [C: 필요조건]
\ /
③ ④
\ /
[D: 행동] ←⑤ 충돌→ [D': 행동]
화살표 ①~⑤ 각각에 전제가 있다. 전제를 깨면 화살표가 끊어지고, 충돌이 사라진다.
단일 AI가 전제를 세우고 동시에 깨려 하면, 자기 전제에 무의식적 편향이 생긴다. 이를 관점 분리로 해결한다.
| 역할 | 누가 | 하는 일 | 핵심 태도 |
|---|---|---|---|
| 중재자 | 메인 | Cloud 구성(Step 0 | 양쪽 논리를 존중하되 숨은 균열을 발견 |
| 옹호자 A | 서브에이전트 | D 입장의 주장 대리 — ①③⑤ 전제를 steel-manning | "이 전제가 왜 성립하는지" 최대한 강화 |
| 옹호자 B | 서브에이전트 | D' 입장의 주장 대리 — ②④⑤ 전제를 steel-manning | "이 전제가 왜 성립하는지" 최대한 강화 |
옹호자는 공격자가 아니라 주장 대리인이다. 자기 쪽 전제를 최대한 강하게 세우면, 중재자가 "이렇게 강한 근거에도 불구하고 깨지는 지점"을 찾을 수 있다. 양쪽 다 이기고 싶어하면 타협이 되지만, 양쪽 다 진지하게 세우면 진짜 균열이 드러난다.
진입하면 메인은 중재자 역할을 맡는다.
/conflict, $conflict 또는 "A vs B", "딜레마", "양립 불가" 같은 신호로 진입한다.대화 맥락에서 충돌 지점을 파악하여 바로 Step 1로 진입한다.
양쪽 모두 진짜 원하는 것을 찾는다. 충돌하는 두 방향이 공유하는 상위 목적이다.
"[A]를 달성하고 싶다."
양쪽이 동의하지 않는 목표는 공통 목표가 아니다. 충분히 올라가면 반드시 합류점이 있다.
공통 목표를 위해 각각 필요한 것을 명시한다.
"A를 위해 B가 필요하다." (한쪽의 가치/방향)
"A를 위해 C가 필요하다." (다른쪽의 가치/방향)
B와 C 자체는 충돌하지 않는다. 둘 다 A를 위해 필요한 것이다.
각 필요조건을 충족하기 위한 구체적 행동을 적고, 양립 불가능함을 확인한다.
"B를 충족하려면 D를 해야 한다."
"C를 충족하려면 D'를 해야 한다."
"D와 D'는 양립할 수 없다." ← 이것이 충돌
여기까지가 Cloud 다이어그램의 완성이다. 사용자에게 확인을 구하지 않고 바로 Step 4로 진행한다. Cloud + 전제 강화 + Injection까지 완료한 뒤 결과를 한 번에 보여주고 그때 피드백을 받는다.
Cloud 구성 후 즉시 옹호자 A/B를 서브에이전트로 병렬 디스패치한다.
너는 [D] 입장의 변호인이다. 이 Cloud에서 D가 필요한 이유를 최대한 강하게 세워라.
Cloud:
[A] → [B] → [D]
[A] → [C] → [D']
[D] ↔ 충돌 ↔ [D']
너의 담당 화살표:
- ① A→B: "A를 위해 B가 필수인 이유"
- ③ B→D: "B를 충족하려면 D밖에 없는 이유"
- ⑤ D↔D': "D와 D'가 양립 불가능한 이유" (D 관점에서)
각 화살표에 대해:
1. 전제를 나열하라 (여러 개 가능)
2. 각 전제가 성립하는 근거를 최대한 강화하라
3. "이 전제가 깨지려면 뭐가 바뀌어야 하는가?"를 솔직하게 적어라
공격하지 마라. 상대(D')를 깎아내리지 마라. 네 쪽을 최대한 강하게 세워라.
너는 [D'] 입장의 변호인이다. 이 Cloud에서 D'가 필요한 이유를 최대한 강하게 세워라.
Cloud:
[A] → [B] → [D]
[A] → [C] → [D']
[D] ↔ 충돌 ↔ [D']
너의 담당 화살표:
- ② A→C: "A를 위해 C가 필수인 이유"
- ④ C→D': "C를 충족하려면 D'밖에 없는 이유"
- ⑤ D↔D': "D와 D'가 양립 불가능한 이유" (D' 관점에서)
각 화살표에 대해:
1. 전제를 나열하라 (여러 개 가능)
2. 각 전제가 성립하는 근거를 최대한 강화하라
3. "이 전제가 깨지려면 뭐가 바뀌어야 하는가?"를 솔직하게 적어라
공격하지 마라. 상대(D)를 깎아내리지 마라. 네 쪽을 최대한 강하게 세워라.
양쪽 결과를 수집하여 통합 전제 테이블을 구성한다:
| 화살표 | 옹호자 | 전제 | 근거 강도 | 깨지려면 |
|---|---|---|---|---|
| ① A→B | A | ... | ... | ... |
| ② A→C | B | ... | ... | ... |
| ③ B→D | A | ... | ... | ... |
| ④ C→D' | B | ... | ... | ... |
| ⑤ D↔D' | A | ... | ... | ... |
| ⑤ D↔D' | B | ... | ... | ... |
메인이 통합 전제 테이블을 검토한다. 양쪽이 강화한 전제 중 **"그럼에도 깨질 수 있는 것"**을 찾는다.
전제 [X]-[N]: "[전제 내용]"
→ 옹호자 [A/B]의 근거: [강화된 근거]
→ 그럼에도 깨지는 이유: [중재자 판단]
→ Injection: [구체적 대안]
돌파구가 나오면 3가지를 확인한다:
3가지 모두 통과하면 돌파구가 확정된다. 하나라도 실패하면 다음 전제로 이동.
결과를 대화에서 직접 제시한다. 깨진 전제와 Injection은 다음 판단이나 실행 계획의 입력으로 남긴다.
## 대립 해소 다이어그램: [제목]
### Cloud
[다이어그램]
### 전제 강화 (옹호자 A/B)
[통합 전제 테이블]
### Injection (돌파구)
- 깨진 전제: [어떤 전제가 거짓이었는가]
- 옹호자의 근거: [강화된 근거에도 불구하고 왜 깨지는가]
- 돌파구: [구체적 대안]
- 검증: B 충족 ✅ / C 충족 ✅ / 부작용 없음 ✅
Refactor frontend source trees so layer/slice/segment(role) hierarchy stays clear. Treat FSD names such as shared/entities/features/widgets/app as examples, not as the required target. Use when the user asks to reorganize src, separate app-owned code from reusable packages, remove layer smells, or clarify 책임 경계.
요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.
Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.
Use when refactoring frontend entity folders, FSD feature/entity boundaries, exported type names, prefix alignment, or cohesive entity/viewModel/value-object props so files and UI interfaces are grouped by real domain or UI concepts instead of role labels, generic names, or shredded field props. Trigger on requests such as entities 응집도, 접두어 정렬, 인터페이스 중심 폴더링, FSD 위치 점검, feature/entity 경계 리팩토링, props drill, entity shredding, viewModel props, 엔티티를 그대로 넘기기.
파일이나 기능의 개방-폐쇄 원칙(OCP)을 점검하고 리팩토링한다. "OCP", "/ocp", "개방 폐쇄", "switch 너무 많다", "if 분기 정리", "분기 흩어짐", "선언적 맵", "registry", "descriptor", "새 타입/variant 추가마다 여러 곳 수정" 같은 요청에서 사용한다. 열린 집합의 분기가 여러 소비자에 산재해 동반 변경 지점이 2곳 이상인지 분석하고, 확장 시 기존 코드 수정 지점을 0~1곳으로 줄이는 구조를 설계·전환한다.
사용자 발화를 액면 그대로 수행하지 않고 숨은 조사 의도, 배경, 목표를 먼저 추론한 뒤 비교 대상의 범주와 피어셋을 잠그고, 내부 맥락을 감사하고 standard, best practice, de facto, frontier trend를 비교해 읽히는 reference narrative를 만든다. "reference", "레퍼런스", "BP 찾아줘", "best practice", "사실상 표준", "de facto", "요즘 트렌드", "최근 시도", "업계는 어떻게 해", "표준 뭐야", "research", "리서치", "/reference", "/research"처럼 외부 수렴 흐름을 알고 싶을 때 사용한다. 단순 링크 목록이나 표 보고서가 아니라, 소스를 대신 읽고 같은 범주의 BP/de facto와 얼마나 가까운지, 결이 얼마나 비슷한지, 차이가 있다면 더 가까운 유사 레퍼런스는 무엇인지 문단 중심으로 설명하고 필요한 근거 표는 appendix로 내린다.