2026년 8월호

📝 한줄 요약

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

📝 한줄 요약

AI에게 일을 맡기고 싶었지만, 나는 늘 컴퓨터 앞에 붙어서 하나하나 확인하고 고쳐야 했다. 처음에는 내가 AI를 못 믿어서 그런 줄 알았다. 그런데 살펴보니 AI가 일을 시작할 입구도, 끝났다고 판단할 기준도, 다른 AI에게 넘길 방법도 없었다. 요구사항부터 검수와 보고까지 이어지는 작은 업무의 틀을 만들고 나서야 처음으로 한 사이클을 맡겨볼 수 있었다.

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

• AI에게 일을 못 맡긴 이유는 모델 성능만이 아니라 업무의 입구와 출구가 없었기 때문이었다.
• 작은 작업은 한 장짜리 브리프, 큰 작업은 Spec Kit식 스펙으로 나누었다.
• 목표·권한·금지선·완료 조건·멈춤 조건을 먼저 주고 실행하게 했다.
• 기계 검사를 통과해도 내가 원한 결과와 다를 수 있었다. 그래서 별도의 검수와 사용자 판정을 붙였다.
• 완전한 위임에는 아직 도달하지 못했지만, 매 단계 옆에 붙지 않고 한 사이클을 돌리는 틀은 처음 생겼다.

🎯 이런 분들께 도움돼요

• AI에게 “알아서 해줘”라고 하면 결과가 자꾸 빗나가는 사람
• AI가 작업하는 동안 계속 옆에서 확인하느라 자리를 뜨지 못하는 사람
• Claude, Codex처럼 도구를 바꿀 때마다 설명과 지침을 다시 써야 하는 사람
• AI 에이전트나 조직도를 만들기 전에 무엇부터 정해야 할지 막막한 비개발자

😫 문제 상황 — 나는 왜 계속 마이크로매니징했을까

다른 사람들은 AI에게 일을 맡겨두고 다른 일을 한다고 했다. 나는 그러지 못했다. AI가 무언가를 만들면 바로 확인하고, “이건 아닌데”라고 고치고, 다시 결과를 보고 또 수정했다. 함께 만드는 작업에는 이 방식이 필요할 때도 있지만, 모든 일을 이렇게 하니 컴퓨터 앞을 떠날 수가 없었다.

처음에는 내가 AI를 잘 못 믿어서 그런 줄 알았다. 그래서 아예 전용 에이전트를 만들면 해결될까 생각했다.

지금 내가 너한테 일을 위임하고 싶은데 위임이 잘 안 되거든.
계속 내가 너를 마이크로매니징해야 되는 부분이 있어.

그런데 작업환경을 열어보니 에이전트를 만들기 전에 해결할 문제가 더 많았다.

• 모든 프로젝트에 적용되는 전역 지침은 계속 길어지고 있었다.
• 특정 프로젝트에서만 필요한 내용도 전역 지침에 섞여 있었다.
• 프로젝트별 지침은 오래됐거나 실제 작업에서 잘 읽히지 않았다.
• Claude용 지침에 몰아 넣은 내용은 Codex가 알지 못했다.
• 계획 문서는 계획이라기보다 오래된 할 일 목록처럼 변해 있었다.
• 어떤 문서가 현재 상태이고 어떤 문서가 과거 기록인지 구분하기 어려웠다.

AI가 일을 못 하는 것이 아니라, 일을 시작하기 전에 읽어야 할 것부터 서로 모순되고 있었다.

✅ 확인한 방법: 전역 지침, 프로젝트 지침, 계획 문서, 인계 문서를 실제로 열어 역할과 중복을 대조했다. “정리가 안 된 것 같다”는 느낌을 파일 단위로 확인했다.

🛠️ 사용한 도구와 재료

• Claude Code: 처음 문제를 진단하고 회의·기획 구조를 만드는 데 사용
• Codex: 다른 모델이 문서를 이어받아 실제 작업할 수 있는지 확인
• Paseo-Codex와 별도 Claude 작업자: 맥락을 제한한 인계와 냉독 검수에 사용
• Spec Kit 방식: 복잡한 작업의 요구사항·계획·실행·검증 단계를 참고
• Markdown 문서와 Git: 브리프, 작업 목록, 인계, 결과와 증거를 남기는 바닥

새로운 대형 에이전트 플랫폼을 설치한 것은 아니다. 먼저 지금 가진 도구들 사이에서 공통으로 쓸 수 있는 파일 기반 업무 흐름을 만들었다.

🔧 작업 과정

1. 에이전트를 만들기 전에 방부터 정리했다

처음에는 작은 위임 실험부터 해보자는 제안도 나왔다. 하지만 내 눈에는 이미 방이 너무 어질러져 있었다. 새 자동화를 하나 더 넣으면 잠깐 쓰다가 또 버릴 것 같았다.

지금도 글로벌 지침은 계속 자라고 있고 메모리도 계속 늘어나고 있어.
계획 문서도 점점 쓰레기통이 되고 있어.
지금 엄청나게 지저분하고 물건이 가득 쌓여 있는 방 같은 상태인 것 같아.

그래서 무엇을 더 만들기 전에 정보가 있어야 할 자리를 나눴다.

• 모든 작업에 공통인 원칙
• 프로젝트에서만 필요한 지침
• 현재 할 일과 완료 조건
• 왜 그렇게 결정했는지 남기는 작업 기록
• 다른 AI가 이어받는 입구

정리의 목적은 예쁜 문서 체계를 만드는 것이 아니었다. 다음 AI가 “무엇을 읽고, 무엇을 하고, 어디서 멈춰야 하는지” 알 수 있게 만드는 것이었다.

✅ 확인한 방법: 같은 사실이 여러 문서에 중복되지 않는지 보고, 현재 상태·작업 기록·규칙·인계 문서의 역할을 각각 한 곳으로 좁혔다.

2. 채팅으로 흘러가던 요구사항을 업무의 입력으로 바꿨다

AI와 오래 대화하다 보면 중요한 결정도 채팅 위로 밀려 올라간다. 다음 세션에서는 그 이야기를 다시 설명해야 했다. 그래서 작업에 들어가기 전에 대화를 문서로 고정해달라고 요청했다.

지금까지 작업 대화한 내용을 회의록으로 남기고,
확정된 내용으로 기획서를 만들고,
기획서에서 상세계획과 실행 목록을 뽑아 진행해.
다른 AI가 이어받을 수 있을 정도로 문서 작업을 해놔야 돼.

이때부터 요구사항이 다음 순서로 흐르기 시작했다.

사용자 요청
→ 회의와 질문
→ 기획서와 성공 판정
→ 실행 가능한 작업 목록
→ 작업자에게 전달
→ 결과와 증거 회수

예전에도 회의록, 계획, 보고서는 있었다. 하지만 실제로 누군가에게 일을 넘기는 작업 단계가 비어 있었다. 이번에는 그 빈칸을 채우는 것을 목표로 삼았다.

✅ 확인한 방법: 위임환경의 과거 기록을 대조했다. 2026년 5월에 정한 ‘회의록 → 계획 → 작업 → 보고서’ 네 단계 중 작업, 즉 실제 위임 단계만 석 달 동안 비어 있었다.

3. 작은 작업은 한 장 브리프로 시작했다

처음부터 복잡한 스펙 문서를 매번 쓰면 문서 관리가 다시 일이 된다. 반대로 “이것 좀 해줘”만 전달하면 AI는 빠진 맥락을 추측한다.

그래서 기본 입력을 한 장짜리 브리프로 정했다.

첫 실무는 기존 학습 자료 일부를 아루나 사이트 안의 위키로 옮기는 일이었다. 새 기능을 만드는 것이 아니라 정해진 구조 안에 콘텐츠를 옮기는 작업이었기 때문에 한 장 브리프로 시작했다.

Spec Kit 방식도 검토했다. 요구사항을 명확히 하고 계획·작업·검증으로 연결하는 원리는 가져왔지만, 모든 일에 전부 적용하지는 않았다.

• 원본과 위치와 완료 조건이 정해진 작은 일: 한 장 브리프
• 새 기능, 사용자 흐름 변경, 여러 프로젝트 수정, 불명확한 검수: Spec Kit식 문서 단계

중요한 것은 유명한 방법론을 통째로 설치하는 일이 아니라, 작업 크기에 맞는 입구를 고르는 일이었다.

✅ 확인한 방법: 첫 브리프에 목표·원본·권한·금지선·완료 조건·멈춤 조건이 모두 들어갔는지 항목별로 대조했다. 새 코드나 새 화면이 필요해지면 작업을 멈추고 큰 스펙으로 올리도록 경계를 넣었다.

4. 처음으로 한 사이클을 맡겨봤다

브리프를 받은 AI는 관련 문서를 읽고, 계획을 세우고, 작업하고, 검증 결과를 정리했다. 예전처럼 매 단계에서 바로 피드백하지 않고 먼저 끝까지 가보게 했다.

이것만 보면 위임에 성공한 것처럼 보였다. 실제로 파일 수, 문서 형식, 원본과 복사본의 일치 여부, 페이지 주소 같은 기계 검사는 통과했다.

그런데 내가 결과를 보니 기대한 수준에는 한참 못 미쳤다. 결국 다시 대화하며 고쳤다.

여기서 중요한 걸 배웠다.

완료 조건을 통과한 결과와 내가 원한 좋은 결과는 같지 않을 수 있다.

브리프가 틀린 것은 아니었다. 브리프에 내가 품질이라고 생각한 것이 충분히 들어 있지 않았다. AI가 멋대로 실패한 부분도 있었지만, 내가 머릿속으로만 알고 있던 기준도 많았다.

첫 실험은 완전한 위임에는 실패했다. 그래도 이전과 다른 점이 하나 있었다. 처음으로 AI가 요구사항을 받아 계획·실행·검수·보고까지 한 사이클을 돌렸고, 나는 마지막 결과를 보고 어느 기준이 빠졌는지를 찾을 수 있었다.

✅ 확인한 방법: 정본과 작업본의 Markdown 파일 28개 목록과 해시가 일치했고, 문서 정보칸 오류가 없었으며 대표 페이지 주소가 정상 응답하는지 확인했다. 그 뒤 사용자가 직접 결과의 내용과 방향을 판정했다. 기계 검수와 사람의 품질 판정을 분리했다.

5. “완료했습니다” 뒤에 별도 검수 단계를 붙였다

AI가 자기 작업을 자기가 검사하면 같은 오해를 그대로 들고 갈 수 있다. 그래서 작업 흐름에 Verify, 즉 검수 단계를 따로 넣었다.

요청 받기
→ 작업 성격 분류
→ 브리프 또는 스펙
→ 계획
→ 실행
→ 검수
→ 통과·수정·사용자 확인·중단 판정
→ 결과 보고
→ 기록과 인계

