레이아웃 전쟁의 끝에서 CSS가 남긴 질문

요즘 개발자 커뮤니티에서 종종 듣는 말이 하나 있다. "이제 AI가 다 해주는데 CSS까지 손으로 쓸 필요가 있나?" 마치 스타일링은 예전의 취미 활동처럼 취급되며, 진짜 개발은 데이터 흐름이나 서버 아키텍처를 다루는 것으로 여겨진다. 하지만 실무 현장에서 한 번이라도 AI가 생성한 레이아웃 코드를 운영 환경에 올려본 사람이라면, 이 말이 얼마나 공허한지 잘 알 것이다. UI가 깨지는 순간, 스태킹 컨텍스트가 뒤엉키고 명시도 전쟁이 발발할 때, 그 자리를 메워야 하는 건 여전히 인간 개발자다. CSS는 단순한 스타일링 언어가 아니라, 사용자가 마주하는 모든 화면의 근간을 설계하는 실용적 엔지니어링이다.

이런 인식이 생긴 데는 이유가 있다. 최근 AI 코딩 도구들은 HTML과 CSS를 상당히 능숙하게 생성해낸다. 프롬프트에 "반응형 랜딩 페이지를 만들어줘"라고 하면, 그럴듯한 그리드 레이아웃과 미디어 쿼리, 현대적인 색상 팔레트가 담긴 코드가 쏟아진다. 첫인상은 완벽하다. 하지만 이 코드를 진짜 프로젝트에 붙이기 시작하면 문제가 드러난다. AI는 보이는 결과물의 형태를 흉내 낼 수 있을 뿐, 브라우저의 레이아웃 엔진이 실제로 어떤 판단을 내리는지는 깊이 이해하지 못한다. position: sticky가 어느 순간 갑자기 동작을 멈추고, z-index가 예상대로 쌓이지 않으며, flex 아이템이 의도와 다르게 늘어나거나 줄어드는 순간들이 바로 그 증거다.

브라우저는 단순한 렌더링 도구가 아니다. CSS를 해석하는 과정은 표면적으로 보이는 것보다 훨씬 복잡한 계층 구조를 가진다. 스타일 선언이 쌓이면 브라우저는 명시도(specificity)를 계산하고, 상속 규칙을 적용하며, 박스 모델을 조립하고, 플로팅 요소를 정렬하고, 마지막으로 스태킹 컨텍스트를 결정한다. 이 과정에서 한 줄의 overflow: hidden이 새로운 블록 포맷팅 컨텍스트를 만들어 내부 요소의 레이아웃을 완전히 뒤바꿀 수도 있다. AI는 이런 미시적 물리 법칙을 학습하지만, 그 학습이 항상 문맥을 정확히 파악하는 것은 아니다. 특히 레거시 코드와 신규 코드가 뒤섞인 기존 프로젝트에서는, AI가 생성한 "깔끔한" CSS가 기존의 명시도 체계와 충돌하며 예상치 못한 부작용을 낳는다.

실제로 AI가 생성한 코드를 검토보면, 종종 !important를 남발하거나 과도하게 중첩된 선택자를 사용하는 경향이 있다. 이는 AI가 시각적 결과를 맞추기 위해 가장 직접적인 방법을 택한 것으로 보인다. 하지만 이 방식은 유지보수성을 해치며, 나중에 다른 개발자가 덮어쓰려 할 때 예기치 않은 저항을 만든다. CSS의 명시도는 단순한 숫자 게임이 아니다. 그것은 전체 스타일 시스템의 계약이며, 한 번 무너지면 디버깅은 지옥이 된다. DevTools를 열어 Computed 탭을 들여다보아도, 왜 이 요소가 저 색상을 갖는지 추적하는 과정은 여전히 수동적이고 직관에 의존해야 하는 경우가 많다. AI는 이 추적 과정을 대신해주지 않는다. 오히려 문제를 더 얽히게 만들 뿐이다.

