Claude Code를 회사 서버에서 돌린다: Self-Hosted Coding Agent Runtime 실전 설계

이경규·2026년 8월 19일

Claude Code를 회사 서버에서 돌린다: Self-Hosted Coding Agent Runtime 실전 설계

Coding Agent를 개인 개발 환경에서 사용할 때는 구조가 단순하다.

Developer
   ↓
Claude Code
   ↓
Local Repository
   ↓
Build / Test

개발자 Mac이나 PC 안에 Repository가 있고, Claude Code도 같은 환경에서 실행된다.

하지만 기업 환경으로 들어가면 이야기가 달라진다.

Private Git

Internal Package Registry

사내 Database

사내 API

내부 MCP Server

VPN 전용 서비스

사내 Build Toolchain

Signing Infrastructure

같은 자원이 인터넷에서 직접 접근되지 않는 경우가 많다.

여기에 보안팀 요구사항까지 붙는다.

Source Code 외부 반출 제한

Build Artifact 외부 저장 금지

Network Egress 제한

Secret 직접 노출 금지

작업별 Audit Log 필요

개발자별 접근 권한 분리

이때 Coding Agent를 단순한 SaaS 개발 도구로만 운영하기 어려워진다.

2026년 8월 Anthropic이 공개한 Claude Code Self-hosted environments가 흥미로운 이유가 여기에 있다.

Claude Code 세션을 Web·Mobile·Desktop 등에서 시작하면서도 실제 코드 실행 환경은 Anthropic의 Hosted VM이 아니라 기업이 관리하는 자체 Compute 안에 둘 수 있게 됐다. 현재 이 기능은 Public Beta이며 Claude Team과 Enterprise 조직을 대상으로 제공된다.

구조를 단순화하면 이렇다.

Developer
   │
   │ Claude Web / Desktop / Mobile
   ▼
Claude Control Plane
   │
   │ Session
   ▼
Company Network
┌───────────────────────────┐
│ Self-Hosted Runner        │
│                           │
│  Claude Code Session      │
│          │                │
│          ├─ Private Git   │
│          ├─ Internal MCP  │
│          ├─ Database      │
│          ├─ Registry      │
│          └─ Build Tools   │
└───────────────────────────┘

그렇다고 Claude 모델 자체를 회사 서버에 설치하는 것은 아니다.

이 부분부터 정확히 이해해야 한다.

1. Self-Hosted라고 모델까지 내부에 있는 것은 아니다

Self-hosted environments라는 이름 때문에 다음 구조를 생각하기 쉽다.

Company Network

┌─────────────────────┐
│ Claude Model        │
│ Claude Code         │
│ Repository          │
│ Build               │
└─────────────────────┘

하지만 현재 구조는 그렇지 않다.

자체 인프라로 이동하는 것은 코드와 Tool Execution 환경이다.

Anthropic은 공식 설명에서 Repository Checkout, Build Artifact, Secret, 세션이 생성하거나 수정한 파일은 사용자가 제공하는 인프라에 유지된다고 설명한다. 반면 Prompt, Response, Tool Result 등 모델이 다음 행동을 결정하기 위해 필요한 대화 데이터는 Anthropic으로 전달된다.

즉 경계는 대략 이렇게 생각하는 편이 정확하다.

Anthropic
────────────────────────

Claude Model
Session / Control Plane
Prompt
Response
Tool Result

────────────────────────
Company Infrastructure

Repository
Filesystem
Processes
Build
Test
Internal Network
Secrets
Artifacts

따라서:

Self-hosted
=
모든 데이터가 Anthropic으로 절대 나가지 않는다

라고 이해하면 안 된다.

더 정확한 표현은:

Tool Execution과
Filesystem과
Network Access Boundary를

기업이 직접 통제한다.

에 가깝다.

Claude Managed Agents의 Self-hosted sandbox 역시 동일한 경계를 명시한다. Tool Execution·Filesystem·Process·Network Egress는 자체 인프라에 머물지만 Tool Input과 Output은 Claude가 다음 행동을 판단하기 위해 Anthropic Control Plane으로 전달된다.

2. 그럼 왜 굳이 Self-Hosted가 필요한가

가장 큰 이유는 세 가지다.

Network

Environment

Compliance

Anthropic도 Self-hosted environments를 사용하는 대표 이유로 내부 Network 접근, Custom Toolchain 구성, Compliance 요구사항을 들고 있다.

첫 번째는 Internal Network다.

예를 들어 회사 안에 이런 시스템이 있다고 하자.

git.company.local

jira.company.local

registry.company.local

db.dev.internal

mcp.company.local

Public Internet에서는 접근되지 않는다.

Hosted Agent가 이를 사용하려면 별도의 Tunnel이나 Gateway를 만들어야 한다.

하지만 Runner 자체가 회사 VPC 안에 있다면:

Claude Code
   ↓
Internal DNS
   ↓
Internal Service

가 가능하다.

3. 두 번째는 개발 환경 자체다

대규모 회사에서는 개발 환경이 단순하지 않다.

예를 들어 Mobile 팀만 해도:

Android SDK

JDK

Gradle

Internal Gradle Plugin

Private Maven Repository

Fastlane

Ruby

Custom Build CLI

Security Scanner

같은 Toolchain이 있을 수 있다.

iOS라면 더 복잡해질 수 있다.

Xcode

Swift

SwiftPM

CocoaPods

Fastlane

Internal xcframework

Signing Tool

Custom Simulator Setup

