Durable Canvas와 Bugbot이 바꾸는 에이전트 코딩의 실행 구조

긴 작업에서 사라지는 것은 코드보다 계획이다

AI 코딩 에이전트가 자동완성을 넘어 여러 단계의 엔지니어링 작업을 맡기 시작하면서, IDE 설계의 중심도 달라졌다. Cursor 3.3의 Durable Canvas와 Bugbot Autofix는 기능 목록보다 작업을 분해하고, 실행 순서를 관리하며, 수정 결과를 검증하는 방식에서 의미가 있다.

기존 보조 도구의 계획과 리뷰 결과는 대개 채팅 기록에 머물렀다. 파일을 옮겨 다니거나 세션을 닫으면 에이전트가 세운 계획과 작업 상태를 다시 복원해야 했다. 마이그레이션, 대규모 리팩터링, 여러 서비스에 걸친 변경처럼 하위 작업이 수십 개로 늘어나는 상황에서는 이 재구성 자체가 부담이 된다. 복잡한 소프트웨어 작업에서 컨텍스트 전환 비용이 생산적 작업 시간의 23-40%를 소비한다는 연구도 있다.

Durable Canvas가 겨냥하는 지점은 계획의 영속성이다. 채팅 메시지 대신 커밋 가능한 구조화된 아티팩트에 파일 경로, 코드 참조, 의존성, 실행 순서를 기록한다. 세션이 바뀌어도 작업 맥락이 이어질 수 있는 형태다.

트리보다 의존성 그래프로 보는 작업

목표를 작은 작업으로 나누는 방식에는 계층적 분해와 의존성 기반 분해가 있다.

계층적 분해는 최상위 목표를 하위 목표와 원자적 태스크로 재귀적으로 쪼개는 트리 구조다. 구현과 진행 상태 파악이 단순한 대신, 실제 코드베이스의 복잡한 선후 관계나 병렬 실행 기회를 충분히 표현하기 어렵다.

의존성 기반 분해는 태스크의 선행 조건과 결과물을 방향성 그래프(DAG)에 담는다. 데이터베이스 스키마 변경 뒤에 마이그레이션 스크립트를 작성해야 하는 관계, API 엔드포인트 수정과 프론트엔드 컴포넌트 업데이트를 서로 독립적으로 실행할 수 있는 관계를 모두 명시할 수 있다.

Cursor의 Durable Canvas는 이 의존성 기반 접근을 사용한다. 2026년 1월에 발표된 Task-Decoupled Planning(TDP) 프레임워크와 유사하게, 슈퍼바이저 에이전트가 전체 목표를 그래프로 나누고 서브에이전트가 독립 태스크를 병렬 처리하는 구도다.

⤢✕

그래프를 만드는 과정은 코드베이스의 심볼 관계를 먼저 파악하는 데서 시작한다. 저장소를 AST(Abstract Syntax Tree)로 파싱해 호출, 임포트, 타입 의존성을 연결하고, Cursor에서는 @Codebase 인덱싱이 이 심볼 그래프를 유지한다.

그 다음 특정 파일이나 함수를 바꿨을 때 영향을 받는 범위를 전이적으로 계산한다. 공유 유틸리티 함수의 시그니처가 바뀌면 직접 호출하는 파일인 1-hop뿐 아니라, 그 파일을 임포트하는 2-hop까지 의존성 체인이 이어질 수 있다.

각 태스크의 입력과 출력을 정의한 뒤, 한 태스크의 출력이 다른 태스크의 입력과 겹치면 의존성 엣지를 만든다. 마지막으로 DAG를 위상 정렬해 실행 순서를 결정한다. 같은 레이어의 태스크는 선행 조건을 공유하지 않으므로 병렬 실행 대상이 된다.

병렬 빌드 전에 확인할 충돌 조건

Cursor 3.3의 Build in Parallel은 위상 정렬에서 같은 레이어에 놓인 독립 태스크를 찾아 비동기 서브에이전트에 넘긴다. 다만 같은 레이어라는 사실만으로 안전한 병렬 처리가 보장되지는 않는다.

두 태스크가 같은 파일을 수정하면 파일 쓰기 충돌이 생기므로 직렬화해야 한다. 한 태스크가 읽기만 하고 다른 태스크가 쓰는 경우에는 읽기 작업을 먼저 실행한다.

심볼 상태도 순서를 강제한다. 태스크 A가 함수 foo()를 정의하고 태스크 B가 foo() 호출로 코드를 바꾼다면, A가 먼저 완료되어야 한다. 또한 각 결과를 독립 테스트로 검증할 수 있어야 병렬 처리 이후의 통합 검증 부담을 제어할 수 있다.

계획 파일을 실행 상태와 함께 남기는 방식

Durable Canvas의 계획 모드는 파일 경로, 코드 참조, 할 일 목록, 의존성 표시를 담은 편집 가능한 마크다운 계획을 만든다. 이를 저장소에 두면 팀과 공유할 수 있고 브랜치 이동 뒤에도 상태가 남으며 git blame으로 계획 변경 이력도 추적할 수 있다.

