6장 네 개의 디자인 시스템

Leysys는 화면과 출력물을 쓰임새에 따라 네 개의 디자인 시스템으로 나누고, 서로 기대지 않게 완전히 분리합니다. 한 화면은 한 시스템만 쓰며, 어느 시스템을 쓸지는 화면의 접점 유형이 정합니다.

왜 필요한가

업무 관리 화면과 대중용 화면은 같은 버튼이라도 놓이는 환경이 다릅니다. 관리 화면은 표와 폼이 빽빽한 데스크톱 화면이 중심입니다. 대중용 화면은 카드와 행동 버튼이 많고, 휴대폰에서 먼저 성립해야 합니다. 시스템 하나로 둘을 맞추면 한쪽의 밀도나 크기가 어긋납니다.

종이는 또 다른 매체입니다. 인쇄물은 화면 픽셀이 아니라 mm와 pt로 잽니다. 화면 값 16px을 기계적으로 바꾸면 사람이 읽고 잴 수 없는 긴 소수가 나옵니다.

시스템을 나누되 공통 기반을 함께 쓰는 방법도 있습니다. Leysys도 한때 공통 시스템(CDS)을 두 화면 시스템이 함께 쓰는 CSS 기반으로 두었습니다. 그러나 측정해 보니 두 시스템은 이미 의미 수준에서 갈라져 있었고, 함께 쓰는 것은 팔레트 원본 값 정도였습니다. 그런데도 토큰마다 「어느 쪽 것인가」를 따져야 했습니다. 그래서 2026-05-30 KST에 공유 기반을 없애고 완전히 분리했습니다. 판단 기준은 중복 제거(DRY)보다 일관성이었습니다.

네 시스템

시스템	대상	단위와 매체	이름 접두
EDS (Enterprise Design System)	관리·ERP·CRM 같은 B2B·B2G 업무 화면	화면, 데스크톱 우선, 높은 정보 밀도	e-, --e-*, E*
MDS (Mass·Marketing·Mobile Design System)	대중 대상 서비스, 마케팅, 반응형 제품 화면	화면, 모바일 우선 반응형	m-, --m-*, M*
Print DS (Print Design System)	A4·A3 종이 문서와 PDF	글자는 pt, 위치와 간격은 mm	print-, --print-*
CDS (Common Design System)	공통 참고 자료	CSS 0, 코드 0	없음

• EDS는 표, 폼, 대시보드처럼 정보가 많은 업무 화면을 위한 시스템입니다.
• MDS는 모바일 전용이 아닙니다. 마케팅 사이트, 대중 서비스, 반응형 제품 화면을 한 체계로 다룹니다. 안전 영역(safe area), 화면 키보드, 굵은 포인터(coarse pointer)처럼 매체에 따른 특성만 MDS 안에서 조건부로 보강합니다. 모바일용 시스템을 따로 만들지 않습니다.
• Print DS는 .print 매체 루트(media root) 위에서 용지, 여백, 조판, 표를 다룹니다. 글자 크기는 정수 pt, 위치와 간격은 정수 중심 mm를 씁니다. px와 rem은 쓰지 않습니다. 다크 모드는 없고, 출력 의도는 컬러(color)와 흑백(mono) 두 가지입니다.
• CDS는 CSS도 코드도 배포하지 않습니다. 참고 자료 두 종류만 둡니다. 하나는 CSS 없이 HTML 구조만 적은 공통 구조 참고입니다(예: native <dialog>의 머리글·본문·바닥글 구조). 다른 하나는 진영과 무관한 수학 자료로, 현재는 팔레트 대비 측정값 color-accessibility.json입니다. CDS 정본의 표현대로 공유의 단위는 값이 아니라 규칙과 구조입니다.

이 책에서 진영은 EDS·MDS처럼 각자 이름 접두를 가진 시스템 하나를 가리킵니다.

패키지로 세면

「네 개」는 역할로 센 숫자입니다. 배포 패키지로 세어도 넷이지만 구성이 조금 다릅니다. CDS는 배포할 것이 없어 패키지가 없습니다. 대신 독립 문서 사이트용 Markdown DS가 있습니다. Markdown DS는 Markdown이나 CMS가 만든 시맨틱 HTML을 .md-typeset 하나로 조판합니다.

