로컬 AI 에이전트용 PC 사양: 작업·문맥·상시 운영으로 고르기

회의록 한 파일을 읽고 핵심을 정리해 달라고 요청한다고 가정해 보겠습니다. 일반 채팅이라면 파일 내용을 보내고 답을 기다리면 끝날 수 있습니다. 에이전트는 파일을 찾고, 읽기 도구를 고르고, 결과를 다시 모델에 전달한 뒤, 필요하면 검색이나 추가 도구를 거쳐 답을 만듭니다. 모델을 실행하는 데 필요한 자원과 이 전체 흐름을 감당하는 자원은 겹치지만 같지는 않습니다.

OpenClaw나 Hermes Agent 같은 프로그램은 모델 가중치가 아닙니다. 이들은 대화와 세션, 도구 호출², 채널 또는 자동화 흐름을 조정하는 런타임입니다. 실제 문장을 생성하는 모델은 같은 컴퓨터의 로컬 서버에서 돌릴 수도 있고, 별도 LAN 장비나 호스티드 API³에 둘 수도 있습니다. 따라서 ‘OpenClaw 사양’ 하나로 하드웨어를 고르면 무엇을 실행할지 빠뜨리게 됩니다.

먼저 세 질문을 분리하세요. 에이전트 런타임을 설치하고 계속 켜 둘 컴퓨터는 무엇인가요? 모델 서버는 어디서 돌리나요? 한 번의 요청에서 파일·브라우저·검색·셸 가운데 어떤 도구를 몇 번 쓸 예정인가요? 런타임만 작은 PC에 두고 모델은 다른 GPU⁴ 서버에 연결하는 구성도 가능합니다. 반대로 한 대에서 모든 작업을 처리하면 여유 메모리와 열·소음·유휴 전력까지 고려해야 합니다.

모델이 로드됐다는 표시는 첫 관문일 뿐입니다. 같은 모델도 짧은 한 줄 질문과 긴 대화 이력, 도구 정의, 파일 발췌가 붙은 에이전트 요청에서 필요한 메모리가 달라집니다. 채팅 응답이 정상이라고 해서 도구 호출 형식이 맞거나 목표 작업이 완수됐다는 보장도 없습니다. 이 글에서는 회의록을 읽고 요약하는 한 작업을 유지하면서, 메모리와 기다림의 조건을 하나씩 더해 보겠습니다.

첫 후보를 고를 때 모델 파일 크기는 유용한 출발점입니다. 다만 파일 크기만큼의 메모리만 있으면 된다는 뜻은 아닙니다. 모델 가중치가 메모리에 올라가고, 입력과 대화 상태를 다루는 컨텍스트 캐시가 추가되며, 추론 엔진과 운영체제·다른 앱도 메모리를 씁니다. GPU에 일부를 올리고 나머지를 시스템 RAM⁵에 둘 수 있는지는 엔진과 모델 형식, 장비에 따라 달라집니다.

OpenClaw의 공식 로컬 모델 안내도 요구량이 가중치, 컨텍스트 크기, 런타임, 같은 호스트의 다른 작업에 따라 달라진다고 설명합니다. 설치 과정에서 사용 가능한 RAM, 지원되는 GPU 메모리, 디스크 공간을 확인하는 이유가 여기에 있습니다. 공식 문서의 특정 관리형 모델 레시피에 적힌 메모리 바닥값은 그 레시피가 검토한 조건이지, 모든 모델·엔진·도구 구성에 대한 최소 사양이나 속도 보증이 아닙니다.

컨텍스트 창도 모델 파일 크기와 별개입니다. 모델 카드의 최대 컨텍스트 숫자는 한 번에 처리할 수 있는 토큰⁶ 한도에 가깝고, 그 한도를 실제로 쓰면 캐시 메모리가 늘 수 있습니다. 동시에 에이전트는 시스템 지침, 스킬 설명, 사용 가능한 도구의 이름과 인자 형식, 이전 대화, 파일에서 가져온 부분을 함께 보낼 수 있습니다. 긴 컨텍스트를 지원한다고 표시된 모델이라도 현재 서버가 그 길이를 허용하는지, 메모리에 올릴 수 있는지는 따로 확인해야 합니다.

