저는 AI 에이전트를 $5짜리 서버에서 24시간 내내 돌립니다. 제 Mac은 잠듭니다.

밤새 돌리던 에이전트 작업을 마지막으로 날렸을 때, 아무것도 죽지 않았습니다. 에러도 없었습니다. 몇 달째 미뤄두던 저장소에서 긴 마이그레이션을 걸어놓고, 지루한 초반부를 갈아내는 걸 지켜보다가, 그날 일이 끝나서 노트북을 덮었습니다. 다음 날 아침 카페에서 다시 열었습니다. 세션은 사라져 있었습니다. 실패한 게 아니었습니다. 중간 어딘가에서 멈춰 있었고, 절반쯤 만들다 만 브랜치와, 다음에 뭘 하려던 것인지에 대한 기록은 하나도 없었습니다.

게다가 저는 그 해결책을 이미 적용해 둔 상태였습니다. 바로 그 점이 뼈아팠습니다.

그래서 이 글은 그 해결책이 애초에 통할 수 없었던 이유와, 대신 그 일을 해주는 지극히 심심한 임대 서버에 관한 이야기입니다. 지금은 그 위에서 AI 에이전트를 24시간 돌리고 있고, 노트북 전원 설정은 아예 신경 쓰지 않게 됐습니다.

모두가 추천하는 해결책

caffeinate -dimsu. 아니면 커피잔 아이콘이 달린 메뉴 막대 앱. 아니면, 좀 더 파고들었다면, sudo pmset -a disablesleep 1. 가장 극단적인 방법이자, 가장 자신만만하게 들리는 조언에서 튀어나오는 바로 그 방법입니다. 저는 그걸 실행했습니다. 문제가 해결된 것 같은 기분이 들었습니다.

macOS가 잠드는 방법은 하나가 아니고, 여기서 중요한 두 가지는 서로 독립적입니다. 유휴 절전은 아무 일도 일어나지 않을 때 흘러가는 타이머이고, 덮개를 닫으면 보통 그와 별개의 경로를 통해 강제 절전이 발동합니다. 그렇다면 caffeinate 가 만들어내는 것은 일련의 전원 어서션이며, ss64의 caffeinate 레퍼런스 를 보면 그 플래그들이 디스플레이 절전, 유휴 절전, 디스크 유휴 절전, 시스템 절전을 다룬다는 것을 알 수 있습니다. Apple의 전원 관리 문서 는 중요한 구분을 짚습니다. 유휴 절전 어서션은 여전히 평범한 덮개 닫힘, Apple 메뉴, 배터리 부족을 무효화하지 못합니다.

그러니까 절전 방지 도구는 애초에 제어하도록 만들어진 절전 조건에서는 실제로 작동합니다. 하지만 덮개를 평범하게 닫는 것은 다른 문제이고, caffeinate 는 덮개를 닫은 채 돌리는 서버 전략이 아닙니다.

참고: disablesleep 은 이상한 경우입니다. 표준 pmset 옵션 레퍼런스 에는 아예 나오지 않습니다. 사람들이 손을 뻗는 그 해결책은 문서화되지 않은 설정입니다. 전원 어서션도 아닙니다. 배터리로 구동 중일 때를 포함해, 덮개를 닫아도 MacBook을 계속 깨어 있게 만들 수 있고, 이는 다시 끄거나 배터리가 다 될 때까지 이어집니다.

노트북은 24시간 돌아가는 일에 맞는 형태가 아닙니다

90년대에는 누군가의 책상 밑에 있는 데스크톱 타워에서 프로덕션 웹 서버를 돌리던 시기가 있었고, 건물에 있는 모두가 멀티탭을 발로 차지 않는 법을 배웠습니다. 우리는 그 문제를 멀티탭에 붙인 경고문으로 해결하지 않았습니다. 오직 가만히 서서 전원을 유지하는 것만이 임무인 기계로 작업을 옮겨서 해결했습니다.

