IBM Bob

Bob 팀의 인사

오늘은 실제 코드베이스로 작업하는 개발자의 방식을 혁신하도록 설계된 AI SDLC 파트너인 IBM Bob을 공식 출시하면서 소프트웨어 개발의 이정표를 세웁니다.

Bob 팀의 인사

저자

IBM Bob Team

게시됨

카테고리

announcement

공유

이것은 Bob 블로그의 첫 번째 게시물입니다. Bob을 구축하는 팀이 이를 사용하는 개발자를 위해 작성했습니다. 엔지니어링 결정을 설명하고, 실제 코드베이스 내에서 AI 개발 파트너를 제공하면서 배운 것을 공유하며, 때때로 입장을 주장하는 데 사용할 것입니다. 이것은 문서도 마케팅도 아닙니다. 둘 중 하나가 필요하면 올바른 위치로 링크해 드리겠습니다.

첫 번째 게시물에서는 Bob이 하는 모든 것을 살펴보는 대신 세 가지를 하고자 합니다.

  1. Bob의 핵심 기능 중 일부를 살펴봅니다.
  2. Bob이 최고의 작업을 수행할 수 있도록 리포지토리를 설정하기 위한 실용적인 팁을 공유합니다.
  3. 코드에 대한 이러한 종류의 액세스 권한을 가진 도구에서 보안에 어떻게 접근하는지 설명합니다.

1. 개발자가 실제로 시간을 보내는 것

최신 AI 어시스턴트는 설명에서 함수를 작성할 수 있습니다. 이것은 한동안 사실이었으며 더 이상 흥미로운 질문이 아닙니다. 흥미로운 질문은 작업이 "새 코드 생성"이 아니라 "이미 존재하는 시스템 수정"일 때 어떤 일이 일어나는가입니다. 변경할 올바른 위치를 찾고, 팀이 합의한 규칙을 이해하며, 수년간 성장해온 파일 전체에서 동작을 일관되게 유지하는 것입니다. 이것이 대부분의 전문 소프트웨어 개발이 어떻게 보이는지입니다. Bob은 이러한 종류의 작업을 위해 구축되었으며, 이 게시물의 나머지 부분에서 설명하는 설계 선택은 이러한 초점에서 비롯됩니다.

1.1. 모드: Bob에게 수행 중인 작업 유형 알리기

Bob은 단일 "유용한 작업 수행" 상호 작용이 아닙니다. 세션을 시작하는 모드는 Bob에게 수행하려는 작업 유형, 도달할 수 있는 도구, 얼마나 적극적이어야 하는지를 알려줍니다.

  • Ask — 읽기 전용. "탐색 단계"에 완벽합니다. Bob은 변경하지 않고 아키텍처와 로직을 설명합니다. 레거시 시스템에 뛰어들거나 작성하지 않은 로직에 대한 정상성 검사를 수행할 때 사용하세요.
  • Plan — Bob은 수행하려는 변경에 대한 계획을 생성합니다. 건드릴 파일, 고려할 엣지 케이스, 제안된 작업 순서. 출력은 계획이지 코드가 아닙니다.
  • Code — 실제로 변경하기 위한 것입니다. Bob은 설정한 규칙과 규칙을 따라 프로젝트 내에서 읽고, 쓰고, 테스트합니다.
  • Advanced — Model Context Protocol (MCP)을 통해 Code 모드를 확장하여 Bob에게 조직의 특정 도구 및 서비스에 대한 액세스 권한을 부여합니다. 내부 API, 데이터베이스, 독점 도구.
  • Orchestrator — 모드를 넘나드는 다단계 작업용. Bob은 현재 단계에서 요구하는 것에 따라 모드 간에 자체적으로 전환하며, 탐색, 계획 및 실행을 혼합하는 더 큰 작업에 적합한 선택입니다.

세션 시작 시 올바른 모드를 선택하는 것은 더 나은 출력을 얻기 위해 사용할 수 있는 가장 저렴한 레버 중 하나입니다. 특히 잘 모르는 코드베이스나 실제 표면적이 있는 변경의 경우 좋은 습관은 Ask 또는 Plan에서 시작하고 작업에 대한 명확한 그림이 있을 때만 Code로 전환하는 것입니다. Code로 바로 가는 것이 순간적으로 더 빠르게 느껴지지만, 그곳에서 가정이 실제 변경 사항으로 미끄러져 들어가 기술 부채로 축적되기 시작하는 경향이 있습니다.