같은 작업으로 후보를 비교하려면 회의록 파일 자체만 재지 말고 실제 요청에 실리는 입력을 기록하세요. 시스템 프롬프트, 도구 설명, 대화 이력, 읽을 파일 분량, 답변 길이, 검색 결과 포함 여부를 고정합니다. 그런 다음 모델 파일을 불러온 상태에서 시스템 메모리와 GPU 메모리 사용량, 사용 가능한 공간, 요청 실패나 메모리 회수 여부를 봅니다. 숫자는 OS와 런타임 계측 방식에 영향을 받으므로 다른 장비의 숫자와 곧바로 등치하지 않습니다.

메모리에 올라간 모델이 회의록 요약을 생성하는 동안에도 전체 완료 시간은 모델 속도 하나로 결정되지 않습니다. 요청을 받은 뒤 모델이 입력을 읽는(prefill⁷) 시간, 답을 생성하는 시간, 파일 도구가 디스크에서 읽는 시간, 검색 서버의 응답, 에이전트가 결과를 다시 해석하는 시간이 차례로 더해질 수 있습니다. 한 번의 목표 작업에 모델 호출이 몇 차례 들어가는지도 중요합니다.

간단한 계산으로 구분해 봅시다. 설명을 위한 가정에서 모델 입력 처리가 12초, 답변 생성이 18초, 파일 도구가 2초, 외부 검색 왕복이 8초 걸린다고 놓으면 전체는 40초입니다. 이는 측정값이나 특정 장비의 예측이 아닙니다. GPU가 입력 처리 시간을 절반으로 줄여도 다른 구간이 그대로라면 합계는 34초가 됩니다. 바뀐 것은 12초 구간뿐이고, 네트워크 대기나 파일 읽기까지 같은 비율로 빨라진 것이 아닙니다.

외부 검색을 쓰지 않는 작업이면 이 계산에서 검색 대기 구간을 뺍니다. 반대로 브라우저가 페이지를 열고, 내용을 읽고, 다음 페이지를 검색하면 도구 왕복이 여러 번 생길 수 있습니다. 실제 제품과 네트워크에서 그 시간이 얼마인지는 작업마다 재야 합니다. 모델 토큰/초만 보고 ‘에이전트가 이 정도면 몇 초 안에 끝난다’고 단정할 수 없는 이유입니다.

실제 비교에서는 같은 모델 파일과 양자화⁸, 엔진 버전, GPU 배치, 컨텍스트 설정, 입력과 출력 길이를 고정하고, 준비 실행 뒤 같은 작업을 반복해 중앙값을 기록하세요. 모델을 처음 올리는 콜드 실행과 이미 로드된 웜 실행⁹은 따로 적습니다. 도구 사용 단계마다 시작·끝 시각과 성공 여부를 남기면, 모델을 바꿔야 하는지 검색 연결을 고쳐야 하는지 구분할 수 있습니다. 실제로 측정하지 않은 숫자는 사용하지 않습니다.

메신저 봇이나 정기 보고서를 밤낮으로 받으려면 에이전트 런타임이 계속 살아 있어야 합니다. 그렇다고 모델 프로세스까지 계속 메모리에 둬야 하는지는 별도 설정입니다. 모델 서버가 유휴 상태에서 언로드된다면 다음 요청은 다시 읽고 초기화하는 시간을 포함합니다. 모델을 계속 올려 두면 그 대기 일부를 줄일 수 있지만, 그동안 다른 앱이 쓸 RAM이나 VRAM¹⁰이 줄고 전력과 열이 계속 생깁니다.

