인프런 커뮤니티 질문&답변

안녕하세요 hans님!

먼저 정확한 지점을 짚어주셔서 정말 감사합니다. 이 주제는 겉보기에는 “인라인 스타일 vs classList” 정도로 단순해 보이지만, 실제로는 브라우저 내부 구조, 렌더링 타이밍, 그리고 대규모 UI에서의 코드 조직 방식까지 모두 연결된 이야기라 조금 더 설명이 길어질 수밖에 없습니다.

우선 hans님이 질문에서 이해하신 내용은 정확합니다. 단순히 인라인 스타일을 루프 안에서 두 번 정도 바꾸는 정도라면, 그 순간마다 리플로우나 리페인트가 여러 번 발생하지 않습니다. 브라우저는 자바스크립트가 실행되는 동안 스타일이 바뀌어도 곧바로 레이아웃을 다시 잡지 않고, 보통은 자바스크립트 실행이 끝나는 타이밍이나 다음 프레임을 그릴 때 스타일 계산 → 레이아웃 → 페인트를 한꺼번에 처리합니다. 그래서 이런 간단한 예시에서는 인라인 스타일을 쓰든 classList를 쓰든 렌더링 비용 자체는 거의 비슷하다는 점이 맞아요.

다만 제가 강의에서 이 부분을 조금 더 강조했던 이유는, 코드가 실제 서비스 수준으로 커졌을 때 인라인 스타일이 성능과 유지보수 양쪽에서 문제가 발생하기 쉬운 구조를 만들어버리기 때문입니다. 이 위험성은 예시 코드 같은 단순한 상황에서는 절대 드러나지 않고, 인터랙션이 많아지고 화면 요소가 많아질수록 서서히 누적되다가 어느 순간 체감될 정도로 큰 문제로 터지는 편입니다.

조금 더 현실적인 예를 하나 들어볼게요. 쇼핑몰 메인 페이지처럼 수백 개의 상품 카드가 흐르는 UI를 떠올려 보면, 화면 아래쪽에 있는 이미지는 아직 보이지 않지만 스크롤이 내려오면 보여야 하죠. 이런 상황에서 흔히 사용하는 것이 “lazy loading”입니다. lazy loading은 화면에 보이지 않는 이미지는 미리 로딩하지 않았다가, 사용자가 스크롤해서 해당 이미지가 화면 근처에 왔을 때 로딩을 시작하는 기법입니다. 이걸 효율적으로 구현하려고 최근에는 Intersection Observer라는 기능을 자주 씁니다. 이 기능은 “어떤 요소가 화면 안에 들어왔는지, 혹은 화면에 어느 정도 겹쳐졌는지”를 브라우저가 알려주는 API인데, 이 API를 이용해서 스크롤 이벤트를 직접 처리하지 않고도 필요한 타이밍에만 이미지 로딩을 시작할 수 있습니다.

문제는 이런 환경에서 인라인 스타일이 과도하게 들어가기 시작하면, 눈에 보이지 않던 성능 문제가 매우 자연스럽게 드러나기 시작한다는 점입니다. 예를 들어 카드 요소마다 style.backgroundColor, style.boxShadow, style.opacity 같은 스타일을 직접 넣기 시작하면, 화면에 등장하는 카드마다 조금씩 다른 스타일이 인라인으로 흩어지게 됩니다. 시간이 지나 디자이너의 요구가 더 늘어나면, 할인 상품에는 테두리 굵기 변화, 특정 카테고리에는 hover 애니메이션, 장바구니 담긴 상품에는 배지가 붙는 등 조건이 더 다양해지죠. 이런 상태 조합이 모두 인라인 스타일로 섞여 있으면, 코드를 따라가며 “이 카드가 어떤 상태일 때 어떤 스타일이 적용돼야 하는지”를 추적하는 일이 점점 더 어려워집니다.

이 상황에서 스크롤 위치 계산을 위해 getBoundingClientRect() 같은 레이아웃 값을 읽는 코드가 들어오면 문제가 한층 더 복잡해집니다. 이 API는 화면에 그려진 최신 위치 정보를 반환해야 하므로, 그 직전까지 쌓여 있던 인라인 스타일 변경을 모두 반영한 뒤에야 값을 반환할 수 있습니다. 즉 브라우저는 그 시점에서 강제로 레이아웃을 다시 계산해야 하고, 스크롤 중에는 이 작업이 거의 매 프레임 반복됩니다. 이렇게 “스타일 바꿈 → 최신 위치 읽음 → 또 스타일 바꿈 → 다시 위치 읽음”이 반복되면 화면이 뚝뚝 끊기기 시작하는데, 이런 상황을 복잡한 용어로는 layout thrashing이라고 부릅니다. 그냥 쉽게 말하면 “브라우저가 숨 돌릴 틈도 없이 계속 새로 레이아웃을 잡느라 바빠서 버벅이는 상황”이라고 할 수 있습니다.

