본문으로 건너뛰기

결정-0029: 디자인 시스템을 Spartan(brain + helm)으로 되돌린다

상태

승인됨. 저장소의 결정-0024(Krill 채택)와 결정-0019(컴포넌트 직접 제작)를 대체합니다.

맥락

당시 전제는 다음과 같습니다. web/ 이 Krill 기반이며 krill.css 414줄과 오버라이드 80줄, 대비 검증 58건, 컴포넌트 8종을 갖고 있습니다.

결정-0026이 블로그의 아키텍처 문서 62건을 이 저장소로 옮겼습니다. 그 문서 전체가 Spartan 을 전제로 쓰여 있습니다. 디자인 시스템과 토큰 302줄과 결정-0037, 결정-0045, 결정-0046, 결정-0047이 그 위에 서 있습니다.

동시에 블로그 자신이 그 표준의 참조 구현입니다. Spartan 컴포넌트 10종이 실제로 돌고 있고 Steiger 와 ESLint 가 위반을 빌드에서 차단합니다.

결정-0024가 Krill 을 채택한 핵심 근거는 여러 프로젝트가 같은 시스템을 공유한다는 것이었습니다. 그 전제가 성립하지 않게 되었습니다. 이 아키텍처의 참조 구현으로 실제로 도는 두 코드베이스 중 하나가 Krill 을 쓰지 않으며 문서도 Spartan 쪽에 있습니다.

검토한 대안

Krill 을 유지하고 옮겨온 문서를 고칩니다

구분 내용
장점 코드 변경이 0입니다
단점 문서 비용이 비쌉니다. 디자인 시스템 문서 302줄 전체와 결정 넷을 다시 써야 합니다
기각 사유 블로그가 계속 Krill 이 아닌 채로 남아 참조 구현이 표준을 따르지 않는 상태가 고정됩니다

둘을 병행하고 프로젝트마다 고릅니다

결정-0024가 이미 같은 이유로 색 토큰만 Krill 을 쓰는 안을 기각했습니다. 두 체계가 섞이면 어느 쪽 규칙을 따를지 매번 판단해야 하므로 기각합니다.

Spartan 으로 되돌립니다 (채택)

결정

web/ 의 디자인 시스템을 Spartan(brain + helm)으로 교체합니다.

  1. krill.css 를 제거하고 토큰을 Spartan 규약으로 다시 세웁니다. 규칙의 원본은 디자인 시스템과 토큰입니다.
  2. 컴포넌트는 helm 사본으로 갈아탑니다. helm 은 자유롭게 수정하며(결정-0037), 그 사본이 저장소 안에 있으므로 업스트림 갱신을 손으로 병합합니다.
  3. 결정-0019(1차 컴포넌트를 직접 만들고 헤드리스 선택은 2차로 미룬다)를 대체합니다. 헤드리스를 고르지 않는다는 유보가 Spartan brain 채택으로 해소됩니다.
  4. 대비 검증은 지우지 않고 Spartan 의 계약에 맞게 다시 씁니다. 결정-0024가 Krill 로 옮길 때 한 것과 같은 작업이며, 검증을 잃는 것이 본 결정의 목적이 아닙니다.

결정-0024가 Krill 자체에서 찾아낸 대비 문제 두 건은 본 결정으로 무효가 되지 않습니다. 그 보고는 Krill 업스트림에 남길 가치가 있는 기록이므로 저장소에서 지우기 전에 상류에 전달합니다.

결과

  • 문서와 두 참조 구현이 같은 디자인 시스템 위에 섭니다. 표준을 따르지 않는 참조 구현이 사라집니다.
  • 블로그에서 확인한 컴포넌트 계약을 그대로 씁니다. 겹치는 넷(button · card · input · spinner)은 이미 검증된 형태가 있습니다.
  • 감수하는 것
    • 본 결정은 코드 변경 비용이 큰 쪽입니다. krill.css 414줄과 오버라이드 80줄을 걷어내고 컴포넌트 8종의 내부를 다시 쓰며 대비 검증 58건을 Spartan 계약으로 옮깁니다. 문서만 바꾸고 코드를 두면 문서가 코드를 앞선 상태가 되므로 본 결정은 코드 작업이 끝나야 완료됩니다.
    • Krill 이 얻으려던 것을 잃습니다. 붙여넣으면 끝이라는 성질과 여러 프로젝트의 공통 기반이 그것입니다. helm 은 사본을 저장소에 두므로 업스트림 갱신이 자동으로 오지 않습니다.
    • 저장소 소유자가 직접 만든 시스템을 자기 참조 구현에서 쓰지 않게 됩니다. 이것은 기술적 판단이 아니라 범위의 판단입니다. Krill 은 그 자체로 유지되고 이 저장소는 발행되는 문서와 정합한 쪽을 택합니다.
    • 결정-0024가 옮겨 심은 네 가지 판단(다크 전환 방식 · 깊이 표현 · 반경 이름 · 폰트)을 Spartan 기준으로 다시 정해야 합니다. 폰트는 두 체계가 모두 Pretendard 자체 호스팅이므로 그대로입니다.

재검토 조건

  • 블로그가 디자인 시스템을 바꾸면 본 결정의 전제가 다시 흔들립니다. 두 참조 구현이 갈리는 순간 같은 판단을 다시 합니다.
© 2026 dev.goraebap