AI를 서버에 연결하기: AI 에이전트가 내 서버의 배포와 관리를 맡는 방법

지금까지 대부분의 사람은 AI를 전화 너머의 아주 박식한 동료처럼 써 왔습니다. 서버 문제를 설명하면 명령을 제안받고, 그 명령을 콘솔에 복사해 넣고, 오류 메시지를 다시 복사해 보내고, 제대로 될 때까지 이 과정을 되풀이합니다. AI를 서버에 연결하면 이런 우회로가 사라집니다. Claude Code, OpenAI Codex CLI, Gemini CLI 같은 AI 에이전트는 SSH로 서버에 직접 로그인해 로그를 읽고, 설정을 확인하고, 변경 사항을 적용하고, 결과를 테스트한 뒤 무엇을 했는지 기록합니다. 작업은 여러분이 정하고, 되돌릴 수 없는 단계는 여러분이 승인합니다.

이 글은 저희의 실제 운영 경험을 담은 실무 사례입니다. KernelHost에서는 몇 달 전부터 AI 에이전트가 매일 저희 자체 인프라 작업에 참여하고 있습니다. 고객 포털, 모니터링, 결제 수단, 문서화가 그 대상입니다. 에이전트와 서버의 연결을 어떻게 구성하는지, 에이전트가 어떤 절차로 운영 시스템에 배포하는지, 그 과정에서 문제가 생기거나 정보가 외부로 새어 나가지 않도록 어떤 규칙을 두는지, 그리고 이 모든 것이 작동하려면 서버가 무엇을 갖춰야 하는지 보여 드립니다. 도구와 구조에 관한 기초는 AI 관리형 서버: AI 에이전트를 안전하게 연결하기 글에서, 서버에 설치하는 방법은 Claude Code와 Codex CLI 설치 가이드에서 다룹니다.

AI를 서버에 연결한다는 것의 의미

AI를 서버에 연결한다는 것은 AI 에이전트에게 서버 명령줄에 대한 전용 접근 권한을 통제된 형태로 부여하는 것이며, 보통 SSH 키를 사용합니다. 이 순간부터 에이전트는 명령을 제안하는 데 그치지 않고 직접 실행하고, 출력을 읽고, 이를 바탕으로 다음 단계를 도출할 수 있습니다. 언어 모델 자체는 여전히 제공업체(Anthropic, OpenAI 또는 Google)에서 실행되며, 내 컴퓨터나 서버에서는 명령을 보내는 가벼운 명령줄 도구만 실행됩니다.

핵심은 “통제된”이라는 말입니다. 서버에 접근할 수 있는 에이전트는 자동 조종 장치가 아니라, 시스템에 개입하는 작업 전에는 반드시 먼저 묻는 아주 빠른 동료입니다. 묻지 않고 어디까지 해도 되는지는 직접 정합니다. 읽기 전용 접근부터 정해진 절차에 따라 업데이트를 스스로 적용하는 수준까지 고를 수 있습니다.

챗봇과 에이전트: 표로 보는 차이

이렇게 30분씩 오가던 주고받기가 몇 분으로 줄어드는 경우가 많고, “잘못 옮겨 적음”이라는 오류 원인은 완전히 사라집니다.

AI 에이전트가 서버에서 하는 일: 저희 운영 사례

다음 사례는 저희 일상 업무에서 나온 것입니다. 이름, 주소, 접속 정보는 생략했지만 작업 과정은 실제 그대로입니다.

백업과 롤백 경로를 갖춘 배포

고객 포털이나 서버 스크립트를 수정할 때 적용 작업은 에이전트가 맡습니다. 먼저 서버에 있는 파일을 마지막으로 알려진 상태와 비교해, 다른 사람이 한 변경을 덮어쓰지 않도록 합니다. 그다음 웹 디렉터리 밖에 날짜가 붙은 백업을 만들고, 롤백 스크립트를 작성하고, 새 파일의 문법을 검사하고, 이전과 같은 소유자와 권한으로 적용한 뒤 해당 기능을 테스트합니다. 모든 점검을 통과해야 비로소 완료를 보고합니다. 자세한 절차는 아래 배포 섹션에서 설명합니다.