검수도 모든 작업에 무겁게 붙이지 않았다.

• 기본 검수: 요구사항, 변경 내용, 테스트, 빠진 범위 확인
• 심화 검수: 복잡하거나 위험한 변경, 반복 실패, 하네스 변경 확인
• 냉독: 그래도 애매하거나 실패 비용이 큰 경우, 맥락 없는 다른 AI가 다시 읽기

냉독 AI의 말도 정답으로 취급하지 않았다. 지적을 원본에서 다시 확인하고, 재현되는 것만 고쳤다.

실제 냉독에서는 승인한 문서 8개만 별도 작업자에게 주고 한 번에 감사하게 했다. 작업자는 후속 질문 없이 결과 파일 하나를 반환했고, 오래된 체크 표시와 날짜, 복사돼 남은 검증 내용 등 5건을 지적했다. 원본에서 다시 확인해 맞는 것은 고치고, 불필요한 제안은 받아들이지 않았다.

✅ 확인한 방법: 전달 전후 원본 8개의 해시가 같은지 확인해 작업자가 원본을 건드리지 않았음을 증명했다. 냉독 결과 5건은 상위 AI가 라이브 원본에서 하나씩 재판정했다.

6. 조직도보다 먼저 업무 흐름을 그렸다

웨비나에서 사람, AI, 공동 작업, 사람 검수를 나눈 업무 흐름도를 봤다. 나도 AI 회사 조직도를 만들면 위임할 수 있을 것 같았다.

하지만 역할 이름만 정한다고 일이 움직이지는 않았다. 먼저 필요한 것은 요청이 들어온 뒤 어디까지 자동으로 하고, 어디에서 사람에게 물으며, 무엇을 증거로 돌려줄지 정하는 일이었다.

시작 신호
→ 요청을 한 문장 목표로 정리
→ 자동·반자동·사람 작업·판단으로 분류
→ 브리프 또는 스펙 작성
→ 계획
→ 실행
→ 검수
→ 다음 상태 결정
→ 사용자 보고
→ 기록

이 흐름을 그림으로 보고서야 내 시스템이 처음으로 눈에 들어왔다. 그동안은 지침, 계획, 메모리, 작업 기록이 보이지 않는 곳에 흩어져 있어 늘 막연했다. 다이어그램에서는 각각이 왜 필요하고 다음 단계로 무엇을 넘기는지 보였다.

그래서 지금은 CEO, CTO, CMO 같은 큰 에이전트 조직을 만들지 않았다. 사용자, 개인 비서, 작업자, 검수자라는 작은 역할만 두었다. 반복 업무가 실제로 쌓일 때 역할을 더 나누기로 했다.

✅ 확인한 방법: 새 세션이 HANDOFF.md와 TASKS.md라는 두 입구만 받고도 읽어야 할 원본, 실행 가능 여부, 차단 조건을 설명하는지 시험했다. 별도 작업자가 결과 패킷을 반환하고 상위 세션이 검수할 수 있는 흐름도 실제로 한 번 돌렸다.

✅ 결과 — 완전한 위임은 아니지만, 처음으로 길이 생겼다

아직 컴퓨터를 켜두고 AI가 며칠씩 완전히 자율적으로 일하는 단계는 아니다. 첫 결과도 기대보다 부족했고 여러 번 다시 고쳤다.

그래도 기분 탓만은 아니었다. 요구사항이 입력으로 들어가고, 계획과 완료 조건을 거쳐, 실행·검수·보고로 돌아오는 길이 실제 파일과 테스트로 생겼다. 사용자가 모든 중간 단계를 붙잡지 않아도 되는 첫 틀이었다.

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

효과적이었던 것

1. 에이전트의 성격보다 업무의 입구와 출구를 먼저 만든다. 누구에게 맡길지보다 무엇을 받고 무엇을 돌려줄지가 먼저다.
2. 완료 조건과 품질 기준을 구분한다. 파일이 생기고 테스트가 통과한 것과 내가 원한 결과는 다를 수 있다.
3. 작은 일과 큰 일의 문서 무게를 다르게 한다. 작은 일은 한 장 브리프, 복잡한 일만 스펙 단계로 올린다.
4. AI의 자기검수 뒤에 다른 시선을 둔다. 단, 냉독 결과도 원본에서 재현된 것만 고친다.
5. 첫 위임의 부족한 결과를 실패로 버리지 않는다. 무엇이 머릿속 기준으로만 남아 있었는지 찾는 재료로 쓴다.

이렇게 하면 안 돼요

1. “알아서 해줘” 뒤에 숨은 기준까지 AI가 알아낼 것이라 기대하기. 목표·권한·금지선·완료 조건이 없으면 AI는 빈칸을 추측한다.
2. 처음부터 에이전트 조직을 크게 만들기. 실제 반복 업무가 없으면 역할 문서만 늘어난다.
3. 모든 작업에 무거운 스펙과 냉독을 붙이기. 관리 비용이 다시 위임의 이익을 잡아먹는다.
4. 테스트 통과를 사용자 만족과 같은 것으로 보기. 기계 검사와 사람의 품질 판단은 서로 다른 단계다.

🌍 다른 업무에 적용한다면

이 구조는 개발 작업에만 쓰는 것이 아니다. 조사, 콘텐츠 작성, 강의 준비, 자료 정리도 같은 질문으로 시작할 수 있다.

• 무엇을 끝내야 하나?
• 어떤 자료를 읽어야 하나?
• 어디까지 바꿔도 되나?
• 절대 건드리면 안 되는 것은 무엇인가?
• 무엇이 확인되면 끝났다고 볼 수 있나?
• 예상과 다르면 어디서 멈춰야 하나?
• 결과와 증거를 어떤 형식으로 돌려받을까?

이 일곱 가지가 있으면 AI 도구가 달라져도 같은 업무를 다시 건넬 수 있다.

🚀 앞으로의 계획

다음 목표는 에이전트 파일을 더 많이 만드는 것이 아니다. 실제 업무 하나를 처음부터 끝까지 맡겨보고, 다음 세 단계가 얼마나 작동하는지 확인하는 것이다.

1. 처음 하는 일은 사용자와 AI가 함께 기준을 발견한다.
2. 두 번째에는 AI가 주도하고 사용자가 결과를 검수한다.
3. 반복되면 AI가 실행하고 사용자는 예외와 중요한 결정만 본다.

그리고 이 바닥 위에 Claude, Codex, Hermes, 가상 컴퓨터 같은 실행 도구를 갈아 끼우는 구조를 시험하려 한다. 도구가 바뀔 때마다 내 프로젝트 지식과 일하는 방식을 다시 이사하지 않는 것이 다음 이야기다.

📋 재사용 가능한 프롬프트

작은 일을 맡길 때 쓰는 위임 브리프

아래 일을 내가 중간마다 확인하지 않아도 한 사이클로 진행할 수 있게 먼저 브리프로 정리해줘.

• 한 문장 목표
• 원하는 결과물과 저장 위치
• 반드시 읽어야 할 원본
• 수정 가능한 범위
• 건드리면 안 되는 범위
• 완료 조건
• 각 완료 조건의 확인 방법
• 예상과 다를 때 멈출 조건

빠진 정보가 결과를 크게 바꾸는 경우에만 질문하고, 충분하면 계획 → 실행 → 검수 → 결과 보고 순서로 진행해줘. 결과 보고에는 바꾼 것, 확인한 증거, 확인하지 못한 것, 내가 결정할 것만 포함해줘.

AI가 완료했다고 했을 때 쓰는 검수 요청

방금 작업의 완료 주장을 그대로 믿지 말고 검수해줘.

1. 처음 요구사항과 실제 변경을 대조하고
2. 완료 조건마다 증거를 붙이고
3. 성공한 경우뿐 아니라 실패 경계도 확인하고
4. 확인하지 못한 것은 미검증으로 남기고
5. 다른 AI의 지적은 원본에서 재현된 것만 채택해줘.

마지막에는 입증됨, 관측됨, 미검증을 구분해서 보고해줘.

📝 한줄 요약

새로운 AI 모델과 도구가 나올 때마다 내 작업환경을 다시 만들어야 할 것 같아 지쳤다. 문제는 새 기술이 계속 나오는 것이 아니라, 오래 가져갈 업무 기준과 자주 바뀌는 실행 도구가 한 덩어리로 붙어 있던 것이었다. 둘을 나누고 시스템을 한 장의 지도로 그려본 뒤에야 “중심은 보존하고 바깥만 갈아 끼우면 된다”는 감각이 생겼다.

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

• 새 AI가 나올 때마다 지침과 폴더를 전부 옮기는 방식은 오래 유지하기 어렵다.
• 내가 계속 보유해야 할 것은 모델이 아니라 목표, 자료, 권한, 완료 기준, 검수 방법과 기록이다.
• Claude나 Codex 같은 AI와 검색·브라우저·MCP 같은 도구는 필요할 때 교체하는 바깥층으로 두었다.
• 공통 지침을 특정 도구의 파일에 복사하지 않고, 하나의 원본과 얇은 연결 파일로 나누었다.
• 구조를 그래프로 보자 보이지 않던 시스템의 흐름이 처음으로 이해됐고, 막연한 불안도 줄었다.
• 아직 완전한 자동 위임은 아니지만, 다음 도구가 나와도 전체 시스템을 다시 짓지 않을 기준은 생겼다.

🎯 이런 분들께 도움돼요

• 새로운 AI 도구가 나올 때마다 지금 시스템을 버리고 옮겨야 할 것 같은 사람
• Claude에서는 잘 되던 지침이 Codex에서는 적용되지 않아 곤란했던 사람
• 전역 지침, 프로젝트 지침, 스킬과 메모리가 계속 늘어나 관리가 어려운 사람
• 내 작업환경이 실제로 어떻게 연결되어 있는지 눈에 보이지 않아 불안한 비개발자
• AI를 오래 쓰고 싶지만 특정 모델이나 서비스에 모든 것을 맡기고 싶지는 않은 사람

😫 문제 상황 — 새 기술을 따라가려다 유지보수만 하게 될 것 같았다

AI를 공부하다 보면 새로운 모델과 도구가 계속 나온다. 어떤 것은 가상 컴퓨터를 쥐여주고 혼자 일하게 하고, 어떤 것은 여러 에이전트를 조직처럼 움직이게 한다. 내가 원하던 기능이 새 도구에 들어 있는 것을 보면 당연히 써보고 싶어진다.

그런데 반가움보다 부담이 먼저 들 때가 많았다.

“저걸 쓰려면 지금까지 만든 지침을 또 옮겨야 하나?”

“새 도구의 폴더 구조와 설정 방식에 다시 맞춰야 하나?”

