버려야 정리가 된다

물건이 많으면 관리 비용이 든다. 문서도 마찬가지다.

많으면 많을수록 정리하는 데 시간이 들고, AI 시대엔 거기서 끝이 아니다. 실제로 토큰도 든다.

버리지 않으면 정리는 영원히 끝나지 않는다.

내 위키가 계속 망하는 이유

파일이 늘어날수록 관리 비용은 기하급수적으로 커진다. 이게 엔트로피다.

자동화도 마찬가지다. RAW 데이터가 너무 많으면 자동화해도 결국 무너진다. 자동화는 엔트로피를 늦출 뿐, 막지 못한다.

자동화보다 정제가 먼저다.

폴더 구조가 정수기 역할을 한다

inbox → projects → area → PKM → archive
                              ↘
                           reserve (보류함) → 빠르게 배출

PKM 안에서도 단계가 있다.

RAW → 저널 → 블로그 → 뉴스레터 → 잡지 → 책
←── 거침 ──────────────────── 정제됨 ──→

블로그로 쓰면 저널보다 한 단계 정제된 거고, 뉴스레터로 묶으면 블로그 여러 개가 하나로 응축된다.

위키는 연결이 아니라 색인이다

정제를 거치면 문서는 고도화된다. 고도화된 문서엔 자연스럽게 목차가 생긴다. 위키는 그 목차들의 연결이다. 단순한 정보의 연결이 아니라, 정제된 정보의 연결.

실전: 6단계 정제 흐름

1단계. 전체 지도 — 버릴 기준 먼저

뭘 남길지 기준이 없으면 결국 다 남기게 된다. 내가 어떤 주제로 일하는지, 핵심 카테고리가 뭔지 먼저 한 장으로 잡는다.

2단계. 최대한 버리기 → 재고표

순서가 중요하다. 재고표부터 만드는 게 아니다.

전체 지도 기준으로 최대한 버리기
        ↓
살아남은 것들만 재고표에 올리기
        ↓
재고표 보면서 또 버리기

재고표는 전부 다 올리는 목록이 아니라, 실제 활성화된 문서들만 들어오는 목록이다.

| 파일명 | 위치 | 한줄 설명 | 상태 |
|--------|------|-----------|------|
| 사업계획서_v3 | projects/사업 | 23년 방향 초안 | 활성 |
| 자기소개_강의용 | area/소개 | 강의 소개 | 활성 |

3단계. 청킹 — 재사용 조각 뽑기

재고표에 살아남은 문서들에서 독립적으로 쓸 수 있는 조각을 꺼낸다.

조각마다 메타데이터를 달아둔다: 주제 / 스타일 / 길이 / 용도

4단계. 색인표 — 청킹을 꺼내 쓰기 쉽게

비슷한 조각이 여러 개 있을 때 대표 하나를 정하고 나머지는 용도별로 배치한다.

| 청킹명 | 스타일 | 용도 | 대표 |
|--------|--------|------|------|
| 소개_짧은버전 | 캐주얼 | SNS, 블로그 | ★ |
| 소개_강의용 | 격식체 | 강의 소개 | |
| 사업방향_한줄 | 간결 | 제안서, 소개 | ★ |

5단계. 대표 청킹 — 앞줄에 꺼내두기

지금 가장 자주 쓰는 것을 앞에 두고 주기적으로 갱신한다. 쌓아두는 아카이브가 아니라 살아서 쓰이는 도구로 운영하는 단계다.

6단계. 보류함 — 시스템을 깨끗하게 유지하기

보류함에는 두 종류가 들어온다.

• 비활성 문서 — 지금 당장 쓰지 않는 것
• 자리 미정 문서 — 어디 넣어야 할지 아직 모르는 것

이걸 바로 projects나 area에 넣으면 시스템이 서서히 지저분해진다. 보류함이 그걸 막아준다.

보류함 안에서도 자연스럽게 정제가 일어난다.

보류함
  ├── 쓸 만한 것      → 블로그·SNS 공유 or 판매
  ├── 나눌 수 있는 것  → 무료 공개
  └── 그것도 아니면   → 버림

계속 안 쓰이는 건 나중에 미련 없이 버릴 수 있게 된다.

마무리

버리지 않으면 정리는 끝나지 않는다. 정제가 먼저다.

