밤, 아치형 노르딕 홀 안 돌 벤치에 앉은 NordBastion의 북극곰 마스코트가 닫힌 노트북 옆에서 청록색 홀로그램 루프와 시계 모양 아래 서버 랙을 바라보고 있다
방법 가이드 · 실습 25분·2026년 업데이트됨

VPS에서 AI 에이전트를 24/7 실행하기.
노트북을 벗어나, 잠들지 않는 금속 위로.

VPS에서 AI 에이전트를 24/7 실행하려면 네 가지가 필요합니다. 어느 것도 대단히 영리한 것은 아닙니다: 계속 켜져 있는 서버, 그것을 재시작하는 감독 프로세스, 이미지에는 절대 들어가지 않는 시크릿, 그리고 지출 상한 — 여기에 여러분의 신원을 요구하지 않는 호스트가 더해집니다.

요약
  • 01

    대부분의 에이전트는 호스팅된 모델 API를 감싸는 I/O 바운드 접착제에 불과합니다. 추론이 여러분의 서버에서 일어나지 않으므로 서버는 작아도 됩니다: 2 vCPU와 4 GB면 단일 루프 에이전트를 충분히 감당합니다.

  • 02

    가동 시간은 하드웨어 문제가 아니라 감독 프로세스 문제입니다. systemd 유닛이든 Docker 재시작 정책이든 — 활성화하고, 실제 재부팅으로 테스트하는 것 — 이것이 전부입니다.

  • 03

    실제로 물어뜯는 두 가지: 이미지 레이어에 그대로 구워진 시크릿, 그리고 지출 상한 없이 종량제 API를 상대로 밤새 루프를 도는 에이전트.

제1장

왜 노트북은 배포가 아닌가. 네 가지 실패 양상, 하나같이 지루하다.

여러분의 컴퓨터에서 작동하는 에이전트는 작동하는 에이전트일 뿐, 배포된 에이전트는 아닙니다. 그 간극은 네 가지 화려하지 않은 문제이며, 어느 것도 프롬프트 엔지니어링과는 관계가 없습니다.

절전 모드. 뚜껑을 닫으면 프로세스가 중단됩니다. 전원 관리 기능은 뚜껑이 닫히기 훨씬 전부터 백그라운드 작업을 억제하는데, 이는 이 실패의 최악의 버전을 만듭니다: 실행되긴 하지만 늦게, 예측할 수 없게 실행되는 에이전트.

IP 변동. 가정이나 카페 연결은 재접속할 때마다 새 주소를 부여합니다. IP로 속도 제한되는 모든 것, 안정적인 콜백이 필요한 모든 웹훅, 여러분이 등록한 모든 허용 목록이 간헐적으로 깨집니다.

재부팅. 운영체제 업데이트는 자체 일정에 따라 컴퓨터를 재시작합니다. 에이전트가 서비스 관리자에 등록되어 있지 않다면, 재시작 후 돌아오는 것은 실행 중인 루프가 아니라 데스크톱 화면입니다. 대부분의 사람들은 일주일 뒤에야 알아챕니다.

이동. 여행을 가고, 컴퓨터를 바꾸고, 재설치합니다. 오직 셸 히스토리 안에만 존재하는 것은 재현할 수 없습니다 — 3월 어느 오후에 뚝딱 설정한 에이전트에는 애초에 배포 절차라는 것이 없습니다.

서버는 이 네 가지만 고칠 뿐, 그 이상은 고치지 않습니다 — 정확성도, 비용도, 안전성도 아닙니다. 서버가 주는 것은 실패를 여러분이 직접 고쳐야 하는 런타임입니다. 이보다 더 대단한 것으로 파는 사람이 있다면 의심하십시오.

제2장

서버 크기 정하기. 어떤 에이전트 형태에 어떤 VPS 등급인가.

인공지능이라고 하면 무거울 것 같아 과다 프로비저닝하려는 본능이 생깁니다. 하지만 모델이 남의 하드웨어에서 돌아가는 한 그렇지 않습니다: 호스팅된 API를 호출하는 에이전트는 시간 대부분을 네트워크 I/O를 기다리며 보냅니다. 세 번째 형태 — 모델 자체를 실행하는 것 — 는 이 글의 범위 밖입니다. 그 워크로드는 가상 머신보다 GPU를 원합니다.