“몇 달 뒤 더 좋은 것이 나오면 또 이사해야 하나?”

모델이 좋아지면 프롬프트를 쓰는 방식도 달라졌다. 예전에는 빈틈없이 긴 지침과 자세한 스펙을 주는 것이 중요해 보였는데, 모델 성능이 오르자 지나치게 빽빽한 지침이 오히려 방해가 되기도 했다. 도구가 바뀌면 읽는 파일도 달랐다. Claude는 CLAUDE.md를 읽지만 Codex는 같은 방식으로 움직이지 않았다.

나는 최근 Claude를 주로 사용하면서 중요한 규칙을 CLAUDE.md에 계속 넣고 있었다. 당장은 편했다. 하지만 Codex로 작업하면 그 내용을 제대로 이어받지 못했다. 그러면 다시 설명해야 했고, 설명하지 못한 부분에서는 엉뚱한 폴더를 만들거나 오래된 규칙을 따르는 일이 생겼다.

그 문제를 막으려고 전역 지침에 더 많은 내용을 넣었다. 어느 프로젝트에서든 읽히게 만들고 싶었기 때문이다. 그 결과는 반대였다.

• 모든 프로젝트에 필요한 규칙과 특정 프로젝트에만 필요한 규칙이 섞였다.
• 같은 내용이 여러 AI용 파일에 복사됐다.
• 어느 파일이 원본인지 알기 어려워졌다.
• 규칙 하나를 고치면 다른 사본은 낡은 채로 남았다.
• 시스템을 정리하는 시간이 실제 일을 하는 시간보다 커질 조짐이 보였다.

새 기술을 잘 따라가고 싶어서 만든 시스템이 오히려 새 기술을 시도하기 무서운 시스템이 되어가고 있었다.

💡 전환점 — 시스템에는 잘 안 바뀌는 것과 자주 바뀌는 것이 함께 있었다

이 문제를 이야기하다가 단순하지만 중요한 구분을 만났다.

시스템 전체가 매번 바뀌는 것이 아니다. 오래 유지되는 중심과 자주 바뀌는 바깥이 붙어 있어서 전부 바뀌는 것처럼 느껴졌던 것이다.

내가 정말 오래 보유해야 하는 것은 특정 AI 모델이 아니었다.

• 내가 이루려는 목표
• 내가 쌓아온 문서와 지식
• AI가 해도 되는 일과 하면 안 되는 일
• 무엇을 완료라고 볼지 정하는 기준
• 결과를 어떻게 검수할지 정하는 방법
• 작업이 끝난 뒤 무엇을 기록하고 다음에 어떻게 이어갈지에 대한 계약

반대로 자주 바뀌어도 되는 것도 있었다.

• Claude, Codex 같은 AI 모델과 실행 서비스
• 각 도구가 지침을 읽는 파일 이름과 방식
• 검색, 브라우저, 파일, MCP 같은 작업 도구
• 화면과 명령어
• 한 작업을 어느 AI에게 나눠줄지 정하는 방식

이 둘을 한 덩어리로 관리하고 있었기 때문에 AI를 바꾸는 일이 곧 시스템 전체를 이사하는 일처럼 느껴졌던 것이다.

🗺️ 보이지 않던 시스템을 한 장의 흐름으로 그렸다

나는 비개발자라서 파일 이름과 설정 목록만 보면 전체 구조가 잘 잡히지 않는다. 문서가 열 개 있다는 사실을 알아도 그 열 개가 어떤 순서로 움직이는지 보이지 않으면 계속 불안하다.

이번에는 시스템을 파일 목록이 아니라 흐름으로 그려보았다.

나의 목표와 자료
      ↓
업무 의뢰서
목표 · 자료 · 권한 · 완료 조건
      ↓
교체 가능한 AI와 도구
Claude · Codex · 검색 · 브라우저 · 파일
      ↓
검수대
완료 기준 · 실제 동작 · 안전 · 근거
      ↓
결과 상자
결과 · 변경 내용 · 남은 문제 · 다음 행동
      ↓
다시 내 기록과 지식으로

이 그림을 보고 나서야 처음으로 “아, 내 시스템은 이런 식으로 움직이는구나”라는 감각이 들었다.

AI는 내 시스템 그 자체가 아니었다. 가운데서 일을 수행하는 교체 가능한 작업자였다. 특정 AI가 사라지거나 더 좋은 모델이 나와도, 앞의 업무 의뢰서와 뒤의 검수·기록 방식이 남아 있다면 전체 흐름은 유지할 수 있었다.

이 구조는 기술적으로 거창해서 의미가 있었던 것이 아니다. 눈에 보이지 않던 것을 내가 이해할 수 있는 모양으로 바꿔주었다는 점이 중요했다. 시스템을 이해하지 못해서 생기던 막연한 불안이 “어느 부분을 보존하고 어느 부분을 바꾸면 되는지” 판단할 수 있는 문제로 바뀌었다.

🔧 실제로 바꾼 것

1. 공통 원칙의 원본을 한 곳으로 좁혔다

Claude용 파일과 Codex용 파일에 같은 규칙 전문을 각각 복사하는 방식을 줄였다. 공통 규칙은 하나의 원본에 두고, 각 도구가 그 원본을 찾아가도록 연결했다.

여기서 연결 파일은 번역기이자 안내판에 가깝다.

공통 규칙 원본
   ├─ Claude가 읽는 얇은 입구
   ├─ Codex가 읽는 얇은 입구
   └─ 다른 실행기가 읽는 얇은 입구

도구별 입구에는 그 도구에서만 필요한 최소한의 설명만 둔다. 업무 원칙 전체를 복사하지 않는다. 그러면 공통 규칙을 한 번 고쳤을 때 각 사본을 찾아다니며 다시 수정할 필요가 줄어든다.

2. 전역 규칙과 프로젝트 규칙을 분리했다

모든 프로젝트에 적용할 규칙과 한 프로젝트에서만 필요한 사실을 나눴다.

전역에는 이런 것을 남겼다.

• 사용자에게 쉽게 설명하기
• 기존 파일과 관련 없는 변경 보호하기
• 삭제나 외부 공개처럼 위험한 일은 먼저 확인하기
• 현재 사실과 과거 기록을 구분하기

프로젝트에는 이런 것을 두었다.

• 이 프로젝트의 목표
• 지금 해야 할 일
• 완료 조건과 검증 방법
• 건드리면 안 되는 범위
• 최근 결정과 다음 작업

이렇게 나누자 다른 프로젝트의 사정이 전역 지침에 계속 쌓이는 것을 막을 수 있었다.

3. 파일 이름보다 역할을 먼저 정했다

이전에는 CLAUDE.md, AGENTS.md, HANDOFF.md 같은 파일 이름부터 보였다. 하지만 파일 이름만 외우면 새로운 도구가 나왔을 때 다시 혼란스러워진다.

그래서 먼저 역할을 정했다.

도구가 바뀌면 이 역할에 맞는 새 입구만 연결하면 된다. 중심 문서의 의미까지 다시 만들 필요는 없다.

4. 지침이 존재하는지뿐 아니라 실제로 읽히는지도 확인했다

파일을 만들어두었다고 AI가 반드시 읽는 것은 아니었다. 특히 실행 도구가 바뀌면 “분명 지침이 있는데 왜 모르지?”라는 일이 생겼다.

그래서 파일의 존재만 확인하지 않고, Claude와 Codex처럼 서로 다른 실행 환경에서 대표 규칙을 실제로 따르는지 확인했다. 처음에는 검사 환경이 실제 사용 환경과 달라 거짓 경고가 나오기도 했다. 그 경험 때문에 검사 결과도 무조건 믿지 않고, 실제 실행 조건이 같은지 함께 보게 됐다.

이 과정에서 배운 것은 단순했다.

지침을 썼다는 사실과 AI가 그 지침을 읽고 행동했다는 사실은 다르다.

5. 새 도구는 전체 이사가 아니라 얇은 어댑터로 받아들이기로 했다

앞으로 새로운 에이전트 도구가 나와도 먼저 모든 자료를 옮기지 않기로 했다.

대신 세 가지를 확인한다.

1. 지금 시스템에 없는 어떤 능력을 주는가?
2. 기존 업무 의뢰서와 결과 형식을 그대로 사용할 수 있는가?
3. 그 도구를 빼도 내 자료와 기록이 남는가?

세 조건을 만족하면 새 도구는 교체 가능한 작업자나 얇은 어댑터로 붙인다. 만족하지 못하고 그 서비스 안에 모든 지침과 기록을 다시 넣어야 한다면, 도입 비용을 더 신중하게 본다.

📊 무엇이 달라졌나

가장 큰 변화는 “이제 어떤 AI든 완벽하게 위임할 수 있다”가 아니다. 아직 거기까지 가지 못했다.

달라진 것은 새 기술을 바라보는 기준이다.

이전에는 새 도구를 보면 이런 생각부터 했다.

저걸 쓰려면 지금까지 만든 걸 어떻게 옮기지?

지금은 이렇게 묻게 됐다.

저 도구는 내 흐름의 어느 자리에 끼울 수 있지?
기존 중심은 그대로 두고 바깥 연결만 바꿀 수 있나?

이 차이는 작아 보이지만 내게는 컸다. 새 기술을 무조건 따라가거나 무조건 피하는 대신, 내 시스템을 기준으로 도입 여부를 판단할 수 있게 됐기 때문이다.

또 하나의 변화는 시스템을 설명할 수 있게 된 것이다. 예전에는 “뭔가 지침이 많고 여러 AI가 연결되어 있다”고밖에 말하지 못했다. 지금은 내가 보유하는 자료, 업무 의뢰, 교체 가능한 작업자, 검수, 기록이라는 흐름으로 설명할 수 있다.

내가 설명할 수 있다는 것은 문제가 생겼을 때 어느 층을 살펴봐야 하는지도 조금씩 알게 되었다는 뜻이었다.

⚠️ 아직 남은 문제

구조를 나눴다고 해서 유지보수가 사라지는 것은 아니다.

• 새로운 AI가 공통 지침을 실제로 읽는지 확인해야 한다.
• 도구별 입구가 너무 두꺼워져 공통 규칙의 사본이 되지 않는지 살펴야 한다.
• 오래된 프로젝트 지침이 다시 쌓이지 않도록 주기적으로 검수해야 한다.
• 자동 검사는 시스템의 일부만 확인하므로 실제 결과와 사용자 판단이 여전히 필요하다.
• 처음 해보는 일이나 취향을 함께 만들어야 하는 일은 사람과 AI의 대화가 많이 필요하다.

그리고 나는 아직 AI에게 큰일을 통째로 맡긴 뒤 완전히 자리를 떠나는 단계는 아니다. 다만 모든 작업에서 매 순간 옆에 붙어 있어야 하는 구조와, 한 사이클을 맡겨보고 마지막에 결과를 확인하는 구조의 차이는 조금씩 경험하고 있다.