스태킹 컨텍스트(stacking context)를 생각해보자. 이 개념은 CSS 초심자에게도 어렵고, 숙련자에게도 종종 골칫거리다. z-index 값을 아무리 높게 줘도 요소가 뒤로 가려지는 상황을 겪어본 적이 있는가. 그 원인은 대부분 부모 요소가 새로운 스태킹 컨텍스트를 형성했기 때문이다. opacity가 1보다 작거나, transform이 적용되거나, position이 fixed나 sticky가 되면, 그 요소는 자신만의 격리된 층(layer)을 만든다. AI는 시각적 효과를 위해 이런 속성들을 자연스럽게 추가하지만, 그것이 전체 레이아웃의 깊이 구조에 어떤 영향을 미치는지는 거의 고려하지 않는다. 결과적으로 모달 다이얼로그가 의도보다 뒤에 표시되거나, 드롭다운 메뉴가 다른 섹션에 묻히는 버그가 발생한다. 이 문제를 해결하려면 개발자가 직접 브라우저의 레이어 트리를 들여다보고, 어떤 요소가 어떤 컨텍스트에 갇혀 있는지 판단해야 한다. 이 과정은 자동화되지 않는다. 이것이 바로 CSS가 여전히 '손맛'이 필요한 영역인 이유다.

AI가 잘 못하는 또 다른 영역은 반응형 레이아웃의 미묘한 차이다. 미디어 쿼리를 쓰는 것과 진정한 반응형을 설계하는 것은 다르다. AI는 보통 뷰포트 너비를 기준으로 단순히 레이아웃을 전환하는 코드를 생성한다. 하지만 실제 사용자는 다양한 디바이스를 사용하고, 화면은 단순히 크기가 다른 것이 아니라 입력 방식, 픽셀 밀도, safe area, 접근성 설정까지 모두 다른 환경이다. min-width와 max-width 사이에서 발생하는 틈새(edge case)를 처리하거나, 컨테이너 쿼리(container query)를 적재적소에 활용하는 것은 여전히 개발자의 판단이 필요하다. AI는 통계적으로 가장 가능성 높은 레이아웃을 제시할 뿐, 특정 기기에서 발생하는 1px 차이의 레이아웃 붕괴를 예측하지 못한다.

이런 문제들이 단순한 버그 수준이 아니라는 점을 강조해야 한다. CSS는 사용자 경험(UX)의 직접적인 물리적 표현이다. 클릭 영역이 잘못 잡히면 사용자는 의도한 동작을 하지 못한다. 색상 대비가 부족하면 시각 장애 사용자는 콘텐츠를 인식할 수 없다. 애니메이션이 프레임 드롭을 일으키면 인터랙션이 끊기는 느낌을 준다. 이런 것들은 모두 CSS의 영역에서 결정된다. AI가 생성한 코드가 이런 세부사항까지 완벽하게 고려하기는 어렵다. 특히 웹접근성 관련 속성들은 맥락을 이해해야만 제대로 적용할 수 있는데, AI는 이미지가 장식용인지 정보 전달용인지, 버튼이 실제로 클릭 가능한 영역인지를 코드만 보고 판단하기 어렵다.

레이아웃의 붕괴는 종종 눈에 보이지 않는 곳에서 시작한다. Cumulative Layout Shift(CLS)는 대표적인 예다. 페이지가 로드된 후에 이미지나 폰트가 늦게 들어오면서 요소가 밀리는 현상이다. 이를 방지하려면 aspect-ratio를 미리 지정하거나, 폰트의 size-adjust를 조정하거나, 콘텐츠 영역을 예약해두는 등의 전략이 필요하다. AI는 이런 성능 지표와의 연결을 생각하지 않는다. 그것은 코드가 "작동"하는지를 보고 판단하지, 그 코드가 실제로 사용자의 눈에 어떤 잔상을 남기는지는 고려하지 않는다. 하지만 프론트엔드 엔지니어는 이것이 핵심 업무다. Lighthouse 점수가 몇 점인지, Core Web Vitals를 통과하는지는 여전히 개발자가 책임져야 할 영역이다.

그렇다면 CSS는 어떻게 공부해야 하는가? 이 질문은 오래된 질문처럼 들리지만, AI 시대에 더욱 중요해졌다. CSS를 외우는 것이 아니라, 브라우저가 어떻게 생각하는지 이해해야 한다. 왜 float가 clearfix를 필요로 했는지, 왜 flex가 1차원이고 grid가 2차원인지, 왜 margin collapse가 발생하는지를 이해하는 것이다. 이런 원리를 알면 AI가 생성한 코드가 어디서부터 꼬였는지 빠르게 파악할 수 있다. AI는 도구일 뿐이며, 도구를 사용하는 사람이 원리를 모르면 그 도구는 언제든 역풍을 일으킨다. AI가 쓴 CSS를 리뷰하는 능력은, AI가 쓰는 것을 넘어서는 인간 개발자의 핵심 경쟁력이 될 것이다.

