디자인 시스템을 통일하지 않고 시작한 대가

색상 값 하나, 기준 글자 크기 한 줄을 처음에 정해 두지 않았습니다. 그 사소해 보이는 누락이, 나중에 화면마다 미묘하게 어긋나는 비용으로 돌아왔습니다. 같은 “파란색”인데 나란히 놓으면 다 다르고, 같은 클래스를 썼는데 화면마다 정렬이 안 맞았습니다. “스타일은 나중에 정리하면 되지”는, 이 프로젝트에서 가장 비싸게 갚은 거짓말 중 하나였습니다.

”디자인 시스템”이라는 게 뭔가요

화면을 그리는 일은 결국 수많은 작은 선택의 합입니다. 이 버튼은 무슨 파란색인가, 글자 사이 간격은 얼마인가, 카드의 모서리는 얼마나 둥근가, 제목과 본문 글자 크기 차이는 몇 배인가. 화면이 한 장이면 이 선택을 그때그때 즉흥적으로 해도 됩니다. 문제는 화면이 수십 장이 될 때입니다. 매번 즉흥적으로 고르면, 화면마다 조금씩 다른 답이 쌓입니다.

용어: 디자인 시스템

색·글자·간격·모서리·그림자 같은 시각 요소의 “정답값”을 한곳에 모아 두고, 모든 화면이 거기서만 꺼내 쓰게 하는 약속입니다. 화면을 예쁘게 만드는 일이 아니라, 모든 화면이 같은 규칙을 따르도록 강제하는 인프라에 가깝습니다.

용어: 토큰(token)

디자인 시스템 안에서 의미에 이름을 붙인 값입니다. 예를 들어 #3b82f6이라는 색을 화면마다 직접 적는 대신 --accent(강조색)라는 이름으로 한 번만 정의하고, 모든 화면은 그 이름을 부릅니다. 나중에 강조색을 바꾸고 싶으면 정의 한 곳만 고치면 전 화면이 따라옵니다.

화면마다 조금씩 다른 파란색

프로젝트 초기에는 화면을 빨리 만드는 게 가장 중요해 보였습니다. 그래서 영역마다 각자 편한 방식으로 스타일을 짰습니다. 어드민 페이지는 어드민대로, 전자결재 화면은 전자결재대로, 업무 모듈 페이지는 모듈대로. 어떤 화면은 색 값을 코드에 직접 박았고, 어떤 화면은 유틸리티 클래스를 썼고, 어떤 화면은 또 다른 변수를 만들어 썼습니다. 당장은 다 “파란색”이라 똑같아 보였습니다. 하지만 두 화면을 나란히 띄워 놓으면, 같은 위치의 파란색이 미묘하게 달랐습니다.

단일 출처가 없을 때 벌어지는 일(개념도). 세 화면 모두 "파란색"이라고 믿었지만, 정의한 곳이 셋이라 값이 갈라졌습니다. 멀리서 보면 비슷하지만 같은 화면에 모이는 순간 어긋남이 드러납니다.

왜 이런 분산이 생길까요. 사람 혼자 짜도 시간이 지나면 직전에 어떤 값을 썼는지 잊습니다. 그런데 AI와 짝을 이뤄 개발하면 이 분산은 훨씬 더 빨리 자랍니다. AI는 세션이 바뀌면 이전 맥락을 잊습니다. 직전 화면이 어떤 파란색을 썼는지 모른 채 새 화면을 그립니다. 그리고 명시적인 단일 출처가 없으면, AI는 “이 자리엔 이쯤 되는 파란색이 어울리겠다”며 매번 그럴듯한 값을 새로 만들어 냅니다. 그렇게 색·간격·폰트가 조용히, 그러나 꾸준히 갈라졌습니다.

root font 한 줄이 부른 전 화면 어긋남

가장 인상적인 사고는 색이 아니라 기준 글자 크기에서 나왔습니다. 웹에서는 모든 크기를 “기준 글자 크기의 몇 배”로 표현하는 방식(상대 단위)을 흔히 씁니다. 간격도, 여백도, 버튼 높이도 다 그 기준을 곱한 값입니다. 그런데 포탈의 기준 글자 크기를 표준값보다 살짝 작게 잡아 두자, 그 곱셈에 얹힌 모든 값이 전체적으로 미세하게 축소돼 박혔습니다.

함정 — 전역 기준 한 줄이 수십 화면을 동시에 틀어 버린다

한쪽 화면은 픽셀 고정값으로 치수를 잡고, 다른 쪽은 기준 글자 크기에 비례하는 상대 단위로 잡았다고 합시다. 기준 글자 크기가 표준과 다르면, 같은 의도로 짠 두 화면이 서로 다른 실제 크기로 그려집니다. 똑같은 클래스를 붙여도 옆 화면과 픽셀이 안 맞습니다. 범인은 화면 코드가 아니라, 아무도 의심하지 않는 전역 설정 한 줄입니다. 이런 버그는 “왜 2px이 안 맞지?”를 화면마다 반복하게 만듭니다.

비유하자면 이렇습니다. 모두가 같은 도면을 보고 가구를 짰는데, 한 팀만 자(尺)의 눈금이 살짝 다른 자를 썼습니다. 도면대로 정확히 만들었으니 각자는 잘못이 없습니다. 그런데 한방에 모아 놓으면 책상과 책장의 높이가 안 맞습니다. 기준 단위가 갈라지면, 아무도 틀리지 않았는데 전부가 어긋납니다.

왜 “나중에 통일”이 그렇게 어려운가

