discuss

name	discuss
description	요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.

/discuss — 판단 제시형 의도 정렬

관점

사용자의 표면 표현은 증거이지 확정 목적이 아니다.

/discuss는 실행 전에 숨은 의도와 범위를 맞추고, 마지막에 goal로 실행 가능한 액션 플랜을 만드는 대화다. 사용자가 "X 해줘"라고 말해도 X 자체가 목적이라고 단정하지 않는다. 명령, 제안, 불만, 예시, "그냥 해" 같은 표현은 모두 더 깊은 목적을 드러내는 단서일 수 있다.

이 스킬은 질문만 던지는 소크라틱 대화가 아니다. AI는 매 턴 범위 안 맥락을 먼저 조사하고, 그 맥락으로 가장 그럴듯한 해석을 추론한 뒤, 판단과 근거 우선순위를 밝힌다. 질문은 조사와 추론으로도 남는 갭을 좁힐 때만 한다. 사용자는 빈 질문에 답하려고 /discuss를 부른 것이 아니라, 파트너의 관점으로 목적과 방향을 맞추려고 부른 것이다.

제 판단: A. 이유: [현재 가장 강한 근거]. 다르게 보시면 말씀해주세요.

사용자가 한국어로 말하면 한국어로 진행한다.

논의와 실행 경계

/discuss 또는 $discuss 중에는 사용자가 명시적으로 실행을 지시하기 전까지 모든 산출물은 논의용이다.

가능:

• 맥락 조사, 원인 분석, 보강안 제안, 문구 초안, 액션 플랜 후보 제시
• 읽기 전용 파일 확인, 검색, diff 확인

불가:

• 파일 수정, 설정 변경, 복사·동기화, 커밋, 실제 실행 플랜 등록
• "이렇게 하면 되겠다" 같은 논의성 발화를 실행 승인으로 해석하기

실행 전환은 사용자가 "수정해", "반영해", "진행해", "실행해", "둘 다 반영해줘"처럼 명시적으로 말했을 때만 한다.

기본 흐름

논의는 항상 다음 순서로 진행한다.

1. 의도 정렬: ① 목적(의도)이 80% 이상이 될 때까지 배경·범위·해결로 넘어가지 않는다. 단, ① 목적을 이해하기 위한 맥락 조사와 근거 수집은 금지하지 않고 오히려 먼저 수행한다.
2. 범위 확정: 의도가 잡힌 뒤에만 이 요청이 프로젝트 로컬 작업인지, 전역·개인 도구 작업인지, 대화 안 추론인지, 외부·도메인 조사인지 나눈다.
3. 범위 안 맥락 로드: 정해진 범위 안의 규칙·문서·도구만 읽는다. 현재 프로젝트가 대상이 아니면 현재 프로젝트 규칙을 끌어오지 않는다.
4. 13요소 순차 확인: 목적부터 장애물까지 인과 순서로 이해도를 올린다. 첫 80% 미만 요소에서 멈추되, 질문 전에 그 요소를 채우는 데 필요한 맥락을 먼저 조사한다.
5. 액션 플랜 작성: 해결이 그럴듯해 보여도 부작용·장애물·FRT 검증 없이 실행으로 넘기지 않는다. 검증을 통과하면 goal로 실행할 수 있는 액션 플랜으로 닫는다.

의도 80% 이상은 다음 중 하나로만 통과한다.

• 사용자가 해석이 맞다고 확인했다.
• 사용자가 AI에게 판단을 명시적으로 위임했다.
• 충돌 없는 공식 표준, 공식 스펙, 강한 사실상 표준이 적용된다.

추측, 취향, 일반론적 Best Practice만으로는 게이트를 통과시키지 않는다.

맥락 우선 채우기

13요소 게이트는 다음 요소로 넘어가는 것을 제한하는 장치이지, 현재 요소를 이해하기 위한 조사를 막는 장치가 아니다.

각 요소를 처음 채울 때는 질문부터 하지 않는다. 먼저 현재 요소를 해석하는 데 필요한 범위 안 맥락을 조사하고, 그 근거로 가장 그럴듯한 내용을 추론해 이해도 표를 채운다. 질문은 조사 후에도 남는 해석 분기, 사용자 의도 충돌, 실행 위험이 있을 때만 한다.

요소별 첫 채움 절차:

1. 사용자 원문과 제공 자료에서 앵커를 뽑는다.
2. 표면 요청만으로 임시 범위를 잡는다. 프로젝트 로컬, 전역·개인 도구, 대화 안 추론, 외부·도메인 조사 중 어디가 가장 가능성이 높은지 판단한다.
3. 임시 범위 안에서 접근 가능한 맥락을 먼저 확인한다.
   • 프로젝트 로컬이면 AGENTS.md, CLAUDE.md, rules.md, memory, feedback, inventory, 관련 코드·문서, 관련 커밋을 본다.
   • 전역·개인 도구면 대상 도구·스킬·설정·전역 규약 파일과 repo 대응 파일을 본다. 대상 경로 밖의 현재 프로젝트 규칙은 끌어오지 않는다.
   • 대화 안 추론이면 현재 대화와 사용자가 붙여준 자료를 다시 읽는다.
   • 외부·도메인 조사이면 현재성·표준·외부 사실이 필요한지 판단하고 필요한 범위에서만 확인한다.
4. 조사한 근거로 1~3개 해석 후보를 만들고 가장 그럴듯한 해석을 추천한다.
5. 이해도 표에는 파일 경로, 커밋, 사용자 원문, 규칙명 같은 앵커를 넣어 채운다.
6. 조사 후에도 80% 미만이면 그때 갭 질문을 한다. 질문은 남은 분기를 줄이는 선택지와 AI 추천을 포함해야 한다.

다중 통과 정착

AI가 맥락을 조사하다 보면 한 턴에 여러 요소가 80% 이상으로 올라갈 수 있다. 이것은 허용한다. 다만 사용자가 그 요소들을 같이 짚지 못한 채 다음 미해결 요소로 빨려 들어가면 안 된다.

구분:

• 신규: 이번 턴에 처음 표에 등장했거나 처음 80% 이상으로 올라간 요소
• 신규-대기: 조사상 80% 이상이지만 이번 턴 정착 대상 3개에 들지 못한 요소
• 표기 없음: 사용자가 명시적으로 확인했거나, 사용자가 그 요소를 전제로 다음 논의에 응답한 요소. 표에는 별도 라벨을 붙이지 않는다.

규칙:

1. 한 턴에 여러 요소를 🟢 신규로 올릴 수 있다.
2. 표 이후 근거 정착 섹션에서 한 번에 다룰 🟢 신규 요소는 최대 3개다.
3. 4개 이상이 새로 80% 이상이면 인과 순서상 앞선 3개만 정착하고, 나머지는 신규-대기로 남긴다.
4. 신규-대기 요소는 표에는 보여줄 수 있지만, 아직 확정 전제로 사용하지 않는다.
5. 🟢 신규 요소가 있으면 첫 미해결 요소 질문보다 신규 묶음 확인이 우선이다.
6. 사용자가 묶음을 통과시키면 다음 턴부터 해당 요소는 별도 라벨 없이 일반 🟢로 둔다.
7. 사용자가 하나라도 반박하면 그 요소로 되돌아가고, 뒤 요소는 필요하면 낮춘다.

표 다음에는 ## 이번 턴 통과 후보 근거 섹션을 둔다. 이 섹션은 표가 아니라 대화체 문단으로 쓴다. 각 요소는 항목별 줄바꿈을 두고, 다음 세 가지를 자연스럽게 말한다.

• 어떻게 판단했는가
• 가장 강한 근거는 무엇인가
• 무엇이 사실이면 이 판단이 바뀌는가

예시:

## 이번 턴 통과 후보 근거

목적은 "UI를 줄이자"보다 "Source Inspector를 폴더 구조 기반 도구로 되돌리자"에 가깝게 봤습니다.
근거는 "폴더구조만", "오탐 제거", "심플"이라는 표현입니다. entity/role/state 진단을 유지하려는 의도가 있다면 목적은 다시 잡아야 합니다.

배경은 의미 추론 메타데이터가 섞이면서 복잡도와 오탐 가능성이 커진 상황으로 봤습니다.
코드상 `data-cstar-entities`, `data-cstar-entity-surface`, `data-cstar-local-layer`, `data-cstar-roles`, `data-cstar-state` 같은 속성이 생성됩니다. 오탐의 실제 원인이 UI 필터나 표시 로직이라면 배경 판단은 바뀝니다.

이상적 결과는 실제 `src/ui/<layer>` 폴더 기준만 남기는 상태로 봤습니다.
"폴더구조만"이라는 말이 가장 강한 근거입니다. copy ctx나 내부 디버깅용으로 의미 추론을 남기고 싶다면 여기서 멈춰야 합니다.

제 판단: 이번 턴에는 목적, 배경, 이상적 결과 3개만 묶음 통과 후보로 확인하는 게 맞습니다.
현실과 문제는 근거가 있어도 다음 묶음으로 넘기겠습니다.

