알스솔루션
디자인 시스템 구축
신설 조직의 멀티 프로젝트 환경을 위한 사내 범용 디자인 시스템. Bootstrap 기반 커스텀 컴포넌트 라이브러리 위에 CSS Variables로 사내 정체성 토큰을 입힌 Monorepo 구조
주요 성과
- 백오피스 도메인 비중이 높은 사내 환경에 맞춰 컴포넌트 풍부도·디자인 커스터마이징 용이성·반응형 그리드 성숙도를 종합 검토하여 Bootstrap 채택
- 사내 디자인 토큰을 CSS Variables로 추상화하여 Bootstrap 기본 스타일 위에 사내 정체성 레이어를 일관 적용
- 색상·타이포·간격·레이아웃을 단일 토큰으로 정의하여 토큰 1회 변경으로 시스템 전반 갱신
- 컴포넌트를 Monorepo 단위 패키지로 분리하여 UI 자산의 독립 배포·버전 관리 구조 확보
- 라이트/다크 테마를 토큰 레이어에서 분기. 컴포넌트 코드는 테마 인지 없이 동작하도록 분리
- 백오피스 신규 프로젝트의 첫 적용을 통해 토큰·컴포넌트 구조를 운영 환경에서 검증한 뒤 사내 표준 라인업으로 정착
설계 자세히 보기
신설 조직이라 참고할 사내 자산이 없었다. 무엇을 기준으로 베이스를 골랐고, 사내 정체성을 어느 층에 올렸으며, 왜 컴포넌트를 패키지 단위로 쪼갰는지 — 이후 사내 디자인 시스템 3종의 출발점이 된 결정들.
1. 무엇을 기준으로 골랐나
“요즘 많이 쓰는 것”이 아니라 사내 프로젝트가 실제로 그릴 화면을 기준으로 삼았다. 세 축으로 검토해 Bootstrap을 택했다.
컴포넌트 풍부도
사내 프로젝트는 백오피스 비중이 높다. 테이블·폼·모달처럼 운영 화면이 매일 쓰는 부품이 기본으로 갖춰져 있어야 0에서 만드는 시간이 줄어든다.
디자인 커스터마이징 용이성
기본 스타일을 그대로 쓸 게 아니라 사내 정체성을 입혀야 했다. 라이브러리 내부를 뜯지 않고 위에서 덮을 수 있는 구조인지가 관건이었다.
반응형 그리드 성숙도
화면 밀도가 높은 운영툴은 레이아웃이 곧 사용성이다. 그리드를 직접 만들면 프로젝트마다 규칙이 갈린다.
2. 정체성은 위에 얹고, 베이스는 건드리지 않는다
Bootstrap을 그대로 쓰면 사내 정체성이 없고, 내부를 뜯어고치면 업그레이드 경로가 막힌다. 그래서 사이에 토큰 레이어를 넣었다. 색상· 타이포·간격·레이아웃을 CSS Variables 단일 이름 집합으로 정의하고, 컴포넌트는 그 이름만 참조하게 했다.
이 구조의 값은 다크모드에서 분명해졌다. 테마가 갈리는 지점이 토큰 레이어 한 곳뿐이라, 컴포넌트는 지금 어떤 테마가 켜져 있는지 알 필요가 없다. 테마 대응이 컴포넌트마다 분기문으로 번지지 않는다.
3. 왜 하나의 패키지가 아니라 여러 패키지인가
동시에 여러 프로젝트가 굴러가는 환경이었다. 디자인 시스템을 한 덩어리로 배포하면 버튼 하나를 고쳐도 모든 프로젝트가 같은 버전을 받아야 하고, 그 순간 “업데이트하면 뭐가 깨질지 몰라서” 아무도 올리지 않는 상태가 된다. 그래서 컴포넌트를 Monorepo 안의 단위 패키지로 쪼개 각 프로젝트가 필요한 것만 원하는 버전으로 가져가게 했다.
4. 만들고 끝내지 않는다 — 운영에서 검증
디자인 시스템은 쓰이기 전까지 가설이다. 그래서 곧바로 사내 표준으로 선언하지 않고, 사내 백오피스 신규 구축에 첫 적용해 실제 운영 화면에서 토큰·컴포넌트 구조를 검증한 뒤 표준 라인업으로 정착시켰다.
→ 이 프로젝트가 이후 사내 디자인 시스템 3종의 출발점이 됐다. 전체 흐름은 디자인 시스템 스토리에 정리해 뒀다.