맥미니 M4를 AI 작업대로 쓰며 알게 된 것

맥미니 M4를 AI 작업대로 쓰면서 제일 먼저 깨진 기대는 “성능 좋은 작은 컴퓨터 하나면 흐름이 정리되겠지”였다. 결론부터 말하면 성능보다 권한, 경로, 세션, 로그, 역할 분리가 먼저였다. 이 다섯 가지가 흐리면 AI 도구가 늘어날수록 일이 빨라지는 게 아니라 확인할 리모컨만 늘어난다.

지금은 맥미니를 완전 자동화 서버라고 부르지 않는다. 항상 켜둘 수 있는 개인 작업대에 가깝다. Obsidian 노트를 열어두고, WordPress 글을 고치고, Codex나 Hermes로 점검을 돌리고, 브라우저에서 공개 화면을 확인하는 기준점을 한곳에 묶어두는 장비다.

처음 증상은 작업이 빨라지지 않는다는 점이었다

처음에는 맥미니에 필요한 도구를 깔아두면 노트, 블로그, 코드, 브라우저 확인이 자연스럽게 이어질 줄 알았다. 실제로는 달랐다. AI가 글을 고쳤다고 해도 공개 URL을 따로 열어봐야 했고, 브라우저 세션이 필요한 일은 원격 명령만으로 끝나지 않았다. 자동 실행은 성공처럼 보였는데 결과 파일이 없어서 나중에 무엇이 됐는지 다시 확인해야 하는 일도 있었다.

겉으로는 작은 불편처럼 보이지만, 공개 글 운영에서는 꽤 치명적이다. 글 본문은 바뀌었는데 내부링크가 빠졌거나, hero 이미지가 없어졌거나, noindex 여부를 확인하지 않은 채 완료로 착각하면 다시 손이 간다. 맥미니가 문제가 아니라, 맥미니 위에서 일을 맡기는 기준이 빈약했던 셈이다.

실제 환경은 한 대의 컴퓨터보다 여러 층이었다

내 작업 환경은 맥미니 M4, Obsidian 노트, WordPress, 브라우저, 몇 가지 AI 도구가 겹쳐 있다. 글을 쓰는 단계에서는 Obsidian이 편하고, 파일 수정과 검증에는 Codex 계열 도구가 편하다. 외부에서 지시를 던지고 결과를 받는 흐름에는 Hermes가 붙고, 말투 점검은 Antigravity처럼 별도 도구를 쓰기도 한다.

이 환경에서 중요한 것은 도구 이름이 아니라 경계였다. 어떤 도구가 파일을 고칠 수 있는지, 어떤 도구는 판정만 해야 하는지, 어떤 계정 액션은 사람이 직접 봐야 하는지 나누지 않으면 작은 자동화가 금방 위험한 자동화가 된다. 특히 AdSense, WordPress, Google 계정이 얽힌 작업은 “할 수 있음”과 “해도 됨”을 따로 봐야 했다.

원인은 성능 부족이 아니라 운영 기준 부족이었다

맥미니 M4의 속도 자체가 막힌 적은 많지 않았다. 더 자주 막힌 것은 macOS 권한, 외장 SSD 경로, 로그인 세션, 자동 실행 로그, 브라우저 확인이었다. 사람이 직접 터미널을 열어 실행할 때는 넘어가는 권한도 백그라운드에서는 막힐 수 있다. 브라우저에서 이미 로그인된 상태라 되는 일도, headless나 새 프로필에서는 전혀 다른 일이 된다.

그래서 문제를 성능 튜닝으로 풀지 않았다. 먼저 “AI가 읽어도 되는 파일”, “사람 확인이 필요한 작업”, “결과 파일이 남아야 하는 작업”을 나눴다. 이 선이 생기니 맥미니를 더 세게 돌리는 것보다, 실패했을 때 어느 층에서 멈췄는지 보는 일이 쉬워졌다.

지금 나눠둔 역할

이 표는 멋진 아키텍처가 아니다. 실제로 덜 꼬이려고 만든 작업 분리표다. 역할을 나누고 나면 “AI가 못했다”가 아니라 “어느 도구에 잘못 맡겼다”로 원인을 좁힐 수 있다.

해결은 권한을 넓히기보다 좁히는 쪽이었다

처음에는 권한을 넓게 열어두면 편할 줄 알았다. 지금은 다르게 운용한다. AI 도구가 읽어야 하는 폴더와 절대 읽지 말아야 하는 폴더를 나눈다. WordPress 글을 고칠 때도 본문, 제목, excerpt, SEO 메타처럼 작업 범위를 제한하고, 계정 설정이나 AdSense 검토 요청은 작업 밖에 둔다.

