[🤖] 결과물 디자인이 계속 달라졌다: DESIGN.md가 필요했던 이유

✨ GPT-5.6 Sol의 요약 　

브로셔 결과물이 매번 달라져 DESIGN.md를 찾았지만, 디자인 일관성의 필요성은 이미 다른 개인 프로젝트들에서도 오래전부터 느끼고 나름대로 적용하고 있었다. 흩어진 적용 기준을 AI가 계속 읽을 수 있는 형식으로 연결한 기록이다.

브로셔를 만들 때마다 디자인이 달라졌다

긴 연휴에서 복귀한 뒤, 지금 회사에서 브로셔 제작 업무를 이어가고 있다. 코디네이터와 워커를 관리하다가 정작 브로셔를 시간 안에 만들지 못한 뒤, 작업 방식은 줄였지만 디자인은 여전히 마음에 걸렸다. 같은 PPT 안에서도 페이지마다 분위기가 흔들리고, 새 버전을 만들 때마다 디자인이 새로 뽑혔다.

다른 프로젝트들도 크게 다르지 않았다. 나름대로 디자인 레퍼런스와 좋은 샘플을 찾게 하거나 직접 공유해주면서 통일성을 만들어보려 했다. 때로는 랜덤 뽑기라도 잘 나오기를 기대했다. 돌아온 것은 통일성도 없고 AI 냄새 풀풀 나는 D급 뽑기뿐이었다.

내가 원하는 것은 매번 그럴듯한 화면 하나를 뽑는 일이 아니었다. 같은 색, 같은 글자 위계, 같은 여백과 컴포넌트 감각이 다음 페이지와 다음 버전에도 이어지는 것이었다. 그런데 브로셔에는 그 기준이 없었다. AI는 레퍼런스를 받을 때마다 다시 처음부터 분위기를 추측하고 있었다.

처음 느낀 문제가 아니었다

돌이켜보니 디자인 일관성의 필요성을 이번에 처음 느낀 것도 아니었다. 이미 2025년 7월에 바이브 코딩으로 디자인 시스템을 어떻게 만들지 고민한 기록을 남겼다. 당시에도 Figma AI로 디자인하고, 화면과 코드를 레퍼런스로 저장하고, 타이포그래피와 컬러 팔레트를 정리한 뒤 실제 결과물을 비교하는 흐름을 생각했다.

타닥 바이블에서는 생각으로만 끝내지도 않았다. 2026년 1월부터 색상, 타이포그래피와 테마를 한곳에 모으기 시작했고, 파스텔 블루와 라벤더, 차분하고 따뜻한 분위기, 성경 타자 화면의 가독성 같은 방향을 문서에 적었다. 이후 BibleColors, BibleTypography, 간격, 모서리, 아이콘과 모션 토큰을 만들고 여러 화면에 적용했다. 새 화면이 임의의 색과 글자 크기를 다시 만들지 못하게 검사도 붙였다.

그러니까 나는 디자인 시스템이 왜 필요한지 이미 알고 있었다. 타닥 바이블 안에서는 제품의 색과 서체, 공통 컴포넌트를 코드와 문서로 묶는 방향으로 꽤 멀리 가고 있었다.

문제는 그 경험이 다른 프로젝트와 결과물로 이어지지 않았다는 것이다. 타닥 바이블의 기준은 타닥 바이블 문서와 Flutter 코드와 검사 안에 흩어져 있었다. 새 웹 프로젝트나 PPT를 시작한 AI가 곧바로 읽고 같은 감각을 이어갈 공통 형식은 없었다. 프로젝트마다 또 레퍼런스를 찾아주고, 또 샘플을 던지고, 또 잘 나오기를 기다렸다.

흩어진 기준을 DESIGN.md로 연결하려 했다

그러다가 한국 서비스의 디자인 시스템을 LLM 컨텍스트로 정리한 ko/design.md 카탈로그¹와 Google Labs Code의 DESIGN.md 저장소²를 발견했다.

이름과 샘플을 보니 어떤 파일인지 대충 느낌은 왔다. AI가 디자인을 만들 때마다 참고할 수 있도록 색, 서체, 간격, 컴포넌트와 전체 분위기를 한곳에 적어두는 파일 같았다. 이처럼 나도 타닥 바이블에서 이미 만들어온 디자인 기준을 Agent가 지속해서 읽을 수 있는 형태로 옮기고, 다른 프로젝트에서도 같은 방식으로 관리할 수 있겠다는 생각이 들었다.

문제는 여기서도 ‘대충’ 넘겨짚었다는 것이다. AI에게 DESIGN.md가 무엇인지 알아보고 샘플을 참고해서 비슷하게 만들어보라고 했다. 그 뒤에는 충분히 알아봤겠지, 충분히 적용됐겠지 하고 넘겼다. 공식 문서가 말하는 범위를 내가 직접 확인하지 않았고, 만들어진 파일이 그 범위를 지키는지도 보지 않았다. 실제 결과물에서 디자인 일관성이 생겼는지도 끝까지 검증하지 않았다.