패키지	내용
@leysys/eds	EDS CSS, 토큰, 클래스 목록
@leysys/mds	MDS CSS, 토큰, 클래스 목록
@leysys/print-ds	Print DS CSS, 토큰, 클래스 목록
@leysys/markdown-ds	문서 조판 CSS, 토큰, 선택형 어댑터

네 패키지는 같은 버전 번호로 함께 게시하며, 이 책은 3.1.3을 기준으로 합니다. 시스템마다 패키지를 하나씩 둔 데에도 이유가 있습니다. 관리 콘솔 저장소는 @leysys/eds만 설치하므로 MDS 클래스가 처음부터 존재하지 않습니다. 섞지 않는다는 규칙을 의존성 수준에서 물리적으로 지키는 셈입니다. 배포와 채택 절차는 24장에서 다룹니다.

완전 분리

분리는 세 층에서 지킵니다.

1. CSS와 토큰. 각 시스템은 자기 접두의 토큰만 정의하고 참조합니다. 같은 컬러 모델에서 나온 값도 EDS는 --e-palette-color-*, MDS는 --m-palette-color-*로 각자 복제해 둡니다. 2026-10-04 KST에 소스를 확인했을 때 MDS가 EDS 토큰을 참조하는 곳과 그 반대는 모두 0건이었습니다.
2. 화면. 한 페이지는 한 시스템만 씁니다. EDS와 MDS의 컴포넌트, 클래스, 토큰을 섞지 않습니다. 섞으면 같은 역할의 토큰과 컴포넌트가 두 벌이 되어 서로 충돌합니다. 인쇄 페이지와 문서 사이트도 자기 시스템 하나만 씁니다.
3. 복사해 쓰는 Vue 컴포넌트. Leysys는 Vue 컴포넌트를 패키지가 아니라 복사본 묶음(registry)으로 제공하고, 제품이 복사해 소유합니다. 이 복사본도 진영끼리 import하지 않습니다. 두 진영이 함께 쓰던 보조 코드도 각자 복제합니다. 예를 들어 폼 필드 상태를 전하는 context는 EDS가 FIELD_CONTEXT, MDS가 M_FIELD_CONTEXT를 따로 가집니다.

세 번째 규칙은 실제 사고에서 나왔습니다. MDS만 쓰는 새 제품 저장소를 준비하다가, MDS 컴포넌트 일부가 EDS 쪽 보조 코드를 import하고 있다는 것을 발견했습니다. MDS 컴포넌트만 복사하면 실행 중에 깨지는 구조였습니다. 공유 코드를 중립 위치에 모으는 안도 검토했지만, 2026-06-19 KST에 각 진영이 복제하는 안을 택했습니다.

• 한 페이지는 한 진영만 쓰므로, 실행 중에 코드를 공유해서 얻는 이득이 없습니다.
• MDS 전용 제품은 m-*만 복사해도 동작해야 합니다.
• 규칙이 하나로 줄어듭니다. 「자기 진영 밖을 import하지 않는다. 필요한 것은 모두 자기 진영 안에 있다.」 AI 에이전트가 예측하기 쉬운 규칙입니다.
• 두 시스템은 지금 모양이 같을 뿐 대상이 다릅니다. 미리 묶어 두면 한쪽 변경이 다른 쪽으로 샙니다.
• 복제본은 바이트 단위로 같게 두고 동기화 규율로 관리합니다. CSS에서 이미 쓰던 방식입니다.

실제 예

접점 유형으로 고른다

어느 시스템을 쓸지는 화면의 접점 유형(surface)이 정합니다.

접점	성격	시스템
console	고객사 관리 작업 공간	EDS
center	운영자·파트너 백오피스	EDS
portal	셀프서비스	MDS
kiosk	공용 단말	MDS
www	마케팅 사이트	MDS
모바일 전용 화면	휴대폰 전용 경험	MDS
백엔드(API)	화면 없음	해당 없음

• 사용자 집단은 시스템을 바꾸지 않습니다. 직원용이든 고객용이든 셀프서비스 포털이면 MDS입니다.
• 화면 폭(viewport)으로 시스템을 바꾸지 않습니다. 데스크톱에서 보더라도 portal·www 같은 접점이면 MDS입니다. MDS 안에서 좁은 폭을 기본으로 만들고 넓은 폭은 반응형으로 확장합니다.
• 예를 들어 Leyve의 관리 콘솔과 본사·파트너 관리 앱(Leyve Center)은 EDS를, 고객용 모바일 포털과 마케팅 사이트는 MDS를 씁니다.