삼십 년이 지난 지금, 같은 모양의 문제입니다. MacBook은 닫아서 들고 나가는 것을 전제로 설계된 기계입니다. 이건 전원 관리의 버그가 아닙니다. 그게 제품 그 자체입니다. 절전을 막으려는 모든 시도는 누군가가 일부러 내린 설계 결정과 벌이는 논쟁이고, 그 논쟁에서 한동안 이길 수는 있습니다. 대가는 그 문제를 영원히 신경 쓰는 것입니다.

더 나아가 절전을 아예 꺼버릴 수도 있습니다. 축하합니다. 이제 배터리가 들어 있는 상시 가동 서버를 갖게 되었고, 노트북을 가방에 넣기 전에 되돌려 놓는 걸 기억해야 하는 시스템 전역 설정도 하나 생겼습니다. 급하게 짐을 챙긴 그 첫 순간에도 작업은 멈추지 않습니다. 기계는 깨어 있는 채로 남아 배터리를 소모하고, 정말로 원하지 않는 곳에서 열을 쌓습니다.

이 중 무엇도 새로운 이야기는 아닙니다. 자체 호스팅하는 에이전트 데몬도 같은 이유로 같은 벽에 부딪힙니다. 당신이 책상에 없을 때도 켜져 있어야 한다. 그래서 아무것도 설정하기 전에 이미 노트북은 후보에서 빠집니다. 이 분야에서는 꽤 오래전부터 사실이었습니다. 다만 아직 저에게 하룻밤치 작업을 대가로 물리지 않았을 뿐이었습니다.

당신의 에이전트는 그 기계에서 생각하지 않습니다

Claude Code가 명시한 시스템 요구 사항은 4 GB or more of RAM and an x64 or ARM64 processor. 하드웨어 요구 사항은 그게 전부입니다. GPU 항목도, VRAM 항목도 없습니다. 모델에 관한 언급 자체가 없습니다. 당신의 기계에는 모델이 없기 때문입니다.

이걸 몸으로 받아들이는 데 창피할 만큼 오래 걸렸고, 그래서 가격이 더는 수상하게 들리지 않게 됩니다. 당신의 기계에서 도는 에이전트 프로세스는 세 가지 일을 합니다. 컨텍스트를 모아 API 호출로 실어 보내고, 턴 사이의 대화 상태를 유지하고, 모델이 요청하는 도구를 실행하는 것입니다. 이건 조율 작업입니다. (저는 이 이야기 속에서 GPU를 계속 찾았습니다. 이 이야기에 GPU는 없습니다.) 비싼 부분, 가속기 랙을 요구하는 그 부분은 남의 데이터센터에서 벌어지고 있습니다.

에이전트는 그 기계에서 생각하지 않습니다. 생각하는 무언가에 호출을 걸고 있을 뿐입니다.

그래서 이런 일을 해내는 기계의 가격이 그 정도인 것입니다. 2026년 8월 말 기준으로 DigitalOcean의 가장 저렴한 Basic Droplet은 512 MiB와 vCPU 하나에 월 $4이고, Vultr의 Cloud Compute는 IPv6 전용 512 MB 인스턴스 $2.50에서 시작해 1 GB에서 $5에 이릅니다. 두 업체, 같은 모양의 바닥입니다. 두 최하단 단계 모두 그 요구 사항의 4 GB에 못 미치고, $5급 요금제도 마찬가지입니다. 특히 Claude Code를 돌린다면 4 GB가 공표된 하한선입니다. 저가 구간은 당신이 실제로 돌리는 에이전트의 요구 사항이 더 낮을 때만 통합니다.

