aluna 대시보드 — 사업 관제탑

📝 한줄 요약

프로젝트가 늘어날수록 전체 그림이 안 보여서 관리 도구를 찾아 헤맸는데, 답은 지라도 노션도 아니라 org-mode라는 2003년생 물건의 원리였다. 도구를 배우는 대신 원리만 훔쳤다 — "상태는 텍스트 파일에 적고, 화면은 그 파일들을 읽어서 조립한다." AI와 하룻밤 만에 첫 화면을 띄웠다.

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

• 노션·투두앱은 다 죽었다. 원인은 내가 아니라 "체크하는 것 자체가 일"이 되는 구조
• 마크다운으로 적으니 218줄 통짜 목록이 됐고, 그걸로는 아무것도 파악이 안 됐다
• "내 폴더가 거울처럼 대시보드로 보이면 좋겠다"는 꿈을 말했더니, AI가 20년 전부터 그렇게 사는 사람들(org-mode)을 알려줬다
• 지라 기각(팀 조정 도구 — 혼자 일하는 사람에겐 의식 비용만), 노션 기각(내 데이터가 남의 서버에)
• 핵심 원칙 하나만 지키면 된다: 상태·계획을 앱이나 DB에 가두지 않는다. 소스는 파일, 뷰어는 여러 개
• AI의 첫 답변이 틀려서 반박했더니 정정했다 — 근거를 되묻는 게 설계 품질을 지켰다

🎯 이런 분들께 도움돼요

• 노션·투두앱·다이어리를 전전하다 전부 버려본 사람
• AI랑 여러 프로젝트를 굴리는데 "지금 전체가 어떻게 돌아가는지" 볼 화면이 없는 사람
• 비개발자지만 "내 도구는 내가 만든다"에 끌리는 사람

😫 문제 상황 (Before)

관리 도구의 무덤이 있다. 내 경우엔 노션, 투두앱, 그리고 몇 권의 다이어리가 묻혀 있다.

죽은 이유는 매번 같았다. 기록하는 것 자체가 일이었다. 실제 작업은 폴더 안에서 벌어지는데, 관리 도구는 그 바깥에 따로 있으니 "작업 따로, 기록 따로"가 된다. 바쁠수록 기록이 밀리고, 밀린 기록은 거짓말이 되고, 거짓말이 된 보드는 안 열게 된다.

그래서 AI와 일하면서부터는 그냥 마크다운 파일에 적었다. 작업하던 자리에 그대로 적으니 기록은 됐다. 그런데 새 문제가 생겼다. 할 일을 모아둔 파일이 218줄짜리 통짜 목록이 된 것이다.

그 사이 프로젝트는 계속 늘었다. 스터디 운영, 강의 개편, 사이트, 시스템 정비까지 동시에 굴러가는데, 목록을 아무리 읽어도 "지금 뭐가 어디까지 왔고 뭐가 이상한지"가 안 보였다. 뭔가를 보류해 놨는데 왜 보류했는지 기억이 안 났다. 한동안은 내가 정리를 못 하는 사람이라서 그런 줄 알았다.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus 5 / Claude Fable 5
• 특이사항: 새 앱 설치 없음 — 이미 있던 마크다운 파일과 사이트 코드 위에 얹음

🔧 작업 과정

밤 9시, "이 파일도 화면으로 보여야 돼" — 대시보드가 태어난 발화

시작은 거창한 기획이 아니었다. 통짜 목록 파일을 정리하다가, 문득 내 사이트가 떠올랐다. 내 사이트는 각 프로젝트 폴더의 README를 읽어서 프로젝트 카드를 자동으로 만들어준다. 그렇다면 —

아루나 사이트에서 README 읽어서 프로덕트 카드로 표시하잖아. 그런 것처럼 이 할 일 파일도 그런 식으로 대시보드로 보여야 돼. 그래야지 관리가 되고 내가 파악을 할 수가 있거든. 가능할까?

AI의 답: 가능하고, 이미 있는 부품(사이트의 폴더 스캐너)을 재사용하면 오늘 밤에 된다. 그리고 진짜 그날 밤에 됐다. 브라우저에 관리 화면이 떴다 — 프로젝트 26개의 명함 전수 표, 깨진 데이터 경고 배너, 현황판.

됐는지 확인한 방법: 이 화면엔 비공개 정보가 다 보이니까, 공개 사이트(배포 주소)에서는 같은 주소가 아예 404(없는 페이지)로 뜨는 걸 확인했다. 관리 화면은 내 컴퓨터에서만 열린다.

첫 화면을 펼친 순간 — "내가 못 하는 게 아니었구나"

화면을 처음 펼쳐놓고 나온 말:

내가 이걸 이렇게 펼쳐놓고 보니까, 내가 괜히 파악을 못 하는 게 아니구나. 뭔가 많고 복잡한데? 뭐가 뭔지 잘 모르겠고, 보류된 건 왜 보류됐는지도 모르겠고. 칸반보드 같은 게 필요한 거 같아.

이게 대시보드의 첫 성과였다. 잘 정리된 화면이 아니라, "많고 복잡하다"는 사실이 눈에 보이게 된 것. 문제가 보이니 정리가 시작됐다. 그날 밤 보류 41개를 전부 심판했다 — 죽은 항목 8개 삭제, 15개는 각 프로젝트 문서로 이사, 16개는 "○○되면 깨움" 조건을 달아 대기, 2개는 지금 할 일로 승격.

"칸반으로 보니까 한눈에 확 보인다" — 그리고 화면은 리모컨이 됐다

유형별 표를 상태별 칸반(대기 → 하는 중 → 운영 중 → 완성 → 잠듦)으로 바꾸자 반응이 왔다:

칸반으로 보니까 이제 한눈에 확 보인다, 뭐가 이상한지 아닌지가. 근데 너한테 일일이 말하기 귀찮으니까 칸반에서 내가 직접 상태를 바꿀 수 있으면 좋겠어.

여기서 이 시스템의 성격이 정해졌다. 카드에서 상태를 바꾸면 데이터베이스가 아니라 그 프로젝트 폴더의 README 파일이 직접 수정된다. 진실은 여전히 파일에 있고, 대시보드는 리모컨일 뿐이다.

됐는지 확인한 방법: 상태 한 줄 말고는 파일이 1바이트도 안 바뀌는 걸 해시 대조(파일 지문 비교)로 검증했고, 새로고침하면 카드가 실제로 다른 열로 이사해 있었다.

부산물도 있었다. 화면에서 카드를 직접 옮겨보다가 "잠깐 재운 것"과 "완전히 접고 참고용으로만 남긴 것"이 다르다는 걸 발견해서 상태 값 자체를 6단계로 다시 깎았다. 화면이 생기니 분류 체계의 구멍이 몸으로 느껴졌다.

다음 날의 제동 — "그런 선례가 진짜 있어?"

다음 날 오후, 작업을 이어가기 전에 내가 먼저 브레이크를 걸었다. README에 메타데이터(파일 맨 위의 정보칸)를 넣어서 프로젝트 관리까지 하는 게 어쩐지 찜찜했다.

README라는 게 원래 그냥 폴더 설명 파일일 뿐인데, 나는 지금 메타데이터를 올려서 기능을 확장하고 있잖아. 이런 식으로 쓰는 선례가 진짜 있어? 그냥 마크다운 파일 위에 메타데이터 올리는 거랑 README에 올리는 건 다른 얘기잖아. 네가 조사한 두 개를 지금 헷갈리는 거 같아.

AI의 첫 답변은 "업계 표준"이라며 유명 도구들을 나열했는데, 따져 물으니 정정이 나왔다. 그 도구들은 일반 콘텐츠 파일에 쓰는 거지 README가 기본이 아니었고, "README에 정보칸을 넣는 방식"은 일부 문서 사이트 도구의 관행이었다. 뭉뚱그린 답이었던 것이다.

이 반박 덕에 설계 근거가 오히려 단단해졌다. 내 README는 그냥 설명 파일이 아니라 사이트가 본문을 그대로 페이지로 발행하는 콘텐츠 파일이라 그 관행에 정확히 해당한다는 결론이 나왔다. AI 답변이 그럴듯할수록 "그 근거 진짜야?"라고 한 번 되묻는 게, 비개발자가 설계 품질을 지키는 유일한 방법이라는 걸 배웠다.

"거울처럼 실시간으로" — 지라와 노션이 기각된 이유

찜찜함이 풀리자 진짜 질문이 나왔다. 내가 최종적으로 원하는 그림:

내가 폴더에서 작업을 하면, 자동으로 대시보드에 내 프로젝트 현황이 거울처럼 실시간으로 보이기를 원하는 거거든. 개발자분들은 지라 같은 걸 써서 프로젝트 관리를 하던데 나도 그걸 써야 되는지, 아니면 자체 대시보드를 만드는 걸로 해결이 가능할지. 노션도 있긴 하지만 노션은 내 데이터가 외부로 나가잖아.

AI의 판정:

• 지라 기각 — 지라의 본질은 여러 사람의 작업을 조정하는 도구다. 티켓을 만들고 상태를 옮기는 의식(ceremony)이 많은 이유가 그거다. 혼자+AI로 일하는 사람에겐 그 비용만 있고 이득이 없다. 게다가 데이터가 남의 서버로 나간다.
• 노션 기각 — 같은 이유. 데이터가 외부에 갇힌다. 그리고 이미 한 번 죽은 무덤이다.
• 판정 기준은 기능 목록이 아니라 불변식 하나였다: "상태·계획을 앱이나 DB에 가두지 않는다. 소스는 파일, 뷰어는 여러 개." 이 문장에 지라도 노션도 다 걸렸다.

"Org 모드가 뭐야?" — 20년 된 물건에 내 꿈이 이미 있었다

그때 AI가 처음 듣는 이름을 꺼냈다. 내 위시리스트를 다 말해보고 물었다:

Org 모드가 뭐야? 자세하게 설명해줄래? 나는 비전보드도 있었으면 좋겠고, 그 안에 프로젝트도 있고, 세부 프로젝트도 있고, 루틴이나 투두 혹은 저널·메모도 다 있단 말이지. 칸반도 필요하고 간트도 필요하고 캘린더뷰·갤러리뷰도 필요하지. Org 모드로 그걸 다 할 수가 있는 거야?

org-mode는 2003년에 나온 시스템이다. Emacs라는 개발자용 에디터 안에서 도는데, 원리는 한 줄이다. 일반 텍스트 파일에 계획·할일·일지를 적으면, 도구가 여러 파일을 훑어서 현황 화면을 자동으로 조립해준다. 계층은 무한(비전 → 프로젝트 → 세부 → 할일), 체크박스를 달면 상위 항목에 진행률이 자동으로 굴러 올라가고, 루틴은 완료해도 다음 주기에 되살아나고, "오늘 할 일·마감 임박"을 모든 파일에서 긁어 한 화면(agenda)으로 만들어준다.

"작업은 각자 폴더의 파일에서, 현황은 거울처럼 한 화면에" — 내가 방금 말한 그림 그대로였다. 내가 새로 발명해야 하는 줄 알았던 것을, 20년째 그렇게 살아온 사람들이 이미 있었다.

재미있는 건 AI도 완벽하지 않았다는 것. 처음엔 "40년 된 물건"이라더니 다음 턴에 스스로 정정했다 — org-mode는 23년, 40년은 그게 얹혀 있는 Emacs였다.

그래서 org-mode를 쓰기로 했냐면 — 아니다. 여기가 이 글에서 제일 중요한 부분이다:

• Emacs는 학습곡선이 험해서 비개발자가 배울 물건이 아니다 (AI도 말렸다)
• 그리고 위시리스트를 대조해보니 org-mode가 약한 뷰(칸반은 텍스트뿐, 간트 불편, 갤러리 없음, 예쁜 웹 배포 없음)가 정확히 내가 원하는 뷰들이었다

그래서 결정: 도구는 안 배우고 패턴만 훔친다. "파일이 진실, 화면은 조립"이라는 원리는 org-mode 것을 그대로 가져오되, 파일은 (Emacs 전용 형식 대신) 마크다운으로, 화면은 내 사이트에 얹은 자체 대시보드로, 파일 관리는 AI가 대행한다. org-mode가 못 그리는 칸반·갤러리·로드맵은 어차피 자체 화면이니 그리면 된다.

