월 $200. Cursor의 Ultra 플랜 가격이다. Composer 2가 출시된 이후 수많은 팀이 이 숫자 앞에서 멈칫했다. 재무팀은 왜 $20짜리 시트가 갑자기 $200이 됐냐고 묻고, 개발자는 그 10배의 가격이 정말 10배의 가치를 내는지 고민한다. 이 질문은 단순한 비용 분석이 아니다. 지금 AI 코딩 도구 생태계 전체가 묻고 있는 질문—이 도구를 어디에 쓸 것인가—의 축소판이다.
Composer 2가 실제로 하는 일
Cursor Composer 2를 단순한 코드 자동완성이나 채팅 모델로 이해하면 틀린다. dev.to의 실사용 분석에 따르면, 이 모델은 수백 개의 순차적 액션을 요구하는 태스크 단위로 훈련된 에이전틱 코딩 모델이다. "auth 모듈을 users에서 분리하고, 모든 import를 업데이트하고, 깨진 테스트를 고치고, 빌드가 통과할 때까지 실행해줘"—이 한 문장을 실제로 수행한다. 계획을 세우고, 파일을 넘나들며 편집하고, 커맨드를 실행하고, 실패 로그를 읽고 다시 시도한다.
이 모델이 진짜 값어치를 하는 영역은 명확하다. 80군데에서 쓰이는 함수를 rename하는 멀티 파일 리팩토링, 테스트 커버리지가 없는 모듈에 대한 backfill, Pydantic v1→v2 같은 메이저 의존성 업그레이드, CI 파이프라인 재작성. 공통점은 하나다—루프를 붙잡고 있어야 하는 작업. 시니어 엔지니어의 시간을 90분짜리 babysitting이 아닌 5개의 작은 커밋 리뷰에 쓸 수 있게 만드는 것, 그게 $200의 실체다.
반면 이 모델이 돈을 태우는 영역도 명확하다. 한 줄짜리 버그 수정, 스펙이 불확실한 탐색적 작업, 테스트도 타입도 없는 코드베이스. 에이전트는 검증할 신호가 없으면 그럴듯해 보이지만 프로덕션에서 터지는 코드를 작성한다. Composer 2는 코드베이스가 보내는 신호를 증폭시킨다—좋은 신호든 나쁜 신호든.
콘텐츠 인프라까지 삼키는 MCP 생태계
같은 시기, 콘텐츠 관리 영역에서도 흥미로운 재정의가 일어나고 있다. Cosmic의 분석에 따르면, "헤드리스 CMS"라는 카테고리 라벨은 이미 시대에 뒤떨어진 표현이 됐다. 2015년에 의미 있었던 이 개념—콘텐츠와 프레젠테이션 레이어의 분리—은 2026년 현재 개발팀이 실제로 요구하는 것의 절반도 설명하지 못한다.
개발팀이 지금 원하는 것은 다르다. AI 에이전트가 인간 없이 콘텐츠를 읽고 쓸 수 있어야 하고, 콘텐츠 워크플로우가 Slack 알림과 배포 파이프라인을 트리거할 수 있어야 하며, Claude Code나 Cursor 같은 AI 코딩 도구가 MCP 서버를 통해 콘텐츠 인프라에 직접 접근할 수 있어야 한다. 이건 CMS 기능 개선이 아니라 개발 도구 생태계의 콘텐츠 인프라 수준으로의 확장이다.
프론트엔드 개발자 입장에서 이 변화는 중요한 시사점을 가진다. 디자인-개발 협업 도구, CMS, CI/CD 파이프라인의 경계가 MCP 레이어에서 녹아내리고 있다. Cursor가 콘텐츠 플랫폼에 직접 연결되고, 에이전트가 Slack에서 콘텐츠를 업데이트하고, 개발자는 그 결과를 코드베이스에서 바로 확인하는 워크플로우—이것이 "AI 네이티브 콘텐츠 인프라"가 DX에 가져오는 실질적인 변화다.
'계산에 AI 없음'—의도적 배제의 설계 철학
그런데 바로 이 시점에, 완전히 다른 목소리가 나온다. 결정론적 소프트웨어 견적 엔진을 만드는 개발자의 이야기다. 이 엔진은 TypeScript로 작성된 수천 줄의 규칙, 가중치, 룩업 테이블로 구성된다. 계산 경로 어디에도 모델 호출이 없다. 같은 입력을 넣으면 오늘도, 내일도, 내년 3월에도 같은 숫자가 나온다.
이 설계의 이유는 단순하다—계약서에 올라가는 숫자이기 때문이다. 같은 견적을 두 번 돌렸을 때 312시간과 287시간이 나온다면, 그건 견적이 아니라 분포에서 샘플링한 값을 사실처럼 포장한 것이다. LLM은 분포에서 샘플링하는 아키텍처다. 온도를 0으로 고정해도 모델 업데이트, 컨텍스트 포매팅, 벤더의 조용한 재훈련에 취약하다. 채팅봇에서는 quirk이지만 계약서에서는 malpractice다.
감사 추적(audit trail)의 문제도 있다. 규칙 기반 엔진은 어느 모듈이 어떤 가중치를 적용했는지 추적할 수 있다. "멀티 테넌시 수정자: +18%"라는 라인을 보고 그 판단이 맞는지 토론할 수 있다. 하지만 LLM이 계산 경로에 있다면 감사 추적은 "모델이 결정했다"가 전부다. 변호사 앞에서 이 방어는 무너진다.
세 가지 사례가 수렴하는 설계 원칙
이 세 이야기—$200짜리 에이전틱 코딩 모델, MCP로 확장되는 콘텐츠 인프라, 계산에 AI를 배제한 견적 엔진—는 결국 하나의 질문으로 수렴한다. 이 단계의 출력이 인간에게 가는가, 아니면 다른 결정론적 프로세스로 가는가?
결정론적 견적 엔진 개발자가 정리한 룰이 명쾌하다. AI는 인간 인터페이스 레이어에 맞는다. 출력이 인간에게 전달되어 판단을 받는 단계—번역, 요약, 초안 작성, 분류—라면 AI가 최적이다. 매번 조금씩 다른 출력은 괜찮다. 인간이 오류 보정 레이어이기 때문이다. 하지만 출력이 다른 결정론적 프로세스로, 계약으로, 감사 대상으로, 12개월 뒤 CFO 앞에서 설명해야 하는 숫자로 이어진다면—AI는 잘못된 도구다.
Composer 2가 빛나는 영역—멀티 파일 리팩토링, 버그 헌팅, 테스트 backfill—도 이 원칙으로 설명된다. 에이전트의 출력은 항상 시니어 엔지니어의 리뷰를 거친다. 인간이 마지막 검증 레이어다. MCP를 통해 AI 에이전트가 콘텐츠를 업데이트하는 워크플로우도 마찬가지—에디터가 결과를 확인하고 승인하는 루프가 있다. 반면 견적 숫자는 인간 리뷰 없이 계약서로 직행한다. 이 차이가 AI 배치 여부를 결정한다.
프론트엔드 개발자가 지금 해야 할 질문
2026년의 AI 코딩 도구 선택은 "쓸 것인가 말 것인가"의 이분법이 아니다. Cursor Composer 2의 $200이 정당화되는 것은 팀의 워크플로우가 에이전틱 루프를 필요로 하는 태스크로 채워져 있을 때다. MCP 서버 연동이 의미 있는 것은 콘텐츠 인프라와 개발 도구 사이의 경계를 실제로 허물어야 할 때다. AI를 배제하는 것이 올바른 선택인 것은 출력의 재현성과 감사 가능성이 사용자와의 계약이 될 때다.
빠른 프로토타이핑에서 검증으로, 검증에서 고도화로 이어지는 흐름에서 AI 도구는 강력한 동반자다. 하지만 그 동반자를 어느 단계에 배치할지 결정하는 것은 여전히 사람의 몫이다. 도구가 스파클 아이콘을 달고 있다고 해서 모든 단계에 끼워 넣는 것은 설계가 아니라 유행을 따르는 것이다. 지금 팀에게 필요한 질문은 하나다—이 단계의 출력은 누가, 어떻게 책임지는가?