이번 주 Cursor Pro 사용자라면 IDE 우상단에 작은 점 하나가 깜빡이는 걸 봤을 겁니다. 클릭하면 그 안에서 에이전트 하나가 격리된 컨테이너로 들어가 작업을 끝까지 가져옵니다. 같은 점을 여러 개 동시에 띄울 수 있습니다.

Anthropic의 Claude Code도 /team 한 줄로 서브에이전트 N개를 동시에 굴립니다. Cognition Devin은 IDE 자체가 없습니다. Slack 멘션으로 호출하면 자기 클라우드 워크스페이스에서 빌드·테스트·PR까지 끝내고 “처리했어요” 답장만 옵니다. Replit Agent는 코드 한 줄도 안 보여주고 라이브 URL만 띄웁니다.

네 도구가 작년 봄에는 거의 같은 모양이 아니었습니다. 모두 채팅창 안에 있었고, 사용자는 에이전트가 타이핑하는 걸 끝까지 지켜봐야 했습니다. 1년 사이에 무엇이 바뀌었는지, 그리고 그 결과 PM이 다시 보아야 할 KPI가 무엇인지 정리합니다.

작년 봄 N=1, 올해 봄 N=5~7

지난 1년의 변화를 한 숫자로 압축하면 이렇습니다. 사용자 한 명이 동시에 굴릴 수 있는 에이전트 수 N.

  • 2025년 봄: N=1 (채팅창 안 페어 프로그래머, 사용자가 화면 위에서 지켜봄)
  • 2025년 가을: N=2 (Cursor Composer · Anthropic Subagents 초기 버전)
  • 2026년 봄: N=5~7 (Cursor Background Agents · Claude Code /team · Devin 멀티 잡 · Replit Agent 풀스택)

Cursor의 2025년 5월 Background Agents 릴리스 노트에 이런 문장이 있습니다. “We’ve heard from users that watching the agent type is exciting the first 10 times, and exhausting the next 100.” 처음 열 번은 짜릿하지만 다음 백 번은 지친다는 것입니다.

지치는 정도가 아니라 위험합니다. 같은 이슈 스레드의 한 사용자 댓글이 정확히 짚었습니다. “I realized I was ‘helping’ the agent in ways that made it worse.” 도와주려는 개입이 오히려 결과 품질을 떨어뜨린다는 것입니다.

네 도구가 같은 분기에 같은 결론에 도달했습니다. 에이전트는 사용자가 보지 않을수록 더 일을 잘한다. 보지 않아야 컨텍스트 스위칭이 없고, 보지 않아야 한 명이 여럿을 굴립니다. 디폴트 동작이 통째로 뒤집힌 이유가 여기 있습니다.

세 곡선이 같은 분기에 임계값을 넘었다

같은 UI 패턴이 2024년에는 왜 불가능했고 2026년에 왜 가능해졌는가. 세 기술 곡선이 동시에 임계값을 넘었기 때문입니다.

첫째, 토큰 단가가 1년 만에 약 1/5로 떨어졌습니다. 2025년 봄 GPT-4o 한 번의 작업 평균 비용이 $0.30 수준이었다면, 2026년 봄 Claude Sonnet 4.6과 Gemini 2.5 Flash는 같은 작업을 $0.05~$0.08 선에서 처리합니다. 백그라운드로 7개를 동시에 띄워도 한 시간 비용이 $5 안쪽입니다. 실패해도 다시 돌릴 수 있는 가격대가 됐습니다.

둘째, 자기 검증 정확도가 임계값을 넘었습니다. 2025년 봄까지 에이전트의 self-grading 정확도는 60% 언저리였습니다. Claude 3.7 시리즈부터 85%를 넘기면서 “95점 미만이면 자동 재작업” 루프가 실제로 작동하기 시작했습니다. 7개 에이전트를 띄워서 사람이 7번 검토하면 검토 시간이 폭발하지만, 에이전트가 self-grade 90%를 책임진다면 사람은 통과한 결과 1~2개만 최종 승인합니다. 검토 부채(review debt)가 N에 비례해서 늘지 않는 구조가 됐습니다.

셋째, 가장 결정적으로, 컨텍스트 격리 비용이 사라졌습니다. 2024년에는 멀티 에이전트를 띄우면 사용자 메인 채팅에 모든 출력이 섞여 들어왔습니다. 둘이면 200줄, 다섯이면 500줄. 컨텍스트 윈도우가 빠르게 오염됐고 병렬화는 이론상 가능해도 실용적으로는 불가능했습니다. 2025년 말부터 Anthropic Subagents API와 Cursor 격리 컨테이너 모델이 표준이 되면서 각 에이전트가 독립된 컨텍스트 풀을 들고 사용자에게는 요약만 올리는 구조가 자리잡았습니다.

세 곡선이 우연히 같은 분기에 임계값을 넘었기 때문에 백그라운드 에이전트가 표준이 됐습니다. 단일 기능이 아니라 여러 기능이 동시에 임계값을 넘어야 가능한 모드 전환입니다.

