노션도 지라도 아니었다 — 20년 된 물건에서 내 대시보드의 답을 찾았다

📝 한줄 요약

프로젝트가 늘어날수록 전체 그림이 안 보여서 관리 도구를 찾아 헤맸는데, 답은 지라도 노션도 아니라 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