아루나의 다른 프로젝트가 궁금하다면 → litt.ly/aluna

사소한 과정도 결과로 만드는 시스템 만들기

지난 글 [당신의 위키가 계속 망하는 이유 — 쌓지 말고 정제하라]의 후속입니다. 1부는 왜 만들었는지, 2부는 따라 만드는 법입니다.

1부. 왜 이걸 만들었나

세상은 쌓으라는데, 나는 반대다

다들 많이 쌓으라고 한다. 위키에, AI 메모리에, 무조건 맥락을 쌓으라고.

나는 반대다. 쌓지 말고 정제하라.

그런데 이 정제 방식에서 뜻밖의 선물이 나왔다.

정제하다 보면, 콘텐츠가 저절로 생긴다.

거친 기록 → 저널 → 블로그 → 강의 → 책
←──────── 정제될수록 ────────→

한 단계 정제할 때마다 더 다듬어진 글이 떨어진다. 따로 만든 게 아니라 정제하다 생긴 것이다.

문제는 그게 다 내 컴퓨터 안에만 갇혀 있었다. 블로그에 올리면 되는데, 그 한 가지가 너무 귀찮았다. 그래서 만들었다.

글을 쓰면 알아서 발행되는 사이트.

일기를 공개하는 게 아니다

먼저 오해부터 풀자. 일기는 밖으로 나가지 않는다.

일기 (비공개)
  ↓  AI가 글감을 뽑아줌
소재
  ↓  소재로 초안 작성
초안
  ↓  다듬고 '공개'로 전환
발행

일기는 재료일 뿐이다. 거기서 뽑아낸 글이 나간다.

AI에게 친구처럼 "오늘 이런 일 있었어" 하고 종알종알 떠들면, 글감을 다섯 개씩 뽑아준다.

별거 없는 하루라고 생각했다. 그 안에 콘텐츠가 이렇게 많을 줄 몰랐다.

결과란 괴롭게 짜내야 나오는 줄 알았다. 그런데 그냥 떠든 게 글이 된다.

블로그에서 멈추지 않는다

이건 그냥 블로그가 아니다.

프로젝트 (만드는 과정 연재 = 브랜딩)
   ↓ 완성되면
강의 (커리큘럼 = 판매)
   ↓ 결제 붙이면
쇼핑몰

만드는 과정을 본 사람은 신뢰가 쌓여 구매로 온다. 과정이 곧 영업이다.

내가 떠든 일상이 글이 되고, 발행되고, 강의가 되고, 이 모든 게 모여 브랜딩이 된다. 좌충우돌한 과정과 결과가 한곳에 다 보인다. 그리고 이 흐름이 저절로 돈다. 힘 안 들였는데 계속 굴러간다.

2부. 따라 만들기

비개발자도 할 수 있다. AI(클로드 코드 같은)에게 시키면서 따라가면 된다. 큰 순서는 이렇다.

Step 1. 사이트 틀 만들기

Next.js로 빈 사이트를 하나 만든다. 터미널에 이 한 줄이면 된다.

npx create-next-app@latest my-site

npm run dev 를 치면 내 컴퓨터에서 사이트가 뜬다. 브라우저에서 localhost:3000 으로 확인한다.

정적 사이트 도구(Astro)도 있지만, 나중에 결제·로그인을 붙이려면 Next.js가 낫다.

Step 2. 글에 '태그' 붙이기

글은 마크다운(.md)으로 쓰고, 맨 위에 frontmatter를 붙인다. 사이트가 읽는 정보다.

---
공개: false      # true로 바꾸면 사이트에 뜬다
status: 진행중    # 진행중 / 완성 → 배지로 표시
type: 블로그      # 블로그 / 프로젝트 / 강의 → 어느 메뉴로
태그: [AI, 자동화]
title: 글 제목
---

여기부터 본문.

Step 3. 정해진 폴더에 넣기

글을 종류별 폴더에 넣는다. 블로그 글이면 content/blog/ 안에.

my-site/
└── content/
    └── blog/
        └── 오늘쓴글.md   ← 여기 넣으면 끝

Step 4. 폴더를 읽어서 자동으로 띄우게

