128기가 맥이 버벅이자 나온 답 — 실행을 월 80달러 서버로 옮기기

저녁 8시 43분, 한 참여자가 맥 램 사용량을 줄이는 방법을 물었다. 곧 덧붙인 한마디가 문제의 크기를 보여줬다. "128도 버벅거리네요"라는 것이다. 128기가 램을 갖춘 장비인데도 버거운 상황이라면, 이는 사양 부족이라기보다 사용 방식의 문제에 가깝다. 실제로 이 방에서는 에이전트 세션을 여러 개 동시에 띄우는 것이 일상이다.

첫 조언은 진단부터였다. 한 참여자는 "클로드한테 그냥 지금메모리 많이먹고있는게 뭔지 …물어보면 의미있는건지없는건지 알려주더라고요"라며, 사람이 프로세스 목록을 뒤지는 대신 모델에게 판단을 맡기는 방법을 공유했다. 실제로 이 방식으로 확인해 보니 이미 끝난 작업의 잔여 프로세스가 남아 있는 경우가 잡혔고, 질문자는 "고아 MCP 서버라니"라며 놀랐다. 다른 참여자도 작업하다 보면 뒤에 쌓이는 게 많더라며 주기적으로 정리해 줘야 한다고 거들었다.

대화의 방향을 바꾼 건 다른 참여자의 고백이었다. 다들 로컬에서 돌린다는 사실에 놀라며, 자신은 클로드 코드 자체를 램 64기가짜리 서버에 올려서 쓴다고 밝힌 것이다. 장비를 키우는 대신 실행 위치를 아예 옮긴 접근이다. 비용은 월 80달러이고 8코어 프로세서에 64기가 램 구성이라는 사양까지 공개됐다. "가격대비 (월 80달러) 나쁘지 않습니다"라는 평가와 함께 3년째 쓰고 있다는 사용 기간도 덧붙었다.

단점도 숨기지 않았다. 유일한 흠은 서버가 국내에 없다는 점이라고 했다. 다만 접속 문제를 겪은 적은 없다고 하면서 그 이유를 함께 설명했는데, 자신이 운영하는 사이트들은 모두 CDN 뒤에 올려두기 때문에 사용자가 서버를 직접 호출하는 일이 없다는 것이다. 지연이 문제가 되는 경로를 애초에 만들지 않는 구성인 셈이다.

이 이야기가 나오자 방의 관심이 서버 스펙 쪽으로 옮겨갔다. 한 참여자는 자신이 계약한 업체의 배포가 이틀이나 걸릴 만큼 느렸다는 경험과, 원하는 지역이 막혀 있었다는 점을 공유하며 "12기가만삿는데"라며 "개후회되네여 ㅋㅋㅋ"라고 했다. 같은 선택지 안에서도 업체와 사양에 따라 경험이 크게 갈린다는 점이 드러난 대목이다.

정리하면 이 대화의 실질적인 함의는 두 가지다. 첫째, 에이전트를 여러 세션 병렬로 돌리는 사용 패턴에서는 로컬 장비 사양이 병목이 되고, 128기가로도 부족하다면 장비를 키우는 것보다 실행 위치를 옮기는 편이 비용 효율이 높을 수 있다. 둘째, 그 선택의 전제 조건은 지연에 대한 설계다. 응답 속도가 곧 사용자 경험이 되는 서비스를 얹을 생각이라면 서버 위치를 먼저 따져야 하고, CDN 뒤에 두는 구성이 함께 있어야 체감 문제가 줄어든다. 무거운 짐을 옮기기 전에 옮길 곳의 조건부터 확인하라는 이야기다.