문제 다그치기

연구 주제를 정하기 전에, 또는 문제 정의가 흔들릴 때 질문을 하나씩 던져 문제를 확정하고 잠근다. 도구가 답을 대신 정하지 않는다. 사용자가 답하고, 도구는 빈 곳과 모순을 찾아 다시 묻는다.

이 스킬은 문제를 정하는 단계만 맡는다. 선행 연구 확인은 literature-scout, 착수 판정은 feasibility-gate가 맡는다. 순서는 이 스킬에서 "안"을 만들고, literature-scout로 신규성을 본 뒤, 사용자가 승인해 잠그는 것이다. 신규성을 보기 전에 승인하지 않는다. research-session의 공통 규칙을 따른다.

0. 시작 전에 읽는 것

공통 규칙 1대로 파일을 읽는다.

• 이 프로젝트의 이전 판 문제 정의, 변경 기록, 승인기록, 접은 주제(docs/접은주제.md)
• research-portfolio의 연구 지도와 경계가 있으면 다른 프로젝트의 문제 정의와 접은 주제. 같은 질문을 다른 프로젝트가 이미 다루거나 접었으면 그 기록부터 보인다.
• 이번에 다시 정의하는 것이라면 지금까지 몇 판이 나왔는지 센다(5절).

1. 묻는 방식

• 한 번에 질문 하나만 한다. 질문마다 왜 묻는지 한 줄을 붙인다.
• 가능하면 선택지 2~4개와 도구의 권고 하나를 함께 준다. 선택지 입력 도구가 있으면 쓰고, 없으면 번호 목록으로 묻는다.
• 사용자가 모른다고 하면 "미정"으로 두고 무엇을 알면 정해지는지 적는다. 억지로 답을 받지 않는다.
• 다음 말은 측정할 수 있는 말로 바꿀 때까지 다시 묻는다: 효율적, 안전한, 신뢰할 수 있는, 확장 가능한, 자동으로, 실용적인, 일반적인.

2. 다그치는 규칙

• 새 답이 앞 답과 어긋나면 두 답을 나란히 보이고 어느 쪽인지 묻는다.
• 답이 범위를 넓히면 넓어진 부분을 짚고, 넣을지 범위 밖으로 둘지 묻는다.
• 사용자가 확신하는 주장에도 반례나 가장 단순한 대안을 하나 대고 반응을 듣는다.
• 과제 제안서, 투고처 공고, 지도교수 의견 같은 외부 문서에 맞추려고 문제를 바꾸자는 답이 나오면, 그것이 연구 질문 자체의 변경인지 표현의 조정인지 묻고 따로 기록한다.
• 맞장구, 칭찬, 요약으로 시간을 쓰지 않는다. 도구의 권고와 사용자의 결정을 섞지 않는다.

3. 물을 축 (순서대로, 이미 확정된 축은 건너뛴다)

축	확정할 것	확정의 기준
1 문제	누가, 어떤 상황에서, 무엇 때문에, 무엇을 못 하는가	한 문장. 해법 이름이 들어가지 않는다
2 문제의 층	공학으로 풀 문제인가	법, 제도, 사회 합의로만 풀리는 부분은 범위 밖으로 옮긴다
3 실재 증거	문제가 현장에 있다는 증거	공개 자료로 확인할 수 있는 숫자나 사례 하나. 없으면 관문 G1 후보
4 단순 대안	지금 방법과 가장 단순한 대안이 왜 안 되는가	설정 하나, 짧은 시한, 우회 경로로 같은 효과가 나지 않는 이유
5 논문의 종류	측정, 방법(설계), 증명, 시스템 가운데 무엇인가	하나를 고르고 그 이유. 나중에 바꾸면 5절의 변경으로 친다
6 주장	이 논문이 하는 주장	하나. 셋 이상이면 하나로 줄인다
7 정의상 참 점검	주장이 모형의 정의에서 바로 나오는가	그렇다면 그것은 결과가 아니라 성질이다. 결과로 남길 부분(크기 측정, 비교, 반례)을 따로 적는다
8 성공과 반증	결과 전에 정하는 성공 기준과 접는 조건	숫자나 판정 규칙. 어떤 결과가 나오면 접는지
9 범위 밖	하지 않는 것	세 가지 이상, 이유와 함께
10 자료	무엇으로 증거를 얻는가	공개되어 있고 검증 가능한가, 직접 만들면 재현 가능한가와 그 비용
11 산출	투고처 후보, 마감, 분량, 요건	일정과 졸업이나 과제 요건에 맞는가. 투고처는 문제를 정한 뒤에 고른다. research-portfolio의 투고처표와 요건계산이 있으면 읽고 묻는다

4. 멈춤

• 열한 축이 모두 "확정" 또는 "미정(정해지는 조건 포함)"이면 멈춘다.
• 질문 20개에 닿으면 멈추고 남은 축을 목록으로 보인다.
• 같은 축에서 세 번 연속 답이 바뀌면 그 축을 미정으로 두고, 판단에 필요한 자료(선행 연구, 파일럿 측정)를 다음 할 일로 적는다.

5. 잠금과 변경

문제 정의는 쉽게 바뀐다. 결과나 심사평을 본 뒤 틀을 바꾸면 이전 관문과 문헌 조사가 무효가 되는데도, 기록 없이 판만 올라가는 일이 많다. 그래서 다음을 지킨다.

• 사용자가 승인하면 그 판을 잠근다. 파일 해시와 승인 시각을 승인기록에 남긴다.
• 잠근 뒤 축 1, 5, 6, 7 가운데 하나라도 바꾸면 "틀 변경"이다. 변경 기록에 이전 판, 새 판, 바뀐 축, 이유를 적는다. 이유는 셋 가운데 하나로 분류한다: 새 증거(실험, 문헌), 새 논점(사용자나 심사자의 의견), 외부 맞춤(과제, 투고처).
• 틀 변경 뒤에는 literature-scout와 feasibility-gate를 바뀐 축에 대해 다시 돌린다. 다시 돌리기 전까지 새 판은 "안"이다.
• 판 수를 센다. 하루에 두 번, 또는 한 주에 세 번 넘게 틀이 바뀌면 진행을 멈추고 사용자에게 숫자로 알린다(예: "이번 주 틀 변경 4회, 모두 새 논점. 새 증거에 따른 변경 0회"). 계속할지는 사용자가 정한다.
• 축 24, 811의 수정은 틀 변경이 아니다. 판 번호의 소수점만 올린다.

6. 산출

docs/문제정의-v<판>.md(프로젝트 설정이 다른 위치를 정하면 그곳)에 쓴다. 지난 판은 구판/으로 내린다.

# 문제 정의 v<판> (날짜) 상태: 안 / 잠금(해시)

한 문장 문제:
논문의 종류와 주장:

| 축 | 내용 | 상태(확정/미정) | 근거나 정해지는 조건 |
|---|---|---|---|

정의상 참인 부분과 결과로 남길 부분:
범위 밖:
성공 기준과 접는 조건(결과 전 고정 예정):
사용자 결정: (시각과 함께)
도구 권고 가운데 채택하지 않은 것:
틀 변경 이력: v<n> → v<n+1>, 바뀐 축, 이유 분류
다음: literature-scout(축 6), feasibility-gate(축 3, 4, 7, 8, 10, 11)

사용자 결정은 승인기록에도 한 줄씩 남긴다. 만든 파일은 답에서 바로 열 수 있게 링크로 보인다.

7. 글

질문과 기록은 쉽고 짧은 한국어로 쓴다. 영어 용어와 식별자는 영문 그대로 둔다.