나는 클라우드 코딩 에이전트(cloud coding agent)가 여전히 페어 프로그래밍(pair programming)일 것이라고 생각했다. 즉, 그저 다른 어딘가에서 실행될 뿐, 동일한 로컬 대화가 이어질 것이라고 믿었다.

나를 놀라게 한 첫 번째 요소는 코드가 아니었다. 실행 과정에서 내가 거의 필요하지 않았다는 점이었다.

그 증거는 실제 모노레포(monorepo)를 대상으로 진행한 첫 번째 Cursor Cloud Agent의 실행 결과다. 처음에는 단순한 Cursor의 기능처럼 보였던 것이, 알고 보니 완전히 다른 실행 모델(execution model)임이 드러났다. 실행은 새로운 환경에서 시작되어 온보딩(onboarding) 작업을 수행하고 증거를 남겼다. 유용하고, 자율적이며, 로컬 세션에서 내가 이미 알고 있던 거의 모든 것들이 결여되어 있었다.

잘못된 그림

로컬 Cursor에서는 이미 계획 스레드(planning thread)를 가지고 있었다. 조사 내용, 트레이드오프(tradeoffs), 그리고 해당 세션에서 이미 인증을 마친 도구들(Notion MCP 포함)이 준비되어 있었다. 내가 Cloud Agent를 Express API, Vite 프론트엔드, Playwright E2E, 그리고 CI를 갖춘 npm-workspaces 모노레포인 Codenames AI로 지정했을 때, 나는 연속성을 기대했다. 동일한 결정, 동일한 인증, 동일한 미완성된 추론 과정이 그저 원격으로 이루어질 것이라고 생각했다.

하지만 그 가정은 첫 한 시간 만에 무너졌다.

첫 번째 실행이 실제로 수행한 일

작업 자체는 작았다. 저장소를 향후 Cloud Agent 실행이 가능하도록 준비하고, AGENTS.md에 명확하지 않은 설정법을 문서화하는 것이었다. 이를 완료하려면 전체 실행 환경(execution environment)을 구축하고 증명해야 했다.

그 프롬프트 이후, 에이전트는 내가 루프(loop) 안에 앉아 있지 않아도 스스로 작동했다. 에이전트는 저장소를 클론(clone)하고, 의존성(dependencies)을 설치하고, 린트(lint), 타입 체크(typecheck), 빌드(build), 테스트(tests)를 실행했다. 또한 Playwright 브라우저를 설치하고 E2E 스위트(suite)를 실행했으며, UI에서 솔로 턴(Solo turn, 1인용 연습 게임)을 플레이하고, 스크린샷과 워크스루(walkthrough) 영상을 캡처한 뒤 풀 리퀘스트(pull request)를 생성했다.

해당 풀 리퀘스트(pull request)는 AGENTS.md 노트를 추가하고, UI에서의 hello-world Solo 턴을 포함하여 클린 VM(clean VM)으로부터의 검증 흔적(verification trail)을 기록했다. 변경 사항(change set)은 작았다. 하지만 그 _행동(behavior)_은 거대했다. 자율적인 환경 설정과 더불어, 로컬 에이전트 워크플로(workflows)가 좀처럼 남기지 않는 결과물(artifacts)들을 생성해냈기 때문이다.

예상치 못했던 두 가지 실패

로컬 추론(Local reasoning)은 노트북에 머물러 있었다. Cursor에서 내가 이미 내렸던 결정들(무엇이 중요한지, 무엇을 건너뛸지, 작업을 어떻게 프레이밍할지)은 그 새로운 클라우드 작업에 포함되어 있지 않았다. 그러한 판단에 의존하는 모든 것은 다시 확립되어야 했다. 에이전트는 레포지토리(repo)와 CI에 접근할 수 있었다. 하지만 내가 이미 스스로와 나누었던 논거(argument)를 상속받을 수는 없었다. 다른 Cursor 플로(flows)는 대화를 클라우드로 옮길 수 있지만, 이 새로운 작업은 그 뒤에 있는 로컬 프레이밍(local framing)과 함께 도착하지 않았다.

도구 인증(Tool auth)이 따라오지 않았다. Notion MCP는 클라우드 실행을 위한 별도의 인증을 거친 후에야 작동했다. 로컬 Cursor 접근 권한은 세션 연속성(session continuity)을 보장하지 않았다. "클라우드가 MCP를 사용할 수 있다"는 것과 "클라우드가 이미 나의 MCP 세션을 가지고 있다"는 것은 서로 다른 주장임이 드러났다.

왜 채용하는 느낌이었는가

비동기 인수인계(Async handoff)에는 적합했다. 하지만 클라우드에서의 개방형 설계 토론(Open-ended design debate)에는 적합하지 않았다. 실행(run)은 제품을 파악하기 위한 원격 페어(remote pair)가 아니라, 경계가 정해진 작업(bounded job)과 완료 정의(definition of done)를 원했다.

절반쯤 끝난 Slack 스레드를 전달하는 것만으로는 누군가를 온보딩(onboard)할 수 없다. 당신은 그들에게 머신, 체크리스트, 그리고 브리프(brief)를 주어야 한다. 자율성이 높아질수록 맥락(context)의 부재는 더 큰 타격을 준다. 왜냐하면 새로운 클린 환경 작업은 당신의 로컬 추론 없이 시작되기 때문이다.

