#디자인시스템

List 디자인 시스템 · 11편

List의 공개 범위는 왜 타입만으로 지킬 수 없었을까

exports로 패키지의 공개 경로를 설계하고, JavaScript와 CSS가 줄어드는 단위를 가르기

List 디자인 시스템 · 10편

같은 List를 만들었는데 왜 플랫폼 구현은 달라야 했을까

세 플랫폼이 공유할 의미와 각 플랫폼이 소유할 실현을 나누기

List 디자인 시스템 · 9편

List를 나눈 것은 모양이 아니라 '상태의 소유권'이었다

동일한 화면 구조의 목록을 왜 두 개의 Recipe로 나누어야 했을까

List 디자인 시스템 · 8편

ListRow에서 List로 올라와도 새 Recipe는 생기지 않았다

목록의 공간을 제목과 본문으로 나누고 그 위에 구분선과 배경 두 축을 세우기까지

List 디자인 시스템 · 7편

ListRow마다 유효하던 코드가 List 전체에서는 어긋났다

ListRow와 List의 책임 경계를 다시 긋고 무엇을 List가 소유할지 가르기

List 디자인 시스템 · 6편

ListRow에 열 수 있었던 prop을 왜 열지 않았을까

이 결정을 누가, 어디서, 몇 번 하는지로 갈랐다

AI가 사용할 디자인 시스템은 무엇이 달라야 할까

규칙을 문서에 적는 것과 시스템에 심는 것의 차이

List 디자인 시스템 · 5편

ListRow의 모양과 동작을 왜 하나의 계약으로 묶었을까

화살표와 버튼이 동작 영역, DOM, 접근성까지 결정한 과정

List 디자인 시스템 · 4편

ReactNode 슬롯은 ListRow에 들어올 컴포넌트를 제한하지 못했다

컴포넌트의 정체성을 검사하는 대신 정해진 데이터만 받기까지

List 디자인 시스템 · 3편

List API의 유연성은 어디에 두어야 했을까

같은 ListRow를 Flat, Compound, Recipe로 만들자 잘하는 일이 갈렸다

List 디자인 시스템 · 2편

List를 화면이 아니라 구조로 나누자 Recipe의 기준이 생겼다

화면 사례를 anatomy로 나누고 Recipe와 Variant의 경계를 정한 세 가지 질문

List 디자인 시스템 · 1편

List 디자인 시스템은 왜 자유도를 제한해야 했을까

오픈소스 컴포넌트와 사내 컴포넌트가 다른 답을 고르는 이유

디자인 시스템을 처음 맡은 리드의 회고

좌충우돌, 잘 모르는 자리에서 듣고, 묻고, 함께 기준을 만들어간 이야기

디자인 QA 지옥에서 탈출하기: 픽셀 비교 기반 자동화 테스트 도입기

기능 테스트는 전부 그린인데 버튼은 깨져 있었다. 시각적 회귀 테스트를 어떤 기준으로 고르고 Playwright로 어떻게 붙였는지, 그리고 무엇이 남았는지