문제 해결: 몇 분 만에 증상에서 원인까지

“사무실에서는 웹사이트에 접속되지 않는데 밖에서는 됩니다.” 예전 같으면 한참을 찾아 헤매야 했을 문제입니다. 에이전트는 방화벽 규칙을 확인하고, 보안 소프트웨어의 로그에서 사무실 IP 주소를 검색하고, 실제로 적용된 규칙을 찾아낸 뒤 어떤 요청 때문에 그 규칙이 작동했는지 설명합니다. 무엇을 할지는 여전히 저희가 결정하지만, 탐정 같은 조사 작업은 에이전트에게 넘어갔습니다. 502 Bad Gateway나 디스크가 가득 차는 것 같은 전형적인 웹 서버 오류에서도 똑같이 작업합니다. journalctl과 애플리케이션 로그를 읽고, 가설을 세우고, 무언가를 바꾸기 전에 그 가설을 근거로 입증합니다.

에이전트가 직접 만드는 모니터링

저희 모니터링의 상당 부분은 에이전트와 함께 만들었습니다. 몇 분마다 cron 작업으로 서비스를 처음부터 끝까지 테스트하고, 오류가 나면 텔레그램 봇 등을 통해 휴대폰으로 알림을 보내는 작은 점검 스크립트들입니다. 에이전트는 스크립트를 작성하고, 일부러 오류를 일으켜 테스트하고, cron 작업을 등록하고, 알림을 끄는 방법을 문서로 남깁니다. 이런 구성을 기본적으로 어떻게 만드는지는 서버 모니터링 설정하기 글에서 설명합니다.

현황 파악과 정리 작업

계약이 해지되었는데도 여전히 돌아가는 서버는 어느 것일까요? 비용은 나가는데 더 이상 쓰지 않는 부가 서비스는 무엇일까요? 에이전트는 데이터베이스와 API를 읽기 전용으로 조회하고 결과를 표로 정리해 이런 질문에 답합니다. 정리 작업은 승인을 받은 뒤에만 할 수 있으며, 그 전에 최근 며칠간의 트래픽 등을 보고 해당 머신이 정말 쓰이지 않는지 확인합니다.

작업과 함께 저절로 자라는 문서

모든 변경은 변경 이력에 항목을 남기고, 필요하면 운영 매뉴얼을 보완하는 것으로 마무리됩니다. 에이전트에게는 몇 초면 되는 일이지만 나중에 저희는 몇 시간을 아낍니다. “이건 도대체 왜 이렇게 되어 있지?”라는 질문에 글로 된 답이 있기 때문입니다.

AI가 서버에서 직접 작업할 때의 장점

• 속도: 사람이 몇 분 걸려 읽을 내용을 에이전트는 몇 초 만에 읽고, 가설을 먼저 설명하는 대신 곧바로 시험해 봅니다.
• 철저함: 누군가 중요하다고 여긴 일부분만이 아니라, include된 파일까지 포함한 설정 전체와 오류 전후의 로그 줄을 읽습니다.
• 한결같은 절차: 백업, 문법 검사, 결과 확인이 매번 실행됩니다. 금요일 저녁에도, 스무 번째 사소한 변경에서도 마찬가지입니다.
• 추가 수고 없는 문서화: 모든 변경이 이유, 백업 위치, 롤백 방법과 함께 기록됩니다.
• 스크립트 공부 없는 자동화: 점검 스크립트, cron 작업, 보고서가 일상 언어로 쓴 설명에서 만들어지고, 투입 전에 테스트를 거칩니다.
• 덤으로 얻는 학습: 에이전트는 무엇을 왜 하는지 설명합니다. 옆에서 함께 읽다 보면 몇 주 뒤에는 자신의 서버를 훨씬 잘 이해하게 됩니다.

세 가지 구조와 저희가 쓰는 방식

에이전트를 서버에 연결하는 검증된 방법은 세 가지입니다. 도구가 어디에서 실행되는지, 접속 정보가 어디에 보관되는지가 서로 다릅니다.

저희의 선택: 에이전트는 작업용 PC에서, 서버는 SSH로