✅ 결과 (After)

Before vs After

이틀의 진짜 수확은 화면보다 기준이다. 이후 어떤 기능을 붙일까 말까 고민될 때마다 판정이 한 문장으로 끝난다: "이거 하면 상태가 앱에 갇히나?" 갇히면 기각, 파일에 남으면 진행.

결과물

내 컴퓨터에서만 열리는 관리 화면 — 프로젝트 칸반(상태 드롭다운으로 README 직접 수정), 명함 전수 표, 경고 배너. 이 위에 이후 로드맵·루틴·계기판이 쌓이게 된다 (다음 편들에서).

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

효과적이었던 것

1. 도구를 고르기 전에 불변식부터 정한다. "상태를 앱에 가두지 않는다" 한 문장이 지라·노션 고민을 즉시 끝냈다. 기능 비교표는 끝이 없지만 불변식 판정은 한 방이다.
2. AI 답변이 그럴듯할수록 근거를 되묻는다. "그런 선례가 진짜 있어?" 한 번에 뭉뚱그린 답이 정정됐고, 설계 근거가 단단해졌다. AI는 반박하면 더 정확해진다.
3. 새로 발명하기 전에 오래된 선례부터 찾게 한다. 내 요구사항을 다 말하고 "이미 이렇게 사는 사람들 없어?"라고 물었더니 20년짜리 답이 나왔다. 검증은 세월이 해줬다.

이렇게 하면 안 돼요

1. 도구부터 고르고 요구사항을 끼워 맞추기. 노션이 죽은 이유를 안 따지고 다음 앱으로 갈아타면 무덤만 늘어난다. 죽은 이유(체크가 일이 됨, 데이터가 밖에 갇힘)를 먼저 부검해야 한다.
2. 선례가 있다고 도구까지 통째로 배우기. org-mode가 답이라고 Emacs에 입문했으면 지금쯤 대시보드가 아니라 에디터 튜토리얼에 갇혀 있었을 거다. 패턴과 도구는 분리해서 훔칠 수 있다.

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

• 팀 위키·업무 현황판: "회의록·상태를 노션에 또 적는" 이중 기록 대신, 작업 문서 자체에 상태 한 줄을 넣고 화면이 그걸 긁어 보여주는 구조는 어디든 이식 가능하다
• 가게·매장 운영: 발주·재고·루틴 체크를 각각의 파일에 적고 한 화면으로 조립 — 앱 구독 없이
• 공부 관리: 과목별 폴더에 진도 체크박스만 적으면, 전체 진도판은 조립되는 것

🚀 앞으로의 계획

이 글은 시리즈 1편이다. 이후 편에서 이 뼈대 위에 쌓은 것들을 하나씩 풀 예정:

• 2편 — 계획 파일 하나가 캘린더·로드맵이 되는 문법 (날짜 3정밀, 우선순위, 접기)
• 3편 — 클릭조차 안 하는 루틴 (파일이 있으면 한 것)
• 4편 — 하루 종일 일했는데 로드맵이 0%인 이유 (측정의 원리)
• 5편 — 마크다운이 관제탑 화면이 되기까지
• 종합편 — 전체 설계도 + 따라하기 치트시트

📋 재사용 가능한 프롬프트

프롬프트 1: 도구 선택 컨설팅 (지라·노션 vs 자체 제작)

나는 [원하는 최종 그림 — 예: 폴더에서 작업하면 대시보드에 거울처럼 현황이 보이는 것]을 원해. 내가 지키고 싶은 불변식: [예: 내 데이터를 외부 서버에 두지 않는다 / 기록 자체가 일이 되면 안 된다]. 기존 도구(지라·노션·트렐로 등)를 쓸지, 자체 제작할지 컨설턴트처럼 판정해줘. 각 도구가 원래 어떤 문제를 풀려고 만들어졌는지와 내 상황의 차이를 근거로 대고, 내 불변식에 걸리는 도구는 기능이 좋아도 기각해.

프롬프트 2: 오래된 선례 찾기

내가 원하는 워크플로우: [설명]. 이걸 새로 발명하기 전에, 이미 10년 이상 검증된 오래된 선례가 있는지 찾아줘. 그 도구를 통째로 배우라는 답 말고, 어떤 원리·패턴을 내 환경([마크다운/AI/웹] 등)으로 가져올 수 있는지로 답해줘. 그 선례가 약한 부분도 같이 알려줘 — 거긴 자체 제작할 거야.

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

📝 한줄 요약

계획 문법을 정하던 날, AI가 할 일을 성격으로 분류하다 첫날부터 중복을 냈다. 그래서 판단 자체를 없앴다 — "그 일의 파일이 사는 폴더가 곧 카테고리." 추론하는 AI보다 눈으로 보면 아는 규칙이 이긴다. 이날 하루에 목표 파일 폐기, 날짜 3정밀, 우선순위 2개까지 — 내 계획 문법이 통째로 태어났다.

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

• 주간·월간 목표 파일을 만들려다 관뒀다 — "떨렁 있는 파일은 안 쓰게 된다". 대신 날짜 붙은 항목을 대시보드가 긁어모아 주간·월간 화면을 자동 조립 (org-mode agenda 방식)
• 날짜는 3정밀 — 확정(@8월 5일), "이 주 안"(@32주차), "이 달 쯤"(@9월). 불렛저널의 퓨처로그를 문법으로
• org-mode엔 기능이 다 있다. 그래서 위험하다 — "그 속성이 화면을 바꾸느냐"로 심사해서 우선순위 2개(!·!!)만 통과시켰다
• AI가 항목을 "무슨 성격인가"로 분류하다 중복을 냄 → "파일이 사는 폴더가 카테고리"로 규칙 교체. 추상 판단 제거
• 표준을 만들어도 옛 문서에서 값을 옮기며 검증을 안 하면 화석이 생긴다 — 낡음 점검을 루틴에 박음

🎯 이런 분들께 도움돼요

• 계획표·목표 파일을 만들 때마다 안 쓰게 돼서 자책해본 사람
• 노션 템플릿의 속성 채우기(태그·상태·우선순위·기한…)에 지쳐본 사람
• AI한테 정리를 맡겼는데 자꾸 이상한 데 분류해서 답답한 사람

😫 문제 상황 (Before)

1편(「노션도 지라도 아니었다」)에서 뼈대는 섰다. 파일이 진실, 화면은 조립 — org-mode의 원리를 마크다운으로 가져오기로 했다.

그런데 뼈대만으로는 아무것도 안 굴러간다. 바로 다음 질문이 온다. 그래서 그 파일에 뭘, 어떻게 적는데?

여기가 사실 제일 위험한 구간이다. 나는 계획 양식을 만들 때마다 죽였다. 항목마다 채워야 할 칸이 늘어나는 순간 적는 게 일이 되고, 일이 된 양식은 안 열게 된다. 그리고 이번엔 변수가 하나 더 있었다 — 파일을 관리하는 게 나만이 아니라 AI라는 것. AI가 알아서 잘 분류해줄 거라 믿었는데, 표준을 만든 첫날부터 그 믿음이 깨졌다.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus 5 / Claude Fable 5
• 특이사항: 이날 하루(7/30)에 문법 대부분이 정해짐 — 재료는 그날 세션 원문

🔧 작업 과정

"떨렁 있는 파일은 안 쓰게 된다" — 목표 파일이 태어나기 전에 죽은 사건

주간·월간 목표를 세우고 트래킹하고 회고하고 싶다고 했더니, AI가 "목표.md 파일을 하나 만들자"고 제안했다. 연간·월간·주간 섹션이 있는 그럴듯한 양식이었다. 그런데 보자마자 걱정이 앞섰다:

걱정이 되는 게, 목표.md가 자동으로 밑에 세부 목표가 들어가고 체크가 되면서
최종 목표가 완료되는 식으로 돼야지 관리가 될 거 같거든?
그냥 저렇게 떨렁 있으면 아마 사용 안 하게 될 수도 있을 거 같거든?

이 한마디에 설계가 뒤집혔다. AI의 답: "그 걱정이 맞다. 목표 파일을 안 만든다."

대신 이렇게 됐다. 각 프로젝트의 계획 파일에는 이미 @날짜가 붙은 항목들이 있다. 날짜가 이번 주면 그게 곧 이번 주 목표다. 대시보드가 아홉 개 계획 파일에 흩어진 날짜 항목을 긁어모아 주간·월간 화면을 조립한다. 체크는 목표 화면에서 따로 하는 게 아니라, 평소처럼 일하고 저장할 때 계획 파일에서 자연히 일어난다. 그러면 주간 화면의 달성률이 저절로 올라간다.

관리할 파일 0개 추가, 새로 들일 습관 0개. 이게 org-mode의 agenda 방식이다 — 주간 파일이 따로 없고, 모든 파일의 날짜 항목을 모아 한 주를 조립한다. 20년 검증된 패턴.

됐는지 확인한 방법: 다음 주가 되면 대시보드 주간 화면에 각 프로젝트의 날짜 항목이 실제로 모여 뜨는지, 지난주 결산("12개 중 9개 완료")이 자동으로 나오는지로 판정.

"너무 자유롭나?" — 불렛저널이 문법이 된 순간

그다음 걱정은 날짜였다. 목표라는 게 다 마감이 있는 게 아니다:

목표라는 게 데드라인이 있는 것도 있지만 없는 것도 있잖아.
"9월 달쯤에 해야지" 같은 것도 있는 거잖아. 나는 불렛저널 방식을 써도 좋을 거 같아.
처음엔 그냥 투두처럼 적었지만 나중에 속성이 붙는 거지 — 얘는 마일스톤이다,
얘는 9월에 넣는 마일스톤… 속성을 마음대로 바꿀 수 있어야 될 거 같아.
네가 생각하기엔 어때? 너무 자유롭나?

AI의 답이 이 글에서 제일 아끼는 문장이다: "자유를 속성 시스템으로 구현하면 죽고, 줄 옮기기로 구현하면 산다."

노션식으로 가면 항목마다 유형·상태·우선순위 필드를 채우는 양식이 된다. 적는 순간 분류를 강요당하니 캡처가 무거워진다 — 내가 노션을 떠난 이유 그대로. 불렛저널의 진짜 천재성은 반대다. 표기가 곧 속성이고, 승급·강등은 그냥 줄을 다시 쓰는 것. 마크다운 계획 파일은 이미 그렇게 생겼다 — 항목의 속성은 "어느 섹션에 있냐"(다음/마일스톤/이슈/한 일)가 결정하고, 이슈였던 줄을 마일스톤 밑으로 옮기면 그게 승급이다. 스키마 변경 0.

빠진 건 흐릿한 날짜뿐이어서, 날짜가 3정밀이 됐다:

• @2026-08-05 — 확정 (캘린더 칸에)
• @2026-W32 — "이 주 안에" (주간 목표 줄에)
• @2026-09 — "이 달 쯤" (불렛저널 퓨처로그 — 월간 화면 "이 달 중" 줄에)

날짜가 확정되면 그 줄의 날짜만 고쳐 쓴다. 그럼 항목이 퓨처로그에서 캘린더 칸으로 스스로 내려온다.

"ORG 모드가 대체 어디까지 할 수 있는 거야?" — 기능이 다 있어서 위험했다

문법이 잡히니 욕심이 났다:

작업 기한이나 반복 빈도, 중요도, 어려운 거 쉬운 거, 작업의 속성 같은 것도
설정할 수가 있나? 지금 ORG 모드에 그런 게 있어?
ORG 모드가 대체 어디까지 할 수 있는 거야?

답: 전부 있다. 마감과 시작일 구분, 우선순위 3단계, 반복 3종, 예상 소요시간, 임의 속성, 실제 걸린 시간 측정, 진행률 자동 갱신까지 — 20년 살아남은 이유가 있다.

그래서 위험했다. AI가 바로 경고를 붙였다: "다 넣자는 함정이야. org-mode 쓰는 사람들도 대부분 우선순위랑 마감만 쓰고, 나머지 속성은 처음에 신나서 설정했다가 안 본다." 심사 기준은 하나 — 그 속성이 화면을 바꾸느냐. 화면이 안 바뀌는 속성은 적는 수고만 늘린다.