사이트가 그 폴더를 스스로 훑어서 공개: true인 글만 골라 카드로 띄우게 만든다. 이 부분은 AI에게 이렇게 시키면 된다.

"content/blog 폴더의 .md들을 읽어서 공개가 true인 것만 최신순으로 목록에 보여줘."

한 번 만들어 두면, 그다음부터는 코드를 안 건드린다.

Step 5. 글만 쓰면 끝

이제 글 파일 하나를 폴더에 넣으면 카드가 자동으로 생긴다.

정말 그런지 의심돼서 가짜 글을 하나 넣어봤다. 자동으로 떴다.

한 가지 원칙 — 진실은 한 곳

이게 안 꼬이는 비결이다. 진실은 내 문서 한 곳에만 둔다. 사이트는 그걸 비추는 거울일 뿐이라, 문서를 고치면 사이트가 따라 바뀐다. 사이트를 따로 손댈 일이 없다.

검색 노출(SEO)도 처음에 챙겨 두면 좋다. sitemap·robots 파일을 만들고 글마다 제목·설명이 다르게 나오게 해 두면, 잘만 하면 블로그만큼 노출된다. 이것도 AI에게 시키면 된다.

같은 고민이 있다면

머릿속엔 많은데 세상에 못 내보이는 사람에게 권하고 싶다.

블로그도 유튜브도 꾸준히 못 하는 건 그게 쉽지 않아서다. 쉬우면 한다.

쌓지 말고 정제하면 콘텐츠가 저절로 생긴다. 글 위에 태그 한 줄 붙여 두면 알아서 흘러나가 나를 보여준다. 거창한 기술이 아니라 그 흐름 하나를 만든 것뿐이다.

아루나의 다른 프로젝트가 궁금하다면 → litt.ly/aluna

📝 한줄 요약

폴더 구조가 잘못돼서 시스템이 복잡해졌다고 믿고 전면 개편을 하려 했는데, AI와 하루 종일 대화한 끝에 원인이 git을 백업 용도로 오용한 것임을 찾았다. 도구를 원래 용도로 되돌리자 그동안 덧붙였던 규칙들이 같이 사라졌다.

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

• 겉으로 보이는 폴더 구조는 단순한데 머릿속에서 시스템이 안 잡혔다. 원인은 폴더가 아니라 그걸 감싸고 있던 git 구조였다
• 구글드라이브 동기화가 git과 충돌 → 백업 포기 → 대체재로 git을 백업에 씀. 여기서부터 꼬였다
• 갈아엎어야 하는 줄 알았던 최상위 폴더 구조는 이미 업계에서 쓰는 방식에 가까웠다. 안 바꿔도 됐다
• git 오용을 걷어내자, 그 이상한 구조를 유지하려고 누덕누덕 붙였던 예외와 규칙이 같이 사라졌다
• 규칙이 자꾸 늘어나는 건 해결이 아니라 증상이었다
• 아직 다 정리되진 않았다. 하지만 원인이 뭔지, 뭘 해야 할지 가닥은 잡혔다

🎯 이런 분들께 도움돼요

• 바이브 코딩하다가 git을 백업인 줄 알고 쓰고 있는 비개발자
• AI한테 시스템 관리를 맡기고 싶은데 "AI가 뭘 놓치는지 내가 모른다"가 불안한 사람

😫 문제 상황 (Before)

시작은 백업이었다.

원래는 구글드라이브 실시간 동기화로 작업 폴더를 통째로 백업하고 있었다. 그런데 이게 git과 맞지 않았다. 동기화가 돌면서 git 내부 파일을 건드려 문제가 생겼다. 그래서 드라이브 백업을 포기했다.

문제는 그다음이다. 백업 수단이 사라지자, git으로 백업을 하기 시작했다.

git은 원래 코드 되돌리기와 배포용 도구지 백업 도구가 아니다. 하지만 당시엔 "GitHub에 올려두면 안전하다"는 감각이 있었고, 그래서 굳이 git을 쓸 필요 없는 폴더까지 전부 레포로 만들어 올렸다. 문서만 있는 폴더, 개인 기록, 실험하다 만 것까지.

여기서부터 구조가 이상해졌다.