스타일은 “한 군데만 고치면 되는” 종류의 문제가 아닙니다. 화면 수십 개에 이미 제각각 박혀 버린 값을 하나의 토큰으로 수렴시키려면, 모든 화면을 다시 열어 점검해야 합니다. 게다가 화면마다 “이건 의도된 차이인가, 실수인가”를 사람이 판단해야 합니다. 자동으로 일괄 치환할 수 없는 회색지대가 끝없이 나옵니다.

시점	디자인 시스템 상태	”파란색 하나 바꿔 주세요” 비용
첫날	토큰 정의 1곳	정의 한 줄 수정 → 전 화면 자동 반영
3개월 후	값이 화면 수십 곳에 흩어짐	화면을 전부 열어 찾아 바꿈 + “이건 일부러 다른가?” 판단
통일 작업	하드코딩 → 전역 변수 교체 커밋 반복	만들 때 들인 시간만큼, 청소에 또 시간

실제로 작업 후반부에는 이런 종류의 커밋이 반복적으로 등장했습니다. 화면에 박힌 색 값을 전역 변수로 바꾸는 정리 커밋, 사이드바·헤더의 폭과 높이를 기준 화면에 맞춰 다시 정렬하는 커밋, 폰트 적용 방식을 한 가지로 통일하는 커밋. 새 기능을 만든 게 아니라, 이미 만든 것을 같은 모양으로 맞추는 작업이었습니다. 가치는 그대로인데 시간만 두 번 든 셈입니다.

처음부터 했어야 할 순서 — 토큰을 먼저, 화면을 나중에

되돌아보면 순서가 반대였어야 했습니다. 화면을 한 장이라도 그리기 전에, 단 하나의 디자인 시스템 문서와 단 하나의 전역 스타일 파일을 먼저 만들었어야 했습니다. 그러면 모든 화면은 “내가 쓸 색을 새로 정하는” 일 없이, 이미 정해진 토큰을 부르기만 하면 됐을 것입니다.

1. 토큰을 정의한다. 색·폰트·간격·모서리·그림자를 전역 변수(토큰)로만 정의합니다. 화면에서 raw 값(#3b82f6 같은)을 직접 쓰지 못하게 합니다.
2. 기준값을 못 박는다. 기준 글자 크기처럼 전역에 영향을 주는 값은 첫날 고정합니다. 나중에 바꾸면 전 화면이 동시에 흔들립니다.
3. 게이트로 강제한다. “정의되지 않은 클래스·색상은 금지”를 규칙으로 둡니다. 그러면 AI든 사람이든 토큰 밖으로 새지 못합니다. 규칙이 없으면 좋은 의도만으로는 분산을 못 막습니다.
4. 그 위에서 화면을 늘린다. 새 화면은 토큰을 소비할 뿐이라, 만들기만 하면 저절로 일관됩니다.

단일 출처(SSOT)가 주는 진짜 이득

토큰을 한곳에 모으면 얻는 건 “예쁨”이 아니라 변경의 비용이 작아진다는 것입니다. “강조색을 조금 진하게” 같은 요청이 와도 정의 한 줄만 고치면 끝납니다. 화면이 100개여도 마찬가지입니다. 반대로 단일 출처가 없으면, 같은 요청이 “100개 화면을 다 열어 보세요”가 됩니다. 디자인 시스템은 미적 취향의 문제가 아니라 유지보수 비용의 문제입니다.

AI 협업에서는 더더욱 필수입니다

이 교훈은 AI와 함께 개발할 때 특히 무겁습니다. 사람 협업자는 적어도 “어제 내가 쓴 파란색”을 어렴풋이 기억하고, “이 파일 색이 옆 화면과 다른데?” 하는 직관이 있습니다. AI 협업자는 세션이 바뀌면 그 기억이 0으로 리셋됩니다. 매 세션이 “처음 보는 코드베이스에 새로 합류한 신입”처럼 행동합니다. 그 신입에게 일관성을 기대하려면, 기억에 의존하지 않는 외부의 단일 출처를 줘야 합니다.

다시 말해, 디자인 시스템은 AI 협업에서 “있으면 좋은 것”이 아니라 일관성을 얻는 유일한 방법입니다. 기억이 끊기는 협업자에게 “지난번처럼 해 줘”는 통하지 않습니다. 통하는 건 “이 토큰만 써”라는 명시적 규칙뿐입니다.

상황	사람 협업	AI 협업
”옆 화면과 색이 다른데?”	대충 알아채는 직관이 있음	지적해 주지 않으면 모름 — 명시적 토큰 필요
지난 세션 맥락	어렴풋이 기억	세션이 바뀌면 0으로 리셋
일관성을 얻는 법	”지난번처럼”이 어느 정도 통함	”이 토큰만 써”라는 외부 규칙만 통함

교훈

디자인 시스템은 “예쁘게 만드는 일”이 아니라 일관성을 강제하는 인프라입니다. 화면을 한 장이라도 그리기 전에 ① 색·타이포·간격을 토큰(전역 변수)으로 단일 출처에 못 박고, ② 기준 글자 크기 같은 전역 값을 첫날 고정하고, ③ “토큰 밖 사용 금지”를 게이트로 강제하세요. 나중에 통일하는 비용은 처음에 통일하는 비용의 몇 배입니다. 그리고 세션마다 기억이 끊기는 AI 협업에서는, 단일 출처가 선택이 아니라 생존 조건입니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에, 이어지는 이야기는 〈포탈 통합 셸을 먼저 못 만든 것〉에 있습니다.