태스크 노드는 pending, in_progress, completed, failed, blocked 상태를 가진다. 에이전트 실행 결과가 이 상태를 자동 갱신한다. 장시간 작업에서는 체크포인트를 남겨 네트워크 오류나 프로세스 종료 뒤에도 중간 지점부터 다시 시작할 수 있다.

상태 변경은 전체 계획을 매번 다시 만들기보다 delta로 반영된다. 대규모 프로젝트에서 50개 태스크 가운데 1개가 끝날 때마다 전체 계획을 재파싱하는 방식은 비효율적이기 때문이다.

⤢✕

여기서 중요한 문제는 비동기 실행과 화면에 보이는 상태가 어긋나지 않도록 하는 일이다. 서브에이전트가 파일을 변경할 때 캔버스에 이벤트를 발행하고, 캔버스는 해당 태스크의 상태를 갱신한다. 선행 조건이 충족된 후속 태스크는 큐에 들어가며 실행 흐름이 이어진다.

Bugbot이 버그 수정에 접근하는 순서

PR 리뷰에서 발견된 문제는 실제 실패 테스트가 없는 정적 분석 결과일 수 있다. “이 코드는 null을 반환할 수 있다”는 지적만으로는 수정의 정확성을 보장하기 어렵다. Bugbot의 자율 수정 흐름에서 가장 까다로운 구간이 재현 단계인 이유다.

먼저 변경된 코드 경로를 실행하는 기존 테스트를 찾아 실패 여부를 확인한다. 이미 실패하는 테스트가 있으면 그 자체가 재현 근거가 된다. 기존 테스트가 없거나 모두 통과하면, 퍼징과 경계값 분석을 조합해 null 입력, 빈 컬렉션, 오버플로우 조건 등 버그를 유발하는 최소 입력 조건을 생성한다.

Bugbot Autofix는 독립 가상 머신에서 서브에이전트를 실행한다. 재현 작업이 개발 환경에 영향을 주지 않고, 여러 버그를 서로 격리해 동시에 다룰 수 있도록 하기 위한 구조다.

원인 분석에서는 크로스파일 데이터 플로우 추적과 심볼릭 실행(Symbolic Execution)을 사용한다. 전자는 값이나 객체가 코드베이스에서 생성·변환·전달·소비되는 경로를 따라간다. null 포인터 오류라면 값이 null이 될 수 있는 최초 지점을 역방향으로 찾아 근본 원인을 추적한다.

심볼릭 실행과 경로 분석은 코드를 실제로 실행하지 않고 가능한 경로를 열거한다. 이를 통해 입력 x가 음수이고 배열이 비어 있을 때 인덱스 오류가 발생한다는 식의 조건을 도출한다. Bugbot은 2025년 가을, 고정된 단계를 순차 실행하던 파이프라인 구조에서 분석 중 발견한 단서에 따라 도구 호출과 조사 방향을 바꾸는 완전 에이전틱 설계로 전환했다.

작은 diff를 선택하고 테스트로 되돌아가는 루프

원인을 찾은 뒤 수정 코드를 만들 때 Bugbot이 따르는 원칙은 변경 최소화(Minimal Diff)다. 이는 단순히 적게 고치라는 조언이 아니다. 불필요한 변경이 섞이면 리뷰어가 수정 범위를 파악하기 어려워지고, 의도하지 않은 사이드이펙트 가능성이 커지며, 회귀가 발생했을 때 원인 추적도 복잡해진다.

⤢✕

매개변수 검증, null 체크, 경계 조건 처리를 추가할 때도 기존 코드 스타일을 따른다. 코드베이스가 Optional.ofNullable() 패턴을 사용한다면 그 패턴을 적용하고, if (x != null) 검사를 선호한다면 같은 방식을 택한다.

수정 뒤에는 버그 재현 케이스만이 아니라 전체 테스트 스위트를 실행한다. 재현 케이스와 기존 테스트가 모두 통과하면 수정이 완료된다. 기존 테스트가 실패하면 다른 동작을 손상시킨 것이므로 수정 범위를 다시 검토하고 새 후보를 만든다.

이 검증 루프는 Bugbot의 76% 해결률을 뒷받침하는 구조다. Bugbot이 제안한 Autofix 가운데 35%가 개발자 개입 없이 직접 병합된다는 통계도 검증 단계의 역할을 보여준다.

계획을 보존하는 IDE와 플랫폼 중심 워크플로우의 차이

