‘Resilient’는 무엇을 의미하나요? — Drift와 Invariants 정의
Source: Dev.to
위에 제공된 내용만으로는 번역할 텍스트가 없습니다. 번역을 원하는 본문을 알려주시면 한국어로 번역해 드리겠습니다.
CSS 디자인에서의 Drift
Part 1에서 나는 CSS 아키텍처가 “외우고 따라야 할 규칙”에서 “피드백 시스템”으로 전환되어야 한다고 주장했습니다. 그런데 탄력적인(drift‑저항) 디자인이 정확히 무엇을 의미할까요? 이 파트에서는 디자인 퇴보 현상을 drift라고 정의하고, 이를 방지하기 위한 불변량(invariants) 개념을 소개합니다.
CSS 디자인은 한 번에 무너지는 것이 아닙니다. 작은 결정의 불일치가 누적되면서, 깨달을 때쯤에는 일관성이 사라집니다. 나는 이를 drift라고 부릅니다.
Breaking Down
이 시리즈에서 “breaking down”은 구체적으로 다음 세 가지를 의미합니다:
- 컴포넌트 경계 모호성 – 한 컴포넌트가 어디서 끝나고 다른 컴포넌트가 어디서 시작하는지가 사람마다 다르게 인식됩니다.
- 레이아웃 책임 혼동 – margin이 부모에 속하는지 자식에 속하는지가 파일마다 다르게 적용됩니다.
- 명명 및 구조 일관성 부족 – 명명 규칙과 파일 조직 방식이 프로젝트 전반에 걸쳐 일관되지 않습니다.
예시: BEM 프로젝트에서 흔히 발생하는 drift
| 상황 | Drift |
|---|---|
한 팀원이 margin을 자식 컴포넌트 자체에 작성하고, 다른 팀원은 부모에서 지정함 | “이 요소가 독립적인 컴포넌트인가, 부모의 일부인가?” – 답변이 사람마다 다름 |
| 수정자(Modifier) granularity가 파일마다 다름 | – |
이것들은 “규칙 위반”이 아닙니다. 가이드라인에 남겨진 해석 여지가 결정 drift를 일으키며, 팀 규모가 커질수록 그 여지는 넓어집니다.
AI Drift
AI 코딩 에이전트를 도입해도 구조 자체가 바뀌지는 않습니다. 컨텍스트 창에 가이드라인을 가득 넣어도, 판단이 필요한 부분에서는 출력이 달라집니다. 인간의 drift가 AI drift로 전환되는 것입니다.
관습 기반 설계의 약점
관습 기반 설계는 구조적인 약점을 공유합니다:
- 암기 부담 – 가이드라인이 길수록 모든 사람이 정확히 기억하고 적용하기가 어려워집니다.
- 주관적 결정 – “한 컴포넌트가 어디서 끝나는가?”와 같은 질문에는 객관적인 답이 없습니다.
- 검증 어려움 – 무언가가 관습을 위반했는지 기계적으로 판단할 수 없으며, 리뷰에만 의존할 수 있습니다.
세 가지가 모두 존재하면, 드리프트는 불가피합니다. 리뷰는 검토자의 판단이 일관된 동안에만 품질을 유지하고, 검토자도 인간이므로 판단이 흐려집니다.
불변식
프로그래밍에는 불변식이라는 개념이 있습니다 – 프로그램의 모든 지점에서 유지되어야 하는 조건(예: 배열 인덱스가 범위 내에 머무르는지, 계좌 잔액이 절대 음수가 되지 않는지). 이러한 조건은 타입과 어설션을 통해 기계적으로 강제됩니다.
같은 아이디어를 CSS 아키텍처에 적용할 수 있습니다: 해석에 따라 답이 달라지는 규칙은 없애고, 기계적으로 true 또는 false 로 평가될 수 있는 조건만 채택합니다.
구체적인 예시
| 관례 기반 (해석 필요) | 불변식 (기계적으로 검증 가능) |
|---|---|
| “구성 요소를 적절한 granularity(세분화)로 분해한다.” | “Block의 직접 자식은 Block 또는 Element만 될 수 있다.” (Part 4에서 정의된 용어) |
| “부모가 레이아웃을 관리한다.” | margin-top은 부모의 > .child 선택자에서만 지정될 수 있다. |
| “명명 규칙을 일관되게 유지한다.” | Block은 2단어 케밥 케이스를 사용하고, Element는 한 단어를 사용한다. |
| “상태와 변형을 구분한다.” | Variant는 data-variant를 사용하고, State는 data-state를 사용한다. |
왼쪽 열은 올바름을 판단하기 위해 인간의 해석이 필요합니다. 오른쪽 열은 문자열 패턴 및 선택자 구조 매칭을 통해 판단할 수 있어 자동화된 lint 검증이 가능합니다. 오른쪽 예시는 제가 개발하고 실제 운영 중인 SpiraCSS에서 사용되는 실제 불변식이며, Part 4에서 자세히 다룹니다.
Source: …
실행 가능한 불변식의 속성
모든 규칙이 불변식이 될 수 있는 것은 아닙니다. 불변식으로 기능하려면 규칙이 다음과 같은 속성을 가져야 합니다:
- Binary evaluation – 위반 여부 또는 준수 여부가 명확하게 결정됩니다(회색 지대가 없습니다).
- Syntax‑verifiable – 런타임 없이 오직 소스 코드 구문 분석만으로 판단할 수 있습니다.
- Locally verifiable – 프로젝트 전체를 스캔할 필요 없이 대상 파일만 보면 판단할 수 있습니다.
디자인이 이러한 기준을 모두 만족하는 규칙들로만 구성된다면, 린트 도구가 “게이트키퍼” 역할을 할 수 있습니다. 사람은 판단을 내릴 필요가 없으며—도구의 판결을 그대로 따르면 됩니다. AI 에이전트도 마찬가지입니다.
반대 의견 다루기
“이것이 ‘정확성’을 정의하기보다 단지 선호도를 고정시키는 것이 아닌가요?”
그것은 타당한 반론입니다. “부모로부터 마진을 쓰기”가 유일한 올바른 접근법은 아니지만, 디자인 선호도를 고정시켜 모든 작성자가 동일한 결과물에 수렴하도록 하는 데는 가치가 있습니다 — 특히 작성자 풀에 인간과 AI가 모두 포함될 때는 더욱 그렇습니다. 불변의 기준을 갖는 것 자체가 팀 생산성을 높여줍니다.
The Feedback Loop
불변 조건만 정의한다고 해서 설계가 보존되는 것은 아닙니다. 위반을 감지하고 무엇이 잘못됐는지와 어떻게 고쳐야 하는지를 전달하지 않으면 수정이 이루어지지 않습니다. 다음 순서가 피드백 루프를 형성합니다.
- 불변 조건 정의.
- 위반 감지.
- 수정 지침 제시.
다음 부분에서는 이 루프를 설계하는 방법을 더 깊이 살펴봅니다. 린트가 단순히 “무엇이 잘못됐는지”가 아니라 “어떻게 고쳐야 하는지”까지 알려줄 때, 오류 메시지는 신중하게 작성되어야 합니다.
Next Steps
→ Part 3 — 피드백 루프 — 무엇을 고쳐야 하고 어떻게 고쳐야 하는지 알려주는 Lint 설계 (이번 주 후반)
리소스
- SpiraCSS – 디자인 사양, 도구 및 소스 코드는 오픈 소스입니다.
- 웹사이트:
- GitHub: