DESIGN.md부터 product taste까지, AI 시대 제품 개발자가 알아야 할 3가지 변화

AI가 코드를 짜주는데, 왜 결과물이 어딘가 어색할까요?

클로드 코드(Claude Code), 커서(Cursor), 깃허브 코파일럿(GitHub Copilot) 써보신 분들이라면 다들 한 번쯤 이런 경험을 하셨을 거예요.

화면이 기능적으로는 잘 돌아가는데, 뭔가 어딘가 어색합니다. 우리 브랜드 색상도 아니고, 폰트도 다르고, 버튼 모양도 제각각이에요. AI가 만들어준 화면 10장을 보면, 버튼 모서리 둥글기가 제각각이고 여백도 일관성이 없습니다. "AI가 만든 티"를 벗겨내느라 결국 시간을 다 써버리는 거죠.

그리고 또 다른 고민도 생겼습니다. AI가 만드는 속도는 엄청 올려줬는데, 정작 "뭘 만들어야 하는지"를 결정하는 일이 훨씬 더 어려워진 것 같습니다.

이 두 가지 고민에 각각 실용적인 답을 내놓은 사람들이 있습니다. 구글의 DESIGN.md 팀, 10년 차 빌더 조던 로드(Jordan Lord), 그리고 앤트로픽(Anthropic)에서 클로드 코드와 코워크(Cowork)를 이끄는 캣 우(Cat Wu)입니다.

오늘은 이 세 가지 이야기를 풀어보겠습니다. AI 시대에 제품을 만드는 분들이라면 꼭 한번 읽어보시길 추천드려요.

DESIGN.md, 이게 뭔지부터 짚고 가요

2026년 3월, 구글은 자사 디자인 도구 스티치(Stitch)를 대대적으로 업데이트하면서 DESIGN.md라는 포맷을 함께 선보였습니다. 그리고 4월 말에는 이 포맷 자체를 오픈소스로 공개했어요.

DESIGN.md는 한 마디로, AI 에이전트가 읽을 수 있는 디자인 시스템 설명서입니다.

기존에 README.md가 프로젝트를 "사람"에게 설명하는 파일이었다면, DESIGN.md는 디자인 규칙을 "AI 에이전트"에게 설명하는 파일이라고 보시면 됩니다. 마크다운이라는 단순한 텍스트 형식으로 만들어져 있어서, 별도의 플러그인이나 설정 없이 프로젝트 최상위 폴더에 넣어두기만 하면 됩니다.

공개 72시간 만에 깃허브 스타 5,000개를 돌파했고, 이를 활용한 awesome-design-md 저장소는 한 달 만에 스타 6만 8,000개를 넘겼습니다. 개발자 커뮤니티에서 이 정도 반응이라면 단순한 유행이 아닌 거죠.

매번 색상 코드 설명하던 그 번거로움, 이제 없앨 수 있어요

저도 처음엔 AI 코딩 에이전트에게 이런 설명을 반복했습니다.

"메인 색상은 #1A73E8이고, 본문 폰트는 Inter 16픽셀, 버튼은 모서리 반지름 8픽셀로 해줘."

프로젝트를 새로 열 때마다, 대화가 길어질 때마다 이 내용을 처음부터 다시 입력해야 했어요. DESIGN.md는 이 반복을 없애줍니다.

파일 구조는 크게 두 부분으로 나뉘어요. 앞부분(YAML 형식)에는 색상 코드, 폰트 크기, 간격 값 같은 정확한 수치가 들어가고, 뒷부분(마크다운 설명)에는 그 수치가 왜 존재하는지, 어떤 맥락에서 써야 하는지를 설명합니다.

실제로 클로드 코드나 커서에 스티치 MCP를 연결해서 사용해보면, AI가 DESIGN.md를 "시스템 규칙"으로 먼저 인식하고 코드를 생성합니다. 실무 사용자들의 경험을 보면 첫 코드 렌더링 결과가 시안과 약 90% 일치했다는 이야기도 들려오고 있어요.

DESIGN.md, 어떻게 만들면 될까요?

처음부터 직접 만드는 것보다 더 쉬운 방법이 있습니다.

첫 번째는 구글 스티치에서 자동 생성하는 방법입니다. stitch.withgoogle.com에 기존 웹사이트 주소를 입력하면 그 사이트의 디자인 규칙을 자동으로 추출해줍니다. 구글 계정이 있으면 한 달에 550회까지 무료로 사용할 수 있어요.

두 번째는 getdesign.md 사이트를 활용하는 방법입니다. 애플(Apple), 노션(Notion), 피그마(Figma), 스포티파이(Spotify), 버셀(Vercel) 등 이미 만들어진 70개 이상 브랜드의 DESIGN.md 파일이 정리되어 있습니다. 마음에 드는 브랜드 파일을 내려받아 색상과 폰트만 우리 브랜드에 맞게 수정하면 끝입니다.

세 번째는 직접 작성하는 방법입니다. 이미 피그마에 디자인 토큰이 정리되어 있거나 테일윈드(Tailwind) 설정 파일이 있는 팀이라면, 그 값들을 옮겨 쓰면 됩니다.

처음 시작한다면 두 번째 방법이 가장 현실적입니다. 오늘 당장 시도해볼 수 있는 방법이기도 해요.

어떤 AI 도구에서든 그대로 작동합니다

DESIGN.md의 진짜 강점은 특정 도구에 종속되지 않는다는 점입니다.

현재 클로드 코드, 커서, 깃허브 코파일럿, 키로(Kiro), 윈드서프(Windsurf), 구글 스티치에서 호환이 확인됐습니다. 프로젝트 루트에 파일 하나만 넣으면 되고, 별도 플러그인이나 설정이 필요 없어요.