형태 하나 — 단일 루프. 프로세스 하나, 폴링 또는 예약 루프, 호스팅된 모델 API, SQLite에 담긴 상태. 대부분의 인디 에이전트와 모니터링 봇이 여기에 해당하며, 정말로 작습니다.

형태 둘 — 작은 스택. 에이전트에 더해 Postgres, Redis 기반 큐, 워커, 벡터 스토어. 이제는 메모리가 결정적인 제약입니다 — 프로세스 내에 적재된 임베딩 모델은 그 자체로 1~2기가바이트를 원합니다.

카탈로그에 대입해 보면: Sentinel(NB-V1 — 2 vCPU, 4 GB RAM, 120 GB NVMe, 1 Gbps, 무제한 대역폭, 월 $3.90)은 형태 하나를 여유 있게 커버합니다. Garrison(NB-V2 — 4 vCPU, 8 GB, 240 GB, 월 $7.90)은 Postgres와 큐가 그림에 들어오는 순간 형태 둘의 정직한 최소선입니다. Ravelin(NB-V3 — 8 vCPU, 16 GB, 480 GB, 2.5 Gbps, 월 $16.90)은 여러 에이전트가 한 서버를 함께 쓸 때를 위한 것입니다. 로컬 추론은 전용 서버의 영역입니다.

약정은 월 단위로 진행되며, 더 긴 약정에는 할인이 붙습니다 — 3개월 10%, 6개월 20%, 12개월 30%. 에이전트가 Python 프로세스가 아니라 Windows 전용 트레이딩 클라이언트라면, 그런 경우를 위해 remote-desktop 등급이 마련되어 있습니다.

제3장

배포 경로 — 약 15분 만에 VPS에서 AI 에이전트 실행하기.

서버는 Ubuntu 24.04 LTS나 Debian 13으로 프로비저닝하십시오 — 주문 시 Ubuntu 22.04, Debian 12, AlmaLinux 9, Rocky Linux 9와 함께 제공됩니다. root 자격증명을 받게 되는데, 그것으로 해야 할 첫 번째 일은 그것을 그만 쓰는 것입니다. SSH 키 인증이 낯선 영역이라면, 아래 링크된 보안 강화 가이드를 먼저 읽으십시오.

1 — 서비스 사용자 만들기. adduser --system --group --home /srv/agent agent. 에이전트는 root로 실행되어서도, 대화형 셸을 소유해서도 안 됩니다. 지금 명령어 하나면, 나중에 에이전트가 호출하는 도구가 자신에게 불리하게 쓰이더라도 피해 반경이 작게 유지됩니다.

2 — 코드를 서버에 올리기. /srv/agent에 git clone하거나, 서버에 배포 키를 남기고 싶지 않다면 rsync를 쓰십시오. 의존성을 고정하십시오: 락파일이 있느냐 없느냐가 재현되는 재배포와 여러분을 놀라게 하는 재배포의 차이입니다.

3 — 환경 구축하기. python3 -m venv /srv/agent/.venv를 실행한 다음, 그 virtualenv의 pip로 락파일에서 설치하십시오. 아니면 uv를 설치해 인터프리터와 락파일 둘 다 관리하게 하십시오. 둘 중 무엇이든 괜찮지만, 둘을 섞는 것은 안 됩니다.

4 — 손으로 한 번 실행해 보기. sudo -u agent /srv/agent/.venv/bin/python -m agent --once. 이 단계를 건너뛰고 곧장 서비스 유닛으로 가지 마십시오. 여기서 나는 실패의 열 중 아홉은 누락된 환경 변수나 여러분의 노트북 기준 상대 경로 때문이며, 둘 다 journald보다 터미널에서 훨씬 또렷하게 읽힙니다.