그 기준으로 심사한 결과:

• 통과: 우선순위 !(중요)·!!(꼭) — 붙이면 목록 맨 위로 올라오고, 달력 칸에 한 줄만 보일 때도 우선순위 붙은 게 먼저 뽑힌다. 화면이 바뀐다.
• 보류: 예상 시간(~30분) — "시간이 애매하게 빌 때 대시보드를 여는가"가 실제로 확인되면 그때. 지금 넣으면 적는 습관만 새로 생긴다.

됐는지 확인한 방법: 실제 항목 두 개에 !를 붙여 목록 맨 위로 올라오고 배지가 뜨는 것까지 렌더 확인 후 채택.

AI가 분류하다 틀렸다 — "폴더 = 카테고리"의 탄생 ★이날의 하이라이트

표준이 생기고 몇 시간 뒤, 첫 사고가 났다. AI한테 새 할 일을 계획 파일에 넣으라고 했더니 어쩐지 아무 데나 쌓는 느낌이 들었다:

근데 거기다가 그냥 또 막 있는 그대로 넣고 있는 거 아니지? 카테고리가 있잖아.

점검해보니 진짜였다. 같은 할 일이 두 계획 파일에 중복으로 들어가 있었다. 원인은 AI의 분류 방식 — "이건 시스템 얘기니까 시스템 쪽에"라고 성격으로 추론해서 넣은 것. 그 항목은 실제로는 대시보드 화면 코드 일이었다.

그래서 규칙을 내가 냈다:

어떤 작업을 하면 그 작업에 관련된 폴더가 있을 거 아니야.
그 폴더가 그 작업의 상위 카테고리라고 할 수 있잖아.
그렇게 하면 카테고리 정하는 게 어렵지 않지 않을까?

AI의 반응: "훨씬 나은 기준이야. 내가 '추상적으로 무슨 성격인가'로 판단해서 틀린 거거든. 폴더로 봤으면 안 틀렸어."

이게 이 글의 제목이 된 순간이다. AI는 추론을 잘하지만, 추론은 틀릴 수 있다. 판단이 필요한 규칙을 눈으로 보면 아는 규칙으로 바꾸면, AI가 고민하다 틀릴 여지 자체가 사라진다. "이 일의 파일이 어느 폴더에 사나"는 고민할 게 없다 — 보면 안다. 애매하면 인박스(분류 전 대기석)에 두고 추측 분류를 금지했다.

됐는지 확인한 방법: 규칙 교체 후 계획 파일 9개 전수 대조로 중복이 그 1건뿐임을 확인, 규칙은 AI가 매 세션 읽는 규칙 파일에 반영.

보너스 사고 — 표준을 만들어도 화석은 생긴다

같은 날 저녁, 또 하나 걸렸다:

2주차 콘텐츠 이미 제작해서 공개까지 했는데, 지금 왜 이거 업데이트가 안 됐어?
이런 것들이 많아?

전수 점검 결과 낡은 항목 1건, 중복 1건. 원인은 AI가 계획 파일 9개를 처음 만들 때 옛 문서의 문장을 그대로 옮기면서 최신인지 검증을 건너뛴 것. 옮겨 적을 땐 맞았던 문장이 그날 내가 작업을 끝내면서 죽은 문장이 됐다. 재발 방지로 저장 루틴에 "낡음 점검"이 들어갔다 — 날짜가 지났는데 미완료인 항목을 저장할 때마다 훑어서 나한테 묻는다. AI가 짐작으로 완료 처리하는 건 금지 — 끝났는지는 나만 안다.

✅ 결과 (After)

Before vs After

결과물 — 문법 치트시트

## 다음 / ## 마일스톤 / ## 이슈 / ## 한 일   ← 섹션 4칸 고정 (위치가 곧 속성)

- [ ] 3주차 검토 후 공개 @2026-08-05 !!     ← 확정 날짜 + "꼭"
- [ ] 전자책 표지 다듬기 @2026-W32          ← "이 주 안에"
- [ ] 다음 기수 모집 공고 @2026-09          ← "이 달 쯤" (퓨처로그)
- [x] 2주차 공개 @2026-07-30               ← 완료 → "한 일"로 줄 이동
- [-] 접은 항목                             ← 안 하기로 한 것 (지우지 않고 접기)
- 체크박스 없는 줄은 메모                    ← 집계에서 제외

이게 전부다. 이 문법만 지키면 각 폴더의 계획 파일이 대시보드에서 캘린더·주간·월간·로드맵으로 조립된다.

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

효과적이었던 것

1. "안 쓰게 될 것 같다"는 직감을 바로 말한다. 그럴듯한 양식일수록 위험하다. 내 걱정 한마디("떨렁 있으면 안 쓰게 된다")가 파일 하나를 없애고 자동 조립 설계를 끌어냈다.
2. 새 속성은 "화면을 바꾸나?"로 심사시킨다. 기능 욕심이 날 때마다 이 질문 하나로 거른다. 화면 안 바뀌는 속성 = 적는 수고.
3. AI가 반복해서 틀리면, 더 잘하라고 하지 말고 판단을 없앤다. 추론 규칙("성격으로 분류")을 관찰 규칙("파일이 사는 폴더")으로 바꾸면 틀릴 여지가 사라진다.

이렇게 하면 안 돼요

1. AI가 만들어준 양식을 그대로 받기. AI는 그럴듯한 양식을 잘 만든다. 그런데 그 양식을 채우며 사는 건 나다. "이거 내가 진짜 쓸까?"를 양식이 생기기 전에 물어야 한다.
2. 옛 문서에서 값을 옮길 때 검증 생략. 옮길 땐 맞았던 문장이 오늘 죽은 문장일 수 있다. 표준을 새로 만들 때가 화석이 제일 많이 생기는 순간이다.

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

• 팀 업무 분류: "이 업무 누구 담당?"을 성격으로 토론하지 말고 "결과물이 어느 팀 폴더에 사나"로 — 판단을 관찰로
• 가계부·자료 정리: 카테고리 고민이 길어지는 시스템은 오래 못 간다. 애매하면 인박스에 던지고 나중에 분류가 규칙
• 회사 보고 양식: 필드를 늘리기 전에 "이 칸이 실제로 어느 화면·보고서를 바꾸나"부터

🚀 앞으로의 계획

• 3편 — 클릭조차 안 하는 루틴: "파일이 있으면 한 거다" (자동 판정 이야기)
• 4편 — 하루 종일 일했는데 로드맵이 0%인 이유 (측정의 원리)
• 5편 — 마크다운이 관제탑 화면이 되기까지
• 종합편 — 전체 설계도 + 따라하기 치트시트

📋 재사용 가능한 프롬프트

프롬프트 1: 계획 문법 도입

내 프로젝트 폴더마다 계획.md를 만들어줘. 규칙: ① 섹션 4개 고정 — 다음 / 마일스톤 / 이슈 / 한 일. 항목의 속성은 필드가 아니라 어느 섹션에 있느냐로 표현하고, 승급·강등은 줄 옮기기로. ② 날짜는 3정밀 — @YYYY-MM-DD(확정) / @YYYY-Wnn(이 주 안) / @YYYY-MM(이 달 쯤). ③ 우선순위는 !(중요)·!!(꼭) 두 개만. ④ 주간·월간 목표 파일은 만들지 마 — 날짜 붙은 항목이 곧 그 기간의 목표야. 할 일을 어디 넣을지는 성격으로 추론하지 말고 그 일의 파일이 사는 폴더로 정해. 애매하면 인박스 파일에 넣고 나한테 물어봐.

프롬프트 2: 속성 추가 심사

내가 계획 관리에 새 속성(태그·난이도·예상시간 등)을 추가하고 싶다고 하면, 바로 만들지 말고 이 기준으로 심사해줘: "이 속성이 실제로 화면(정렬·필터·표시)을 바꾸는가?" 바꾸지 않으면 "적는 수고만 는다"고 반대해줘. 바꾸더라도 지금 필요가 실측된 게 아니면 "필요가 확인되면 그때"로 보류를 제안해줘.

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

📝 한줄 요약

제목은 비유가 아니라 실화다. 이 글의 파일이 내 폴더에 저장되는 순간, 대시보드의 "사례글 루틴"이 기계 판정으로 완료된다 — 내가 체크하지 않는다. 이렇게 만든 이유는 하나다. 일지·루틴 시스템이 세 번 죽은 부검 결과, 죽은 것들의 공통점은 전부 "따로 실행해야 하는 것"이었기 때문이다.

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

• 일지 폴더는 완벽했다(일간·주간·월간 다 있음). 그런데 세 번 다 죽었다 — 구조가 아니라 실행 방식이 문제
• 부검 결론: 살아남은 기록은 전부 기존 작업 흐름에 붙어 있던 것, 죽은 기록은 전부 따로 열어서 해야 하는 것
• 그래서 루틴 판정을 뒤집었다 — 체크하는 게 아니라 감지되는 것. 그날 실물 파일이 있으면 완료
• 수동 체크는 몸으로 하는 것만 2~3개로 최소화 (안 그러면 네 번째 죽음)
• 수량형 루틴은 부분 달성이 그대로 남는다 — 팔굽혀펴기 100회 목표에 50회 한 날은 46%로 기록
• 화면에서 입력해도 기록은 전부 내 PC의 마크다운 파일에 — 대시보드를 버려도 기록은 남는다

🎯 이런 분들께 도움돼요

• 습관 앱·다이어리·일지 양식을 만들 때마다 며칠 쓰고 버려본 사람
• "기록 자동화"를 설계하다가 정작 기록을 멈춰본 사람
• AI·대시보드로 루틴을 관리하고 싶은데 체크하는 것도 일인 사람

😫 문제 상황 (Before)

내 일지 폴더는 구조만 보면 모범생이었다. 일간·주간·월간 폴더가 다 있고, 일지 스킬도 두 개나 만들어뒀고, 음성 일기 자동화까지 설계해뒀다.

실측을 해봤다. 일간 일지 27개 — 몇 주 전에 멈춤. 주간 일지 2개 — 작년 겨울에 멈춤. 월간 9개 — 작년 가을에 멈춤. 만들어둔 일지 도구들 — 전부 미사용. 세 번 시작했고 세 번 다 죽었다.

제일 아픈 건 이거다. 일간 일지가 멈춘 날짜와 "일지 자동화 설계" 문서를 쓴 날짜가 같은 날이었다. 자동화하겠다고 설계를 시작한 날, 손 기록도 같이 멈춘 것이다. 설계는 그 후로 잠들었고 기록은 돌아오지 않았다.

구조를 몰라서 죽은 게 아니었다. 그럼 뭐가 문제였을까.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus 5 / Claude Fable 5
• 특이사항: 예시의 루틴 이름은 일반화했다 — 구조는 실화 그대로

🔧 작업 과정

부검 — "죽은 건 전부 '따로 실행해야 하는 것'이었다" ★이 시리즈 전체의 뿌리

대시보드에 루틴을 붙이기 전에, AI한테 과거 일지 시스템의 사망 원인부터 조사시켰다. 폴더와 파일 날짜를 전수 실측한 결과, 선명한 패턴이 나왔다:

살아남은 기록 — 작업 세션을 마칠 때마다 도는 저장 루틴에 붙어 있는 것들(작업 로그, 발행 동기화, 건강검진). 내가 기억하지 않아도 세이브만 하면 따라온다.

죽은 기록 — 일간·주간·월간 일지, 일지 스킬 전부. 공통점은 하나. 따로 열어서, 따로 실행해야 하는 것.

결론은 한 문장이 됐다: "사람이 기억해야 유지되는 건 썩는다. 구조가 대신 기억하는 것만 남는다." 내가 게을러서가 아니라, "기억해서 실행"이라는 방식 자체가 썩는 구조였던 것이다.

그래서 이번 결정의 방향이 정해졌다 — 네 번째 일지 도구를 만들지 않는다. 대신 판정을 사람에서 기계로 넘긴다.