확인 질문: 위 3개를 통과로 보고, 다음 턴에 현실/문제/원인을 이어서 볼까요?

금지:

• 80% 미만을 곧바로 사용자 질문으로 처리하지 않는다.
• "의도 80% 전에는 배경으로 넘어가지 말라"를 "의도 파악을 위한 repo·커밋·문서 조사를 하지 말라"로 해석하지 않는다.
• 사용자가 붙여준 파일, 현재 스킬 파일, 관련 커밋처럼 바로 닿는 근거를 보지 않고 목적·배경·이상적 결과를 추측으로만 채우지 않는다.
• 조사로 여러 요소를 초록 처리해놓고 표 다음에 첫 미해결 요소만 묻지 않는다.
• 신규 초록 요소 4개 이상을 한 번에 정착시키지 않는다.
• 신규-대기 요소를 확정된 전제처럼 사용하지 않는다.

범위와 맥락

의도가 잡히면 요청 범위를 확정한다. 의도 확정 전에는 위의 임시 범위로 현재 요소에 필요한 맥락만 조사한다.

범위	읽는 것	읽지 않는 것
프로젝트 로컬 작업	현재 프로젝트의 AGENTS.md, CLAUDE.md, rules.md, memory, feedback, inventory, 관련 코드·문서	무관한 전역 설정
전역·개인 도구 작업	대상 도구·스킬·설정·전역 규약 파일	대상 경로 밖의 현재 프로젝트 규칙
대화 안 추론	현재 대화와 사용자가 붙여준 자료	로컬 파일·외부 자료
외부·도메인 조사	확인해야 할 외부 지식, 표준, 최신 정보	검증 전 단정

범위 안에서 닿는 자산을 확인한다. 코드, 문서, memory, 설치된 스킬·플러그인, MCP 도구, 사용자가 붙인 자료가 모두 보유 자산이다. 닿는 것과 바깥에서 새로 확인해야 하는 것을 분리한다.

범위 규칙이 일반 Best Practice와 충돌하면 범위 규칙을 따른다. 그 규칙을 바꾸자는 논의는 별도 주제로 분리한다.

13요소

논의는 13개 요소를 인과 순서대로 채운다. 뒤 요소의 정보가 먼저 나와도 보관만 하고, 첫 번째 미해결 요소부터 통과시킨다.

#	요소	의미
1	목적(의도)	표면 요청 뒤의 진짜 동기
2	배경	이 논의를 촉발한 상황·사건·히스토리
3	이상적 결과	다 되었을 때의 구체 상태. 가능하면 입력→출력으로 표현
4	현실	현재 코드·데이터·프로세스·자료의 실제 상태
5	문제	이상적 결과와 현실 사이의 갭
6	원인	그 갭이 생긴 근본 원인
7	제약	바꿀 수 없는 고정 조건
8	보유 자산	닿을 수 있는 코드·문서·memory·도구·스킬·사용자 자료
9	외부 탐색	바깥에서 확인하거나 비교해야 할 지식
10	목표	바꿀 수 있는 레버리지 지점
11	해결	구체적인 future reality 해법
12	부작용	해결이 새로 만드는 문제
13	장애물	실행 전에 넘어야 할 선행 조건

이해도 판정

이해도는 진행률 보고가 아니라 게이트다. 각 행은 색과 퍼센트를 함께 쓴다.

• 🟢 85~100%: 앵커가 있고, 모호어가 없고, 해석이 하나이며, 사용자·범위 근거가 있다.
• 🟡 40~84%: 방향은 있으나 위 조건 중 하나라도 빠졌다. 기본값이다.
• 🔴 0~39%: 비어 있거나 추상 표현뿐이다.

퍼센트는 "사용자가 동의할 확률"이 아니라 "이 행만 보고 다음 결정을 할 수 있는 정도"다. 보통 5% 단위로 올린다. 해석이 둘 이상이거나 사용자·범위 근거가 없거나 숨은 가정에 기대면 80%를 넘기지 않는다.

다음 단어가 핵심 내용에 남아 있으면 해당 행은 노란색을 넘기기 어렵다.

적절히, 필요시, 가능한, 잘, 좋은, 개선, 정리, 더 나은, 대충, 알맞게, 효율적, 유연하게

출력은 1번부터 첫 80% 미만 행까지만 보여준다. 그 행이 다음 작업의 유일한 대상이다. 단, 다음 작업은 곧바로 질문하는 것이 아니라 먼저 그 행을 올릴 수 있는 맥락 조사다. 조사 후에도 80% 미만이면 갭 질문을 한다.

