디자인 시스템 다시 보기 (02) - 디자인 시스템은 어떻게 운영해야 살아남을까

디자인 시스템은 예쁜 자산이 많을 때보다, 변경이 같은 흐름으로 처리될 때 비로소 시스템처럼 움직입니다.

들어가며

앞선 글에서는 스타일 가이드, UI 키트, 컴포넌트 라이브러리, 디자인 시스템이 서로 다른 역할을 가진다는 점을 정리했습니다. 거기서 자연스럽게 남는 질문은 하나입니다. 그래서 디자인 시스템은 실제로 어떻게 운영해야 하는가입니다.

이 질문은 생각보다 중요합니다. 많은 팀이 Figma 라이브러리와 공통 컴포넌트를 갖추고도 제품이 조금씩 어긋나는 이유는, 자산이 부족해서가 아니라 변경을 다루는 방식이 느슨하기 때문인 경우가 많기 때문입니다.

그래서 이 글에서는 "전담 조직을 어떻게 꾸릴 것인가"보다 먼저, 디자인 시스템이 실제로 굴러가기 위해 어떤 운영 흐름이 필요한지에 초점을 맞추려고 합니다. 작은 팀이든 큰 팀이든, 완벽한 체계보다 먼저 필요한 것은 같은 변경을 같은 흐름으로 다루는 기준입니다.

운영은 전담 조직보다 먼저 같은 흐름의 문제입니다

디자인 시스템 운영이라고 하면 종종 전담 팀부터 떠올립니다. 물론 전담 팀이 있으면 좋습니다. 하지만 전담 팀이 있다고 해서 운영이 자동으로 좋아지는 것은 아닙니다.

핵심은 더 단순합니다. 토큰을 바꿨을 때, 컴포넌트를 수정했을 때, 문서를 고쳤을 때, 릴리스를 했을 때 이 변화들이 서로 다른 경로로 흩어지지 않고 하나의 변경 흐름 안에서 움직이는가입니다.

즉 운영의 핵심은 "누가 담당 팀인가"보다, 아래 질문에 답할 수 있는가에 가깝습니다.

질문	운영에서 필요한 답
무엇이 바뀌었는가	토큰인지, 컴포넌트인지, 패턴인지가 구분돼야 합니다
누가 확인하는가	디자인, 개발, 문서 중 누가 어떤 책임을 갖는지 보여야 합니다
언제 끝난 것으로 보는가	Figma 수정만으로 끝나는지, 코드와 문서 반영까지 포함하는지 정해야 합니다

이 기준이 없으면 전담 팀이 있어도 결국 메신저와 기억력에 기대게 됩니다. 반대로 작은 팀이어도 이 기준이 있으면 훨씬 안정적으로 운영할 수 있습니다.

먼저 정해야 할 세 가지 기준

운영을 복잡하게 시작할 필요는 없습니다. 처음에는 아래 세 가지를 정하는 것만으로도 상당히 많은 어긋남을 줄일 수 있습니다.

무엇을 기준 원본으로 볼지 정합니다

브랜드 표현의 기준은 스타일 가이드에, 화면 설계 자산은 Figma에, 실제 제품 동작은 코드 컴포넌트에 둘 수 있습니다. 중요한 것은 "모두가 한곳만 바라본다"가 아니라, 각 산출물이 어떤 책임을 가지는지 먼저 분명히 하는 일입니다.

변경을 어떤 단위로 묶을지 정합니다

토큰 하나를 바꾸는 일이라도 실제로는 Figma 수정, 코드 반영, 문서 갱신, 릴리스 노트가 함께 움직일 수 있습니다. 무엇을 하나의 변경으로 볼지 기준이 있어야 나중에 누락을 추적할 수 있습니다.

완료 조건을 어디까지 볼지 정합니다

디자이너가 시안을 바꿨다고 끝인지, 컴포넌트 배포까지 포함해야 끝인지, 문서 갱신까지 들어가야 끝인지가 정해져 있어야 합니다. 완료 기준이 흐리면 시스템은 늘 반쯤만 업데이트된 상태로 남기 쉽습니다.

이 세 가지는 화려하지 않지만, 실제 운영에서는 가장 효과가 큽니다. 시스템이 흔들릴 때는 대개 이 중 하나가 비어 있습니다.

작은 팀이라면 이 정도 도구 조합부터 시작해도 충분합니다

이 글에서 특정 툴 하나를 정답처럼 말하고 싶지는 않습니다. 다만 작은 팀 기준으로는 아래 정도 조합이면 운영 흐름을 만들기에 충분합니다.

