IBM Bob 해부 (1) — 에이전트형 개발 플랫폼은 무엇이 다른가

IBM이 10월 1일 개발 에이전트 플랫폼 IBM Bob의 자체 호스팅 배포를 발표했습니다. 온프레미스, 프라이빗·소버린 클라우드, 그리고 외부 연결이 끊긴 폐쇄망에서도 Bob을 돌릴 수 있게 한 것입니다. 소스코드를 외부 AI 서비스로 보낼 수 없는 금융·공공·제조 기업에게는 "코딩 에이전트를 쓸 수 있느냐"의 문제가 "어떻게 들여올 것이냐"의 문제로 바뀌는 신호입니다.

이 시리즈는 두 편으로 구성됩니다.

• 1편(이 글): Bob이 무엇이고, 어떤 구조와 통제 장치를 갖고 있으며, 한계는 무엇인지 공개 문서 기준으로 분석합니다.
• 2편: Bob의 구성요소를 오픈소스로 대응시켜, 폐쇄망에서 운영할 수 있는 개발 에이전트 플랫폼을 설계합니다.

이 글은 2026년 10월 4일 기준 IBM 공식 발표·제품 문서(bob.ibm.com/docs)와 보도를 바탕으로 작성했습니다. 직접 사용한 평가가 아니며, 기능과 지원 범위는 바뀔 수 있습니다.

1. Bob은 무엇인가 — 코드 자동완성이 아니라 SDLC 플랫폼

IBM은 Bob을 "AI 개발 파트너"라고 부릅니다. 핵심 주장은 Bob이 코드를 제안하는 도구가 아니라 계획·코딩·테스트·배포·현대화까지 소프트웨어 개발 수명주기(SDLC) 전체를 조율하는 시스템이라는 것입니다.

AI 개발 도구의 흐름 속에서 보면 위치가 분명해집니다.

Bob은 3단계를 지향합니다. 개별 개발자의 생산성 도구라기보다, 조직이 AI의 행동 범위를 정의하고 감독하는 플랫폼에 가깝습니다.

출시 연혁

생산성 수치는 IBM 사내 설문과 고객 사례(예: Java 업그레이드 30일 → 3일)에서 나온 것으로, 독립 검증된 수치는 아닙니다.

2. 아키텍처 — 하나의 하네스, 두 개의 사용 화면

2026년 7월 개편 이후 Bob은 공통 에이전트 하네스 위에 사용 화면을 올리는 구조입니다. 하네스는 에이전트의 실행 기반으로, 모델 호출·도구 실행·작업 관리를 담당합니다.

구성요소별로 보면 다음과 같습니다.

하네스 기능. IBM은 개편된 하네스의 기능으로 네이티브 도구 호출, 병렬 실행, 서브에이전트(별도 컨텍스트에서 전문 작업 수행), 백그라운드 작업 오케스트레이션(개발자를 막지 않는 장기 작업)을 꼽습니다. 대규모 저장소 분석이나 여러 모듈에 걸친 업그레이드처럼 컨텍스트가 큰 작업을 쪼개 처리하기 위한 구조입니다.

두 개의 사용 화면. Bob IDE는 작업 공간 전체를 다루는 전용 개발 환경입니다. BobShell은 CLI로, 대화형 사용과 CI/CD 파이프라인에서의 비대화형 실행을 모두 지원합니다. BobShell은 bob acp 명령으로 ACP(Agent Client Protocol) 서버가 될 수 있습니다. ACP는 에디터와 코딩 에이전트를 잇는 JSON-RPC 표준으로, 언어 서버에 LSP가 하는 역할을 에이전트에 대해 합니다. 덕분에 Zed, IntelliJ, Neovim, Xcode에서 화면은 각 에디터가 그리고 실행은 Bob이 맡는 구성이 됩니다.

모델 라우팅. Bob은 작업마다 정확도·지연·비용을 기준으로 모델을 고릅니다. IBM이 든 예시는 보안 검사에는 미세조정된 Granite 소형 모델, 복잡한 계획에는 Anthropic Claude, 코드 생성 단계에는 Mistral 오픈 모델을 쓰는 식입니다. IBM은 이 라우팅으로 AI 컴퓨팅 비용을 약 40% 줄였다고 주장합니다.

MCP 연동. 사내 시스템은 MCP 서버로 연결합니다. 기본 설정에서 MCP 도구 호출은 자동 승인되지 않으며, 원격 MCP 서버에는 인증·전송 암호화·접근 통제·감사를 요구합니다.

3. 통제 장치 — 모드, 규칙, 승인, 신뢰

