IBM Bob 해부 (2) — 오픈소스로 만드는 폐쇄망 개발 에이전트 플랫폼 설계

1편에서 IBM Bob을 분석했습니다. 정리하면 Bob의 가치는 모델 자체보다 공통 하네스, 역할별 모드와 승인 정책, 감사, 현대화 워크플로, 그리고 이 모두를 고객의 폐쇄망 안에 들여놓는 배포 방식에 있습니다.

이번 글은 같은 플랫폼을 오픈소스로 직접 구성한다면 어떻게 설계할지 다룹니다. 목표는 Bob을 그대로 복제하는 것이 아니라, Bob이 보여 준 구조를 기준선으로 삼되 1편에서 짚은 약점(시스템 수준 샌드박스 부재, 제한적인 폐쇄망 모델 선택)을 보완하는 것입니다.

이 글은 설계 문서입니다. 설정 예시는 구조를 설명하기 위한 것이며 그대로 운영에 쓰기 전에 각 프로젝트 문서로 검증해야 합니다. 오픈소스 프로젝트의 라이선스와 상태는 2026년 10월 4일 기준이며 바뀔 수 있습니다.

1. 요구사항

폐쇄망 개발 에이전트 플랫폼이 만족해야 할 요구사항부터 정리합니다.

2. 설계 원칙

요구사항을 다섯 가지 원칙으로 압축했습니다. 이후 모든 계층 설계가 이 원칙을 따릅니다.

1. 표준 프로토콜로 계층을 나눈다. 에디터와 에이전트 사이는 ACP, 에이전트와 도구 사이는 MCP, 에이전트와 모델 사이는 OpenAI 호환 API, 규칙은 AGENTS.md. 계층 사이가 표준이면 한 계층의 오픈소스 프로젝트가 멈춰도 그 계층만 교체하면 됩니다.
2. 격리는 에이전트 바깥에서 한다. 에이전트 내부의 무시 목록이나 승인 설정은 편의 장치일 뿐 보안 경계가 아닙니다. 보안 경계는 컨테이너 런타임과 네트워크 정책이 맡습니다.
3. 모델은 게이트웨이 뒤에 숨긴다. 하네스는 실제 모델 이름이 아니라 agent-plan, agent-code 같은 역할 별칭만 압니다. 모델 교체·라우팅·예산·로그는 게이트웨이에서 처리합니다.
4. 결정론적 도구가 먼저, 모델은 나머지를. 컴파일러, 테스트, 정적 분석, 코드 변환 도구로 할 수 있는 일은 그것으로 하고, 모델은 그 결과를 해석하고 남은 문제를 고치는 데 씁니다.
5. 정책과 설정은 Git으로 관리한다. 모드 정의, 승인 정책, 규칙, 게이트웨이 설정을 모두 저장소에 두고 리뷰를 거쳐 배포합니다. 정책 변경도 감사 대상입니다.

3. 전체 아키텍처

1편의 Bob 구조와 비교하면, Bob의 "공통 하네스"를 ②~③으로 나눠 에이전트 실행과 명령 실행 환경을 분리한 것이 가장 큰 차이입니다.

4. Bob 구성요소와 오픈소스 대응표

IBM i(RPG)와 메인프레임(Z) 패키지에 대응하는 성숙한 오픈소스는 사실상 없습니다. 이 영역은 오픈소스 구성의 한계로 분명히 남겨 둡니다.

5. 계층별 설계

5.1 사용 화면: 에디터는 ACP로, CI는 비대화형으로

사용 화면은 세 갈래입니다.

• 에디터: ACP를 지원하는 에디터(Zed, JetBrains, Neovim 등)는 하네스 CLI를 ACP 서버로 띄워 연결합니다. 에디터는 화면과 승인 대화상자만 그리고, 실행은 하네스가 맡습니다. Bob이 bob acp로 하는 것과 같은 구조입니다.
• 브라우저 IDE: 개발자 PC에 도구를 설치하기 어려운 폐쇄망에서는 code-server를 사내에 띄우고 에이전트 확장을 미리 넣어 둔 이미지를 배포합니다. 확장 파일(.vsix)은 공급망 절차(5.9)로 반입합니다.
• CI: 반복 작업(의존성 업그레이드, 문서 갱신, 리뷰 초안)은 하네스의 비대화형 모드로 파이프라인에서 실행하고, 결과는 항상 PR로 남깁니다.

하네스는 하나를 표준으로 정하되, 교체 가능하게 둡니다. 비교 기준은 다음과 같습니다.

마지막 기준은 실제 사례가 있습니다. Bob의 모드 형식과 거의 같은 형식을 쓰던 Roo Code는 2026년 5월 원 개발팀이 저장소를 아카이브했습니다. 계층을 표준으로 나눠 두는 원칙 1이 필요한 이유입니다.