이 기준은 보안만을 위한 것이 아니다. 작업 품질에도 영향을 준다. 읽을 수 있는 파일이 너무 많으면 AI가 오래된 노트나 다른 사이트 규칙을 현재 작업의 근거처럼 끌고 올 수 있다. 맥미니가 항상 켜져 있다는 장점은, 기준이 흐릴 때는 오히려 오래된 맥락을 계속 끌고 가는 단점이 된다.

경로와 로그는 생각보다 빨리 문제를 만든다

외장 SSD, 클라우드 동기화 폴더, WordPress 백업 파일, 브라우저 다운로드 폴더가 섞이면 같은 글도 서로 다른 위치에 남는다. 사람은 최근 파일을 눈으로 고르지만 자동화 도구는 경로를 그대로 믿는다. 그래서 작업 지시서에는 공개해도 되는 범위에서 대상 글 ID, 공개 URL, 백업 파일의 성격을 적고, 실제 비밀 경로는 보고서에 쓰지 않는다.

로그도 같은 문제다. “작업 완료”라는 메시지만 있으면 다음 날 복구가 어렵다. 어떤 원문을 백업했고, 어떤 본문을 적용했고, 공개 URL에서 무엇을 확인했는지 파일로 남겨야 한다. 이 원칙은 AI 에이전트 크론 작업은 결과 파일부터 남겨야 덜 꼬인다에서 따로 정리했다.

브라우저 확인을 빼면 공개 작업은 끝난 게 아니었다

WordPress REST에서 200을 받았다고 공개 화면이 독자에게 제대로 보인다는 뜻은 아니다. 캐시가 남아 있을 수 있고, hero 이미지가 빠질 수 있고, canonical이나 robots meta를 따로 확인해야 할 때도 있다. 그래서 공개 글을 손댄 뒤에는 API readback과 공개 URL 확인을 둘 다 본다.

내가 보는 최소 검증은 간단하다. 공개 URL이 200인지, canonical이 자기 URL인지, robots meta에 noindex가 없는지, 내부링크가 2개 이상인지, hero 이미지가 화면에 남아 있는지 확인한다. 모바일 폭에서 본문이 옆으로 밀리지 않는지도 볼 때가 많다. 이 검증을 글쓰기 뒤에 붙여야 맥미니 작업대가 “작업한 척”으로 끝나지 않는다.

Obsidian 지시서가 같이 필요했다

맥미니를 켜두는 것만으로는 기준이 생기지 않는다. 기준은 노트에서 나온다. Obsidian에 작업 목적, 대상 URL, 금지선, 검증 조건을 적어두면 AI에게 넘길 때 설명이 훨씬 짧아진다. 이 부분은 Obsidian 노트를 AI 작업 지시서로 바꾸는 법에서 더 자세히 적었다.

장기기억도 같은 이유로 조심한다. 다음 세션에도 필요한 운영 규칙은 남기되, 당일 로그나 이미 끝난 진행상황은 오래 들고 가지 않는다. 기억 기준은 AI 에이전트 장기기억 설계 기준과 맞춰 보는 편이 낫다.

새로 세팅할 때 보는 순서

• 노트, 작업 파일, 공개하면 안 되는 파일을 먼저 나눈다.
• macOS 권한은 도구별로 확인하고 한 번에 몰아주지 않는다.
• 외장 SSD와 프로젝트 경로는 작업 지시서에서 헷갈리지 않게 적는다.
• 자동 실행은 결과 파일과 실패 로그를 먼저 만들게 한다.
• Google 로그인, 2단계 인증, 계정 보호 화면은 자동화로 우회하지 않는다.
• 글 수정 뒤에는 REST 결과와 공개 브라우저 화면을 둘 다 확인한다.

맥 AI 작업환경을 처음 세팅한다면 맥 AI 작업환경 세팅 체크리스트를 먼저 보는 편이 더 빠르다. Gemini CLI 자동 실행처럼 인증과 trust가 얽히는 문제는 Gemini CLI OAuth 크론 오류 체크리스트와 이어진다.

지금 기준의 결론

맥미니 M4는 좋은 AI 작업대가 될 수 있다. 다만 “작은 서버”라는 말에 취하면 놓치는 것이 많다. 실제로 오래 남는 차이는 칩 성능보다 권한을 얼마나 좁혔는지, 경로를 얼마나 덜 헷갈리게 적었는지, 실패 로그를 남겼는지, 공개 화면을 확인했는지에서 났다.

나는 이제 맥미니를 혼자 일하는 자동화 기계로 보지 않는다. 사람이 정한 기준을 계속 붙잡아두는 책상으로 본다. 도구가 늘어도 이 기준이 있으면 덜 불안하다. 없으면 빠른 컴퓨터 위에서 같은 실수를 더 빠르게 반복할 뿐이었다.