5 — 감독 프로세스에게 넘기기. 다음 장의 내용입니다. 이 단계가 여러분이 시작한 스크립트를 컴퓨터가 소유하는 서비스로 바꿔 줍니다. 이 과정이 15분보다 상당히 오래 걸렸다면, 원인은 거의 항상 개발 머신에 대한 암묵적 의존성입니다 — 전역 바이너리, 셸 프로필 속 자격증명, 저장소 밖의 경로.

제4장

24/7 계속 살아있게 하기. systemd, Docker, 그리고 크래시 루프 함정.

SSH 세션을 통해 시작한 프로세스는 세션이 끝나면 죽고, 재부팅 후에도 돌아오지 않습니다. 감독은 선택 사항이 아니며, 합리적인 선택지는 두 가지입니다.

systemd, 단일 프로세스를 위해. /etc/systemd/system/agent.service에 User=agent, WorkingDirectory=/srv/agent, virtualenv 인터프리터를 가리키는 ExecStart, Restart=always, RestartSec=5를 담은 유닛. 그다음 systemctl daemon-reload, 그다음 systemctl enable --now agent. 재부팅을 견뎌내는 것은 enable입니다. enable 없이 시작만 해두는 것이 3주 뒤 에이전트를 잃어버리는 가장 흔한 방법입니다.

Docker, 여러 개를 위해. 에이전트에 형제가 있을 때 — 데이터베이스, 큐, 헤드리스 브라우저 — 하나의 Compose 파일 안에 각 서비스마다 restart: unless-stopped를 붙여 기술하십시오. unless-stopped는 always와 중요한 한 지점에서 다릅니다: 여러분이 의도적으로 멈춘 컨테이너는 데몬이 재시작되어도 멈춘 채로 남습니다.

크래시 루프 함정. systemd는 기본적으로 재시작을 속도 제한합니다. 그 구간 안에서 충분히 자주 크래시하면 유닛은 failed 상태에 들어가 재시도를 멈춥니다 — 유닛 파일이 분명히 Restart=always라고 적혀 있는데도 소리 없이 죽은 것처럼 보이는 에이전트가 됩니다. 무한히 재시도하려면 StartLimitIntervalSec=0으로 설정하고, 고장 난 에이전트가 밤새 코어를 돌리지 않도록 RestartSec을 늘리십시오.

살아있음은 건강함이 아닙니다. 소켓 읽기에 아홉 시간째 멈춰 있는 루프도 systemd가 볼 수 있는 모든 척도에서는 실행 중인 프로세스입니다. 심박을 노출하십시오: WatchdogSec을 쓴 워치독, Docker HEALTHCHECK, 또는 에이전트가 주기마다 건드리는 타임스탬프 파일에 그것이 오래되면 경고하는 타이머를 붙이는 방법.

제5장

시크릿. 이미지에 결코 닿아서는 안 되는 환경 파일.

에이전트는 웹 애플리케이션보다 더 위험한 자료를 쥐고 있습니다. 모델 API 키는 지출 수단이고, 트레이딩 키는 레버리지가 걸린 것이며, 지갑 키는 자금 그 자체입니다. 그리고 웹 앱과 달리 에이전트는 자신이 작성하지 않은 텍스트에 따라 행동하는데, 이는 에이전트가 키를 쥐고 있는 것과 공격자가 그 키를 쥐고 있는 것 사이의 경계를 얇게 만듭니다.

이미지 밖에 두십시오. Dockerfile 속 ENV와 ARG 값은 이미지 레이어에 그대로 기록되어, 그 이미지를 손에 넣은 누구든 docker history로 읽을 수 있습니다. Compose에서는 env_file:을, systemd 유닛에서는 EnvironmentFile=을 쓰고, 그 파일을 빌드 컨텍스트 밖에 두십시오.

저장소 밖에 두십시오. .gitignore와 .dockerignore는 쉰 번째 커밋이 아니라 첫 커밋에 넣으십시오. 한 번이라도 커밋된 키는 그 커밋을 나중에 다시 쓰더라도 이미 유출된 것입니다. 객체가 클론과 포크 안에 살아남기 때문입니다. 히스토리를 다시 쓰는 대신 키를 교체하십시오.