이번 턴에 새로 80% 이상이 된 요소가 있으면 이해도 뒤에 신규 또는 신규-대기만 표시한다. 이미 통과된 요소에는 별도 상태 라벨을 붙이지 않는다. 신규가 하나라도 있으면 표 다음의 첫 섹션은 반드시 이번 턴 통과 후보 근거다.

| 요소 | 내용 | 이해도 |
|------|------|--------|
| 목적 | 비용보다 출시 속도가 우선이라는 의도 (사용자 원문: "속도가 먼저") | 🟢 95% |
| 배경 | Q2 릴리즈 일정 2026-06-30 | 🟢 90% |
| 이상적 결과 | "빠르게 만든다"의 통과 기준이 속도/범위/품질 중 어디인지 미확정 | 🟡 65% |

매 턴의 일

매 턴은 첫 번째 미해결 요소를 조금 더 결정 가능하게 만드는 데 쓴다. 질문보다 맥락 조사와 추론이 먼저다. 다만 조사로 새로 초록색이 된 요소가 있으면, 첫 미해결 요소로 가기 전에 최대 3개까지 먼저 정착시킨다.

1. 이해도 표를 1번부터 첫 80% 미만 요소까지 갱신한다.
2. 첫 80% 미만 요소를 채우기 위해 범위 안에서 더 볼 수 있는 맥락이 있으면 먼저 조사한다.
3. 조사로 새로 🟢 신규가 된 요소가 있으면 최대 3개를 이번 턴 통과 후보 근거에서 대화체로 정착시킨다.
4. 신규 묶음 확인이 필요하면 여기서 멈추고 묶음 통과 여부를 묻는다.
5. 신규 묶음이 없거나 사용자가 이미 통과시킨 상태라면, 현재 가장 그럴듯한 해석을 말한다.
6. 그 해석을 뒷받침하는 근거와 빠진 근거를 밝힌다.
7. 조사 후에도 남은 해당 요소의 갭 질문 하나를 한다. 같은 요소를 통과시키는 데 꼭 필요할 때만 두 개까지 묻는다.
8. 빈 질문을 던지지 않는다. 2~3개 후보와 AI 추천을 함께 제시한다.

첫 턴에서는 숨은 동기 가설을 2~3개 제시하고 가장 가능성 높은 것을 추천한다. 목적이 추상적이면 iceberg 또는 5-Why로 사건 → 패턴 → 구조 → 가정 순서로 내려간다.

예시:

제 판단: 지금 목적은 "문서를 다시 쓰는 것" 자체보다 "다음 사람이 같은 결정을 반복하지 않게 기준을 고정하는 것"에 가깝습니다.
이유: 사용자 원문이 "왜 이렇게 했는지 남겨야 한다"와 "다음에도 같은 판단을 하고 싶다"에 집중되어 있습니다.

해석 후보:
A) 문장 표현만 다듬고 싶다
B) 의사결정 기준을 문서에 고정하고 싶다 (추천)
C) 실행 체크리스트를 만들고 싶다

어느 쪽이 목적에 가장 가깝나요?

근거 사용

판단 근거는 아래 순서를 따른다. 위 근거가 있으면 아래 근거로 덮지 않는다.

1. 확인된 사용자 의도
2. 사용자의 명시적 위임
3. 범위 안 규칙·지시·고정 제약
4. 공식 표준과 공식 스펙
5. 강한 사실상 표준
6. 일반 설계 원리
7. AI의 추론이나 취향

표준이나 Best Practice를 말하기 전에는 실행 환경, 의존성 제약, 아키텍처, 범위 비용을 확인한다. 정식 표준이나 강한 사실상 표준이 분명하면 "제 판단"이 아니라 "정석은 X입니다"라고 말한다. 다만 그 정석이 확인된 사용자 의도, 제약, 취향과 충돌하면 멈추고 묻는다.

사용자가 "맞아?", "그치?", "어떻게 생각해?"라고 확인을 구하면 무비판적으로 동의하지 않는다. 근거가 충분하면 근거를 들어 동의하고, 부족하면 빠진 전제나 반례를 짚는다.

외부 탐색

외부 탐색은 ⑨ 요소로 다룬다. 최신성, 표준, 법·가격·제품, 외부 API처럼 바뀔 수 있는 정보에 의존하면 확인한다. 확인한 결과는 ⑨에 넣고, ⑪ 해결의 근거로만 사용한다.

외부 Best Practice가 범위 안 규칙과 충돌하면 "표준이니까 바꾸자"고 말하지 않는다. 충돌 사실을 밝히고, 규칙을 바꾸는 논의가 필요한지 별도로 묻는다.

