모호한 주제를 기사 개요로 변환 스킬(Vague Topic to Article Outline Skill)

사용자를 대신해 기사를 작성하지 않고, 광범위하거나 반쯤 형성된 주제를 독특하고 연구 가능한 기사 개요로 전환합니다. 사용자의 기존 작업과 지식 기반에서 시작하여, 관련 커뮤니티에서 반복되는 질문을 식별하고, 집중된 독자 질문을 선택한 후, 섹션별 연구 발판을 만듭니다.

사용 시기

다음과 같은 경우에 사용합니다:

사용자가 모호한 주제를 주고 기사로 전환하는 데 도움을 원할 때
연구 질문, 개요, 또는 관점을 요청할 때
직접 작성하고 나중에 에이전트가 다듬기를 원할 때
새 주제를 기존 위키 페이지, 프로젝트 또는 구현 작업에 연결하려 할 때

다음과 같은 경우에는 사용하지 마십시오:

완성된 기사를 즉시 작성할 때
연구나 출처 작업 없이 일반적인 브레인스토밍을 할 때
논제와 구조가 이미 명확한 기존 초안을 편집할 때

핵심 사고 모델(Core Mental Model)

다음 순서를 사용하십시오:

모호한 주제
  ↓
기존 작업 및 지식
  ↓
반복되는 외부 질문
  ↓
집중된 독자 문제
  ↓
차별화된 논제
  ↓
구체적인 메커니즘 또는 설계 객체
  ↓
섹션 주장 및 연구 질문
  ↓
반론 및 증거 격차
  ↓
요청된 작업 공간에 재사용 가능한 개요 저장

목표는 미래를 예측하거나 분야를 요약하는 것이 아닙니다. 목표는 다음 네 가지 사이에서 가장 강력한 교차점을 찾는 것입니다:

사용자가 실제로 구축하고, 관찰하고, 생각한 것
특정 기술 독자가 이해하거나 결정해야 하는 것
현재 실무자들이 활발히 논쟁하고 있는 것
일차 출처와 구체적인 예시로 뒷받침할 수 있는 것

[[outlining-an-article|기사 개요 작성]]의 개요 작성 순서를 사용하십시오:

주제 → 브레인덤프 → 그룹화 → 형태 만들기 → 섹션당 한 문장 → 초안

기술 Substack 기사의 경우, 초안 작성 전에 연구 계층을 추가하십시오:

주제 → 기존 작업 → 반복 질문 → 집중된 각도
→ 브레인덤프 → 그룹화 → 스토리 형태 → 섹션 주장 → 연구 → 초안

절차(Procedure)

1. 글쓰기 제약 조건 정의(Define the writing constraint)

연구를 시작하기 전에 다음을 설정하십시오:

의도된 독자
기사 유형: 기술 에세이, 현장 가이드, 아키텍처 노트, 반대 논쟁, 또는 사례 연구
사용자가 개요를 원하는지 완성된 산문을 원하는지 여부
개요를 저장할 위치
사용자의 기존 프로젝트, 구현, 또는 위키 컨텍스트

기본값: 기술 독자, 수동 연구 및 초안 작성, 개요만, 이후 개선.

완료 확인: 독자와 기사의 역할을 설명하는 한 문장을 작성하십시오.

