소프트웨어 개발의 모든 중요한 발전은 팀이 의도를 표현하는 방식을 바꾸어 왔습니다. 워터폴은 방향 전환이 느렸기 때문에 방대한 문서에 의존했습니다. 애자일은 반복 비용이 낮고 팀이 움직이면서 배웠기 때문에 문서 작업을 줄였습니다.

에이전트에는 고유한 계획 중 방식이 필요합니다. 의도를 너무 이르게 고정해 버리는 단계별 게이트 프로세스 대신, 사전에 방향을 제시하면서도 실제 작업에 기반을 두고 살아 움직이는 계획 중 접근 방식이 더 큰 효과를 냅니다.

#에이전트가 효과적으로 일하기 위한 조건

에이전트는 문제를 명확한 언어로 풀어 쓸 수 있을 때 흔들리지 않고 일을 수행합니다. 질문을 던지고, 전제를 걷어 내며, 코드를 건드리기 전에 앞으로의 경로를 개략적으로 설계합니다. 학습 과정에서 이런 행동이 반복적으로 강화됩니다.

계획이 명시적이고 유연할수록, 에이전트는 방향을 잃지 않고 더 긴 작업 단위를 맡을 수 있습니다. 그래서 에이전트를 위한 계획은 고정된 스펙이 아니라 반복적으로 수정·보완할 수 있는 작업 표면 위에서 이뤄질 때 강점을 발휘합니다. 계획 자체가 루프의 일부가 됩니다.

에이전트가 제약 조건을 발견하면 계획을 갱신합니다. 사용자가 의도를 더 정교하게 다듬으면 계획도 다시 바뀝니다. 이러한 리듬은 이전 세대에서 이어져 내려온 분절된 계획 단계보다 에이전트 중심 개발의 결에 훨씬 더 잘 맞습니다.

#Cursor가 에이전트 지능을 위해 플래닝을 설계하는 방식

우리는 소프트웨어 개발 팀이 에이전트를 활용해 가장 많은 일을 해내는 방식을 이해한 것을 바탕으로 Plan Mode를 만들었습니다. 에이전트 기반 개발을 위해 특별히 설계된 강력한 범용 플래닝 방식입니다.

Plan Mode는 에이전트가 질문을 하고, 코드베이스를 스캔하고, 경로를 제안한 뒤 사용자와 함께 이를 다듬을 수 있는 공간을 제공합니다. 짧은 작업에는 가볍게 사용할 수도 있고, 더 장기간 유지되는 표준 아티팩트로 발전시킬 수도 있습니다. 이 프로세스는 다섯 단계로 이루어집니다:

1. 질문을 통한 요구사항 명확화. 에이전트는 모호함을 제거하기 위해 질문을 합니다. 애자일 팀은 이를 빠른 질의응답으로 처리합니다. Spec-driven Development(SDD)는 이를 공식 요구사항 단계로 옮깁니다. Plan Mode는 모호성을 줄인다는 같은 목표를 유지하되, 에이전트가 직접 질문을 주도하게 만들어 에이전트 중심 작업의 속도에 더 잘 맞춥니다.

2. 리서치. 에이전트는 상호작용이 필요한 지점을 파악하기 위해 코드베이스를 스캔합니다. 예전 워크플로에서는 이를 별도의 설계 단계로 취급했습니다. Plan Mode는 이 단계를 에이전트의 추론 과정 안에 바로 통합합니다.

3. 플랜 초안 작성. 에이전트는 변경 사항과 이를 구현하기 위한 단계를 설명하는, 수정 가능한 플랜 파일을 작성합니다. SDD에서는 이를 고정된 스펙으로 얼립니다. 애자일에서는 문서가 자주 실제와 어긋나도록 방치되곤 합니다. Plan Mode는 플랜을 살아 있는 상태로 유지해, 새로운 정보가 등장할 때마다 여러분과 에이전트가 함께 이를 계속 다듬을 수 있게 합니다.

4. 작업 실행. 에이전트는 단계를 하나씩 수행하며 태스크를 완료해 나갑니다. 전통적인 방식은 플래닝과 구현을 분리합니다. Plan Mode는 이를 하나의 프로세스로 취급해 플랜이 상황에 맞게 적응하도록 합니다.

