Figma 화면을 AI로 구현해 보면서, 디자인 시스템을 다시 들여다보게 되었습니다.

처음에는 결과 화면이 원본과 얼마나 비슷한지에 눈이 갔습니다. 그런데 모양이 비슷하다고 같은 컴포넌트를 사용한 것은 아니었습니다. 화면을 비교하는 것만으로는 놓치는 차이가 있었습니다.

Figma에서 공통 컴포넌트와의 연결이 유지되어 있는지, Detach된 요소인지, 어떤 Variant를 선택했는지, 색상과 간격이 토큰에 연결되어 있는지가 구현을 판단하는 근거에 영향을 주었습니다.

그때부터 질문이 조금 달라졌습니다.

우리가 만든 디자인 시스템은 사람뿐 아니라 AI도 같은 기준으로 이해할 수 있는 상태일까?

컴포넌트를 만들고 문서에 등록하면 된다고 생각했습니다

디자인 시스템 구축 프로젝트에 참여하면서 처음에는 Figma에 정의된 컴포넌트를 React로 만들고 Storybook에 등록하면 된다고 생각했습니다.

하지만 실제로는 디자인 의도를 개발자가 사용할 수 있는 인터페이스로 바꾸는 과정이 필요했습니다. 같은 버튼이라도 아이콘 유무, 로딩 상태, 비활성 상태, 전체 너비 사용 여부에 따라 구현 기준이 달라졌습니다.

variant, size, disabled, loading 같은 Props는 단순한 속성이 아니라 컴포넌트를 만든 개발자와 사용하는 개발자 사이의 약속이었습니다. 디자인팀과 개발팀은 필수 상태, 접근성, 예외 처리까지 함께 정해야 했습니다.

이때까지 디자인 시스템은 주로 사람 사이의 협업 기준이라고 생각했습니다. 문서에 빠진 내용이 있으면 서로 질문하고, 기존 화면을 찾아보며 의도를 맞출 수 있었습니다.

AI가 화면 구현에 참여하면서는 그 빈칸을 어떻게 전달할지가 새로운 문제가 되었습니다.

같은 화면처럼 보여도 같은 컴포넌트는 아니었습니다

Figma에서는 공통 컴포넌트의 인스턴스와 연결을 끊은 요소가 당장 같은 모양으로 보일 수 있습니다. 토큰을 참조하는 색상과 값을 직접 지정한 색상도 현재 값이 같다면 화면만 보고 구분하기 어렵습니다.

하지만 이후 공통 기준이 바뀔 때 두 요소가 함께 바뀐다고 기대할 수는 없습니다. Variant와 상태 정의가 불명확하면 어떤 React 컴포넌트와 Props를 선택해야 하는지도 모호해집니다.

이번 경험에서 AI는 시각적 결과뿐 아니라 전달된 Figma 내부 구조를 구현 근거로 활용했습니다. 사람이 보기에는 같은 버튼이어도 컴포넌트 연결이나 상태 정보가 다르면 같은 구현으로 이어진다고 기대하기 어려웠습니다.

모든 AI 도구가 Figma를 같은 방식으로 읽는다는 뜻은 아닙니다. 다만 우리가 전달하는 구조와 맥락이 구현 판단에 영향을 준다는 점은 분명히 확인할 필요가 있었습니다.

Detach 자체를 무조건 잘못된 작업으로 볼 수도 없었습니다. 의도적인 예외라면 왜 공통 컴포넌트를 벗어났는지, 그 예외를 코드에서는 어떻게 표현할지 남겨야 했습니다. 문제가 된 것은 차이 자체보다 그 차이를 설명할 기준이 없는 상태였습니다.

구현 전에 확인할 기준을 더 명확하게 해야 했습니다

AI에게 화면을 맡기기 위해 전혀 새로운 기준이 필요한 것은 아니었습니다. 사람이 협업할 때 필요했던 약속을 더 명시적으로 정리하는 일이 먼저였습니다.

  • Figma 컴포넌트가 어떤 React 컴포넌트와 연결되는지
  • Variant와 상태를 어떤 Props로 표현하며 어떤 조합을 허용하는지
  • 색상·간격·폰트가 어떤 디자인 토큰을 참조하는지
  • 공통 컴포넌트를 벗어나도 되는 경우와 그 이유는 무엇인지
  • 구현 후 시각적 결과, 상태 변화, 키보드 동작과 포커스를 어떻게 확인할지