여기서 선을 하나 긋겠습니다. 이걸 잘못 이해하면 돈이 나가기 때문입니다. 지금까지의 이야기는 호스팅된 모델을 호출하는 에이전트에 해당합니다. 당신이 원하는 것이 소유한 하드웨어에서 로컬로 돌아가는 모델이라면, 이 중 어느 것도 적용되지 않습니다. RAM이 1기가바이트인 기계는 당신이 코딩에 쓰고 싶어 할 만한 모델을 돌리지 못합니다.

그 기계가 싼 이유는, 비싼 부분이 다른 곳에서 벌어지고 있기 때문입니다.

Mac mini의 가격, 그리고 그 값으로 얻는 것

Mac mini는 이제 $899이고, 9월 22일까지는 손에 넣을 수 없습니다. 기본 M6 구성 (12코어 CPU, 12코어 GPU, 메모리 16GB, 저장 용량 256GB)은 사전 주문 중이며 그날 배송됩니다. TechCrunch의 출시 기사 에 그 숫자가 나옵니다. Apple은 그 아래로는 아무것도 판매하지 않습니다.

이 숫자는 곱씹어 볼 만합니다. 같은 16GB, 같은 256GB. 이 메모리와 저장 용량 구성은 2024년 10월에 $599로 출시됐습니다. 2년도 안 되는 사이에 기본형 Mac mini 가격이 1.5배가 된 것입니다. 그 사이에는 $799라는 단계가 있었습니다. 2026년 5월에 Apple이 256GB 구성 판매를 중단하면서 시작 가격도 함께 올라간 것입니다. 사서 소유하자는 주장이 딛고 선 땅이 바로 이것이고, 그 땅은 계속 움직입니다.

반대편에는 제가 인정하고 싶은 것보다 더 많은 강점이 있습니다. 기계는 완전히 당신 것이고, 되팔 수 있으며, 매달 나가는 항목도 없습니다. 유휴 상태에서 전기 요금은 거의 티가 나지 않습니다. Apple은 M4 구성의 유휴 시 전력 4W, 이는 2026년 6월 미국 가정용 전기 평균 가격. 실제 워크로드는 더 많이 끌어다 쓰므로, 4W가 운용 수치라고 우기지는 않겠습니다. 그리고 빌린 연산 자원은 사다리의 맨 아래에서만 쌉니다. $4에서 시작하는 그 DigitalOcean 목록은 16 GB 기계에서 월 $96로 끝나고, 그걸 3년 쓰면 Mac mini 값의 몇 배가 듭니다.

그러니 그렇습니다. 질문이 '주어진 양의 연산 능력을 3년 동안 소유하는 것과 빌리는 것 중 어느 쪽이 싼가'라면, Mac mini를 사세요. 그 질문에는 답이 있고, 그건 제가 주장하는 답이 아닙니다.

Mac mini가 사주는, 셈을 바꾸는 두 가지가 있습니다. 첫째는 macOS 그 자체입니다. 거기서 도는 에이전트는 macOS 자동화와 앱 권한을 통해 메모, 메시지, 단축어, 캘린더, 미리 알림에 연결될 수 있습니다. 헤드리스 Linux 기계에는 그런 로컬 앱이 없습니다. 당신 에이전트의 일이 그것들을 다루는 것이라면 Mac mini가 옳은 기계이고, 저는 아닌 척하지 않겠습니다.

둘째는 로컬 추론입니다. 빠른 칩 옆에 빠른 메모리가 넉넉히 붙어 있는 구성은 정말로 가성비가 좋고, 어떤 저가 VPS도 여기서는 상대가 되지 않습니다. 바로 이 주제를 다룬 Hacker News 스레드 의 논지는 잘 짜여 있고, 저는 그들이 옳다고 봅니다. 다만 제 질문과는 다른 질문입니다.

그 둘 중 어느 것도 닫히는 노트북에 대한 해결책은 아닙니다. 노트북이 잠드는 걸 막으려고 데스크톱을 사는 것은, 위상 구조의 문제를 하드웨어로 풀려는 일입니다.

옮기고 나서 달라진 것