메모리 구매를 검토하기 전에 평소 켜 두는 앱과 동시에 들어올 요청 수를 적어 보세요. 예를 들어 회의 요약 한 건만 사람이 실행한다면 순차 처리로 충분할 수 있습니다. 여러 메신저, 예약 작업, 두 명의 사용자가 겹치면 같은 모델을 공유해 큐에 쌓을지, 복수 모델/인스턴스를 동시에 띄울지 결정해야 합니다. 프로필이나 봇 숫자보다 실제로 동시에 활성화되는 추론 서버와 컨텍스트가 메모리 피크를 좌우합니다.

호스트를 재부팅했을 때 에이전트와 모델 서버가 어떻게 다시 시작되는지도 확인하세요. 서비스가 로그인 전에 떠야 하는지, 디스크에 모델 파일이 충분히 있는지, 네트워크가 끊기면 로컬 작업만 계속할지, 메시징 채널에 접근하지 못할 때 오류를 어떻게 알릴지 적습니다. 상시 운영용 장비는 최고 속도만큼 복구 가능한 설정과 냉각, 소음, 안정적인 저장공간이 중요할 수 있습니다. 실제 전력은 해당 장비와 유휴·부하 조건에서 측정해야 합니다.

Hermes의 관리형 로컬 모델과 OpenClaw의 관리형 llama.cpp 경로는 각 프로젝트가 지원하는 특정 런타임 및 릴리스의 기능입니다. 현재 공식 페이지는 세부 지원 플랫폼, 빌드 채널, 메모리 동작을 버전별로 안내합니다. 이 사실을 Ollama나 LM Studio를 직접 운영하는 모든 설정의 보장으로 넓히지 마세요. 관리형 옵션, 직접 실행하는 서버, 원격 서버를 각각 자신의 환경에서 확인해야 합니다.

회의록을 가끔 요약하고 도구는 읽기 전용으로 쓴다면 우선 현재 PC에서 작은 후보 모델을 시험할 수 있습니다. 단, ‘작다’는 모델 이름이 아니라 실제 파일, 양자화, 컨텍스트 제한, 엔진 지원으로 정합니다. 모델 로드, 짧은 대화, 회의록 입력, 읽기 도구 한 번, 끝까지 요약 작업의 순서로 통과 여부를 확인합니다. 실패 지점을 기록해야 메모리 부족인지 도구 호환성인지 구분할 수 있습니다.

긴 회의록이나 여러 파일을 다뤄야 한다면 실제 자료의 입력 길이와 동시에 켜 둔 앱을 포함해 확인하세요. 컨텍스트를 줄이면 필요한 메모리를 줄일 수 있지만, 모델이 볼 수 있는 자료도 줄어듭니다. 문서를 나눠 요약하거나 검색으로 필요한 부분만 불러오면 모델에 주는 토큰 수를 조절할 수 있습니다. 이 방법이 원문 전체를 한 번에 넣는 구성과 같은 결과를 보장하지 않으므로, 요약의 누락을 사람이 확인해야 합니다.

여러 사용자가 동시에 요청하거나 예약 작업이 겹칠 때만 메모리 압박이 생긴다면, 새 GPU를 사기 전에 요청을 순차 처리하거나 유휴 시 모델을 내리는 설정을 검토할 수 있습니다. 반대로 대기 시간이 작업 흐름을 자주 끊고, 실제 측정에서도 모델 추론¹¹이 병목이면 더 많은 GPU 메모리나 통합 메모리¹², 다른 서버 배치가 도움이 될 수 있습니다. 모델이 도구 호출을 잘못하거나 검색이 느린 문제는 GPU만 바꿔도 해결되지 않습니다.

마지막으로 항상 켜 두는 이유를 점검하세요. 정기 실행이 없다면 데스크톱에서 필요할 때 Gateway¹³와 모델을 켜는 편이 간단할 수 있습니다. 메신저 수신, 예약 보고서, 원격 접근이 필요하면 전원·네트워크·재시작·접근 통제를 포함해 별도 운영 구성을 만듭니다. 구매 결론은 모델 파일의 크기 하나가 아니라 목표 작업, 실제 컨텍스트, 도구 왕복, 동시 요청, 유휴 운영을 함께 시험한 뒤 내릴 수 있습니다.