그 파일이 닿을 수 있는 범위를 제한하십시오. 환경 파일의 소유자를 서비스 사용자로 지정하고 mode 600을 설정하십시오. non-root 서비스 사용자와 결합하면, 서버 어딘가의 침해된 의존성이 디스크에서 여러분의 키를 그냥 읽어 갈 수는 없습니다.

발급처에서 각 키의 범위를 제한하십시오. 에이전트당 키 하나씩, 제공업체가 내주는 가장 좁은 권한으로 — 읽기만으로 충분하면 읽기 전용으로, 거래소 키는 출금 비활성화로, 서버로 IP 허용 목록을 걸어서. 고정 IP는 노트북을 벗어나면서 얻는 조용한 이점입니다: 이제야 비로소 허용 목록을 걸 수 있게 됩니다. 여러 사람이 같은 자격증명을 필요로 한다면, 자매 가이드에 나오는 셀프 호스팅 볼트 뒤에 두십시오.

제6장

스케줄링. 루프, 타이머, 그리고 여러분을 무는 시간대.

계속 실행된다는 말은 서로 다른 세 가지 아키텍처를 가리킬 수 있으며, 잘못된 것을 고르는 것은 작업 중복과 실행 누락의 흔한 원인입니다.

상주 루프. 주기 사이에 잠드는, 오래 사는 프로세스 하나. 이해하기 가장 쉽고, 올바른 기본값입니다. 약점은 상태입니다: 메모리에 있는 모든 것은 재시작하면 사라지므로, 크래시에도 살아남아야 하는 것은 변수가 아니라 SQLite나 Postgres에 있어야 합니다.

예약 실행. 시작해서 작업 단위 하나를 처리하고 종료하는 프로세스. OnCalendar를 쓴 systemd 타이머가 여기서는 더 나은 도구인데, 주된 이유는 Persistent=true 때문입니다: 다운타임 후, persistent 타이머는 놓친 실행을 대신 발동시키는 반면 cron은 그냥 건너뜁니다.

큐. 생산자가 작업을 큐에 넣고, 워커들이 그것을 소비합니다. 작업이 처리되는 속도보다 빠르게 도착하는 순간 이것이 필요해집니다. 재시도, 데드레터 처리, 동시성 상한도 함께 얻습니다.

무엇을 고르든 두 가지 규칙. 모든 작업을 멱등하게 만드십시오 — 크래시 시 재시작하는 감독 프로세스는 작업을 재시도할 것이며, 재시도된 작업이 이중으로 게시하거나 이중으로 주문해서는 안 됩니다. 그리고 서버 시계는 UTC로 두고, 변환은 오직 경계에서만 하십시오: 1년에 두 번 한 시간씩 밀리는 일정은 찾아내기 지루한 버그입니다.

제7장

에이전트에게 도구 쥐여주기. 같은 서버 위의 도구 서버.

도구가 없는 에이전트는 채팅 루프에 불과합니다. 도구는 저장소를 읽고, 데이터베이스를 조회하고, 주문을 넣고, 이슈를 등록하게 해 주는 것입니다 — 그리고 에이전트가 서버 위에 살게 되면, 도구도 그래야 합니다.

Model Context Protocol은 그런 도구를 노출하는 흔한 방식이 되었고, 여러분이 사적으로 실행하는 서버는 에이전트 옆에 두기 쉽습니다: 같은 서버, 같은 사설 인터페이스, 공개 노출이 필요 없습니다. 자매 가이드가 이를 제대로 다룹니다 — 원격 MCP 서버 호스팅하기는 TLS, streamable-HTTP 전송 방식, OAuth, 에이전트 카드까지 안내하며, no-ID 호스팅 관점은 같은 스택을 신원 측면에서 다룹니다.

먼저 localhost에 바인딩하십시오. 유일한 소비자가 같은 머신 위의 에이전트뿐이라면, 도구 서버가 공개 포트를 가질 이유가 없습니다. 루프백 주소에 바인딩하고 인증서는 건너뛰십시오. 두 번째 머신이 필요로 할 때만 공개로 노출하십시오 — 그리고 그때는 TLS와 인증 둘 중 하나가 아니라 둘 다 필요합니다.