몇 주 동안 그게 존재한다는 사실을 잊고 지냈습니다. 그게 제 사용기입니다.

서버를 띄우고, 에이전트를 그리로 옮기고, 아직 못 믿어서 몇 번 확인해 보다가, 확인을 그만뒀습니다. 작업은 끝까지 갑니다. 덮개는 이제 아무 상관이 없습니다. 제 Mac은 이제 잠듭니다. 노트북에 바라는 게 바로 그것입니다.

마찰은 실재하니, 여기 그대로 적습니다. 저는 로컬 기계를 잃었습니다. 에이전트가 제 데스크톱을 직접 건드려서 하던 일은 이제 할 수 없고, 그래서 아무 생각 없이 만들어 두었던 작은 워크플로 두 개가 깨졌습니다. 이제 서버가 하나 생겼고, 그 위에는 SSH가, 앞에는 방화벽이, 그리고 업데이트를 요구하는 배포판이 있습니다. 이건 제 주의력에 매기는 작지만 영구적인 세금입니다. 빌린 서버가 유지보수 제로라고 말하는 사람은 한 단계를 건너뛰고 있는 겁니다. 그리고 싼 이유는 추론이 원격이기 때문입니다. 거기서 뭔가를 로컬로 돌리고 싶어지는 날, 저가 등급은 더 이상 그 가격이 아니게 됩니다.

SSH 셸 안에서 바로 띄운 에이전트는 그 연결이 끊기면 죽을 수 있습니다. 먼저 지속되는 세션 안에서 실행하세요. tmux 가 표준적인 답이고, 원격 서버에서 세션을 살려 두기 에 구체적인 방법이 나와 있습니다.

그다음은 사람들이 이 주장에 던지는 가장 날카로운 반론입니다. 빌린 기계가 물리적으로 소유한 하드웨어보다 에이전트에게 더 나쁜 집이 아닌가? 개인 파일에 접근하는 오퍼레이터형 에이전트라면 타당한 지적입니다. 코딩 에이전트라면, root 권한으로 통제하고 방화벽을 직접 설정한 VPS는 공용 인터넷에 널리 노출한 에이전트 서비스와는 다른 위험 프로필입니다. 그래도 여전히 남의 하드웨어 위에 올라간 가상 머신이고, 인터넷에서 닿을 수 있게 남겨 둔 것은 전부 여전히 당신의 공격 표면입니다. 그리고 당신의 통제를 벗어나는 부분, 즉 코드를 모델 제공자에게 실어 보내는 API 호출은 어느 쪽이든 똑같이 벗어납니다. Mac이든 Linux든 그 신뢰 경계는 동일합니다.

제가 원했던 건 더 이상 신경 쓰지 않아도 되는 기계였습니다. 켜고, 단단히 잠그고, 에이전트를 올리고, 잊어버리는 것. 하나 세팅할 생각이라면, 평범한 Linux VPS 면 이 워크로드가 요구하는 건 전부입니다. 그리고 저희 것은 리전과 배포판을 고른 지 1분 뒤에 SSH로 root를 건네줍니다. 이 일에 어울리는 딱 그만큼의 격식입니다.

오늘 시작하는 사람에게 해줄 말

세 가지만 말하고 마치겠습니다.

지금 제가 돌리는 구성: 작은 임대 Linux 서버 한 대, RAM 1~2기가바이트, vCPU 하나, NVMe 스토리지, 제가 있는 곳과 가까운 리전. 제 워크로드에 필요한 건 그게 전부입니다. 당신의 에이전트가 더 높은 하한선을 공표한다면 그쪽을 따르세요. 그 위에는 에이전트 CLI, tmux, 방화벽, 자동 업데이트가 올라가 있습니다. 제 관심을 가져가는 정도는 대략 제 공유기 수준입니다.