1.2. Bob tips: 실시간 복잡성 메트릭

우리 모두 경험했습니다. "존"에 깊이 빠져 엣지 케이스를 처리하기 위해 마지막 조건을 중첩하고 있는데, 갑자기 단일 함수가 30줄 미로로 성장했습니다. 일반적인 워크플로에서 그 미로는 팀원이 몇 시간 후 풀 리퀘스트에서 지적할 때까지 풀리지 않습니다. Bob Tips는 로직이 여전히 마음속에 따뜻할 때 리팩토링 제안을 제공하여 이야기를 바꿉니다. 입력하는 동안 지속적인 정적 분석이 열린 파일을 조용히 모니터링합니다. 함수가 높은 순환 복잡성으로 넘어가거나 유지 관리가 어려워지면 Bob은 즉시 보라색 밑줄로 플래그를 지정합니다. 전통적인 린터는 잘못한 것을 알려주기만 합니다. Bob Tips는 탈출구를 제공합니다. 도구의 초점은 실행 가능한 리팩토링 제안을 제공하는 데 전적으로 있습니다.

컨텍스트 인텔리전스: 보라색 밑줄 위로 마우스를 가져가면 경고만 표시되는 것이 아니라 바로 그 자리에서 로직을 풀기 위한 특정 AI 생성 전략을 제공합니다. 원활한 실행: Fix with Bob을 클릭하면 전용 채팅이 즉시 열립니다. AI는 이미 함수의 컨텍스트를 보유하고 있으며 옆에서 정리를 실행할 준비가 되어 있습니다.

백그라운드에서 실행되는 메트릭은 단지 배관일 뿐입니다. 가치 있는 부분은 오래된 코드 품질 신호가 이제 3일 후 코드 리뷰에서 표면화되는 대신 개발자가 파일에 있는 순간에 AI 제안을 구동한다는 것입니다.

1.3. Review 모드: 시스템이 함께 읽는 코드 리뷰

코드 리뷰는 지난 20년 동안 소프트웨어 품질을 위해 다른 어떤 관행만큼이나 많은 일을 해왔으며, 팀이 추진력을 잃는 곳이기도 합니다. Bob은 인간 리뷰를 대체하지 않습니다. 기계적인 부분을 수행하므로 "쉬운" 버그를 찾는 대신 높은 수준의 아키텍처와 의도에 집중할 수 있습니다.

리뷰는 사이드바의 Review Panel 또는 채팅의 /review를 통해 실행됩니다. 두 가지 모드가 있습니다.

  • 브랜치 비교. 이 모드는 "클래식" diff를 처리합니다. /review를 사용하여 현재 헤드에 대해 커밋되지 않은 작업을 감사하거나 /review <branch>를 사용하여 특정 원격을 대상으로 합니다. 일반적으로 리뷰 스레드를 막는 "nitpicks"에 대한 선제 공격입니다.
  • Issue 커버리지. /review <issue-url> --issue-coverage는 로컬 변경 사항이 GitHub issue가 요청하는 것을 실제로 해결하는지 확인합니다. 이것은 개발자들이 시도할 때까지 원한다는 것을 깨닫지 못했다고 말하는 모드입니다. 결과는 전용 패널에 나타나므로 검토하고 Bob으로 수정하기로 결정할 수 있습니다. 좋은 코드를 작성했을 뿐만 아니라 올바른 코드를 작성했음을 확인하는 정상성 검사입니다.

1.4. Literate coding: 코드 옆에 작성된 의도

