위키를 사업계획서 양식으로 쌓기로 했다 — 기획이 탄탄해지는 부수 효과

📝 한줄 요약

위키를 슬라이드로 변환하는 데 성공한 뒤, 같은 방법으로 사업계획서와 할 일까지 뽑을 수 있을까를 실험했다. 그러다 "문서를 잘 쓴다는 게 뭘까"에서 사업계획서 양식에 도착했는데, 진짜 값어치는 문서가 하나 더 나오는 게 아니라 기획 자체가 탄탄해지는 것이었다.

바쁘시면 이것만 읽어도 돼요:

• 위키 한 벌에서 슬라이드가 나오는 건 이미 확인했다(지난 글). 그럼 사업계획서·할 일도?
• "문서를 잘 쓴다"를 파다가 → 사업계획서 항목대로 위키를 쌓자는 아이디어에 도착
• ★ 부수 효과가 더 컸다 — 항목이 곧 체크리스트라 기획이 촘촘해지고, 수익화까지 생각하게 된다
• AI에게 할 일을 뽑게 했더니 원본과 21개 중 4개만 글자가 같았다. 매번 달라지니 믿을 수가 없다
• 문서 구조를 기계가 그대로 읽게 바꿨더니 마일스톤 5개·할 일 21개가 매번 똑같이 나왔다
• 다만 설계 문서에서는 잘 안 뽑혔다. 설계는 판단을 적는 문서지 계획 문서가 아니라서

🎯 이런 분들께 도움돼요

• AI로 프로젝트를 굴리는데 문서를 여러 벌 쓰는 게 지겨운 분
• 만들기는 시작하는데 "그다음 어떻게 팔지"에서 막히는 분
• AI한테 계획을 뽑게 해봤는데 매번 다른 게 나와서 못 믿겠는 분

😫 문제 상황 (Before)

며칠 전에 위키 문서에서 발표 슬라이드가 저절로 나오게 만들었다. 슬라이드용 파일을 따로 만들지 않고, 원래 있던 글을 화면이 알아서 잘라 보여주는 방식이다.

그때 알게 된 게 있었다. 변환이 안 되는 부분은 하나같이 원래부터 안 읽히던 문단이었다. 그래서 규칙을 손보는 대신 원문을 다듬었더니 한 챕터 14장이 전부 한 화면에 들어갔다. 슬라이드도 글도 같이 좋아진 것이다.

그러면서 질문이 남았다. 슬라이드가 되면 다른 것도 되지 않을까?

내가 같은 얘기를 세 번 쓰고 있었기 때문이다. 기획할 때 한 벌, 사업계획서 쓸 때 또 한 벌, 할 일 정리할 때 또 한 벌. 형식만 바꿔서 세 번 쓰다 보면 어느 게 최신인지도 헷갈린다.

🛠️ 사용한 도구

• 도구: Claude Code (VS Code 확장) · 모델: Claude Opus 5
• 기간: 이틀 (문서와 실험 위주, 코드는 거의 안 건드림)

🔧 작업 과정

"잘 쓴다"가 뭘까 — 사업계획서 양식이 떠올랐다

슬라이드가 됐으니 다른 것도 뽑아보자는 생각까지는 쉬웠다. 문제는 원천이 되는 문서가 어떻게 생겨야 하는지를 모르겠다는 것이었다.

그러다 떠올랐다. 위키를 사업계획서 항목대로 쌓아보면 어떨까?

처음엔 "그러면 사업계획서를 따로 안 써도 되겠네" 정도였다. 그런데 따져볼수록 다른 게 더 커 보였다.

첫째, 항목이 곧 체크리스트라 기획이 촘촘해진다. 사업계획서에는 문제·고객·가치제안·수익 모델·채널이 이미 잘 짜여 있다. 그 칸을 채우는 것만으로 빠짐없이 기획하게 된다.

둘째 — 이게 진짜 큰데, 수익화까지 생각하게 된다. 사업계획서는 원래 투자를 받으려고 쓰는 문서다. 그런데 투자라는 게 결국 판매와 비슷하다. 남에게 돈을 받는 일이니까. 그 양식을 쓰면 내 프로젝트가 돈이 되는 마지막 단계까지 고려하면서 기획하게 된다.

보통은 만드는 데까지만 하고 나서 "이제 이걸 어떻게 하지?"로 힘들어한다. 만들어놓고 파는 걸 고민하니 늦는 것이다. 양식이 그 칸을 미리 물어봐 주면 처음부터 고려하게 된다.

셋째, 덤으로 상세페이지가 나온다. 크라우드펀딩 상세페이지 항목이 사업계획서와 꽤 겹친다. 문제·해결·왜 우리인가. 한 벌 잘 쌓아두면 꺼내 쓸 수 있다.

