폴더 구조를 대대적으로 갈아엎으려다, 아무것도 안 바꿔도 된다는 걸 알았다

📝 한줄 요약

폴더 구조가 잘못돼서 시스템이 복잡해졌다고 믿고 전면 개편을 하려 했는데, 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