여기에 인라인 스타일이 흩어져 있으면 문제가 더 커집니다. 어떤 조건에서 어떤 스타일이 적용되는지 한 곳에서 관리하기 어려워지고, 어떤 변화가 레이아웃을 다시 계산하게 만드는지 추적하기가 매우 힘들어집니다. 크롬 DevTools로 성능 프로파일링을 해도, 스타일이 여기저기 흩어져 있으면 원인이 분명하게 드러나지 않기도 합니다.

반대로 클래스 기반 구조를 사용하면 .card--discount, .card--loading, .card--hovered 같은 상태 클래스를 명확하게 만들고, 스타일은 CSS에서 한 번만 정의합니다. 자바스크립트에서는 단지 “지금 이 카드가 어떤 상태인지”만 클래스로 표시해주면 되기 때문에, UI 상태와 스타일이 깔끔하게 분리됩니다. 이런 구조는 기능이 많아질수록 유지보수가 쉬워지고, 나중에 레이아웃 관련 성능 문제가 생겨도 어디를 먼저 살펴봐야 하는지 훨씬 명확해집니다.

따라서 질문에서 주신 코드 수준에서는 hans님 말씀이 정확하고, 인라인 스타일 때문에 리플로우, 리페인트가 갑자기 여러 번 발생한다고 볼 수 없습니다. 다만 실서비스 규모에서는 인라인 스타일이 구조적인 혼란을 만들기 쉽고, 그 결과로 스크롤, 애니메이션, 반응형 컴포넌트 등이 섞인 상황에서 성능 병목으로 이어지기 쉬운 구조를 만들기 때문에, 학습 초기부터 클래스를 중심으로 스타일을 관리하는 습관을 들이셨으면 하는 의도로 설명을 드렸던 것입니다.

이런 질문 덕분에 강의에서도 앞으로 더 직관적으로 이해할 수 있는 사례와 실제 현업에서 마주치는 상황을 더 많이 포함해야겠다는 생각을 하게 되었습니다. 강의를 더 풍부하고 실용적으로 만드는 데 큰 도움이 되었습니다.

궁금한 점이 있으시면 언제든 편하게 말씀 부탁드립니다.

그리고 추가로, 현재 업로드된 다음 강의들에서도 이번 질문과 이어지는 흐름을 더 깊게 다루고 있으니 참고해주시면 좋을 것 같습니다. 이벤트부터 SPA까지, 상호작용 웹의 필수 엔진을 다룬 [DOM 완전 정복 Part 2], 그리고 DOM에서 실제 픽셀로 이어지는 렌더링 여정을 깊게 파헤친 [DOM 완전 정복 Part 3]까지 많은 관심 부탁드립니다!

감사합니다!

안녕하세요, 인프런 AI 인턴입니다. hans님.

강의에서 설명된 것처럼, 인라인 스타일의 변경은 특정 요소에 즉각적으로 적용되기 때문에 리플로우/리페인트가 자주 발생할 수 있습니다. 이는 브라우저가 스타일을 계산하고, 레이아웃을 재구성하는 과정에서 발생하며, 특히 많은 요소가 변경될 때 성능에 큰 영향을 줄 수 있습니다.

클래스와 인라인 스타일의 차이

• 클래스(classList 사용): CSS 클래스는 스타일이 이미 정의되어 있고, 요소에 클래스가 추가되면 별도의 계산 없이 한 번에 스타일을 적용할 수 있습니다. 여러 요소에 동일한 스타일을 적용할 때 유리합니다.

• 인라인 스타일: 자바스크립트를 통해 개별 스타일을 직접 설정하거나 변경할 때 사용됩니다. 각 변경사항에 대해 브라우저는 스타일을 계산하고 적용해야 하며, 이는 리플로우와 리페인트를 유발할 수 있습니다.

성능 측면

브라우저의 최적화 덕분에 두 방법 모두 최적화된 경우 큰 차이가 없을 수 있으나, 일반적으로 대량의 변경이나 빈번한 변경이 있는 경우에는 클래스 방식이 더 효율적입니다. 이는 브라우저가 한 번에 여러 스타일을 처리할 수 있게 하기 때문입니다.

문서의 구조가 복잡하거나 많은 스타일 변경이 필요할 때 클래스 기반 스타일링을 통해 리플로우/리페인트를 최소화하는 것이 성능적인 측면에서 유리할 수 있습니다.

다음 링크에서는 CSS 기본 성능 및 최적화에 대한 강의 내용을 참고하실 수 있습니다:
- 26. 클래스와 스타일을 다루는 가장 강력한 방법 – classList, style, 그리고 리플로우까지

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.