💭 가장 크게 배운 것

처음에는 더 좋은 에이전트를 만들면 위임 문제가 해결될 거라고 생각했다. 그러다 지침을 정리했고, 문서 역할을 나눴고, 완료 기준과 검수 흐름을 만들었다. 그 과정에서 문제의 범위는 더 커졌지만 방향은 오히려 단순해졌다.

오래 가져갈 것은 내가 소유하고, 빨리 바뀌는 것은 교체 가능하게 둔다.

내 자료와 기준, 완료 조건과 검수 기록을 특정 AI 서비스 안에 가두지 않으면 새 기술이 나와도 전부 이사할 필요가 없다. 더 좋은 모델은 내 시스템을 대체하는 새 집이 아니라, 같은 작업실에서 새로 고용할 수 있는 작업자가 된다.

완성된 시스템은 아니다. 하지만 이제는 새 도구가 나올 때마다 “또 다 뜯어고쳐야 하나”라는 막연한 불안 대신, “어느 층만 바꾸면 되는가”를 물을 수 있게 됐다.

비개발자인 내게 이번 개편의 가장 큰 결과는 자동화 기능 하나가 아니었다. 내 시스템이 어떤 구조로 움직이는지 처음으로 조금 이해하게 된 것, 그리고 그 구조를 내가 계속 가꿔갈 수 있겠다는 감각이었다.

이 글은 1편 「왜 나는 AI에게 일을 맡길 수 없었을까」에서 이어집니다. 1편에서는 브리프, 완료 기준과 검수 흐름을 만들며 처음으로 업무 한 사이클을 맡겨본 과정을 다뤘습니다.

📝 한줄 요약

강의용 슬라이드가 필요해서 위키(마크다운 문서)를 슬라이드로 자동 변환해봤는데, 잘 안 되는 부분이 하나같이 원래부터 안 읽히던 문단이었다. 그래서 슬라이드를 손보는 대신 위키를 손봤더니 양쪽이 같이 좋아졌다.

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

• 위키 마크다운을 발표 슬라이드로 보는 뷰를 만들었다. 슬라이드용 파일은 안 만든다 — 글 한 벌에서 조립
• 처음엔 생각보다 잘 됐다. 위키가 이미 단계별로 쪼개져 있어서
• 안 되는 데를 고치려고 변환 규칙의 기준값을 다섯 번 조정했는데, 하나 맞추면 다른 하나가 어긋났다
• 원인은 규칙이 아니라 원문이었다. 소제목 없이 줄줄 이어진 긴 문단
• 원문을 다듬자 한 챕터 14장이 전부 한 화면에 들어가고, 화면에서 뺄 내용이 하나도 안 남았다
• 결론: 슬라이드를 위해 뭘 따로 만들 필요가 없다. 위키를 눈에 잘 들어오게 쓰면 슬라이드는 저절로 나온다

🎯 이런 분들께 도움돼요

• 노션·옵시디언에 문서는 쌓는데, 그게 발표나 공유로 안 이어지는 분
• 강의·스터디를 운영하며 교안과 슬라이드를 두 벌 관리하는 분
• "문서 정리해야 하는데" 하면서 계속 미루고 있는 분 (미루게 되는 이유가 명분이 없어서인 경우)

😫 문제 상황 (Before)

원래 하려던 건 전자책이었다. 강의 위키를 전자책 형태로 묶는 것.

전자책은 쓸 데가 분명하다. 파일로 다운로드해서 나눠줄 수 있고, 무료로 주는 미끼 상품이 될 수도 있고, 제대로 다듬으면 출판까지 간다. 다만 그건 전부 "언젠가"였다. 지금 당장 나눠줄 일도, 팔 일도, 낼 일도 없었다.

그래서 "지금 당장 필요한 게 뭐지?" 를 다시 생각했다. 답은 강의용 슬라이드였다. 강의는 곧 시작한다. 시작할 때 화면에 띄워놓고 "오늘은 이걸 합니다" 설명할 자료가 필요했다. 위키 페이지를 그대로 띄우면 글이 빽빽해서 발표용으로는 안 맞았다.

같은 재료(위키)로 만들 수 있는 게 여럿인데, 먼저 만들 건 지금 쓸 것이었다.

여기에 미루고 있던 문제도 하나 있었다. 위키를 읽다 보면 눈에 잘 안 들어오는 대목이 있었다. 한 문단이 너무 길고, 소제목 없이 여섯 문단이 이어지고. "언젠가 고쳐야지" 생각만 하고 계속 미뤘다. 급하지 않았으니까.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus
• 대상: 마크다운으로 쓴 강의 위키 (챕터 25개)

🔧 작업 과정

시작은 가벼웠다 — "위키를 슬라이드로 한번 변환해보자"

거창한 계획은 없었다. 이미 마크다운으로 글이 다 있으니 보여주는 방식만 바꾸면 되지 않을까 싶었다.

아루나 사이트에 23기 위키를 발표용 슬라이드로 만들고 싶어.

여기서 방향을 한 번 못 박았다. 슬라이드용 파일을 따로 만드는 안도 있었지만 골랐다.

지금 위키가 비추고 있는 마크다운 파일을 활용해서 그냥 뷰어만 슬라이드로 바꾸고 싶은 거야.

이유는 단순하다. 파일이 두 벌이 되면 글을 고칠 때마다 양쪽을 고쳐야 하고, 그러면 반드시 어긋난다. 글은 한 곳에 두고 보여주는 방식만 바꾸기로 했다.

결과는 생각보다 잘 됐다. 위키가 이미 소제목으로 단계가 나뉘어 있어서, 그 경계를 그대로 슬라이드 경계로 쓰니 챕터 하나가 8~9장으로 잘렸다. 슬라이드용으로 뭘 새로 쓰지 않았는데도.

✅ 됐는지 확인: 챕터 페이지에 "발표 슬라이드 (8장)" 버튼이 뜨고, 눌렀을 때 전체화면으로 열렸다. 25개 챕터 전부에 버튼이 붙었는지는 목록을 세어 확인했다.

그런데 예쁘지 않았다

내 발표 슬라이드가 너무 안 예뻐. 그리고 그냥 위키를 슬라이드 형식으로 것 뿐인 거 같아.

맞는 말이었다. 흰 화면에 검은 글씨 두 문단이 위쪽에 몰려 있고 아래는 텅 비어 있었다. 슬라이드가 아니라 문서를 확대한 것이었다.

그래서 디자인을 갈아엎었다. 16:9 비율 무대를 고정하고(화면 크기가 달라져도 배치가 안 흔들리게), 글자를 키우고, 목록을 카드로 만들고.

이거 너무 별로야.

계속 어긋났다 — 다섯 번의 조정

여기서부터가 이 글의 본론이다. 안 되는 부분을 고치려고 규칙을 계속 손봤다.

한 화면에 너무 많이 들어간다 → 분량 기준을 낮췄다. 그랬더니 이번엔 실습에 필요한 단축키 안내까지 화면에서 사라졌다.

단축키가 사라졌다 → 기준을 다시 올렸다. 그랬더니 다시 넘쳤다.

그림이 잘린다 → 그려진 크기를 재서 넘치면 자동으로 줄이는 장치를 넣었다. 두 번 시도해서 두 번 다 더 나빠졌다. 배율을 바꾸면 레이아웃이 바뀌고, 바뀐 걸 다시 재느라 값이 안 잡혔다. 위에는 거대한 빈 공간이 생기고 아래는 여전히 잘렸다.

다 이상해졌어. 다 잘리고. 다 난리가 났어.

되돌렸다. 세 번째 시도는 하지 않았다. 두 번 연속 어긋나면 그건 숫자 문제가 아니라 방식 문제라서.

✅ 됐는지 확인: 챕터마다 슬라이드 몇 장이 나오고 각 장이 화면을 넘치는지를 스크립트로 세어 표로 뽑았다. 눈으로 하나씩 넘겨보는 대신 "넘칠 수 있는 장 N개"라는 숫자로 봤다.

방향이 뒤집힌 한마디

이거를 뭐 바꿀 때마다 이렇게 하나하나 다 바꿔줄 순 없는데,
원문에 그 줄바꿈이나 문단도 슬라이드를 고려해서 하는 게 나을 수도 있을 거 같아.
그게 원문 자체 가시성 좋아질 수 있을 거 같고.

이 말을 하고 나서야 보였다. 잘 안 되는 대목이 하나같이, 원래부터 안 읽히던 대목이었다.

• 한 문단에 세 가지 얘기가 들어 있는 곳 → 슬라이드에서 넘침
• 소제목 없이 굵은 글씨로만 강조하고 넘어간 곳 → 슬라이드에서 계층이 안 잡힘
• 목록 한 항목이 세 줄인 곳 → 카드가 커져서 네 개만 돼도 화면을 넘김

변환 규칙이 부족한 게 아니었다. 원문이 그렇게 쓰여 있어서 그런 거였다. 규칙을 아무리 정교하게 만들어도, 원문마다 문단 길이도 형식도 제각각이면 하나의 기준으로 다 맞출 수가 없다.

그리고 이건 미루고 있던 그 문제와 같은 문제였다.

원문을 다듬었다

챕터 하나를 골라 이렇게 고쳤다.

• 굵은 글씨로만 강조하고 지나가던 문장을 소제목으로 승격 (5군데)
• 세 가지 얘기가 든 문단을 여러 문단으로 쪼갬
• **제목** + 긴 설명 문단 네 개를 목록 네 줄로
• 목록 항목의 설명을 한 줄로 줄임
• 인용 상자 안에 목록이 들어 있던 것을 소제목 + 목록으로 펴냄

문장을 손대는 일이라 하나하나 뭘 어떻게 바꿨는지 확인받으며 진행했다.

✅ 됐는지 확인: 다듬은 뒤 다시 세어보니 14장 전부 한 화면에 들어갔고, 발표자 노트가 비었다. 노트는 "화면에 넣기엔 긴 설명"이 가는 자리인데, 거기 갈 게 하나도 안 남았다는 건 원문이 이미 슬라이드 크기라는 뜻이다. 이게 방향이 맞다는 제일 확실한 신호였다.

곁다리로 발견한 것 둘

한글에서 굵은 글씨가 조용히 안 먹는다. **넘어지는 법(낙법)**을이라고 쓰면 별표가 그대로 화면에 보인다. 마크다운 표준상 닫는 별표 앞이 괄호 같은 문장부호이고 뒤에 글자가 바로 붙으면 강조로 안 쳐준다. 영어는 뒤에 공백이 오니까 잘 안 걸리는데, 한국어는 조사가 바로 붙어서 자주 걸린다. 사이트 전체를 훑어보니 52개 파일 중 18개, 29곳이 깨져 있었다. 글쓴이가 이 규칙을 외워서 피하는 건 무리라, 화면에 그릴 때 자동으로 받아주게 했다.