저희는 첫 번째 방식을 씁니다. 에이전트는 작업용 컴퓨터에서 실행되고, 서버마다 SSH 설정에 항목이 하나씩 있으며, 에이전트는 전용 키로 접속합니다. 가장 중요한 이유는 저희가 관리하는 시스템이 많다는 점입니다. 바로 이 방식이어야 에이전트 하나가 한 세션 안에서 웹 서버에서 데이터베이스를 거쳐 방화벽까지, 여러 서버에 걸친 원인을 추적할 수 있습니다. 또한 AI 제공업체 로그인 정보와 키가 저희가 어차피 보호하고 있는 한곳에 모여 있습니다. 서버가 한 대뿐이고 밤마다 자동 보고서를 받고 싶다면 두 번째 방식이 잘 맞습니다. 장단점은 AI 관리형 서버 글에서 더 자세히 다룹니다.

가이드: SSH로 AI 에이전트를 서버에 연결하기

아래 일곱 단계는 Claude Code, Codex CLI, Gemini CLI에서 똑같이 작동합니다. 예시에서는 문서화용으로 예약된 주소 203.0.113.10과 사용자 이름 deploy를 사용하니, 둘 다 실제 값으로 바꾸세요. SSH 보안 강화와 키 로그인 설정 글에서 설명한 것처럼 SSH 키로 로그인할 수 있는 서버가 필요합니다.

1단계: 에이전트 전용 SSH 키 만들기

에이전트에게는 개인 키를 절대 주지 않고, 에이전트 전용 키를 줍니다. 그래야 내 접근 권한은 그대로 둔 채 언제든 에이전트의 접근만 회수할 수 있고, 로그에서도 어떤 로그인이 에이전트에게서 왔는지 알아볼 수 있습니다.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 키는 짧고 빠르며 안전한 것으로 인정받습니다. 주석 ki-agent는 나중에 서버의 authorized_keys에 그대로 표시되므로 이 키를 한눈에 알아볼 수 있습니다.

2단계: 서버에 공개 키 등록하기

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

접근을 더 좁히고 싶다면 서버의 ~/.ssh/authorized_keys 파일에서 키 앞에 옵션을 추가합니다. from=은 특정 주소에서만 로그인을 허용하고, no-agent-forwarding과 no-port-forwarding은 이 연결이 다른 곳으로 넘어가는 발판으로 쓰이지 않게 막습니다.

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

그 후 서버가 Permission denied (publickey)를 반환하면 SSH Permission denied (publickey) 해결하기 글이 도움이 됩니다.

3단계: SSH 설정에 호스트 별칭 만들기

별칭을 쓰면 에이전트는 짧은 이름 하나만 알면 되고, 언제나 올바른 키를 사용합니다.

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

이후에는 ssh web-prod "systemctl status nginx"만 입력하면 됩니다. IdentitiesOnly yes는 SSH가 키 모음에 있는 다른 키를 하나씩 시도하는 것을 막습니다. 서버를 추가할 때마다 별도의 블록을 만들고, 테스트 시스템과 운영 시스템에는 web-test와 web-prod처럼 서로 다른 이름을 붙이는 것이 좋습니다. 그러면 혼동이 이름에서부터 드러납니다.

4단계: 에이전트 설치와 로그인

Claude Code, Codex CLI, Gemini CLI는 Linux, macOS, Windows에서 실행되며, 제공업체 계정이나 API 키로 로그인합니다. 설치 방법과 브라우저 없이 로그인하는 방법은 단계별 가이드에 나와 있습니다. 작업용 PC 방식에서는 도구를 서버가 아니라 내 컴퓨터에 설치합니다.

5단계: 에이전트가 따를 규칙 정하기

세 도구 모두 시작할 때 작업 디렉터리에 있는 규칙 파일을 읽습니다. Claude Code는 CLAUDE.md, Codex CLI는 AGENTS.md, Gemini CLI는 GEMINI.md를 읽습니다. 여기에는 내 서버에서 어떻게 작업해야 하는지를 적습니다. 검증된 출발점은 다음과 같습니다.

# 서버 작업 규칙