에이전트가 익숙하지 않은 체크아웃(checkout) 상태에 놓였을 때 AGENTS.md는 중요해졌다: 명확하지 않은 Node 버전 하한선, 로컬 실행을 위한 선택적 .env, E2E 설정, 폰트에 민감한 시각적 스냅샷(visual snapshots) 등 말이다. 파일 자체가 필요한 것이 아니다. 핵심은 이것이 실행 작업자(execution worker)를 위한 브리핑 자료라는 점이지, 내 노트북에서 이루어진 계획 대화(planning conversation)를 대체하는 것이 아니라는 점이다.

왜 또 다른 로컬 워크트리(worktree)가 아닌가?

두 번째 로컬 git 워크트리(worktree) 또한 병렬 실행(parallel execution)을 제공할 수 있으며, 한 가지 분명한 장점이 있습니다. 바로 제가 이미 가지고 있는 도구(tools), 자격 증명(credentials), 캐시(caches), 그리고 머신 상태(machine state)를 재사용할 수 있다는 점입니다. 단일 개발자에게는 이것이 핸드오프(handoff) 비용을 낮춰줄 수 있습니다.

하지만 이는 제가 또 다른 로컬 워크스페이스(local workspace)를 관리하게 만들며, 결과물을 제 머신에 종속된 상태로 유지합니다. 즉, 추가적인 체크아웃(checkouts), 로컬 프로세스(local processes), 포트 충돌(port conflicts), 그리고 결과물이 오직 제 환경에서만 작동할 위험이 따릅니다. 팀 동료는 제 노트북의 상태를 그대로 물려받지 않는 한, 해당 실행 과정을 정확하게 재현(reproduce)할 수 없습니다.

클라우드 에이전트(cloud agent)는 상속(inheritance)받는 요소가 더 적은 상태에서 시작하므로, 핸드오프(handoff)가 더 중요해집니다. 그 대가로 저는 병렬화하기 쉽고 "내 머신에서는 작동한다(works on my machine)"는 위험이 적은 격리된 작업(isolated task)을 얻게 되며, 또 다른 로컬 워크스페이스를 계속 지켜보지 않고도 원격으로 작업을 시작하거나 모니터링할 수 있습니다.

Cursor는 제가 그 경계를 명확하게 마주한 곳이었습니다. 클린 환경(clean environments), 온보딩(onboarding), 그리고 노트북 상태의 부재는 원격 서버로 결과물을 배포(shipping)해 온 경험이 있다면 새로운 교훈이 아닙니다. 새로웠던 점은 오래된 시스템 설계 개념이 AI 코딩 워크플로(workflow) 내부에서 다시 나타나는 것을 보는 것이었습니다. 유용한 대응책은 세션의 원격 연장이 아니라, 명시적인 핸드오프(handoff)입니다. 코딩 에이전트가 독립적으로 실행 가능해지는 곳이라면 어디든 동일한 트레이드오프(trade-off)가 나타날 것으로 예상합니다. 그 경계는 아키텍처(architectural)적인 것입니다.

각 측면이 적합한 위치

로컬 워크스페이스(Local workspace)
(계획(planning), 판단(judgment), 브리프(brief))
        ↓
...

그 첫 번째 실행은 몇 가지 질문을 남겼습니다. 이후의 실행들이 온보딩(onboarding) 작업을 재사용할 것인지, 그리고 이 패턴이 신중하게 경계가 정해진 하나의 작업을 넘어 어떻게 유지될 것인지에 대한 질문입니다.

돌이켜보면, 저는 제한된 실행 (bounded execution)을 위해 클라우드 에이전트 (Cloud Agents)를 계속 선택해 왔습니다. 즉, 유지보수 루프 (의존성 업그레이드 포함), 타겟팅된 버그 수정, 그리고 리뷰 결과 추적이나 특정 질문 검증과 같은 집중적인 조사 작업들입니다. 이는 초기 실행 비용이 사라졌기 때문이 아니라, 격리 (isolation)와 공유된 작업 모델 (shared task model)이 조정 오버헤드 (coordination overhead)를 줄여주었기 때문입니다. 실행 결과는 여전히 검토 가능한 흔적 (스크린샷, 비디오, PR)을 남기며, 이는 다른 엔지니어가 작업을 넘겨줄 때 기대하는 것과 동일한 종류의 데모 증거입니다.

지속적인 놀라움은 명확한 경계 (clean boundary)가 단순히 제약 사항일 뿐만 아니라, 모델을 확장 가능하게 만드는 기능 (feature)이기도 하다는 점이었습니다.

핵심 요약 (Takeaway): 클라우드 에이전트는 격리와 확장 가능한 위임 (scalable delegation)을 얻는 대신, 상속된 로컬 컨텍스트 (local context)의 일부를 포기합니다. 기존 세션의 원격 연장선처럼 다루지 말고, 신입 사원에게 업무를 지시하듯 브리핑 (brief) 하세요. 에이전트에게 필요한 컨텍스트는 의도적으로 그 경계를 넘도록 전달되어야 합니다.

이러한 워크플로우 실험의 기반이 된 프로젝트를 확인하고 싶다면, Codenames AI를 살펴보세요.