2. 먼저 사용자의 기존 작업 검사(Inspecting the user's existing work first)

참조된 파일을 완전히 읽어 다음을 식별하십시오:

명시적 논제
구체적인 경험 또는 예시
아키텍처 경계
실패 사례
평가 기준
트레이드오프
미해결 질문
사용자가 이미 사용하는 언어

사용자가 위키나 폴더를 참조하면, 새로운 프레임을 발명하기 전에 겹치는 개념을 검색하십시오. 가장 관련성 높은 개념, 출처, 테마, 노트 및 프로젝트 페이지를 읽으십시오.

사용자 자신의 작업에 기반한 아이디어를 선호하십시오. 구체적인 구현, 실패한 평가, 설계 결정, 또는 미해결 트레이드오프는 일반적인 트렌드 주장보다 일반적으로 더 가치 있습니다.

완료 확인: 사용자의 자료에서 재사용 가능한 원칙 3~8개를 나열하십시오.

3. 반복되는 실무자 질문 연구(Research recurring practitioner questions)

엔지니어링 커뮤니티의 현재 논의와 일차 기술 출처에 대해 웹 검색을 사용하십시오. 적절한 여러 표면을 검색하십시오:

프로토콜 저장소 및 GitHub 이슈/토론
공식 구현 예시
엔지니어링 블로그 및 문서
Reddit 또는 기타 실무자 커뮤니티
기술 포럼 또는 컨퍼런스 자료

주제 이름뿐만 아니라 질문을 검색하십시오. 예시:

[주제] GitHub issue authority
[주제] implementation problem
[주제] engineering discussion failure
[주제] protocol limitations
[주제] production lessons

다음과 같은 범주 아래에 반복되는 질문을 기록하십시오:

정체성과 권위
상태 및 트랜잭션
상호 운용성
데이터 및 컨텍스트 경계
안전 및 남용
평가 및 관찰 가능성
제품 및 운영 모델

체계적인 데이터 세트가 뒷받침하지 않는 한 통계적 인기를 주장하지 마십시오. 연구가 정성적인 경우 "표본 논의에서 반복되는 질문"과 같은 표현을 사용하십시오.

완료 확인: 주제별로 그룹화된 10~25개의 반복 질문과 대표적인 출처를 생성하십시오.

4. 최상의 기사 질문 선택(Select the best article question)

후보 질문을 다음 기준으로 평가하십시오:

테스트	질문
독자 가치	특정 독자가 설계 또는 제품 결정을 내리는 데 도움이 됩니까?
사용자 권위	사용자가 이에 대한 직접적인 작업이나 발전된 관점을 가지고 있습니까?
증거	주장이 일차 출처와 예시로 뒷받침될 수 있습니까?
구체성	전체 주제보다 좁습니까?
독창성	설문 조사가 아닌 관점을 만듭니까?
내구성	현재 과대광고가 바뀐 후에도 유용할까요?
시리즈 가능성	후속 기사로 이어질 수 있습니까?

하나의 주요 질문과 최대 두 개의 대체 질문을 선택하십시오. 승자가 더 강한 이유를 설명하십시오.

좋은 질문 형태:

[특정 구축자]는 [새로운 조건]에서 [특정 시스템]을 어떻게 설계해야 합니까?

피해야 할 형태:

[대형 기술]이 [전체 산업]을 어떻게 바꿀까요?

완료 확인: 선택된 독자 질문과 그 이유를 명시하십시오.

5. 사용자의 작업에서 논제 도출(Derive the thesis from the user's work)

다음 템플릿을 사용하십시오:

일반적인 견해는 다음과 같습니다:
사용자의 작업이 시사하는 바는 다음과 같습니다:
그 견해가 불완전한 이유는 다음과 같습니다:
더 유용한 모델은 다음과 같습니다:
구축자를 위한 실질적 결과는 다음과 같습니다:
가장 강력한 반대 의견은 다음과 같습니다:

논제는 주제 레이블이 아닌 논쟁 가능한 주장이어야 합니다.

유용한 변환의 예시:

"에이전틱 전자상거래" → "판매자 에이전트는 챗봇이 아닌 제한된 결과 해결 시스템입니다."
"엔터프라이즈 에이전트" → "통제 단위는 모델이 아닌 액션 시스템입니다."
"에이전트 메모리" → "메모리는 모델 기능이 아닌 애플리케이션 계층 제어 표면입니다."

완료 확인: 한 문장으로 된 논제와 30초 설명을 작성하십시오.

6. 구체적인 메커니즘 이름 지정 또는 정의(Name or define a concrete mechanism)

기사에 논제를 유용하게 만드는 설계 객체를 부여하십시오. 예시:

여정 계약
권위 경계
평가 도구
컨텍스트 예산
기능 표면
결정 추적
결과 원장
개입 루프

단순히 독창적으로 들리기 위해 전문 용어를 발명하지 마십시오. 용어가 이미 존재하는지 검색하고, 인접 용어를 식별하며, 필요한 경우 작업 용어로 레이블을 지정하십시오.

완료 확인: 메커니즘을 1~3문장으로 정의하고 작은 예시를 보여주십시오.

7. 기사를 스토리로 구성(Shape the article as a story)

주제 카탈로그를 만들지 마십시오. 독자에게 한 섹션에서 다음 섹션으로 계속 읽을 이유를 제공하십시오.

다음 기본 스토리 흐름을 사용하십시오:

시작 문제 또는 시나리오 — 주제를 설명하기 전에 구체적인 상황을 보여줍니다.
긴장감 — 명백한 해결책이 실패하거나 불완전한 이유를 드러냅니다.
논제 — 주요 주장을 명확히 진술합니다.
메커니즘 — 문제를 설명하는 모델, 아키텍처 또는 설계 객체를 소개합니다.
적용 — 메커니즘이 실제로 어떻게 변화시키는지 설명합니다.
가드레일 또는 트레이드오프 — 무엇이 잘못될 수 있고 경계가 어디에 속하는지 보여줍니다.
증거 및 평가 — 구축자가 접근 방식이 효과가 있다는 것을 어떻게 알 수 있는지 설명합니다.
시사점 — 독자의 작업이나 산업에 어떤 변화가 있는지 보여줍니다.
열린 결말 — 요약이 아닌 질문이나 해결되지 않은 긴장감으로 마무리합니다.

모든 섹션에 대해, 문단을 작성하기 전에 한 문장을 작성하십시오:

섹션:
이 섹션이 만드는 주장:
예시 또는 증거:
독자가 가지게 될 질문:
다음 섹션이 어떻게 답변하는지:

다음 섹션은 일반적으로 이전 섹션이 만든 질문에 답변해야 합니다. 스토리를 진행하지 않는 섹션은 제거하십시오.

완료 확인: 개요를 위에서 아래로 읽을 때 주제 목록이 아니라 질문과 답변의 사슬처럼 읽혀야 합니다.

8. 브레인덤프, 그룹화 및 축소(Braindump, group, and reduce)

개요를 최종 확정하기 전에:

브레인덤프 모든 관련 아이디어, 예시, 출처, 반대 의견 및 개인적인 관찰.
기존 자료 검색 위키, 노트, 하이라이트 및 프로젝트 파일에서.
그룹화 관련 아이디어를 묶고 선택된 각도를 지원하지 않는 자료는 제거.
형태 선택 위의 스토리 흐름 또는 다른 적절한 구조에서.
섹션당 한 문장 작성 및 전환 확인.
미해결 아이디어는 보류 목록에 유지 기사에 억지로 넣지 말 것.

주제에서 바로 산문으로 이동하지 마십시오. 개요는 원시 사고와 초안 사이의 다리입니다.

완료 확인: 모든 유지된 아이디어는 섹션에 속하고, 모든 섹션은 하나의 주요 주장을 가집니다.

9. 연구 질문 및 증거 격차 추가(Add research questions and evidence gaps)

각 유지된 섹션에 대해 다음을 제공하십시오:

사용자가 답변해야 할 연구 질문
찾아야 할 증거
예상되는 반론
논제를 바꿀 수 있는 요소
구체적인 예시, 다이어그램 또는 사례

단순히 흥미로운 질문을 작성하지 마십시오. 각 질문은 섹션의 주장을 확립, 도전 또는 조건화하는 데 도움이 되어야 합니다.

완료 확인: 모든 섹션에는 2~5개의 답변 가능한 연구 질문과 최소한 하나의 증거 대상이 있습니다.

10. 반론 및 증거 격차 추가(Add counterarguments and evidence gaps)

일방적인 트렌드 서술을 만들지 마십시오. 4~8개의 심각한 반대 의견을 추가하십시오. 각각에 대해:

주장:
찬성 증거:
반대 증거:
내 마음을 바꿀 요소:
논제에 대한 시사점:

주장을 사실, 예측, 해석 또는 의견으로 표시하십시오. 게시 전에 일차 증거가 필요한 주장을 식별하십시오.

완료 확인: 기사의 가장 약한 뒷받침되지 않은 주장과 이를 테스트하는 데 필요한 출처를 나열하십시오.

11. 개요 아티팩트 생성(Create the outline artifact)

사용자가 파일을 요청하면 요청된 위치에 생성하십시오. Substack 초안의 경우:

substack/drafts/<설명적-제목>.md

전면부를 사용하십시오:

---
type: substack-draft
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: outline
working_title: "..."
---

파일에는 작업 논제, 독자, 선택된 질문, 연구 분야, 섹션 개요, 질문, 반론 및 출처 목록이 포함되어야 합니다. 명시적으로 요청되지 않는 한 완성된 기사 산문을 작성하지 마십시오.

사용자가 명시적으로 요청하지 않는 한 Substack 초안에 대해 wiki/index.md 또는 wiki/log.md를 업데이트하지 마십시오. raw/를 수정하지 마십시오.

완료 확인: 파일이 존재하고, 완전한 개요를 포함하며, 사용자에게 다음에 무엇을 연구할지 명확히 알려줍니다.

12. 결과 보고(Report the result)

다음을 포함한 짧은 보고서를 제공하십시오:

선택된 프레이밍
선택된 이유
사용자의 기존 작업과 가장 강한 겹침
개요가 저장된 위치
사용자가 다음에 연구하고 작성해야 할 내용
연구의 한계, 특히 "가장 일반적인"이 정성적 표본에서 추론된 경우

연구 및 출처 규율(Research and Source Discipline)

프로토콜 및 구현 주장에는 일차 기술 문서를 사용하십시오.
커뮤니티 논의는 질문과 실패 모드를 발견하는 데 사용하고, 시장 전반의 행동에 대한 의문의 여지가 없는 증거로 사용하지 마십시오.
프로토콜 기능, 구현 동작, 사용자 신뢰 및 시장 채택을 분리하십시오.
일반적인 예측보다 구체적인 예시, 추적, 평가 사례 및 실패 보고서를 선호하십시오.
웹 검색을 사용한 경우 최종 응답에서 인터넷에서 파생된 사실적 주장을 인용하십시오.
정성적 검색 결과를 통계적으로 대표적인 것으로 제시하지 마십시오.

일반적인 실패 모드(Common Failure Modes)

사용자의 가장 강력한 증거 대신 업계 주제로 시작하기
주장 없이 프로토콜 개요 생성하기
실제 분석 단위가 여정, 워크플로우 또는 액션 시스템일 때 에이전트를 분석 단위로 취급하기
독자의 질문을 정의하기 전에 기사 작성하기
모델 기능을 프로덕션 보장과 혼동하기
API 또는 프로토콜을 안전한 상호 운용성의 증거로 취급하기
기사의 결론을 바꿀 수 없는 연구 질문 묻기
"시장이 움직이고 있습니다"와 같은 표현 뒤에 불확실성 숨기기
인상적인 용어를 만들면서 인접 문헌을 확인하지 않기
사용자가 수동으로 연구하고 작성하도록 요청했을 때 세련된 산문 초안 작성하기

확인 체크리스트(Verification Checklist)

완료하기 전에:

모호한 주제를 기사 개요로 변환