디자인 규칙은 실제 제품까지 이어져야 쓸모가 있습니다

AI는 당신처럼 디자인 시스템을 읽지 않습니다를 보면 컴포넌트가 있다는 것과 사용 기준이 전달된다는 것은 다른 문제입니다. 사람은 “그 조합은 지난번에 문제가 있었어”라는 대화로 빈칸을 채우지만, AI는 남아 있는 기록을 참고해야 합니다. 어떤 상황에 쓰고, 무엇과 함께 쓰면 안 되며, 예외를 왜 허용했는지까지 필요합니다. 라이브러리를 더 채우기 전에, 자주 틀리는 선택의 이유부터 기록해볼 만합니다.

Figma가 담지 못한 설계 의도를 명명 규칙으로 연결하기는 작은 이름 하나가 자동화에 어떤 정보를 주는지 보여줍니다. 아이콘 자산인지, 어떤 컴포넌트의 하위 항목인지 구분할 수 있으면 추출과 코드 생성 방식도 달라집니다. 다만 이름을 바꿨는데 화면은 멀쩡해서 연결이 끊긴 줄 모를 수도 있습니다. 명명 규칙을 정하는 일과 함께, 그 규칙이 깨졌을 때 알아차릴 방법까지 있어야 합니다.

디자인 시스템 2.0, 코드가 공동의 기준이 될 때는 실행되는 코드를 중심에 두는 작업 방식을 제안합니다. Figma, 문서, 코드에 같은 내용을 따로 관리하면 수정할 때마다 사본을 맞춰야 합니다. AI가 어느 쪽을 읽느냐에 따라 결과도 달라지고요. 모든 팀이 당장 작업 방식을 바꿀 필요는 없지만, 서로 다른 값이 나왔을 때 무엇을 따를지는 분명해야 합니다. 문서가 최신이라는 말보다, 실제 배포된 버전과 연결되어 있다는 확인이 더 든든합니다.

다시 찾아보게 되는 디자인 시스템 8개, 그 안의 의사결정에서 눈여겨볼 것은 버튼의 모양만이 아닙니다. 오류가 나면 입력값을 보존할지, 데이터가 일부만 있으면 어떻게 보여줄지, 공통 규칙으로 풀리지 않는 문제는 어디까지 확장할지 같은 판단입니다. 이런 내용이 있어야 팀이 같은 문제를 처음부터 다시 풀지 않습니다. 시스템을 정비할 때도 컴포넌트 목록보다 최근 반복해서 논의한 문제 하나에서 시작하면 필요한 문서가 더 잘 보입니다.