클릭조차 없앤다 — "파일이 있으면 한 거다"

루틴 파일은 한 곳에만 둔다(반복은 특정 프로젝트가 아니라 삶 전체의 것이라서). 정의는 표 한 줄이다 — 루틴 이름, 주기, 목표, 그리고 판정 방식:

| 루틴       | 주기            | 목표   | 판정        |
|-----------|----------------|-------|------------|
| 글쓰기     | 주1             |       | 자동: 글 파일 |
| 달리기     | 월수금          | 5km   | 수동        |
| 팔굽혀펴기 | 매일            | 100회 | 수동        |
| 챌린지 기록 | 매일~2026-08-31 |       | 수동        |

핵심은 판정 열이다. 자동:이 붙은 루틴은 그날 그 실물 파일이 존재하면 기계가 완료로 판정한다. 글쓰기 루틴이면 오늘 날짜로 글 파일이 생겼는지를 검사한다. 내가 대시보드를 열 필요도, 체크할 필요도 없다. 부검 결론을 그대로 뒤집어 심은 것이다 — 기록의 사인(死因)이 "따로 실행"이었으니, 실행 자체를 없앴다.

수동 판정은 몸으로 하는 것(운동 같은 것)만 남기고, 그마저 2~3개로 시작하기로 했다. AI가 리스크도 정직하게 고지했다 — "대시보드를 매일 안 열면 수동 루틴은 또 죽는다." 맞는 말이라 욕심을 버렸다.

부가 문법 둘: 주기는 매일·월수금·주3(요일 안 정함)처럼 쓰고, 끝나는 루틴은 매일~2026-08-31처럼 종료일을 붙이면 그날 지나 저절로 빠진다 — 죽은 루틴이 목록에 쌓이지 않는다.

"세이브가 왜 루틴에 들어가 있는 거야?" — 목록 오염 잡기

첫 화면을 보다가 이상한 걸 발견했다:

세이브가 왜 루틴에 들어가 있는 거야? 저거는 빼도 될 거 같고,
지금 내가 하고 있는 루틴은 두세 개 정도고 아직 다른 루틴은 안 하고 있어.

AI가 기능 시연용으로 넣어둔 예시가 루틴 목록을 오염시키고 있었다. 세이브는 작업 흐름이지 내가 관리할 습관이 아니다. 바로 걷어냈다.

작지만 중요한 원칙이 여기서 나왔다 — 루틴 목록은 "되고 싶은 나"가 아니라 "실제 하는 것"만. 습관 앱이 죽는 이유 중 하나가 첫날에 이상적인 루틴 10개를 등록하는 것이다. 목록이 현실과 어긋나는 순간 화면 전체가 거짓말이 되고, 거짓말이 된 화면은 안 열게 된다.

"얼마나 했는지가 기록돼야지" — 수량형 루틴

했다/안 했다 체크만으로는 부족한 루틴이 있다:

얼마를 했는지 카운트되는 숫자를 넣어야 되는데… 어떤 루틴은 횟수,
몇 키로를 달렸는지, 단위가 있잖아. 우리 org모드에서 그런 게 구현이 가능할까?
아니면 이거는 코드로 작업을 하는 걸까?

AI의 답: org-mode에도 있는 기능이다(습관 반복 스케줄과 수량 기록). 다만 우리는 org-mode 프로그램을 안 쓰고 패턴만 빌리니, 문법은 우리가 정하고 파서와 화면은 코드로 만든다.

결과 — 목표 칸에 100회처럼 숫자+단위를 쓰면 수량형이 된다. 팔굽혀펴기 100회 목표인 날 50회만 했으면 50을 입력하고, 그날은 46% 달성으로 남는다. 전부 아니면 무(無)가 아니라 실제 노력만큼 기록되는 것 — 그날 달력의 링도 그만큼만 채워진다. 단위는 5km, 30분, 2L 뭐든 된다.

됐는지 확인한 방법: 입력 → 목표치 → 지우기를 실제 호출로 왕복시켜서 기록 줄이 정확히 바뀌고 다른 항목은 1바이트도 안 변하는 것 확인.

"그거 적으면 내 PC 파일에 기록돼?" — 파일이 정본이라는 감각

대시보드에서 숫자를 입력하다가 문득 물었다:

여기 사이트에서 내가 몇 회 했는지 적으면, 그게 실제 내 PC의 기록 파일에 들어가?

답: 들어간다. 브라우저 입력 → 내 컴퓨터의 로컬 서버 → 루틴 파일의 기록 줄이 직접 수정된다. 중간에 데이터베이스도 클라우드도 없다. 기록 줄은 이렇게 생겼다:

- 2026-08-03: 달리기 5, 팔굽혀펴기 50

이게 전부다. 대시보드를 통째로 버려도 내 기록은 마크다운 파일로 남는다. 습관 앱을 갈아탈 때마다 기록이 앱과 함께 증발했던 것과 정반대다. 이어서 하나 더 물었다 — "웹에 배포한 다음에 거기서 입력해도 내 PC에 들어와?" 답은 아니오. 관리 화면은 의도적으로 내 컴퓨터에서만 열린다(배포판에선 404). 비공개 정보 보안 때문이고, 폰 입력은 폰이 내 PC로 접속하는 터널 방식이 미래 과제로 남았다.

그리고 이 글 — 자동 판정의 첫 확장

여기까지가 루틴 시스템이 만들어진 날의 이야기다. 며칠 뒤 자동 판정이 처음 확장됐다 — 글쓰기(사례글) 루틴에 자동: 판정이 붙었다. 그날 사례글 파일이 폴더에 생겼으면, 글쓰기 루틴은 완료다.

그러니까 제목은 문자 그대로다. 지금 이 글이 내 폴더에 저장되는 순간, 오늘의 사례글 루틴은 사람 손 없이 완료 판정된다. 심지어 이 시리즈 전체(목표 편수)도 같은 방식으로 자동 측정되고 있는데, 그 이야기는 다음 편(측정)에서.

✅ 결과 (After)

Before vs After

결과물

루틴 정의 표 + 날짜별 기록이 든 마크다운 파일 하나. 대시보드는 그걸 읽어 오늘의 루틴 위젯, 달력의 달성 링, 연속 기록을 그린다 — 그리고 자동 루틴은 내가 안 열어도 스스로 채워진다.

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

효과적이었던 것

1. 새 시스템을 만들기 전에 죽은 시스템을 부검시킨다. "왜 안 썼을까"를 감정이 아니라 실측(파일 날짜 전수 조사)으로 — 사인이 나오면 설계 방향은 저절로 정해진다.
2. 판정을 "존재 증명"으로 바꾼다. "했나요?"라고 묻는 시스템은 죽는다. 행동의 부산물(파일·커밋·기록)이 이미 존재한다면, 그걸 감지하게 하면 판정이 공짜다.
3. AI가 예시로 넣은 것도 의심한다. 시연용 데이터가 실데이터 자리에 남으면 화면이 거짓말을 시작한다. "이거 왜 있어?"를 묻는 건 사용자만 할 수 있다.

이렇게 하면 안 돼요

1. 자동화 설계로 기록을 대체하기. 내 일간 일지는 자동화를 설계한 날 멈췄다. 설계는 실행이 아니다 — 완벽한 자동화 계획보다 오늘의 한 줄이 낫다.
2. 첫날에 루틴 10개 등록하기. 목록이 현실과 어긋나는 순간 화면 전체가 거짓말이 된다. 실제 하는 것 2~3개로 시작하고, 자동 감지할 수 있는 것부터 늘린다.

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

• 팀 업무 보고: "주간보고 썼나요?" 대신 보고 파일 존재를 감지 — 리마인더가 아니라 감지기
• 공부 인증: 스터디 인증을 채팅 캡처 대신 그날 커밋·노트 파일 존재로
• 운동 기록: 수량형(몇 회·몇 km) 부분 달성 기록은 어떤 습관 관리에도 이식 가능

🚀 앞으로의 계획

• 4편 — 하루 종일 일했는데 로드맵이 0%인 이유 (측정의 원리)
• 5편 — 마크다운이 관제탑 화면이 되기까지
• 종합편 — 전체 설계도 + 따라하기 치트시트

📋 재사용 가능한 프롬프트

프롬프트 1: 죽은 습관 시스템 부검

내가 예전에 쓰다 만 기록·습관 시스템들을 부검해줘. [폴더/앱 목록]을 보고 각각 마지막 기록 날짜를 실측해서, "살아남은 것"과 "죽은 것"의 공통점을 찾아줘. 감정적 이유(게으름·의지)는 금지 — 구조적 이유(실행 방식·위치·트리거)만. 결론은 "다음 시스템이 지켜야 할 원칙 한 문장"으로.

프롬프트 2: 자동 감지 루틴 설계

내 루틴 목록: [루틴들]. 각 루틴에 대해 "이 행동을 하면 자연히 남는 부산물(파일·커밋·기록)이 있나?"를 검토해줘. 부산물이 있는 루틴은 그 존재를 감지해서 자동 완료 처리하는 방법을 설계하고, 부산물이 없는 것만 수동 체크로 남겨줘. 수동이 3개를 넘으면 경고해줘. 판정 원칙: "사람이 기억해야 유지되는 건 썩는다."

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

📝 한줄 요약

로드맵을 만들었는데 숫자가 안 움직였다. 하루 종일 일한 날도 0%. 나흘에 걸쳐 범인 넷을 잡고 나니 결론은 이랬다 — 진행률은 프로젝트가 아니라 조건의 충족률로 세고, 끝나지 않는 목표는 %가 아니라 레벨로 센다. 그렇게 만든 구조가 알고 보니 AI 업계에서 말하는 루프 엔지니어링과 같은 모양이었다.

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

• 하루 종일 일했는데 로드맵이 0%인 건 게으름이 아니라 측정 설계 버그다
• 범인 ① 층 섞임: 마일스톤의 집은 프로젝트가 아니라 비즈니스 모델(BM) 층이었다
• 범인 ② %의 저주: 성장하는 목표는 분모가 계속 커져서 100%가 영원히 안 온다 → RPG처럼 레벨로 센다
• 범인 ③ 엉뚱한 숫자: 조건을 자동 추론시켰더니 "강사 양성 2/5"가 실은 다른 프로젝트의 진행률이었다 → 진행률 = 조건 충족률
• 범인 ④ 완료를 딴 데로 옮기면 진행이 증발한다 → 완료도 마일스톤 밑에 남긴다
• 이 구조 = AI 업계의 루프 엔지니어링(목표·완료조건을 정하고 충족까지 돌리기)과 동형 — 비개발자의 직관이 업계 패턴과 만났다

🎯 이런 분들께 도움돼요

• 목표·로드맵을 세워도 "지금 몇 %인지" 답을 못 해본 사람
• 열심히 일한 날일수록 관리 화면이 허무했던 사람
• 게임에선 만렙 찍으면서 현실 목표는 측정 못 하는 게 억울한 사람

😫 문제 상황 (Before)

앞선 편들에서 로드맵 화면까지 만들었다. 전사 흐름부터 비즈니스 모델, 프로젝트, 세부 할 일까지 한 줄기로 내려오는 그림. 보기엔 그럴듯했다.

그런데 숫자가 안 움직였다. 스터디 운영하고, 강의 콘텐츠 만들고, 시스템 고치고 — 분명히 하루 종일 일했는데 로드맵의 진행률은 그대로였다. 어느 날 AI한테 따졌다:

난 지금 계속 일하고 있고, 과거에도 계속 일을 진행해 왔고,
거기에 대한 작업 기록이 다 있다면 진행된 거잖아. 근데 왜 로드맵은 그대로야?

내가 일을 안 한 게 아니다. 측정이 거짓말을 하고 있었다. 범인은 하나가 아니라 넷이었다.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus 5 / Claude Fable 5
• 특이사항: 나흘(7/30 밤~8/3)에 걸친 시행착오 — 실패해서 되돌린 설계도 그대로 담았다

🔧 작업 과정

범인 ① — 층이 섞여 있었다: "마일스톤은 BM의 것"

로드맵 뷰를 처음 펼쳐놓고 한참 보다가 깨달았다:

이렇게 로드맵 뷰를 보고 나니까 내가 왜 혼란스러웠는지 알 거 같아.
프로젝트를 로드맵의 가장 상단에다 놨잖아?

프로젝트가 꼭대기에 있으니 마일스톤이 프로젝트마다 흩어졌고, 같은 목표가 여기저기 조각나 있었다. 조금 더 들여다보다 진짜 구조가 보였다:

그건 일부 비즈니스 모델에 대한 마일스톤인 거고,
사실 그 비즈니스 모델마다의 마일스톤이 있는 거잖아.

마일스톤의 집은 프로젝트가 아니라 비즈니스 모델(BM) 층이었다. 그래서 층이 4개로 확정됐다 — 계절(방향) → BM(마일스톤이 사는 곳) → 프로젝트(단계를 미는 실행체) → 세부 할 일. 프로젝트 하나가 여러 단계를 동시에 밀 수도 있다(다대다). 스터디 하나가 "사람 모으기"와 "강사 양성"을 같이 미는 게 현실이니까.

중간에 실패도 있었다. 한 단계를 다르게 재구성해봤다가 "진 거 같아, 이전 꼴로 돌려"라고 되돌린 날도 있다. 층 정리는 한 방이 아니라 실물을 보면서 다듬는 과정이었다.

범인 ② — %의 저주: "마일스톤 자체가 레벨 아니야?" ★제목의 순간

층을 정리해도 이상한 게 남았다. 어떤 목표는 아무리 해도 %가 안 찼다. 이유는 단순했다 — 살아있는 목표는 분모가 계속 커진다. 일을 할수록 할 일이 늘어나니, 100%는 영원히 안 온다. 화면엔 늘 "진행률 낮음"만 떴다. 열심히 살수록 초라해지는 숫자.

그러다 게이머의 직감이 발동했다:

강의 같은 경우에는 이 마일스톤 자체가 일종의 레벨 아니야?
하나하나씩 깨가는 거잖아. 그 레벨 안에 레벨이 더 들어있을 수도 있지 않나?

이게 레벨제의 탄생이다. 완료가 아니라 성숙하는 목표는 %를 버리고 레벨로 센다 — "Lv1 첫 기수 완주 → Lv2 누적 참여 100명 → …"처럼. 깬 레벨은 배지로 남고, 화면엔 "지금 레벨"만 크게 뜬다. RPG에서 만렙까지 몇 %냐고 안 묻는 것과 같다. 지금 몇 레벨이고, 다음 레벨 조건이 뭔지만 물으면 된다.

단, 선은 그었다 — 경험치·포인트는 안 만든다. 점수를 매기고 유지하는 것 자체가 새 일이 되기 때문이다. 측정은 체크박스·수량·집계로 충분하다. 게임에서 가져올 건 레벨이라는 프레임이지, 게임화(gamification)의 장식이 아니다.

범인 ③ — 엉뚱한 숫자: 진행률 = 조건 충족률

세 번째 범인이 제일 교묘했다. 단계의 진행률을 "그 단계를 미는 프로젝트의 진행률"에서 자동으로 가져오게 했더니, 그럴듯한 숫자가 떴다. 예를 들어 "강사 양성 2/5".

그런데 까보니 그 2/5는 스터디 프로젝트 전체의 진행률이었다. 스터디 안에는 강사 양성 말고도 온갖 일이 들어 있다. 즉 화면의 숫자는 진짜였지만, 엉뚱한 것을 세고 있었다. 이런 숫자가 제일 위험하다 — 틀린 게 티가 안 나니까.

해법은 도출을 폐지하고 원리를 세우는 것이었다:

자동으로 판정할 수 있는 건 자동으로 판정하고,
수동으로 할 수 있는 건 수동으로 내가 하면 되는 거야.
"아, 이건 내가 봤을 때 완료했어" — 체크.

단계 진행률 = 그 단계 밑에 직접 적은 조건들의 충족률. 남의 프로젝트에서 숫자를 빌려오지 않는다. "1기 완주", "협업 문의 3건"처럼 그 단계를 깨는 조건을 직접 적고, 그 조건이 몇 개 찼는지만 센다. 숫자 하나가 무엇을 세는지 말할 수 있어야 측정이다.

됐는지 확인한 방법: 도출 폐지 후 각 단계의 분모가 "직접 적은 조건 개수"와 정확히 일치하는지 실측. 엉뚱한 2/5는 사라졌다.

범인 ④ — 완료를 옮기면 진행이 증발한다

마지막 범인은 관습이었다. 끝난 항목을 "한 일" 섹션으로 옮겨서 정리하는 습관 — 깔끔해 보이지만, 마일스톤 밑에서 완료를 빼가면 그 마일스톤은 영원히 0%다. 하루 종일 일해도 로드맵이 안 움직인 직접적 원인이 이거였다. 그래서 규칙을 뒤집었다: 조건은 완료해도 마일스톤 밑에 [x]로 남긴다. 완료가 쌓이는 게 보여야 진행이다.

같은 맥락에서 이런 대화도 있었다:

커밋 수만 세서 뭐하게. 그 커밋이 어떤 로드맵의 어떤 프로젝트에
어떤 할 일이 완료된 건지 알아야 어떻게 진행되고 있는지 알지 않아?

활동량(커밋 수·작업 로그 개수)은 측정이 아니다. 어느 목표의 어느 조건이 찼는지에 연결돼야 측정이다. 그래서 "활동 피드" 류의 화면은 만들었다가 지웠다 — 있어도 체크가 안 되는 화면은 장식이니까.

그리고 발견 — "이거 루프 엔지니어링이랑 같은 구조 아니야?" ★이 글의 피크

측정 원리가 잡혀갈 때쯤, 문득 익숙한 그림이 떠올랐다. 먼저 게임으로:

MMORPG 게임 같은 경우에는 전체적인 시나리오가 있고,
그거에 대한 메인퀘스트·서브퀘스트가 있고…

전사 아크(시나리오) → BM 단계(메인퀘스트) → 조건(퀘스트 완료 조건). 그리고 한 발 더:

요새 하는 루프 엔지니어링으로 골 설정해놓고, AI가 그 완료 조건을
완성할 때까지 계속 일을 할 수 있게 전체적인 워크플로우랑 조건 같은 걸…

AI한테 조사를 시켰더니 답이 왔다 — 맞다. AI 에이전트 업계에서 말하는 루프 엔지니어링(목표와 완료 조건을 명시하고, 충족될 때까지 에이전트가 반복 작업하게 하는 패턴)과 내 로드맵 구조가 동형이었다. 단계 = 골, 조건 = 완료 판정, 프로젝트 = 실행 루프.

이 시리즈 1편에서 나는 20년 된 org-mode에서 원리를 훔쳤다. 그런데 나흘을 파고들어 도착한 곳은 최신 AI 패턴이었다. 좋은 구조는 시대를 안 가리고 같은 모양으로 수렴한다는 걸, 비개발자의 직관으로 한 바퀴 돌아 확인한 셈이다. 이 발견의 실용적 결론이 다음 규칙이다 — 기계가 셀 수 있는 조건은 사람이 체크하지 않는다. 조건 꼬리에 자동 판정을 붙이면(예: 글 편수 세기) 기계가 실측 배지를 띄운다. 지금 이 시리즈도 "12편"이라는 조건에 자동 판정이 붙어 있어서, 이 글이 저장되면 실측이 10/12로 올라간다.

마무리 문법 — 조건은 착수할 때 적는다

측정 욕심이 나면 모든 단계에 조건을 미리 다 적고 싶어진다. 그것도 함정이었다:

아직 시작 안 한 거는 조건을 아직 안 적어도 되지 않을까 싶어.
다음 계획을 진행할 때, 그때 단계가 필요하니까.

불렛저널 원리 그대로 — 탑다운은 단계 이름 한 줄까지만, 완료 조건은 착수할 때 적는다. 시작도 안 한 단계에 조건을 깔아두는 건 미래를 양식으로 채우는 일이고, 그 양식은 반드시 낡는다.

✅ 결과 (After)

Before vs After

결과물

전사 아크 → BM 레벨 → 조건 충족률로 내려오는 로드맵. 이제 "지금 몇 레벨이고 다음 레벨까지 뭐가 남았나"에 화면이 대답한다.

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

효과적이었던 것

1. 게이머의 직관을 설계 언어로 쓴다. "이거 레벨 아니야?", "메인퀘스트 같은데?"가 그대로 스펙이 됐다. 내가 이미 통달한 시스템(게임)의 어휘는 훌륭한 설계 도구다.
2. 숫자를 보면 "이거 무엇의 숫자야?"부터 묻는다. 그럴듯한 %가 제일 위험하다. AI가 만든 지표는 출처(무엇을 셌는지)를 꼭 추궁한다.
3. 내 방식이 이미 있는 패턴인지 조사시킨다. "이거 요새 말하는 ○○랑 같은 구조 아니야?"라고 물으면, AI가 업계 선례와 대조해준다. 맞으면 확신이, 다르면 배울 게 나온다.

이렇게 하면 안 돼요

1. 활동량을 진행률로 착각하기. 커밋 수·기록 개수는 "일했다"의 증거지 "나아갔다"의 증거가 아니다. 목표의 조건에 연결 안 되는 측정은 장식이다.
2. 경험치·포인트 시스템 만들기. 게임화 욕심은 점수 유지라는 새 일을 만든다. 프레임(레벨)만 빌리고 장식(XP)은 버린다.
3. 시작 안 한 단계까지 조건 미리 채우기. 미래를 양식으로 채우면 그 양식이 낡아서 거짓말을 시작한다.

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

• 다이어트·운동: "몸무게 %"가 아니라 레벨(5km 완주 → 10km → 하프)로 — 분모가 변하는 목표엔 전부 통함
• 팀 OKR: 진행률을 팀 활동량에서 도출하지 말고, KR(조건) 충족 개수로만 — 엉뚱한 숫자 방지
• 공부: "교재 진도율" 대신 "이 레벨을 깨는 조건"(모의고사 몇 점, 문제집 1권)으로

🚀 앞으로의 계획

• 5편 — 마크다운이 관제탑 화면이 되기까지 (블록 조립·뷰들)
• 종합편 — 전체 설계도 + 따라하기 치트시트

📋 재사용 가능한 프롬프트

프롬프트 1: 측정 설계 점검

내 목표·로드맵 구조를 점검해줘. 기준 4개: ① 각 진행률 숫자가 "무엇을 세는지" 한 문장으로 말할 수 있나? (남의 진행률을 빌려오면 실격) ② 분모가 계속 커지는 성장형 목표에 %를 쓰고 있진 않나? → 레벨제(Lv1·Lv2…)로 바꿔줘 ③ 완료된 항목이 목표 밑에서 사라지고 있진 않나? → 완료도 그 자리에 남겨서 쌓이게 ④ 시작 안 한 단계에 조건을 미리 채워놓지 않았나? → 착수할 때 적게 지워줘

프롬프트 2: 내 직관, 업계 패턴 대조

내가 쓰는 방식: [내 방식 설명 — 예: 목표마다 완료 조건을 적고 찰 때까지 반복]. 이게 이미 검증된 업계 패턴·방법론과 같은 구조인지 조사해줘. 같다면 그 패턴의 이름과, 그쪽 동네에서 배울 수 있는 것 2~3개를, 다르다면 어디가 다르고 그 차이가 위험한지 알려줘.

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

📝 한줄 요약

대시보드를 만들고 나서도 나는 세 번이나 "여전히 눈에 안 들어온다"고 말했다. 그때마다 범인이 달랐다 — 처음엔 그리는 방식(도넛·색), 다음엔 소스(옛 문서의 덤프), 다음엔 뷰(통째로 뿌리기). 그리고 마지막 진짜 범인은 정보량이 아니라, 한 화면에 여러 질문이 섞여 있던 것. 장(페이지)마다 질문을 하나씩만 주니 끝났다 — 오늘(뭐 하지), 계기판(목표가 움직이나), 시나리오(어디까지 왔나), 서랍(자산).

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