목적	현실적인 최소 도구 예시	왜 필요한가
디자인 기준 관리	Figma Variables, Tokens Studio 같은 토큰 관리 도구	토큰 변경의 출발점을 한곳에 둡니다
변경 기록	GitHub Issue/PR, GitLab MR, Jira 티켓 중 하나	메신저 밖에 변경 단위를 남깁니다
코드 기준 관리	저장소 안의 token JSON, generated CSS/TS, 컴포넌트 코드	실제 반영 상태를 `git diff`로 확인할 수 있습니다
문서와 예시	Storybook, MDX 문서, 내부 컴포넌트 가이드	변경 영향 범위를 코드 바깥에서도 같이 봅니다
검토 장치	PR 체크리스트, visual review, screenshot diff	토큰만 바뀌고 문서가 빠지는 상황을 줄입니다

핵심은 툴 이름보다 역할입니다. Figma가 출발점이라면, Git은 변경을 기록하고 검토하는 지점이어야 하고, 문서는 완료 조건 안에 들어와야 합니다. 이 셋이 끊겨 있으면 어떤 도구를 써도 운영은 다시 사람 의존으로 돌아가기 쉽습니다.

예시 1: 브랜드의 기본 파란색이 바뀌었을 때

조금 더 구체적으로 보겠습니다. 예를 들어 브랜드의 기본 파란색이 #2563eb에서 #1d4ed8로 바뀌었다고 해 보겠습니다. 이때 시스템이 있는 팀이라면 보통 변경을 아래처럼 다룹니다.

디자이너가 Figma variable이나 토큰 원본을 먼저 수정합니다

여기서 끝나지 않습니다. "기준 원본이 바뀌었다"는 사실이 팀 안에 기록 가능한 변경으로 넘어가야 합니다.

토큰 export 파일이나 JSON 스냅샷을 저장소에 커밋합니다

그래야 개발자는 메신저 알림이 아니라 git diff로 무엇이 바뀌었는지 볼 수 있습니다. 색상 변경이 실제 파일 변화로 남는 것이 중요합니다.

생성 스크립트로 CSS 변수와 컴포넌트 토큰을 함께 갱신합니다

팀에 따라 Style Dictionary, 자체 스크립트, 빌드 스텝을 쓸 수 있습니다. 중요한 것은 토큰 원본과 생성 결과가 같은 변경 안에서 움직이는 일입니다.

완료 조건을 통과했을 때만 머지합니다

Figma만 바뀌었거나 코드만 바뀐 상태를 완료로 보지 않습니다. 코드와 문서와 시각 확인이 함께 끝나야 변경이 닫힙니다.

이 흐름에서 Git이 중요한 이유는 버전 관리 자체보다, 변경을 눈에 보이는 단위로 묶어 주기 때문입니다. 토큰 수정이 저장소 안의 diff로 남아야 개발자와 리뷰어가 같은 변경을 보고 이야기할 수 있습니다.

예를 들어 PR 체크리스트도 아래 정도면 충분히 유용합니다.

- [ ] Figma variable 또는 token 원본을 수정했습니다
- [ ] token export / JSON 스냅샷을 커밋했습니다
- [ ] generated CSS/TS 파일을 갱신했습니다
- [ ] 영향받는 컴포넌트와 예시 화면을 확인했습니다
- [ ] 문서 또는 컴포넌트 가이드를 함께 수정했습니다

토큰 변경은 사람이 알려 주는 방식보다 diff로 보이게 만드는 편이 낫습니다

많은 팀에서 토큰 변경은 여전히 "디자인 수정됐어요"라는 말로 전달됩니다. 문제는 이 방식이 바뀐 값을 설명할 수는 있어도, 무엇이 얼마나 바뀌었는지 추적하기 어렵다는 점입니다.

그래서 토큰은 가능한 한 아래 흐름을 갖는 편이 좋습니다.

Figma Variables 수정
-> token export(JSON 등) 커밋
-> generated CSS/TS 재생성
-> PR에서 diff 검토
-> 문서/컴포넌트 영향 확인

스크립트 이름은 팀마다 다를 수 있지만, 예를 들면 이런 식입니다.

# Figma에서 export한 토큰 파일을 기준으로 생성 결과를 다시 만듭니다.
pnpm tokens:build
 
# 생성 결과가 커밋되지 않았다면 CI나 로컬 체크에서 실패시킵니다.
git diff --exit-code tokens src/styles

핵심은 명령어가 아니라 원칙입니다. 토큰 변경은 "누가 알려 주면 반영하는 정보"가 아니라, 저장소 안에서 diff로 검토 가능한 변경이어야 합니다. 그래야 바뀐 값, 영향 범위, 누락된 파일이 한눈에 보입니다.

메신저 한마디로 굴리는 방식은 왜 오래 못 갈까

