에이전트를 돌려본 사람은 많다. 그런데 에이전트가 예측 가능하게 움직이게 만들어본 사람은 훨씬 적다. Cursor 3 출시, .cursorrules 최적화 패턴, Claude Code 24/7 프로덕션 운영 사례—이 세 가지를 같이 놓고 읽으면 하나의 공통된 질문이 떠오른다. 에이전트를 '신뢰할 수 있는 동료'로 만들려면 무엇을 설계해야 하는가?
핵심 이슈: 오케스트레이션은 됐다, 이제 신뢰성 차례다
Cursor 3(4월 2일 출시)의 가장 큰 변화는 Agents Window다. 클라우드 에이전트, 로컬 에이전트, Slack·GitHub·Linear에서 시작한 에이전트까지 단일 사이드바에서 관리하고, 클라우드→로컬→클라우드 핸드오프를 원클릭으로 처리한다. dev.to 기고자 Cristian Sarmiento의 표현을 빌리면 "에이전트 플릿을 운영하는 게 자연스러워진 첫 번째 에디터"다.
그런데 이걸 팀 리드 시각으로 읽으면 질문이 달라진다. 에이전트가 많아질수록, 각 에이전트가 얼마나 일관되게 움직이느냐가 전체 시스템의 품질을 결정한다. 멀티 에이전트 워크플로우가 가능해진 순간, 병렬로 돌아가는 에이전트 중 하나가 잘못된 패턴을 코드베이스에 심어도 아무도 모른다는 리스크가 함께 커진다.
맥락 해석 ①: .cursorrules는 '설정 파일'이 아니라 '계약서'다
dev.to의 Olivia Craft는 50회 이상 .cursorrules를 반복 수정하며 패턴을 정제했다. 결론은 단순하다. 규칙의 양이 아니라 순서·범위·폴백 행동이 신뢰성을 결정한다.
핵심 패턴 세 가지만 뽑으면:
- 우선순위 주석: 프레임워크 무관 규칙 → 프레임워크 특화 규칙 순으로 명시적 순서를 부여해야 Cursor가 올바른 규칙을 선택한다.
- 네거티브 가드레일:
useEffect로 데이터 패칭 금지,any타입 금지처럼 '하지 말 것'을 명시적으로 열거해야 deprecated 패턴이 코드베이스에 스며드는 걸 막는다. - 폴백 지정: 명시된 규칙이 없는 상황에서 에이전트가 어떻게 행동할지를 설계하지 않으면, 에이전트는 가장 그럴듯한 답을 스스로 만들어낸다.
이 세 번째 포인트가 특히 중요하다. .cursorrules를 '에이전트에게 보내는 계약서'로 보면, 계약서에 없는 상황이 생겼을 때 어떻게 행동할지를 규정하지 않은 계약은 분쟁의 씨앗이다. 팀에서 .cursorrules를 공유 자산으로 관리하고 있다면, 폴백 조항 설계가 빠져 있지 않은지 지금 당장 확인해야 한다.
맥락 해석 ②: 프로덕션 에이전트는 '실행'이 아니라 '운영 설계'다
Claude Code 에이전트 Koda를 MacBook Pro에서 24/7 데몬으로 2주간 운영한 기고자 kfuras의 사례는 훨씬 냉정하다. 21개 스케줄 태스크, 11개 MCP 서버, 43개 헬퍼 스크립트를 붙여놓고 실제로 무너진 지점들을 기록했다.
실패 패턴을 요약하면:
- 컨텍스트 소진: 긴 파이프라인은 토큰 한계 중간에 터진다. 해결책은 단계마다 중간 아티팩트를 파일로 저장하는 것.
- 조용한 설정 상속:
settingSources기본값이 외부 설정 파일을 자동으로 당겨와 에이전트가 엉뚱한 규칙을 따랐다. 명시적으로[]로 비우기 전까지 아무도 몰랐다. - 서브 에이전트 턴 캡:
maxTurns기본값 15는 파일시스템을 건드리는 태스크에 터무니없이 낮다. 기본값을 믿으면 안 된다.
더 흥미로운 건 자가 복구 설계다. 인증 오류, 크래시 루프, 설정 문제를 분류하고 적합한 복구 액션을 실행한 뒤 30초 후 헬스를 확인하는 self-heal 스킬이 마크다운 파일 하나로 구현됐다. 에이전트의 행동 로직이 코드가 아니라 마크다운에 산다—이게 이 아키텍처의 핵심 통찰이다. 복구 로직을 바꾸고 싶으면 마크다운을 편집하면 된다. 재배포 없이.
시사점: '에이전트 실행'에서 '에이전트 설계'로
세 사례를 겹쳐 읽으면 공통된 구조가 보인다.
| 레이어 | 도구 | 설계 포인트 |
|---|---|---|
| 오케스트레이션 | Cursor 3 Agents Window | 클라우드↔로컬 핸드오프, 병렬 에이전트 가시성 |
| 행동 제약 | .cursorrules | 순서·네거티브 가드레일·폴백 명시 |
| 운영 복원력 | Claude Code + pm2 | 턴 캡, 중간 저장, 자가 복구 스킬 |
에이전트를 팀에 붙이는 건 이제 어렵지 않다. 어려운 건 에이전트가 팀의 컨벤션을 이탈하지 않도록 설계하는 것, 그리고 이탈했을 때 스스로 복원되도록 만드는 것이다. 이건 프롬프트 엔지니어링이 아니라 시스템 설계다.
팀 리드로서 지금 당장 점검해야 할 세 가지: 1. .cursorrules에 폴백 행동이 명시되어 있는가? 2. 멀티 에이전트 워크플로우에서 에이전트별 작업 범위가 명확히 격리되어 있는가? 3. 프로덕션 에이전트의 실패 패턴이 로깅되고 자동 복구 경로가 설계되어 있는가?
전망: 에이전트 신뢰성이 다음 경쟁 축이 된다
Cursor 3이 보여준 것은 오케스트레이션 레이어의 성숙이다. 이제 도구는 됐다. 다음 6개월 안에 팀 간 생산성 격차를 만드는 건 에이전트를 얼마나 빠르게 붙이느냐가 아니라 에이전트가 팀의 기준을 얼마나 일관되게 유지하느냐가 될 것이다.
에이전트를 믿는다는 건 맹목적으로 실행 결과를 수용한다는 뜻이 아니다. 에이전트가 어떤 상황에서도 팀이 설계한 경계 안에서 움직이도록 구조를 짰다는 확신이다. 그 확신을 만드는 것—그게 지금 AI-First 팀에서 테크 리드가 해야 할 일이다.