• 화면 구성조차 마크다운 파일이다 — 한 줄=블록, 줄 순서=화면. 노션처럼 뷰를 쌓는데 개발이 필요 없다
• "파이 그래프 말고 직선" — 비전문가의 감각이 시각화 원칙과 정확히 일치했다. 도넛 전면 폐지
• "있어도 체크 안 하는 화면은 지워라" — 활동 피드처럼 그럴듯한 블록이 제일 먼저 죽었다
• 안 보이면 소스와 뷰를 둘 다 의심하라 — 같은 증상인데 범인이 반대인 사건이 이틀 간격으로 있었다
• 최종 해법은 빼기도 더하기도 아닌 분리 — 한 장에 질문 하나
• 실사용 데이터를 넣자마자 잠복 버그 2건이 바로 나왔다 — 데모 데이터는 테스트가 아니다

🎯 이런 분들께 도움돼요

• 대시보드·관리 화면을 만들었는데 정작 안 열게 되는 사람
• 노션 대시보드에 위젯을 더할수록 복잡해지는 경험을 한 사람
• "정리를 잘하면 보이겠지"라며 정보를 계속 다듬고 있는 사람

😫 문제 상황 (Before)

앞선 편들에서 다 만들었다. 파일이 진실(1편), 계획 문법(2편), 자동 감지 루틴(3편), 측정 원리(4편)까지. 재료는 완벽했다.

그런데 화면 앞에서 자꾸 같은 말을 했다. "여전히 눈에 안 들어온다." 한 번이 아니다. 나흘 동안 세 번을 말했다. 정보는 다 있는데 읽히지가 않았다. 데이터가 문제가 아니라면 뭐가 문제일까 — 이번 편은 그 범인을 세 번 갈아치운 기록이다.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus 5 / Claude Fable 5
• 특이사항: 화면 수리인데 코드보다 마크다운 편집이 더 많았다 (이유는 본문에)

🔧 작업 과정

화면 구성조차 마크다운 — 노션처럼 뷰 쌓기

시작은 멀티뷰 욕심이었다:

노션처럼 멀티뷰가 있으면 좋겠어. 갤러리라든지, 칸반도 한 계절만 보여준다든지…

탭 말고, 그 화면 하단에 대시보드를 하나 더 만들 수도 있잖아. 또 다른 뷰로.

AI의 해법이 이 시스템다웠다. 화면 구성의 정본도 마크다운 파일 한 장으로 — 대시보드.md. 한 줄이 블록 하나고, 줄의 위→아래 순서가 곧 화면이다. 달력 블록을 두 번 쓰면(주간+월간) 화면에 달력이 두 개 뜬다. 섹션 제목을 나누면 그때만 상단 탭이 생긴다. 블록 순서를 바꾸고 싶으면 화면의 화살표를 눌러도 되고, 파일에서 줄을 옮겨도 되고, AI한테 "달력을 위로"라고 말해도 된다 — 셋 다 같은 파일을 고치는 것이니까.

이게 왜 중요하냐면, 이후의 모든 화면 실험이 개발 없이 가능해졌기 때문이다. 이 편 마지막의 대개편도 이 파일 편집만으로 했다.

"파이 그래프 말고 직선" — 비전문가의 감각을 믿어라

두 번째 불만은 생김새였다:

여전히 정신없고 한눈에 안 들어와. 글자도 작고 색도 별로야.
파이 그래프 말고 직선 같은 게 나은 데도 있잖아.

AI가 데이터 시각화 원칙 문서와 대조해보더니 — 내 감각이 교과서와 일치했다. "단일 비율을 두 조각 파이로 그리지 마라, 가는 미터 바로 그려라." 그래서 화면의 도넛 링을 전면 폐지하고(92곳을 미터로), 색도 다이어트했다 — 의미 있는 색만(소속을 나타내는 계절 5색 + 완료/진행/밀림 상태색), 장식색은 전부 잉크색으로.

진행 방식도 배울 점이었다. 전체를 한 번에 다시 칠하지 않고, 블록 하나만 시안으로 만들어 승인받은 뒤 전체 적용. 시각 판단은 결국 사람 몫이라, AI가 크게 그려놓고 "어때?"를 반복하면 서로 지친다.

"있어도 체크 안 하는 화면은 지워" — 다이어트

세 번째 라운드는 빼기였다:

대시보드라고 하지만 잘 눈에는 안 들어오거든.
내가 생각하기에는 너무 많은 것들이 보여서 그런 거 같아.

활동 섹션 그냥 지워. 있어도 어차피 체크가 되지 않아.

작업 이력을 시간축으로 보여주는 활동 피드 — 만들 땐 그럴듯했지만 실제론 한 번도 안 봤다. 삭제. 로드맵에 붙어 있던 프로젝트 카드들 — 로드맵은 흐름을 보는 화면이지 프로젝트 목록이 아니다. 전면 제거. 여기서 원칙이 하나 굳었다: 뷰마다 자기 층 하나만 비춘다. 로드맵은 흐름만, 프로젝트는 갤러리 몫, 세부는 일간 뷰 몫.

같은 증상, 반대 범인 — 소스를 의심하고, 뷰를 의심하라

이 나흘의 백미는 이틀 간격으로 벌어진 두 사건이다. 증상은 똑같이 "화면이 지저분하다"인데:

사건 1 — 로드맵에 할 일이 카테고리도 없이 뭉텅이로 붙어 있었다. 화면 버그인 줄 알았는데, 범인은 소스였다. 옛 문서 하나가 폐기된 연결 기능으로 태스크 수십 개를 로드맵에 쏟아붓고 있었다. 화면은 시키는 대로 그렸을 뿐.

사건 2 — 월간 뷰가 글 벽이 됐다. 이번엔 내 작성 습관을 의심했다 — "애초에 내가 대중없이 낙서처럼 적는 건가?" 실측해보니 반대였다. 파일 항목들은 문법을 잘 지키고 있었고, 뷰가 항목 줄 전체를 통째로 뿌리고 있었다. 작성 습관 무죄, 뷰 유죄. 제목만 보여주고 전체는 툴팁으로 내리니 끝.

교훈: 화면이 이상할 때 "화면 고쳐줘"라고만 하면 절반은 헛다리다. 소스가 이상한 걸 화면이 정직하게 그린 건지, 소스는 멀쩡한데 화면이 뭉갠 건지 — 양쪽을 다 실측시켜야 진범이 나온다.

진짜 범인 — 정보량이 아니라 "한 장에 질문이 섞인 것" ★이 글의 피크

그렇게 고치고도 마지막 불만이 남았다:

다른 분들처럼 한 화면에 촥 보여졌으면 좋겠는데. 오늘 부분에서 내가 뭔가 체크하면
얼만큼 진행이 되는지 봤으면 좋겠는데. 정보를 너무 많이 넣어서 그런가?

"정보를 줄여야 하나?"가 내 가설이었는데, AI의 진단은 달랐다 — 정보량이 아니라, 한 장에 모든 질문이 섞여 있는 것. "오늘 뭐 하지?"를 보러 들어왔는데 로드맵 전체가 같이 떠 있으면, 답을 찾는 게 아니라 화면을 해석해야 한다. 게다가 탭 기능은 이미 있는데 안 쓰고 있었다.

그래서 대시보드를 4장으로 쪼갰다. 장(페이지) = 질문 하나:

• 오늘 — 지금 뭐 하지? (루틴·이번 주·인박스)
• 계기판 — 목표가 움직이고 있나? (목표 카드·실행 페이스)
• 시나리오 — 전체 이야기는 어디까지 왔나? (전사 아크 로드맵)
• 서랍 — 내 자산이 뭐가 있나? (갤러리·발행물)

이 대개편에 코드는 한 줄도 안 짰다 — 대시보드.md 편집이 전부. 그리고 계기판의 실행 카드엔 사전 경보를 달았다: 이번 달 누적과 페이스로 "이 속도면 월말 ~N"을 예측하고 순항/위험 뱃지를 띄운다. 마감이 지나서야 빨개지는 "밀림"은 사후 통보라 늦다 — 계기판은 미래를 보여줘야 계기판이다.

실사용이 최고의 테스트 — 그리고 뜻밖의 답

실제 내 루틴을 등록하자마자 잠복 버그 2건이 바로 나왔다. 주 N회형 루틴이 화면에 두 번 렌더되는 버그(매일 루틴만 있던 동안엔 안 보였던 것), 기간형 루틴에 체크 버튼이 아예 없던 버그. 데모 데이터로는 며칠을 써도 안 나왔을 것들이 실데이터 하루 만에 나왔다.

그리고 걱정 하나가 풀렸다:

다른 분들은 블로그 몇 편·쇼츠 몇 편, 실제 작업물을 카운팅하는데
난 학습일지나 사례글이라서 이렇게 해도 되나 싶어.

AI의 답 — 사례글이 곧 실제 작업물이다. 내 사업에선 글이 콘텐츠 퍼널의 1차 생산물이니, 남들의 "블로그 N편" 자리에 정확히 대응한다. 반복 생산물은 실행 카드(루틴)로, 단발 산출물은 월간 목표로. 그래서 지금 이 시리즈가 그 실행 카드에서 실시간으로 카운트되는 중이다 — 이 글이 다섯 번째 눈금이다.

✅ 결과 (After)

Before vs After

결과물

질문 4개에 각각 대답하는 4장짜리 관제탑. 화면 구성의 정본은 여전히 마크다운 파일이라, 내일 내 질문이 바뀌면 화면도 파일 편집만으로 따라온다.

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

효과적이었던 것

1. "안 보인다"를 부끄러워하지 않고 반복해서 말한다. 세 번 말할 때마다 다른 범인이 잡혔다. 한 번에 다 고쳐지는 화면은 없다.
2. 화면이 이상하면 소스·뷰 양쪽을 실측시킨다. "화면 고쳐줘" 대신 "소스가 이상한 거야, 화면이 뭉갠 거야? 실측해봐"라고 묻는다.
3. 디자인은 블록 하나 시안 → 승인 → 전체 적용. AI가 전체를 다시 칠하게 두면 서로 지친다. 미적 판단은 사람 몫으로 남긴다.
4. 실데이터를 최대한 빨리 넣는다. 데모 데이터는 테스트가 아니다 — 잠복 버그는 실사용 첫날에 나온다.

이렇게 하면 안 돼요

1. 안 보인다고 정보부터 줄이기. 내 마지막 가설("정보를 너무 많이 넣었나?")은 틀렸다. 정보량이 아니라 질문의 혼선이 범인일 수 있다 — 빼기 전에 "이 화면은 무슨 질문에 답하나"부터.
2. 그럴듯한 블록 방치하기. 활동 피드처럼 "있으면 좋을 것 같은" 화면은 한 번도 안 보게 된다. "이거 지난주에 봤나?"로 심판하고 지운다.

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

• 노션 대시보드 정리: 위젯을 더하기 전에 페이지마다 질문 하나를 정하고, 그 질문에 답 안 하는 위젯은 다른 페이지로
• 팀 주간회의 자료: 슬라이드 한 장 = 질문 하나(매출 움직였나 / 이번 주 뭐 하나) — 종합 현황판 한 장짜리보다 빨리 읽힘
• 보고서·리포트: "밀림" 사후 보고 대신 페이스 기반 사전 경보("이 속도면 월말 미달")로

🚀 앞으로의 계획

• 종합편 — 시리즈 전체 설계도 + 따라하기 치트시트 (다음 편이 마지막)

📋 재사용 가능한 프롬프트

프롬프트 1: 안 보이는 화면 진단

내 대시보드(또는 노션 페이지)가 눈에 안 들어와. "정보를 줄여줘"라고 하기 전에 순서대로 진단해줘: ① 이 화면이 답해야 할 질문이 몇 개야? 2개 이상이면 장을 분리해줘 (한 장 = 질문 하나) ② 지저분한 부분의 범인이 소스(데이터가 이상함)인지 뷰(멀쩡한 데이터를 뭉개서 보여줌)인지 실측해줘 ③ 최근 일주일간 내가 실제로 본 적 없는 블록을 찾아서 삭제 후보로 올려줘 디자인 변경은 블록 하나만 시안으로 먼저 보여주고 승인받은 뒤 전체 적용해줘.

프롬프트 2: 사전 경보 계기판