조언이랄 게 있다면 이겁니다. 무엇이든 사기 전에, 에이전트가 공표한 요구 사항을 충족하는 가장 싼 기계에 먼저 올려 보세요. 영구적인 결정이 아니라 테스트로요. 일주일이면 당신의 워크로드가 API 오케스트레이션인지, 그렇다면 이미 끝난 것이고 $899를 지킨 셈인지, 아니면 정말로 자기 하드웨어가 필요한지 알게 됩니다.

다시는 하지 않을 한 가지: 몇 주씩 전원 관리를 붙들고 씨름하는 것. 저는 caffeinate를 써봤고, 그다음엔 메뉴 막대 앱, 그다음엔 disablesleep, 그리고 예약 기상까지 시도하면서, 매번의 실패를 아직 못 찾은 설정 버그로 취급했습니다. 아니었습니다. 단서는 바로 거기 놓여 있었습니다. 해결책 하나하나가 그 기계를 노트북으로서 조금씩 더 나쁘게 만들고 있었던 것입니다. 하룻밤치 작업을 날린 건, 그걸 알아차리기에는 비싼 방법이었습니다.

읽기

VPS에서 Code Server와 Claude Code를 돌리는 법: 브라우저 기반 AI 개발 환경

자주 묻는 질문

덮개를 닫아도 Caffeinate가 Mac을 깨어 있게 하나요?

번호 caffeinate 는 유휴 절전이나 디스플레이 절전 같은 절전 조건을 붙잡아 두기 위해 전원 어서션을 사용합니다. 해당 어서션에 대한 Apple 자체 문서는 덮개 닫힘, Apple 메뉴, 배터리 부족으로는 시스템이 여전히 절전에 들어갈 수 있다고 밝히고 있습니다. 덮개를 평범하게 닫으면 강제 절전이 발동되고 그 어서션들은 이를 막지 못합니다. 절전 방지 도구가 덮개가 닫히기 직전까지는 확실히 작동하는 이유가 바로 이것입니다.

AI 코딩 에이전트는 서버에서 RAM이 얼마나 필요할까요?

대부분의 예상보다 적습니다. 모델이 거기서 돌지 않기 때문입니다. Claude Code가 공개한 시스템 요구 사항은 RAM 4 GB 이상과 x64 또는 ARM64 프로세서를 요구하며, GPU 요구 사항은 없습니다. 추론은 모델 제공자의 하드웨어에서 일어나기 때문입니다. 하한선을 정하는 것은 모델이 아니라 에이전트 자신의 도구 체인, 즉 체크아웃, 빌드 단계, 언어 런타임입니다.

3년 기준으로 Mac mini가 서버를 빌리는 것보다 쌀까요?

얼마만큼의 기계가 필요한지에 달렸습니다. 임대 시장의 밑바닥에서는 작은 서버 3년치가 Mac mini 값의 일부에 불과합니다. Mac mini는 이제 기본 M6 구성이 $899부터 시작하며 9월 22일에 배송됩니다. 사다리를 올라가면 소유한 하드웨어가 이깁니다. 구매 가격은 끝이 있지만 월 청구서는 끝이 없기 때문입니다. 어느 쪽이든 그건 비용에 대한 답이지, 휴대용 기계의 상시 가동 작업이 어디에 있어야 하는가에 대한 답은 아닙니다.

서버 연결을 끊은 뒤에도 에이전트 세션을 계속 돌아가게 하는 건 무엇인가요?

터미널 멀티플렉서입니다. 에이전트를 서버의 tmux (또는 screen) 세션 안에서 실행한 뒤 분리(detach)하세요. SSH 연결이 끊겨도 계속 돌아가고, 나중에 어디서든 다시 붙을 수 있습니다. 그게 없으면 터미널을 닫는 것만으로 그 셸에 직접 붙어 있던 프로세스가 죽을 수 있고, 노트북을 떠나며 피하려 했던 바로 그 문제를 서버에서 그대로 재현하게 됩니다.