실무에서는 이런 장면이 흔합니다. 디자이너가 Figma에서 버튼 색과 간격을 수정한 뒤 팀 메신저에 "이 부분 수정됐어요. 반영 부탁드려요"라고 남깁니다. 개발자는 바쁜 일정 사이에서 그 메시지를 보고 필요한 부분만 코드에 반영합니다. 문서는 나중에 하기로 합니다.

이 방식은 당장 편리합니다. 별도 티켓을 만들지 않아도 되고, 승인 절차도 짧고, 팀 규모가 작을수록 빠르게 굴러갑니다. 그래서 많은 팀이 초반에는 이 방식을 자연스럽게 택합니다.

문제는 이 흐름이 시스템 안에 남지 않는다는 점입니다. 변경이 기록보다 사람의 기억에 남고, 문서보다 대화창에 남고, 기준보다 상황 판단에 남습니다. 그러면 어느 순간부터는 Figma는 최신인데 코드가 늦고, 코드는 바뀌었는데 문서는 옛날 내용이고, 새 컴포넌트는 생겼는데 예외 화면은 그대로인 상태가 쌓입니다.

즉 메신저 방식의 핵심 문제는 협업 도구가 메신저라서가 아니라, 변경이 추적 가능한 운영 흐름으로 남지 않는다는 점입니다. 이 지점부터 디자인 시스템은 자산이 아니라 느슨한 합의가 되기 쉽습니다.

같은 상황도 아래처럼 바꾸면 훨씬 낫습니다.

메신저에서 논의가 시작되더라도 최종 변경 단위는 이슈나 PR로 옮깁니다.
Figma 링크, 관련 토큰 이름, 영향받는 컴포넌트, 문서 수정 여부를 같은 기록에 남깁니다.
머지 전에 "코드만 반영했는지", "문서까지 끝났는지"를 체크리스트로 확인합니다.

도구는 바뀔 수 있어도, 메신저를 최종 기록으로 두지 않는다는 원칙은 꽤 오래 유효합니다.

예시 2: 버튼 컴포넌트 패딩 수정이 들어왔을 때

토큰이 아니라 컴포넌트 수정도 비슷합니다. 예를 들어 디자이너가 "기본 버튼의 좌우 패딩이 답답해 보여서 12px에서 10px로 줄이고 싶다"고 말하는 상황을 떠올려 보겠습니다.

이 요청을 그냥 구현으로 바로 넘기면, 개발자는 Button 컴포넌트의 값 하나만 바꾸고 끝내기 쉽습니다. 하지만 실제로는 먼저 몇 가지를 구분해야 합니다.

먼저 확인할 질문	이유
이 변경이 `Button`만의 수정인가	특정 컴포넌트 수정인지, 공통 spacing 토큰 수정인지가 달라집니다
`size=md`만 바꾸는가	모든 버튼 크기에 적용되는지 확인해야 합니다
기존 화면에 어떤 영향이 있는가	Dialog footer, form action, table action처럼 깨지는 곳이 있을 수 있습니다
문서와 예시 화면도 같이 바꿔야 하는가	컴포넌트 설명과 실제 구현이 어긋나지 않게 해야 합니다

즉 좋은 운영은 "바꾸지 말자"가 아니라, 변경의 성격을 먼저 분류하고 같은 변경 단위로 다루자에 더 가깝습니다.

이런 요청은 보통 아래 정도 템플릿으로 남기면 충분합니다.

변경 대상: Button / size=md
변경 이유: 기본 액션 버튼의 가로 밀도가 높아 보임
관련 토큰: spacing.inline.button-md
영향 범위: Form actions, Dialog footer, Toolbar
완료 조건:
- Figma 컴포넌트 수정
- Button 코드 반영
- 문서 예시 갱신
- 영향 화면 확인

이 정도만 남겨도 "디자인이 말했고 개발이 반영했다" 수준에서 끝나지 않고, 변경이 어떤 의미를 가지는지 팀이 함께 이해할 수 있습니다.

예외는 막는 것보다 회수하는 방식이 더 중요합니다

디자인 시스템을 운영한다고 해서 예외를 완전히 없앨 수는 없습니다. 제품 일정은 늘 급하고, 새로운 화면은 기존 자산만으로 설명되지 않는 경우도 많습니다. 그래서 현실적인 질문은 "예외를 금지할 수 있는가"가 아니라, 예외를 어떻게 남기고 나중에 회수할 것인가입니다.

예를 들어 급한 프로모션 페이지 하나 때문에 기존 버튼 규칙을 조금 벗어난 스타일이 필요할 수 있습니다. 이때 예외를 허용하는 것 자체는 큰 문제가 아닙니다. 문제는 그 예외가 아무 기록 없이 화면 안에 남아, 몇 주 뒤에는 누가 왜 그렇게 만들었는지 아무도 설명하지 못하게 되는 상태입니다.