내 반복 목표([예: 글 주 1편, 운동 주 3회])에 사전 경보를 달아줘. 이번 달 누적과 남은 날짜로 "이 페이스면 월말 ~N"을 예측하고, 목표 대비 순항/위험/달성 뱃지를 붙여줘. 마감 지난 뒤의 "밀림" 표시는 사후 통보라 늦어 — 경보는 미래형이어야 해.

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

📝 한줄 요약

이건 6일짜리 프로젝트의 회고가 아니다. 몇 년 묵은 가설의 검증기다. 메모 앱 무덤에서 "차라리 전부 plain text로"를 외치다 org-mode라는 물건을 알게 됐던 게 오래전. AI 시대가 되자 세상이 마크다운으로 — 사실상 텍스트로 — 귀환했고, 잊고 있던 그 답이 돌아왔다. 가설은 이랬다: 텍스트에 다 적어두면, 화면은 뿌리기만 하면 된다. 6일 검증 결과 — 가설은 대체로 맞았고, 내가 아는 한 선례가 없는 조합이라 설계는 오래 걸렸고, 그래서 더 재미있었다.

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

• 출발은 메모 앱 무덤 — 리치텍스트·엑셀·앱마다 흩어진 메모, 갈아탈 때마다 증발. "차라리 plain text"가 org-mode로 이어진 옛 기억
• AI 시대 = 텍스트로의 귀환. 마크다운은 사실상 서식 있는 plain text — AI가 제일 잘 다루는 재료
• 가설: 색인(파일 위 정보칸)을 넘어 한 줄 한 줄에 태그(날짜·조건·상태)를 심으면, 대시보드는 뷰로 뿌리기만 하면 된다
• 검증: "이 화면 바꾸고 싶어" 하면 AI가 슉슉 바꾼다 — 자료는 이미 파일에 다 있어서, 보이는 것만 바꾸면 되니까
• 대가: org-mode를 웹 대시보드로 뿌리는 선례를 못 찾아 좌충우돌 — 개척은 설계가 오래 걸린다
• 다음 꿈: 각 잡고 만드는 게 아니라, AI로 일하면 저절로 만들어지는 인생 퀘스트 보드

🎯 이런 분들께 도움돼요

• 메모 앱·관리 앱을 갈아탈 때마다 데이터 이사에 지쳐본 사람
• AI랑 VS Code(또는 아무 에디터)로 문서 작업하며 사는데, 그 작업이 그대로 현황판이 되면 좋겠는 사람
• 이 시리즈를 처음 보는 사람 — 여기서 시작해 필요한 편으로 가면 된다

😫 이 이야기는 6일 전에 시작되지 않았다 (Before)

먼 배경부터. 나는 메모 앱 무덤을 여럿 가진 사람이었다. 이 앱 저 앱을 돌아다닌 결과 메모가 흩어졌다 — 어떤 건 리치텍스트, 어떤 건 스프레드시트, 어떤 건 그냥 텍스트. 포맷이 다 달라서 옮기지도 합치지도 못했고, 백업해서 빼내오는 건 늘 고역이었다. 그때 결심 비슷한 게 생겼다. "이럴 바엔 전부 plain text로 관리하는 게 낫지 않나." 그 갈망을 따라 찾다 찾다 만난 게 org-mode였다 — 개발자들이 텍스트 파일만으로 일정·할일·인생을 관리하는 물건. "불렛저널이랑 궁합이 좋겠는데?" 정도 생각하고, 그땐 거기까지였다.

시간이 지나 AI 시대가 왔다. 그리고 이상한 일이 벌어졌다 — 세상이 다시 텍스트로 귀환하기 시작했다. 다들 마크다운을 쓴다. 마크다운이란 게 뭔가? 서식 기호가 조금 붙었을 뿐, 사실상 plain text다. AI와 일하는 사람들은 이제 코드도 문서도 계획도 전부 텍스트 파일로 다룬다. 내가 옛날에 도착했던 결론에, 세상이 이제 도착한 것이다.

나도 그 흐름 위에 있었다. 내 사이트는 각 프로젝트 폴더의 README 정보칸(색인)을 읽어 프로젝트 카드를 자동으로 띄운다 — 사실 그게 이미 조그만 대시보드였고, "문서 안의 색인이 실시간으로 화면이 됐으면"이라는 욕구의 실험이었다. 그런데 진짜 대시보드를 만들려니 벽이 왔다. 폴더 단위 색인만으로는 안 된다. 목표와 프로젝트와 투두와 세부 계획의 계층, 그것들의 관계 — 파일 하나에 정보칸 하나 붙이는 정도로는 표현이 안 됐다.

이걸 어떻게 해결하지, 고민하다가 — 옛날의 그 기억이 돌아왔다. org-mode.

🛠️ 사용한 도구

• 도구: Claude Code (설계 대화·구현·검증 전부)
• 모델: Claude Opus 5 / Claude Fable 5
• 비용: 새 앱 구독 0원 — 이미 있던 마크다운 파일과 사이트 코드 위에 지음

🔧 가설, 그리고 6일의 검증

가설 — "한 줄 한 줄에 심어두면, 화면은 뿌리기만 하면 된다"

원조 org-mode의 방식은 이렇다. 일기를 쓰다가 체크박스 하나를 적으면 그게 자동으로 투두가 되고, "투두만 모아줘" 하면 모든 파일에서 체크박스 줄만 쫙 모인다. 쓰는 곳과 보는 곳이 분리돼 있고, 진실은 항상 텍스트에 있다.

내 가설은 거기서 반발짝 더 나간 것이었다. 색인(파일 맨 위 정보칸)을 넘어 단어·문장·줄 단위로 태그를 심는다 — 날짜, 마감, 우선순위, 완료 조건, 커스텀 뭐든. 그렇게 흩어진 정보를 모으는 데서 멈추지 않고, 웹 대시보드로 한 번 더 뿌린다. 그러면 굉장히 유연한 대시보드가 된다 — 내가 원하는 것만, 원하는 형식으로 얼마든지 보여달라고 할 수 있으니까. 게다가 AI는 텍스트를 다루는 걸 제일 잘한다. 어차피 나는 VS Code에서 AI랑 문서로 모든 걸 관리하는데, 그 자연스러운 작업 흐름 자체가 대시보드의 재료가 되는 것이다.

이 가설을 들고 6일을 갔다. 결과는 시리즈 다섯 편이 됐다:

검증 ① 태그의 문법 — 줄 하나에 심는 정보 (1·2편)

지라·노션을 기각하고(상태를 앱에 가두니까) org-mode 패턴만 차용하기로 한 게 1편. 줄 단위 태그의 문법을 정한 게 2편이다 — 결론은 겨우 4개: 섹션 4칸(위치가 곧 속성), 체크박스+날짜 3정밀(@확정일/@이번주/@이달쯤), 느낌표 2개, 줄 옮기기. 욕심나는 속성은 "화면을 바꾸는 것만" 심사로 걸렀다. 태그가 많아지면 그게 곧 노션식 양식 지옥이니까.

검증 ② 판정도 텍스트가 한다 (3·4편)

루틴은 클릭조차 없앴다 — 그날 실물 파일이 있으면 한 거다(3편). 측정은 "진행률 = 목표 밑에 직접 적은 조건의 충족률"로 재정의하고, 성장형 목표는 % 대신 RPG 레벨로(4편). 기계가 셀 수 있는 조건은 기계가 세고, 사람은 판정만 한다. 전부 텍스트 줄 하나에 심은 태그가 해내는 일이다.

검증 ③ 가설 적중의 순간 — "보이는 것만 바꾸면 되네" (5편)

검증 중 제일 기분 좋았던 순간들은 화면을 바꿀 때였다. "이 부분 대시보드 바꾸고 싶어"라고 하면 AI가 슉슉 바꿨다. 왜냐하면 — 자료는 이미 파일에 전부 준비돼 있어서, 보여지는 것만 바꾸면 되니까. 화면 구성조차 마크다운 한 장(한 줄=블록, 순서=화면)이라, 대시보드 대개편에 코드 한 줄 안 쓴 날도 있다. 가설이 정확히 맞아떨어진 지점이다. 최종 화면은 질문 4개짜리 4장이 됐다 — 오늘(뭐 하지)/계기판(목표가 움직이나)/시나리오(어디까지 왔나)/서랍(자산).

그리고 대가 — 선례 없는 길은 설계가 오래 걸린다

솔직하게: 오래 걸렸다. 잘하면서도 계속 불안했던 이유는, org-mode를 웹 대시보드로 뿌려 쓰는 방식을 내 주변에선 본 적이 없어서다. 어딘가 있을지도 모른다(계속 찾아볼 생각이다). 하지만 참고할 실물이 없으니 매 단계가 "떠듬떠듬 내 생각을 만들어가는" 일이었고, 그래서 좌충우돌했고, 시행착오가 시리즈 다섯 편이 나올 만큼 쌓였다. 대신 얻은 것도 분명하다 — org-mode는 20년 넘게 살아남은 기술이다. 그 세월이 안정성과 편리함을 증명해줬으니, 내 조합(org 패턴 × 마크다운 × AI × 웹 뷰)의 뿌리는 검증돼 있는 셈이다. 개척한 건 조합이지 원리가 아니다.

검증에서 내 역할 — 위화감을 말로 바꾸는 것

돌아보면 설계를 바꾼 결정타는 대부분 내 반박이었다. "그 선례 진짜 있어?"(1편), "그 파일 떨렁 있으면 안 쓰게 돼"(2편), "폴더가 카테고리잖아"(2편), "마일스톤 자체가 레벨 아니야?"(4편), "파이 그래프 말고 직선"(5편). AI는 초안·구현·검증을 맡았고, 나는 위화감을 뭉개지 않고 꺼내는 일을 맡았다. 비개발자의 무기는 코드가 아니라 그거였다. 반대로 AI가 나를 말린 것도 있다 — 속성 다 넣기, 경험치 시스템, 남의 양식 통째 도입. 가설 검증은 둘의 합작이었다.

🗺️ 전체 설계도 (이것만 보고 따라 해도 됨)

층 구조 — 위에서 아래로 4층:

계절(방향) → 비즈니스 모델(마일스톤·레벨이 사는 곳)
           → 프로젝트(단계를 미는 실행체, 다대다)
           → 세부 할 일(각 프로젝트의 계획 파일)

파일 — 전부 마크다운, 전부 내 폴더에:

각 프로젝트/README.md   ← 명함 (정체·상태. 상태 변경은 사람이 결정)
각 프로젝트/docs/계획.md ← 할 일·마일스톤·조건 (섹션 4칸)
일지/루틴.md            ← 반복의 정의와 기록 (한 곳)
대시보드.md             ← 화면 조립표 (한 줄=블록)

문법 치트시트:

## 다음 / ## 마일스톤 / ## 이슈 / ## 한 일    ← 섹션 4칸 (위치=속성)
- [ ] 할 일 @2026-08-05 !!                   ← 확정 날짜 + 우선순위
- [ ] 할 일 @2026-W33 / @2026-09             ← "이 주 안" / "이 달 쯤"
- [x] 완료 — 마일스톤 밑이면 그 자리에 남긴다   ← 옮기면 진행률 증발
- [-] 접기 (안 하기로 한 것 — 지우지 않는다)
- [ ] Lv2 누적 100명                          ← 성장형 목표는 레벨
- [ ] 글 12편 @자동:개수>=12                   ← 기계가 셀 수 있으면 자동 판정

흐름 — 평소엔 그냥 일한다. 작업하며 계획 파일의 체크박스가 바뀌면 대시보드가 그걸 읽어 주간·월간·로드맵·계기판을 조립하고, 루틴은 파일 존재로 자동 판정된다. 관리를 위한 별도 노동이 0에 수렴하는 게 목표다.

🚧 아직 안 되는 것 (정직하게)

• 자유의 통제 — org 방식은 너무 자유로워서, 모아서 통제하는 게 오히려 어렵다. 문법을 4개로 묶은 것도 이 때문인데, 실사용하며 더 조여야 한다
• 폰 입력 — 관리 화면은 보안상 내 PC에서만. 폰이 PC로 접속하는 터널 방식이 다음 과제
• 실사용 검증 진행 중 — 주간 뷰 첫 전환, 페이스 카드 실효성은 몇 주 살아봐야 안다