Hosted Environment를 매번 회사 환경에 맞게 조정하는 대신 회사에서 검증된 Runner Image를 만들 수 있다.

Anthropic도 Self-hosted 환경에서는 Compiler, SDK, 내부 CLI 등을 미리 설치해 모든 세션이 준비된 환경에서 시작하도록 구성할 수 있다는 점을 주요 장점으로 설명한다.

4. 세 번째는 실행 환경에 대한 통제권이다

Coding Agent는 단순히 코드를 읽지 않는다.

실제로:

File Read

File Write

Shell

Git

Package Install

Build

Test

Network Request

를 수행한다.

즉 Coding Agent는 사실상:

자연어를 받아
Shell을 실행하는 개발 Worker

에 가깝다.

그래서 기업에서는 모델의 지능보다 Agent가 실행되는 Runtime의 권한이 더 중요해질 수 있다.

5. Self-Hosted Coding Agent Runtime은 Runner 하나로 끝나지 않는다

처음에는 이렇게 만들고 싶어진다.

Company VM

└── Claude Code

하지만 여러 개발자가 사용하는 Production 환경이라면 충분하지 않다.

추천 구조는 다음과 같다.

                Claude Control Plane
                         │
                         ▼
                 Session Queue
                         │
                         ▼
                Runner Orchestrator
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
      Runner A        Runner B        Runner C
          │              │              │
       Sandbox         Sandbox         Sandbox
          │              │              │
       Session 1       Session 2       Session 3

여기서 중요한 구성 요소는 크게 여섯 개다.

1. Runner

2. Sandbox

3. Workspace

4. Credential Broker

5. Network Policy

6. Audit / Observability

하나씩 보자.

6. Runner는 Agent 실행 Worker다

Anthropic의 Self-hosted environment에서는 Runner가 세션을 받아 Claude Code Process를 실행한다.

공식적으로 두 가지 운영 방식이 소개되어 있다.

Fixed Runner

On-Demand Runner

Fixed 방식은 일정 수의 Runner를 계속 실행해두고 세션을 분배한다.

On-demand 방식은 Queue에 세션이 들어오면 Orchestrator가 Runner를 시작하고 작업 종료 후 제거한다. Anthropic은 Runner가 여러 세션을 처리할 수 있지만 각 세션은 별도의 Checkout에서 실행되어 작업 공간을 격리한다고 설명한다.

7. Fixed Runner

구조가 가장 단순하다.

Runner Pool

Runner 1
Runner 2
Runner 3
Runner 4

항상 실행되어 있다.

장점:

Startup 빠름

운영 단순

예측 가능한 Capacity

단점:

Idle Cost

Scale 제한

Runner 공유에 따른 격리 설계 필요

팀 규모가 작고 사용량이 일정하면 괜찮다.

8. On-Demand Runner

좀 더 Cloud Native한 방식이다.

Session Request
      ↓
Queue
      ↓
Orchestrator
      ↓
Runner 생성
      ↓
Task 실행
      ↓
Runner 제거

예를 들어 Kubernetes라면 이런 식으로 생각할 수 있다.

Claude Session

↓

Kubernetes Job

↓

Agent Pod

↓

Workspace

↓

Task Finish

↓

Pod Delete

Anthropic의 Self-hosted 환경 공식 설명도 Session Queue를 감시해 필요할 때 Runner를 시작하고 작업 종료 후 제거하는 On-demand 운영 방식을 제공한다.

기업 규모가 커질수록 이쪽이 더 자연스럽다.

9. 중요한 것은 Runner보다 Sandbox다

Agent가 다음 명령을 실행했다고 하자.

rm -rf ...

또는 Dependency 안에 악성 Script가 들어있을 수도 있다.

npm install

↓

postinstall

↓

외부 서버 접속

Agent가 악의적이지 않아도 Repository나 Dependency가 공격 경로가 될 수 있다.

그래서:

Runner
=
Security Boundary

로 생각하면 안 된다.

실제 Security Boundary는 Sandbox여야 한다.

Anthropic의 Managed Agents Self-hosted 보안 문서도 Sandbox Image Hardening, 최소 Linux Capability, Non-root 실행, Read-only Root Filesystem, Egress 제한, 최소 권한 Mount 등을 Self-hosting 측 책임으로 명시한다.

10. Session마다 별도 Sandbox를 두는 구조가 좋다

추천:

Runner
  │
  ├── Sandbox A
  │      └── Session A
  │
  ├── Sandbox B
  │      └── Session B
  │
  └── Sandbox C
         └── Session C

피하고 싶은 구조:

Shared VM

├── Developer A Repository
├── Developer B Repository
├── Developer C Repository
└── Shared Secret

한 Agent Session의 문제가 다른 개발자의 Workspace까지 영향을 줄 수 있기 때문이다.

Managed Agents 문서에서도 더 강한 Isolation이 필요하면 Session마다 새로운 Sandbox를 생성해 Fresh Filesystem, Resource Limit, Per-session Network Control을 적용하는 구조를 안내한다.

11. Ephemeral Workspace로 만든다

Agent Workspace는 가능하면 Disposable하게 만든다.

Session Start

↓

Fresh Workspace

↓

Git Clone

↓

Task

↓

Build / Test

↓

Patch / Commit / Artifact

↓

Session Finish

↓

Workspace Destroy

다음 세션이 이전 세션의 파일을 그대로 물려받지 않는다.

이렇게 하면:

Hidden State

Dirty Build

남은 Secret

Temporary File

Agent가 만든 임시 Script

가 다음 작업으로 넘어갈 가능성을 줄일 수 있다.

