Mac Studio 128GB로 AI 직원 회사를 만든 이유 — 처분까지 계산한 트레이드오프

4월 25, 2026

📚 AI 직원 회사 빌드기 — 4부작 시리즈

① Mac Studio 128GB로 AI 직원 회사 만든 이유 (현재 글)
② 외부 부작용 통제 — Discord 승인 + launchd
③ claude -p 6-step 체이닝 — V3.5 + Phase 2 트랩
④ 30시간 회고 — 토큰·막힌 5번·다음 6주 KPI

Mac Studio를 켜놓고 자도 되는가

Mac Studio 128GB를 켜놓고 자도 되는가. 구입 후 며칠이 지나서야 이 질문이 처음 떠올랐다. 전기요금이 걱정된 게 아니었다. 이 기계가 실제로 뭔가를 만들어내고 있는가 — 라는 질문이었다.

개발자라면 이런 상황을 한 번쯤 겪었을 것이다.

서버를 켜두고 ssh만 가끔 접속하는 걸 "활용 중"이라 부르는 상황
로컬 LLM 148GB를 다운받아 놓고 실제 추론 시간이 전체의 5%도 안 되는 상태
에이전트 파이프라인 세팅을 다 해놓고 "이게 수익이 되는가"라는 질문을 계속 뒤로 미루는 것

이 글은 그 질문에 정면으로 답하는 과정에서 내가 실제로 만든 것, RAM 수치를 어떻게 계산했는지, 그리고 팔 타이밍을 어떤 기준으로 미리 설계했는지를 기록한다. 결론부터 말하면 — 아직 "회사"가 아니고, 처분 시나리오는 이미 설계해뒀다.

로컬 LLM이 이유가 아니다

구입 이유를 물어보면 "로컬 LLM 돌리려고"가 가장 쉬운 답처럼 보인다. 그런데 그게 이유라면 128GB는 정당화하기 어렵다. 로컬 LLM이 실제로 필요한 조건은 대체로 세 가지다.

프라이버시: 개인 민감 문서를 대량 처리해야 할 때
API 볼륨: 월 $100+ 이상의 클라우드 API 비용이 발생할 때
오프라인 운용: 인터넷 없는 환경에서 LLM이 필요할 때

나는 이 세 가지 중 하나도 해당하지 않는다. 그렇다면 로컬 LLM 서버로서의 Mac Studio 128GB는 정당화되지 않는다.

진짜 이유는 따로 있었다. "자동으로 굴러가는 AI 직원이 있는 회사"를 만들고 싶다는 것. 이건 하드웨어 최적화 문제가 아니라 조직 설계 문제였다. 이 관점에서만 128GB가 말이 된다.

128GB가 정당화되는 유일한 계산

AI 직원 회사를 24/7로 돌리려면 동시에 얼마나 많은 것이 상주해야 하는지 수치로 따졌다.

컴포넌트	RAM 추정
에이전트 프로세스 (hermes, openclaw 등)	5~8GB
Claude Code 세션 5~10개 병렬	5~10GB
Chrome headless 5~10 인스턴스	5~15GB
Docker 스택 (pgvector + redis + WordPress)	6~10GB
빌드 프로세스 2~3개 동시	10~15GB
벡터 DB 인메모리 캐시 (honcho)	5~20GB
OS + 여유	10GB
합계	46~88GB

여기에 로컬 LLM을 부차 상주시키면 +30~65GB가 추가된다. 64GB는 빠듯하고 128GB는 여유가 생긴다. 이 계산 위에서만 128GB가 정당화된다. "로컬 LLM 때문"이 아니라 "동시에 돌아가야 하는 것들의 총합 때문"이다.

V5 스캐폴딩 — 하룻밤에 만든 것

조직 설계를 코드로 옮기는 데 하룻밤이 걸렸다. 서브에이전트 6명을 병렬 디스패치해서 새벽 01:48~04:45 사이에 스캐폴딩을 완성했다.

승인 대기열 + 카드: SQLite 48h TTL. Discord 웹훅 미설정 시 stdout 덤프로 자동 대체.
handoff 디스패처: 딜 감지 → 쇼츠·스레드 동시 투입, 블로그 발행 → 쇼츠 재활용.
수익 집계실: 드라이런 샘플 1주 합계 24,400원 (adsense 12,500 + coupang 3,200 + youtube 8,700). CSV 수동 입력 우선, API 커넥터는 OAuth 완료 후 전환.
일일 리듬 cron: 08:00 킥오프, 20:00 QA, 20:30 저녁 승인 카드, 매시 queue_purge.

65+ 유닛 테스트 전부 통과 (queue 21, dispatcher 6, revenue 16, honcho 18, blog 4). launchd plist 5개는 모두 Disabled=true다. 가동 결정은 내가 별도로 한다.