엉뚱한 파일을 고치고 있었다. 원문을 다듬었는데 화면에 반영이 안 됐다.

어디가 소제목이 반영된거야?

알고 보니 내가 고친 폴더는 자동 생성되는 복사본이었다. 진짜 원본은 다른 곳에 있었고. 더 나빴던 건, 결과를 확인하던 스크립트도 같은 복사본을 읽고 있어서 "잘 되고 있다"는 잘못된 신호를 계속 줬다는 것이다. 한참을 헤맸다.

✅ 결과 (After)

Before vs After

결과물

• 위키 챕터를 열면 "발표 슬라이드" 버튼이 있고, 누르면 전체화면 슬라이드로 열린다
• 주소에 장 번호가 붙어서, 링크만 보내면 그 장이 바로 열린다 ("3번 장 프롬프트 복사해서 해보세요")
• 실습용 프롬프트는 슬라이드에서도 복사 버튼이 살아 있다

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

효과적이었던 것

1. 결과물을 숫자로 확인하기. 슬라이드를 눈으로 하나씩 넘겨보는 대신 "각 장이 화면을 넘치는지"를 스크립트로 세어 표로 뽑았다. "넘칠 수 있는 장 3개"처럼 숫자로 보면 고칠 데가 바로 보이고, 고친 뒤에 나아졌는지도 바로 안다.
2. 같은 문제로 두 번 어긋나면 방식을 의심하기. 자동 축소 장치를 두 번 만들어 두 번 다 악화됐다. 세 번째를 시도하는 대신 되돌리고 방향을 바꿨다.
3. AI가 뭘 고쳤는지 어디를 고쳤는지 확인하기. 문장을 다듬는 작업이라 "이 문장을 이렇게 바꿨다"를 하나씩 보고받으며 진행했다. 내가 쓴 글이 조용히 바뀌는 걸 막을 수 있다.

이렇게 하면 안 돼요

1. 자동 변환 규칙만 계속 손보기. 기준값을 다섯 번 조정했는데 하나 맞추면 다른 하나가 어긋났다. 원문이 제각각이면 하나의 규칙으로 다 맞출 수 없다.
2. 결과를 확인하는 도구가 뭘 보고 있는지 안 챙기기. 확인 스크립트가 엉뚱한 파일을 읽고 있어서 "잘 된다"는 거짓 신호를 계속 받았다. 고치기 전에 "이 파일이 원본인가 복사본인가"부터.
3. 문서용으로 만든 그림을 슬라이드에 그대로 넣기. 세로로 길게 만든 도표는 슬라이드 비율(16:9)에 넣으면 줄이든 자르든 안 읽힌다. 슬라이드에서는 빼고 필요할 때 문서를 열어 보여주는 게 낫다.

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

이건 슬라이드에 국한된 얘기가 아니다. "쌓아둔 문서를 다른 형태로 꺼내 쓰려는 모든 경우"에 같은 원리가 통한다.

• 회의록 → 공유용 요약: 회의록에 소제목을 달고 문단을 짧게 써두면, 요약을 따로 쓸 필요 없이 소제목만 뽑으면 된다
• 업무 매뉴얼 → 신입 교육 자료: 매뉴얼이 단계별로 쪼개져 있으면 그게 곧 교육 슬라이드다
• 프로젝트 기록 → 보고서: 기록할 때 "이건 배경, 이건 결정, 이건 결과"로 나눠 써두면 보고서 목차가 이미 있는 셈

공통점은 하나다. 꺼내 쓸 때를 위해 뭘 따로 만드는 게 아니라, 원본을 잘 쓰는 것으로 해결된다. 그리고 원본을 잘 쓰면 원본 자체도 읽기 좋아진다.

🚀 앞으로의 계획

1. 앞으로 쓰는 위키는 처음부터 이 형식으로. 소제목 달고, 한 문단 짧게, 목록은 "제목 + 한 줄". 나중에 고칠 일이 없고 슬라이드도 알아서 잘 나온다.

2. 강의 전체 로드맵 슬라이드. 지금은 챕터마다 슬라이드가 있는데, 강의 전체를 훑는 슬라이드가 하나 더 있으면 좋겠다. 쓸 데가 두 군데다 — 강의를 처음 여는 날 전체 그림을 설명할 때, 그리고 기업에서 강의 문의가 왔을 때 커리큘럼을 제출할 때. 문의가 오면 "어떤 식으로 진행하는지 커리큘럼을 달라"는 요청이 늘 따라온다.

3. 나머지는 천천히. 발표자 노트를 별도 창으로 띄우는 것(지금은 화면 공유하면 관객에게도 보인다), 디자인 다듬기 같은 건 나중에 붙이면 된다. 우선은 틀을 잡는 게 중요하다.

📋 재사용 가능한 프롬프트

프롬프트 1: 문서를 다른 형태로 꺼내 쓰기 (파일을 두 벌로 만들지 않기)

[내 문서가 있는 위치]의 문서를 [슬라이드 / 요약본 / 교육자료]로도 볼 수 있게 해줘.

조건: 원본 파일은 그대로 두고 보여주는 방식만 바꿔줘. 파일이 두 벌이 되면 글을 고칠 때마다 양쪽을 고쳐야 하고, 그러면 반드시 어긋나니까.

프롬프트 2: 결과를 눈이 아니라 숫자로 확인하기

만든 결과가 제대로 됐는지 눈으로 하나씩 보는 대신, 숫자로 셀 수 있는 기준을 만들어줘. [예: 각 장이 화면을 넘치는지 / 빠진 항목이 몇 개인지]를 세서 표로 보여줘. 고치고 나서 나아졌는지도 같은 표로 비교할 수 있게.

프롬프트 3: 두 번 어긋났을 때 멈추기

같은 문제를 두 번 고쳤는데 두 번 다 더 나빠졌어. 세 번째 시도하지 말고, 이게 세부 조정 문제가 아니라 접근 자체의 문제인지 판단해줘. 접근을 바꿔야 한다면 방법 2~3개를 이유와 함께 알려줘. 내가 고를게.

프롬프트 4: 문서를 "꺼내 쓰기 좋은" 형태로 다듬기

이 문서를 아래 기준으로 다듬어줘. 문장을 바꾸는 부분은 어디를 어떻게 바꿨는지 다 알려줘.

• 한 문단 = 한 가지 얘기, 두세 줄 안쪽
• 굵은 글씨로 강조만 하고 지나가는 문장 중 소제목이 될 만한 건 소제목으로
• 목록 항목은 "제목 — 한 줄 설명" 형태로
• 문단이 넷 이상 이어지면 소제목으로 끊기

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

📝 한줄 요약

AI랑 만든 사이트가 잘 굴러가고 있었다. 기능을 더 붙이기 전에 한 번 열어봤더니 같은 코드가 10곳에 복사돼 있고, 색깔을 손으로 477번 지정해뒀더라. 하루 날 잡아 청소했고, 그 김에 몰랐던 버그 2개도 잡았다.

바쁘시면 이것만:

• "클린 아키텍처로 짜줘"는 그때 한 번만 먹힌다.** 기능을 추가할 때마다 **"기존 구조에 맞춰서"를 말해줘야 하는데, 나는 한 번도 안 했다
• 그래도 어긋나니까 한 번씩 열어봐야 한다. 제일 중요한 신호 = "앞으로 붙일 게 눈에 보일 때"
• 정리하다가 원래 있던 버그 2개가 튀어나왔다. 잘 굴러간 게 아니라 몰랐던 것
• 청소 전에 자로 재는 게 먼저. "지저분한 것 같아" 말고 "같은 게 10곳에 있다"로
• 잘 만들어진 데는 안 건드리는 게 실력

🎯 이런 분들께 도움돼요

• AI로 뭔가 만들었는데 기능이 붙을수록 슬슬 불안해지는 분
• "코드 정리"를 언제 해야 하는지 감이 안 오는 분
• 만든 걸 남들이 쓰고 있어서 함부로 못 고치는 분

😫 왜 정리하게 됐나

사실 이번이 두 번째 개편이다.

처음엔 되는 대로 만들었다. 틀이 잡히고 나서 한 번 갈아엎었는데, 그때는 정적 사이트(글만 보여주는 형태)라 결제나 기능 확장이 어려울 것 같아서였다. 기획은 이미 있으니 그대로 두고, 도구만 확장 가능한 걸로 바꿔 구조부터 새로 짰다. 그때 이렇게 요청했다.

완전 클린 아키텍처로,
앞으로 기능을 덧붙여도 무너지지 않게 처음부터 구조를 짜서 만들어줘

그리고 그 부분은 지금도 멀쩡하다. 오늘 열어보고 손 안 댔다.

문제는 그 뒤였다. 레이아웃을 조금씩 바꾸고 기능을 하나씩 추가하면서, "기존 구조에 맞춰서 해줘"라는 말을 한 번도 안 했다. 생각해보니 정말 한 번도.

AI 입장에선 당연하다. "이 버튼 색 바꿔줘" 하면 색을 바꿔준다. "이 색을 어디 모아둬야 나중에 안 흩어질까"까지는 안 따진다. 내가 안 물었으니까.

그게 열 번 쌓이면 같은 게 열 군데에 흩어진다. 한 번에 무너지는 게 아니라 조금씩 어긋나서 눈치채기 어렵다.

결정적인 건 "앞으로 붙일 것"이었다. 결제 기능도 붙여야 하고, 얼마 전엔 강의 자료를 슬라이드로 보는 기능이 생겼다. 앞으로 사업계획서 화면, 상세 페이지 화면도 붙일 생각이다. 화면이 늘면 디자인이 흩어진다. 색깔이 477군데 흩어진 채로 화면을 셋 더 붙이면 1,000군데가 된다.

그래서 하루를 비웠다.

⏰ 언제 정리해야 할까

내가 겪은 걸로 정리하면, 하나라도 해당하면 볼 때가 된 거다.

1. 같은 걸 두 번째로 복붙할 때 — 두 번은 우연, 세 번부터 습관
2. 고치려는데 어디를 고쳐야 할지 못 찾을 때 — 내가 만든 건데 못 찾으면 흩어진 거다
3. 한 곳 고쳤는데 다른 데가 안 따라올 때 — 같은 내용이 여러 곳에 있다는 증거
4. 기능 붙이는 게 무서워질 때 — 불안하다는 건 구조가 말해주는 거다
5. ★ 앞으로 붙일 게 눈에 보일 때 — 지금 안 불편해도, 붙이기 전이 제일 싸다