12. Repository Checkout도 Session 단위로 분리한다

예:

/workspaces/

├── session-a/
│   └── myapp/
│
├── session-b/
│   └── myapp/
│
└── session-c/
    └── backend/

Anthropic의 Claude Code Self-hosted 환경 역시 여러 세션이 하나의 Runner를 사용할 수 있어도 각 세션은 별도 Checkout에서 실행된다고 설명한다.

13. Production Secret을 Agent에게 직접 주지 않는다

가장 위험한 패턴 중 하나다.

Agent Sandbox

AWS_SECRET_KEY

DB_ADMIN_PASSWORD

APP_STORE_KEY

PROD_TOKEN

를 Environment Variable로 그대로 넣는다.

Coding Agent에게 Production Credential을 기본 제공할 이유는 거의 없다.

대신:

Agent

↓

Credential Broker

↓

Task Scoped Credential

↓

Internal Service

구조가 좋다.

14. Credential Broker를 둔다

예를 들어 Agent가 Private Package Registry에 접근해야 한다.

직접:

NPM_TOKEN=<long-lived-token>

을 넣는 대신:

Agent Session

↓

Identity

↓

Credential Broker

↓

10분짜리 Token

↓

Package Registry

형태로 만든다.

원칙:

Short-lived

Task-scoped

Read-only 우선

Revocable

Auditable

이다.

15. Environment Service Key도 Secret이다

Managed Agents Self-hosted worker를 운영할 경우 Anthropic은 ANTHROPIC_ENVIRONMENT_KEY를 Worker가 Work Queue를 Poll하고 결과를 제출하는 데 사용하는 Service Key로 설명한다.

Anthropic은 이 Key를 Sandbox Image나 일반 Environment File에 넣지 말고 Secret Manager에 저장하며, 유출이 의심되면 즉시 Rotation할 것을 권고한다.

즉:

Dockerfile

ENV ANTHROPIC_ENVIRONMENT_KEY=...

같은 방식은 피해야 한다.

16. Network Egress를 반드시 제한한다

Agent에게 인터넷 전체를 열어두면 편하다.

0.0.0.0/0

하지만 보안 관점에서는 가장 큰 위험 중 하나다.

Repository 안에 Prompt Injection이나 악성 Script가 있고:

Secret 읽기

↓

curl external-server.com

가 실행되면 문제가 된다.

그래서:

Agent Sandbox

        ├─ Git Server           ALLOW
        ├─ Package Registry     ALLOW
        ├─ Internal MCP         ALLOW
        ├─ Artifact Storage     ALLOW
        └─ Random Internet      DENY

처럼 가져가는 편이 안전하다.

Anthropic도 Self-hosted 환경에서는 Network Egress가 기업 VPC와 Firewall 정책에 의해 결정되며, 제한하지 않으면 Tool Execution이 임의 외부 Host에 접근할 수 있으므로 필요한 Endpoint만 허용하라고 명시한다.

17. Agent별로 Network Profile을 나눌 수도 있다

모든 Agent가 같은 권한을 가질 필요가 없다.

예:

Code Review Agent

Git Read
Package Registry
No External Network
Dependency Upgrade Agent

Git
Package Registry
Vendor Release Site
Release Agent

Git
CI
Artifact Registry
App Store API

이렇게 Agent Role에 따라 Egress Profile을 분리하는 편이 좋다.

18. 내부 MCP가 있으면 구조가 더 재미있어진다

회사에 다음 MCP Server가 있다고 해보자.

Jira MCP

Git MCP

Internal Docs MCP

Database MCP

CI MCP

Agent가 이를 사용하면 상당히 강력해진다.

"결제 오류 수정해."

↓

Jira Issue 확인

↓

관련 Repository 찾기

↓

Internal Documentation 확인

↓

코드 수정

↓

CI 실행

↓

결과 보고

까지 하나의 Session에서 연결할 수 있다.

19. Self-Hosted와 MCP Tunnel은 서로 다른 문제다

이 부분도 구분할 필요가 있다.

Self-Hosted

=
Agent 실행 위치
MCP Tunnel

=
Private MCP에 접근하는 연결 방식

Managed Agents 공식 문서에서도 Self-hosting과 MCP Tunnel은 독립적인 기능이라고 설명한다. Cloud Sandbox에서도 MCP Tunnel을 통해 Private MCP에 접근할 수 있고, Self-hosted Sandbox에서도 Tunneled MCP 또는 Public MCP를 사용할 수 있다.

따라서:

Private MCP 때문에
무조건 Self-Hosted

는 아니다.

20. 어떤 경우 Self-Hosted가 정말 필요한가

예를 들어:

Agent가

Private Database에 직접 접근해야 함

또는:

Build가

사내 Network에서만 가능

또는:

Code / Artifact 실행 환경을
회사 Security Control 안에 둬야 함

같은 경우다.

Anthropic 역시 Self-hosted가 특히 적합한 상황으로 Private Network의 비공개 서비스 접근과 조직 자체 Compliance·Audit Control을 적용해야 하는 경우를 들고 있다.

21. 반대로 대부분의 팀은 Hosted가 더 낫다

Self-hosted가 무조건 고급 구성은 아니다.

Anthropic도 대부분의 기업에는 운영할 Infrastructure가 필요 없는 Hosted Offering을 권장한다고 명시한다. Self-hosted는 Network·Tooling·Compliance 요구사항 때문에 자체 실행 환경이 필요한 조직을 위한 선택이며, Platform/Developer Experience 팀이 Setup과 지속적인 Maintenance를 담당해야 한다고 설명한다.