5.2 하네스: 모드·규칙·승인을 코드로

모드. 하네스마다 모드 설정 형식이 다르므로, 플랫폼의 원본 정의는 중립 형식으로 Git에 두고 각 하네스 형식으로 변환해 배포합니다. Bob의 형식을 참고한 원본 예시입니다.

# platform-policy/modes.yaml — 플랫폼 표준 모드 (원본 정의)
modes:
  - slug: ask
    description: 코드 분석·질의. 아무것도 바꾸지 않는다.
    tools: [read, code_search]
  - slug: plan
    description: 변경 계획 수립. 계획 문서만 작성한다.
    tools: [read, code_search, edit]
    edit_paths: ["docs/plans/**"]
  - slug: code
    description: 구현과 테스트.
    tools: [read, code_search, edit, execute, mcp]
    edit_paths: ["src/**", "test/**", "pom.xml", "build.gradle*"]
  - slug: review
    description: 다른 에이전트의 변경을 검토. 코멘트만 남긴다.
    tools: [read, code_search, comment]
    model: agent-review          # 작성 모델과 다른 모델로 교차 검토

규칙. 조직 공통 규칙은 AGENTS.md로 작성해 모든 저장소에 배포합니다. Bob, Codex, OpenCode 등 대부분의 코딩 에이전트가 이 파일을 읽으므로, 하네스를 바꿔도 규칙은 유지됩니다.

서브에이전트. 계획·구현·리뷰를 별도 컨텍스트에서 수행합니다. 리뷰 에이전트는 구현 에이전트의 대화 기록을 보지 않고 diff와 계획 문서만 보게 해야 같은 실수를 반복하지 않습니다.

승인 정책. 행동 판정은 하네스 설정에 흩어 두지 않고 OPA 정책 하나로 모읍니다. 하네스(또는 하네스 래퍼)는 도구를 실행하기 전에 정책 엔진에 묻고, 판정은 감사 로그에 남깁니다.

# platform-policy/approval.rego
package agent.approval
 
import rego.v1
 
# 판정 우선순위: 차단 > 자동 허용 > 승인 요청
decision := "deny" if {
	denied
} else := "allow" if {
	auto_allowed
} else := "ask"
 
denied if {
	input.tool == "execute"
	some prefix in data.policy.denied_commands      # 예: "rm -rf", "curl", "ssh"
	startswith(input.command, prefix)
}
 
denied if {
	input.tool == "edit"
	not path_allowed
}
 
auto_allowed if input.tool in {"read", "code_search"}
 
auto_allowed if {
	input.tool == "execute"
	some prefix in data.policy.approved_commands    # 예: "mvn -q test", "git diff"
	startswith(input.command, prefix)
}
 
path_allowed if {
	some pattern in data.modes[input.mode].edit_paths
	glob.match(pattern, ["/"], input.path)
}

이 구조의 장점은 Bob의 allowed_permissions·approvedCommands·deniedCommands·fileRegex가 하던 일을 하네스와 무관하게 한곳에서 관리하고, 정책 변경도 PR로 리뷰할 수 있다는 점입니다.

5.3 실행 샌드박스: 작업마다 일회용 격리 환경

1편에서 짚은 Bob의 가장 큰 약점이 "시스템 수준 샌드박스 없음"이었습니다. 오픈소스 설계에서는 이 부분을 플랫폼의 중심에 둡니다.

설계 요점은 다음과 같습니다.

• 작업마다 새 Pod: 이전 작업의 파일·캐시·자격증명이 남지 않습니다. 빌드 캐시가 필요하면 읽기 전용 캐시 볼륨을 따로 붙입니다.
• 커널 격리: gVisor 또는 Kata Containers를 런타임 클래스로 지정해, 에이전트가 실행한 명령이 호스트 커널을 직접 건드리지 않게 합니다.
• 최소 자격증명: 해당 저장소의 작업 브랜치에만 push할 수 있는 단기 토큰을 주입합니다. main 브랜치 보호로 직접 반영을 막습니다.
• 외부 통신 차단: 기본은 전부 차단하고 게이트웨이, Git 서버, 패키지 미러만 허용합니다.

# 샌드박스 네임스페이스의 외부 통신 정책
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-sandbox-egress
  namespace: agent-sandbox
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
    - to:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: model-gateway }
      ports: [{ port: 4000, protocol: TCP }]
    - to:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: git }
      ports: [{ port: 443, protocol: TCP }]
    - to:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: artifact-mirror }
      ports: [{ port: 443, protocol: TCP }]
    - to:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
      ports: [{ port: 53, protocol: UDP }, { port: 53, protocol: TCP }]