- 변경하기 전에는 매번 웹 디렉터리 밖에 날짜가 붙은 백업을 만드세요.
- 적용하기 전에 문법을 검사하세요(nginx -t, php -l, apachectl configtest).
- 적용한 뒤에는 서비스, 로그, 기능을 확인하고 결과를 보고하세요.
- 비밀번호, API 키, 토큰은 절대 출력하지 말고 파일에 복사하지도 마세요.
- 삭제, 데이터베이스 변경, 되돌릴 수 없는 모든 작업은 명시적인 승인을 받은 뒤에만 하세요.
- 컨트롤 패널이 관리하는 파일은 직접 수정하지 마세요.
- 테스트가 끝나면 테스트 파일을 다시 삭제하세요.

규칙은 계속 자랍니다. 에이전트가 원하는 것과 다르게 작업할 때마다 그 교정 내용을 규칙으로 만들어 이 파일에 넣으세요. 몇 주가 지나면 에이전트는 여러분이 직접 작업할 때와 같은 방식으로 일합니다.

6단계: 승인과 허용 목록 설정하기

기본적으로 도구는 무언가를 바꾸는 명령마다 실행 전에 묻습니다. 처음에는 이렇게 하는 것이 맞습니다. 매번 승인하게 되는 읽기 전용 명령은 미리 허용해 둘 수 있습니다. Claude Code에서는 .claude/settings.json 파일에서 설정합니다.

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

이 목록에 없는 명령은 모두 계속 승인이 필요합니다. 모든 확인 질문을 꺼 버리는 옵션은 기껏해야 일회용 테스트 머신에서나 쓸 것입니다.

7단계: 첫 작업은 읽기만

아무것도 바꿀 수 없는 작업부터 시작하고, 에이전트가 어떻게 진행하는지 지켜보세요.

web-prod에서 지난 24시간 동안의 nginx 오류를 확인하고, 가장 흔한 원인 세 가지를
각각 로그 근거 하나씩과 함께 알려줘. 아무것도 변경하지 마.

분석이 정확하다는 것이 확인된 뒤에야 새 로그 로테이션이나 systemd 서비스 같은 작은 변경으로 넘어가고, 운영 시스템 배포는 그다음입니다.

에이전트의 배포 방식: 운영 시스템을 변경할 때마다 따르는 저희 절차

AI 에이전트는 백업, 미리 준비한 롤백 경로, 적용 전후의 검증을 포함한 정해진 절차에 따라서만 운영 시스템에 배포해야 합니다. 저희의 절차는 다음과 같습니다.

1. 현재 상태 확인. 서버의 파일을 마지막으로 알려진 상태와 비교합니다. 그사이 다른 사람이 파일을 바꿨다면 에이전트는 그 변경을 덮어쓰지 않고 작업을 중단한 뒤 확인을 요청합니다.
2. 백업 생성. 해당 파일은 날짜와 함께 웹 디렉터리 밖의 백업 폴더에 저장됩니다. 웹 디렉터리 안에 둔 백업은 경우에 따라 외부에서 누구나 열어 볼 수 있습니다.
3. 롤백 준비. 명령 하나로 이전 상태를 되돌리는 작은 스크립트를 비상시가 아니라 변경 전에 만들어 둡니다.
4. 문법 검사. 새 파일은 적용 전에 검사합니다. PHP는 php -l로, nginx는 nginx -t로 확인합니다. 이렇게 하면 문법 오류가 운영 시스템에 아예 도달하지 않습니다.
5. 올바른 권한으로 적용. 소유자, 그룹, 파일 권한은 이전 상태를 그대로 따릅니다. 잘못된 권한은 문법 오류 다음으로 업데이트 후 장애를 일으키는 가장 흔한 원인입니다.
6. 부작용 없는 테스트. 테스트는 읽기 전용으로, 가상의 테스트 데이터로, 또는 격리된 환경에서 진행하며, 실제 주문이나 실제 고객 데이터로는 절대 하지 않습니다.
7. 실서비스 확인. 적용 후 HTTP 상태, 오류 로그, 변경된 기능을 점검합니다.
8. 문서화. 백업 위치와 롤백 명령을 포함해 변경 이력과 운영 매뉴얼을 보완합니다.