정체 구간 처리

13요소 중 하나가 막히면 /discuss 안에서 해당 행을 더 작게 쪼개어 근거, 선택지, 반증 조건을 보강한다.

예:

• ③ 이상적 결과가 추상적이면 실제 입력→출력 예시를 만든다.
• ⑦ 제약이 서로 충돌하면 고정 조건, 선호, 추측을 분리한다.
• ⑧ 보유 자산보다 새 개념이 많아지면 기존 자산으로 줄일 수 있는 경로를 먼저 본다.
• ⑨ 외부 근거가 필요하면 확인할 질문과 출처를 특정한 뒤 필요한 범위에서만 탐색한다.

그 결과는 다시 13요소 표의 해당 행에 반영한다.

메모리

사용자가 지속될 원칙·경계·프로젝트 사실을 확인하면, 해당 범위에 memory 관행이 있는지 본다. 있으면 그 형식대로 저장한다. 없으면 대화 안에서만 유지하고, 임의로 새 memory 체계를 만들지 않는다.

AI 추론만으로는 저장하지 않는다.

액션 플랜 판정

그럴듯한 해결이 나왔다고 바로 실행을 제안하지 않는다. goal로 넘길 액션 플랜을 만들려면 다음이 필요하다.

• 핵심 요소 1~11이 모두 🟢 85%+
• 12 부작용과 13 장애물 질문을 실제로 수행
• FRT 게이트 통과

부작용과 장애물

⑪ 해결이 초록색에 도달하면 후행 요소를 심문한다.

부작용은 세 가지를 본다.

1. 파급 범위: 다른 모듈·기능·프로세스에 무엇이 번지는가?
2. 숨은 가정: 이 해결은 무엇이 변하지 않는다고 전제하는가?
3. 되돌림 비용: 틀렸을 때 rollback이 가능한가?

장애물은 세 가지를 본다.

1. 선행 작업: 시작 전에 먼저 해야 할 일은 무엇인가?
2. 기술적 전제: 필요한 API·라이브러리·인프라가 준비되어 있는가?
3. 지식 갭: 아직 확인하지 않은 스펙·동작·내부 구조는 무엇인가?

FRT 게이트

FRT는 의례가 아니라 전환 게이트다. 해결을 넣었을 때 앞의 요소들이 실제로 정합하는지 역방향으로 확인한다.

#	검증	통과 조건	실패 신호
1	⑪→⑤ 문제 해소	해결이 문제를 직접 제거한다	문제와 무관한 작업을 해결로 둠
2	⑪→⑥ 원인 제거	근본 원인이 제거된다	증상만 줄이고 원인은 남음
3	⑪→⑦ 제약 준수	고정 제약을 모두 지킨다	제약 위반 1건 이상
4	⑪→⑧ 자산 활용	이미 있는 자산을 검토했다	새 개념·새 파일·새 도구를 바로 도입
5	⑪→⑫ 부작용 수용	부작용이 문제보다 작다	부작용을 "없음"으로 둠
6	⑨ 대안 검토	최소 1개 대안을 기각 근거와 함께 봤다	대안 없음

각 행은 주장, 증거, 반증 조건을 가져야 한다. 증거가 파일·규칙·사용자 원문·구체 코드 없이 일반 서술뿐이면 통과시키지 않는다. 반증 조건을 쓸 수 없는 주장도 통과시키지 않는다.

통과하면 최종 산출물은 goal 실행용 액션 플랜이다. 액션 플랜은 실행자가 대화를 다시 추론하지 않아도 바로 움직일 수 있어야 한다.

## Goal 액션 플랜

### Goal
[한 문장 objective — 무엇을 달성할 것인가]

### Done
- [완료 판정 1]
- [완료 판정 2]

### Scope
- 포함: [실행 범위]
- 제외: [하지 않을 것]

### Constraints
- [고정 제약]

### Plan
1. [첫 실행 단계]
2. [두 번째 실행 단계]
3. [검증 단계]

### Verification
- [테스트/빌드/리뷰/수동 확인]

### Risks
- [예상 부작용과 대응]

액션 플랜 제안은 이렇게 닫는다.

핵심 요소 1~11은 🟢 85% 이상이고, 부작용·장애물 질문을 마쳤습니다.
FRT 게이트도 통과했습니다.

제 판단: 위 액션 플랜을 goal로 실행하면 됩니다.
이유: [확인된 의도 / 범위 규칙 / 표준 / Best Practice 근거].

goal로 진행할까요?

사용자가 승인하면 /discuss는 끝나고 goal 실행으로 넘어간다.