아직 "회사"가 아닌 이유

스캐폴딩이 완성됐다는 것과 회사가 됐다는 것은 다르다. 현재 상태에서 세 가지가 빠져 있다.

수익 모델 미검증: 드라이런 24,400원은 샘플 데이터다. 실제 파이프라인이 돈을 버는지 확인이 안 됐다. 수익 없는 회사는 회사가 아니라 취미 모임이다.

OAuth 미완성: YouTube, Threads, Instagram, AdSense 연결이 모두 남아 있다. 발행은 현재 수동이거나 stub 상태다. "자동화"가 자동이 아니다.

콘텐츠 품질 측정 불가: blog-publisher에 발행 로그 자체가 없다. "사실오류 10% 미만"이라는 합격선을 측정할 방법이 아직 없다. 측정 못 하는 건 관리 못 한다.

에이전트 10개 돌려 블로그 10편/일 발행해도 품질·트래픽·수익이 없으면 고속 공회전이다. 극한 활용이 가치 창출을 자동으로 의미하지 않는다는 걸 미리 인정해두는 게 낫다. CEO가 직원 평가 지표 없이 월급(전기·시간)을 지급 중인 상태다.

처분 시나리오 4가지 — 3개월 후 결정 기준

1~2개월 운영 데이터가 쌓이면 Mac Studio 자체를 재평가한다. 결론은 미리 정해두지 않는다. 가능한 경우의 수는 네 가지다.

① 유지: 128GB가 실제로 필요하다는 게 측정으로 증명될 때. 피크 RAM이 지속적으로 80GB를 초과하거나, 로컬 LLM이 실제 수익 파이프라인에서 클라우드 API 대비 비용을 절감하거나, 병렬 처리가 측정 가능한 처리량 차이를 만들 때다. 이 중 하나라도 수치로 나오면 현 기기를 유지하는 게 합리적이다.

② 다운그레이드: 64GB로도 충분하다는 게 확인될 때. 3개월 평균 RAM 사용량이 50GB 미만으로 유지된다면 M4 Max 128GB → 64GB 중고 교체로 차액을 회수할 수 있다. 로컬 LLM을 배제하면 에이전트·빌드·Docker 스택이 64GB 안에 들어갈 가능성이 높다.

③ 클라우드 이전: 대부분의 자동화가 VPS로 가능하다는 게 확인될 때. 블로그·쇼츠·스레드 파이프라인이 Claude API + 소형 VPS 조합으로 충분히 돌아간다면, Mac Studio를 팔고 M4 MBP + VPS + 클라우드 API로 전환하는 게 비용 효율적이다. Mac Studio 처분 가격으로 VPS 3~4년치를 커버할 수 있다. 단, "24시간 인터랙티브 개발 + 대형 빌드"가 필요하다면 VPS 성능·지연이 병목이 될 수 있다.

④ 하이브리드: 대형 빌드·인터랙티브 개발은 MBP, 24/7 자동화만 VPS로 분리. 가장 보수적인 선택이지만 운영 비용이 낮아지고, "Mac Studio가 멈추면 모든 게 멈춘다"는 단일 장애점 문제가 해결된다. 현재 구조가 특정 기기에 강하게 묶여 있다는 것 자체가 리스크다.

처분은 실패가 아니다. 측정 결과가 그걸 가리키면 그게 합리적인 결정이다. 3개월이 지나도 같은 질문을 반복하고 있다면, 그건 측정을 안 했다는 뜻이다.

이 모든 계산을 미리 해둔 이유가 하나 있다. 매몰비용 오류에 빠지지 않으려면 판단 기준이 미리 있어야 한다. 내가 설정한 기준은 단순하다.

수익이 나오는 파이프라인이 128GB를 필요로 하는가.

"아니오"가 나오면 팔면 된다. "예"가 나오면 계속 켜놓으면 된다. 판단을 위한 데이터는 지금부터 모인다. 운영 데이터가 쌓이기 시작하면 여기에 결과를 업데이트할 생각이다.

태그: #MacStudio #AI에이전트 #로컬LLM #개발자 #24시간자동화 #처분시나리오 #트레이드오프

📚 AI 직원 회사 빌드기 — 4부작 시리즈

① Mac Studio 128GB로 AI 직원 회사 만든 이유 (현재 글)
② 외부 부작용 통제 — Discord 승인 + launchd
③ claude -p 6-step 체이닝 — V3.5 + Phase 2 트랩
④ 30시간 회고 — 토큰·막힌 5번·다음 6주 KPI

이 블로그 검색

AI 도구 매일 노트 — 해고된 개발자의 기록