앞의 넷은 "지금 불편해서"인데, 이번에 내가 멈춘 진짜 이유는 5번이었다. 이렇게 물어보면 된다.

"앞으로 3개월 안에 뭘 더 붙일 예정이지? 그걸 지금 구조 위에 올려도 괜찮을까?"

시점으로 보면 — 첫 번째는 만들고 싶던 게 일단 굴러갈 때(제일 쌈), 그다음은 위 신호가 뜰 때와 큰 기능 붙이기 직전. 아직 뭘 만들지 모를 때는 하지 말자 — 방향이 바뀌면 정리한 게 버려진다.

🔧 하루 동안 한 것

도구: Claude Code (Opus 5) · 시간: 하루

1. "지저분한 것 같아"를 숫자로 바꿨다

바로 고치지 말고 세는 것부터 시켰다. 몇 분 뒤 나온 답:

• 같은 코드가 10곳에 복사됨
• 색깔을 손으로 지정한 곳 477군데
• 관리 화면 파일 하나가 3,884줄 (전체의 33%)

그런데 전부 엉망은 아니었다. 처음에 신경 쓴 부분은 깨끗했고, AI가 이걸 짚으며 말했다.

"여긴 안 건드립니다. 잘 된 것을 리팩터링하는 게 이런 작업이 실패하는 제일 흔한 방식이에요."

이 한마디가 하루의 방향을 잡았다.

✅ 확인법: "10곳·477군데·3,884줄"이라는 숫자가 손에 잡혔을 때. 숫자가 안 나오면 진단이 안 끝난 거다

2. 정리하다 원래 있던 버그 2개가 나왔다

흩어진 코드를 한 곳으로 모으는 단순 이사라고 생각했는데, AI가 이러더라.

"파일에 뭘 쓰는 코드는 화면으로 확인이 안 됩니다. 테스트를 따로 돌려볼게요."

저장 방식을 8가지 경우로 나눠 실제로 써봤더니 두 개가 걸렸다. 지워진 자리에 빈 줄이 남는 것, 그리고 파일마다 다른 줄바꿈 방식을 무시하고 한 가지로만 붙이던 것(우리 파일 208개 중 94개가 위험에 걸려 있었다).

둘 다 오늘 이전부터 있던 버그다. 화면에선 멀쩡해 보였으니 아무도 몰랐다.

그러니까 "잘 굴러가는데 왜 고쳐요?"의 답은 이거다. 잘 굴러간 게 아니라, 안 굴러가는 걸 몰랐던 것.

✅ 확인법: 빌드(조립 검사) 통과 = 안전이 아니다. 파일을 다루는 코드는 실제로 써보는 테스트가 따로 필요

3. "지금 저장하면 수업 중인 사이트가 갈립니다"

작업 도중에 확인차 물었다. 마침 주말이라 사람들이 이 사이트로 수업 중이었다.

지금 이걸 내 컴퓨터에서만 작업하고 있는 거니?
실제 운영되는 사이트에서 바로 작업하는 거면,
지금 수업 중이라 문제가 생기면 아예 안 될 것 같거든.

답은 "지금은 안전"이었다. 그때까지 작업은 전부 내 컴퓨터 안에만 있었으니까.

문제는 그다음이었다. 나는 하루에 몇 번씩 /save라는 명령을 쓴다. AI한테 시킬 마무리 절차를 내가 직접 만들어둔 건데 — 오늘 뭘 했는지 기록하고, 계획 문서를 갱신하고, 코드를 저장하고, 점검을 돌리고, 사례글 소재까지 뽑아준다. 한 단어로 열 가지 일이 한 번에 도는 거다.

편한데, 그 안에 "사이트에 올리기"가 들어 있다. 그러니까 이 상황에선 세이브를 누르는 순간 수업 중인 사이트가 갈린다. 배포되는 구조인 건 알고 있었지만, 작업하다 습관적으로 세이브를 눌렀으면 그대로 나갔을 거다.

해결은 작업용 갈래(브랜치)였다. 프로젝트를 잠깐 복사본처럼 하나 더 만들어서 거기에 저장하는 거다. 저장은 되니까 컴퓨터가 꺼져도 안 날아가고, 원래 것은 안 건드리니 사이트도 그대로다. 나중에 합치는 순간이 곧 배포다. 그건 수업 없는 새벽에 하기로 했다.

남들이 쓰는 걸 만들었다면, 내가 만든 편한 명령이 어디까지 하는지 한 번 훑어보시길. 편할수록 많은 일을 한 번에 한다.

✅ 확인법: 실제 사이트 주소를 열어서 예전 상태 그대로인지 눈으로. "아직 안 올라간 변경이 몇 개인지" 세는 것도 같이

✅ 결과

• 색 바꾸려면 이제 한 파일만 연다
• 다크모드가 가능해졌다 — 예전 구조면 수백 곳을 손으로 뒤집어야 했다
• 화면은 하나도 안 바뀌었다. 이게 성공 조건이었다

제일 큰 덩어리는 절반에서 멈췄다.** 지금 옮겨봐야 파일만 쪼개지고 얽힘은 그대로일 상태여서, 그 화면을 실제로 고칠 때 같이 하기로 했다. 이게 가능했던 건 **"각 단계가 끝나면 언제든 멈춰도 되는 상태"를 미리 규칙으로 정해뒀기 때문이다.

💬 배운 것

됐던 것

1. 고치기 전에 잰다. "지저분한 것 같아"로는 어디까지 할지 못 정한다
2. 잘 된 곳은 안 건드린다. 멀쩡한 걸 손대다 새 버그를 넣는 게 제일 흔한 실패
3. 값은 그대로 두고 이름만 바꾼다. 색 477개를 정리할 때 색 값은 하나도 안 바꿨다. 그래서 "화면이 안 바뀐다"가 저절로 보장됐다

안 되는 것

1. "클린 아키텍처로 짜줘" 한 번으로 끝났다고 믿기. 그건 그때 한 번만 먹힌다
2. 검사 통과했으니 됐다고 믿기. 조립 검사는 모양만 본다
3. 편한 명령을 습관적으로 누르기. 여러 일을 한 번에 하는 명령일수록, 위험한 시간대엔 그중 뭐가 나가는지 봐야 한다

📋 재사용 가능한 프롬프트

1. 기능 추가할 때마다 붙이는 한 줄 (제일 중요)

[원하는 기능]을 추가해줘. 단, 이미 있는 구조에 맞춰서 해줘. 새로 만들기 전에 비슷한 게 있는지 먼저 확인하고, 있으면 재사용해. 색깔·간격 같은 값도 이미 정해둔 곳이 있으면 거기서 가져다 쓰고, 없으면 흩뿌리지 말고 한 곳에 모아줘.

이 한 줄을 매번 붙였으면 오늘 하루가 통째로 필요 없었을 거다.

2. 정리할 때가 됐는지 진단

앞으로 기능을 더 붙여도 구조가 안 무너지게 하고 싶어. 바로 고치지 말고 먼저 실측해줘: 같은 코드가 여러 곳에 복사된 것과 개수 / 지나치게 큰 파일 / 하드코딩된 값이 흩어진 곳과 개수. 그리고 잘 되어 있어서 안 건드려야 할 곳도 알려줘. 전부 뒤집는 게 목적이 아니야.

3. 안전하게 진행하기

정리를 단계로 나눠줘. 각 단계가 끝나면 화면이 전과 똑같아야 하고, 그 상태로 멈춰도 문제없어야 해. 그리고 [내 사이트]는 지금 사람들이 쓰고 있어. 지금 작업 중인 내용이 실제 서비스에 언제 반영되는지 먼저 확인해줘. 위험한 시간대엔 저장은 하되 서비스엔 안 나가게 하는 방법(작업용 갈래 만들기)도 같이 알려줘.

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

📝 한줄 요약

AI에게 지켜야 할 규칙을 계속 적었는데, 적을수록 더 안 지켜졌다. 원인을 파다 "애초에 청소할 게 없어야 한다"는 미니멀라이프 원리에 도달했고, 문서를 스킬처럼 색인만 늘 보이고 본문은 필요할 때 열리는 구조로 바꾸기로 했다. 코드는 한 줄도 안 짰다. 하루 종일 설계만 했고, 그중 절반은 AI 비평가들에게 무너졌다.

바쁘시면 이것만:

• AI는 규칙을 실행하지 않고 참고한다 — 많을수록 각각이 약해진다. 100% 지켜야 할 건 기계에게
• 문서도 스킬처럼: 색인만 상시, 본문은 필요할 때
• 내 설계를 AI 비평가 3명에게 서로 모르게 부수게 했더니 셋이 같은 곳을 때렸다
• 감지 장치를 만들려다 구조 자체를 없애는 쪽이 답이었다
• 이날의 산출물은 만든 것이 아니라 안 만들기로 한 것 셋이었다

🎯 이런 분들께 도움돼요

• AI에게 규칙을 적어놨는데 자꾸 안 지켜서 답답한 사람
• 자료는 쌓이는데 정작 필요할 때 못 찾는 사람
• AI와 오래 일하며 지침 파일이 계속 비대해지는 사람

😫 문제 상황 (Before)

내 작업 폴더엔 AI가 매번 읽는 지침 파일이 있다. 말투, 폴더 분류법, 작업 절차. 처음엔 몇 줄이었는데 수백 줄이 됐다. 그런데 적을수록 더 안 지켜졌다.

새벽에 세 번 연속 같은 장면을 봤다. AI가 승인도 없이 규칙 문서에 새 규칙을 박아놓길래 지적했더니 → 반성하며 자기 메모리에 교훈을 적었고 → 그것도 지적하니 할 일 목록에 중요 표시(!)를 붙여 항목을 만들었다.

! 이거 넣고 또계속 규칙을 추가하는거 같은데ㅎㅎ
이렇게 계속하면 중요표시가 달린 문장만 여러개 늘어나며 아무것도 안중요해 지게 되겠지.

세 번 다 처방이 "적기"였다. 병을 고치려는 행동이 병이었다. 세어보니 계획 파일들에 중요 표시가 46개 붙어 있었다. 그리고 "규칙 추가 전 승인받아라"는 규칙은 이미 지침 맨 위에 있었다 — 규칙이 없어서 생긴 문제가 아니었다.

🛠️ 사용한 도구

• 도구: Claude Code / 모델: Claude Fable 5
• 특이사항: 설계를 세운 것도 AI, 그 설계를 무너뜨린 것도 AI였다

🔧 작업 과정

1. 청소 속도로는 못 이긴다 → "정보도 스킬처럼"

처방을 하나 더 얹는 대신 원리를 말했다.

