에이전트가 엉뚱한 코드를 뱉을 때, 우리는 보통 모델 탓을 한다. 프롬프트를 고치거나, 더 좋은 모델로 바꾸거나. 그런데 실제 원인 중 상당수는 모델이 받는 입력 자체의 품질에 있다. 기획 맥락도, 디자인 규칙도, 코드 컨벤션도—에이전트는 우리가 먹인 것만큼만 이해한다. 최근 세 가지 흐름이 이 문제를 각기 다른 각도에서 건드리고 있다. 합쳐서 읽으면 '에이전트 입력 설계'라는 하나의 프레임이 선명하게 보인다.
1. DESIGN.md: 디자인 시스템을 파일 한 장으로 주입하라
Google이 자사 디자인 도구 Stitch를 통해 공개한 DESIGN.md는 구조 자체는 단순하다. 프로젝트 루트에 마크다운 파일 하나를 넣어두면 AI 코딩 에이전트가 자동으로 읽고 디자인 규칙을 따른다. Apache 2.0으로 오픈소스 공개된 지 72시간 만에 GitHub 스타 5,000개, 한 달 만에 관련 레포가 6.8만 스타를 넘긴 반응이 말해주는 건 이 규격 자체의 완성도가 아니다. 개발자들이 이 문제를 얼마나 오래 겪어왔는지다.
Claude Code, Cursor, Copilot으로 UI를 만들어본 팀이라면 이 장면이 익숙할 것이다. 기능은 작동하는데 브랜드 색상도 다르고, 폰트도 다르고, 버튼 스타일도 맞지 않는다. 그래서 매번 프롬프트에 색상 코드, 폰트 크기, border-radius를 붙여 넣는다. 대화가 길어지면 또 반복한다. DESIGN.md는 이 반복을 끊는다. README.md가 사람에게 프로젝트를 설명하듯, DESIGN.md는 에이전트에게 디자인 시스템을 설명한다.
파일 구조도 잘 설계되어 있다. 앞쪽 YAML 블록에는 색상 코드·폰트·간격 같은 정확한 토큰 값을 넣고, 뒤쪽 마크다운에는 그 값을 언제 어떻게 써야 하는지 맥락을 쓴다. 숫자는 에이전트에게 정확한 값을 주고, 서술은 판단의 근거를 준다. 이 구조가 핵심이다. 값만 주면 에이전트는 적용 맥락을 틀린다. 맥락만 주면 구현이 흔들린다. 둘을 같이 줘야 일관된 출력이 나온다.
실용성 관점에서 보면 도입 장벽은 낮다. Google Stitch에서 기존 웹사이트 URL만 넣으면 자동 생성해주고, getdesign.md에는 Apple·Notion·Figma·Spotify 등 70개 브랜드의 파일이 정리되어 있다. 이미 Figma 토큰이나 Tailwind 설정이 있는 팀은 그걸 포맷에 맞춰 옮기면 된다. 아직 알파 단계이고 Figma 기반 워크플로우가 탄탄한 팀이라면 당장 필수는 아니지만, Google이 업계 표준으로 밀고 있는 방향이라 흐름 자체는 모니터링할 필요가 있다.
2. Figma 연동의 진짜 문제: 데이터가 아니라 노이즈
Figma를 AI 에이전트와 연결하려는 시도는 많다. 결과가 대부분 실망스러운 이유를 dev.to에 올라온 실전 사례가 정확하게 짚어준다. 핵심은 더 많은 컨텍스트가 항상 좋은 게 아니다라는 것.
Figma 파일을 통째로 에이전트에게 넘기면 어떤 일이 벌어지냐. 깊게 중첩된 트리 구조, 불일치한 레이어 네이밍, 코드 생성과 무관한 시각적 메타데이터가 뒤섞인 노이즈 덩어리를 모델이 소화해야 한다. 사람 눈에는 깔끔한 디자인이 모델 입장에서는 신호 대 잡음 비율이 극도로 낮은 JSON이다. 결과는 기술적으로 그럴싸하지만 수정이 많이 필요한 코드. Dev Mode나 API로 추출해도 본질적으로 같은 문제다—원시 데이터는 기계 해석용으로 설계되지 않았다.
이 사례에서 찾은 해법은 역발상이다. 데이터를 더 주는 게 아니라 줄이고 다듬어서 준다. 작업에 필요한 프레임이나 컴포넌트만 선택해 내보내고, 로컬 파이프라인에서 구조를 정규화한 뒤, MCP 서버를 통해 에이전트가 구조화된 컨텍스트로 쿼리할 수 있게 노출한다. 모델은 더 이상 Figma를 직접 해석하지 않는다. UI의 논리적 표현에 가까운 데이터를 받는다.
이 접근의 부수 효과가 흥미롭다. 에이전트가 보는 범위가 자연스럽게 제한된다. 수동으로 입력을 자르는 게 아니라, 정규화 과정 자체가 관련 있는 조각만 살아남게 만든다. 출력의 일관성이 올라가고, 이상한 레이아웃 결정이 줄어들고, 수동 수정량이 감소한다. '프롬프트하고 기도하는' 느낌에서 '믿고 맡길 수 있는' 느낌으로 바뀐다는 표현이 정확하다. 로컬 실행이라 외부 API 의존성도, 사용량 기반 비용도 없다는 것도 장점.
DESIGN.md와 이 Figma 파이프라인 접근의 공통 교훈은 같다. 에이전트에게 넘기기 전에 먼저 해석하라. 원본 데이터를 그대로 통과시키지 말고, 에이전트가 추론하기 좋은 형태로 가공하는 레이어가 중간에 있어야 한다.
3. Cursor 3의 병렬 에이전트: 입력 설계 없이 확장하면 노이즈만 늘어난다
Cursor 3(코드명 Glass)는 에이전트 한 개를 잘 쓰는 도구에서 에이전트 플릿을 운영하는 플랫폼으로 패러다임을 바꾼다. Agents Window에서 여러 에이전트를 병렬로 실행하고, 로컬에서 시작한 세션을 클라우드 VM에 넘겨 노트북을 닫고 자리를 뜰 수 있다. /multitask는 큰 작업을 쪼개 서브에이전트 플릿에 동시에 던진다. CI/CD 레이어처럼 대화로 조작하는 그림이다.
Hacker News의 반응이 갈렸다. 핵심 비판은 기능 부재가 아니라 철학의 방향이다. 코드를 직접 쓰고 싶은 개발자들은 에이전트 퍼스트 인터페이스를 원하지 않았다. Cursor 엔지니어가 빠르게 응답했다—IDE는 그대로 있고 Agents Window는 별도 서피스이며 동시에 쓰거나 무시할 수 있다. 둘 다 사실이다. 하지만 그게 논쟁의 핵심이 아니다. Cursor 3가 제안하는 건 다른 직업이다. 코드를 쓰는 일과 반자율 시스템 여러 개의 출력을 관리하는 일은 다른 인지 모델, 다른 리뷰 감각, 다른 디버깅 접근이 필요하다.
비용 구조도 냉정하게 봐야 한다. 클라우드 에이전트를 이틀 돌리고 2,000달러 청구서를 받은 사례가 Hacker News에 올라왔다. 클라우드 실행의 VM 분당 요금은 가격 페이지에 명시되지 않는다. 로컬 실행(Composer 2)은 별도 과금이 없지만 클라우드 에이전트가 진짜 강점—야간 실행, 멀티 레포 병렬화—을 발휘하는 구간이다. Claude Code Max의 월 100~200달러 정액제와 비교하면 헤비 워크로드에서 수학이 달라진다. 병렬 에이전트를 실전에 투입하기 전에 일주일치 비용을 추적하는 게 필수다.
Composer 2 모델 베이스 미공개 논란도 짚어야 한다. 외부 개발자가 시스템 응답에서 Moonshot AI의 Kimi K2.5 기반임을 역추적했고, Cursor 공동창업자가 뒤늦게 인정했다. Cursor 측은 75%의 컴퓨트를 자체 사전학습과 강화학습에 썼다고 설명했지만, 초기 미공개는 신뢰 비용을 남겼다. 팀 도구 선택에서 투명성은 기능만큼 중요하다.
시사점: 에이전트 확장 전에 입력 설계 먼저
세 흐름이 같은 것을 가리킨다. 에이전트 성능의 병목은 모델이 아니라 모델이 받는 컨텍스트의 품질이다. DESIGN.md는 디자인 시스템 컨텍스트를 구조화해서 반복 주입 문제를 해결한다. Figma 파이프라인 접근은 과도한 원시 데이터를 정규화해 신호 대 잡음 비율을 올린다. Cursor 3의 병렬 에이전트는 이 설계가 없는 상태에서 규모만 키우면 노이즈가 병렬로 늘어날 뿐이라는 반면교사를 제공한다.
팀 관점에서 실천 순서를 정리하면 이렇다. 첫째, 에이전트에게 주는 컨텍스트 레이어를 명시적으로 설계하라. DESIGN.md든, 정규화 파이프라인이든, CLAUDE.md든—어떤 형태든 '원본을 그대로 통과시키지 않는' 해석 레이어가 있어야 한다. 둘째, 에이전트 확장(병렬화, 자동화)은 단일 에이전트 출력 품질이 안정된 다음에 고려하라. 불안정한 입력 위에 올린 병렬화는 빠른 실패를 병렬로 생산할 뿐이다. 셋째, 도구 선택 전에 비용 모델을 주간 단위로 시뮬레이션하라. 데모에서 보이는 수치와 실제 청구서 사이의 갭이 생각보다 크다.
에이전트가 많아지고 빨라질수록, 그 에이전트에게 무엇을 어떻게 먹이냐는 질문이 팀 역량의 핵심이 된다. 도구를 고르는 것보다 입력을 설계하는 능력이 실제 생산성 격차를 만드는 구간으로 이동하고 있다.