실제 경로 대신 플레이스홀더를 넣어 명령 순서로 나타내면 대략 다음과 같습니다.

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

롤백 경로를 변경 전에 만드는 이유

장애가 난 상황에서 깔끔한 롤백 방법을 궁리할 만큼 여유로운 사람은 없습니다. 스크립트가 이미 준비되어 있으면 되돌리기는 몇 초면 끝나고, 적용 후 검증이 실패하면 에이전트가 직접 실행할 수도 있습니다. 바로 이것이 “잠깐” 무언가를 바꿔 버리는 에이전트와 운영 시스템을 믿고 맡길 수 있는 에이전트의 가장 큰 차이입니다.

아무것도 망가뜨릴 수 없는 테스트

많은 기능은 무언가가 실제로 일어나지 않고서는 테스트할 수 없습니다. 주문, 결제, 이메일 같은 것들입니다. 여기에는 세 가지 기법이 도움이 됩니다. 첫째, 도구 자체가 제공하는 드라이 런입니다. 둘째, 어디에도 존재하지 않는 것이 확실한 가상의 식별자입니다. 셋째, 격리된 환경입니다. 네트워크 없이 별도의 네트워크 네임스페이스에서 실행되는 프로세스(unshare -n)는 외부 API에 접속할 수도, 실수로 무언가를 구매할 수도 없지만, Unix 소켓을 통해 로컬 데이터베이스는 계속 볼 수 있습니다. 테스트가 끝나면 모든 테스트 파일을 다시 삭제합니다.

비용이 드는 작업에는 잠금이 필요합니다

어떤 작업 흐름이 무언가를 주문하거나, 청구하거나, 삭제한다면 동시에 두 번 실행되어서는 안 됩니다. 누군가 두 번 클릭하거나 에이전트가 명령을 반복하는 경우에도 마찬가지입니다. Linux에서 가장 간단한 해결책은 flock입니다.

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "이미 실행 중"

데이터베이스 애플리케이션에서는 이름 있는 잠금(MySQL과 MariaDB의 GET_LOCK)이, API에서는 Idempotency-Key가 같은 역할을 합니다. 자세한 내용은 아래 KernelHost API 부분에서 다룹니다.

보안: 아무것도 새어 나가지 않는 에이전트 접근 권한

가장 자주 듣는 걱정은 “그럼 제 데이터는요?”입니다. 솔직하게 답하자면, 에이전트는 읽는 모든 내용을 처리를 위해 제공업체의 언어 모델로 보냅니다. 그래서 아래 규칙을 통해 에이전트가 애초에 무엇을 보게 될지 여러분이 정합니다.

비밀 정보는 채팅에 넣지 않습니다

비밀번호, API 키, 토큰은 절대 작업 지시에 적지 않고, 에이전트가 출력하지도 않습니다. 스크립트는 이런 값을 권한이 600인 파일에서 읽으며, 에이전트는 스크립트를 쓰기 위해 이 파일을 열어 볼 필요가 없습니다. 그래도 키가 채팅에 들어가게 되면 즉시 제공업체에서 해당 키를 차단하고 새로 발급합니다. 키의 일부 조각도 채팅에 넣으면 안 됩니다. 키의 앞 몇 글자는 문제 해결에 아무 도움이 되지 않지만 공격자의 수고는 덜어 줍니다.

전용 키, 전용 권한, 언제든 회수 가능

에이전트마다 전용 SSH 키를 주며, 각 키는 authorized_keys에서 주석으로 구분할 수 있습니다. 접근을 회수하려면 해당 줄 하나만 지우면 됩니다. 그것으로 충분한 곳에서는 에이전트가 전용 사용자와, 필요한 명령만 허용하는 sudo 규칙으로 작업합니다. API에는 최소한의 권한만 가진 전용 키를 발급하고, 단순 분석용이라면 읽기 전용으로 제한합니다.

승인: 사람 없이는 절대 일어나지 않는 일