Bob을 단순한 코딩 에이전트와 구분하는 것은 행동 범위를 선언적으로 정의하는 장치들입니다. 공식 문서에 공개된 형식을 기준으로 정리합니다.

모드: 역할별 도구 권한

기본 모드는 세 가지입니다(2026년 7월에 5개에서 정리).

여기에 팀이 커스텀 모드를 정의할 수 있습니다. 전역 설정은 ~/.bob/settings/custom_modes.yaml, 프로젝트 설정은 .bob/custom_modes.yaml에 둡니다.

# .bob/custom_modes.yaml — 문서만 고칠 수 있는 리뷰어 모드 (형식 예시)
customModes:
  - slug: docs-reviewer
    name: Docs Reviewer
    roleDefinition: >-
      You review and improve technical documentation.
      You never modify application code.
    whenToUse: Use for documentation review and editing.
    groups:
      - read
      - - edit
        - fileRegex: ".*\\.(md|mdx)$"
          description: Markdown files only

groups는 모드가 쓸 수 있는 도구 그룹이고, 문서에 나온 그룹은 read, edit, execute, mcp, skill, workflow, todo, subtask, subagent, mode입니다. edit 그룹에는 fileRegex로 수정 가능한 파일 패턴을 걸 수 있습니다. 위 예시처럼 "Markdown만 고칠 수 있는 모드"나 "읽기만 하는 리뷰어 모드"를 만들어 저장소에 커밋하면, 팀 전체가 같은 권한 경계를 공유합니다.

참고로 이 정의 형식(slug, roleDefinition, groups, fileRegex, whenToUse)은 오픈소스 VS Code 확장인 Roo Code의 커스텀 모드 형식과 거의 같습니다. 2편에서 오픈소스 대응 구성을 설계할 때 중요한 관찰입니다.

규칙: 조직의 코딩 표준을 주입

규칙(rules)은 에이전트의 답변 스타일과 판단 기준을 정하는 지시문입니다. BobShell은 rules/(공통), rules-code/, rules-plan/, rules-{모드}/ 디렉터리를 재귀적으로 읽고, 작업 공간 루트의 **AGENTS.md**도 기본으로 읽습니다. AGENTS.md는 여러 코딩 에이전트가 공통으로 읽는 사실상 표준 파일이라, 다른 도구와 규칙을 공유하기 쉽습니다.

승인 정책: 무엇을 자동으로 허용할 것인가

승인 정책은 ~/.bob/settings/settings.json의 approval 키에서 관리합니다. 문서에 공개된 구조는 다음과 같습니다.

IBM 커뮤니티 문서의 권장 원칙은 단순합니다. 읽기는 자동 승인할 수 있고, 상태를 바꾸는 행동은 검토를 거친다. 신뢰하지 않은 작업에서는 명령 실행이 기본으로 꺼져 있고, 한 번만 신뢰할 작업 묶음에는 작업 단위 승인을 쓸 수 있습니다. 변경은 diff로 보여 주고, 체크포인트로 되돌릴 수 있습니다.

신뢰 폴더와 .bobignore

Bob은 프로젝트 설정을 읽기 전에 폴더 신뢰 여부를 묻습니다. 신뢰하지 않은 폴더는 제한 모드로 열리며, 프로젝트 설정·자동 승인·MCP 서버·커스텀 명령이 꺼집니다. 저장소에 악의적인 .bob/ 설정을 심어 두는 공격을 막기 위한 장치입니다.

.bobignore는 .gitignore 문법으로 에이전트가 읽거나 고칠 수 없는 파일을 지정합니다. 비밀정보 파일은 .gitignore와 .bobignore 양쪽에 넣고, 토큰은 .bob/mcp.json 같은 설정 파일에도 넣지 말라는 것이 공식 권고입니다.

4. 현대화 패키지 — 범용 에이전트 위의 도메인 워크플로

2026년 7월 IBM은 세 가지 프리미엄 패키지를 내놨습니다.

여기서 눈여겨볼 점은 범용 에이전트에 도메인 워크플로를 얹는 구조입니다. 한 사용 후기는 Java 현대화 모드의 흐름을 "빌드 → 실패 분석 → 원인별로 오류 묶기 → 단계적 수정"으로 설명합니다. 모델에게 "Java 21로 올려 줘"라고 맡기는 것이 아니라, 빌드 도구와 분석 결과로 작업을 쪼개고 에이전트는 그 안에서 움직이게 하는 방식입니다.

이것이 IBM의 사업적 해자이기도 합니다. Java·IBM i·메인프레임은 IBM 고객의 핵심 자산이고, 범용 코딩 에이전트가 가장 약한 영역입니다. 2편에서 오픈소스로 같은 패턴을 만들 때도, 핵심은 모델이 아니라 결정론적 변환 도구와 워크플로라는 점을 다시 다룹니다.