이렇게 하면 프롬프트 인젝션으로 에이전트가 "이 파일을 외부 주소로 보내라"는 지시를 따르더라도, 네트워크 계층에서 실패합니다. 에이전트 내부의 판단이 아니라 환경이 막는 구조입니다.

5.4 모델 계층: 게이트웨이 뒤의 역할 별칭

하네스는 역할 별칭만 알고, 실제 모델은 게이트웨이 설정에서 결정합니다.

# LiteLLM 게이트웨이 설정 예시 (config.yaml)
model_list:
  - model_name: agent-plan            # 계획·설계: 추론 성능 우선
    litellm_params:
      model: hosted_vllm/<plan-model>
      api_base: http://vllm-plan.model-serving:8000/v1
  - model_name: agent-code            # 구현: 도구 호출 품질·속도 우선
    litellm_params:
      model: hosted_vllm/<code-model>
      api_base: http://vllm-code.model-serving:8000/v1
  - model_name: agent-review          # 리뷰: 구현 모델과 다른 모델
    litellm_params:
      model: hosted_vllm/<review-model>
      api_base: http://vllm-review.model-serving:8000/v1
 
router_settings:
  fallbacks:
    - agent-code: ["agent-plan"]
 
litellm_settings:
  callbacks: ["otel"]
 
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL   # 가상 키·팀별 사용량 기록

• 역할별 모델: Bob이 보안 검사·계획·코드 생성에 서로 다른 모델을 쓰는 것과 같은 발상입니다. 리뷰에는 구현과 다른 모델을 지정해 같은 맹점을 피합니다.
• 팀별 가상 키와 예산: 팀·프로젝트마다 키를 발급하고 사용량 상한을 겁니다. 사용량은 게이트웨이 DB와 관측 계층으로 모입니다.
• 모델 교체: 새 모델은 게이트웨이에 별칭으로 추가하고 일부 트래픽만 보내 비교한 뒤 전환합니다. 하네스와 개발자 설정은 바뀌지 않습니다.

모델 선택은 사내 평가셋으로 합니다. 공개 벤치마크 점수는 사내 코드베이스·빌드 체계·코딩 규칙에서의 성능을 보장하지 않습니다. 다음 방식으로 평가셋을 만들 것을 권합니다.

1. 사내 저장소에서 테스트가 함께 들어간 과거 버그 수정 커밋을 고릅니다.
2. 수정 전 상태와 이슈 설명을 입력으로, 해당 테스트 통과를 정답 기준으로 삼습니다.
3. "모델 × 하네스" 조합마다 통과율, 작업당 토큰·시간, 정책 차단 횟수, 리뷰 반려율을 측정합니다.

이 평가셋은 모델·하네스 교체 때마다 다시 돌리는 회귀 시험이 됩니다.

5.5 코드 이해 계층: 저장소를 MCP 서버로 노출

대규모 저장소에서 에이전트가 헤매는 이유는 대부분 "어디를 봐야 하는지 모르기 때문"입니다. 코드 이해 기능을 MCP 서버로 만들어 모든 하네스가 같은 방식으로 쓰게 합니다.

색인에는 저장소 접근 권한을 그대로 반영해야 합니다. 개발자가 볼 수 없는 저장소의 코드가 검색 결과로 새어 나오면 그 자체가 정보 유출입니다.

5.6 현대화 파이프라인: 결정론적 변환 다음에 에이전트

Bob의 Java 현대화 모드가 보여 준 "빌드 → 실패 분석 → 원인별 묶기 → 단계적 수정" 흐름을 오픈소스로 구성합니다. 핵심은 원칙 4, 결정론적 도구가 먼저입니다.

1. 분석: Konveyor 분석기로 대상 기술(예: 최신 Java, 컨테이너 환경)로 옮길 때의 문제 지점을 찾습니다. Konveyor는 수천 개의 마이그레이션 규칙을 제공하고, Kai는 이 분석 결과와 과거 변경 이력을 LLM에 제공하는 방식으로 수정을 돕습니다.
2. 결정론적 변환: 기계적으로 바꿀 수 있는 부분은 OpenRewrite 레시피로 일괄 변환합니다. 같은 입력에 항상 같은 결과가 나오고, 모델 비용이 들지 않습니다.

# 예: Java 21 마이그레이션 레시피 실행 (폐쇄망에서는 레시피 아티팩트를 사내 Maven 미러로 제공)
mvn -U org.openrewrite.maven:rewrite-maven-plugin:run \
  -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-migrate-java:RELEASE \
  -Drewrite.activeRecipes=org.openrewrite.java.migrate.UpgradeToJava21