부패 속도가 청소 속도보다 빠르기가 쉽지 않아. 애초에 청소할 게 없어야 돼.
정보나 문서는 생성 비용이 너무 낮아졌거든. 만들고 쌓는 건 중요하지가 않아.
중요한 건 구조고, 필요할 때 찾을 수 있는지야.

그럼 정보는 어디에 두나. 답은 이미 쓰던 기능 안에 있었다. 스킬은 "이거 해줘"라고 말하면 그때 관련 문서가 열린다. 늘 보이는 건 한 줄 설명뿐, 본문은 필요할 때만. 이게 점진적 로드다. 문서도 그렇게 만들면 된다.

여기에 둘이 더 붙는다. 문서에 명함(메타데이터)을 달아 색인을 만들면 그 구조를 그래프 뷰(마인드맵처럼 펼쳐지는 화면)로 뽑을 수 있다 — 개발 쪽에서 코드 구조를 그래프로 그려 AI에게 주면 훨씬 적게 읽고 빨리 파악한다는데, 그걸 문서에 하는 것. 그리고 org-mode(20년 넘은 텍스트 기반 할 일 관리 방식)를 쓰니 같은 파일이 마감일·태그·월간 뷰까지 되는 프로젝트 관리 도구를 겸한다.

2. 왜 적어놔도 안 지켜지나

물었다. "메모리에도 지침에도 있는데 왜 안 지켜?"

AI는 규칙을 실행하지 않고 참고한다. if문처럼 100% 발동하는 게 아니라, 언덕의 기울기처럼 대개 그쪽으로 구르되 가끔 튄다. 원인은 셋 — 희석(지시가 많을수록 각각 약해짐), 관성(훈련된 "적어서 돕기" 습관), 압축(대화가 길어지면 앞 규칙이 닳음).

그래서 분업이 나온다. 100% 지켜져야 할 건 기계(스크립트)에게, AI에게는 판단만. 나중에 웹 조사로 대조하니 실제 연구·공식 문서와 일치했다.

3. AI 비평가 3명이 설계를 무너뜨리다

설계가 그럴듯해 보이자 의심했다. "누덕누덕 만들었는데 또 구멍 나올 것 같거든?"

비평가 3명을 동시에, 서로 모르게 붙였다. 1번 "6개월 뒤 어떻게 썩나", 2번 "AI가 실제로 그렇게 움직이나", 3번 "기존 것들과 충돌하나". 셋이 독립적으로 같은 곳을 때렸다. 겹치면 진짜 급소다.

• 로드 순서 구멍 — 폴더마다 색인을 두려 했는데, 그 파일은 "그 폴더를 만진 뒤에야" 보인다. 즉 어디로 갈지를 안내할 수 없다. 스킬이 되는 이유는 모든 설명이 처음부터 떠 있어서인데, 앞 절반 없이 뒷 절반만 베낀 셈이었다.
• 감시 밖 증식 — 새로 만들 지침 파일 11개는 기존 검사 바깥. 다이어트 하려다 규칙이 자랄 자리를 11곳 만드는 꼴.
• "괜찮음" 판정이 근거 부실 — AI가 스스로 낸 안심 판정이었는데, 근거로 든 "이미 잘 돌아가는 층"이 절반 허수였다.

결론: 폴더마다 색인 두기 기각. 실측하니 프로젝트당 문서가 2~3개뿐이라 이미 있는 계획 파일이 색인 노릇을 하고 있었다. 색인 공사 자체를 뒤로 미뤘다.

✅ 확인: 비평가 말도 그대로 믿지 않고 근거 파일을 직접 열어 대조했다. 덤으로 파싱 버그 1건이 나왔다.

4. 감지기를 만들려다, 구조를 없애다

내 작업 폴더는 전체가 하나의 저장소인데 그 안에 독립 저장소 31개가 중첩돼 있어 검색이 안쪽을 건너뛴다. AI의 첫 반응은 감지 장치를 만들자였다. 거기서 멈춰 세웠다.

자꾸 기계적으로 감지하는 툴을 만들어 해결하려는 게 근본적인 해결은 아닌 거 같아.
구조를 심플하게 가져가야 돼.

관리 사다리에서 1번은 없애기, 기계화는 2번인데 AI는 2번부터 꺼냈다. 게다가 이 구조가 남아 있던 이유(다른 컴퓨터와 동기화)는 실측하니 이미 죽어 있었다(외부 유입 0건). 그래서 최상위 저장소를 해체하기로 했다. 구조 하나를 없애니 만들 뻔한 장치 셋이 같이 사라졌다.

마지막으로 하나가 더 없다는 걸 알았다. "내가 원하는 최종 결과를 정리해놨니? 그게 있어야 됐는지 안 됐는지 알 거 아니야." 설계는 있는데 완성 기준이 없었다. AI 요약은 납작해서 반려하고, 내 작업 기록에서 내가 실제로 한 말만 뽑아 요구사항 문서를 만들게 했다. 판정 기준은 거기서 저절로 나왔다.

✅ 결과 (After)

하루 종일 설계만 했고 코드는 한 줄도 안 짰다. 그런데 취소한 공사가 셋이다.

이날의 산출물은 만든 것이 아니라 안 만들기로 한 것이었다. 만들었으면 6개월 뒤 셋 다 관리 대상이 됐을 것이다.

💬 배운 AI 활용 팁

효과적이었던 것

1. AI가 만든 설계를 AI에게 부수게 한다. 단 여러 명을 서로 모르게, 각자 다른 각도로. 한 명에게 "검토해줘"라고 하면 대개 칭찬이 온다.
2. "실제로 그렇게 돼 있어?"라고 물어라. AI는 현재 상태를 낙관적으로 가정한다. 실측시키면 멈춰 있던 장치가 나온다.
3. 요구사항은 요약시키지 말고 내 기록에서 캐내게 하라. 출처 날짜가 안 붙은 줄은 지어낸 것이다.

이렇게 하면 안 돼요

1. 규칙을 추가해서 규칙 문제를 풀기. 안 지켜지는 상황에서 더하면 희석만 심해진다.
2. 감지 장치부터 만들기. 순서는 ①없애기 ②기계화 ③표시 ④글로 쓰기. AI는 ②부터 꺼내니 "이 장치가 지키는 구조를 없앨 수 있나"를 먼저 물어야 한다.

🚀 앞으로의 계획

백업 자동화 → 저장소 해체 → 메모리 다이어트 → 용량 감시. 그다음에야 색인 공사고, 최종 목표는 그래프 뷰 — 문서 구조를 마인드맵처럼 뽑아 AI에게 지도를 통째로 건네는 것이다.

📋 재사용 프롬프트

내가 만든 [설계]를 적대적으로 검증해줘. 비평가 3명을 동시에, 서로 모르게 붙이고 각자 다른 렌즈를 줘: ①6개월 뒤 이게 어떻게 썩나 ②실제로 그렇게 작동하나 ③기존 것들과 충돌하나

칭찬 금지, 발견만. 주장 전에 실물을 읽고 근거를 파일·줄 번호로 대라. 결과가 오면 셋이 독립적으로 같은 곳을 지적한 항목부터 보여주고, 그 근거를 네가 직접 다시 확인해줘.

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

📝 한줄 요약

AI에게 문서 전체를 안 읽히려고 "지도"(문서 목차 파일)를 만들었다. 하루 만에 9개를 만들고, 시험하고, 전부 지웠다. 검색 명령 한 줄이 0.068초에 같은 일을 하고 있었기 때문이다. 그런데 지도를 버리고도 "필요한 부분만 골라 읽는 방식"은 살아남았다 — 만들어봤기 때문에 그 둘이 다른 문제라는 걸 알 수 있었다.

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

• 조사에서 "이런 도구 있다"고 나온 것 중 절반이 빈 껍데기였다 (설치는 되는데 실행 파일이 없음)
• 직접 만들어보니 핵심 기능은 정규식 다섯 줄. 유료 API가 필요한 건 그 위의 부가 기능이었다
• 전체 문서로 지도를 만드니 36만 토큰 — 애초에 한 번에 못 준다는 걸 만들고 나서 알았다
• 만든 지도를 AI에게 주고 시험했더니 절반만 맞혔다. 실패한 쪽이 더 중요한 정보였다
• 결국 검색 명령 한 줄에 밀려 폐기. 그런데 방식 자체는 따로 검증해서 살렸다 — 정확도 같고 읽은 양 절반
• 교훈 하나: 도구가 필요한가와 방식이 맞는가는 다른 질문이다. 섞으면 방식까지 같이 버린다

🎯 이런 분들께 도움돼요

• AI에게 자기 문서·메모를 읽히는 구조를 만들려는 분
• 지식 관리 시스템(PKM)에 AI를 붙여보려다 "뭘 만들어야 하지?"에서 멈춘 분
• 조사해서 도구를 고르는 단계에서 시간을 많이 쓰는 분

😫 문제 상황 (Before)

전날(1편) 문서를 필요할 때만 층층이 열리는 구조로 바꾸기로 설계를 끝냈다. 색인을 먼저 보여주고, AI가 거기서 필요한 문서만 골라 펴게 하는 방식이다.

설계는 끝났는데 실물이 없었다. 그래서 "지도"를 만들기로 했다. 각 프로젝트마다 문서 목록 + 그 안의 제목 + 몇 번째 줄인지를 담은 파일. AI가 그것만 보고 "3번 항목이 필요하네, 14번째 줄부터 읽자" 할 수 있게.

문제는 그걸 만들어야 하는지조차 확신이 없었다는 것이다. 이미 만들어진 도구가 있을 수도 있고, 만들어도 쓸모없을 수도 있었다.

🛠️ 사용한 도구

• Claude Code (Opus) — 조사·제작·검증 전부
• 검증 방법: 같은 AI를 별도로 띄워서(헤드리스) 문제를 풀게 하고 채점

🔧 작업 과정

조사에선 "이미 도구가 있다"고 했다

먼저 남들은 뭘 쓰는지 찾아봤다. 두 개가 나왔다.

하나는 ast-outline — 소개가 이랬다. "AI 코딩 에이전트가 파일 전체를 읽는 대신 필요한 것만 뽑게 한다. 마크다운도 지원." 내가 만들려던 그거였다.

또 하나는 PageIndex — "마크다운에서 계층 트리를 생성. 마크다운은 제목 계층이 명시적이라 PDF보다 빠르고 정확."

둘 다 딱 맞아 보였다. 여기서 멈췄으면 "도구 있으니 쓰자"로 끝났을 거다.

✅ 확인법: 설치해서 실행해봤다.

절반이 빈 껍데기였다

ast-outline  → 설치는 되는데 실행 파일이 없음. 설명란도 비어 있음 (이름만 선점한 상태)
PageIndex    → 설치되는 건 클라우드 서비스 접속용. 유료 API 키가 있어야 함