AI가 링크를 읽고 그럴듯한 파일을 만들었다는 사실과, 내가 원한 디자인 기준이 제대로 생겼다는 것은 전혀 같은 일이 아니었다. 그 차이를 확인하지 않은 것은 내 잘못이었다.

제품 기획을 전부 DESIGN.md에 넣을 뻔했다

DESIGN.md의 범위를 제대로 확인하지 않은 상태에서, 나는 다음 제품 기획부터 사용자별 화면과 흐름, 상태, 권한, 복구까지 모두 DESIGN.md로 정리하려 했다. Codex도 그 말을 그대로 넓혀 받아들여 역할별 DESIGN.md와 별도 규칙을 만들기 시작했다.

뭔가 이상했다. UI 쪽을 제대로 다루지 않는 것 같았고, 내가 가장 중요하다고 건넨 Google Labs Code 샘플부터 확인하라고 다시 말했다.

원문을 읽고 나니 경계가 훨씬 분명했다. Google Labs Code의 DESIGN.md는 코딩 Agent에게 제품의 시각 정체성을 지속해서 알려주는 형식이다. YAML에는 정확한 디자인 토큰을 둘 수 있고, Markdown 본문에는 왜 그런 색과 서체와 형태를 쓰는지, 전체 디자인이 어떻게 보이고 느껴지며 동작해야 하는지를 적는다.³

여기서 ‘동작’한다는 말이 제품 기획 전체를 삼킨다는 뜻은 아니었다. 사용자 역할, 여정, 권한, 예외, 복구, 화면 구조와 검증은 기존 제품 문서에서 계속 자세히 다뤄야 했다. 내가 처음 하려던 역할별 상세 정리는 버릴 내용이 아니라 일반 docs/에 정리할 내용이었다. DESIGN.md라는 이름을 붙일 일이 아니었다.

형식을 따르는 것과 디자인을 베끼는 것은 다르다

경계를 바로잡고 나니 또 하나를 확인해야 했다. Google Labs Code를 기준으로 삼는다고 해서, 저장소의 예시 디자인을 그대로 베껴 모든 프로젝트에 적용하는 것은 아니다.

Google이 제공한 것은 디자인의 내용이 아니라 DESIGN.md라는 형식과 해석 방법이다. 예시에 나온 색, 서체, 분위기는 그 예시의 시각 정체성일 뿐이다. 실제 프로젝트의 DESIGN.md에는 그 제품의 사용자, 환경, 브랜드와 내가 선택한 레퍼런스에서 나온 시각 기준이 들어가야 한다. ko/design.md의 카탈로그도 참고하고 비교할 재료이지, 아무 디자인이나 골라 복사하면 자동으로 우리 제품의 정체성이 되는 것은 아니다.

그래서 공용 규칙과 제품 기획 Skill을 다시 고쳤다. DESIGN.md는 시각 정체성이 실제 범위에 있을 때만 하나를 만들고, 역할·여정·권한·복구와 상세 화면 설계는 일반 제품 문서에 남기게 했다. 처음에 멋대로 만든 역할별 DESIGN.md 방향은 없앴고, 최종 템플릿은 Google의 공식 검사도 통과시켰다.

이번에는 디자인 뽑기를 줄이겠다고 찾은 DESIGN.md의 의미까지 AI 뽑기에 맡겨버렸다. 링크를 주고 ‘알아보고 적용해’라고 말한 뒤 파일이 생긴 것만 보고 믿으면, AI는 내가 확인하지 않은 빈칸을 자기 방식으로 채운다.

DESIGN.md 하나가 좋은 디자인을 자동으로 만들어주지는 않는다. 특히 PPT라면 실제 슬라이드 마스터와 레이아웃 샘플을 만들고, 렌더링한 결과가 그 기준을 지키는지도 봐야 한다. 하지만 제품마다 내가 받아들인 시각 기준을 DESIGN.md에 정본으로 남기면, 적어도 AI가 매번 빈 화면에서 다시 분위기를 뽑는 일은 줄일 수 있다.

디자인 일관성의 필요성은 예전부터 알고 있었다. 타닥 바이블에서는 이미 디자인 시스템을 만들어가고 있었다. 이번에야 그 경험을 다른 프로젝트와 결과물까지 이어줄 Agent용 형식을 발견했고, 뒤늦게 DESIGN.md라는 이름과 연결했다.

참고 자료

1. ko/design.md, 한국 서비스 디자인 시스템 카탈로그. 한국 서비스의 시그니처 디자인을 LLM 컨텍스트로 제공한다. ↩

2. Google Labs Code, DESIGN.md. 코딩 Agent가 지속해서 참고할 수 있는 시각 정체성 형식을 소개한다. ↩

3. Google Labs Code, DESIGN.md specification. YAML 디자인 토큰과 Markdown 디자인 근거의 구조, 표준 section과 검사 규칙을 정의한다. ↩