• 백업하려고 레포를 만들다 보니 레포 개수가 계속 늘었다
• 폴더를 옮기면 그 안의 git이 따라다니면서 꼬였다. 큰 프로젝트 폴더 안에 작은 프로젝트를 넣으면 git 안에 git이 들어가는 상태가 됐다
• 이 이상한 상태를 유지하려고 예외와 규칙을 계속 덧붙였다. "이 폴더는 이렇게, 저 폴더는 저렇게"

그러다 어느 순간 내 시스템인데 내가 파악을 못 하게 됐다.

겉으로 보이는 폴더는 단순했다. 최상위에 열 개 남짓. 그런데 그걸 감싸고 있는 git 구조가 이상하니까, 머릿속에서 전체 그림이 두루뭉실하게만 잡혔다. 그래서 폴더를 옮기는 게 무서워졌다. 원래 내 방식은 "작업하다 보면 이 폴더는 저쪽으로 옮기는 게 낫겠다" 싶으면 옮기는 건데, 깨질까 봐 못 옮겼다.

시스템이 나를 못 움직이게 만들고 있었다.

이 상태로는 안 되겠다 싶어서 "폴더 구조를 대대적으로 갈아엎자"고 마음먹고 AI와 대화를 시작했다.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus 5 (1M) / Claude Fable 5 — 교차 검증에 두 모델을 번갈아 사용
• 특이사항: 조사·감사에 서브에이전트를 병렬로 여러 개 돌림

🔧 작업 과정

"왜 자꾸 깃을 빼먹니?" — 세 번 말하고서야 확인된 문제

처음에 나는 이중 git 문제를 걱정했다. 큰 프로젝트 폴더 안에 다른 프로젝트를 넣으면 git이 겹치는 것 아니냐고.

AI는 문제없다고 했다. 두 번을 물었는데 두 번 다 괜찮다고 했다. 세 번째로 콕 집어서 다시 물었다.

지금 자꾸 깃이 문제가 없다고 하는데, 내가 생각하기에는 이런 문제가 있는데.
정말 그게 문제가 안 되는 게 맞아?

그제야 AI가 실제로 폴더 트리를 전부 스캔했고, 이중 git이 4곳 실재한다는 걸 찾아냈다. 내 직감이 맞았던 것이다.

이때 알았다. AI는 내가 콕 집어 말하지 않으면 넘어간다. 그리고 여기서 더 큰 문제로 이어졌다.

"내가 감지 못한 문제는, AI도 못 고친다"

이게 이날의 진짜 발견이었다.

내가 문제를 감지하지 못하면 애초에 네가 문제인지도 몰라서, 그걸 감지할 스크립트조차
네가 만들지 못한다는 거야. 개발에 대해 전혀 전문지식도 없는 사람이고, 파일을 하나하나
다 찾아보고 아는 사람도 아닌데. 내가 감지하지 못한 문제 너는 고치지도 못해.
그러다 보면 계속 구멍이 생기는데, 그 구멍을 감지하질 못하니까 구멍이 있는 줄도 몰라.

AI에게 시스템 관리를 맡길 때의 근본 한계다. AI는 시킨 건 잘한다. 그런데 "시켜야 할 게 뭔지"를 내가 모르면 아무 일도 안 일어난다. 그러면 구멍은 계속 생기는데 아무도 모른다.

AI의 첫 반응은 "감지 장치를 만들자"였다. 점검 스크립트를 만들고, 정기 감사를 돌리고, 경고를 띄우자는 것. 나는 그게 더 걱정됐다. 그럼 내가 파악 못 하는 층이 하나 더 늘어나는 거니까.

규칙을 더 만드는 게 아니라, 종류를 줄이는 것

여기서 방향이 바뀌었다.

어떤 시스템이든 파악하기 어려운 건 좀 별로인 것 같아. 물건이 아주 많아도 제대로 된
원칙으로 정리돼 있으면 파악이 가능하거든. 근데 애초에 정리를 잘하려면 정리할 물건
자체를 제한해야 돼. 미니멀라이프랑 비슷한 거지.

그리고 내가 예전에 쓴 글 하나를 AI에게 읽혔다.

그런데 미니멀위키 프로젝트 한번 확인해 봐. 내가 말한 걸 조금 더 이해할 수 있을 거야.

6월에 내가 쓴 「당신의 위키가 계속 망하는 이유」라는 글이었다. 거기엔 이미 이렇게 써 있었다. "자동화는 엔트로피를 늦출 뿐이다. 정제가 먼저다."