즉:

Self-Hosted
=
더 좋은 방식

이 아니다.

정확히는:

Hosted

운영 단순성 ↑
Self-Hosted

환경 통제력 ↑
운영 책임 ↑

이다.

22. Self-Hosted 도입 판단 기준

이런 질문을 해보면 된다.

Agent가 Private Network에 접근해야 하는가?

사내 전용 Compiler / SDK가 필요한가?

Artifact를 자체 환경에 유지해야 하는가?

Custom Security Control이 필요한가?

Runner 운영팀이 존재하는가?

대부분:

NO

라면 Hosted가 더 낫다.

반대로 여러 항목이:

YES

라면 Self-hosted를 검토할 이유가 생긴다.

23. 개발자 개인 PC를 Self-Hosted Runner로 쓰는 것과도 다르다

Claude Code에는 Remote Control도 있다.

Remote Control은 개발자 자신의 Machine에서 실행 중인 Claude Code Session을 Browser나 Phone에서 이어서 조작하는 방식이다.

반면 Self-hosted environment는 Platform Team이 운영하는 공유 Infrastructure에서 Runner가 실행되며 여러 사용자가 이용할 수 있다. Anthropic도 두 방식을 명확히 구분하고 있다.

구조 차이는 다음과 같다.

Remote Control

Phone
 ↓
Developer Mac
 ↓
Claude Code
Self-Hosted

Web / Mobile / Desktop
 ↓
Company Runner Pool
 ↓
Claude Code Session

24. Desktop의 SSH Remote와도 목적이 다르다

Claude Code Desktop은 자체 관리 Linux/macOS Machine에 SSH로 연결해 Claude Code를 실행하는 Remote 환경도 지원한다. 이런 방식은 특정 VM이나 Dev Container에서 개인 개발 세션을 실행할 때 유용하다.

하지만 회사 전체 Runtime을 만들려면:

SSH Server 한 대

보다:

Session Queue

Runner Pool

Isolation

Autoscaling

Credential

Audit

이 필요한 경우가 많다.

즉 SSH Remote는 좋은 개인/소규모 Remote Development 방식이고, Self-hosted Runner Pool은 Platform Architecture에 가깝다.

25. 실무에서는 세 가지 환경을 함께 운영할 수도 있다

꼭 하나만 선택할 필요는 없다.

Local

빠른 대화형 개발.

Hosted

독립적인 일반 Repository 작업.

Self-Hosted

Private Infrastructure가 필요한 작업.

예:

Simple Refactor

→ Hosted
UI 수정

→ Local
Internal SDK Build

→ Self-Hosted
Private DB Migration 분석

→ Self-Hosted

이런 Routing이 더 현실적이다.

26. 추천 Runtime Architecture

조금 더 실제적으로 그려보면 다음과 같다.

Developer
    │
    ▼
Claude Code
Web / Desktop / Mobile
    │
    ▼
Anthropic Control Plane
    │
    ▼
Session Queue
    │
    ▼
┌───────────────────────────┐
│ Company VPC               │
│                           │
│ Runner Orchestrator       │
│        │                  │
│        ▼                  │
│ Ephemeral Agent Sandbox   │
│        │                  │
│        ├─ Workspace       │
│        ├─ Build Tools     │
│        ├─ AGENTS.md       │
│        ├─ Skills          │
│        └─ MCP Client      │
│                           │
│ Credential Broker         │
│        │                  │
│        ├─ Git             │
│        ├─ Registry        │
│        ├─ CI              │
│        └─ Internal API    │
│                           │
│ Egress Gateway            │
│                           │
│ Audit / Trace             │
└───────────────────────────┘

이 구조에서 Claude Code 자체보다 더 중요한 부분은 사실 주변 Infrastructure다.

27. Runner Image를 표준화한다

예:

FROM company-dev-base:2026.08

RUN install-jdk
RUN install-android-sdk
RUN install-gradle
RUN install-node
RUN install-company-cli
RUN install-security-scanner

USER agent

WORKDIR /workspace

실제 Self-hosted 환경에 필요한 Image 형식과 설치 방법은 사용하는 Runner·Sandbox Platform에 맞춰야 한다.

핵심은:

Developer 환경과

Agent 환경의

Toolchain 차이를 줄인다.

이다.

28. Image는 Versioning한다

좋지 않은 구조:

company-agent:latest

만 사용한다.

어제 성공한 Build와 오늘 실패한 Build의 환경 차이를 알기 어렵다.

추천:

company-agent:2026.08.1

company-agent:2026.08.2

company-agent:2026.09.0

그리고 Session Metadata에:

{
  "runnerImage": "company-agent:2026.08.2",
  "gitSha": "ab12cd3",
  "policyVersion": "14"
}

처럼 남긴다.

Self-hosting에서는 Sandbox Image와 Runtime Hardening을 Anthropic이 대신 검증하지 않으므로 Image Supply Chain도 기업의 책임 영역이 된다.

29. Production Repository와 Experiment Repository를 같은 Runner에 넣지 않는다

Trust Boundary를 분리한다.

Runner Pool A

Public OSS
Runner Pool B

Internal Product
Runner Pool C

Security Sensitive

각각:

Network

Credential

Filesystem

Tool

권한을 다르게 가져간다.

Anthropic도 Untrusted Workload를 실행하는 경우 Environment Service Key의 범위를 좁히기 위해 Trust Boundary별 별도 Workspace와 Environment 구성을 고려하라고 권고한다.