도구에는 통하는 한 가장 작은 권한만 주십시오. 에이전트는 텍스트를 근거로 어떤 도구를 호출할지 결정하며, 그 텍스트 중 일부는 외부에서 옵니다. 웹페이지나 받은편지함을 읽는 에이전트에게 프롬프트 인젝션은 가정이 아니라 예상해야 할 사례입니다. 읽기만 할 수 있는 도구는 쓰기를 하도록 설득당할 수 없습니다. 도구가 반드시 써야 하는 곳에서는, 파괴적인 경로에 사람의 확인을 요구하게 만드십시오.

여러분 자신의 에이전트가 아니라 다른 사람들의 에이전트를 위한 도구를 만들고 있다면, machine API에이전트 대상 서피스가 이 플랫폼이 프로비저닝을 에이전트에게 직접 어떻게 노출하는지 문서화합니다.

제8장

관찰 가능성과 비용. 무엇을 기록할 것인가, 그리고 폭주 킬 스위치.

실제 에이전트 배포를 지배하는 실패 양상은 두 가지이며, 둘 다 크래시가 아닙니다. 하나는 완벽하게 실행되지만 쓸모 있는 것을 아무것도 만들어내지 못하는 에이전트입니다. 다른 하나는 완벽하게 실행되지만 하룻밤 사이에 네 자릿수 API 청구서를 만들어내는 에이전트입니다.

내용이 아니라 형태를 기록하십시오. 타임스탬프, 작업 id, 단계 수, 호출된 도구 이름, 토큰 총합, 소요 시간, 결과. 그것이 여러분이 실제로 물을 모든 운영상의 질문에 답해 줍니다. 전체 프롬프트와 응답은 에이전트가 지금껏 요청받은 모든 일의 기록을, 평문으로, 남의 건물 안 디스크 위에 남기는 것입니다.

보존 기간에 상한을 두십시오. journald는 여러분이 멈추라고 하기 전까지 계속 자랍니다. journald.conf의 SystemMaxUse와 MaxRetentionSec이 크기와 나이 둘 다에 상한을 둡니다. 그렇지 않으면 수다스러운 에이전트가 몇 주 만에 디스크를 채우며, 가득 찬 디스크는 깔끔한 크래시보다 훨씬 읽어내기 어려운 방식으로 고장 납니다.

세 겹의 지출 통제. 제공업체 단에서는 API 키에 하드 상한을 두십시오 — 여러분 코드의 어떤 버그도 우회할 수 없는 유일한 제한이며, 사람들이 흔히 건너뛰는 것이기도 합니다. 에이전트 안에서는 실행당 토큰 카운터에 중단 임계값을 두십시오. 에이전트 주변에서는 최대 단계 수와 실시간 타임아웃을 두어, 스스로와 논쟁하는 모델이 4천 번이 아니라 스무 번 반복 후 멈추게 하십시오.

필요해지기 전에 킬 스위치를 만들어 두십시오. 모든 것을 멈추는 명령어 하나: systemctl stop agent, 또는 docker compose down. 특정 키가 담긴 노트북을 요구하지 않도록 하십시오. 나쁜 하룻밤과 나쁜 한 달의 차이는 폭주를 멈추는 데 10초가 걸리느냐 한 시간이 걸리느냐입니다.

제9장

신원의 최소선. 호스트가 아는 것 — 그리고 호스트가 여러분을 지켜줄 수 없는 것.

에이전트는 자격증명을 지닌, 오래 사는 프로세스로서 고정된 주소에서 여러분을 대신해 계속 행동합니다. 이는 정적 웹사이트보다 대여 기록을 더 흥미롭게 만듭니다: 몇 달 동안, 매시간, 여러분에게 귀속되는 일을 하고 있는 것입니다.