내가 이미 내린 결론이 있는데, AI는 그걸 모르고 반대 방향(감시 장치를 더 쌓는 쪽)으로 가고 있었던 것이다. 이 글을 읽은 뒤 AI가 설계 방향을 바꿨다. 제거 > 자동화 > 감시라는 우선순위로.

나 같은 사람이 또 있나 — 열 갈래 조사

방향은 잡혔는데, 내 방식 자체가 이상한 건 아닌지 확인하고 싶었다.

지금 내가 겪고 있는 이런 문제를 다른 사람들은 어떻게 해결을 해? 나처럼 하는 사람들이
있어? 없다면 왜 없는지. 그런 걸 네가 좀 자세하게 전수조사해봐.

AI가 조사 담당을 열 갈래로 나눠서 동시에 돌렸다. 나온 것 중 결정적이었던 것들:

• "git은 백업이 아니다"가 개발자 세계의 컨센서스였다. 버전관리와 백업은 다른 일이라는 게 상식이었다. 내가 몰랐던 것
• 개발자들은 폴더를 안 옮긴다. 프로젝트가 완료돼도 폴더를 이사시키지 않고, 상태는 GitHub 쪽 설정(보관 토글·배지)으로 표시한다
• 업계 표준 폴더 구조 같은 건 없었다. dev.to 창업자조차 "나는 dev라는 폴더 하나가 있고 그냥 큰 쓰레기통이다"라고 답했다
• 대형 프로젝트 국제표준(ISO 19650)은 생애주기를 폴더가 아니라 '상태 코드'로 관리한다. 위치가 아니라 표시로
• 내가 참고했던 Johnny Decimal은 창시자가 "1인 사업자 케이스는 아직 못 풀었다"고 공식 인정하고 있었다

그리고 하나 더. 내 조합(폴더 이동 + git + 문서와 코드 혼합 + AI 위임)과 정확히 같은 선례는 없었다. 원래 안 섞이는 두 세계를 붙이는 축이라서.

뒤엉킨 문제를 세 개로 쪼개기

조사 결과를 보고 나서 생각이 바뀌었다.

차라리 폴더 구조를 고정으로 가는 거지. 옮기지 않게. 그리고 그 안에서 필요한 프로젝트만
레포로 관리하고. 내가 백업을 하려고 해서 이런 구조가 나온 것 같거든?
백업을 git으로 처리하려고 한 것 자체가 문제였던 것 같기도 해.

AI가 여기서 논의를 세 축으로 분해했다.

쪼개고 보니 명확해졌다. 내가 "대대적 개편"이라고 부르던 것의 실제 차이는 첫 번째 축 하나뿐이었다. 나머지 둘은 이미 답이 나와 있었다. 백업은 백업 도구로, git은 원래 용도로.

그래서 아무것도 안 바꿔도 됐다

설계를 확정하고 보니 결론이 이랬다.

최상위 폴더 구조는 그대로 둔다. 조사해보니 내 폴더 구조는 이미 기록관리에서 수십 년간 살아남은 "기능 기반 분류"에 가까웠다. 갈아엎을 이유가 없었다.

바꾼 건 그걸 감싸던 쪽이다.

• 시스템은 폴더 위치를 읽지 않는다. 진행 상태는 각 폴더의 README에 적힌 정보로 판단한다. 위치는 사람이 보기 편하려고 있는 것
• git은 원래 용도로만. 코드 되돌리기와 배포에만. 백업하려고 만든 레포는 걷어낸다
• 백업은 백업 도구로. 구글드라이브 같은 실시간 양방향 동기화 말고, 개발자들이 쓰는 단방향 스냅샷 방식. 외장하드나 개인용 NAS도 가능하다

그리고 위치와 관련해 만들어뒀던 규칙 6개를 폐기했다. "z_reserve로 가면 레포를 접는다", "프로젝트로 승격하는 순간 git을 만든다" 같은 것들. git 오용이 사라지니까 그걸 지탱하려고 붙였던 규칙들이 존재 이유를 잃은 것이다.

이게 이날 가장 좋았던 부분이다. 뭘 더 만들어서 해결한 게 아니라, 잘못 쓰던 걸 걷어내니까 나머지가 같이 사라졌다.

