design.md로 브랜드에 맞는 페이지를 만드는 Vercel의 방법
1. 저장소 밖에서는 브랜드 맥락이 사라졌습니다
Vercel은 코드베이스 밖에서도 에이전트가 같은 디자인 판단을 사용할 방법이 필요했습니다.
- 저장소 안에서는 product-design 스킬이 디자인 시스템, 컴포넌트, 실제 출시 사례를 함께 읽을 수 있었습니다.
- 보고서·제안서·독립형 페이지를 만드는 외부 도구에는 그 맥락이 없었습니다.
- 기존 가이드를 공개 프롬프트로 옮기는 방식도 충분하지 않았습니다.
- “깔끔한 레이아웃” 같은 주관적 표현을 모델마다 다르게 해석했습니다.
- 같은 지침에서도 구조와 스타일이 크게 다른 결과가 나왔습니다.
2. design.md, 스타일시트, 평가 루프로 역할을 나눴습니다
브랜드 일관성을 한 파일의 설명에만 맡기지 않고 판단, 표현 수단, 검증의 세 층으로 구성했습니다.
- design.md는 독자의 과제, 근거 구조, 구성과 카피에 관한 판단을 안내합니다.
- 에이전트가 반복해서 만드는 좋지 않은 디자인 패턴에도 이름을 붙여 피하도록 했습니다.
- 공개 CSS 스타일시트는 타이포그래피, 간격, 표, 차트의 클래스와 토큰을 제한합니다.
- CSS는 브라우저에서 로드되므로 모델 컨텍스트를 차지하지 않습니다.
- 에이전트가 반복 가능한 시각 요소를 매번 다시 발명하지 않게 합니다.
- 평가 루프는 사람의 디자인 판단과 결정론적 검사를 함께 사용합니다.
- 계층과 구성은 사람이 블라인드 A/B로 비교합니다.
- 폭을 무시한 표 같은 기계적 실패는 코드로 검사합니다.
3. 스타일뿐 아니라 페이지 구조와 오류율이 달라졌습니다
고정된 조건에서 반복 비교하며 실제 결과를 개선한 규칙만 남겼습니다.
- 실제 업무에서 뽑은 7개 시나리오에 같은 프롬프트, 데이터, 모델, 뷰포트를 적용했습니다.
- design.md를 사용한 결과는 색과 타이포그래피만 바뀐 것이 아니었습니다.
- 갱신 제안서는 권장 사항을 먼저 보여주고 상업적 근거를 비교 가능한 구조로 재배치했습니다.
- 서로 다른 페이지도 같은 템플릿이 아니라 각 독자의 목적에 맞는 정보 구조를 유지했습니다.
- 200회가 넘는 실행 뒤 세 데스크톱 시나리오를 비교한 테스트에서는 알려진 실패가 91건에서 39건으로 줄었습니다.
- 약 57% 감소했지만 표본은 6페이지뿐이었고 모든 결과에 출시를 막을 실패가 남아 있었습니다.
4. 반복되는 피드백을 다음 실행의 규칙으로 바꿉니다
고정 평가를 통과한 뒤에도 실제 사용에서 같은 불만이 줄어드는지 추적하며 시스템을 갱신합니다.
- Slack의 @design-agent는 design.md와 스타일시트를 불러 페이지를 만든 뒤 스크린샷과 배포 URL을 공유합니다.
- Slack, GitHub, Figma의 피드백을 매주 모아 반복되는 문제를 변경 제안으로 만듭니다.
- 판단의 문제는 design.md에, 재사용 가능한 표현은 CSS에, 기계적 오류는 검사 코드에 반영합니다.
- 자동화가 변경을 제안하더라도 최종 반영은 사람이 검토합니다.