그럼 할 일도 뽑히나

내 최종 목적은 대시보드다. 계획과 진행을 한 화면에서 보는 것. 그러려면 문서에서 할 일까지 나와야 한다.

사업계획서에는 보통 상세 계획과 일정도 들어 있으니 될 것 같았다. 그런데 그동안 나는 AI와 대화만 하면서 작업했다. 문서가 안 남는 방식이다. 그래서 이번엔 순서대로 제대로 써보기로 했다.

PRD부터 시작해서 제대로 작성하면서 진행하고 싶어

기획 문서를 쓰고, 요구사항을 정리하고, 설계 문서까지 만들었다. 중간에 한 번 반려도 했다. AI가 정리해준 요구사항을 읽어보니 그동안 한 얘기를 모아놓은 것이지 체계가 아니었다.

✅ 확인한 것: 원인은 맨 위에 전체 그림 한 장이 없어서 항목들이 부스러기로 읽힌 것이었다. 그림 한 장을 따로 만들고 요구사항에 번호를 붙이니(REQ-01, REQ-02…) "이거 됐나?"로 추적되는 문서가 됐다.

AI가 뽑아준 할 일이 원본과 4개만 같았다

설계 문서에서 할 일을 뽑아 계획 파일에 옮겨 적었다. 그런데 하다 보니 이상했다. AI가 문서를 읽고 머릿속으로 쪼개서 옮기고 있었던 것이다.

그래서 대조해봤다. 원본 문서에 있는 문장과, 옮겨 적힌 문장을.

✅ 확인한 것: 개수는 21개로 같았는데 글자까지 똑같은 건 4개뿐이었다.

옮기면서 무의식적으로 줄어 있었다. "양식 1장 쓰기"가 "양식 1장"이 되고, "섞어 안 깨지는지"가 "섞어도 안 깨지는지"가 됐다. 한 글자 차이지만 기계는 이걸 다른 일로 본다. 나중에 문서를 고쳤을 때 "이게 그거인가"를 대조할 수 없어진다.

하루 전에 옮긴 게 하루 만에 이 상태였다.

그래서 추론을 버리고 파싱으로 갔다

이때 생각이 바뀌었다. AI가 문서를 읽고 이해해서 할 일을 만드는 방식이 문제였던 것이다. 그러면 매번 조금씩 달라진다.

문서 자체에 제목 태그가 있고 리스트 태그나 순서 태그가 있잖아.
거기에 따라 자동으로 트리 구조가 만들어지니까,
그걸 그대로 할 일로 변환하면 되는 거 아닌가?

이해하지 말고 구조만 기계적으로 읽게 하자는 것이다. 40줄짜리 짧은 스크립트로 확인해봤다. 문서에는 체크박스도 표시도 하나 안 넣었다.

✅ 확인한 것: 마일스톤 5개, 할 일 21개가 그대로 뽑혔다. 그리고 몇 번을 돌려도 똑같이 나왔다.

규칙은 이것뿐이다.

이게 이번 실험의 제일 큰 수확이다. AI가 이해해서 만들면 매번 달라지지만, 구조를 기계가 그대로 읽으면 매번 같다. 그리고 양식이 바뀌어도 바뀐 양식대로 읽으니 그대로 따라온다. 문서를 고칠 필요가 없다.

그런데 설계 문서에서는 잘 안 뽑혔다

계획이 어긋난 지점이 있었다. 나는 원래 상세 계획 문서에서 할 일을 뽑을 생각이었는데, AI가 설계 문서 안에 계획까지 넣어버려서 거기서 뽑게 됐다. 그리고 헐거웠다.

처음엔 문서의 구조를 더 잘 쓰면 되는 문제라고 봤다. 실제로 다듬으니 조금 나아졌다. 그런데 계속 부족했고, 결국 다른 결론에 왔다.

설계 문서는 그냥 설계 문서일 뿐이야. 상세 계획 문서가 아니잖아

설계 문서를 열어보면 방법 비교표, 실측 근거, 순서를 왜 바꿨는지, 안 하기로 한 것으로 차 있다. 전부 판단과 근거다. 할 일은 부록처럼 붙어 있다. 애초에 할 일을 뽑으라고 쓴 문서가 아니니 누락이 생기는 게 당연했다.

그래서 층을 하나 더 두기로 했다.

설계 문서      →  왜 이렇게 하나 (판단·근거)
상세 계획 문서  →  무엇을 어떤 순서로   → 여기서 큰 목표가 나온다
실행 문서      →  실제로 이렇게 한다   → 여기서 할 일이 나온다

실행 문서는 튜토리얼에 가깝다. "이렇게 하면 된다"를 적는 문서라 거기서 뽑으면 누락이 적을 것이다. 그리고 그 문서는 나중에 그대로 사례글이나 강의 자료가 된다.