PageIndex는 공식 문서에 적힌 코드가 설치본에 아예 없었다. GitHub 원본을 직접 받아서야 돌아갔다.

✅ 확인법: 실행 파일 목록이 비어 있음 / import 실패 후 설치된 파일 목록 확인

그런데 그렇게 고생해서 돌린 결과물이 이거였다.

{"doc_name": "2026-08-04", "structure": [
  {"title": "1차 — 감지기 6개도 낡는 거 아니야?", "line_num": 5},
  {"title": "3차 — 메모리에 넣는 게 소용 있어?", "line_num": 14},
  ...

제목이랑 몇 번째 줄인지. 그게 전부였다. 원문 13,031자가 2,219자로 줄긴 했다.

그래서 직접 만들었다 — 다섯 줄

마크다운은 제목 앞에 #이 붙는다. 그러니 #으로 시작하는 줄만 골라 모으면 그게 목차다. 실제로 핵심은 정규식 한 줄이었고, 우리 규칙(한글 파일명, 문서 머리의 정보칸, 계획 문서 문법)에 맞추는 게 나머지였다.

PageIndex의 진짜 값어치는 그 위에 있었다 — 각 항목에 요약을 붙여주는 것. 그건 유료 API를 부른다. 그리고 원래 PDF용으로 만든 도구라 우리한테 필요 없는 짐이 잔뜩 딸려왔다.

✅ 확인법: 직접 만든 것과 PageIndex 결과가 같은 제목·같은 줄번호를 뱉는지 대조

전체로 만들어보니 애초에 불가능했다

전 문서에 돌렸더니 이랬다.

문서 1,769개 / 제목 19,641개
지도 크기 72만자 = 약 36만 토큰

한 번에 줄 수 있는 양이 아니었다. 게다가 무게의 75%가 남의 것이었다 — 참고하려고 받아둔 남의 프로젝트 하나가 43만자를 차지하고 있었고, 정작 내가 매일 만지는 문서는 전체의 0.5%였다.

그래서 각 프로젝트 문서 머리에 붙여둔 상태값(진행중·운영·잠듦 같은 것)으로 걸렀다. 지금 굴리는 것만 남기니 6.2만자. 프로젝트별로 쪼개면 대부분 1만자 이하였다.

✅ 확인법: 폴더별 크기를 표로 뽑아 어디가 무거운지 확인 → 상위 두 개가 전체의 75%

만든 지도를 AI에게 주고 시험했다

9개 프로젝트에 지도가 생겼다. 이제 진짜 질문 — 이게 쓸모가 있나?

별도로 AI를 띄워서 지도 파일만 읽게 하고 물었다. 다른 파일은 못 열게 막고.

그 지도만 보고 답해:
'PowerShell BOM 때문에 파서가 죽은 사고'가 어느 파일 몇 번째 줄쯤에 기록돼 있을 것 같나?
못 찾겠으면 '못찾음'이라고만 답해라.

답은 "못찾음"이었다.

공정한 시험이었는지 확인하려고 다른 질문을 했다.

그 지도만 보고: '이 프로젝트의 최종 목표'가 적힌 파일과 줄번호를 답해라.

이번엔 정확히 맞혔다. 00_전체그림.md:7.

차이가 뭐였냐면 — 실패한 질문의 그 내용은 제목이 ⓪ 백업 실물 가동인 절 안에 있었다. 제목만 봐선 그 안에 그 얘기가 있는 줄 몰랐던 것이다.

✅ 확인법: 정답을 내가 알고 있으니 채점 가능. 두 문제의 성패가 갈린 지점을 비교

그리고 한마디에 전부 지웠다

여기까지 왔을 때 이런 말을 들었다.

지도 파일이 왜 필요한지 잘 모르겠고, 그냥 마크다운 문서에 따라서 순차적으로
제목을 먼저 훑고 필요하면 더 깊이 들어가는 식으로 해주면 되는 거 아니야?
그거는 파일이 아니라 지침에서 하거나, 기계적으로 강제하면 되는 거 아닌가?

재봤다. 검색 명령으로 제목만 뽑는 데 0.068초. 프로젝트 전체 87개 제목을 훑는 데 0.049초.

미리 만들어둔 지도는 문서가 바뀌면 낡는다. 검색은 늘 최신이다.

지도 파일 9개와 생성기를 지웠다. 같은 이유로, 그 전에 세웠던 백과사전식 색인(어떤 단어가 어디에 몇 번 나오는지) 계획도 접었다. 검색으로 "BOM"을 찾는 데 0.9초, 정확한 줄까지 나왔다.

종이책 뒤에 색인이 붙는 이유는 종이엔 검색이 없어서였다. 우린 있다.

✅ 확인법: 같은 결과를 뽑는 데 걸린 시간을 직접 측정(time)

그런데 더 근본적인 질문이 왔다

근데 이걸 하기 전에, 우선 제목부터 순차적으로 읽었을 때
과연 AI가 더 잘 파악할까? 오히려 더 놓치는 거 아닐까?

맞는 걱정이었다. 그날 나는 실제로 그 실수를 했다 — 긴 기록에서 한 구절만 뽑아 읽고 목적을 잘못 이해해서, 며칠간 엉뚱한 방향으로 작업하고 있었다.

지도가 필요 없다는 건 확인했지만, 방식 자체가 나은지는 안 재봤던 것이다.

그래서 실험했다. 같은 문서(251줄), 같은 질문 3개, 두 가지 방식으로.

• A: 문서를 통째로 읽고 답하기
• B: 제목만 먼저 훑고, 필요한 절만 골라 읽고 답하기

질문 중 하나는 일부러 어렵게 냈다. "이 문서에 AI가 사용자 발화를 오독한 사례가 나오나?" — 그 내용은 여러 절에 흩어져 있고, "오독"이라는 단어로 검색해도 안 나온다.

정확도는 같고 읽은 양은 절반. 어려운 문제도 제목을 보고 그 절을 골라 읽어서 맞혔다.

✅ 확인법: 같은 질문·같은 문서로 두 번 돌려 답을 채점하고, 읽은 줄 수를 세게 함

✅ 결과 (After)

Before vs After

하루 종일 만들고 남은 것

파일로 남은 건 없다. 대신 세 가지를 알게 됐다.

1. 지도 파일은 필요 없다 — 검색이 더 빠르고 늘 최신이다
2. 방식은 유효하다 — 정확도 손해 없이 읽는 양이 절반
3. 되는 조건이 있다 — 제목이 내용을 대표할 때만. 제목이 껍데기면 통째로 읽을 수밖에 없다

3번이 제일 값졌다. 다음에 할 일이 "장치 만들기"에서 "제목 잘 쓰기"로 바뀌었기 때문이다. 실제로 내 할 일 목록 파일은 제목이 다음 / 마일스톤 / 이슈 / 한 일 네 개뿐이라 안에 뭐가 있는지 하나도 안 보인다. 거기부터 손보면 된다.

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

효과적이었던 것

1. 조사 결과는 돌려보기 전엔 확정이 아니다. "마크다운 지원 CLI"가 빈 껍데기였고, "설치 한 줄"이 유료 서비스 접속용이었다. 둘 다 소개글만 보면 완벽했다.
2. 만들기 전에 대상부터 재본다. 지도를 다 만들고 나서야 36만 토큰이라 못 준다는 걸 알았다. 먼저 쟀으면 범위를 좁혀서 시작했을 것이다.
3. 판정 기준을 먼저 정하고 시험한다. "쓸모 있나?"는 채점이 안 된다. "이 질문에 답하나?"는 채점이 된다. 정답을 내가 아는 질문을 골라야 한다.
4. 실패한 시험이 더 많은 걸 알려준다. 지도가 못 맞힌 질문 하나가 "제목이 내용을 대표해야 한다"는 조건을 드러냈다. 성공한 질문에선 안 나왔을 정보다.

이렇게 하면 안 돼요

1. "도구가 필요한가"와 "방식이 맞는가"를 섞지 마세요. 지도 파일이 필요 없다는 결론에서 멈췄으면, 방식까지 같이 버릴 뻔했다. 따로 재보니 방식은 살아 있었다.
2. 만들었다는 이유로 붙잡지 마세요. 하루를 썼어도 검색 한 줄이 더 나으면 지우는 게 맞다. 안 지우면 그때부터 그 파일을 관리해야 한다.
3. "안 만들어도 되겠지"로 건너뛰지도 마세요. 만들어봤기 때문에 필요 없다는 걸 안 것이다. 안 만들었으면 계속 "지도가 없어서 안 되나 보다" 했을 것이다.

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

• 자동화 도구를 고르기 전에 처리할 대상부터 세보기. 개수·용량을 재면 후보 절반이 저절로 걸러진다
• AI에게 긴 자료를 줄 때 목차를 먼저 주고 필요한 부분만 지정하기. 자료를 통째로 붙여넣는 것보다 정확도 손해가 없다
• 회의록·업무일지 제목을 내용이 드러나게 쓰기. 나중에 찾을 때 목차만 봐도 되는지가 여기서 갈린다

🚀 앞으로의 계획

장치를 더 만드는 대신 문서 제목부터 손본다. 할 일 목록 파일에 완료된 항목이 12개나 섞여 있고(미완은 8개), 한 항목이 400자까지 늘어난 상태다. 정리하면 그게 곧 "필요한 부분만 읽는 구조"를 만드는 일이기도 하다.

그리고 그 구조가 다시 무너지지 않게 기계가 검사하게 만들 생각이다. 규칙은 이미 있는데 안 지켜진 상태라, 규칙을 한 줄 더 쓰는 건 답이 아니라는 걸 이미 여러 번 확인했다.

📋 재사용 가능한 프롬프트

프롬프트 1: 도구를 고르기 전에 대상부터 재기

이 작업을 위한 도구를 고르기 전에, 처리할 대상부터 실측해줘. [대상 폴더/파일]의 개수·용량·종류별 분포를 표로 보여주고, 그 수치가 도구 선택을 바꾸는 지점이 있으면 짚어줘. 재보기 전에는 도구를 추천하지 마.

프롬프트 2: 만든 것이 쓸모 있는지 채점하기

방금 만든 [결과물]이 실제로 쓸모 있는지 시험하려고 해. 내가 정답을 아는 질문 3개를 낼 테니, 너는 [결과물]만 보고 답해. 다른 파일은 열지 마. 모르겠으면 '못찾음'이라고만 답해. — 질문 중 하나는 일부러 어려운 걸 넣으세요. 실패한 질문이 조건을 드러냅니다

프롬프트 3: 두 방식 비교하기

같은 자료·같은 질문으로 두 방식을 비교해줘. A안: [방식 1]로 답하기 B안: [방식 2]로 답하기 각각의 정답 여부와 읽은 분량(줄 수)을 같이 보고해줘.

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