글쓰기에 OpenSpec 적용해 보기
시작점 - 왜 글쓰기에 OpenSpec을 쓰기로 했는지?
OpenSpec으로 스펙 문서를 작성하는 개발 방식이 나에게는 효과가 컸다. 초안을 작성하고, 모호한 부분이나 누락된 부분, 잘못될 수 있는 부분을 여러 번 검토해 채운 뒤, 그걸 바탕으로 할 일 목록을 만들고 순서대로 개발하니 의도한 대로 결과가 나왔다. 다만 개발 결과를 검증하는 단계는 아직 없어 보완 중이다.
회사나 개인 작업에서 얻은 깨달음과 지식을 블로그에 정리하고 싶은데, 쉽지가 않다. 글쓰기 습관이 들지 않아서 생각이 글로 잘 정리되지 않는다. 두서없이 쓴 뒤 AI에게 "어색한 부분 고쳐 달라", "구성 검토해 달라" 하며 수정을 맡기곤 했는데, AI가 고쳐 주는 것도 단편적이라서인지 전체 글은 여전히 두서없고 정리되지 않은 느낌이었다.
그러다 개발 스펙 작성 과정과 글쓰기 과정이 비슷하다는 생각이 들었다. 초안을 쓰고, 검토하고, 보완하는 반복 구조가 같다. 스펙 쓰듯 생각을 정리하면 되겠다. 그래서 그 방식을 적용해 보기로 했다.
글쓰기용 워크플로우 설계
OpenSpec에는 커스텀 스키마를 만드는 기능이 있다. 기존에 개발용으로 쓰던 스키마는 proposal → specs → design → tasks 구조인데, 글쓰기에는 맞지 않다. 그래서 글쓰기 전용 스키마를 처음부터 새로 설계했다.
구조는 3단계다. outline → draft → post. outline에서는 주제, 핵심 주장, 독자, 톤, 섹션 구조를 정한다. 글을 쓰기 전에 방향을 잡는 단계다. draft에서는 outline을 바탕으로 본문을 문장과 문단으로 채운다. post에서는 완성된 draft를 블로그에 올릴 수 있는 MDX로 변환한다.
설계에서 가장 신경 쓴 부분은 AI의 역할이다. 기존 방식의 문제가 "AI에게 다듬어줘 하고 던지는 것"이었으니까, 이번에는 AI가 각 단계에서 글쓰기 코치로 동작하도록 만들었다. 바로 결과물을 내놓지 않고, 먼저 질문을 던진다. outline 단계에서는 "왜 이 글을 쓰는지", "독자에게 어떤 변화를 주고 싶은지"를 묻는다. draft 단계에서는 내가 쓴 초안에 구조, 논리, 명확성, 톤, 문장 품질 다섯 가지 관점으로 피드백을 준다.
문장 품질 원칙도 스키마에 넣었다. 한 문장에 하나의 생각. 명사형 종결 대신 동사형 종결. 중복 표현과 불필요한 수식어 제거. 이런 기준이 있어야 AI가 구체적으로 피드백할 수 있다.
각 단계에 완료 조건을 넣었다. 조건이 없으면 "좀 더 고칠까?" 하다가 수정만 반복하게 된다. 조건을 충족하면 다음 단계로 넘어가도록 해서, 글쓰기에도 마감이 생기게 했다. 전체 설계 스펙은 GitHub에서 볼 수 있다.
실제로 써보기 — 워크플로우로 이 글 쓴 이야기
이 글은 위에서 설계한 3단계(outline → draft → post) 워크플로우를 적용해 쓴 첫 번째 결과물이다. 지금부터는 각 단계에서 실제로 어떤 일이 일어났는지 얘기한다.
시작하면 AI가 먼저 이렇게 말한다.
워크플로우: outline → draft → post. 첫 번째 아티팩트부터 시작하겠습니다.
outline 단계에서는 단계 표시줄과 첫 질문이 함께 나온다.
← ☐ 글쓰기 동기 ☐ 독자 변화 ☐ 계기 ✔ Submit →
이 글을 쓰는 이유가 뭔가요? (왜 이 경험을 공유하고 싶은지)
- **1. 과정 기록** — 나만의 워크플로우를 만들어간 과정을 기록으로 남기고 싶다
- **2. 도구 소개** — OpenSpec을 활용한 글쓰기 방법을 다른 사람들에게 알리고 싶다
- **3. 회고 & 인사이트** — AI와 글쓰기 프로세스에 대해 깨달은 점을 정리하고 싶다
- **4. Type something.** — (직접 입력)
- **5. Chat about this** — (대화로 설명)
선택지가 있어서 빠르게 고를 수도 있고, 맞는 게 없으면 4번으로 직접 쓰거나 5번으로 이야기할 수 있다. 저 표시줄의 세 가지(글쓰기 동기, 독자 변화, 계기)를 차례로 물어보는데, 나는 첫 질문에서 선택지가 딱 맞지 않아서 4번으로 직접 설명했다. 답하면서 주제랑 핵심 주장이 잡히고, 섹션 구조도 나왔다. 빈 문서에 막 쓰기랑은 달랐다. 방향이 먼저 있으니까 뭘 쓸지 덜 막막했다.
draft 단계에서는 섹션 하나씩 초안 쓰고 피드백 받는 식으로 갔다. 첫 섹션을 두서없이 써서 보냈더니 구조, 논리, 명확성, 톤, 문장 품질 이렇게 다섯 관점으로 피드백이 왔고, "검증 프로세스 언급은 곁가지라 빼거나 줄여라", "스펙 작성이랑 글쓰기 유사점을 한 문장만 더 구체적으로" 같은 게 있었다. 둘 다 맞는 말이라 받아들였다. 전에는 "다듬어줘"라고만 했을 때 이런 식의 피드백은 거의 없었고, 문장만 다듬어져서 내 생각을 체계적으로 표현한다는 느낌은 없었는데, 이번에는 그렇게 할 수 있었다.
워크플로우를 설계한 부분은 설계 문서가 이미 있어서 AI가 초안을 잡았다. 글의 모든 부분을 직접 쓸 필요는 없다. 기존 자료가 있으면 그걸 토대로 초안을 만들고, 내가 검토하고 수정하는 방식도 가능하다. 단계별 역할이 정해져 있으니 어떤 방식이든 흐름이 끊기지 않는다.
느낀 점
세 단계를 모두 거치고 나니 몇 가지 느낀 점이 있다.
구조화된 프로세스는 개발 밖에서도 동작한다. outline에서 방향을 잡고, draft에서 살을 붙이고, 피드백을 받아 수정하는 흐름은 스펙 문서를 쓸 때와 본질적으로 같았다. "초안 → 검토 → 보완" 반복이 글쓰기에서도 통한다는 걸 이번에 확인했다.
AI를 다르게 쓰게 됐다. "다듬어줘"만 하면 교정기처럼 쓰이는데, 단계마다 질문 던지고 관점별로 피드백 주면 코치처럼 쓰인다. 도구는 같은데 프로세스 설계에 따라 역할이 갈린다.
글쓰기 부담도 덜했다. "좋은 글을 써야지" 압박 대신 "outline만 채우기", "이 섹션만 초안 쓰기"처럼 잘게 나누니까 시작이 수월했다. 개발할 때 큰 기능을 태스크로 쪼개는 것과 같은 이치다.
아쉬운 점도 있지만, 평소보다 글이 빠르게 나온 것만 해도 만족스럽다. 부족한 부분은 반복하면서 채워 나가면 된다. 다만 글쓰기는 나 혼자 하고 싶다. 이번처럼 생각을 정리하는 방식으로 연습하고, 매일 잠들기 전 30분씩 책을 읽고, 주기적으로 글 쓰는 건 이어 가되, 점차 AI 없이 혼자 쓰는 쪽으로 옮겨 가려 한다.