AI 에이전트가 코드를 생성하는 속도가 빨라질수록, 역설적으로 두 가지 질문이 더 선명해진다. 첫째, 에이전트가 UI를 그릴 때 참조하는 디자인 값은 '누가 결정한 것인가?' 둘째, 에이전트가 만들어낸 코드를 컴파일하는 빌드 설정은 '얼마나 명시적인가?' 최근 Google Labs의 DESIGN.md 오픈소스 공개와 TypeScript 6.0 전환 논의는 서로 다른 맥락에서 출발했지만, 같은 방향을 가리킨다. 설계 기반을 암묵적 추론에 맡기지 말고, 선언적으로 표준화하라.
핵심 이슈: 에이전트는 결정을 내려주지 않는다
Google Labs가 공개한 DESIGN.md는 AI 코딩 에이전트가 읽고 쓸 수 있는 디자인 토큰 포맷이다. YAML로 색상·간격·타입 스케일을 정의하고, CLI 하나로 Tailwind 익스포트와 diff 추적까지 된다. 깔끔하다. 그런데 dev.to에 올라온 분석 글("A Design Document vs a Design Chain")은 이 지점에서 정확한 질문을 던진다. 포맷은 목적지고, 경로가 아니다.
accent: "#aa3bff"라는 값이 DESIGN.md에 적히기 전에, 누군가는 '왜 이 보라색인가'를 결정해야 한다. 그 결정 과정이 없으면 에이전트는 그냥 추측한다. 충분한 디자인 시스템과 디자이너가 있는 팀에게 DESIGN.md는 강력한 표준화 도구다. 하지만 0→1 제품을 만드는 팀이나 솔로 개발자에게 진짜 문제는 포맷 이전에 존재한다. '디자인 인텐트를 어떻게 발견하는가'다.
맥락 해석: 디자인 체인이 채우는 공백
글에서 제안하는 '디자인 체인'은 네 단계로 구성된다. 1단계는 방향 문서—구체적인 색상값 없이 시각적 톤과 레퍼런스 제품만 산출한다. 2단계는 목업—추상적 묘사를 픽셀 단위로 시각화해 '이 간격이 너무 넓다'처럼 구체적으로 반박할 수 있게 한다. 3단계는 값 동결—목업이 사람의 승인을 통과한 뒤에야 색상값을 확정한다. 4단계가 바로 DESIGN.md의 lint·diff·export 자동화다.
이 구조에서 DESIGN.md는 4단계 출구다. 입구가 아니다. 에이전트에게 #aa3bff를 신뢰할 수 있는 값으로 전달하려면, 그 값이 세 번의 검증을 살아남았다는 기록이 먼저 있어야 한다. 방향 문서에서 한 번, 픽셀 목업에서 한 번, 사람의 최종 승인에서 한 번. 그 과정을 건너뛰고 첫 패스에 바로 스펙 파일에 적어넣으면, 에이전트는 검증되지 않은 직감을 소스 오브 트루스로 믿게 된다.
이 흐름은 내가 AI 도구와 협업할 때 자주 겪는 마찰과 정확히 일치한다. v0.dev나 Cursor로 빠르게 UI를 뽑을 때, 에이전트가 내놓는 색상이나 간격이 '나쁘지 않아 보이지만 왜인지 모르게 어색한' 경우가 있다. 그건 에이전트의 문제가 아니라 내가 디자인 인텐트를 명확히 전달하지 않은 문제다. DESIGN.md는 그 인텐트를 구조화하는 좋은 형식이지만, 체인 없이 형식만 있으면 빈 그릇일 뿐이다.
TypeScript 6.0: 빌드 설정도 같은 문제다
velog의 TypeScript 6.0 마이그레이션 글은 전혀 다른 레이어에서 같은 원칙을 보여준다. TypeScript 6.0은 기존에 TypeScript가 '넓게 추측해주던' 설정들을 프로젝트가 직접 선언하도록 요구하는 방향으로 이동한다. rootDir 추론, 전역 타입 자동 포함, DOM iterable 분리 설정—이 모든 것이 암묵적 추론에서 명시적 선언으로 이동하는 흐름이다.
실무 영향은 생각보다 넓다. rootDir을 명시하지 않으면 dist/index.js를 기대하던 배포 스크립트가 dist/src/index.js를 마주하며 컨테이너가 뜨지 않는다. types를 명시하지 않으면 테스트 환경 타입과 브라우저 타입이 뒤섞여 describe, process, Request가 어디서 왔는지 추적이 어려워진다. CI에서만 실패하고 로컬에서는 되는 현상도 대부분 이 암묵적 추론의 균열에서 비롯된다.
해결 방향은 단순하다. 추측을 줄이고 선언을 늘린다. Next.js 웹, Vite 관리자 도구, Node BFF 스크립트가 공통 tsconfig.base.json을 공유하더라도, 각자의 실행 환경에 맞는 tsconfig.web.json, tsconfig.admin.json, tsconfig.node.json을 분리해야 한다. 그리고 CI에 test -f dist/index.js 같은 산출물 존재 확인을 심어두면, 설정 변경이 배포 장애로 이어지는 연결 고리를 끊을 수 있다.
시사점: 에이전트가 빠를수록 기반이 명시적이어야 한다
두 이슈를 나란히 놓으면 같은 구조가 보인다. 에이전트(또는 도구)가 암묵적 추론에 의존하게 두면, 속도가 빠를수록 오차가 누적된다. 디자인 에이전트가 토큰 없이 색상을 추측하면 UI가 무지개색이 된다. TypeScript 컴파일러가 rootDir을 추론하게 두면 배포 경로가 어긋난다. 둘 다 '일단 돌아가는 것처럼 보이다가 특정 조건에서 조용히 실패'하는 패턴이다.
프론트엔드 팀이 AI 에이전트를 워크플로우에 편입할 때 가장 먼저 해야 할 일은, 에이전트가 참조할 기반을 명시적으로 선언하는 것이다. 디자인 레이어에서는 디자인 체인을 통해 검증된 토큰을 DESIGN.md에 동결하고, 빌드 레이어에서는 types, rootDir, lib, moduleResolution을 환경별로 명시해 추론에 기대는 면적을 최소화한다. 이 두 작업은 둘 다 '속도를 높이기 위한 준비'다. 기반이 명확할수록 에이전트에게 위임할 수 있는 범위가 넓어진다.
전망: 표준화는 자동화의 전제 조건이다
AI 에이전트가 디자인-개발 파이프라인 전반에 깊숙이 들어오는 속도는 예상보다 빠르다. Figma 플러그인이 토큰을 추출하고, 에이전트가 컴포넌트를 생성하고, CI가 타입을 검증하는 흐름이 이미 실험 단계를 넘어 실무에 들어오고 있다. 이 파이프라인이 신뢰성 있게 작동하려면 각 단계의 입출력이 예측 가능해야 한다.
DESIGN.md의 lint와 diff가 의미 있으려면 그 안의 값이 체인을 통과한 것이어야 하고, TypeScript의 타입 검사가 CI에서 의미 있으려면 설정이 환경별로 명시되어 있어야 한다. 표준화는 규율을 위한 것이 아니라 자동화의 전제 조건이다. 에이전트에게 더 많은 것을 맡기고 싶다면, 에이전트가 기댈 수 있는 명시적인 기반을 먼저 쌓아야 한다. 속도와 안정성은 트레이드오프가 아니라, 기반의 품질이 결정하는 같은 축이다.