critique-researchlisted

## 왜 필요한가 **쓴 사람은 자기 글을 검증할 수 없다.** 코드는 돌려 보면 틀린 게 드러나지만, 글은 틀려도 그대로 읽힌다 — 특히 표 안의 숫자는 그럴듯해 보여서 저자가 다시 봐도 안 걸린다. 그리고 조사 문서의 결함은 **문장이 아니라 다리에 있다.** 계수는 맞는데 거기서 처방으로 넘어가는 대목이 비약이거나, 자기가 세운 구분이 자기 결론을 반박하거나, 표본 설계가 보장한 결과를 발견으로 적는 식이다. 이건 같은 사람이 다시 읽어서는 안 보인다 — 그 다리를 놓은 게 본인이기 때문이다. 실측(2026-09-16): 스크린샷 653장을 집계한 조사 문서를 다섯 관점에 넘겼더니 여섯 건이 나왔다 — 방향이 반대로 적힌 비교 한 건, 어떤 정의로도 재현되지 않는 상관계수 한 건, 근거 없이 단정한 규제 판정 한 건, 자기 구분이 자기 결론을 뒤집는 자리 한 건, 원자료에 있는데 안 쓴 절 하나, 그리고 **원자료 파일 자체가 부분 집합**이었다는 것. 저자는 그 직전까지 문서를 세 번 고쳤는데 하나도 못 잡았다. ## 언제 쓰나 **쓴다** — 글이 산출물이고 남이 그걸 근거로 다음 일을 할 때: - 조사·벤치마킹·실측 보고서 - 분석 문서, 의사결정 근거 문서 - 수치·표·집계가 든 모든 문서 **안 쓴다**: - 디자인 시안·목업 → `mockup-review`가 담당한다. 관점이 다르다 — 시안은 "이 화면이 작동하는가"를 묻고, 이 스킬은 "이 주장이 근거를 갖는가"를 묻는다 - 코드 변경 → 정확성·동시성·테스트 실효성 같은 코드용 관점으로 간다 - 개인 메모, 대화 요약, 한 번 쓰고 버릴 글 ## 절차 ### 1. 관점을 고른다 **전부 다 띄우지 않는다.** 문서 성격에 맞는 것만 고른다. 아래 다섯이 기본 후보다. | 관점 | 무엇을 묻나 | 언제 넣나 | |---|---|---| | **수치 재현** | 문서의 모든 숫자를 원자료에서 다시 계산해 일치하는가. 집계 정의가 절마다 일관되는가 | 원자료가 파일로 있을 때. **원자료가 있으면 이건 거의 항상 넣는다** | | **논증 구조** | 관찰에서 결론으로 넘어갈 때 빠진 전제. 자기모순. 제목이 본문보다 센 자리. 표본 구성이 결론을 만든 자리 | 문서가 권고·판정을 낼 때 | | **미사용 인사이트** | 원자료에 있는데 문서가 안 쓴 것 | 원자료가 문서보다 클 때 | | **실행 유용성** | 이 문서를 받아 다음 일을 할 사람이 무엇을 결정할 수 있나. 안 읽어도 결과가 같은가 | 문서가 누군가의 입력일 때 | | **압축** | 무엇을 자르고 무엇을 합치나 | 문서가 길어졌을 때 | 성격이 다르면 새로 짠다 — 위 다섯은 목록이지 정답이 아니다. ### 2. 프롬프트를 규격대로 쓴다 **네 가지를 반드시 넣는다.** 하나라도 빠지면 그만큼 검증이 약해진다. 1. **읽기 전용을 명시한다** — "파일을 편집·생성하지 말고 git 명령·빌드를 실행하지 마라." 분석용 일회성 스크립트 실행이 필요하면 그것만 따로 허용한다. `g