프롬프트가 사라지는 날
"Manually prompting your agents is so… 2025." Google Jules 팀이 Project Jitro 웨이트리스트 페이지에 올린 한 줄이다. 도발적이지만, 허풍이 아닐 수 있다. dev.to에 공개된 Project Jitro 분석에 따르면, Google이 내부적으로 개발 중인 이 시스템은 기존 코딩 에이전트와 아키텍처 수준에서 다르다. GitHub Copilot이 됐든 Cursor가 됐든 현존하는 모든 AI 코딩 도구는 하나의 전제를 공유한다: 개발자가 작업을 정의하고, AI가 실행한다. Jitro는 그 전제를 뒤집으려 한다.
태스크 실행 vs. 결과 소유—간극의 의미
지금의 AI 코딩 워크플로우를 솔직하게 들여다보면, 개발자는 여전히 스케줄러이자 PM이자 QA다. AI는 매우 빠른 실행자일 뿐이다. "백엔드 메모리 누수를 20% 줄여라"는 목표를 갖고 있더라도, 실제로는 그것을 열 개의 순차 프롬프트로 번역해 한 주에 걸쳐 수행해야 한다. 목표를 건네는 것이 아니라, 목표를 스스로 분해하고 있는 셈이다.
Project Jitro는 바로 이 간극을 겨냥한다. Jules V2로 알려진 이 시스템은 KPI 기반 목표 설정을 중심으로 설계됐다. 개발자가 "접근성 점수를 100점으로 끌어올려라" 혹은 "에러율을 줄여라"는 고수준 목표를 워크스페이스에 등록하면, 에이전트가 코드베이스를 분석하고 무엇을 바꿔야 해당 지표가 움직이는지 스스로 판단한다. 그리고 결정적으로—세션이 끊겨도 목표는 지속된다. 현재 코딩 에이전트 어디에도 없는 연속성이다.
MCP 통합이 만드는 진짜 차별점
유출된 워크스페이스 API 명세를 보면 Jitro의 야심이 더 구체적으로 드러난다. list goals, create a goal, list insights, get update history, list configured tool integrations—이 오퍼레이션들은 단순한 코드 생성 도구가 아니라 개발 목표를 추적하는 시스템의 인터페이스다. 특히 눈에 띄는 것은 MCP(Model Context Protocol) 리모트 서버와의 네이티브 통합이다.
목표 지향 에이전트가 MCP를 통해 CI/CD, 모니터링, 이슈 트래커 전체에 연결된다면, 이건 로컬 파일만 읽는 도구가 아니다. 코드베이스 바깥의 맥락—배포 상태, 런타임 에러 로그, 스프린트 백로그—을 함께 읽고 판단하는 시스템이 된다. 툴체인 전반을 컨텍스트로 삼는 에이전트, 그것이 Jitro가 그리는 그림이다.
투명성도 설계에 녹아 있다고 한다. 에이전트는 조용히 작동하지 않고 자신의 추론 과정을 노출한다—왜 이 라이브러리를 선택했는지, 왜 이 테이블 구조를 바꿨는지. 개발자는 방향을 승인하고, 실행은 에이전트가 맡는다. 이상적으로 들리지만, "방향 승인"이 수십 개의 결정이 얽힌 대형 코드베이스에서 실제로 어떤 UI로 구현될지는 아직 공개된 바 없다.
지금 실무에서 벌어지고 있는 일
Jitro가 미래를 가리키고 있다면, 현재 개발자들이 마주한 문제는 훨씬 날 것이다. 국내 개발자가 만들어 GeekNews에 공유한 Cursor Subagent 제어 VS Code 익스텐션이 그 단면을 보여준다. Cursor의 Composer(Subagent) 기능을 켜두면 요청 500개 제한이 하루 만에 200개 이상 소진되는 일이 비일비재하다. Cursor 자체에는 Subagent만 따로 끄는 버튼조차 없다.
이 사례는 단순한 불편 함의 이야기가 아니다. 자율성이 높아질수록 개발자가 통제권을 잃는 지점도 함께 드러난다는 신호다. 에이전트가 더 많은 것을 결정할수록, 그 결정이 언제 어떻게 발동되는지를 개발자가 이해하고 조율하는 능력이 오히려 더 중요해진다. 익스텐션 제작자가 hooks와 .cursorrules를 병행 적용해야만 Subagent가 제대로 차단된다는 사실은 시사적이다—자율 에이전트를 다루는 것은 도구 사용법이 아니라 시스템 아키텍처 문제다.
생산성의 단위가 바뀐다
Jitro가 상징하는 전환의 핵심은 UX 개선이 아니다. 작업 단위의 변화다. 지금 개발자 생산성은 얼마나 좋은 프롬프트를 쓰느냐로 측정된다. Jitro가 목표한 대로 작동한다면, 그 기준은 얼마나 명확하게 결과를 정의하느냐로 이동한다.
이 변화는 프론트엔드 개발 워크플로우에 직접적인 함의를 갖는다. 접근성 점수, Core Web Vitals, 전환율—지금은 지표를 보고 개발자가 직접 개입 포인트를 찾아 코드를 수정한다. 목표 기반 에이전트 시대에는 그 지표를 목표로 등록하고, 에이전트가 코드베이스를 분석해 개입 포인트를 제안하거나 직접 수정한다. 개발자의 역할은 실행이 아니라 목표 정의와 방향 검증으로 무게중심이 이동한다.
빠른 프로토타이핑 → 사용자 검증 → 고도화라는 사이클 자체도 재설계된다. 프로토타입 단계에서 에이전트가 아키텍처 블루프린트를 만들고, 검증 후 확정된 스펙을 목표로 등록하면, 에이전트가 세션에 걸쳐 지속적으로 구현을 진행하는 흐름이 가능해진다. 지금처럼 프롬프트를 이어붙이는 방식이 아니라.
신뢰가 병목이 된다
Project Jitro의 공개 일정은 2026년, Google I/O 2026(5월 19일)이 유력한 발표 시점으로 거론된다. Jules 베타에서 수천 명의 개발자가 14만 건 이상의 코드 개선을 공유했다는 실적은 비동기 에이전트 모델의 가능성을 이미 검증했다. Jitro는 그 기반 위에서 목표 지속성과 MCP 통합을 얹는다.
하지만 가장 큰 장벽은 기술이 아니다. 신뢰다. 대형 코드베이스에서 수십 개의 결정을 자율적으로 내리는 에이전트를 팀이 받아들이려면, "에이전트가 왜 이 결정을 했는가"를 검토하는 워크플로우가 함께 설계되어야 한다. 투명성 레이어는 그래서 기능이 아니라 채택의 조건이다.
프롬프트 기반 도구에서 자율 에이전트로 넘어가는 이 전환점에서, 개발자에게 필요한 것은 더 좋은 프롬프트 스킬이 아니다. 목표를 명확히 정의하고, 에이전트의 판단을 구조적으로 검토하는 아키텍트의 시각이다. Jitro가 그 미래를 앞당길지, 혹은 다른 누군가가 먼저 그 선을 넘을지—경쟁의 기준점은 이미 이동했다.