복잡한 기능에 깊이 빠져 있을 때 채팅 창에서 여러 파일을 참조하는 것은 번거롭습니다. "types.ts의 인터페이스와 api.ts의 서비스를 보고 여기서 로직을 업데이트하세요..."라고 입력하는 자신을 발견합니다. Bob은 이 역학을 뒤집습니다. Literate Coding을 통해 상호 작용을 소스 파일로 직접 이동함으로써 편집기 자체가 인터페이스가 됩니다. 이것은 사이드 패널을 피하는 것만이 아닙니다. AI에 의도의 정교한 다중 파일 맵을 제공하는 것입니다.

  • 의도를 자연스럽게 표현: Cmd+M으로 모드를 전환하고 일반 언어 또는 의사 코드로 로직을 작성합니다. 지침은 편집기에 파란색으로 나타나며 구현이 속한 위치에 정확히 존재합니다.
  • 단일 라인을 넘어서: 전통적인 채팅은 종종 복잡한 프로젝트의 "스레드"를 잃는 반면, Bob의 literate coding은 파일 간의 격차를 메우기 위해 진화하고 있습니다. 개발자는 이제 여러 모듈에 걸쳐 컨텍스트를 제공할 수 있으며, 데이터 모델의 변경 사항이 관련 컨트롤러에 정확하게 반영되도록 합니다.
  • 즉각적인 검증: Cmd+Enter를 누르면 Bob이 제자리에서 구현을 생성합니다. 결과가 인라인 diff로 표시되므로 변경 사항을 커밋하기 전에 주변 코드에 대해 로직을 감사할 수 있습니다.

이점은 간단합니다. 프롬프트는 코드가 있는 곳에 있으며 주변 파일이 이미 컨텍스트 역할을 합니다. 현재 범위는 단일 파일입니다. 다중 파일 지원은 로드맵에 있습니다.

1.5. 터미널의 Bob

Bob Shell은 Bob의 기능을 명령줄로 가져오며, 특히 가치 있다고 생각하는 두 가지 사용 방법이 있습니다.

  • 작업 공간으로서의 터미널: 셸 내에서 AI 개발 어시스턴트와 작업하는 것은 그 자체로 인기 있는 폼 팩터로 등장했습니다. 많은 개발자가 이미 Git, 빌드 및 테스트를 구동하는 방식과 자연스럽게 짝을 이루며 많은 팀의 일상적인 워크플로의 일부가 되었습니다. 네이티브 IDE 통합을 사용할 수 없는 원격 서버나 환경에 AI를 가져오는 가장 신뢰할 수 있는 방법입니다. 터미널이 있는 곳이면 어디든 Bob을 가질 수 있습니다.
  • 결정론적에서 적응형 자동화로: Bob Shell은 예약된 작업 및 CI/CD 파이프라인의 배포 스크립트와 같은 비대화형 세션에서 빛을 발합니다. 오늘날 스크립트가 결정론적 도구로 셸 아웃하는 곳이면 어디든 주변 리포지토리의 전체 컨텍스트를 가진 Bob으로 셸 아웃할 수 있으며, 반대편에서 나오는 자동화는 고정 파이프라인보다 더 적응적입니다.

CI에서 비대화형으로 Bob을 실행하면서 배운 것에 대한 후속 게시물을 게시할 것입니다. PR 요약, 위험 플래그 지정 및 기존 자동화에 대한 통합을 포함하여 실제로 잘 작동하는 패턴입니다.

2. 리포지토리를 Bob 준비 상태로 만들기

Bob이 최고의 작업을 생산하는 리포지토리는 몇 가지 공통된 특성을 공유합니다. 그 중 어느 것도 AI 전용이 아닙니다. 모든 개발자가 작업하기에 즐거운 리포지토리를 만드는 것과 동일한 것들이지만, 각각은 Bob에게 작업할 더 많은 것을 제공합니다.

빠르고 신뢰할 수 있는 테스트. npm test(또는 동등한 것)가 5분이 걸리거나 간헐적으로 실패하면 반복 루프가 기어가는 속도로 느려지고 피드백 신호가 저하됩니다. 1분 미만의 테스트는 모든 개발자에게 승수입니다. 타이트한 사이클로 작업하는 AI 어시스턴트에게는 필수적입니다.

문서화된 빌드 및 테스트 명령. Makefile, package.json의 최상위 스크립트 섹션 또는 README 블록 — Bob이 "이것을 어떻게 실행합니까"를 찾을 수 있는 곳. 그것이 없으면 Bob은 추론해야 하며 추론은 실수가 들어가는 곳입니다.