5. 플랜 수정. 일이 계획에서 벗어날 때, 플랜은 다시 시작하는 기준점이 됩니다. 후속 프롬프트로 행동을 임시 봉합하는 대신, 팀은 작업을 되돌리고 플랜을 개선한 뒤 다시 실행할 수 있습니다. 이렇게 하면 의도가 명시적으로 유지되고, 실행 도중 에이전트를 수동으로 조정하는 것보다 더 깔끔한 결과를 얻을 수 있습니다.

플랜은 .cursor/plans/ 안의 버전 관리되는 파일로 워크스페이스에 저장됩니다. 이 파일들은 코드와 나란히 위치하며, 다른 프로젝트 아티팩트와 마찬가지로 git으로 추적됩니다. 무엇이 언제 변경되었는지 확인할 수 있고, 필요하다면 되돌릴 수도 있습니다.

#유연한 계획 프리미티브

팀마다 업무 목표를 정리하는 방식이 다릅니다. 어떤 팀은 정형화된 요구 사항에 의존하고, 다른 팀은 변화하는 디자인이나 단계별 워크플로를 사용합니다. 계획 프레임워크는 각 팀이 선호하는 업무 방식을 수용할 수 있을 만큼 유연해야 합니다.

이 유연성은 지금처럼 환경이 빠르게 변할수록 더욱 중요해집니다. 수십 년 동안은 워터폴이 계획을 정의했고, 그 뒤 또 다른 수십 년 동안은 애자일이 팀을 형성해 왔습니다. 에이전트 지능은 훨씬 더 짧은 주기로 발전하고 있습니다. 고정된 프로세스는 금방 낡아질 수밖에 없습니다.

그래서 우리는 원하는 대로 변형할 수 있는 단순한 프리미티브를 중심으로 접근 방식을 설계했습니다. 에이전트 Skills를 사용해 팀이 선호하는 계획 구조를 정의할 수 있고, 에이전트는 그 구조를 일관되게 따릅니다.

어떤 팀은 더 정형화된 스펙 중심 워크플로를 에이전트 Skill로 구성합니다. 다른 팀은 작업이 진행되면서 함께 진화하는, 더 가벼운 계획을 만들어 내는 스킬을 정의합니다. 계획이 고정 프로세스가 아니라 스킬에 의해 형성되기 때문에, 두 접근 방식 모두 자연스럽게 Plan Mode 안에 들어맞습니다.

핵심은 우리의 계획 방식이 과거 방식과 호환된다는 사실이 아닙니다(물론 호환되지만요). 중요한 것은 이 방식이 미래를 향하고 있다는 점입니다. 소수의 공통 프리미티브에 기반한 프레임워크는, 에이전트가 과거의 계획 방식이 예상하지 못했던 업무까지 맡게 되는 상황에서도 팀이 자신의 방법론을 계속 발전시킬 수 있는 여지를 제공합니다.

#앞으로의 전망

에이전트가 처리할 수 있는 작업의 규모와 복잡성은 빠르게 커지고 있습니다. Plan Mode는 에이전트를 염두에 두고 단순한 기본 프리미티브 위에 설계되었기 때문에 이러한 발전 속도를 따라갈 수 있습니다.

우리는 extended runs 동안 하나의 프로젝트에 지속적으로 참여하고, 세션 간 컨텍스트를 유지하며, 병렬 작업이 유리한 경우 하위 에이전트를 생성하는 에이전트를 테스트하고 있습니다. 곧 여러 개발자가 동일한 세션에 함께 참여하여 계획이 어떻게 발전하는지 확인하고, 프로젝트가 전개되는 동안 에이전트를 직접 이끌 수 있게 될 것입니다. 우리의 목표는 에이전트가 수행할 수 있는 작업 범위를 넓히면서도, 소프트웨어 팀이 계획 수립에서 항상 원해 온 핵심 요소인 명확성, 가시성, 그리고 사용자 제어권을 그대로 유지하는 것입니다.