3. 빌드·테스트로 남은 문제를 드러냅니다.
4. 원인별로 묶기: 컴파일 오류와 테스트 실패를 오류 유형·패키지 단위로 묶습니다. 같은 원인의 오류 수십 개를 하나의 작업으로 만들면 에이전트의 컨텍스트와 비용이 크게 줄어듭니다.
5. 에이전트 수정: 묶음 하나를 샌드박스 작업 하나로 처리하고, 다시 빌드합니다.
6. 모든 변경은 PR로 남기고 보안 검사와 사람 리뷰를 거칩니다.

OpenRewrite 레시피 모듈 중 일부는 Moderne Source Available License로 제공됩니다. 조직 내부 코드에 적용하는 것은 허용되지만 상업 제품에 넣어 재판매할 수는 없으므로, 사용할 모듈의 라이선스를 미리 확인해야 합니다.

5.7 검사와 리뷰 게이트

에이전트의 결과는 어떤 경우에도 main에 직접 들어가지 않습니다. 모든 변경은 PR을 거치고, CI에서 다음을 통과해야 합니다.

5.8 거버넌스·관측: 오픈소스로 만드는 Bobalytics

Bobalytics가 보여 주는 생산성·품질·사용량·비용을 세 가지 데이터 출처로 구성합니다.

• 하네스 추적: 작업 단위의 단계별 실행(모델 호출, 도구 실행, 정책 판정)을 OpenTelemetry로 수집해 Langfuse에서 봅니다. 하네스가 OTel을 지원하지 않으면 게이트웨이 로그와 정책 엔진 로그로 보완합니다.
• 게이트웨이 사용량: 팀·키·모델별 토큰과 비용
• Git·CI 결과: PR 생성·병합·반려, 검사 실패

대시보드에서 봐야 할 지표는 다음과 같습니다.

감사 로그는 정책 판정과 승인 기록을 변경 불가능한 저장소(WORM 설정의 오브젝트 스토리지 등)에 별도로 보관합니다. 관측 데이터는 분석용이고, 감사 로그는 책임 추적용이므로 보존 정책이 다릅니다.

5.9 폐쇄망 공급망: 반입 절차가 곧 운영 역량

폐쇄망 플랫폼의 숨은 핵심은 외부에서 무엇을, 어떤 절차로 들여오는가입니다.

반입 절차는 "외부 반입 영역에서 다운로드 → 서명·해시 검증 → 취약점 검사 → 승인 → 내부 반입 → 사내 평가셋 회귀 시험 → 배포" 순서로 표준화합니다. 특히 모델 가중치와 하네스는 바뀌면 에이전트의 행동이 바뀌므로, 회귀 시험을 통과한 조합만 배포합니다.

6. Bob과 오픈소스 구성 비교

어느 쪽이 정답이라기보다, 통제권과 운영 부담의 교환입니다. 운영 인력이 적고 IBM 플랫폼 자산이 핵심이라면 Bob이, 플랫폼 엔지니어링 역량이 있고 모델·격리·비용을 직접 통제해야 한다면 오픈소스 구성이 맞습니다. 두 방식을 섞는 것도 가능합니다. 예를 들어 Bob을 쓰더라도 이 글의 샌드박스(5.3), 게이트웨이(5.4), 검사 게이트(5.7)는 바깥 계층으로 그대로 적용할 수 있습니다.

7. 단계별 로드맵

MVP에서 일부러 뺀 것이 있습니다. 에디터 연동과 현대화 파이프라인은 가치가 크지만, 격리와 검사 게이트 없이 먼저 넓히면 되돌리기 어렵습니다. 안전장치를 먼저 갖추고 사용 범위를 넓히는 순서를 권합니다.

8. 위험과 대응

마치며

IBM Bob이 보여 준 것은 개발 에이전트의 경쟁력이 모델에서 플랫폼으로 옮겨 가고 있다는 사실입니다. 그 플랫폼은 하네스, 모드와 정책, 격리, 모델 라우팅, 감사, 현대화 워크플로, 그리고 폐쇄망 공급망으로 이뤄집니다.

이 구성요소들은 오픈소스로 대부분 갖출 수 있습니다. 다만 오픈소스 구성의 성패는 개별 도구의 선택보다 계층을 표준으로 나누고, 격리를 환경에 맡기고, 정책과 평가를 코드로 관리하는 설계 원칙에서 갈립니다. Bob을 도입하든 직접 구성하든, 이 원칙은 그대로 적용됩니다.

참고 자료

• 1편 — IBM Bob 해부: 에이전트형 개발 플랫폼은 무엇이 다른가
• Agent Client Protocol · Model Context Protocol · AGENTS.md
• LiteLLM · vLLM · SGLang
• OpenAI Codex CLI · OpenCode · Goose · Cline · Continue · code-server
• OpenRewrite · OpenRewrite 라이선스 · Konveyor AI
• Open Policy Agent · gVisor · Kata Containers
• Semgrep · gitleaks · Trivy
• OpenTelemetry · Langfuse · Harbor