UI ‘예쁘게 만들면 되는 일’이라고 생각했다
UI 일을 처음 시작했을 때 나는
‘예쁘게 만들면 되는 일’이라고 생각했다.
트렌디한 디자인,
깔끔한 레이아웃,
완성도 있는 화면.
그게 좋은 UI의 전부라고 믿었다.
하지만 10년 동안 수많은 프로젝트를 거치며
그 믿음은 반복해서 무너졌다.
완성 직후의 UI는 늘 멀쩡했다.
문제는 시간이 지나면서 시작됐다.
페이지가 늘어나고,
기능이 추가되고,
사람이 바뀌는 순간부터
UI는 서서히 어긋나기 시작했다.
디자인이 틀려서도 아니고
개발 실력이 부족해서도 아니었다.
기준이 없었기 때문이다.
기준이 없으면
모든 결정은 감각에 의존하게 된다.
“이게 더 예쁜 것 같아요.”
“전엔 이렇게 하지 않았잖아요.”
“이건 취향 차이 아닌가요?”
이 순간부터 UI는
설계가 아니라 협의가 된다.
그리고 협의로 만들어진 UI는
유지보수 단계에서 가장 먼저 무너진다.
어느 순간부터 질문이 바뀌었다.
이 UI는 왜 이렇게 구성됐는가.
이 구조는 언제 깨지는가.
사람이 바뀌어도 유지될 수 있는가.
그때부터
클래스 네이밍, 구조, 규칙, 문서에 집착하기 시작했다.
왜 BEM을 그대로 쓰지 않았는지,
왜 SLUR만의 규칙을 만들었는지.
이유는 단순하다.
기준이 없으면 아무것도 남지 않기 때문이다.
SLUR UI System은
화려한 컴포넌트 모음이 아니다.
이것은 버튼이다.
이것은 레이아웃이다.
이것은 수정자다.
누가 보더라도
같은 방식으로 해석하고
같은 판단을 하게 만드는 기준이다.
그래서 SLUR에서의 UI는
“이게 예쁜가?”보다
“이게 기준에 맞는가?”를 먼저 묻는다.
이 블로그는
튜토리얼을 나열하지 않는다.
대신 이런 질문을 다룬다.
UI는 왜 항상 유지보수 단계에서 무너질까
디자인 시스템은 왜 중간에 실패할까
퍼블리싱은 언제 감각 노동이 될까
AI가 만든 UI는 왜 실무에서 자주 터질까
정답을 제시하기보다
판단할 수 있는 기준을 기록하고자 한다.
UI는 감각이 아니다.
경험 많은 사람의 손재주도 아니다.
기준이 있는 사람이 오래 만든다.
이 블로그는
UI를 잘 만드는 법보다
UI가 무너지지 않게 만드는 법을 기록한다.
SLUR의 지난 10년이 그 증거다.