저희 환경에서 에이전트는 명시적인 동의 없이 삭제하거나, 데이터베이스에 쓰거나, 방화벽이나 보호 규칙을 완화하거나, 머신을 중지하거나, 무언가를 주문할 수 없습니다. 도구도 이를 뒷받침합니다. Claude Code는 시스템에 개입하는 작업 앞에서 멈추고 기다리며, 추가로 보안 필터가 위험한 명령을 감지해 승인이 날 때까지 차단하도록 설정할 수도 있습니다. 저희 일상에서 있었던 일을 예로 들면, 이 필터는 기술적으로는 옳았지만 되돌릴 수 없는 작업을 한 번 이상 멈춰 세웠습니다. 그 작업은 사람이 명시적으로 승인한 뒤에야 실행되었습니다. 바로 그래야 합니다.

추적 가능성: 로그, 변경 목록, 백업

모든 세션은 사람이 읽을 수 있는 흔적을 남깁니다. 날짜가 붙은 백업, 롤백 스크립트, 변경 이력의 항목, 시스템 로그의 로그인 기록입니다. 여기에 더해 /etc를 etckeeper로 Git에서 관리하면 모든 설정 변경을 diff로 볼 수 있습니다. 추적할 수 없는 것은 되돌릴 수도 없습니다. 기본은 여전히 제대로 작동하는 백업 전략입니다. 에이전트가 백업을 대신할 수는 없기 때문입니다.

AI 에이전트에는 어떤 서버가 적합할까요?

AI 기반 관리를 위한 서버에는 완전한 루트 권한, SSH 키 로그인, 제한 없는 아웃바운드 연결, 상시 DDoS 방어가 필요하며, 이상적으로는 서버를 자동으로 주문하고 제어할 수 있는 API도 갖춰야 합니다. 언어 모델은 제공업체에서 실행되므로 GPU는 필요 없습니다.

AI 관리형 서버로 KernelHost를 고르는 이유

원칙적으로 AI 에이전트는 셸을 쓸 수 있는 서버라면 어디서든 작업할 수 있습니다. 하지만 실제로 얼마나 많은 일을 맡길 수 있는지는 주변 환경이 좌우합니다. KernelHost의 KVM 루트 서버나 전용 서버에는 제한된 계정도, AI 제공업체로 가는 HTTPS 연결을 가로막는 장애물도, 시험 사용을 비싸게 만드는 약정도 없습니다. DDoS 상시 방어는 모든 서버에서 추가 요금 없이 활성화되어 있으며, 연산 부하가 큰 작업에는 전용 코어를 갖춘 Professional 루트 서버가 있습니다. 요금은 PrePaid 방식으로 정산합니다. 계약도, 최소 이용 기간도, 설치비도 없습니다. 먼저 시험해 보고 싶다면 무료 테스트 서버로 시작하세요.

KernelHost API: 에이전트가 서버를 직접 주문하고 제어합니다

가장 큰 효과는 개별 서버보다 한 단계 위에서 나옵니다. 에이전트는 KernelHost API로 제품과 가격을 조회하고, 서버를 주문하고, 보유한 서비스의 상태를 읽고, 서버를 시작, 중지, 재시작하고, 해지를 신청하거나 철회할 수 있습니다. 그러면 “테스트 서버 하나 준비해 줘”가 하나의 작업으로 끝납니다. 에이전트가 머신을 주문하고, 개통을 기다리고, SSH로 접속해 애플리케이션을 설치한 뒤 주소를 알려 줍니다.

이 API는 에이전트가 사용하는 상황을 염두에 두고 의도적으로 신중하게 설계되었습니다. API 키에는 필요한 권한만 부여되며, 분석용 키로는 아무것도 주문할 수 없습니다. Idempotency-Key는 에이전트가 타임아웃 오류 뒤에 다시 보낸 주문이 두 번 처리되지 않도록 합니다. 요청은 키별, 계정별, IP 주소별로 제한되므로 무한 루프에 빠진 에이전트라도 요청 폭주를 일으키지 못합니다. 그리고 접속 정보를 조회할 때마다 이메일 알림이 발송되므로, 에이전트가 언제 접속 정보를 읽었는지 알 수 있습니다.

AI 관리형 서버의 비용은 얼마인가요?