확인 한 번 더 — AI가 한 작업을 다른 세션에서 검증

설계 문서를 만드는 세션에서 AI가 좀 이상하게 대답한다는 느낌이 있었다. 그래서 새 세션을 열고 모델을 바꿔서 시켰다.

원본 세션이 파일로 보관돼 있잖아. 거기서 확인해서 모순되거나 이상하게 작업한 게 있으면
네가 전수조사해서 확인해줬으면 좋겠어. 냉정하게. 아주 꼼꼼히.

여기서 몇 가지가 나왔다. AI가 내 답변을 듣기도 전에 "확정"이라고 문서에 적어둔 것, 세어보겠다고 다섯 번 말하고 한 번도 안 센 숫자가 그대로 계획에 박혀 있던 것 등이다. 실제로 세어보니 그 숫자가 틀렸고, 그대로 진행했으면 살아있는 공개 레포 5개가 잘못 접힐 뻔했다.

내가 잡아낸 게 아니라 AI에게 시켜서 나온 결과다. 같은 세션 안에서는 자기가 방금 내린 결정을 잘 못 뒤집는데, 세션과 모델을 바꾸니까 냉정하게 봤다.

대시보드를 처음 펼쳐보고

정리 작업을 절반쯤 진행한 뒤, 전체 현황을 한 화면에 띄웠다. 처음 보는 화면이었다.

이렇게 펼쳐놓고 보니까 내가 괜히 파악을 못 하는 게 아니구나라는 생각이. 뭔가 많고
복잡한데? 뭐가 뭔지 잘 모르겠고, 활성된 것과 비활성된 게 다 펼쳐져 있고, 보류된 것 중에서는
뭐가 왜 보류가 됐는지도 잘 모르겠고.

기분이 나쁘진 않았다. "내가 못 하는 게 아니라 실제로 복잡한 거였다"는 확인이었으니까. 그동안은 복잡한지 아닌지조차 볼 수가 없었다.

✅ 결과 (After)

Before vs After

솔직하게 남은 것

아직 다 정리되지 않았다. 레포 정리도 진행 중이고, 백업 도구도 아직 정식 도입 전이라 임시로 폴더를 통째 복사해두고 작업했다. 카테고리 정리와 보류함 정리도 남았다.

그래도 원인이 뭔지, 어떻게 해야 할지 가닥이 잡혔다. 그동안은 그것조차 몰라서 답답했다.

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

효과적이었던 것

1. 구조를 바꾸기 전에 "도구를 원래 용도로 쓰고 있나"부터 본다

나는 폴더 구조가 문제라고 믿고 전면 개편을 하려 했다. 실제 원인은 백업 도구가 아닌 걸 백업에 쓴 것이었다. 갈아엎을 문제가 아니라 오용 문제였다.

AI에게 물을 때도 "이 구조 어떻게 바꿀까"보다 "내가 이 도구를 원래 용도대로 쓰고 있는 게 맞아?"가 훨씬 좋은 질문이었다.

2. 규칙이 자꾸 늘어나면 그건 답이 아니라 증상이다

문제가 생길 때마다 규칙을 하나씩 붙였다. "이 경우엔 이렇게 하자." 그게 쌓여서 내가 내 시스템을 파악 못 하게 됐다.

예외를 계속 덧붙여야 유지되는 구조는 이미 틀어진 것이다. 규칙을 잘 만드는 게 아니라, 규칙이 필요 없어지게 만드는 쪽을 봐야 했다.

이렇게 하면 안 돼요

AI가 "문제없습니다"라고 하면 그냥 넘어가는 것

이중 git 문제는 두 번을 물었는데 두 번 다 괜찮다는 답이 왔다. 세 번째로 콕 집어 말하고 나서야 실제로 세어봤고, 4곳이 나왔다. 직감이 계속 걸리면 "실제로 확인해봐"라고 시켜야 한다.

AI가 제안하는 대로 장치를 계속 늘리는 것

AI는 문제를 발견하면 대체로 뭔가를 추가해서 해결하려 한다. 점검 스크립트, 자동 감사, 경고 알림. 그때마다 내가 파악 못 하는 층이 하나씩 늘어난다. 비개발자에겐 이게 특히 위험하다. 더하는 방향으로 갈 때 한 번쯤 "빼는 방법은 없어?"라고 물어보는 게 좋다.