30. Tool Permission도 Runtime에서 제한한다

Agent Prompt에:

Production DB 수정하지 마.

라고 쓰는 것만으로는 부족하다.

Runtime에서 애초에:

DB Read-only Credential

만 제공하는 편이 낫다.

예:

Code Agent

READ
WRITE
BUILD
TEST
Release Agent

READ
BUILD
UPLOAD-STAGING
Production Deploy

Human Approval Required

Prompt는 Policy 설명이다.

실제 Security Boundary는 Runtime이어야 한다.

31. Package Manager도 중요한 공격 경로다

Coding Agent는 자주:

npm install

pip install

bundle install

swift package resolve

./gradlew build

를 실행한다.

이 과정에서는 외부 코드가 실행될 가능성이 있다.

따라서 Package Registry를:

Public Registry 직접 접근

보다:

Agent
 ↓
Company Package Proxy
 ↓
Approved Registry

형태로 운영하는 것도 좋은 방법이다.

32. Agent에게 Root를 줄 이유가 거의 없다

Sandbox 기본 원칙:

Non-root User

Minimal Capability

Read-only Root FS

Writable Workspace만 제공

이다.

Anthropic의 Self-hosted Security Model에서도 불필요한 Linux Capability 제거, Non-root 실행, Read-only Root Filesystem 같은 Hardening을 권장한다.

33. Resource Limit도 둔다

Agent가 실수로:

Infinite Build

Infinite Test

Fork Bomb

Huge Artifact

를 만들 수 있다.

Session마다:

resources:

  cpu: 4

  memory: 8Gi

  disk: 30Gi

  timeout: 45m

같은 Policy를 둘 수 있다.

수치는 프로젝트 특성에 맞게 정한다.

핵심은 Agent에게 사실상 무제한 Compute를 주지 않는 것이다.

34. Wall-Time Budget도 필요하다

Coding Agent는 사람처럼:

이 정도면 그만해야겠다.

를 항상 적절하게 판단한다고 가정하면 안 된다.

Runtime Level에서:

30분

60분

120분

등 Task Type에 따른 Maximum Duration을 둔다.

35. Agent Session에 Identity를 붙인다

모든 실행에 최소 다음 정보가 있어야 한다.

User

Repository

Branch

Task

Agent

Session ID

Runner

Policy Version

예:

{
  "user": "developer@company.com",
  "repo": "mobile/app",
  "branch": "agent/profile-fix",
  "session": "sess_123",
  "runner": "runner-19",
  "policy": "coding-standard-v14"
}

그래야 나중에:

누가

무슨 작업을

어느 Agent에게

어떤 권한으로

실행시켰는가

를 추적할 수 있다.

36. Audit Log에는 Shell Command도 남긴다

예:

14:01 git status

14:02 rg "SessionManager"

14:04 swift test

14:07 git diff

14:09 xcodebuild ...

특히:

Network

Credential Access

External Write

Package Install

은 별도 Risk Event로 남기는 것이 좋다.

37. 하지만 모든 로그를 그대로 저장하는 것도 위험하다

Tool Result에는 Secret이 포함될 수 있다.

예:

Authorization Header

Database Connection String

Build Environment

Signing Key Path

따라서 Audit Pipeline에는:

Redaction

Secret Detection

Retention Policy

가 필요하다.

Self-hosted 환경에서 Session Content와 Tool Output이 Worker를 통과한 뒤 어떤 방식으로 저장·삭제되는지는 운영 조직의 책임이라는 점도 Anthropic의 보안 모델에 명시돼 있다.

38. Observability는 로그만 보면 부족하다

추천 Metric:

Active Sessions

Queue Time

Runner Startup Time

Task Duration

Build Success Rate

Agent Retry Count

Tool Call Count

Network Denied Count

Sandbox Failure

Human Intervention Rate

여기에 AI 비용까지 연결한다.

Task

↓

Token Cost

+

Compute Cost

+

Human Review Cost

지난 글에서 다룬 Cost per Successful Task와도 연결되는 부분이다.

39. Runner Autoscaling도 결국 Queue 문제다

예:

Queued Sessions

0~5

→ Runner 5
Queued Sessions

20

→ Runner 15
Night

→ Runner 2

처럼 운영할 수 있다.

Self-hosted environments의 On-demand 방식 역시 Queue된 Session에 따라 Runner Capacity를 생성하고 작업 종료 후 줄이는 형태다.

40. Mobile 팀이라면 Runner Pool을 분리할 이유가 더 많다

예:

Android Runner

Linux

JDK
Android SDK
Gradle
Backend Runner

Linux

Node
Go
Python
Docker
iOS Runner

macOS

Xcode
Simulator
Swift
Fastlane

필요한 OS와 Toolchain이 완전히 다르기 때문이다.

Agent Router는 Repository와 Task에 따라 적절한 Environment를 선택한다.

Task

↓

Environment Router

├─ android
├─ ios
└─ backend

41. Environment를 Repository에 고정할 수도 있다

예:

repository: mobile-ios

environment: ios-xcode-26

networkPolicy: mobile-standard

credentialProfile: mobile-dev

이렇게 해두면 Agent가 임의로 Environment를 선택하지 않는다.

42. 중요한 것은 Developer Experience다

Infrastructure가 아무리 좋아도 개발자가 매번:

Runner 선택

Image 선택

Credential 선택

Network Policy 선택

Workspace 생성

을 해야 하면 사용하지 않는다.

개발자는 그냥:

결제 화면의 Race Condition 조사해서
수정하고 테스트까지 돌려줘.

