월간 아루나 창간호 · 2026년 7월 14일 ~ 8월 12일
이번 달의 질문
작업을 끝내면 정리는 밀렸다
나는 하나에 몰입하면 작업은 끝내지만, 기록·정리·사례글·포트폴리오는 늘 밀렸다.
자동화를 마지막이 아니라 시작에 붙였다
그래서 이번 달에는 “정리할 에너지를 남기자”가 아니라, 정리하지 않아도 결과가 남는 구조를 만들자고 생각했다.
하는 동시에 그게 바로 결과로 나오는, 거울처럼 비쳐지는 자동화.
살아남는 시스템의 조건
기록 시스템은 여러 번 만들고 죽였다. 살아남는 방식은 분명했다.
| 살아남은 것 | 죽은 것 |
|---|---|
| 다른 작업에 붙어 저절로 돌아감 | 따로 열고 입력하고 관리해야 함 |
| 글을 쓰면 위키가 됨 | 기록을 위해 다시 기록해야 함 |
| 프로젝트가 끝나면 포트폴리오가 남음 | 나중에 정리할 일을 남김 |
파일을 고치면 결과물도 함께 바뀌어야 했다
그래서 조건을 하나 세웠다. 파일만 고치면 결과물이 함께 바뀌어야 한다.
네 갈래로 한 일
한 달의 작업 지도
| 갈래 | 기간 | 핵심 작업 |
|---|---|---|
| 23기 챌린지 | 7/14~8/13 | 4주 26개 Day 페이지 제작·운영, 갤러리 공개 |
| 시스템 개편 | 7/27~8/8 | 폴더·백업 진단, 레포 40→32, 하네스 리팩터링 |
| 대시보드 | 7/29~8/10 | 계획.md·미션보드·BM 층·레벨제·로드맵·PRD |
| 아루나 사이트 | 7/30~8/12 | 위키=책 정의, 구조 개편 13커밋, 갤러리 배포 |
따로 보였지만 같은 방향이었다
사이트, 대시보드, 스터디, 시스템 정리는 달라 보였지만, 결국 한 번 한 일을 다시 손으로 정리하지 않아도 되게 하려는 일이었다.
개별 사건은 사례글 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