🌍 다른 업무에 적용한다면

이 방식은 폴더 관리 말고도 쓸 수 있다.

• 엑셀·노션이 계속 무거워질 때: 시트를 재설계하기 전에, 원래 그 도구가 할 일이 아닌 걸 억지로 시키고 있는 건 아닌지 본다
• 업무 규칙이 자꾸 늘어날 때: 규칙을 정리하기 전에, 규칙을 만들게 하는 원인 자체를 없앨 수 있는지 본다
• AI에게 뭔가 맡기고 불안할 때: 같은 작업을 다른 세션이나 다른 모델에게 검증시킨다

🚀 앞으로의 계획

• 백업 도구 정식 도입 (임시로 통째 복사해둔 상태)
• 레포 정리 마무리 — 백업용으로 만들었던 것들 걷어내기
• 카테고리 정리와 보류함 정리
• 현황을 한눈에 보는 칸반보드

📋 재사용 가능한 프롬프트

프롬프트 1: 구조를 갈아엎기 전에 원인 확인하기

지금 [내 시스템/폴더/작업 방식]이 복잡해서 관리가 안 된다고 느껴. 그래서 [구조를 전면 개편]하려고 하는데, 그 전에 확인하고 싶은 게 있어.

혹시 진짜 원인이 구조가 아니라, 내가 어떤 도구를 원래 용도가 아닌 데 쓰고 있어서일 가능성은 없어? 내가 지금 쓰는 도구들이 각각 원래 용도대로 쓰이고 있는지 하나씩 짚어줘. 오용하고 있는 게 있으면 그것 때문에 파생된 문제도 같이 알려줘.

프롬프트 2: 규칙을 늘리는 대신 줄이기

이 문제를 해결하려고 규칙이나 자동화 장치를 추가하려는 것 같은데, 잠깐 멈춰줘.

규칙을 더하는 방법 말고, 문제 자체가 없어지게 만드는 방법은 없어? 다음 순서로 검토해줘: ①이 종류를 아예 없앨 수 있나 ②없앨 수 없다면 자동화할 수 있나 ③자동화도 안 되면 그때 감시 장치. 1번부터 검토하고, 3번으로 가야 한다면 왜인지 설명해줘.

프롬프트 3: AI가 한 작업을 다른 세션에서 검증하기

이전 세션에서 작업한 [문서/코드]가 좀 미덥지 않아. 원본 대화 기록이 남아 있으니 그걸 기준으로 검증해줘.

• 내가 실제로 요청한 것과 결과물이 일치하는지
• 내가 승인하지 않은 걸 "확정"으로 적어둔 게 있는지
• 문서에 적힌 숫자나 사실이 실제로 확인된 것인지, 추정인지

냉정하게 봐줘. 문제가 없으면 없다고 해도 되는데, 있으면 근거와 함께 알려줘.

마무리

전면 개편을 각오하고 시작했는데, 결론은 "폴더는 그대로 두고 잘못 쓰던 도구만 제자리로"였다. 복잡해 보이는 문제일수록 구조를 손대기 전에 뭘 오용하고 있는지부터 보는 게 빠를 수 있다.

아직 진행 중인 작업이라 깔끔한 완결은 아니다. 그래도 원인을 알고 움직이는 것과 모르고 답답한 건 완전히 다르다.

아루나의 다른 프로젝트가 궁금하다면 → litt.ly/aluna

작업 기록과 프로젝트 현황은 여기에 정리하고 있습니다 → aluna-site.vercel.app

📝 한줄 요약

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

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

• 위키 마크다운을 발표 슬라이드로 보는 뷰를 만들었다. 슬라이드용 파일은 안 만든다 — 글 한 벌에서 조립
• 처음엔 생각보다 잘 됐다. 위키가 이미 단계별로 쪼개져 있어서
• 안 되는 데를 고치려고 변환 규칙의 기준값을 다섯 번 조정했는데, 하나 맞추면 다른 하나가 어긋났다
• 원인은 규칙이 아니라 원문이었다. 소제목 없이 줄줄 이어진 긴 문단
• 원문을 다듬자 한 챕터 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