설계 차원	Cursor Durable Canvas	GitHub Copilot Workspace
계획 표현 형식	저장소에 커밋 가능한 구조화된 마크다운 아티팩트	웹 기반 이슈-to-코드 워크플로우
태스크 분해 방식	의존성 DAG 기반, 병렬화 자동 식별	선형 단계별 계획, 병렬 실행 제한적
에이전트 실행 환경	로컬 + 클라우드 서브에이전트 하이브리드	GitHub Actions 기반 클라우드 전용
코드베이스 인덱싱	전체 저장소 심볼 그래프, `@Codebase` 참조	오픈 탭 + 설정된 파일 세트
계획 영속성	세션 간 완전 유지, git 추적 가능	이슈 연결 기반, 세션 단절 시 재구성 필요
멀티 저장소	3.3에서 multi-repo 클라우드 에이전트 지원	GitHub 조직 범위 지원
통합 환경	독립 에디터(VS Code 기반) + JetBrains 클라이언트	GitHub 생태계 네이티브(VS Code, JetBrains, Neovim 플러그인)

Copilot Workspace는 GitHub 이슈에서 계획을 만들고, PR을 작성한 뒤 GitHub Actions로 검증하는 흐름에 맞춰져 있다. Cursor Durable Canvas는 계획 자체를 저장소에 두므로 특정 플랫폼에 묶이지 않고 어떤 git 호스팅에서도 사용할 수 있다는 차이가 있다.

JetBrains AI Assistant는 별도 계획 아티팩트보다 IDE의 기존 능력을 활용하는 쪽에 가깝다. PSI(Program Structure Interface)를 통해 코드 구조를 해석하고, 리팩터링·코드 탐색·의존성 분석 기능과 연결해 변경의 안전성을 확보한다. 2026년 기준으로 Cursor Canvas 수준의 독립 계획 아티팩트는 제공하지 않지만, IDE 내 태스크 리스트, TODO 통합, 네이티브 코드 액션 연동으로 계획 실행을 돕는다. JetBrains를 표준 도구로 쓰는 엔터프라이즈 팀에는 학습 비용을 낮출 수 있는 방식이다.

AI IDE가 보여주는 실행 인터페이스의 변화

AI IDE의 UI는 명령어와 채팅 중심 인터페이스에서 시각적 캔버스로 옮겨가고 있다. Durable Canvas는 작업 계획을 화면에 표시하고, 개발자가 특정 태스크를 직접 수정하거나 다시 실행할 수 있는 상호작용을 제공한다.

에이전트가 하나에서 여러 개로 늘어나면 모니터링 화면의 역할도 커진다. 어떤 에이전트가 어느 파일에서 무엇을 하고 있는지 파악할 수 있어야 병렬 실행을 통제할 수 있다. Cursor 3.3의 진행 상태 추적 뷰는 이 요구를 다룬다.

반응형 코드 생성에서 예측적 계획으로의 변화도 눈에 띈다. 복잡한 작업은 전체 계획을 먼저 만들고 개발자의 승인을 받은 후 실행하는 방식으로 바뀌고 있다. 에이전트 행동을 예상 가능하게 만들고 개발자 신뢰를 확보하기 위한 패턴이다.

에이전트 실행 런타임으로 확장되는 개발 환경

2026년 AI IDE는 개발자가 직접 코드를 작성하는 편집기에서 에이전트가 작업을 수행하는 런타임으로 재정의되고 있다.

Cursor 3.3에서는 팀이 에이전트용 개발 환경 설정 도구를 구성할 수 있다. 에이전트가 새 태스크를 시작할 때 필요한 패키지 설치, 환경 변수 설정, 서비스 시작을 자동 처리하는 방식이다. 이는 동시에 수십 개 에이전트가 독립 태스크를 처리하는 agent fleet 구조를 뒷받침하는 기반이 된다.

마이크로서비스 환경에서는 하나의 기능 변경이 여러 저장소를 건드린다. Cursor 3.3의 멀티 저장소 클라우드 에이전트는 프론트엔드, 백엔드, 공유 라이브러리 변경을 함께 다루고 일관성을 조율하는 요구를 반영한다.

PR 리뷰도 생성·리뷰·병합 흐름을 한 인터페이스로 모으는 방향이다. Bugbot이 버그를 찾고 Autofix가 수정안을 제시하면, 개발자는 리뷰 쓰레드, 커밋 이력, 변경 diff를 같은 화면에서 검토한다. 별도 플랫폼으로 옮겨가며 생기던 컨텍스트 전환을 줄이려는 설계다.

Cursor Marketplace의 Canvas 스킬은 Docs Canvas, Security Review Canvas, Deployment Canvas처럼 도메인별 워크플로우로 확장되고 있다. 팀이 자체 Canvas 스킬을 작성해 업무 흐름을 자동화하게 되면, AI IDE는 단순한 도구를 넘어 조직의 지식과 프로세스를 담는 플랫폼이 된다.

Cursor 3.3 Durable Canvas와 Bugbot Autofix가 보여주는 핵심은 코드 생성 자체가 아니라 그 주변의 실행 구조다. 태스크 분해, 의존성 그래프, 변경 최소화, 검증 루프가 에이전트 코딩의 신뢰성을 좌우한다. 월 200만 건의 PR을 처리하고 76% 해결률을 달성한다는 데이터는 이 접근이 초기 실험을 넘어 프로덕션 단계에서 다뤄지고 있음을 보여준다.