디자인 시스템 문서를 다 만들었는데 AI 결과물이 여전히 어색한 이유

디자인 시스템을 AI에 연결하는 작업을 마친 팀들이 공통으로 보고하는 상황이 있다. 색상 토큰은 맞게 쓰고 있고, 컴포넌트 모서리도 라운드 값이 정확하고, 폰트도 지정된 것을 가져오는데 — 화면이 우리 서비스 같지 않다. 어딘가 어색하다. 이 현상을 보고 AI가 디자인 시스템을 무시한다고 진단하면 원인을 잘못 짚은 것이다.

AI는 전달받은 정보 안에서 최선을 다해 추론한다. 문제는 전달된 정보 자체가 특정 유형의 판단을 지원하지 못하는 구조로 만들어졌다는 점이다.

토큰과 컴포넌트는 재료 목록이다

디자인 시스템의 대부분은 무엇이 있는지를 보여주는 데 집중한다. 색상 팔레트, 타이포그래피 스케일, 버튼 배리언트, 인풋 상태값. 이것들이 잘 정리돼 있으면 충분하다고 여기기 쉽다.

그런데 이것만으로는 언제 무엇을 골라야 하는지를 판단할 수 없다. 두 가지 버튼 스타일이 있을 때 이 화면에서는 어느 것을 써야 하는가. 카드 안의 제목에는 타이틀 스타일이 아니라 라벨 스타일을 써야 한다는 규칙은 어디에 적혀 있는가. 숫자가 셀 자리를 넘으면 말줄임표를 쓰는가, 줄 바꿈을 하는가.

이런 판단들은 보통 문서 어디에도 적혀 있지 않다. 팀 안에서 시간이 쌓이면서 만들어진 암묵적 합의이기 때문이다. 디자이너가 기존 화면을 보면서 패턴을 추론하거나, 동료에게 물어보거나, 리뷰에서 지적받으면서 체득한다. 사람이라면 이 과정이 가능하다. AI에게는 그 경로가 없다.

결국 AI는 재료 목록을 받고 용법을 스스로 추론한다. 서비스가 B2B 운영 도구인지, 소비자용 커머스인지, 의료 기록 플랫폼인지 알 수 없으니 범용적으로 그럴듯한 방향을 고른다. 토큰은 정확하게 적용했지만 맥락이 빠진 결과물이 나오는 이유가 여기 있다.

빠진 것은 사용 규칙, 예외 조건, 판단 이유다

디자인 시스템 문서가 AI에게 실질적으로 작동하려면 세 가지 층위가 모두 채워져야 한다.

첫째, 사용 규칙. 이 컴포넌트는 어떤 상황에 쓰는가. Primary 버튼은 사용자가 현재 화면의 핵심 작업을 완료할 때 쓴다, 한 영역 안에 하나만 있어야 한다, 단순 이동이나 취소에는 쓰지 않는다. 이런 문장들이 텍스트로 존재해야 한다.

둘째, 경계 조건. 텍스트가 길어지면 어느 지점에서 잘리는가. 비활성화 상태는 어떤 조건에서만 허용하는가. 로딩 중에는 버튼이 어떻게 보이는가. 에러 케이스와 빈 상태는 어떻게 처리하는가. 컴포넌트가 실제로 마주치는 극단 상황들이 문서 안에 포함돼야 한다.

셋째, 판단 이유. 이 규칙이 왜 존재하는가. 이 부분은 생략하기 가장 쉬운데, 사실 AI가 유사 상황에서 올바르게 추론하려면 원칙의 근거가 필요하다. "위험한 행동에는 빨간색을 쓴다"는 규칙보다 "삭제나 되돌릴 수 없는 작업에는 사용자가 멈추고 한 번 더 확인하게 만들기 위해 시각적 경고 색을 사용한다"는 설명이 AI가 비슷한 새 상황에서 올바르게 적용할 가능성을 높인다.

이 세 층위는 사람이 팀 생활을 하면서 암묵적으로 축적하는 것들이다. AI에게 전달하려면 명시적으로 꺼내 써야 한다.

파일 형식을 바꿔도 내용이 바뀌지 않는다

이 문제를 논의할 때 자주 등장하는 우회로가 있다. 마크다운 대신 JSON을 써야 하지 않을까. MCP 연결 방식이 다른 건 아닐까. 피그마 변수를 어떤 방식으로 추출해야 할까.

파일 형식은 AI가 정보를 읽어들이는 방식에 영향을 줄 수 있다. 그러나 내용이 달라지지는 않는다. 사용 규칙이 없던 문서를 JSON으로 변환하면 기계가 읽기 좋은 형태로 정렬된 빈 칸이 될 뿐이다. 형식 최적화는 내용이 충분히 갖춰진 다음 단계의 작업이다. 결과물 퀄리티가 낮다면 형식을 바꾸기 전에 문서에 사용 규칙과 경계 조건이 실제로 들어가 있는지를 먼저 확인하는 것이 순서다.

문서 정비가 끝나도 학습 루프가 남아 있다

문서를 충분한 수준으로 만들었다고 해서 AI 결과물이 바로 실무 수준으로 나오지는 않는다. 문서는 시작점이다.

이후에는 실제 화면 생성을 요청하고, 우리 가이드라인과 어긋난 지점을 피드백하고, 다시 생성하는 과정을 반복해야 한다. 이 루프에는 비용이 따른다. 토큰 비용보다 더 큰 것은 시간이다. 팀 내에서 이 반복을 감당할 수 있는 일정과 담당자를 미리 배분하지 않으면 문서 정비에 공을 들이고도 운영 단계에서 흐지부지되기 쉽다.

이 과정에서 팀이 준비해야 하는 것이 하나 더 있다. AI 결과물을 보고 가이드라인에 맞는지 아닌지를 판단할 수 있는 사람이 있어야 한다. AI가 잘못 적용한 부분을 짚어주지 못하면 피드백 루프가 제대로 작동하지 않는다. 결국 AI에게 디자인 시스템을 가르치는 과정은 팀이 자신의 설계 원칙을 얼마나 명확하게 언어화할 수 있는지를 검증하는 과정이기도 하다.

AI가 자꾸 틀리는 지점이 실제로 빠진 규칙을 가리킨다

이 관점을 뒤집어 보면 유용한 신호가 있다. AI가 반복적으로 같은 방식으로 틀린다면, 그 틀림의 패턴이 문서에서 명시되지 않은 규칙의 위치를 정확하게 가리키고 있을 가능성이 높다.

AI가 계속 한 화면에 Primary 버튼을 두 개 이상 넣는다면, 그 규칙이 문서 어디에도 쓰여 있지 않다는 뜻이다. AI가 숫자를 말줄임표로 자르는 선택을 반복한다면, 줄 바꿈 규칙이 명시되지 않은 것이다. 이렇게 보면 AI와의 반복 생성 세션은 디자인 시스템 문서의 빈 칸을 찾아내는 검증 과정으로도 활용할 수 있다.

그리고 이렇게 완성된 문서는 AI만을 위한 것이 아니다. 사용 규칙과 판단 이유가 명시된 문서는 새로 합류한 팀원이 맥락을 익히는 시간을 줄이고, 디자인 리뷰에서 같은 피드백이 반복되는 빈도를 낮춘다. AI에게 디자인 시스템을 설명하려는 시도가 결국 팀 내부 지식 정리로 이어지는 것은 자연스러운 수순이다.