여기서의 최소선은 가입을 위한 이메일 주소와 비밀번호, 여덟 가지 자산으로의 결제 — Bitcoin, Ethereum, 두 체인의 Tether, Monero, Litecoin, TRON, Solana — 그리고 어떤 단계에서도 신분증이 없다는 것입니다. 데이터센터는 네 개의 노르딕 입헌 체제 안에 있습니다: Stockholm, Helsinki, Oslo, Reykjavík. 운영 원칙이 무엇이 보관되는지 규정하며, 네트워크 페이지가 라우팅을 다룹니다.

이제 홍보 문구보다 더 중요한 한계입니다. 신원을 요구하지 않는 호스트는 대여 기록을 제거합니다. 추론 계층에는 손을 대지 않습니다: 여러분의 에이전트는 매 호출마다 계정에 묶인 키로, 고정된 IP에서 모델 제공업체에 인증합니다. 그 계정이 여러분의 법적 이름으로 되어 있다면 — 대부분의 사람들에게 그렇듯이 — 누가 서버를 대여하든 상관없이 신원은 그곳에서 확립됩니다. 호스트 계층이 제거하는 연결 고리는 하나입니다: 진짜이지만, 오직 하나뿐인 연결 고리.

그다음에 이어지는 것은 화려하지 않습니다. 구획화하십시오: 에이전트 하나, 서버 하나, 키 하나, 지갑 하나. 서버는 30일째가 아니라 첫날에 강화하십시오 — 첫 한 시간 체크리스트는 몇 달 동안 사람 없이 돌아갈 머신에 쓸 만한 가치가 있는 한 시간입니다. 에이전트가 사설 네트워크에 닿아야 한다면, 서비스를 노출하는 대신 터널로 서버에서 종단시키십시오 — 터널 가이드가 설정을 다룹니다. 그리고 암호화폐로 결제하되, 에이전트가 트레이딩에 쓰는 지갑이 아닌 다른 지갑에서 하십시오.

이 중 어느 것도 이국적이지 않으며, 어느 것도 보장이 아닙니다. 여러분이 잠든 사이 여러분을 대신해 행동하는 무언가를 운영하는, 그저 평범한 규율일 뿐입니다 — 계속 운영된다는 말이 뜻하는 전부입니다. 나머지 클러스터는 가이드 색인에 있습니다.

FAQ · VPS의 에이전트

질문들, 답변됨.

개발자가 에이전트를 localhost 밖으로 옮기기 전 — 그리고 그 후 첫 한 달 동안 — 묻는 일곱 가지 질문.

AI 에이전트를 24/7 실행하려면 VPS가 얼마나 필요한가요?

사람들이 예상하는 것보다 적습니다. 추론은 여러분의 하드웨어가 아니라 제공업체의 하드웨어에서 일어나기 때문입니다. 호스팅된 모델 API를 호출하고 폴링 루프를 도는 에이전트는 I/O 바운드 프로세스입니다: Sentinel 등급(2 vCPU, 4 GB RAM, 120 GB NVMe, 월 $3.90)이면 여유 있게 충분합니다. Postgres, 큐, 로컬 임베딩 모델을 추가하는 순간 Garrison(4 vCPU, 8 GB, 월 $7.90)으로 올라가십시오.

에이전트를 계속 실행하려면 systemd를 써야 하나요, Docker를 써야 하나요?

둘 다 통합니다. 다만 실패 양상이 다릅니다. Restart=always를 설정한 systemd 유닛은 단일 프로세스에 가장 짧은 경로이며 journald, 리소스 제한, 부팅 순서를 공짜로 제공합니다. restart: unless-stopped를 설정한 Docker는 에이전트에 형제 프로세스가 있을 때 더 낫습니다. Compose가 전체 구성을 파일 하나로 기술하기 때문입니다. 더 중요한 것은 실제로 이를 활성화하고, 자리를 뜨기 전에 재부팅으로 테스트해 보는 것입니다.

제 에이전트는 몇 번 크래시하고 나면 왜 재시작을 멈추나요?