그래서 예외를 다룰 때는 최소한 아래 정도는 남기는 편이 좋습니다.

왜 예외가 필요한지 남깁니다

단순히 급해서 넣었다가 아니라, 기존 자산으로 무엇을 설명하지 못했는지 이유가 남아야 나중에 공통화할 가치가 있는지도 판단할 수 있습니다.

누가 다시 볼지 정합니다

예외는 그냥 열어 두면 대부분 영구화됩니다. 다음 스프린트든, 다음 컴포넌트 정리 타이밍이든 다시 검토할 사람과 시점을 함께 잡아 두는 편이 낫습니다.

공통 자산으로 흡수할지 버릴지 결정합니다

자주 반복되는 예외라면 컴포넌트나 패턴으로 승격할 수 있고, 일회성이라면 종료와 함께 없애는 편이 맞습니다. 중요한 것은 예외가 설명되지 않은 채 남지 않게 하는 일입니다.

작은 팀이라면 Git과 PR을 이렇게 묶어도 충분합니다

처음부터 복잡한 승인 체계를 만들 필요는 없습니다. 오히려 작은 팀에서는 아래 정도의 Git 기반 루프만 있어도 디자인 시스템이 훨씬 덜 흔들립니다.

메신저 논의를 이슈나 PR로 옮깁니다

메신저에서 이야기가 시작될 수는 있습니다. 다만 최종적으로는 GitHub Issue, GitLab MR, Jira처럼 다시 찾아볼 수 있는 변경 단위로 옮겨야 합니다.

토큰, 코드, 문서를 가능한 한 같은 PR로 묶습니다

토큰이 바뀌었는데 코드 PR은 따로 있고 문서는 나중으로 밀리면 다시 어긋나기 쉽습니다. 한 PR에서 끝내지 못하더라도, 적어도 같은 이슈 아래에서 연결돼 보여야 합니다.

체크리스트로 완료 조건을 확인합니다

디자인 확인, 코드 반영, 문서 갱신, 영향 화면 검토 중 무엇이 끝났는지 눈에 보여야 합니다. 그래야 "반영은 됐는데 일부만 됐다"는 상황이 줄어듭니다.

머지 후에는 예외와 누락을 다시 봅니다

시스템 운영은 머지로 끝나지 않습니다. 남은 예외, 늦어진 문서, 공통 자산으로 올릴 가치가 있는 변경을 다음 정리 주기에 다시 봐야 합니다.

이 흐름을 꼭 거대한 프로세스로 이해할 필요는 없습니다. 작은 팀이라면 이슈 하나, PR 하나, 짧은 체크리스트 하나만으로도 운영 품질이 꽤 달라집니다.

운영이 잘 되고 있는지는 산출물보다 이런 신호로 보는 편이 낫습니다

운영이 제대로 되고 있는지 확인할 때도 자산 수를 먼저 세는 방식은 큰 도움이 되지 않습니다. 버튼이 몇 개 있는지, Figma 컴포넌트가 몇 개인지보다 아래 신호가 더 중요합니다.

신호	기대할 수 있는 상태
토큰이 바뀌면 관련 컴포넌트와 문서가 함께 움직입니다	변경이 사람의 기억이 아니라 흐름 안에서 다뤄집니다
새 화면에 같은 예외가 반복됩니다	공통 자산으로 흡수해야 할 패턴이 보이기 시작합니다
문서와 실제 구현 차이가 자주 발견됩니다	운영 흐름에서 완료 조건이나 갱신 책임이 비어 있을 가능성이 큽니다
시스템 변경이 늘 특정 사람의 기억에만 의존합니다	구조보다 개인 숙련도에 기대고 있다는 신호일 수 있습니다

즉 디자인 시스템 운영의 목표는 완벽한 통제가 아닙니다. 변경이 흩어지지 않게 만들고, 예외가 설명 없이 남지 않게 만들고, 문서와 코드가 함께 늙지 않게 만드는 것에 더 가깝습니다.

마치며

디자인 시스템은 결국 운영의 문제입니다. 좋은 스타일 가이드와 UI 키트, 공통 컴포넌트는 모두 중요합니다. 하지만 그것들이 실제 제품 안에서 오래 맞물리게 만들려면, 변경을 같은 흐름으로 다루는 기준이 먼저 있어야 합니다.

그래서 팀이 "우리는 디자인 시스템을 운영하고 있다"라고 말하려면, 어떤 도구를 쓰는지보다 변경 요청이 어디에 남는지, 누가 확인하는지, 무엇을 완료로 보는지, 예외를 어떻게 회수하는지를 설명할 수 있어야 합니다. 그 설명이 가능할 때 시스템은 비로소 이름이 아니라 실제 운영 방식이 됩니다.