다음 죽음 후보도 안다 — 수동 루틴과, 조건 없이 착수하는 습관. 죽으면 부검하고 고치면 된다. 그게 이 시리즈에서 배운 태도다.

🚀 다음 꿈 — 저절로 만들어지는 인생 퀘스트 보드

이 시스템의 끝그림은 관리 도구가 아니다. 게임을 보면 거대한 세계관과 시나리오 아래 메인퀘스트·서브퀘스트가 장대하게 펼쳐진다. 내 인생은 그보다 더하다. 그 인생을 퀘스트 맵처럼 쫙 펼쳐서 보고 싶다는 게 오래된 욕구였다 — 단, DB에 각 잡고 입력하는 방식 말고. 내가 원한 건 AI 친화적이고 텍스트 친화적인 방식 — 그냥 AI랑 일하면, 그 텍스트 작업 자체에서 퀘스트 보드가 저절로 자라나는 것.

물론 퀘스트를 만든다는 건 일종의 게임 레벨 디자인이라 쉽지 않다는 걸 이번에 배웠다. 그래도 방향은 확인됐다. 그리고 다음 실전도 정해져 있다 — 다음 기수 스터디는 버킷리스트가 주제다. 각자의 꿈을 로드맵으로 그리고, AI와 작업하면 그 로드맵이 저절로 채워지고 진화하는 걸 같이 만들어보려 한다. 내 가설이 남의 인생에서도 작동하는지 — 그게 다음 검증이다.

📚 시리즈 전체 (아루나 사이트에서 읽을 수 있어요)

1. 노션도 지라도 아니었다 — 20년 된 물건에서 내 대시보드의 답을 찾았다
2. AI가 분류하다 자꾸 틀리길래, 판단을 없애버렸다 — 폴더 = 카테고리
3. 이 글이 저장되면 오늘 루틴이 자동으로 끝난다
4. 내 사업 로드맵을 RPG 레벨제로 바꾼 이유
5. 대시보드가 안 보이는 이유는 정보량이 아니었다 — 한 장에 질문 하나
6. (이 글) 파일이 진실, 화면은 조립 — 전체 설계도

📋 재사용 가능한 프롬프트 — 통째로 시작하기

스타터 프롬프트: 내 마크다운 관제탑

나는 상태·계획을 앱이나 DB에 가두고 싶지 않아. 원칙은 "파일이 진실, 화면은 조립"이야. ① 내 프로젝트 폴더마다 계획.md를 만들어줘 — 섹션 4칸(다음/마일스톤/이슈/한 일), 날짜 3정밀(@일/@주/@월), 우선순위 !·!!, 완료는 마일스톤 밑에 남기기. ② 루틴 파일 하나 — 행동의 부산물(파일)이 남는 루틴은 존재 감지로 자동 판정, 수동은 3개 이하. ③ 진행률은 목표 밑에 직접 적은 조건의 충족률로만 세고, 성장형 목표는 레벨(Lv1·Lv2)로. ④ 주간·월간 목표 파일은 만들지 마 — 날짜 붙은 항목을 긁어 화면에서 조립해. ⑤ 화면은 장마다 질문 하나(오늘 뭐 하지 / 목표가 움직이나 / 어디까지 왔나 / 자산이 뭐가 있나). 내가 "이상한데?"라고 하면 소스와 뷰 양쪽을 실측해서 범인을 찾아줘.

🏁 마지막 문단 — 가설의 마지막 증거

이 시리즈를 시작하던 날, 완료 조건을 계획 파일에 이렇게 적었다: 사례글 12편, 판정은 자동. 사람이 체크하는 게 아니라 글 파일의 개수를 기계가 센다.

방금 이 글이 저장됐다. 12번째 파일이다. 지금 내 대시보드의 그 조건은 내 손을 거치지 않고 실측 뱃지로 차오른다. 텍스트에 적어두면 판정도 화면도 저절로 따라온다는 가설의, 이 글 자체가 마지막 증거인 셈이다. 일을 하면 기록이 남고, 기록이 곧 측정이다.

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

📝 한줄 요약

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

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

• 위키 한 벌에서 슬라이드가 나오는 건 이미 확인했다(지난 글). 그럼 사업계획서·할 일도?
• "문서를 잘 쓴다"를 파다가 → 사업계획서 항목대로 위키를 쌓자는 아이디어에 도착
• ★ 부수 효과가 더 컸다 — 항목이 곧 체크리스트라 기획이 촘촘해지고, 수익화까지 생각하게 된다
• 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

월간 아루나 창간호 · 2026년 7월 14일 ~ 8월 12일

이번 달의 질문

작업을 끝내면 정리는 밀렸다

나는 하나에 몰입하면 작업은 끝내지만, 기록·정리·사례글·포트폴리오는 늘 밀렸다.

자동화를 마지막이 아니라 시작에 붙였다

그래서 이번 달에는 “정리할 에너지를 남기자”가 아니라, 정리하지 않아도 결과가 남는 구조를 만들자고 생각했다.

하는 동시에 그게 바로 결과로 나오는, 거울처럼 비쳐지는 자동화.

살아남는 시스템의 조건

기록 시스템은 여러 번 만들고 죽였다. 살아남는 방식은 분명했다.

파일을 고치면 결과물도 함께 바뀌어야 했다

그래서 조건을 하나 세웠다. 파일만 고치면 결과물이 함께 바뀌어야 한다.

네 갈래로 한 일

한 달의 작업 지도

따로 보였지만 같은 방향이었다

사이트, 대시보드, 스터디, 시스템 정리는 달라 보였지만, 결국 한 번 한 일을 다시 손으로 정리하지 않아도 되게 하려는 일이었다.

개별 사건은 사례글 17편에 남겼다. 이 글은 그 작업이 내 방식을 어떻게 바꿨는지에 대한 회고다.

대시보드가 아니라 거울을 만들고 싶었다

보고 싶었던 것은 ‘할 일’보다 흐름

원했던 것은 할 일 목록이 아니라, 비전·프로젝트·오늘의 일이 이어지는 RPG 상태창 같은 화면이었다.

관리할 화면은 오래 못 간다

계획과 진행률을 따로 입력해야 한다면 결국 안 쓸 것을 알고 있었다.

사이트에서 검증한 방식을 대시보드로 넓혔다

그래서 문서를 고치면 화면이 따라 바뀌는 방식을 대시보드까지 넓히려 했다.

화면을 고치는데도 계속 답답했다

화면은 이미 나와 있었다

계획·진행률·달력 화면을 만들고, 로드맵도 RPG 레벨제로 바꿨다.

고치면 조금 나아지고, 다시 어긋났다

그런데 고칠 때마다 조금 나아졌다가, 다시 보면 또 원하는 모양이 아니었다.

답답함은 worklog에 먼저 남았다

worklog에는 그때의 말이 남아 있다.

• 7/29: “가슴이 답답하다”
• 7/31: “누덕누덕 만든 것 같다”
• 8/10: “이대로 하는 게 맞나 모르겠다”

화면을 더 고치기 전에 멈췄다

한여름의 컨디션 저하와 챌린지 운영이 겹친 데다, 처음 만드는 일이라 매번 판단이 필요했다.

결과가 나오는 원천부터 다시 봤다

그래서 화면을 더 고치는 대신, 내가 원하는 결과는 무엇이고 그 결과는 어디에서 나와야 하는가를 다시 보기로 했다.

슬라이드를 만들며 발견한 것

결과물은 파일이 아니라 뷰였다

위키를 슬라이드로 바꾸는 뷰를 만들며 생각이 정리됐다. 하나의 문서를 전자책·위키·슬라이드로 다르게 보는 것이다.

안 되는 문단은 원래 읽기 어려웠다

처음에는 변환 규칙이 부족하다고 생각했다. 하지만 안 되는 문단은 대체로 줄글이었고, 제목과 항목도 없었다. 원래 사람도 읽기 어려운 문단이었다.

규칙 대신 원문을 고쳤다

규칙 대신 원문을 고쳤다. 제목·번호·목록으로 나누자 한 챕터 14장이 자연스럽게 슬라이드로 나왔고, 글도 함께 좋아졌다.

화면을 잘 만드는 게 아니라, 문서가 구조적이면 화면은 따라온다.

대시보드가 어긋난 이유도 문서에 있었다

화면이 읽을 구조가 없었다

대시보드가 어긋난 이유도 같았다. 원천 문서에 큰 목표·세부 계획·실행 항목의 구조가 없으니, 태그와 진행률을 따로 붙여야 했고 문서와 화면이 바로 어긋났다.

하루 만에 어긋나는 목록

체크박스 없이 제목과 번호만 읽었는데, 큰 목표 5개와 할 일 21개가 뽑혔다. 손으로 옮긴 목록도 21개였지만 글자까지 같은 항목은 4개뿐이었다.

같은 답이 필요하면 구조를 읽어야 한다

• 손으로 옮기는 동안 이미 표현과 범위가 바뀌고 있었다.
• AI가 매번 읽고 요약하면 결과도 매번 달라진다.
• 반복해서 같은 답이 필요한 일은 AI의 추론보다 기계가 문서 구조를 그대로 읽는 방식이 맞다.

상태창은 미뤄진 게 아니라 순서가 바뀌었다

화면보다 먼저 쌓아야 할 것

RPG 상태창은 아직 완성하지 못했다. 대신 만드는 순서를 알게 됐다.

비전 문서
  → 큰 목표: 메인 시나리오
  → 세부 계획: 메인 퀘스트
  → 실행 항목: 서브 퀘스트
  → 대시보드: 지금의 상태를 보여주는 화면

다음 실험은 사업계획서 양식

다음에는 위키를 사업계획서 양식으로 쌓아보려 한다. 문제·고객·가치·수익·채널·실행 계획을 문서에 넣고, 같은 원천에서 사업계획서·상세페이지·슬라이드·할 일을 꺼내는 구조를 확인하고 싶다.

챌린지는 다음 기수의 재료가 됐다

계획 밖에서 생긴 다음 단계

이번 달 절반은 23기 챌린지 운영이었다. 영상 작업은 거의 못 했지만, 26개 Day 페이지를 만들고 운영한 뒤 갤러리를 열었다.

이번 달의 일이 다음 기수의 재료가 됐다

처음에는 계획에서 벗어난 것처럼 보였다. 하지만 수강생의 위키·전자책 구조와 이번 달의 문서·대시보드 구조는 다음 기수의 커리큘럼 재료가 됐다.

한 달 동안 나는 어떻게 달라졌나

화면이 본체라고 생각했던 때

한 달 전에는 HTML과 CSS를 잘 만들면 시스템을 구현할 수 있다고 생각했다. 지금은 문서 → 변환 규칙 → 화면 순서가 먼저라는 것을 안다.

막연한 시스템이 구현 순서가 됐다

더 만드는 것보다 덜 만드는 판단을 배웠다

폴더 구조를 갈아엎으려다 그대로 두었고, 규칙을 정리하려고 만든 장치가 규칙을 늘린다는 것도 봤다. 이제는 새 기능부터 붙이기보다, 원래 있는 구조를 더 잘 읽을 수 없는지 먼저 묻는다.

몸 상태도 작업 시스템의 조건이 됐다

무리했다는 점도 남았다. 컨디션이 떨어진 상태에서 판단이 많은 일을 계속하면 방향도 흐려진다. 다음에는 작업량뿐 아니라 편안하게 갈 수 있는 속도까지 설계하려 한다.

다음 달에 이어갈 것

• 사업계획서 양식으로 프로젝트 하나를 처음부터 쌓아보기
• 문서 구조에서 대시보드 항목을 자동으로 뽑기
• 프로젝트 문서뿐 아니라 저널과 일기에도 같은 방식 적용하기
• 이번 달의 구조를 다음 기수 커리큘럼으로 연결하기

사이트, 대시보드, 스터디, 시스템 정리는 결국 하나였다. 결과물을 나중에 만들지 않으려면, 처음부터 결과물이 나올 수 있게 작업을 쌓아야 한다.

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