✅ 결과 (After)

아직 안 된 것

할 일 뽑기는 절반만 됐다. 구조만으로 뽑히는 건 확인했는데 설계 문서에서 뽑으면 누락이 생긴다. 다음은 상세 계획 문서와 실행 문서를 만들고 거기서 다시 뽑아보는 것이다.

그리고 사업계획서 양식은 아직 본격적으로 시도하지 않았다. 기존에 있던 사업계획서로 변환을 시도해보긴 했는데 잘 안 됐다. 다만 그 문서들이 애초에 뽑히기 좋게 쓰인 게 아니라서, 양식 탓인지 문서 탓인지는 아직 모른다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 말로 따지지 말고 짧게 돌려본다. "문서 구조에서 할 일이 뽑히나"를 한 시간 논의하는 것보다 40줄 스크립트가 빨랐다. 그리고 논의로는 절대 안 나왔을 숫자(21개 중 4개)가 나왔다
2. AI가 이해해야 하는 자리와 기계가 세는 자리를 가른다. 문서를 쓰는 건 AI가 잘하지만, 문서에서 뽑는 건 기계여야 한다. 매번 같은 답이 나와야 하는 일에 추론을 쓰면 안 된다
3. AI가 요구사항을 지어내지 않게 한다. 내가 예전에 한 말을 기록에서 찾아오게 하고 빠진 칸만 질문하게 했다

이렇게 하면 안 돼요

1. 문서 사이를 번호로 가리키지 말 것. "설계 문서 1단계 참고"처럼 적으면 순서가 바뀔 때마다 다 고쳐야 한다. 이틀 동안 순서가 두 번 바뀌었고 그때마다 여러 곳이 어긋났다. 이름으로 가리키면 안 깨진다
2. 같은 내용을 두 문서에 적지 말 것. 요구사항 문서와 설계 문서가 같은 목록을 갖고 있었더니 하나를 고칠 때마다 다른 쪽에 옛 정보가 남았다
3. AI가 만든 걸 그대로 받지 말 것. 이번에도 두 번 틀렸다 — 요구사항이 부스러기가 됐고, 순서를 잘못 옮겼다. 읽어보고 아니면 반려하는 게 품질 장치다

🌍 다른 업무에 적용한다면?

• 제안서를 자주 쓰는 일 — 사업계획서 항목으로 위키를 쌓아두면 제안서·소개서·상세페이지가 같은 원천에서 나온다
• 강의나 교육 자료 — 커리큘럼 문서를 잘 써두면 슬라이드·교재·과제 목록이 같이 나온다
• 핵심은 형식마다 파일을 따로 만들지 않는 것이다

🚀 앞으로의 계획

1. 상세 계획 문서와 실행 문서를 만들고 거기서 할 일을 다시 뽑아본다
2. 사업계획서 양식을 제대로 만들어 프로젝트 하나를 그 양식으로 쌓아본다
3. 최종 목표는 미션 하나를 주면 AI가 문서와 할 일을 스스로 만들고 끝까지 진행하는 것이다. 지금 문서 작업이 무거워 보이는 이유가 그것이다 — 대화로만 할 거면 필요 없지만, 자동으로 돌아가게 하려면 필요한 투자다

📋 재사용 가능한 프롬프트

프롬프트 1: 문서에서 할 일이 뽑히는지 실제로 재보기

이 문서에 체크박스나 표시를 하나도 넣지 말고, 제목과 번호 구조만 읽어서 큰 목표와 할 일 목록을 뽑아봐. 짧은 스크립트로 실제로 돌려보고 결과를 보여줘. 그리고 내가 정리해둔 목록이랑 글자까지 대조해서 몇 개가 같은지 세어줘.

프롬프트 2: 요구사항을 지어내지 않게 하기

이 프로젝트의 요구사항 문서를 만들어줘. 단 조건이 있어. 내가 예전에 한 말들(작업 기록·대화 기록)에서 찾아온 것만 쓰고, 네가 지어내서 채우지 마. 못 채운 칸은 비워두고 나한테 물어봐. 어디서 가져온 건지 날짜도 같이 적어줘.

프롬프트 3: 계획을 갈아엎을 때 옛 할 일 처리하기

계획을 새로 세웠는데 예전 할 일들이 남아 있어. 하나씩 새 계획에 대조해서 ①이미 된 것 ②새 계획에도 있는 것 ③자리가 없어진 것으로 갈라줘. ③은 지우지 말고 "안 하기로 함" 표시만 하고 왜 그런지 한 줄 적어줘. 판단이 애매한 건 나한테 물어봐.

아루나의 다른 프로젝트가 궁금하다면 → aluna-site.vercel.app