도구를 바꿔도 내 브랜드 자산이 그대로 따라온다는 것, 생각보다 엄청난 이점입니다. 그리고 마크다운 텍스트 파일이기 때문에 깃(Git)에 올려두면 디자인 규칙의 변경 이력도 코드처럼 관리할 수 있어요.

다만 과장된 기대는 경계할 필요가 있습니다. DESIGN.md는 기존 코드 기반 디자인 시스템을 대체하는 게 아니라 보완하는 도구입니다. AI로 빠르게 초안을 잡고, 이후에 Tailwind 설정이나 CSS 변수로 구체화하는 워크플로우가 가장 현실적입니다.

만들기 전에 스스로 던져야 할 세 가지 질문

AI가 빠르게 만들어주는 시대일수록, 역설적으로 "만들지 말아야 할 것"을 거르는 기준이 더 중요해졌습니다.

10년간 여러 제품을 만들어온 개발자 조던 로드는 자신의 블로그에 세 가지 제약을 공개했습니다. 하나라도 통과하지 못하면 아예 만들지 않는다는 원칙이에요.

첫째, 한 페이지를 넘기면 만들지 않습니다. 모든 아이디어는 A4 한 장 분량의 문서로 정리되어야 합니다. 한 장을 채우지 못했다면 아직 아이디어가 덜 정리된 것이고, 반대로 한 장을 넘어간다면 너무 복잡한 제품이라는 신호입니다.

둘째, 핵심 기술은 제품과 분리되어야 합니다. 제품이 방향을 바꾸더라도 살아남을 수 있는 기술 자산이 있어야 합니다. 리누스 토르발스(Linus Torvalds)가 리눅스(Linux) 개발 편의를 위해 만든 것이 깃(git)입니다. 리눅스가 없어져도 깃은 살아남았죠. 방향을 바꿀 때마다 모든 것을 처음부터 다시 시작하면 쌓이는 것이 없습니다.

셋째, 하나의 결정적 제약이 제품을 규정해야 합니다. 마인크래프트(Minecraft)는 블록만으로 세상을 만들 수 있고, 노션(Notion)은 블록이라는 단위 하나가 전체 경험을 규정합니다. 이 제약이 없으면 모든 것을 하려는 비대한 제품이 됩니다. 정체성이 없는 제품은 아무도 기억하지 않아요.

앤트로픽 PM이 말하는 "프로덕트 테이스트"

앤트로픽에서 클로드 코드와 코워크 제품을 이끄는 캣 우는 레니스 팟캐스트(Lenny's Podcast)에 출연해 이런 말을 했습니다.

"코드가 싸지면, 무엇을 만들지 결정하는 능력의 가치가 올라간다."

그가 말하는 프로덕트 테이스트(product taste), 즉 제품 감각이란 수만 개의 요청 중 어떤 것을 만들 가치가 있는지, 만든다면 어떻게 만들지를 판단하는 능력입니다.

앤트로픽 프로덕트 팀은 피처 출시 주기를 6개월에서 1개월로, 다시 1주로, 때로는 하루로 줄였습니다. 2026년 1분기에만 클로드 코드에서 45개 이상의 새 기능을 출시했다고 해요. 이 속도를 가능하게 만든 것은 최신 모델만이 아닙니다. 조직 프로세스와 팀 기대치 전체를 바꾼 것이 핵심이었습니다.

특히 캣 우가 강조한 것 중 하나는 95% 자동화에서 멈추지 말라는 것입니다. 95% 정확도의 자동화는 나머지 5%를 사람이 확인해야 하기 때문에 여전히 수작업입니다. 100%에 도달해야 진짜 생산성이 생깁니다.

빠른 조직은 이렇게 움직입니다

캣 우가 소개한 앤트로픽의 세 가지 구조는 스타트업이나 소규모 팀에도 충분히 참고할 만합니다.

첫째는 리서치 프리뷰(Research Preview) 우선 출시입니다. 거의 모든 기능을 초기 단계임을 명확히 알리고 내보냅니다. 완벽하게 준비하려는 부담을 낮추면 1~2주 만에 결과물을 내보낼 수 있습니다.

둘째는 타이트한 프로세스입니다. 엔지니어가 내부 테스트를 마친 기능을 특정 채널에 올리면 마케팅과 문서 팀이 바로 다음 날 발표를 준비합니다. PM은 이 흐름이 막히지 않도록 조율하는 역할입니다.

셋째는 원칙 문서 공유입니다. 핵심 사용자가 누구인지, 어떤 타협을 감수할 수 있는지가 문서로 정리되어 있어 팀원 누구나 PM에게 묻지 않고 스스로 판단할 수 있습니다. 좋은 원칙 문서 하나가 수백 번의 회의를 대신합니다.

마무리: AI 시대의 진짜 희소 능력

DESIGN.md, 조던 로드의 3가지 제약, 캣 우의 프로덕트 테이스트. 이 세 가지는 서로 다른 주제처럼 보이지만 같은 방향을 가리킵니다.

AI가 실행을 대신해주는 시대에, 진짜 가치는 방향을 정하는 능력에서 나옵니다. 디자인 규칙을 파일 하나에 담아두는 것, 만들기 전에 아이디어를 한 장으로 정리하는 것, 수만 개의 요청 중 진짜 중요한 것을 가려내는 것. 이 모든 것은 AI가 대신할 수 없는 판단의 영역입니다.

지금 당장 DESIGN.md 파일 하나를 프로젝트에 추가해보세요. AI에게 매번 색상 코드를 설명하는 시간을 줄이고, 그 시간에 더 중요한 판단에 집중하는 것부터 시작할 수 있습니다.