[기획: AI 트렌드] Claude 에이전트 서버를 직접 돌리면 — 기록은 안에 남고, 대화는 나간다

11월 12일 Anthropic이 AI가 스스로 일하게 하는 자사 제품을, 고객이 자기 서버에서 직접 돌리는 판으로 내놓았습니다. Anthropic은 AI가 일한 기록을 직접 보관해야 하거나, AI 모델을 부를 곳을 직접 정해야 하는 기업에 이 판을 권합니다. 우리는 이 판이 기업 안에 들이는 것은 기록과 책임이고, 대화는 여전히 밖으로 나간다고 봅니다.

방화벽 로그 옆의 목록

새로 나온 것은 Claude Managed Agents의 셀프호스팅판입니다. Managed Agents는 Claude가 도구를 쓰며 스스로 일하게 해 주는 Anthropic의 서비스입니다. 셀프호스팅판은 그 서비스를 고객이 직접 운영하는 판이고, Anthropic 계정 팀에 신청해야 쓸 수 있습니다.

한 기업의 보안 검토자가 이 판의 도입 심사를 맡았다고 합시다. 검토자는 방화벽 로그부터 펼칩니다. 방화벽은 회사 네트워크를 드나드는 연결을 거르고, 그 기록을 로그로 남기는 장치입니다. 옆에는 Anthropic이 보안 검토의 질문에 답하려고 쓴 문서 한 쪽을 둡니다.

문서에는 서버가 연결하는 곳의 목록이 있고, 맨 위는 추론 제공자입니다. AI 모델에 묻는 요청, 즉 모델 호출에 실제로 답하는 곳입니다. 검토자는 로그를 이 목록과 한 줄씩 맞춰 봅니다. Anthropic이 문서에서 직접 권하는 점검법입니다.

모델만 밖에 남는다

Anthropic은 누가 무엇을 돌리는지를 샌드박스·서비스·모델 세 겹으로 나눠 보여 줍니다. 샌드박스는 에이전트의 도구가 명령을 실행하는 격리된 작업 공간이고, 지금까지는 이것만 고객 쪽으로 옮길 수 있었습니다.

이번 판은 서비스까지 옮깁니다. 서비스는 에이전트 루프를 돌리고, 일 한 건 한 건(세션)의 기록을 저장합니다. 에이전트 루프란 모델에게 묻고, 모델이 요청한 도구를 실행해 결과를 다시 건네는 되풀이입니다.

모델을 맡을 추론 제공자는 다섯 갈래에서 고릅니다. 기본값인 Anthropic의 Claude API, Amazon Bedrock·Google Cloud·Microsoft Foundry 세 클라우드, 그리고 모델 게이트웨이입니다. 모델 게이트웨이는 기업이 모델 호출을 한곳에 모아 중계하는 관문 서버입니다. 어느 쪽을 고르든 에이전트는 Claude 모델 이름으로 모델을 부르고, 서버가 그 이름을 제공자에 맞게 바꿉니다.

다른 제공자를 고르면 서버는 Anthropic에 직접 연결하지 않습니다. 다만 게이트웨이를 고르면 첫 행선지가 사내 관문일 뿐, 그 너머로 호출이 어디까지 가는지는 문서가 정하지 않습니다.

나가는 대화, 남는 기록

그런데 모델은 밖에 있으니, 서버는 모델 호출 때마다 지금까지의 대화를 추론 제공자에게 보냅니다. 기본값인 Claude API를 쓰면 이 대화는 Anthropic으로 갑니다.

이때 호출에는 헤더, 즉 요청 앞머리에 붙는 부가 정보가 최대 3개 따라갑니다. 세션·에이전트·실행 환경을 가리키는 ID로, 내용은 없지만 끄는 설정도 없습니다. 게이트웨이나 프록시가 호출을 다른 곳으로 다시 넘기면 사용량 표시 라벨이 함께 갈 수 있다고 문서는 적었습니다.

정리하면 같은 내용이 두 갈래로 움직입니다. 호출마다 제공자에게 가는 전송과, 고객 데이터베이스에 쌓이는 저장입니다. 진료 기록 원본은 자기 병원 서랍에 두면서, 바깥 전문의에게 물을 때마다 그때까지의 기록을 함께 보내는 셈입니다.

셀프호스팅은 이 가운데 저장을 바꿉니다. Anthropic은 이 서버와 서버 로그에 원격으로 접근할 수 없습니다. 서버에 접속할 때 쓰는 키나 토큰도 Anthropic이 발급하거나 갖고 있지 않습니다. 데이터베이스를 붙여 두면 세션 기록은 고객이 지울 때까지 거기 남습니다.

