Mac mini를 자동화 서버처럼 쓸 때 기본 폴더 구조

기본은 네 칸으로 나누면 된다

Mac mini를 자동화 서버처럼 쓸 때는 프로젝트, 로그, 백업, 임시 파일을 처음부터 따로 둬야 덜 꼬인다. 내 경우에는 대충 한 폴더에 몰아넣었다가, 며칠 지나서 “이 파일 지워도 되나?”부터 헷갈렸다. 서버처럼 굴릴 거면 폴더도 서버처럼 나눠야 한다.

나는 이런 식으로 잡는 쪽이 편했다.

~/automation
├── projects
├── logs
├── backups
└── tmp

이름은 취향대로 바꿔도 된다. 중요한 건 “돌아가는 코드”, “남겨야 하는 기록”, “복구용 파일”, “언제든 버려도 되는 파일”이 섞이지 않는 것이다.

projects에는 실제로 돌아가는 것만 둔다

projects에는 자동화 스크립트나 작은 서비스처럼 실제로 실행되는 것만 둔다. 테스트로 받아본 파일, 임시로 만든 CSV, 백업 압축 파일까지 같이 넣기 시작하면 금방 정체를 알 수 없는 폴더가 된다.

처음엔 프로젝트별로만 나누면 충분하다.

~/automation/projects
├── blog-publisher
├── rss-watcher
└── image-resizer

각 프로젝트 안에는 코드, 설정, 실행 스크립트 정도만 둔다. 로그는 여기 두지 않는다. 백업도 여기 두지 않는다. 그래야 프로젝트 폴더를 열었을 때 “이걸 실행하면 되는구나”가 바로 보인다.

logs는 나중에 원인 찾으려고 따로 둔다

자동화는 조용히 실패할 때가 많다. 사람이 버튼을 누르는 게 아니라서, 실패한 순간을 놓치면 남는 건 로그뿐이다. 그래서 로그는 프로젝트 안에 흩뿌리지 말고 한곳에 모아두는 게 낫다.

~/automation/logs
├── blog-publisher
├── rss-watcher
└── image-resizer

여기서 헷갈렸던 건 “로그도 프로젝트의 일부 아닌가?”였다. 개발할 때는 그렇게 느껴지는데, 운영할 때는 다르다. 코드는 버전 관리로 보고, 로그는 실행 기록으로 본다. 둘을 섞으면 나중에 Git 상태도 지저분해지고, 오래된 로그 때문에 프로젝트 폴더가 괜히 무거워진다.

로그 파일 이름은 날짜가 들어가면 찾기 쉽다.

2026-07-26.log
2026-07-27.log

한 파일에 계속 이어 쓰는 방식도 가능하지만, 개인 자동화에서는 날짜별 파일이 더 읽기 편했다. “어제 왜 안 돌았지?” 하고 볼 때 바로 들어갈 수 있다.

backups는 복구할 것만 넣는다

backups에는 다시 살릴 가치가 있는 것만 둔다. 자동화 결과물 전체를 무조건 복사해두면 백업 폴더가 쓰레기장이 된다. 내 경우에는 설정 파일, 발행 전 원본, 데이터베이스 덤프처럼 없으면 곤란한 것만 남기는 쪽이 맞았다.

~/automation/backups
├── blog-publisher
├── rss-watcher
└── image-resizer

백업 기준은 이렇게 잡으면 덜 흔들린다.

대상	백업 여부	이유
직접 쓴 설정 파일	남긴다	다시 만들기 귀찮고 실수하기 쉽다
원본 데이터	남긴다	자동화가 잘못 돌았을 때 되돌릴 수 있다
실행 로그	보통은 안 남긴다	로그 폴더에서 일정 기간만 보관하면 된다
임시 다운로드 파일	안 남긴다	다시 받을 수 있으면 백업 대상이 아니다
빌드 결과물	보통은 안 남긴다	코드에서 다시 만들 수 있다