같은 자리에서 네 도구가 네 가지 길로 간다

같은 디자인 원칙을 채택했지만 네 도구가 위치한 자리는 모두 다릅니다.

Cursor는 IDE 안 격리 컨테이너 1순위입니다. 에디터 우상단 작은 점이 정체성이고, 일반 개발자에게 가장 익숙한 모델입니다. N이 가장 빠르게 늘어나고 있는 도구입니다.

Claude Code는 CLI 기반 오케스트레이션 표준입니다. 터미널 한 줄(/team)로 서브에이전트 14개를 동시에 띄우는 구조가 가장 정교합니다. PM이 코드 외 영역(문서 평가, 챕터 분담, 루브릭 분석)까지 백그라운드로 보낼 수 있는 유일한 도구입니다.

**Devin (Cognition)**은 사용자 화면 자체가 없는 극단입니다. Slack/Linear/GitHub 이슈가 입력 채널이고, Devin은 자기 클라우드 워크스페이스에서 일합니다. 가장 자율적이고 그래서 가장 검증이 어려운 도구입니다. 외주처럼 쓸 수 있는 첫 도구입니다.

Replit Agent는 풀스택 + 즉시 배포 통합 1순위입니다. 비개발자가 채팅 한 줄로 React + Postgres + Vercel 배포까지 끝내는 유일한 도구입니다. 사용자는 코드를 안 봅니다. 라이브 URL만 봅니다.

네 도구가 노리는 사용자는 다르지만, 공통으로 추구하는 변수는 같습니다. 한 명의 사용자가 굴릴 수 있는 N. 같은 품질이라면 N이 큰 도구가 시장을 가져갑니다.

PM이 새로 들여다봐야 할 세 가지

코딩 에이전트가 백그라운드로 가는 변화는 도구 선택의 문제가 아닙니다. 팀이 어떻게 일하는지를 다시 설계해야 하는 문제입니다.

첫째, “한 명의 N”을 팀 메트릭으로 추적합니다. 지금까지 AI 도구의 KPI는 답변 정확도, 응답 속도, 토큰 단가였습니다. 백그라운드 시대에는 한 명의 사용자가 동시에 굴리는 에이전트 수가 추가됩니다. 팀원별 N 분포를 보면 도구 도입의 실효성이 한눈에 드러납니다. N=1에 머무는 팀원이 많다면 도구의 백그라운드 기능을 신뢰하지 못한다는 신호입니다. N 평균이 3을 넘기 시작하면 팀의 일하는 방식 자체가 바뀌고 있다는 신호입니다.

둘째, 자기 검증 임계값을 팀 룰로 명시합니다. 자기 검증 85%는 통계 평균이고 도메인에 따라 편차가 큽니다. 프론트엔드 UI 작업은 자동 통과 임계를 90점으로 낮춰도 안전하지만, 결제·인증·보안 영역은 95점이어도 사람 리뷰가 필수입니다. PM이 미리 영역별 임계값과 사람 개입 지점을 정의하지 않으면, 에이전트가 자율로 머지한 코드가 프로덕션에 사고를 냅니다. 의사결정 경계 설계가 백그라운드 시대 PM의 첫 책임입니다.

셋째, 검토 시간을 새 자원으로 예산화합니다. N이 늘면 코드 생산량이 늘고, 코드 생산량이 늘면 사람 검토 시간이 새 병목이 됩니다. 자기 검증이 통계적으로 95%여도 5%는 사람이 봐야 하는데, 7명의 에이전트가 만든 결과 중 5%면 한 명의 PR보다 검토 대상이 더 늘어납니다. 에이전트 비용을 토큰 예산만으로 잡지 말고, 사람 검토 시간을 예산 항목에 같이 올려야 합니다. 검토 시간 예산이 없으면 N=1로 회귀합니다.

모델이 수렴할수록, 도구 디자인이 해자가 된다

Claude, GPT, Gemini의 코드 생성 품질은 비슷한 수준으로 수렴 중입니다. 벤치마크 점수 차이는 좁아지고 있고 같은 작업을 같은 정확도로 처리합니다.

그래서 차이가 나는 곳은 다른 데 있습니다. 같은 모델을 어떻게 굴리는가. 사용자에게 무엇을 보여주고 무엇을 가리는가. 한 명의 사용자가 굴릴 수 있는 N을 얼마나 늘릴 수 있는가. 이것이 도구 디자인의 영역이고, PM의 영역입니다.

코드를 빠르게 만드는 건 에이전트가 합니다. 그 에이전트들을 보지 않고 굴리는 구조를 설계하는 건 PM의 일입니다.

당신의 팀에서 백그라운드 에이전트를 도입했다면, 지금 팀원들의 평균 N은 몇입니까? 그리고 그 N이 1을 넘지 못하는 이유가 도구 때문인지 검토 구조 때문인지, 한 번 분리해서 보면 다음 분기 우선순위가 또렷해질 겁니다.