저장소와 호스트 이름 규칙은 19장에서 다룹니다.

같은 「주 버튼」, 다른 이름

두 시스템은 이름을 기계적으로 1:1 대응시키지 않습니다. 같은 역할도 각 진영의 정본을 따릅니다. 가장 중요한 실행 버튼이 좋은 예입니다.

<!-- EDS: 역할 색 + 강도 -->
<button class="e-button e-button-md e-button-primary-bold">저장</button>

<!-- MDS: 역할 색 + 형태 -->
<button class="m-button m-button-md m-button-primary-solid">저장</button>

EDS는 강도 어휘(bold)로, MDS는 형태 어휘(solid)로 표현합니다. 두 어휘의 차이는 9장에서 설명합니다. 이름 체계가 이렇게 다르다는 점도 한 화면에서 두 시스템을 섞지 않는 이유입니다.

경계와 예외

• CDS는 공통 기반이 아닙니다. import할 CSS나 코드가 없고, CDS가 없어도 두 시스템은 동작합니다.
• 복제는 중복이 아닌가. 중복 제거 원칙은 의미가 같을 때 적용합니다. EDS와 MDS는 서로 다른 시스템이라 이 원칙의 예외입니다. 같은 접근성 계약을 복제해도 진영이 섞이지 않습니다. 두 context는 서로 다른 Symbol(leysys-field-context, leysys-m-field-context)이라 서로에게 주입될 수 없습니다.
• 제품 화면 안의 Markdown. EDS·MDS 화면 안에서 렌더하는 Markdown은 그 화면 시스템의 .e-typeset이나 .m-typeset을 씁니다. Markdown DS는 독립 문서 사이트용입니다.
• 관리 화면의 모바일 전용판. EDS 콘솔도 반응형이라 좁은 화면에서 동작합니다. 관리 화면을 휴대폰 전용으로 따로 만든다면 모바일 전용 접점이므로 MDS를 쓰지만, 대부분은 반응형 콘솔로 충분합니다.

정리

• EDS는 업무 관리 화면, MDS는 대중용 반응형 화면, Print DS는 종이와 PDF, CDS는 CSS·코드 없는 공통 참고 자료입니다.
• 배포 패키지는 @leysys/eds·@leysys/mds·@leysys/print-ds·@leysys/markdown-ds 넷이며, 이 책은 3.1.3을 기준으로 합니다.
• 토큰, 화면, 복사본 컴포넌트의 세 층에서 진영 간 의존을 0으로 둡니다. 함께 쓰던 코드도 각자 복제합니다.
• 시스템은 접점 유형으로 고릅니다. 사용자 집단이나 화면 폭으로 바꾸지 않습니다.

정본

• leysys-design docs/specs/EDS.md — EDS 규격
• leysys-design docs/specs/MDS.md — MDS 규격과 반응형 원칙
• leysys-design docs/specs/PRINT-DS.md, docs/specs/PRINT-DS-PHYSICAL-UNIT-CONTRACT.md — Print DS 범위와 물리 단위 계약
• leysys-design docs/specs/MARKDOWN-DS.md — Markdown DS 범위
• leysys-design docs/specs/CDS.md — CDS의 역할과 공통 참고 목록
• leysys-design docs/specs/EDS-MDS-MAPPING.md — 진영 선택 절차와 대표 대응표
• leysys-design docs/decisions/CDS-HTML-REFERENCE-ONLY-SEPARATION-2026-05-30.md — 공유 기반 폐지와 완전 분리
• leysys-design docs/decisions/REGISTRY-DS-FULL-INDEPENDENCE-2026-06-19.md — 복사본 컴포넌트의 진영 독립
• leysys-design docs/decisions/NPM-PACKAGE-DISTRIBUTION-PROPOSAL-2026-07-10.md — 시스템별 패키지 분리
• leysys-design AGENTS.md(파리티 미러 CLAUDE.md) 「레포 ↔ 호스트 네이밍」 — 접점 유형별 시스템 매핑