AI를 쓰기 시작하면서 아이디어를 서비스 형태로 옮기는 속도가 빨라졌다. 랜딩 페이지, 대시보드, 앱 화면처럼 예전에는 시간이 꽤 걸리던 작업도 이제는 훨씬 가볍게 시도할 수 있다.
여러 서비스를 만들다 보니 반복되는 작업이 보이기 시작했다. 프로젝트는 달라도 버튼, 카드, 인풋, 모달, 내비게이션 같은 기본 컴포넌트는 계속 등장했다. 새 프로젝트를 시작할 때마다 같은 컴포넌트를 다시 만들고 있었다.
AI가 컴포넌트를 빠르게 만들어주는 건 맞다. 문제는 매번 원하는 스타일을 다시 설명해야 한다는 점이었다. 버튼 높이, radius, 색감, 여백, 카드 밀도 같은 기준을 프롬프트에 계속 넣고, 나온 결과를 다시 고쳤다. 이미 정한 기준을 반복해서 설명하는 데 토큰을 쓰고 있었다.
결과물의 톤도 아쉬웠다. AI가 만든 UI는 빠르고 그럴듯하지만 기본값에 가까운 디자인으로 흐르기 쉽다. 어디선가 본 듯한 카드, 비슷한 SaaS 화면, 무난한 랜딩 페이지가 반복됐다.
내가 원한 건 빠른 생성만이 아니었다. 내가 선호하는 색감, 여백, 컴포넌트의 분위기가 여러 프로젝트에 걸쳐 유지되는 결과물이 필요했다. 그래서 재사용 가능한 컴포넌트와 디자인 기준을 가진 워크플로우를 만들기 시작했다.
OpenAI Symphony는 이슈 보드를 여러 에이전트의 작업 지시판으로 쓰는 방식이다. 이슈 하나가 에이전트가 처리할 작업 단위가 되고, 사람은 보드에서 작업 상태와 흐름을 확인한다.
내가 본 핵심은 에이전트 실행보다 작업 관리 방식이었다. 어떤 작업을 이슈로 만들지, 어떤 상태에서 실행할지, 결과를 어디에 남길지, 언제 사람에게 넘길지를 정하는 구조가 중요해 보였다.
AI 에이전트를 여러 개 붙이면 생산성이 올라갈 것처럼 보인다. 실제로는 역할과 기준이 없을수록 작업이 흩어진다. 에이전트가 많아질수록 누가 어떤 결과를 책임지는지 더 명확해야 한다.
그래서 관심이 갔던 부분은 자동화의 양이 아니었다. 각 에이전트가 맡는 일, 결과를 판단하는 기준, 다음 작업으로 넘기는 방식이었다. Symphony는 이 지점을 이슈와 상태, 라벨, 리뷰 흐름으로 다룬다.
디자인 시스템 작업도 비슷했다. 토큰 정리, 컴포넌트 제작, 문서 작성, 코드 구현은 연결되어 있지만 실제 작업에서는 자주 분리된다.
색상 토큰을 바꾸면 컴포넌트에 영향이 가고, 컴포넌트 구조가 바뀌면 문서와 코드도 같이 바뀌어야 한다. 이 흐름이 관리되지 않으면 각 작업은 따로 진행되고, 나중에 맞추는 비용이 커진다.
Symphony의 관점을 디자인 시스템에 적용할 수 있겠다고 본 이유가 여기에 있다. 디자인 시스템 작업을 큰 덩어리 하나로 두지 않고, 작은 작업 단위와 handoff 흐름으로 다루면 AI도 더 안정적으로 쓸 수 있다. 보드와 문서는 기록용을 넘어 실제 작업을 움직이는 칸반 역할을 맡는다.
디자인 시스템 작업을 하나의 큰 작업으로 두면 시작점이 흐려진다. 색상, 타이포그래피, 컴포넌트, 문서, 코드 구현이 한꺼번에 묶이기 때문이다.
Symphony를 보면서 먼저 떠올린 건 작업을 잘게 나누는 방식이었다. 색상 토큰 정리, 버튼 컴포넌트 정의, 카드 컴포넌트 구현, 사용 가이드 작성처럼 각각을 독립적으로 처리할 수 있는 단위로 나눌 수 있다.
이렇게 나누면 AI에게 맡길 일도 명확해진다. "디자인 시스템 만들어줘"보다 "이 토큰 기준에 맞춰 버튼 컴포넌트의 variants를 정리해줘"가 훨씬 안정적인 요청이다. 작업 단위가 작아질수록 필요한 맥락도 줄고, 결과 검토도 쉬워진다.
작업을 나눈 뒤에는 입력과 출력을 정해야 한다. 에이전트가 무엇을 읽고 무엇을 남겨야 하는지 정해져 있어야 다음 단계가 이어진다.
버튼 컴포넌트를 예로 들면 입력은 색상 토큰, 타이포그래피 기준, radius 기준, 버튼 상태 정의가 될 수 있다. 출력은 버튼 variants, 사용 예시, 코드 컴포넌트, 문서 초안이 될 수 있다.
입력과 출력이 정리되면 작업 간 연결이 선명해진다. 토큰 작업의 결과가 컴포넌트 작업의 입력이 되고, 컴포넌트 작업의 결과가 문서와 코드 작업으로 넘어간다. 디자인 시스템을 산출물 목록보다 작업 흐름으로 다루게 된다.
디자인 시스템에서 모든 결정을 AI에게 맡기기는 어렵다. 어떤 색을 쓸지, 어떤 분위기를 가져갈지, 컴포넌트 밀도를 어떻게 잡을지는 사람이 정해야 한다. 특히 내 색이 묻어있는 디자인을 만들려면 취향과 기준을 사람 쪽에 남겨야 한다.
반대로 정해진 기준을 바탕으로 variants를 정리하고, 반복되는 컴포넌트를 생성하고, 문서 초안을 쓰고, 코드 구조를 맞추는 일은 에이전트에게 맡기기 좋다.
Symphony식 접근은 자동화 범위를 무작정 넓히는 방식이 아니다. 사람이 방향과 기준을 정하고, 에이전트가 그 기준 안에서 반복 작업을 처리하게 만드는 방식이다. 이 구분이 있어야 AI를 써도 결과물이 흔들리지 않는다.
내가 구성한 워크플로우의 중심에는 Linear issue가 있다. 사용자가 "버튼 만들어줘", "검색바 컴포넌트가 필요해"처럼 요청을 남기면 그 이슈가 디자인 시스템 작업의 시작점이 된다.
이슈에는 현재 작업 상태, 필요한 입력값, 승인 여부, 다음 단계, 생성된 산출물 위치가 함께 기록된다. 이 정보를 담는 곳이 Symphony Workpad이다.
Workpad는 각 에이전트가 다음 단계로 넘어가기 전에 남기는 공통 작업 기록이다. Intake Agent는 Component Brief를 남기고, Token Agent는 사용할 토큰과 누락된 토큰을 기록한다. Figma QA Agent는 사람이 확인할 preview image와 digest를 남기고, Code QA Agent는 검증 결과를 기록한다.
Linear issue는 요청 공간이면서 에이전트들이 작업을 넘겨받는 지휘판이다. 사람이 보고 판단할 정보와 에이전트가 읽어야 할 상태가 한곳에 모인다.
이 워크플로우는 하나의 에이전트에게 모든 일을 맡기지 않는다. 작업을 여러 단계로 나누고, 각 단계마다 전담 에이전트를 둔다. 현재 단계를 나타내는 기준은 Linear의 ds:* 라벨이다.
ds:intake 라벨이 붙으면 Intake Agent가 실행된다. 이 에이전트는 사용자의 요청을 읽고 Component Brief를 만든다. 이후 ds:tokens로 넘어가면 Token Agent가 필요한 토큰을 검토한다. 그다음 ds:spec, ds:figma-structure, ds:figma-qa, ds:review 순서로 작업이 이어진다.
전체 흐름은 대략 다음과 같다.
Hozorica
ds:intake
-> ds:tokens
-> ds:figma-tokens
-> ds:icons
-> ds:spec
-> ds:figma-structure
-> ds:figma-qa
-> ds:review
-> ds:figma-register
-> ds:spec-finalize
-> ds:codegen
-> ds:code-qa
-> ds:pr
-> done
이렇게 나눈 이유는 디자인 시스템 작업의 성격이 단계마다 다르기 때문이다. 토큰 검토, Figma 컴포넌트 제작, 시각 QA, React 코드 생성, PR 정리는 필요한 기준과 검증 방식이 다르다.
각 에이전트는 자기 단계의 입력과 출력만 책임진다. 이 구조에서는 AI가 전체 맥락을 한 번에 들고 가지 않아도 된다. Workpad와 라벨을 통해 필요한 정보만 이어받고, 자기 단계의 결과를 다시 남기면 된다.
이 워크플로우에서 가장 중요한 게이트는 Figma 승인이다. 코드 생성은 Figma 결과물이 사람에게 승인된 뒤에 실행된다.
먼저 Spec Agent가 Draft Spec을 만들고, Figma Structure Agent가 그 기준으로 Figma component set과 review frame을 만든다. 이후 Figma QA Agent가 review frame을 캡처해서 Linear에 올린다. 사람은 Figma를 열지 않아도 Linear에 올라온 이미지를 보고 승인하거나 수정 요청을 남길 수 있다.
수정 요청이 있으면 ds:figma-structure로 돌아가 Figma 결과물을 고친다. 승인이 끝나면 Figma Registration Agent가 승인된 node를 registry에 등록하고, Spec Finalize Agent가 승인된 Figma 결과를 기준으로 Approved Spec을 확정한다.
그다음 Codegen Agent가 React 컴포넌트, CSS, Storybook, 테스트를 생성한다. Code QA Agent는 생성된 코드가 Approved Spec, token, Figma registry와 일치하는지 검증한다. 검증을 통과하면 PR Agent가 GitHub PR을 만들고 최종 리뷰와 merge 흐름으로 넘긴다.
이 구조의 초점은 빠른 산출물 생성보다 승인된 디자인 기준을 코드로 이어가는 데 있다. 디자인 시스템에서는 빠르게 만든 컴포넌트보다 재사용 가능한 기준으로 검증된 컴포넌트가 더 중요하다.
디자인 시스템을 처음 생각하면 버튼, 카드, 인풋 같은 컴포넌트 결과물이 먼저 떠오른다. 여러 서비스를 만들다 보니 컴포넌트 하나의 완성도만큼이나 계속 같은 기준으로 만들 수 있는 구조가 중요했다.
컴포넌트는 한 번 만들고 끝나지 않는다. 새로운 요구사항이 생기면 variant가 추가되고, 토큰이 바뀌면 시각적 기준도 함께 바뀐다. Figma에서 수정된 내용은 코드에 반영되어야 하고, 코드 변경은 문서와 테스트에도 이어져야 한다.
그래서 디자인 시스템을 결과물 모음보다 운영 체계로 보게 됐다. 요청이 들어왔을 때 어디서 시작하고, 누가 어떤 기준으로 판단하고, 언제 승인하고, 어떤 검증을 거쳐 반영할지 정해야 한다. Symphony 구조를 가져온 이유도 여기에 있다. 컴포넌트를 빨리 만드는 일보다 컴포넌트가 시스템 안으로 들어오는 과정을 관리하고 싶었다.
AI에게 "예쁜 버튼 만들어줘"라고 요청하면 그럴듯한 결과는 나온다. 디자인 시스템에서 필요한 결과는 일관된 결과다. 같은 토큰을 쓰고, 같은 컴포넌트 구조를 따르고, Figma와 코드가 같은 기준을 바라봐야 한다.
이 기준을 매번 프롬프트로 길게 설명하는 방식은 오래가기 어렵다. 프로젝트가 커질수록 설명해야 할 기준이 많아지고, 이전 결정과 새 작업 사이의 연결도 약해진다. AI가 잘 맞춰주기를 기대하기보다, AI가 읽을 수 있는 작업 맥락을 남겨야 했다.
이 워크플로우에서는 Linear issue, ds:* 라벨, Symphony Workpad, Draft Spec, Approved Spec, Figma registry로 맥락을 나눠 저장한다. 각 에이전트는 전체를 추측하지 않고, 자기 단계에 필요한 입력을 읽고 정해진 출력만 남긴다.
AI를 쓰면 결과물을 빠르게 만들 수 있다. 빠른 생성만으로 품질이 유지되지는 않는다. 어떤 작업에서는 괜찮은 컴포넌트가 나오고, 다른 작업에서는 토큰을 무시하거나 Figma와 코드 구조가 어긋날 수 있다. 문서와 테스트가 빠지는 경우도 생긴다.
그래서 반복 가능한 흐름이 필요했다. 이 워크플로우에서는 컴포넌트 요청이 들어오면 비슷한 순서를 따른다. 요청을 brief로 정리하고, 토큰을 확인하고, Draft Spec을 만들고, Figma 초안을 만든다. 이후 Figma QA와 사람 승인을 거친 뒤 코드 생성으로 넘어간다. 마지막에는 Code QA와 PR 리뷰를 통과해야 한다.
이 구조가 있으면 AI가 만든 결과물을 바로 믿지 않아도 된다. 각 단계마다 확인할 기준이 있고, 기준을 만족하지 못하면 이전 단계로 되돌릴 수 있다. 내가 이 방식을 택한 이유는 AI에게 일을 더 많이 맡기기 위해서보다, AI가 만든 결과물이 디자인 시스템의 기준 안에 들어오게 하기 위해서다.
이 구조에서 기대하는 가장 큰 효과는 일관성이다. 컴포넌트를 만들 때마다 기준을 새로 설명하지 않고, 토큰, Figma, Spec, Code, QA, PR로 이어지는 같은 흐름을 반복할 수 있다. 그러면 결과물이 매번 다른 방향으로 튀는 일을 줄일 수 있다.
추적 가능성도 얻을 수 있다. 어떤 컴포넌트가 어떤 요청에서 시작됐고, 어떤 Figma preview가 승인됐고, 어떤 spec을 기준으로 코드가 생성됐는지 남길 수 있다. 나중에 컴포넌트를 수정하거나 다른 프로젝트에 재사용할 때도 "왜 이렇게 만들었는지"를 다시 따라갈 수 있다.
온보딩 비용도 줄어든다. 새로운 작업자나 에이전트가 들어와도 Workpad와 ds:* 라벨을 보면 지금 작업이 어느 단계인지, 무엇을 입력으로 삼아야 하는지, 다음에 무엇을 넘겨야 하는지 알 수 있다.
현재 워크플로우는 새 컴포넌트 생성에 더 맞춰져 있다. 실제 디자인 시스템에서는 이미 만들어진 컴포넌트를 수정하는 일이 더 자주 생긴다.
버튼의 높이를 바꾸거나, Input의 상태를 추가하거나, 기존 컴포넌트의 Figma 구조와 코드 API를 함께 바꾸는 작업은 영향 범위를 더 조심해야 한다. 하나의 수정이 토큰, Figma registry, Approved Spec, React 코드, Storybook, 테스트에 모두 영향을 줄 수 있기 때문이다.
앞으로는 생성 워크플로우와 함께 수정 워크플로우도 정리하고 싶다. 어떤 변경은 Figma에서 먼저 검토해야 하는지, 어떤 변경은 코드에서 바로 수정해도 되는지, 변경된 컴포넌트의 영향 범위를 어떻게 검증할지 정해야 한다.
또 하나 고민하는 부분은 에이전트 간 handoff 검증이다. 지금은 각 에이전트가 이전 단계의 출력이 충분한지 확인하고, 다음 단계로 넘겨도 되는지 판단한다. 이 방식은 유연하지만 매번 Workpad를 읽고 조건을 해석해야 해서 토큰과 시간이 든다.
앞으로는 이 중 일부를 스크립트로 빼고 싶다. 현재 ds:* 라벨, Workpad의 필수 필드, artifact branch, 승인 digest, validation 결과처럼 기계적으로 확인할 수 있는 조건은 에이전트가 직접 판단하지 않고 스크립트가 먼저 검사하게 만들 수 있다. 에이전트는 스크립트가 통과시킨 입력을 바탕으로 자기 단계의 작업에 집중한다.
이렇게 하면 에이전트가 반복해서 상태를 해석하는 비용을 줄일 수 있고, handoff 조건도 더 일관되게 관리할 수 있다. 사람이 판단해야 하는 영역은 남기고, 기계적으로 확인 가능한 부분은 코드로 옮기는 방향이다.
지금은 디자인 시스템 안에서 컴포넌트를 만들고 검증하는 데 초점이 맞춰져 있다. 다음 목표는 이 디자인 시스템을 다른 프로젝트의 UI 생성 흐름까지 연결하는 것이다.
구상하고 있는 흐름은 이렇다. 먼저 다른 프로젝트에서 Figma로 와이어프레임을 그린다. 그다음 Codex plugin과 Figma library를 활용해 와이어프레임에 맞는 디자인 시스템 컴포넌트를 매핑한다. 이후 플러그인이 Figma 화면을 실제 디자인 시스템 컴포넌트 기반 화면으로 정리하고, 같은 구조를 코드 UI 생성까지 이어준다.
최종적으로는 "컴포넌트 하나를 만드는 워크플로우"를 넘어가고 싶다. 내가 만든 Figma library와 코드 패키지를 기반으로, 다른 프로젝트에서도 와이어프레임 -> Figma UI -> 코드 UI까지 이어지는 흐름을 만드는 것이 목표다. 그렇게 되면 디자인 시스템은 컴포넌트 저장소를 넘어 여러 서비스를 빠르게 만들기 위한 제작 인프라가 될 수 있다.
AI와 협업하는 디자인 시스템 만들기