라고 하는 것이 이상적이다.

뒤에서는 Platform이 자동으로:

Repository

↓

Risk Classification

↓

Runner Selection

↓

Sandbox

↓

Credential

↓

Network Policy

를 결정한다.

43. Self-Hosted Runtime의 목표는 Infrastructure를 보여주는 것이 아니다

좋은 Platform은 Infrastructure가 보이지 않는다.

Developer

Task 작성

↓

Agent Platform

환경 선택

격리

권한

검증

감사

↓

Developer

Diff Review

가 되어야 한다.

44. PR까지 자동화하면 Runtime이 더 중요해진다

예:

Jira Issue

↓

Agent Session

↓

Repository Clone

↓

Bug 수정

↓

Test

↓

Branch Push

↓

PR 생성

↓

Human Review

Anthropic이 공개한 Self-hosted 환경 사례에서도 내부 Workflow와 통합해 PR 생성, CI Issue 수정 등의 작업을 자체 Compute에서 수행하는 형태가 소개됐다.

Agent가 단순 보조 도구가 아니라 Software Delivery Pipeline의 Worker가 되는 것이다.

45. 이때 Human Gate를 어디 둘지 정해야 한다

예:

Repository Read

AUTO
Code Modify

AUTO
Test

AUTO
Branch Push

AUTO
PR Create

AUTO
Merge

HUMAN
Production Deploy

HUMAN

처럼 Risk Level별로 정한다.

Self-hosted라고 해서 Agent에게 더 많은 권한을 자동으로 줘야 하는 것은 아니다.

오히려 기업 Runtime일수록 Permission Policy를 명확히 해야 한다.

46. AGENTS.md도 Runner Image 안에 넣지 않는 것이 좋다

Architecture Rule은 Repository와 같이 Versioning하는 편이 낫다.

Repository

├── AGENTS.md
├── docs/
├── skills/
└── src/

Runner는 범용 실행 환경이고:

Coding Convention

Architecture

Test Policy

Feature Rule

은 Repository가 소유한다.

그러면 PR에서 Rule 변경도 같이 Review할 수 있다.

47. Runner Image와 Repository Policy를 분리한다

Runner Image

OS
Compiler
SDK
Security Tool
Company CLI
Repository

AGENTS.md
Skills
Architecture
Test Rule
Platform Policy

Credential
Network
Timeout
Approval

세 층으로 나누면 관리가 쉬워진다.

48. 추천 Configuration 구조

예를 들어 Platform Repository:

agent-platform/
├── images/
│   ├── android/
│   ├── ios/
│   └── backend/
│
├── policies/
│   ├── network/
│   ├── credentials/
│   ├── resources/
│   └── approvals/
│
├── environments/
│   ├── android-dev.yaml
│   ├── ios-dev.yaml
│   └── backend-dev.yaml
│
└── observability/

Application Repository:

my-app/
├── AGENTS.md
├── .ai/
│   ├── skills/
│   └── templates/
├── docs/
└── src/

책임이 명확해진다.

49. Development Agent와 Security Agent도 Environment를 분리할 수 있다

예:

Developer Agent

Read / Write
Build
Test

Security Agent:

Read
Security Scanner
Dependency DB
No Write

Release Agent:

Read
Build
Artifact Upload
No Source Modification

Agent별 Tool과 Runtime 권한을 최소화한다.

50. 모든 Agent가 같은 Secret Store를 보지 않게 한다

Credential Profile

developer
Credential Profile

release
Credential Profile

security

로 나눈다.

Secret은:

Agent Identity

+

Task

+

Repository

+

Environment

를 확인한 뒤 발급하도록 한다.

51. Kill Switch도 있어야 한다

다음 상황에서:

이상한 Network 요청 급증

Package Supply Chain 사고

Credential Leakage 의심

Agent가 반복적으로 위험 Command 실행

특정 Repository 침해

즉시:

Runner Pool Stop

Credential Revoke

Environment Disable

Network Deny

할 수 있어야 한다.

Agent Platform이 Production Infrastructure가 되면 이런 운영 기능이 필요하다.

52. Self-Hosted라고 모든 보안 문제가 해결되는 것은 아니다

오히려 책임이 늘어난다.

Anthropic의 Shared Responsibility Model을 보면 Self-hosted 환경에서 기업이 직접 책임져야 하는 영역이 명확하다.

Sandbox Image Hardening

Network Egress

Environment Key 보관

Untrusted Workload Isolation

Tool Execution Blast Radius

Log Retention

등이다.

즉:

Cloud에서 빼냈으니 안전하다.

가 아니다.

Security Boundary를
회사가 직접 운영하게 됐다.

가 더 정확하다.

53. 그래서 Platform Team이 필요하다

Self-hosted Coding Agent Runtime은 개별 개발자가 관리할 성격의 시스템이 아니다.

규모가 커지면:

Platform Engineering

Developer Experience

Security

Infrastructure

가 같이 다뤄야 한다.

Anthropic도 Self-hosted environments를 도입하는 조직은 Platform·Developer Experience·Developer Productivity 팀이 Runner Image 구축과 업데이트, Runner 운영, On-demand Orchestrator 등을 소유하는 것을 전제로 설명한다.

54. 처음부터 Kubernetes Platform을 만들 필요는 없다

도입 초기라면:

Fixed Runner 2~3개

↓

Session Workspace 분리

↓

Read-only Internal Access

↓

Audit

정도부터 시작할 수 있다.

사용량이 늘면:

On-Demand

↓

Ephemeral Sandbox

