내 사업 로드맵을 RPG 레벨제로 바꾼 이유

📝 한줄 요약

로드맵을 만들었는데 숫자가 안 움직였다. 하루 종일 일한 날도 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