AI 폴더링
AI와 같이 쓰는 폴더는 프로그램이 «주소»로 파일을 찾습니다. 그래서 저는 폴더 모양을 그리지 않고, 새 파일이 어디로 갈지 묻는 질문 넷으로 정리합니다.
AI 폴더링은 제가 AI와 함께 일하는 컴퓨터의 폴더와 파일을 정리하는 규칙입니다. 핵심은 하나입니다 — 폴더 모양을 먼저 그리지 않고, 새 파일이 생길 때마다 «이건 어디로 가야 하나»를 묻는 질문 넷으로 자리를 정합니다.
AI와 같이 쓰는 폴더는 «주소»가 생명입니다
흔히 아는 폴더 정리법은 사람이 나중에 다시 찾아 읽을 문서를 위해 만들어졌습니다. 사람은 파일이 다른 서랍으로 옮겨져도 몇 번 둘러보면 찾아냅니다.
AI와 같이 일하면 사정이 달라집니다. 제 작업 폴더의 상당수는 사람이 아니라 프로그램이 읽고 씁니다. AI에게 일하는 법을 적어 준 설명서(스킬), 정해진 시각에 저절로 도는 스크립트, 그 실행 결과, 잠깐 쓰고 버리는 임시 파일 같은 것들입니다.
프로그램은 파일을 경로로 찾습니다. 경로는 파일의 주소입니다. C:\work\개인사이트\docs\a.md 처럼 폴더 이름을 차례로 이어 붙인 것이죠. 주소가 바뀌면 프로그램은 둘러보지 못하고, 그 자리에서 멈춥니다.
| 사람만 쓰는 폴더 | AI와 같이 쓰는 폴더 | |
|---|---|---|
| 누가 찾나 | 사람이 눈으로 훑는다 | 프로그램이 주소로 곧장 간다 |
| 폴더를 옮기면 | 잠깐 헤맨다 | 그 주소를 쓰던 일이 멈춘다 |
| 그래서 정리란 | 보기 좋게 다시 나누기 | 처음부터 맞는 자리에 두기 |
자리는 질문 넷으로 정합니다
새 파일이 생기면 위에서부터 차례로 묻습니다. 앞 질문에서 자리가 정해지면 거기서 멈춥니다.
- 비밀값인가? 비밀값은 서비스에 들어가는 열쇠(API 키나 토큰)입니다. 이건
secrets폴더로 갑니다. 두 PC가 같이 쓰지만, 깃허브 같은 공개 저장소에 올라가는 폴더와는 떨어뜨려 둡니다. - 사진이나 영상처럼 큰 파일인가? 그러면 작업 폴더 밖(내 문서)에 둡니다. 작업 폴더는 통째로 클라우드에 백업되는데, 큰 파일은 그대로 돈이 됩니다.
- 어느 도구가 만들었나? 그 도구의 폴더 바로 밑에 둡니다. 도구는 여기, 결과는 저 멀리 두면 나중에 둘을 이어 줄 사람이 없습니다.
- 클라우드에 올릴 필요가 있나? 없으면 그 자리에
_no_sync라는 하위 폴더를 만들어 넣습니다. 이 이름 하나로 백업에서 빠집니다.
이름 하나가 규칙을 대신합니다
넷째 질문이 이 체계에서 제일 오래 살아남았습니다. 묻는 것이 하나뿐이고, 답이 «예» 아니면 «아니오»라서입니다.
처음엔 크기로 정하려 했습니다. 그런데 실제로 재 보니 남겨야 할 가장 큰 폴더가 849MB였고, 지워도 되는 폴더 중에 404MB짜리가 있었습니다. 크기를 기준으로 삼았다면 정반대로 판정했을 겁니다.
이 규칙은 사람이 기억할 필요도 없습니다. 백업 설정에 «_no_sync 는 빼라»는 줄이 하나 있고, 그 줄은 폴더가 얼마나 깊이 있든 이름만 맞으면 잡아냅니다. 앞으로 만들 도구까지 미리 덮는 셈입니다.
이 규칙이 생긴 이유: 백업 도구의 기본값이 «전부 올리기»라서, 아무도 올리기로 정한 적 없는 결과물 11GB가 클라우드에 쌓여 있었습니다(2026-07-27 정리).
폴더는 옮기지 않고, 목록에서 옮깁니다
유명한 정리법 PARA는 끝난 프로젝트를 «보관» 폴더로 옮기라고 합니다. 저는 옮기지 않습니다. 옮기는 순간 주소가 깨지기 때문입니다.
대신 목록 파일에서 상태만 바꿉니다. 목록 파일(인덱스)은 무엇이 어디 있고 지금 어떤 상태인지 적어 둔 차례표입니다. AI의 기억 목록이 이렇게 돕니다. 45일 동안 안 쓴 항목은 목록 맨 아래 «졸업» 칸으로 내려가지만 파일 자체는 제자리에 있고, 다시 읽는 순간 원래 칸으로 돌아옵니다.
목록에도 정원이 있습니다. AI는 이 목록을 대화 첫머리에 읽는데, 정해진 크기를 넘으면 뒷부분을 조용히 못 읽습니다. 그래서 줄마다 글자 수 한도를 두고 검사 스크립트가 매번 잽니다.
AI 설정 폴더는 «늘 읽는 것»과 «필요할 때 여는 것»으로 나눕니다
제가 쓰는 AI(Claude Code)는 대화를 시작할 때마다 설정 폴더의 규칙을 읽습니다. 늘 읽는 규칙이 길어질수록 매번 그만큼 비용이 들고, 정작 중요한 규칙이 묻힙니다. 그래서 두 층으로 나눴습니다.
| 층 | 무엇 | 지금 |
|---|---|---|
| 늘 읽는 규칙 | 어떤 일을 하든 지켜야 하는 것 | 5개 |
| 필요할 때 여는 안내서 | 코드를 쓸 때나 커밋할 때처럼 상황이 정해진 것 | 13개 |
어떤 상황에 어떤 안내서를 여는지는 표 한 장에 적어 둡니다. 분야별 교훈은 그 분야 스킬 폴더 안에 둡니다. 같은 규칙을 두 곳에 두면 언젠가 둘이 달라지기 때문입니다. 정본(원본)은 하나만 둡니다.
남의 이론에서 가져온 것과 버린 것
이 규칙들은 남의 정리법을 읽고 제 환경에 대 보면서 나왔습니다. 맨 위 출처 링크가 그 원본입니다.
| 출처 | 가져온 것 | 버린 것 |
|---|---|---|
| PARA (Tiago Forte) — 주제가 아니라 «지금 얼마나 살아 있나»로 나눈다 | 끝난 것을 따로 표시한다는 생각 | 폴더째 옮기기 |
| Johnny.Decimal — 한 층에 열 개까지, 폴더마다 번호 | 한 층이 너무 많으면 못 훑는다 | 번호(주소에 박힌다) |
| 리눅스 폴더 표준(FHS) — 종류마다 자리가 다르다 | «지워도 되는 것»의 자리를 따로 둔다 | — |
| cookiecutter-data-science — 원본은 고정, 가공본은 언제든 다시 만든다 | «다시 만들 수 있나»라는 질문 | — |
| simonw/til — 폴더는 얕게, 목록은 기계가 만든다 | 목록이 정본이다 | — |
| Jeff Su 영상 — 사람을 위한 9분짜리 파일 정리법 | 임시 거처 · 목록 정원 · 깊이 상한 | 사람의 의지로 지키기 |
| project-layout 비판 — 남의 구조를 통째로 베끼면 빈 폴더만 남는다 | 통째 복사 금지 | — |
Jeff Su 영상과 제 설계를 하나씩 대 본 기록은 파일 관리 체계 편에 따로 있습니다.
아직 못 한 것
폴더 쪽은 아직 사람 눈에 맡겨져 있습니다. 기억 목록은 검사 스크립트가 크기와 줄 길이를 매번 재지만, 폴더 배치를 검사하는 스크립트는 설계만 하고 만들지 않았습니다. 「규칙은 사람 의지에 맡기지 않는다」고 써 놓고, 정작 여기서는 못 지키고 있는 셈입니다.
작업 폴더 전체의 차례표와, 어디에도 안 속하는 파일이 잠깐 머물 «임시 거처»도 아직 설계 문서에만 있습니다.
여기부터는 자세한 기록입니다
2026-08-03에 작업 폴더 최상위가 72개였습니다. 사람이 한눈에 훑을 수 있는 수를 넘었고, 같은 개념이 한글과 영문 두 이름으로 따로 있었고, 「임시」라고 이름 붙인 폴더가 몇 달째 남아 있었습니다. 그날 정리법 자료 스무 개(영상 열·저장소 열)를 모아 처방을 냈는데, 스스로 반박하는 검토에서 절반이 틀렸다는 판정을 받았습니다. 아래는 그 검토를 통과해 지금 실제로 쓰는 규칙이고, 설계만 하고 못 만든 것은 맨 끝에 따로 적었습니다.
첫 처방이 틀린 이유 — 사람용 정리법을 기계 작업장에 댔다
유명한 정리법(PARA·Johnny.Decimal·제텔카스텐)은 전부 사람이 다시 찾아 읽을 노트를 위한 개인 지식 관리 방법입니다. 그런데 제 작업 폴더의 70%는 기계가 소유한 디렉터리였습니다. 코드 저장소, 파이프라인, 캐시, 실행 산출물입니다.
| 계열 | 푸는 문제 | 기계 작업장에 |
|---|---|---|
| 개인 지식 관리 (PARA·Johnny.Decimal) | 사람이 다시 찾아 읽을 문서의 분류 | 안 맞음 — 상태가 바뀌면 폴더를 옮기는 게 전제 |
| 운영체제·코드 (FHS·모노레포) | 도구가 경로로 찾는 것의 배치 | 맞음 — 경로가 안 바뀌는 게 전제 |
| 데이터 (원본·가공본 분리, 날짜별 폴더) | 시점마다 쌓이는 산출물 | 맞음 — 분류가 아니라 시간으로 쪼갠다 |
유명한 방법이 죄다 첫째 계열인 건 그 시장이 크기 때문이지, 그게 정답이라서가 아니었습니다. 리눅스의 /usr /etc /var 는 수십 년 동안 수많은 기계에서 살아남았는데, 아무도 그걸 «정리 방법론»이라 부르지 않습니다. 유행이 아니라 기반 시설이라서입니다.
규칙 1 — 저장 위치는 «무엇이 만들었나»로 정한다
| 규칙 | 내용 |
|---|---|
| 1-1 결과는 만든 도구 옆 | 실행·분석 결과는 그것을 만든 도구나 프로젝트 폴더 밑에 둔다. 맞는 주제 폴더가 없을 때만 C:\work\<주제>\ 를 새로 판다 |
| 1-2 채팅에만 남기지 않는다 | 리포트·대조표·측정값·증거 사진은 파일로 저장한다. 채팅에는 요약과 경로만 |
| 1-3 이름에 내용과 날짜 | <주제>_<내용>_<날짜>.md 꼴. 날짜는 YYYYMMDD |
1-4 비밀값은 secrets |
클라우드 백업에는 올라가되(두 PC가 써야 하므로) 공개 저장소에는 절대 들어가지 않는 자리 |
| 1-5 큰 파일은 작업 폴더 밖 | 녹화·영상은 내 문서 쪽. 작업 폴더에는 보고서 HTML이나 JSON 같은 작은 것만 |
규칙 2 — 동기화 제외는 이름 하나로 한다
- 2-1 판정 질문은 하나다. 「이걸 클라우드에 올릴 필요가 있나」. 「다시 만들 수 있나」는 흔한 근거일 뿐 정의가 아닙니다. 테스트 증거 사진은 다시 못 찍지만 클라우드에 올릴 것도 아니라서 여기로 옵니다.
- 2-2 목적지까지 내려간 뒤에 만든다. 최상위
_no_sync한 곳에 몰지 않고, 그 결과를 만든 도구 폴더로 내려가서 거기에_no_sync를 팝니다. 최상위_no_sync는 소속 폴더가 아예 없는 일회성 조사만 받습니다. 한곳에 몰면 «동기화 제외»라는 성질 하나만 같은 잡동사니 서랍이 됩니다. - 2-3 제외 패턴은 깊이와 무관해야 한다. 백업 설정의 줄은
--exclude=_no_sync/**이고, 앞에/가 없어야 깊숙이 들어간_no_sync까지 빠집니다. 누가 앞에/를 붙여 최상위만 가리키게 바꾸면 중첩된 것이 전부 조용히 올라갑니다. - 2-4 크기로 판정하지 않는다. 위의 849MB·404MB 사례가 근거입니다.
- 2-5 동기화가 둘이고, 규칙은 서로 독립이다. 클라우드 백업(S3)은
_no_sync를 빼고, PC 사이 동기화(Syncthing)는 일부러 넣습니다. 그래서_no_sync는 바깥 백업은 없지만 사본은 두 대에 있습니다. 거꾸로 말하면 한쪽 PC에서 그 폴더를 지우면 다른 PC의 사본도 같이 지워집니다. - 2-6 PC마다 다른 자격증명 파일은 PC 사이 동기화에서 뺀다.
.env가 건너가면 두 PC가 서로의 설정을 덮어씁니다.
규칙 3 — 이름에 번호를 넣지 않는다
- 3-1 경로로 찾는 곳에서는 폴더 이름에 번호를 붙이지 않는다. 이유는 둘입니다. 번호가 주소에 들어가면 분류를 바꿀 때마다 주소가 깨집니다. 그리고 99를 넘기면 정렬이 깨집니다. 글자 순으로 비교하면
100_이10_앞에 끼어드는데(셋째 글자0이_보다 앞이라서), 윈도 탐색기는 숫자 크기 순으로 보여 줍니다. 눈에 보이는 순서와 프로그램이 보는 순서가 달라지는 겁니다. 구글 드라이브처럼 파일을 ID로 찾는 저장소라면 번호를 써도 괜찮습니다. - 3-2 예약어는 철자를 바꾸지 않는다.
_no_sync·secrets·_archive는 프로그램이 이름으로 붙잡는 단어입니다.no_sync나noSync처럼 비슷하게 쓰면 백업 규칙이 못 알아봅니다. 오타 하나가 곧 유출입니다.
규칙 4 — 옮기지 말고, 지우기 전에 격리한다
- 4-1 경로는 옮기지 않는 게 기본이다. 끝나거나 보관할 때도 폴더를 옮기지 않고 목록에 표시합니다.
- 4-2 딱 한 번 크게 옮겼다. 2026-08-03에 최상위 72개를 28개 그룹으로 묶었습니다. 62건을 옮겼고 잃어버린 건 없었습니다. 실행 중인 파이프라인에 경로가 박혀 있는 폴더는 동결해서 손대지 않았습니다. 지금도 최상위 폴더는 28개입니다(2026-10-01 실측).
- 4-3 지우기 전에 격리한다. 그날 정리한 978개는 바로 지우지 않고
_no_sync\_deleted_20260803\로 옮겨 두었고, 지금도 거기 있습니다. - 4-4 끝난 것은
_archive로. 되살릴 수는 있지만 다시 손대지는 않는 것들의 자리입니다.
규칙 5 — AI 설정 폴더는 «정본 하나, 목록은 라우팅표»
- 5-1 프로그램이 정한 이름은 건드리지 않는다.
skills·agents·rules는 Claude Code가 정한 고정 경로입니다. 바꾸면 스킬이 불리지 않습니다. 이 폴더는 이미 «종류별» 구조가 강제돼 있으니, 제 규칙은 그 안쪽에만 씁니다. - 5-2 규칙은 두 층이다. 늘 읽는 규칙(
rules/common, 5개)과 상황이 올 때 여는 안내서(guides, 13개). 어떤 상황에 무엇을 여는지는CLAUDE.md의 표 한 장에 있고, 같은 내용을 두 층에 다 적지 않습니다. - 5-3 기억 목록(
MEMORY.md)은 일지가 아니라 라우팅표다. 「어느 파일을 언제 열지」를 적는 곳입니다. 한 줄을 넣을지는 세 질문으로 정합니다.
| 질문 | 「예」이면 |
|---|---|
| 내 행동을 바꾸는가 (금지·조건·규칙) | 내용째 목록에 넣는다 — 한 줄 250자까지 |
| 나중에 찾을 일이 있는가 | 「언제 여나」 한 줄과 파일 링크만 — 150자까지 |
| 둘 다 아닌가 | 만들지 않는다 |
- 5-4 분야 교훈은 분야 정본으로 보낸다. TC 규칙은 tc-team 스킬의 서랍으로, 게임 제작 교훈은 게임팀 문서로 갑니다. 기억 폴더에 복사하지 않고 옮기기만 합니다. 정본이 둘이 되면 반드시 갈라집니다.
- 5-5 자가 셋 있다. 검사 스크립트가 목록 전체 크기(24,576바이트), 금지 줄 길이(250자), 포인터 줄 길이(150자)를 잽니다. 전체가 한도를 넘으면 꼬리가 잘려 에러 하나 없이 라우팅이 깨지기 때문입니다.
- 5-6 졸업과 부활. 45일 동안 안 쓴 줄은 졸업 후보가 되고, 주간 점검에서 사람 승인을 받아야 내려갑니다. 졸업한 파일을 다시 읽으면 무조건 원래 칸으로 돌아옵니다. PARA의 «보관»을 폴더 이동 없이 구현한 셈입니다.
규칙 6 — 저장소는 합치지 않고, 위에 허브를 얹는다
목적이 다른 저장소 셋(게임 위키 · AI 운영 규칙과 스킬 · 작업 산출물)을 옮기지 않고, 그 위에 _BRAIN 이라는 얇은 허브를 한 겹 얹었습니다. 허브의 부품은 넷입니다. 어디에 무엇이 있는지 적은 지도, 세 곳을 한 번에 찾는 검색, 새 지식을 넣는 순서(제안 → 인박스 → 검토), 그리고 색인에서 뺄 폴더를 적은 명단입니다.
기억은 네 갈래로 나눴습니다. D(도메인 — 게임 위키 같은 사실), P(절차 — 일하는 법과 스킬), E(겪은 일 — 실행 기록), R(참고 자료)입니다. 갈래마다 쓰기 규칙이 다르고, 예를 들어 D는 허브가 직접 고치지 않습니다.
기각한 것 — 값을 치르고 버린 다섯
| 기각 | 왜 |
|---|---|
| 「최상위는 일곱 개까지」 | 근거로 깔았던 「7±2」는 작업기억 용량 이야기지 폴더 탐색 이야기가 아니었다. 탐색 비용은 개수보다 깊이에 더 민감하다 |
번호 붙인 그룹 구조(00_meta · 10_brain …) |
성질이 다른 넷을 한 체계로 덮었다. 거기에 「이 폴더 실물은 옮기지 말 것」이라 적는 순간 지도에는 있는데 땅에는 없는 구조가 됐다 |
| 「석 달 뒤에도 여기 있을까」 | 판정하는 쪽이 사람이고 기준이 주관적이다. 살아남은 규칙(_no_sync)은 질문 하나에 답이 둘이었다 |
| 「태그는 쓰지 않는다」 | 주 분류를 태그로 바꾸면 안 되는 건 맞다. 그래도 파일명을 고칠 수 없는 공유 문서에는 태그밖에 길이 없어서, 금지는 지나쳤다고 고쳤다 |
| 사람 의지로 지키기 | 「하나 골라서 고수하라」는 시간이 지나면 무너진다. 검사되지 않는 규칙은 없는 것과 같다 |
이 기록에서 값을 치른 교훈은 이겁니다 — 정리법을 고르기 전에 «누가 이 폴더를 읽는가»부터 물어야 했습니다. 사람이 읽는 폴더와 프로그램이 읽는 폴더는 같은 「폴더」라는 이름 아래 있을 뿐, 풀어야 할 문제가 다릅니다.
설계만 하고 못 만든 것
2026-08-03 설계(v4)에는 아래가 더 있었습니다. 오늘(2026-10-01) 기준으로 전부 미착수입니다.
| 설계 | 무엇 |
|---|---|
| 작업 폴더별 서랍 넷 | 문서 · 코드 · 결과 · 동기화 제외. 필요한 서랍만 판다 |
INDEX.md |
작업 폴더 전체의 차례표. 「지금 하는 일」 칸은 다섯 개까지 |
inbox |
어디에도 안 속하는 것의 임시 거처. 30일이 지나면 보고한다 |
check_layout.js |
최상위에 새로 생긴 폴더, -temp · _v2 같은 이름, 예약어 오타를 위반으로 보고한다 |
| 규칙 파일 한 장 | 지금 규칙은 안내서 · 기억 파일 · 이 글로 흩어져 있다 |
⚠ «임시 거처»와 «목록 정원»은 Jeff Su 영상에서 채택까지 해 놓고 아직 안 만들었습니다. 채택과 가동은 다른 말입니다. 그리고 이 표가 지금 이 사이트에 있는 이유이기도 합니다 — 적어 두지 않으면 «채택했다»가 «돌고 있다»로 바뀌어 기억되기 때문입니다.