↓

Autoscaling

↓

Credential Broker

↓

Environment Routing

으로 발전시키면 된다.

55. 추천 도입 1단계

가장 먼저 Read-heavy Task부터 시작한다.

예:

Architecture 조사

Bug 원인 분석

PR Review

Test Failure 분석

Agent가 Source를 수정하지 않거나 수정하더라도 외부 Side Effect가 적은 작업이다.

56. 2단계

Code Modification까지 허용한다.

Feature 추가

Bug Fix

Test 추가

Refactoring

하지만:

Push

Merge

Deploy

는 Human Gate로 둔다.

57. 3단계

CI와 연결한다.

Agent

↓

Code

↓

Build

↓

Test

↓

Static Analysis

↓

PR

Agent 결과가 deterministic validation을 통과해야 사람에게 올라온다.

58. 4단계

Workflow Event와 연결한다.

예:

CI Failure

↓

Agent 자동 시작

↓

Log 분석

↓

원인 조사

↓

Patch 생성

↓

Test

↓

PR

이 시점부터 Coding Agent는 Chat Tool보다 Event-driven Worker에 가까워진다.

59. 5단계

Task별 Runtime Routing을 한다.

Simple Code Review

→ Hosted
Internal Service Access

→ Self-Hosted
Local Interactive Debug

→ Local
Sensitive Build

→ Restricted Self-Hosted

모든 작업을 Self-hosted로 보내지 않는다.

60. 최종적으로는 Coding Agent Control Plane이 된다

구조가 발전하면:

                 Developer
                    │
                    ▼
              Agent Gateway
                    │
             Task Classifier
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
     Local        Hosted      Self-Hosted
                                 │
                         Environment Router
                                 │
                   ┌─────────────┼─────────────┐
                   ▼             ▼             ▼
                Android         iOS         Backend
                   │             │             │
                Sandbox       Sandbox       Sandbox

정도가 된다.

개발자는 어느 Runner에서 실행되는지 신경 쓰지 않는다.

61. 결국 중요한 것은 “어디에서 Claude가 실행되느냐”보다 “어디에서 Tool이 실행되느냐”다

Coding Agent는:

Model

+

Tool Execution

두 부분으로 나눠 생각해야 한다.

Model은 판단한다.

어떤 파일을 읽을까

어떤 명령을 실행할까

어떤 코드를 수정할까

Runtime은 실제 행동한다.

파일 읽기

Shell 실행

Network 접근

Credential 사용

Build

Write

기업 보안에서는 두 번째가 훨씬 중요할 때가 많다.

62. Self-Hosted Coding Agent의 핵심은 모델 Hosting이 아니다

한 줄로 줄이면:

Claude를 회사 서버에 설치한다.

가 아니다.

정확한 의미는:

Claude가 행동하는
개발 환경을
회사 Security Boundary 안에 둔다.

이다.

63. 이 변화가 중요한 이유

Coding Agent가 단순히:

코드 추천

만 하던 시절에는 실행 환경이 크게 중요하지 않았다.

하지만 Agent가:

Repository Clone

Code Modify

Shell

Build

Test

Database

MCP

CI

PR

까지 수행하기 시작하면 상황이 달라진다.

Agent 자체가 하나의 Compute Workload가 된다.

64. 그래서 앞으로 Coding Agent Platform은 CI와 닮아갈 가능성이 높다

CI도 처음에는:

개발자가 Script 실행

이었다.

그러다:

Runner

Job

Workspace

Secret

Cache

Artifact

Permission

Audit

이라는 Platform이 만들어졌다.

Coding Agent 역시 비슷한 방향으로 움직이고 있다.

Agent Runner

Session

Sandbox

Credential

Artifact

Network Policy

Audit

이라는 개념이 점점 중요해진다.

이 부분은 공식 기능들을 바탕으로 한 Architecture 관점의 해석이다.

65. 하지만 CI와 완전히 같지는 않다

CI:

미리 정의된 Script

Agent:

상황에 따라
다른 Tool을 선택

한다.

즉 Agent Runtime은 CI Runner보다 행동 공간이 훨씬 넓다.

그래서:

Sandbox

Least Privilege

Network Egress

Credential Scope

Human Gate

가 더 중요해진다.

66. 추천 최소 Production 구성

기업에서 첫 Self-hosted Coding Agent Runtime을 만든다면 다음 정도부터 시작할 수 있다.

Self-Hosted Runner

+

Session별 Workspace

+

Non-root Sandbox

+

Private Git

+

Internal Package Registry

+

Network Allowlist

+

Short-lived Credential

+

Build / Test

+

Audit Log

+

Human Merge

이 정도만 갖춰도 단순 Shared VM에서 Agent를 실행하는 것보다 훨씬 명확한 운영 경계를 만들 수 있다.

67. 피해야 할 첫 번째 구조

회사 개발 서버 한 대

↓

Claude Code 설치

↓

모든 개발자가 같이 사용

↓

같은 Workspace

↓

같은 AWS Credential

↓

인터넷 전체 허용

이다.

Self-hosted는 했지만 보안 경계가 거의 없다.

68. 두 번째로 피해야 할 구조

모든 위험을 Prompt에 맡긴다.

중요한 파일 삭제하지 마.

Production 접근하지 마.

Secret 출력하지 마.

외부 서버로 보내지 마.

Prompt는 보안 통제가 아니다.

가능하다면 Runtime에서:

삭제 불가능

접근 불가능

Credential 없음

Egress 불가능

으로 만들어야 한다.

69. 세 번째로 피해야 할 구조