5. 자체 호스팅과 폐쇄망 구성

10월 1일 발표의 핵심은 Bob을 고객 환경 안에 들여놓는 세 가지 구성입니다.

보도에 따르면 정식 출시 시점에 자체 호스팅에서 지원하는 모델은 NVIDIA Nemotron과 Poolside Laguna입니다. 고객이 이미 라이선스를 가진 모델을 쓰는 방식도 언급됐습니다. 자체 호스팅에는 IDE, BobShell, 병렬 도구 호출, 하네스, 스킬과 모드 같은 핵심 기능이 포함됩니다.

IBM이 인용한 IBM 기업가치연구소 조사에서 경영진의 68%가 국가별 데이터 거주·주권 요건을 맞추기 어렵다고 답했습니다. Bob의 자체 호스팅은 이 수요를 겨냥합니다.

6. 한계와 확인할 점

공개 문서와 발표를 읽으며 도입 전에 확인해야 할 지점을 정리했습니다.

① 시스템 수준 샌드박스가 없습니다. Bob 보안 가이드는 .bobignore가 "시스템 수준 샌드박스를 만들지 않는다"고 명시합니다. 작업 공간 밖의 파일이나 일부 쓰기 작업은 이 제한을 우회할 수 있습니다. 에이전트가 셸 명령을 실행하는 이상, 격리는 컨테이너·VM·네트워크 정책 같은 바깥 계층에서 따로 설계해야 합니다. 2편에서 가장 공들이는 부분입니다.

② 폐쇄망에서 쓸 수 있는 모델이 제한적입니다. 하이브리드 구성에서는 대형 상용 모델을 쓸 수 있지만, 완전 폐쇄망에서는 지원 오픈 웨이트 모델로 범위가 좁아집니다. 같은 Bob이라도 SaaS에서 경험한 품질이 폐쇄망에서 그대로 나온다고 가정하면 안 됩니다. 사내 저장소로 만든 평가셋으로 구성별 품질을 직접 비교해야 합니다.

③ 하이브리드 구성의 데이터 경계를 확인해야 합니다. 모델 서비스가 외부 클라우드에 있으면 프롬프트에 담긴 코드가 그쪽으로 나갑니다. 어떤 작업이 어느 모델로 라우팅되는지, 그 경로를 정책으로 고정할 수 있는지가 핵심 확인 사항입니다.

④ 비용 예측성. SaaS는 Bobcoin 단위의 사용량 과금입니다(Pro 월 20달러, Ultra 월 200달러 등). 자체 호스팅에서는 라이선스와 별도로 GPU·운영 비용이 생깁니다. 백그라운드 작업과 서브에이전트가 늘어날수록 사용량이 사람의 체감과 달라지므로, Bobalytics 같은 사용량 가시화와 예산 통제를 초기부터 설정해야 합니다.

⑤ 프롬프트 인젝션 대응의 세부가 공개돼 있지 않습니다. 정식 출시 발표는 프롬프트 정규화, 민감 데이터 검사, 실시간 정책 집행, 워크플로 내 레드팀을 언급하지만, 구체적인 동작 방식은 공개 문서에서 찾기 어렵습니다. 외부 이슈 트래커·문서·의존성 코드를 읽는 개발 에이전트는 간접 프롬프트 인젝션에 노출되므로, 도입 전에 확인해야 할 항목입니다.

7. 도입 판단 기준

Bob이 보여 주는 방향은 분명합니다. 개발 에이전트의 경쟁력이 모델 성능에서 모드·규칙·승인 정책·감사·현대화 워크플로를 갖춘 플랫폼으로 옮겨 가고 있고, 그 플랫폼을 고객의 폐쇄망 안으로 들여놓는 것이 다음 단계입니다.

그렇다면 이 플랫폼을 오픈소스로 직접 구성할 수 있을까요? 2편 — 오픈소스로 만드는 폐쇄망 개발 에이전트 플랫폼 설계에서 Bob의 구성요소를 하나씩 오픈소스에 대응시켜 설계합니다.

참고 자료

• IBM — Self-Hosted Deployment for IBM Bob (2026-10-01)
• IBM — Bob Premium Packages and new architecture (2026-07-09)
• IBM — Introducing IBM Bob (2026-04-28) · Project Bob 프리뷰 (2025-10-07)
• IBM Bob 제품 페이지
• Bob 문서: 커스텀 모드 · 승인 설정 · 보안 가이드 · ACP · MCP
• IBM Community — Secure and govern IBM Bob
• SiliconANGLE — IBM allows on-prem deployment of Bob
• The Main Thread — IBM Bob for Enterprise Java