이 저장 주체의 변화가 가장 또렷이 보이는 곳이 ZDR(제로 데이터 보존)입니다. 요청과 응답을 처리한 뒤 저장하지 않기로 한 계약입니다. Anthropic은 Managed Agents를 ZDR 적용 대상 밖으로 둡니다. Anthropic이 대신 운영하는 호스팅판은 세션 기록을 고객이 지울 때까지 보관하기 때문입니다. 셀프호스팅판에서는 그 기록을 고객이 직접 보관합니다.

그렇다면 ZDR 계약이 있는 기업에게 셀프호스팅은 필요 없을까요. 우리는 반대로 봅니다. ZDR 계약은 모델 호출에 적용되고, 셀프호스팅 서버가 Claude API로 보내는 호출에도 똑같이 적용됩니다. 호스팅판이 ZDR 밖에 있던 이유는 세션 기록의 보관이었고, 셀프호스팅은 바로 그 보관을 고객에게 옮깁니다. ZDR을 맺은 기업이 걸리던 부분을 이 판이 메우는 셈입니다.

넘어오는 책임과 빠지는 기능

기록을 들이면 지키는 일도 같이 들어옵니다. 고객은 서버와 데이터베이스, 샌드박스를 직접 돌리고 지키며, 새 버전도 직접 설치해야 합니다.

가장 조심할 곳은 셸, 즉 컴퓨터에 명령을 직접 내리는 창입니다. 에이전트의 셸 명령은 워커라는 프로그램이 서버에서 일감을 받아 샌드박스에서 실행합니다. 이 셸은 워커의 권한과 네트워크 접근을 그대로 쓰고, 워커는 셸을 따로 가두지 않습니다.

그래서 격리는 워커를 담는 그릇이 맡습니다. 컨테이너나 가상 머신(VM)처럼 한 컴퓨터 안에 따로 떼어 낸 실행 공간입니다.

신뢰의 경계도 고객이 긋습니다. 서버와 데이터베이스, 워커를 묶은 배포 하나는 한 고객, 한 신뢰 수준만 맡습니다. 에이전트가 돌린 코드는 샌드박스 안에 놓인 자격 증명으로 서버를 부를 수 있습니다. 그래서 문서는 세션마다 샌드박스를 따로 두고, 한 환경의 모든 세션에 닿는 환경 키는 샌드박스 밖에 두라고 권합니다.

빠지는 것도 있습니다. 호스팅판에서 넘어올 때 세션 기록을 포함해 아무것도 복사되지 않고, 예약 실행과 dreams 같은 기능도 쓸 수 없습니다. dreams는 지난 세션 기록과 에이전트의 메모리를 함께 읽어 낡거나 모순된 항목을 고치는 기능입니다. 문서는 셀프호스팅 서버에 dreams의 대체 기능이 없다고 적었습니다.

지난 글 같은 메모리를 붙여도 이득은 아홉 배 갈렸다 — Anthropic 메모리 실험에서 점수를 올린 지시는 「먼저 읽고 시험하라」였다에서 본 Anthropic의 한 번의 실험에서는, 세션 뒤 노트를 원래 기록에 대어 고친 쪽이 다른 두 시도보다 멀리 갔습니다. 기록은 기업 안으로 들어오지만, 그 기록을 다시 읽어 메모리를 고치는 일은 이제 고객이 따로 챙겨야 합니다.

저장인가, 전송인가

우리는 셀프호스팅으로 얻는 것을 두 가지로 봅니다. 세션 기록을 직접 갖는 일, 그리고 모델 호출을 보낼 곳을 고르는 권리입니다. 대신 서버를 지키고 격리를 설계하는 책임이 함께 넘어옵니다. 그래서 이 판을 검토하는 기업이 먼저 물을 것은 「데이터가 나가느냐」가 아니라 「우리 문제가 저장인가, 전송인가」입니다.

문제가 저장이라면, 즉 남의 서버에 세션 기록이 쌓이는 것이 걸림돌이면 이 판이 답입니다.

문제가 전송이라면 답은 셀프호스팅보다 제공자 선택과 계약에 있습니다. 모델로 보내고 받는 내용은 그 제공자와 맺은 계약의 보존 조항을 따르기 때문입니다.

앞의 검토자가 맞춘 목록은 서버의 연결만 다룹니다. 워커는 고객이 샌드박스에 열어 준 만큼 네트워크에 닿으니, 그 길은 검토자가 따로 설계해야 합니다. 그리고 서버 목록의 맨 위 추론 제공자 줄은 어느 설정에서도 지워지지 않습니다. 셀프호스팅으로 바뀌는 것은 그 줄의 행선지와, 세션 기록이 쌓이는 데이터베이스의 주인입니다.