2장 백지 가정과 근본 해결
판단할 때는 「지금 백지에서 시작한다면 무엇이 옳은가」를 먼저 정하고, 그곳까지 가는 비용은 따로 적습니다. 증상을 덮지 않고 원인을 고칩니다.
왜 필요한가
이미 만든 구조와 들인 작업은 판단을 끌어당깁니다. 「이미 X로 되어 있으니 X를 유지한다」가 쌓이면 규칙 옆에 예외가 붙고, 예외 옆에 또 예외가 붙습니다. 예외는 공식으로 도출할 수 없어서 사람도 에이전트도 외워야 합니다. 증상만 고치는 처방도 같습니다. 원인을 그대로 두고 증상이 보이는 자리마다 덧대면, 다음 화면에서 같은 결함이 다시 나옵니다.
원칙
정답을 먼저, 비용은 따로
- 백지에서 시작한다고 가정하고, 근본적이고 구조적으로 가장 옳은 선택을 먼저 정합니다.
- 그다음 지금 상태에서 그곳까지 가는 이행 비용과 영향 범위(blast radius)를 따로 적습니다.
둘을 섞지 않고 나란히 보여 주면 결정하는 사람이 트레이드오프를 직접 판단할 수 있습니다. 이미 들인 작업(매몰비용)은 비용 항목일 뿐 정답의 근거가 아닙니다. 비용을 숨기는 것도, 비용으로 정답을 덮는 것도 하지 않습니다. 이 순서는 권장할 때, 계획할 때, 실제로 작업할 때 모두 적용합니다.
CSS·token 배포 방식을 정한 결정 기록이 그 예입니다. 먼저 백지 기준의 정답(버전 있는 패키지)을 적고, 이어서 「정직한 비용」(즉시 전파 대신 릴리스 주기, 새 릴리스 인프라, 모든 제품의 경로 전환)을 따로 적었습니다.
근본 원인까지 내려갑니다
5-Whys는 「왜」를 거듭 물어 증상에서 근본 원인(root cause)까지 내려가는 방법입니다. Leysys는 다섯 번에서 멈추지 않습니다. 대여섯 번째에서 멈추면 원인을 피했다는 신호로 보고 일곱·여덟 번째까지 묻습니다. 특히 fallback이나 별칭(alias)을 들이려는 순간에는 「이것이 왜 필요해졌는가」를 먼저 묻습니다.
2026-10-01 KST의 결함 기록이 예입니다. 한 소비 제품에서 MDS Hero의 사진이 모바일에서 보이지 않았습니다. 제품은 사진을 감싸는 요소를 더해 우회했습니다. 증상은 사라졌지만 원인은 그대로였습니다. 정본의 분석은 여덟 단계까지 내려갔습니다.
| 단계 | 물음에 대한 답 |
|---|---|
| 1–3 | 사진 칸 높이가 0px이었다. 높이가 정해지지 않은 세로 flex에서 기준 크기가 0이었고, 모서리를 자르려고 둔 overflow: hidden 때문에 자동 최소 크기도 0이었다 |
| 4 | 가로 배치에서만 쓰는 값을 모바일 기본 선택자에 선언했다 |
| 5 | 문서 예제가 그 경로를 보여 주지 않았다 |
| 6 | 반응형 검사는 넘침·내부 scroll·겹침은 쟀지만, 보여야 할 요소가 0px로 접히는 경우는 재지 않았다 |
| 7 | 같은 관용구가 EDS Chat 대화 영역에도 있었다 |
| 8 | 정적 검사로는 부모 높이를 알 수 없으므로 실제 화면의 geometry 테스트가 회귀를 막아야 한다 |
정본은 기본값을 고치고, 문서 예제를 바로잡고, 계약 테스트를 더하고, 302개 CSS 파일에서 같은 패턴을 찾아 점검했습니다.
위험 신호가 되는 말
| 종류 | 예 | 왜 위험한가 |
|---|---|---|
| 완화 어휘 | 「측정 노이즈일 뿐」, 「edge case라 무시해도 된다」, 「wrapper 차이의 자연스러운 결과」, 「의도된 설계(by design)」, 「다수 기준으로 0건이니 안전하다」 | 새 근거 없이 실측된 결함의 등급을 낮춥니다 |
| 미루는 어휘 | 「이번 범위를 넘는다」, 「영향 범위가 위험하다」, 「다음 작업에서 처리」, 「별칭으로 유예」 | 근본 해결을 뒤로 넘기고 임시 우회를 남깁니다 |
이런 말이 나오면 멈추고 다시 판단합니다. 「정말 그런가」라는 물음에는 앞의 답을 변호하지 않고 다시 진단합니다.
두 번째에서 멈춥니다
비슷한 항목을 두 번째로 더하는 순간 멈추고 구조를 다시 봅니다. helper 함수, 데이터 기반 구조, 다시 쓰기 중 무엇이 맞는지 판단합니다. 결함은 처음 나왔을 때부터 제대로 동작하던 이웃 사례와 무엇이 다른지 분석하고, 같은 종류의 결함이 두 번째로 나오면 패치를 더하지 않고 백지에서 다시 진단합니다. 반대로 한 번 나온 것을 미리 일반화하지는 않습니다. 과도한 추상화도 구조를 흐립니다.
실제 예
예외 목록을 공리 하나로 — 크기 체계
2026-04-30 KST의 크기 체계는 「5단 기본 + 예외 넷」이었습니다. Button은 7단, Table과 Avatar는 6단, overlay 폭은 8단이었고, 3단을 쓰는 11개 컴포넌트는 「의도된 격상」으로 따로 분류했습니다. 규칙보다 예외를 더 많이 외워야 했습니다.
2026-05-25 KST에 이 체계를 공리(axiom) 하나로 바꿨습니다. 「모든 크기 스케일은 홀수 단수이고 md를 중심으로 좌우 대칭이다.」 3·5·7·9·11단 모두 md가 기본값이고 xs와 xl, 2xs와 2xl이 짝을 이룹니다. 예전 예외 넷은 모두 짝수이거나 비대칭이어서 폐기했습니다. ERP 목록의 페이지 이동처럼 작은 크기를 기본으로 쓰고 싶으면, 어휘를 비틀지 않고 기본 size를 sm으로 고릅니다. 공리 밖의 예외는 밝혀 둡니다. drawer·sheet의 폭은 Tailwind max-w 스케일을 그대로 쓰므로 공리 대상이 아니라고 적었습니다. 자세한 값은 10장에서 다룹니다.
축 자체를 묻기 — semantic spacing 축 폐기
디자인 시스템에는 한때 요소 사이 거리를 뜻으로 나눈 간격 축 --spacing-proximity-*와 --spacing-section-*가 있었습니다. 2026-05-26 KST 하루 동안 이 축은 두 번 재정의되었습니다. 다음 날 네 컴포넌트의 안쪽 간격을 2px로 맞추자는 요청이 들어오자, 질문은 「이 축이 근본적으로 필요한가」로 바뀌었습니다.
답은 「필요 없다」였습니다. 간격은 Tailwind 유틸리티가 맡고 같은 역할의 CSS 변수를 따로 만들지 않는다는 토큰 원칙을 이 축은 처음부터 어기고 있었습니다. 축은 쓰임이 쌓이면서 정의되었을 뿐 고유한 뜻이 없었고, 고쳐 쓸 때마다 축을 유지할 이유가 덧붙었습니다. 간격 어휘가 두 벌이 되어 AI도 헷갈렸습니다. shadcn/ui·Nuxt UI·MD3에는 이런 축이 없었고 Primer에만 3단의 최소 형태가 있었습니다. 2026-05-27 KST에 축을 모두 폐기하고 149곳의 사용처를 컴포넌트 자체 토큰(--e-tabs-trigger-gap-{sm,md,lg}, --e-toolbar-gap 등)이나 Tailwind 값으로 바꿨습니다.
권고를 다시 열기 — 청구 추가 역할
2026-10-04 KST 접근 역할 체계 개정 때의 일입니다. 처음 권고는 요금제·모듈 변경을 「계약·결제의 최종 통제」로 읽어 조직 소유자의 몫으로 보았습니다. 그러자 청구 관리자 등급에는 고유한 일이 남지 않았고, 권고는 billing_editor 하나만 후보로 냈습니다.
오너가 「쓰지 않더라도 구조적으로 짝을 맞춰야 하지 않는가」라고 물었습니다. 첫 권고를 변호하는 대신 문서를 다시 읽었습니다. 문서가 맡길 수 없다고 적은 것은 해지·소유·조직 종료뿐이었습니다. 되돌릴 수 있는 설정 변경인 요금제·모듈 변경을 관리자 등급의 「설정」으로 두면 세 등급이 각자 다른 일을 갖고, 조회·데이터 작업·설정이라는 주 사다리의 등급 뜻과도 맞습니다. 그래서 billing_viewer·billing_editor·billing_admin 3단을 함께 등록했고, 결정 기록에 이 경위와 버린 선택지를 남겼습니다. 역할 체계 전체는 22장에서 다룹니다.
경계와 예외
- 백지 정답이 「지금 모두 갈아엎는다」는 뜻은 아닙니다. 정답과 비용을 나란히 보이는 데까지가 원칙이고, 언제 얼마나 옮길지는 사람이 결정합니다.
- 「의도된 설계」라는 말 자체가 금지어는 아닙니다. 결정 기록으로 확인될 때만 씁니다. 반대로 AI 감사가 기록된 의도를 결함으로 잘못 보는 일도 있어서, 결함이라고 판단하기 전에 결정 기록을 먼저 확인합니다(5장).
- 외부 다수 사례가 정답을 정하지 않습니다. 크기 체계의 결정 기록은 사용자가 명시한 공리가 외부 벤치마크보다 우선한다고 적었습니다. 모델에서 도출되지 않는 보정(floor, clamp, 벤치마크 맞춤)도 쓰지 않습니다.
정리
- 백지에서의 정답을 먼저 정하고, 이행 비용과 영향 범위는 따로 적습니다. 매몰비용은 정답의 근거가 아닙니다.
- 5-Whys는 일곱·여덟 단계까지 내려가고, fallback·alias를 들이는 순간을 의심합니다.
- 완화 어휘와 미루는 어휘가 나오면 멈추고 다시 판단합니다.
- 비슷한 항목이 두 번째로 나오면 구조를 다시 보고, 한 번 나온 것은 미리 일반화하지 않습니다.
- 예외 목록보다 공리가 낫고, 공리 밖의 예외는 이유와 함께 밝힙니다.
정본
leysys-designAGENTS.md(같은 내용의CLAUDE.md) — 「백지 가정」 원칙과 「사고·진단」 행동 규칙leysys-designdocs/decisions/SIZE-SCALE-SYMMETRIC-AXIOM-2026-05-25.md— 홀수·md중심 대칭 크기 공리leysys-designdocs/decisions/SPACING-SEMANTIC-AXIS-RETIRE-2026-05-27.md— semantic spacing 축 폐기leysys-designdocs/decisions/ACCESS-ROLE-SYSTEM-2026-10-03.md— 오너 결정 8과 그 경위leysys-designdocs/decisions/HERO-CHAT-STACKED-FLEX-HEIGHT-2026-10-01.md— 여덟 단계 5-Whys와 같은 패턴 점검leysys-designdocs/decisions/PATTERN-B-ATOMIC-PRIMITIVE-2026-04-28.md— 두 번째 결함에서 다시 진단하는 규칙