Self-hosted를 모든 Repository에 적용한다.

Self-hosted는 운영비가 있다.

Anthropic도 Hosted Environment를 대부분의 기업에 더 단순한 기본 선택으로 권장한다.

따라서:

Self-hosted가 필요한 Task만

Self-hosted로 보낸다.

가 더 현실적이다.

70. 마무리

Claude Code Self-hosted environments의 의미는 단순히:

Claude Code를
회사 서버에서 실행할 수 있다.

에 그치지 않는다.

더 중요한 변화는 Coding Agent가 기업의 실제 Developer Infrastructure 안으로 들어오기 시작했다는 것이다.

구조는 점점 이렇게 변하고 있다.

과거

Developer
   ↓
IDE
   ↓
Code

지금:

Developer
   ↓
Coding Agent
   ↓
Repository
   ↓
Build / Test

그리고 기업 환경에서는:

Developer
   ↓
Agent Control Plane
   ↓
Self-Hosted Runtime
   ↓
Sandbox
   ↓
Private Git
Internal MCP
Database
Registry
CI

가 된다.

이 단계에 도달하면 Agent를 단순한 IDE Plugin으로만 볼 수 없다.

Agent

=
새로운 종류의
Developer Infrastructure Workload

가 된다.

따라서 앞으로 중요한 질문도 달라진다.

어떤 모델이 코딩을 더 잘하는가?

뿐 아니라:

Agent를 어디에서 실행할 것인가?

어떤 Network를 허용할 것인가?

어떤 Credential을 줄 것인가?

Session을 어떻게 격리할 것인가?

어떤 작업에 Human Approval이 필요한가?

무엇을 Audit할 것인가?

를 함께 설계해야 한다.

Claude Code의 Self-hosted environments는 이 변화를 꽤 명확하게 보여준다.

그리고 실무적으로 가장 중요한 원칙은 하나다.

Self-Hosted의 목적은
Claude를 내부에 넣는 것이 아니다.

Agent가 실제로 행동하는 영역을
회사가 통제할 수 있는
Security Boundary 안에 두는 것이다.

Coding Agent가 점점 더 많은 코드를 작성하게 될수록 모델 선택보다 Agent Runtime Architecture가 중요한 조직도 빠르게 늘어날 가능성이 높다.

참고 자료

  • Anthropic — Run Claude Code sessions on your own compute
    2026년 8월 6일 공개된 Claude Code Self-hosted environments 공식 발표. Public Beta 범위, Fixed/On-demand Runner, 자체 Network 접근, Toolchain Customization, 데이터 경계와 운영 책임을 설명한다.

  • Claude Platform — Self-hosted sandboxes
    Claude Managed Agents에서 Tool Execution·Filesystem·Network Egress를 자체 Infrastructure로 이동시키는 구조와 Worker, Work Queue, Session Sandbox, MCP 연동 방식을 설명하는 공식 문서.

  • Claude Platform — Self-hosted sandbox security model
    Sandbox Image Hardening, Network Egress, Environment Key, Tool Blast Radius, Logging 등 Self-hosted 환경에서 조직이 직접 책임져야 하는 보안 영역을 설명한다.

  • Claude Code — Development containers
    Claude Code를 격리된 Dev Container 내부에서 실행하고 조직 정책과 Network Egress를 제어하는 공식 가이드.

  • Claude Code — Desktop / SSH environments
    Claude Code Desktop에서 Local·Remote·SSH 환경을 선택하고 자체 관리 Server나 VM에서 Session을 실행하는 방식에 대한 공식 문서.

  • Claude Managed Agents — Overview
    Agent·Environment·Session·Event 구조와 Cloud Sandbox 또는 Self-hosted Sandbox를 선택할 수 있는 Managed Agent Runtime의 기본 Architecture를 설명한다.

핵심 참고 포인트

Claude Code의 Self-hosted environments는 2026년 8월 현재 Public Beta이며 Team·Enterprise 조직에서 사용할 수 있다. 다만 Anthropic은 대부분의 기업에는 운영 부담이 적은 Hosted 방식을 권장하고 있으며, Self-hosted는 내부 Network·특수 Toolchain·Compliance 요구가 있는 조직을 위한 선택으로 설명한다.

또한 Self-hosted라는 이름과 달리 Claude 모델 자체가 기업 서버에서 추론되는 구조는 아니다. Repository Checkout·Build Artifact·Secret·Filesystem·Process 등 실행 환경은 자체 Infrastructure에 유지할 수 있지만, 모델 추론에 필요한 Prompt·Response·Tool Result는 Anthropic 측 Control Plane과 통신한다. 따라서 실제 도입 전에는 조직의 Data Classification과 Compliance 요구사항에 맞는지 별도로 검토해야 한다.

Self-hosting 이후에는 Sandbox Image, Network Egress, Credential Storage, Isolation, Tool Permission, Log Retention 같은 영역이 조직의 책임이 된다. 따라서 단순히 VM에 Claude Code를 설치하는 것보다 Ephemeral Sandbox + Least Privilege + Network Allowlist + Short-lived Credential + Audit + Human Gate를 갖춘 Runtime Architecture로 접근하는 편이 안전하다.

profile
이경규
iOS 앱 개발자
이전 포스트

Tokenmaxxing은 정말 낭비일까: AI Agent 비용을 아껴야 할 때와 과감하게 써야 할 때

다음 포스트

이 코드는 누가 만들었나: AI Coding Agent 시대의 Git Provenance와 PR 증명서 설계

0개의 댓글