기초가 흔들리면, 시스템 전체가 흔들린다
솔직히 말하면, 8pt 그리드 이야기를 꺼낼 때마다 조금 피곤해진다. 'Figma에서 spacing을 8의 배수로 맞춰야 한다'는 말은 이제 입문 교육에서도 당연하게 나오는 내용이니까. 그런데 최근 velog에 올라온 UI/UX 개념 입문 기사를 보면서 다시 생각하게 됐다. 이 기초가 실제 대규모 프로젝트에서 얼마나 자주 무너지는지를.
반응형과 적응형의 차이, 브레이크포인트 전략, 4pt vs 8pt 그리드 선택 기준—이것들은 개인 프로젝트 수준에선 '취향 문제'로 넘어갈 수 있다. 하지만 전사 시스템 규모가 되는 순간, 이 선택 하나가 수십 개 화면의 일관성을 통째로 결정한다. Figma에서 오토 레이아웃으로 맞춰놓은 4pt 간격이 실제 구현 단계에서 개발자마다 다르게 해석되는 걸 얼마나 많이 봤는지. '이거 px 단위로 봐야 해요'가 괜히 나오는 말이 아니다.
110억짜리 레거시 UI 전환이 던지는 질문
인스웨이브가 메리츠화재와 진행하는 '업무 시스템 인터페이스 전환 2차 프로젝트'(aitimes 보도)는 표면적으로는 금융 IT 소식처럼 보인다. 하지만 프론트엔드 관점에서 뜯어보면, 이 프로젝트는 훨씬 날카로운 질문을 품고 있다.
"전사 화면을 웹 표준 환경으로 전환한다"—이 한 문장이 실제로 의미하는 게 뭔지 기획자들은 잘 모른다. 수백 개의 레거시 화면에 제각각 박혀 있는 버튼 스타일, 폼 레이아웃, 모달 패턴들을 하나의 디자인 시스템으로 수렴시키는 작업이다. 단순히 '예쁘게 바꾸기'가 아니다. 일관성 없는 UI가 쌓여온 20년치 기술 부채를 청산하는 일이다.
인스웨이브는 여기에 AI 에이전트 플랫폼 '웹스퀘어 AI'와 자동 전환 솔루션 'W-크래프트'를 투입한다고 밝혔다. 개발 공수를 절감하고 품질 일관성을 확보한다는 전략인데—이 부분이 좀 걸린다. 자동 전환 솔루션이 UI 표준을 '만들어주는' 것인지, 이미 정의된 표준을 '적용해주는' 것인지가 핵심이다. 전자라면 컴포넌트 설계 철학이 도구에 종속되는 위험이 있고, 후자라면 그 표준을 먼저 정의하는 작업이 훨씬 더 어렵다. 15개월 안에 이걸 해내겠다는 건데, Lighthouse 점수나 접근성 기준도 이 표준 안에 들어가는지 궁금하다.
MutationObserver가 보여주는 SPA의 민낯
한편 dev.to에 올라온 크롬 익스텐션 개발기는 전혀 다른 각도에서 같은 문제를 건드린다. Claude 토큰 카운터를 45분 만에 만든 경험담인데, 여기서 핵심은 속도가 아니라 React SPA에서 DOM을 추적하는 방식이다.
개발자가 처음에 setInterval로 폴링하려다 MutationObserver로 전환한 이유가 정확히 디자인 시스템 문제와 맞닿아 있다. React가 렌더링하면서 컴포넌트를 마운트·언마운트할 때, 클래스명은 해시값으로 바뀌고 DOM 구조는 예고 없이 달라진다. data-testid 같은 의미 있는 셀렉터를 써야 그나마 버티는데—이게 역설적으로 디자인 시스템이 얼마나 외부에 안정적인 인터페이스를 제공해야 하는지를 보여준다.
사용자 입장에서는 그냥 Claude 쓰는 건데, 그 뒤에서 익스텐션이 DOM 변화를 감지해 토큰을 세고 있는 구조. 이게 동작하려면 Claude의 UI가 최소한의 일관성을 유지해야 한다. contenteditable div의 data-testid가 UI 업데이트마다 바뀐다면, 이 익스텐션은 매번 깨진다. 컴포넌트의 외부 계약—다시 말해 디자인 시스템이 보장해야 하는 셀렉터 안정성—이 얼마나 중요한지가 코드 레벨에서 드러나는 순간이다.
컴포넌트 트리가 없는 UI: 가능성인가, 재앙인가
여기서 가장 급진적인 이야기를 꺼내야겠다. dev.to의 또 다른 글 "When the Model Is the Machine"은 내가 올해 읽은 글 중 가장 불편하게 만든 글이다.
LLM이 런타임에 HTML, CSS, 인터랙션 로직을 전부 생성한다. 컴포넌트 라이브러리도 없고, 가상 DOM도 없고, 상태 관리 시스템도 없다. 모델이 상태를 들고 있다. 모델이 렌더링을 결정한다. 번역 앱을 URL에 프롬프트로 요청하면, 30초 전까지 존재하지 않았던 앱이 브라우저에 나타난다.
기술적으로는 단순하다. Python 550줄, 도구 두 개(render_page, update_elements), Claude Opus가 HTML과 CSS를 직접 생성해서 DOM에 주입한다. 타깃 DOM 패치를 {id, html} 쌍으로 전달하면 끝.
프론트엔드 개발자로서 이 데모를 보면 두 가지 감정이 동시에 온다. 첫째는 '사실 flexbox로 레이아웃 잡는 게 얼마나 단순한 작업인지 AI가 증명하고 있구나'. 둘째는 '그럼 내가 Figma 시안과 1px 씨름하며 만든 디자인 시스템은 뭔가'. 일관성, 재사용성, 토큰 시스템—이 모든 것의 전제가 '사람이 컴포넌트를 만들고 유지한다'는 가정 위에 서 있었다.
글쓴이 스스로 "party trick"이라고 인정하고 있고, 실제로 속도 문제와 상태 복잡도 한계는 분명하다. 하지만 Bain의 분석처럼 '전멸'이 아니라 '전환'이라면—이 전환이 프론트엔드 아키텍처에 미치는 파급력은 SaaS 구독 모델 붕괴보다 더 가까이에 있을 수 있다.
시사점: 표준이 무너지는 세 가지 경로
세 가지 소스를 엮어서 보면, 디자인 시스템이 무너지는 경로가 세 가지로 수렴된다.
첫째, 기초 무시. 8pt 그리드, 브레이크포인트 전략, 컴포넌트 일관성—이게 체계화되지 않은 상태로 화면이 쌓이면, 메리츠화재 같은 110억짜리 리팩토링 프로젝트가 필연적으로 발생한다. 기획 단계에서 UI 표준을 정의하지 않으면, 구현 단계에서 기술 부채로 돌아온다.
둘째, 구현 갭. Figma에서 완벽해 보이는 시안이 React SPA로 구현되면 DOM 구조가 달라지고, 익스텐션이 data-testid를 뒤지게 만든다. 디자인 토큰과 Figma Dev Mode를 쓰더라도, 컴포넌트의 외부 인터페이스—셀렉터, aria 레이블, 테스트 ID—를 명세하지 않으면 협업 시스템 전체가 취약해진다.
셋째, 패러다임 이동. AI가 런타임에 UI를 생성하는 세계에서는 '재사용 가능한 컴포넌트'보다 '모델이 참조할 수 있는 컨텍스트와 제약 조건'이 더 중요해질 수 있다. 디자인 시스템이 Figma 파일이나 Storybook이 아니라, LLM에게 전달하는 프롬프트 명세가 되는 날이 올지도 모른다.
전망: '일관성'의 정의가 바뀌고 있다
당장 내일부터 AI가 모든 UI를 생성하지는 않는다. 메리츠화재 프로젝트는 여전히 사람이 설계한 컴포넌트로 15개월을 채울 것이고, React 생태계는 당분간 건재하다.
하지만 '일관성'의 책임이 어디에 있느냐는 질문은 달라지고 있다. 예전엔 디자이너가 Figma에서, 개발자가 CSS-in-JS나 Tailwind로 그 일관성을 유지했다. 지금은 AI 에이전트가 전환 공수를 줄이고, LLM이 렌더링을 결정하고, MutationObserver가 SPA의 DOM 변화를 추적한다.
사용자 입장에서는 어디서 만들어졌든 화면이 일관되고 직관적이면 그만이다. 문제는 그 일관성을 보장하는 시스템이 무너질 때, 사용자는 이유를 모른 채 불편함만 느낀다는 것이다. 1px 어긋난 버튼 하나, 브레이크포인트에서 깨지는 레이아웃 하나, 컨텍스트 한도를 모르고 쓰다 잘리는 프롬프트 하나—이 모든 게 결국 같은 문제다.
도구가 바뀌어도 '사용자가 모르게 잘 작동하는 것'이 목표라는 사실은 변하지 않는다. 그게 8pt 그리드든, AI 에이전트든.