에이전트를 '돌리는 것'과 '위임하는 것'은 다른 문제다
Cursor Cloud Agent를 처음 실행했을 때 받은 충격을 한 개발자가 dev.to에 솔직하게 기록했다. 그는 로컬 Cursor 세션에서 이미 충분히 논의한 맥락—기술적 트레이드오프, 인증된 Notion MCP, 절반쯤 완성된 판단들—이 클라우드 에이전트에 그대로 이어질 거라고 기대했다. 그 기대는 첫 한 시간 만에 무너졌다.
클라우드 에이전트는 완전히 새로운 환경에서 시작했다. 로컬 세션의 판단은 전달되지 않았고, MCP 인증도 별도로 다시 해야 했다. 에이전트는 repo를 클론하고, 의존성을 설치하고, lint·typecheck·빌드·테스트를 돌리고, Playwright E2E를 실행하고, UI에서 실제 게임 턴을 플레이하고, 스크린샷과 영상까지 남긴 뒤 PR을 열었다. 결과물 자체는 유용했다. 하지만 그것은 '페어 프로그래밍의 원격 버전'이 아니었다.
'신규 입사자 온보딩'으로 프레임을 바꿔야 한다
이 경험에서 나온 결론이 흥미롭다. 그는 클라우드 에이전트를 "신규 엔지니어를 고용하는 것"에 비유했다. 신입에게 반쯤 완성된 Slack 스레드를 포워딩하면 안 되듯, 에이전트에게도 '내 로컬 세션의 원격 연장'을 기대하면 안 된다는 것이다.
제대로 된 위임은 이렇게 생겼다: 머신을 주고, 체크리스트를 주고, 브리핑을 준다. 그가 만든 AGENTS.md가 바로 그 브리핑 문서다. Node 버전 제약, .env 설정, E2E 셋업, 폰트 민감 스냅샷 등 로컬에서는 당연하게 알지만 클린 환경에서는 알 수 없는 것들을 명시적으로 기록했다. 중요한 건 파일 자체가 아니라, 맥락이 경계를 넘어 의도적으로 전달되어야 한다는 원칙이다.
테크 리드 입장에서 이 구분은 워크플로우 설계의 출발점이 된다. 에이전트에게 넘기는 태스크는 '범위가 명확하고 완료 기준이 정의된 것'이어야 한다. 오픈엔드 탐색, 제품 방향 논의, 아키텍처 판단은 여전히 로컬—사람—의 영역이다.
에이전트가 멈출 때, 당신은 어디 있나
두 번째 문제는 더 현실적이다. 에이전트가 실행 중일 때 당신은 회의실에 있거나 커피를 마시러 나간다. 그때 에이전트가 rm -rf build/, git push --force, kubectl delete pod 같은 파괴적 명령 앞에서 멈춘다. 승인을 기다리며 컨텍스트를 붙잡고 있는 채로.
Telechat 팀이 dev.to에 공개한 솔루션은 이 문제를 직접 겨냥한다. Claude Code 세션을 Telegram·WhatsApp·Slack과 연결해, 에이전트가 승인이 필요한 시점에 모바일로 푸시 알림을 보낸다. 전체 명령어와 컨텍스트를 확인하고, 탭 한 번으로 Approve 또는 Deny. VPN도, SSH도, 노트북도 필요 없다.
이걸 단순한 편의 기능으로 보면 안 된다. 이건 휴먼-인-더-루프(Human-in-the-Loop) 설계의 구체적 구현이다. AI-First 워크플로우에서 에이전트의 자율성을 높일수록, 인간의 승인이 개입하는 지점을 명확히 설계해야 한다는 원칙의 실천이다. 에이전트가 '언제, 어떤 행동에서 멈춰야 하는가'를 미리 정의하지 않으면, 자율성은 통제 불능으로 이어진다.
빨리 만들었다고 싸게 유지되지 않는다
세 번째 사례는 좀 더 불편한 진실을 건드린다. dev.to에 올라온 "Faster to Build Isn't Cheaper to Own"은 AI 코딩 도구를 직접 쓰고 팀에도 도입한 시니어 엔지니어가 쓴 글이다. 그는 AI를 부정하지 않는다. 오히려 스캐폴딩, 보일러플레이트, 첫 번째 드래프트에서 얻는 레버리지는 실재한다고 인정한다.
그런데 그의 생각이 바뀐 건 작고 조용한 버그 하나 때문이었다. 코드는 깔끔했고, 테스트는 통과했고, 코멘트도 사려 깊어 보였다. 하지만 로직이 틀렸다. 옵셔널 필드가 빠진 API 응답을 잘못 처리했고, 다운스트림에서 사용자가 이상한 동작을 경험하고 나서야 발견됐다. 폭발은 없었다. 그냥 조용히 신뢰를 갉아먹는 버그였다.
그가 METR의 2025년 연구를 언급하는 지점이 의미심장하다. 숙련된 오픈소스 개발자들이 AI 도구를 쓸 때 실제로는 19% 더 느렸지만, 본인들은 더 빠르다고 느꼈다는 결과다. 코드를 화면에 올리는 시간은 줄었지만, 그 코드가 신뢰할 만한지 판단하는 시간은 오히려 늘었다. 생성 비용은 내려갔지만 소유 비용은 그대로다.
테크 리드가 설계해야 할 세 가지 통제권
이 세 사례를 하나의 주제로 읽으면 공통 메시지가 보인다. 에이전트에게 일을 넘기는 방식보다, 통제권을 어디에 심어둘 것인가가 먼저다.
첫째, 위임 경계 설계: 클라우드 에이전트에게 넘길 태스크는 범위와 완료 기준이 명확해야 한다. 의존성 업그레이드, 타깃 버그 픽스, 특정 리뷰 소견 추적—이런 것들은 에이전트에 맞는 태스크다. 아키텍처 판단, 제품 방향 탐색은 아니다. AGENTS.md 같은 브리핑 문서는 선택이 아니라 위임의 전제 조건이다.
둘째, 승인 게이트 설계: 에이전트가 어떤 행동에서 인간의 승인을 기다려야 하는지를 미리 정의하라. 파괴적 명령(삭제, 강제 푸시, 스케일 다운)은 비동기 모바일 승인으로 게이트를 달 수 있다. 이 설계가 없으면 에이전트의 자율성은 자동화가 아니라 방치다.
셋째, 유지보수 비용 설계: AI가 생성한 코드의 리뷰 기준과 검증 기준을 코딩 표준으로 명문화하라. 코드 볼륨이 늘수록 리뷰 어텐션은 선형으로 늘지 않는다. 자동화 체크를 더 많이 넣고, 리뷰어가 로직과 실패 모드에 집중하도록 워크플로우를 재설계해야 한다. 주니어 엔지니어에게는 AI가 생성한 코드를 직접 설명하게 하는 세션이 필요하다—판단력은 자동으로 이전되지 않는다.
경계가 제약이 아니라 기능이 되는 시점
Cursor Cloud Agent 실험을 기록한 개발자의 마지막 문장이 인상적이다. "클린 경계는 제약일 뿐만 아니라, 이 모델을 확장 가능하게 만드는 기능이기도 하다." 맥락이 단절되는 것이 단점처럼 보이지만, 그 단절이 격리와 병렬화를 가능하게 한다. 내 로컬 상태에 오염되지 않은 결과물은 팀 누구나 재현할 수 있다.
이 역설이 AI-First 팀 설계의 핵심이다. 에이전트에게 더 많은 자율성을 줄수록, 그 자율성이 작동하는 경계를 더 정교하게 설계해야 한다. 브리핑을 명확히 하고, 승인 게이트를 심고, 생성된 결과물의 신뢰 기준을 높이는 것—이 세 가지가 갖춰질 때 비로소 에이전트 위임은 생산성 도구가 된다. 그 전까지는 빠른 실수를 더 빠르게 만드는 도구일 뿐이다.