백업은 “많을수록 안전하다”로 가면 오래 못 간다. 어느 순간 뭐가 진짜 복구 파일인지 못 믿게 된다. 백업 폴더는 적어도 열었을 때 겁나면 안 된다.

tmp는 지워도 되는 것만 둔다

tmp는 이름 그대로 임시 파일 자리다. 다운로드 중인 파일, 변환 중간 결과물, 테스트 출력물 같은 것들이 여기 들어간다. 이 폴더의 규칙은 단순하다. 지워도 자동화가 다시 만들 수 있어야 한다.

~/automation/tmp
├── blog-publisher
├── rss-watcher
└── image-resizer

처음엔 macOS의 Downloads나 바탕화면을 임시 폴더처럼 쓰기 쉽다. 나도 그랬다. 그런데 자동화가 몇 번 돌고 나면 사람이 받은 파일과 스크립트가 만든 파일이 섞인다. 그때부터 정리가 아니라 추리가 된다.

tmp를 따로 두면 주기적으로 비우기도 쉽다. 비울 때 불안하면 이미 규칙이 깨진 것이다. 임시 폴더에 중요한 파일이 들어가고 있다는 뜻이다.

macOS 기본 폴더를 그대로 쓰지 않는 이유

Mac mini라고 해도 서버처럼 쓸 거면 Documents, Desktop, Downloads에 의존하지 않는 게 낫다. 그 폴더들은 사람이 쓰기 좋은 자리다. 자동화가 계속 파일을 만들고 지우기에는 너무 생활 공간에 가깝다.

나는 기준을 이렇게 잡았다.

위치	자동화 서버용으로 애매한 이유
Desktop	사람이 보는 공간이라 파일이 쌓이면 바로 피곤해진다
Downloads	브라우저 다운로드와 자동화 산출물이 섞인다
Documents	문서와 운영 파일의 경계가 흐려진다
/var/log	시스템 영역이라 권한과 관리 방식이 달라진다
~/automation	사용자 권한 안에서 관리하기 쉽고 의도가 분명하다

개인용 Mac mini라면 굳이 시스템 디렉터리 흉내를 낼 필요는 없다. 루트 권한이 필요한 구조로 시작하면, 작은 자동화 하나 고치려다가 권한 문제부터 보게 된다.

프로젝트별로 다시 한 번 나눠둔다

상위 폴더를 네 칸으로 나눴으면, 그 안에서는 프로젝트 이름으로 다시 나누는 게 편하다. 로그는 로그끼리 모이고, 백업은 백업끼리 모이되, 안쪽에서는 어느 자동화가 만든 건지 바로 보여야 한다.

~/automation
├── projects
│   ├── blog-publisher
│   └── rss-watcher
├── logs
│   ├── blog-publisher
│   └── rss-watcher
├── backups
│   ├── blog-publisher
│   └── rss-watcher
└── tmp
    ├── blog-publisher
    └── rss-watcher

이 방식의 장점은 장애가 났을 때 드러난다. blog-publisher가 이상하면 프로젝트 코드, 로그, 백업, 임시 파일을 같은 이름으로 따라가면 된다. 폴더 구조가 머릿속 지도 역할을 한다.

이름은 멋보다 반복 가능성이 먼저다

폴더 이름은 짧고 평범한 게 낫다. automation, projects, logs, backups, tmp 정도면 충분하다. workspace-final, server-stuff, misc-auto 같은 이름은 만들 때는 편한데, 한 달 뒤에 보면 내가 무슨 생각이었는지 잘 모른다.

프로젝트 이름도 마찬가지다.

애매한 이름	나은 이름
test	rss-watcher
new-blog	blog-publisher
scripts	image-resizer
backup2	blog-publisher-backup-check

이름에 역할이 들어가면 나중에 launchd나 cron 설정을 볼 때도 덜 헤맨다. 자동화 서버는 사람이 매일 들여다보지 않기 때문에, 이름이 기억을 대신해줘야 한다.