예를 들어 버튼의 색상이 같다는 사실과 같은 의미의 토큰을 사용했다는 사실은 다릅니다. 지금 보이는 값을 맞추는 데서 끝내면 이후 정책 변경을 함께 반영하기 어렵습니다.

컴포넌트 이름만 같아도 충분하지 않았습니다. 어떤 상태를 지원하고 어디까지 책임지는지 연결되어야 화면을 만드는 쪽에서도 재사용 여부를 판단할 수 있었습니다.

이 기준은 AI에게 더 많은 설명을 붙이기 위한 문서라기보다, 다음 구현에서도 같은 판단을 반복할 수 있도록 남기는 개발 자산에 가까웠습니다.

만드는 역할과 확인하는 역할에도 같은 기준이 필요했습니다

Builder·Review·Audit 역할을 나누면서는 검증 기준의 필요성이 더 분명해졌습니다.

화면을 만드는 역할과 결과를 검토하는 역할을 분리해도, 무엇을 확인할지가 불분명하면 각자 다른 기준으로 완료를 판단할 수 있었습니다. 모양이 비슷한지 확인하는 것만으로는 컴포넌트 재사용이나 토큰 연결까지 확인했다고 말하기 어려웠습니다.

그래서 역할 이름보다 각 역할이 확인할 근거를 정하는 일이 중요하다고 느꼈습니다. Builder는 사용할 컴포넌트와 허용된 Props를 참조하고, Review는 의도한 화면과 상태가 구현되었는지 확인하며, Audit은 공통 기준에서 벗어난 부분과 그 이유를 확인하는 식으로 책임을 구체화할 필요가 있었습니다.

이 구분만으로 품질이 보장되는 것은 아닙니다. 같은 자료를 참조하더라도 빠진 예외나 잘못된 기준은 사람이 다시 판단해야 합니다. 역할 분리는 그 판단이 필요한 지점을 찾기 위한 방법이어야 했습니다.

Storybook은 함께 참조하는 구현 기준으로 확장되었습니다

Storybook도 조금 다르게 보이기 시작했습니다.

처음에는 구현한 컴포넌트를 보여주고 디자인팀과 검수하는 문서라고 생각했습니다. 이제는 어떤 컴포넌트가 존재하고, 어떤 상태와 조합을 지원하며, 어떻게 사용해야 하는지 사람과 AI가 함께 참조할 수 있는 자산으로 볼 필요가 있었습니다.

기본 모습 하나만 등록되어 있다면 실제 화면에서 필요한 판단은 여전히 많이 남습니다. 로딩, 비활성, 오류와 같은 상태, 허용하지 않는 조합, 접근성 기준까지 연결되어 있어야 재사용할 때의 추측을 줄일 수 있습니다.

물론 Storybook에 등록했다는 사실만으로 AI가 그 내용을 자동으로 활용하는 것은 아닙니다. 작업에 필요한 컴포넌트 문서와 사용 예제를 참조할 수 있게 전달하고, 그 자료가 실제 코드와 일치하도록 유지해야 합니다.

Figma는 디자인 의도와 상태를, React 컴포넌트는 구현 가능한 인터페이스를, Storybook은 사용 예제와 검수할 상태를 보여줍니다. 이 셋의 연결이 유지될 때 다음 화면도 같은 기준에서 시작할 수 있습니다.

AI 도입은 이미 가진 자산을 다시 정리하는 일이기도 했습니다

AI로 화면을 만들어 보는 경험은 새로운 도구를 사용하는 일에서 시작했습니다. 하지만 그 과정에서 다시 확인하게 된 것은 기존 디자인 시스템의 연결과 운영 방식이었습니다.

디자인 시스템은 사람 사이의 약속에서 시작했지만, AI가 화면을 구현하기 시작하면서 기계도 참조하고 검증할 수 있도록 표현된 기준이 필요해졌습니다.

중요한 것은 AI가 얼마나 빠르게 화면을 만드는지만이 아니었습니다. 어떤 자산을 재사용하게 할지, 어디까지 허용할지, 결과가 기준을 지켰는지 무엇으로 확인할지가 먼저 준비되어 있어야 했습니다.

이번 경험을 통해 AI 도입의 출발점은 지금까지 쌓아 온 컴포넌트와 문서, 협업 기준을 다시 정리하는 일이기도 하다는 생각을 하게 되었습니다.