AI 도구에 CSS 파일을 넘기는 순간, 우리는 은연중에 기대한다. '이제 깔끔해지겠지.' 하지만 실제로 돌아오는 건 종종 다르다. 그리드가 틀어지고, 호버 효과가 어색해지고, 첫 페인트가 오히려 느려진다. dev.to에 공유된 실무 경험담은 이 순간을 꽤 정확하게 포착한다—AI가 CSS를 '최적화'한 직후, 오버레이를 잡고 있던 position: absolute가 position: relative로 교체되어 UI 전체가 무너지는 장면을.
왜 이런 일이 생기는가. AI 기반 CSS 도구가 스타일시트를 분석하는 방식 자체에 답이 있다. 이 도구들은 대개 CSS를 AST(Abstract Syntax Tree)로 파싱한 뒤 사전에 학습된 휴리스틱을 적용한다. 사용하지 않는 셀렉터를 제거하고, 중복 규칙을 합치고, 복잡한 셀렉터를 단순화한다. .nav > ul > li.active를 .nav-active로 바꾸는 것처럼. 의도는 좋다. 그러나 이 판단은 '정적 분석' 기반이다. 런타임에 JavaScript가 동적으로 붙이는 클래스, 특정 DOM 계층 구조에 의존하는 스타일, 인터랙션 상태마다 달라지는 pseudo-class—이런 맥락은 AI가 코드를 읽는 시점에 보이지 않는다. 결국 AI는 '현재 파일에 없는 것'을 지우고, '더 단순해 보이는 것'으로 바꾼다. 근거 없는 행동이 아니라, 불완전한 정보 위의 합리적 추론이다. 문제는 그 추론이 우리의 의도와 어긋날 때다.
CSS만의 이야기가 아니다. 비슷한 구조의 실패는 코드 전반에 걸쳐 반복된다. Claude로 C# 콘솔 애플리케이션을 처음 만들어 본 한 개발자의 경험도 같은 패턴을 드러낸다. 처음 설계 대화는 훌륭했다. 어떤 LLM을 쓸지, 환경 변수는 어떻게 관리할지, 프로젝트 구조는 어떻게 잡을지—Claude와의 페어 프로그래밍은 기대 이상이었다. 그러나 서브에이전트 옵션을 켠 순간, Claude는 멈추지 않았다. 하드코딩된 Gemini 모델 URL, 테스트용으로 반복 삽입되는 동일한 단락, 개발자가 원하지 않는 방식으로 구현된 기능들—"내가 작성하지 않은 버그"들이 쌓였다. 이것 역시 AI가 나쁜 코드를 쓴 게 아니다. 개발자의 의도와 워크플로우 선호가 충분히 전달되지 않은 상태에서 에이전트가 최선을 다해 달린 결과다.
두 사례가 수렴하는 지점이 있다. AI는 맥락 없이 가속한다. CSS 리팩토링 도구는 런타임 의도를 모른 채 코드를 정리하고, 코딩 에이전트는 개발자의 판단 개입 선호를 모른 채 구현을 완주한다. 그리고 두 경우 모두, 문제를 사전에 막을 수 있었던 건 더 정교한 AI 모델이 아니라 더 명확한 관찰 구조와 중단 조건이었다.
그래서 '어떻게 보는가'가 핵심이다. CSS 리팩토링 실패를 잡는 실전 디버깅 루틴은 단순하지만 체계적이어야 한다. 변경 전후 CSS 스냅샷을 diff로 비교하고, 라이브 DOM을 직접 열어 런타임 클래스명을 확인하고, 브라우저 DevTools에서 repaint와 layout thrashing을 프로파일링한다. hover, focus, active 같은 인터랙션 상태를 빠뜨리지 않고 테스트하며, 문제가 생기면 덩어리째 롤백하는 게 아니라 변경 단위로 선택적으로 되돌린다. 자동화 도구가 일으킨 문제는, 자동화 검증으로 보완해야 한다. 시각적 회귀 테스트와 컴포넌트 단위 테스트가 없다면 AI 도구가 바꾼 스타일을 신뢰할 기준 자체가 없다.
에이전트 레벨로 올라오면 관찰 구조는 더 중요해진다. Claude Code를 사용하다 보면 두 가지가 보이지 않는다. 컨텍스트 창이 얼마나 찼는지, 사용량 한도에 얼마나 근접했는지. 그 숫자들은 한계에 부딪히는 순간에야 드러난다—컨텍스트가 자동 압축되거나, 요청이 막히거나. cc-context-telemetry는 이 문제를 statusLine 레이어에서 해결한다. Claude Code가 렌더링마다 statusLine 프로그램에 JSON 페이로드를 전달한다는 점을 이용해, 컨텍스트 사용률과 5시간·7일 단위 요금제 한도, 모델 정보를 상태바에 실시간으로 표시한다. 더 중요한 건 hook API와의 연결이다. hook 실행 시점에 컨텍스트가 85%를 넘었다면 체크포인트를 만들거나 작업을 일시 중단할 수 있다. 보이지 않아서 대응하지 못했던 것들이, 보이기 시작하면 통제 가능해진다.
세 가지 사례가 가리키는 방향은 하나다. AI 도구를 실무 워크플로우에 통합할 때 진짜 위험은 AI가 '나쁜 결과물'을 내는 것이 아니다. AI가 내는 결과물이 왜 그렇게 나왔는지, 무엇이 달라졌는지, 지금 어느 한계에 근접해 있는지를 우리가 볼 수 없는 것이다. CSS 리팩토링 도구에는 격리된 컴포넌트 단위 실험과 변경 전후 비교 체계가 필요하고, 코딩 에이전트에는 판단 개입 지점과 instruction 파일이 필요하며, 에이전트 실행 환경에는 컨텍스트와 사용량을 드러내는 관찰 레이어가 필요하다.
빠른 프로토타이핑을 AI에 맡기는 흐름은 이미 되돌릴 수 없다. 다음 단계는 그 흐름 위에 검증과 관찰의 구조를 의도적으로 설계하는 것이다. AI가 CSS를 고칠 때 놀라는 건 한 번으로 충분하다. 두 번째부터는, 어디서 무엇이 바뀌었는지 미리 볼 수 있어야 한다.