비용 항목은 두 가지입니다. 첫째는 서버 자체입니다. SSH로 작업하는 에이전트를 위해서라면 특별한 사양이 필요 없고, 애플리케이션이 이미 돌아가고 있는 루트 서버라면 어느 것이든 충분합니다. 에이전트를 서버에서 직접 실행하는 경우에도 도구 자체는 수백 메가바이트의 메모리만 필요하므로, 다른 작업이 별로 없다면 2 vCPU와 4 GB RAM을 갖춘 루트 서버로 충분합니다. 둘째는 언어 모델입니다. 명령줄 도구 사용이 포함된 제공업체 구독을 이용하거나, 사용량에 따라 과금되는 API 키를 씁니다. 매일 집중적으로 사용한다면 대개 구독이 더 저렴하고, 사람이 지켜보지 않는 자동화 작업에는 월 예산으로 상한을 걸 수 있는 API 키가 깔끔한 방법입니다. 현재 서버 가격은 루트 서버 임대 페이지에서 확인하실 수 있습니다.

흔한 실수와 피하는 방법

• 에이전트가 관리자의 개인 키로 작업합니다. 그러면 에이전트의 접근만 따로 회수할 수 없고, 로그에서도 구분되지 않습니다. 해결책: 고유한 주석을 단 전용 키.
• 모든 확인 질문이 꺼져 있습니다. 첫날에는 클릭을 아껴 주지만 언젠가는 서버 한 대를 날리게 됩니다. 해결책: 읽기 전용 명령은 허용 목록으로, 시스템에 개입하는 작업은 모두 승인으로 처리합니다.
• 변경 전 백업 누락. 해결책: 백업과 롤백 스크립트를 CLAUDE.md나 AGENTS.md에 고정 규칙으로 적어 둡니다.
• 웹 디렉터리 안의 백업. 웹 루트에 있는 config.php.bak 같은 파일은 데이터베이스 비밀번호까지 담긴 채 외부에서 열람될 수 있습니다. 해결책: 웹 디렉터리 밖에 권한이 700인 백업 폴더를 둡니다.
• 프롬프트 속 비밀 정보. 해결책: 접속 정보는 스크립트가 읽는, 권한이 600인 파일에만 두고, 실수로 노출되면 즉시 새로 발급합니다.
• 중복 실행. 두 번 클릭하거나 요청을 반복하면 두 번 주문됩니다. 해결책: flock이나 Idempotency-Key로 잠급니다.
• 컨트롤 패널이 관리하는 파일을 직접 수정. 패널이 다음 업데이트 때 이 파일을 덮어쓰거나, 이 파일 때문에 업데이트가 실패합니다. 해결책: 이런 파일은 규칙에서 제외하고, 변경은 패널이나 패널의 API를 통해 합니다.
• 출력을 검증 없이 수용. 출력을 이해하지 못하는 에이전트는 추측합니다. 해결책: 근거를 요구하고(“그 로그 줄을 보여줘”), 결과를 실서비스에서 확인하게 합니다.

핵심 요약

• AI를 서버에 연결한다는 것은 Claude Code, Codex CLI, Gemini CLI 같은 에이전트에게 전용 SSH 키와 명확한 규칙을 주는 것입니다.
• 에이전트는 로그를 읽고, 변경을 적용하고, 결과를 확인하고, 이를 문서로 남깁니다. 시스템에 개입하는 단계는 승인이 있어야만 실행됩니다.
• 모든 배포는 현재 상태 확인, 백업, 롤백 준비, 문법 검사, 적용, 테스트, 실서비스 확인, 문서화라는 정해진 절차를 따릅니다.
• 비밀 정보는 절대 채팅에 넣지 않으며, 비용이 드는 작업에는 중복 실행을 막는 잠금이 필요합니다.
• 서버에는 루트 권한, SSH 키, 자유로운 아웃바운드 연결, DDoS 방어가 필요하지만 GPU는 필요 없습니다.
• KernelHost 서버는 약정 없는 PrePaid 방식으로 이 모든 요구 사항을 기본으로 충족하며, KernelHost API를 이용하면 에이전트가 서버를 직접 주문하고 제어할 수도 있습니다.