aluna 대시보드 — 사업 관제탑
☰ 목차 (8편)펼치기

AI가 분류하다 자꾸 틀리길래, 판단을 없애버렸다 — 폴더 = 카테고리

계획 파일 문법이 태어난 날의 기록. 목표 파일을 만들려다 "떨렁 있으면 안 쓰게 된다"는 한마디로 설계가 뒤집혔고, org-mode의 기능을 다 갖다 쓰는 대신 "화면을 바꾸는 속성만" 남겼다. 마지막엔 AI의 추상 분류 대신 "폴더 = 카테고리"라는 눈으로 보는 규칙이 이겼다.

2org-mode불렛저널계획관리마크다운대시보드바이브코딩

2026-08-03

📝 한줄 요약

계획 문법을 정하던 날, 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

항목BeforeAfter
목표 관리목표 파일 만들 때마다 죽음목표 파일 자체가 없음 — 날짜가 목표, 화면은 자동 조립
항목 속성노션식 필드 채우기 (적는 게 일)섹션 위치 + 날짜 + 느낌표 — 끝
분류AI가 성격으로 추론 → 중복 사고폴더 = 카테고리 (보면 아는 규칙)
문법 개수도구마다 배울 것 수십 개4개 — 섹션 4칸 · 체크박스+날짜 3정밀 · !·!! · 줄 옮기기

결과물 — 문법 치트시트

## 다음 / ## 마일스톤 / ## 이슈 / ## 한 일   ← 섹션 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