실행 가능한 스타일. 저장 시 또는 CI에서 실행되는 린터 및 포매터. Bob은 이것들로부터 규칙을 가져옵니다. 명시적이고 기계적으로 확인 가능한 규칙은 매번 암시적 규칙을 능가합니다.

리포지토리 루트의 agents.md. 프로젝트 구조, 주요 파일, 코딩 표준, 해야 할 일과 하지 말아야 할 일. 이것은 AI 지원을 위해 추가할 수 있는 가장 높은 레버리지 파일입니다. 그것에 대해 생각하는 올바른 방법은 신입 사원이 아닌 LLM을 위해 작성된 CONTRIBUTING.md입니다.

코드와 함께 마크다운의 아키텍처 문서. 짧은 문서도 도움이 됩니다. 모듈과 그 경계를 설명하는 docs/architecture.md를 사용하면 Bob이 가져오기에서 설계를 다시 도출하지 않고 "이것은 어디로 가나요?"에 답할 수 있습니다.

도중에 배운 몇 가지:

  • 큰 규칙 파일은 신호를 줄입니다. 몇 백 줄을 넘어서면 모델 성능이 저하됩니다. 모든 것을 하나의 파일에 집중하는 대신 영역별로 규칙을 분할하세요. 리포지토리 루트의 agents.md, 패키지당 범위가 지정된 readme.md.
  • 엔지니어링을 복합하세요. 작업을 완료하면 Bob에게 관련 학습을 규칙 파일이나 스킬로 다시 증류하도록 요청하세요. 사용하면서 리포지토리가 더 생산적인 환경이 됩니다.
  • 반복하고 원샷하지 마세요. 올바른 변경 사항을 일관되게 착륙시키는 다중 턴 대화는 80%를 착륙시키는 단일 긴 프롬프트를 능가합니다.

3. 보안 및 제어

Bob에는 단일 가드레일이 모든 작업을 수행하는 대신 함께 작동하는 여러 보호 계층이 있습니다. 첫 번째 게시물에 적합한 짧은 버전:

  • 모든 작업을 수동으로 승인하거나 워크플로를 신뢰하면 도구 클래스(읽기 전용 대 쓰기)별로 자동 승인합니다.
  • .bobignore는 Bob이 읽어서는 안 되는 파일(자격 증명, 생성된 아티팩트, 민감한 것)에서 Bob을 멀리 유지합니다.
  • 사용자 정의 규칙은 개발자에게 적용하는 것과 같은 방식으로 Bob에 코딩 표준을 적용합니다.
  • 자동 체크포인트는 원치 않는 변경에서 복구를 원클릭 작업으로 만듭니다.
  • 프롬프트는 학습 데이터로 사용되지 않습니다!

특히 자동 승인은 신중하게 고려할 가치가 있습니다. 이것은 체크포인트 사이에 Bob이 당신과 함께 할 수 있는 양에 대한 주요 제어 중 하나이며, 그것을 넓히는 것은 생산성 향상이지만 그 봉투 안에 무엇이 들어가고 무엇이 들어가지 않는지 결정하는 데 조금 더 많은 것을 요구합니다. 대부분의 개발자에게 합리적인 기본값은 읽기 전용 도구를 자동 승인하고, 적어도 처음 몇 주 동안은 쓰기 작업을 수동 승인으로 두고, 셸 명령을 실행하거나 로컬 작업 트리를 넘어 시스템에 도달하는 모든 것에 대해 특히 신중하게 고려하는 것입니다. 목록의 다른 제어(.bobignore, 사용자 정의 규칙, 체크포인트)는 자동 승인을 대체하는 대신 구성하도록 설계되었습니다.

4. 시작하기

  1. 웹사이트에서 IBM Bob을 설치하거나 선택한 터미널을 통해 Bob Shell을 설치하세요.
  2. 모범 사례 가이드를 검토하고 보안 지침을 참조하세요.
  3. 실제 작업으로 시작하세요 — Bob이 실제 문제를 해결하는 데 도움을 줄 때 가장 잘 배웁니다.

링크