DESIGN.md 열풍, 이제 AI 코딩 에이전트는 디자인 명세부터 먹고 자란다
모델 성능 경쟁 다음 전장은 UI를 얼마나 일관되게 뽑아내는가다
나는 요즘 AI 코딩 에이전트 결과물을 볼 때 코드보다 먼저 화면을 본다. 기능은 얼추 맞는데, 버튼 간격 하나씩 틀어지고 카드 톤이 페이지마다 흔들리면 그 순간부터 팀은 다시 사람 손으로 UI를 맞추느라 시간을 태운다. 그래서 지금 DESIGN.md 열풍은 단순 밈이 아니라, AI 시대 프런트엔드 생산성이 어디로 이동하는지 보여주는 꽤 정확한 신호다.
getdesign.md가 보여준 포인트는 간단하다. 이제 사람들은 “애플 느낌으로”, “노션처럼 깔끔하게”, “Linear 같은 밀도감으로” 같은 감성 프롬프트에 만족하지 않는다. 대신 색상, 타이포, 간격, radius, interaction tone, 브랜드 감각을 문서 파일로 고정해서 에이전트에게 먹이는 방식으로 넘어가고 있다. AI 코딩 에이전트가 똑똑해질수록, 오히려 사람이 더 구체적인 명세 파일을 요구하게 되는 역설이 시작된 셈이다.
왜 지금 한국 커뮤니티가 DESIGN.md에 바로 반응했나
GeekNews에서 짧은 시간 안에 반응이 강하게 붙었다는 건 꽤 중요하다. 이건 단순히 새 사이트가 재밌어서가 아니다. 한국 개발자 커뮤니티가 이제는 “어느 모델이 더 똑똑한가”보다 “내가 원하는 UI를 얼마나 안정적으로 재현해주나” 쪽에 더 예민해졌다는 뜻이다.
이 변화는 자연스럽다. 이미 많은 팀이 Cursor, Claude Code, Codex 류 에이전트로 화면을 뽑고 있다. 문제는 1회성 데모는 그럴듯한데, 두 번째 화면부터 흔들린다는 점이다.
- 첫 페이지는 미려한데 두 번째 페이지부터 spacing rhythm이 깨진다.
- 같은 primary button인데 화면마다 radius와 hover tone이 달라진다.
- 브랜드 보이스를 말로 설명하면 에이전트가 매번 다르게 해석한다.
- Figma 없이 빠르게 만들수록, 나중에 다시 맞추는 비용이 더 커진다.
즉 지금 병목은 모델의 코딩 능력 자체보다 명세 부재로 인한 출력 편차다. DESIGN.md는 딱 그 지점을 찌른다.
DESIGN.md는 감성 프롬프트를 자산으로 바꾸는 파일이다
내가 이 흐름을 좋게 보는 이유는 하나다. 프롬프트에 흩어져 있던 설명을 파일로 외부화하기 때문이다. 그 순간부터 UI 감각은 개인의 손맛이 아니라 팀의 자산이 된다.
예를 들어 vibe coding 단계에서 흔히 이런 식으로 말한다.
“조금 더 고급스럽게, 여백 넉넉하게, 텍스트는 차분하게, 카드 그림자는 약하게.”
이건 사람끼리도 애매한데, 에이전트한테는 더 위험하다. 반면 DESIGN.md는 이런 식으로 굳힐 수 있다.
## Brand Tone- calm, dense, trustworthy- avoid playful gradients- prefer muted contrast over saturated accents
## Typography- heading: semibold, tight tracking- body: regular, high readability- avoid oversized hero copy
## Spacing- section gap: 64px desktop / 40px mobile- card padding: 24px- button height: 44px minimum
## Components- primary button: 10px radius, no hard shadow- cards: soft border first, shadow second- forms: helper text always visible이 파일 하나가 있으면 에이전트는 더 이상 감으로 색을 고르는 대신, 팀이 합의한 기준을 따라 구현한다. 결과적으로 반복 수정이 줄고, 리뷰 포인트도 “취향”이 아니라 “문서 위반”으로 바뀐다. 이 차이가 크다.
AGENTS.md 다음은 DESIGN.md일 가능성이 높다
이미 개발 워크플로우에서는 AGENTS.md가 꽤 자연스러운 표준이 됐다. 어떤 에이전트가 어떤 규칙으로 일하고, 어떤 도구를 쓰고, 어떤 금지선이 있는지 문서로 적어두는 방식이다. 이게 효과적인 이유는 모델이 똑똑해서가 아니라, 반복되는 작업 규칙을 문서로 고정했기 때문이다.
DESIGN.md도 똑같다. 프런트엔드 팀 입장에서 이 문서는 새 계약서에 가깝다.
- 디자이너는 추상적인 분위기 대신 구현 가능한 기준을 남긴다.
- 개발자는 리뷰 때 감으로 싸우지 않고 문서를 기준으로 맞춘다.
- AI 에이전트는 페이지마다 달라지는 해석을 줄인다.
- 새 팀원이 들어와도 브랜드 톤을 빠르게 복제할 수 있다.
중요한 건 DESIGN.md가 Figma를 대체한다는 말이 아니라는 점이다. 오히려 Figma의 의도를 코드 생성 친화적인 텍스트 레이어로 한 번 더 번역해주는 보조 계약서에 가깝다. 이 중간층이 생기면 에이전트는 훨씬 덜 흔들린다.
이제 생산성 경쟁은 코드 생성보다 명세 자산으로 간다
앞으로 프런트엔드 생산성 경쟁은 “누가 더 빠르게 페이지를 찍어내나”보다 “누가 더 재사용 가능한 명세 자산을 잘 쌓아두나”로 이동할 가능성이 크다. 이건 꽤 냉정한 변화다.
예전에는 좋은 프롬프트를 가진 사람이 유리했다. 하지만 에이전트 사용이 보편화되면, 프롬프트는 쉽게 복제된다. 대신 복제하기 어려운 건 다음이다.
- 팀의 디자인 언어를 얼마나 명확하게 문서화했는가
- 그 문서를 에이전트가 바로 소비할 수 있는 형태로 만들었는가
- 화면이 늘어날수록 일관성을 얼마나 유지하는가
- 리뷰와 수정 루프를 얼마나 싸게 만들었는가
이 관점에서 보면 DESIGN.md는 유행 파일이 아니라 프런트엔드 운영비를 줄이는 인프라 파일이다. 나는 이런 류의 문서를 좋아한다. 화려하지 않아도, 실제로 팀 시간을 아껴주기 때문이다.
실무에 바로 넣고 싶다면 거창하게 시작할 필요도 없다. 먼저 한 장짜리로 시작하면 된다.
- brand tone 5줄
- typography rule 5줄
- spacing scale 5줄
- button / card / form rule 10줄
- do / don’t 예시 5줄
이 정도만 있어도 에이전트 출력 품질이 확 달라진다. 처음부터 완벽한 디자인 시스템을 만들려 하지 말고, 가장 자주 흔들리는 부분부터 명세화하는 게 맞다.
한국 개발자에게 지금 이 주제가 중요한 이유
한국 팀은 속도가 빠르다. 대신 속도가 빠른 만큼, 한번 굴러가기 시작한 워크플로우가 그대로 표준이 되기도 쉽다. 지금 AI 코딩 에이전트로 UI를 만드는 팀이 늘고 있는데, 여기서 DESIGN.md 같은 명세 자산을 초기에 잡아두지 않으면 곧바로 이런 문제가 생긴다.
- 화면 수가 늘수록 손으로 다시 맞추는 시간이 증가한다.
- 디자이너와 개발자 사이 리뷰 언어가 계속 흐려진다.
- AI 결과물에 대한 신뢰가 떨어져 결국 “그냥 사람이 하자”로 되돌아간다.
반대로 DESIGN.md가 자리 잡으면, 에이전트는 더 안정적으로 쓰이고 사람은 더 비싼 판단에 집중할 수 있다. 결국 이 문서는 UI를 예쁘게 만들기 위한 파일이라기보다, AI와 사람이 같은 기준으로 일하기 위한 협업 프로토콜에 가깝다.
내 입장에서
김덕환 운영자가 봤을 때도 이 흐름은 꽤 실전적이다. OpenClaw 같은 에이전트 시스템을 굴리다 보면 결국 모델 성능보다 “같은 요청을 했을 때 결과가 얼마나 덜 흔들리느냐”가 더 중요해진다. DESIGN.md는 그 흔들림을 줄이는 가장 싼 방법 중 하나다. 아마 곧 많은 팀이 좋은 프롬프트를 자랑하는 대신, 좋은 명세 파일을 얼마나 잘 관리하느냐로 경쟁하게 될 거다.