실제로 최근의 프로젝트들을 보면, 디자인 시스템이나 UI 프레임워크를 도입한 후에도 커스텀 CSS가 필요한 순간은 반드시 찾아온다. Tailwind CSS나 Bootstrap 같은 도구가 많은 보일러플레이트를 줄여주지만, 디자인 토큰의 변형, 예외적인 브레이크포인트, 특정 브라우저의 버그 대응은 결국 수동으로 작성해야 한다. 이때 CSS에 대한 이해가 없다면, 프레임워크의 클래스를 조합하는 것만으로는 한계에 부딪힌다. AI가 이런 프레임워크 기반 코드를 생성할 때는 더욱 위험하다. 프레임워크의 추상화 위에 AI의 추상화가 겹쳐지면, 문제가 발생했을 때 디버깅의 깊이는 두 배로 깊어진다. 어떤 클래스가 어떤 속성을 덮어썼는지, 그리고 그 덮어쓰기가 왜 기대와 다르게 동작하는지를 추적해야 한다.

이런 맥락에서 볼 때, CSS를 "취미"로 치부하는 것은 기술의 본질을 오해한 것이다. 취미는 하고 싶을 때 하는 것이지만, CSS는 웹 개발에서 절대 건너뛸 수 없는 필수 경로다. 백엔드 개발자라도 언젠가는 API 응답을 화면에 표시해야 하고, 그 순간 CSS는 피할 수 없는 현실이 된다. 데이터 시각화를 하든, 관리자 페이지를 만들든, 이메일 템플릿을 작성하든, 모든 것은 결국 픽셀의 배치로 귀결된다. 그리고 이 배치가 논리적이고 예측 가능하려면, CSS의 근본 원리를 알아야 한다. AI가 이것을 대체하려면, 브라우저의 레이아웃 엔진을 완벽히 시뮬레이션하고, 프로젝트의 전체 스타일 계약을 이해하며, 사용자의 인지적 흐름까지 예측해야 한다. 현재로서는 그것이 불가능에 가깝다.

미래의 프론트엔드 개발자는 어떤 모습일까? 아마도 AI가 생성한 코드를 더 빠르게 감사(audit)하고, 그것이 실제 브라우저 동작과 어떻게 맞물리는지를 판단하는 사람이 될 것이다. 코드를 직접 치는 시간은 줄어들지 몰라도, 코드가 "왜" 그렇게 동작하는지를 해석하는 시간은 오히려 늘어날 것이다. CSS는 이 과정에서 중심이 되는 언어다. 왜냐하면 CSS는 선언적이면서도 동시에 순수하게 부작용을 일으키는(side-effectful) 언어이기 때문이다. 한 줄의 속성 변경이 전체 문서의 흐름을 바꿀 수 있다. 이런 특성은 데이터 처리 로직과는 다른 차원의 사고를 요구한다. AI가 이 사고방식을 완전히 흡수하기까지는 상당한 시간이 걸릴 것이다.

CSS는 단순히 화면을 예쁘게 만드는 기술이 아니다. 그것은 정보의 계층을 시각화하고, 사용자의 주의를 유도하며, 인터랙션의 가능성을 암시하는 설계 도구다. AI가 생성한 코드가 깨지는 순간, 우리는 다시금 깨닫는다. 화면 위의 모든 것은 위치와 크기, 색상과 투명도, 그리고 그것들이 쌓이는 순서의 정밀한 조율 위에 서 있으며, 그 조율의 주체는 여전히 인간 개발자라는 것을. CSS를 단순한 취미로 치부하는 시대가 왔다면, 그것은 오히려 CSS의 진짜 중요성을 다시 확인하는 계기가 될 수 있다. 레이아웃 전쟁은 끝난 적이 없고, 그 전쟁의 끝에서 CSS는 우리에게 한 가지 질문을 던진다. 화면을 제어하는 것이 여전히 당신의 몫인가.

댓글

댓글을 읽어오는 중입니다.