systemd가 재시작을 속도 제한하기 때문입니다. StartLimitBurst와 StartLimitIntervalSec는 짧은 시간 창 안에서 소수의 재시작만 허용합니다. 이를 초과하면 유닛은 failed 상태에 들어가 그대로 머무르는데, 이는 마치 소리 없이 죽은 것처럼 보입니다. 근본 원인이 되는 크래시를 고치는 것이 — 올바른 답입니다 — 아니라면, StartLimitIntervalSec=0으로 제한기를 비활성화하고 RestartSec=10을 설정하여 크래시 루프에 빠진 에이전트가 재시도하며 코어를 태우지 않도록 하십시오.

API 키는 어디에 두어야 하나요?

컨테이너 이미지가 결코 보지 못하는 파일 안에 두십시오. 빌드 컨텍스트 밖에 환경 파일을 두고, systemd 유닛에서는 EnvironmentFile=로, Compose에서는 env_file:로 참조하며, 서비스 사용자 소유에 mode 600으로 설정하십시오. 시크릿에는 Dockerfile의 ENV나 ARG를 절대 쓰지 마십시오. 그 값들은 이미지 레이어에 그대로 구워져 docker history로 읽을 수 있습니다. 첫 커밋 전에 그 파일을 .gitignore와 .dockerignore에 추가하십시오.

에이전트가 하룻밤 사이에 API 예산 전체를 써버리지 않게 하려면 어떻게 해야 하나요?

세 겹이 필요하며, 세 겹 모두 갖추어야 합니다. 제공업체 단에서는 API 키에 하드 지출 상한을 두십시오. 여러분 코드의 어떤 버그도 우회할 수 없는 유일한 제한입니다. 에이전트 안에서는 실행당 토큰이나 호출 수를 세어 임계값을 넘으면 중단하십시오. 에이전트 주변에서는 작업당 단계 상한과 실시간 타임아웃을 두십시오. 어떤 호스트도 이것을 대신해 줄 수 없습니다 — VPS는 대여한 컴퓨팅 용량일 뿐, 남의 API에 대한 예산 감시자가 아닙니다.

에이전트 로그에 절대 남기지 말아야 할 것은 무엇인가요?

전체 프롬프트와 응답, 원본 도구 인자, API 키, 지갑 관련 자료, 사용자가 입력한 모든 것입니다. 대신 실행의 형태만 기록하십시오: 타임스탬프, 작업 id, 단계 수, 도구 이름, 토큰 총합, 소요 시간, 결과. 장황한 에이전트 로그는 에이전트가 지금껏 요청받은 모든 일의 기록을, 평문으로, 여러분이 물리적으로 통제하지 않는 디스크 위에 남기는 것과 같습니다.

KYC 없는 호스트를 쓰면 제 에이전트가 익명이 되나요?

아니요. 정확히 짚을 필요가 있습니다. 신분증 없는 가입과 암호화폐 결제는 호스트가 서버에 결부시킬 법적 신원을 갖고 있지 않다는 뜻일 뿐입니다. 모델 제공업체에 대해서는 아무것도 바꾸지 않습니다. 여러분의 에이전트는 매 호출마다 계정에 묶인 키로, 고정된 서버 IP에서 그 API에 인증합니다. 호스트 계층이 제거하는 것은 사슬 속 연결 고리 하나 — 대여 기록 — 뿐이며, 그것이 제거하는 전부입니다.

서버를 확보하십시오

KYC 없는 VPS를 임대하고, 암호화폐로 결제하며, 오늘 밤 바로 에이전트를 노트북 밖으로 옮기십시오.

Sentinel — 2 vCPU, 4 GB RAM, 120 GB NVMe, 무제한 대역폭, 월 $3.90 — 단일 루프 에이전트를 여유 있게 감당하며 옆에 도구 서버를 둘 공간까지 있습니다. 가입에는 이메일 주소와 비밀번호뿐, 어떤 단계에서도 서류는 없습니다.

마지막 검토일 · 2026-08-24 · 출처 · systemd.service, systemd.timer, journald.conf 매뉴얼 페이지, Docker restart-policy 및 Compose 문서, Model Context Protocol 명세, NordBastion 카탈로그 · 주기 · 연간