"팀장님, 화면이 왜 이렇게 버벅거릴까요?"
얼마 전, 입사한 지 얼마 안 된 주니어 개발자가 울상으로 물어왔습니다.
코드에는 에러가 없는데, 스크롤만 내리면 화면이 뚝뚝 끊긴다는 거였죠.
사실 저도 10년 전에는 똑같은 고민을 했습니다.
기능만 잘 돌아가면 되는 줄 알았거든요.
'원리'를 모르면 최적화는 불가능합니다.
우리가 매일 쓰는 크롬, 사파리 같은 브라우저.
도대체 내부에서 무슨 일이 벌어지고 있을까요?
보통 전공 서적이나 면접 대비용 블로그 글을 보면 머리부터 아파옵니다.
DNS Lookup, TCP 3-way Handshake...
글자만 봐도 벌써 졸리죠?
그런데 최근 해커뉴스(Hacker News)에서 아주 흥미로운 프로젝트를 하나 발견했습니다.
'브라우저 동작 방식에 대한 대화형 가이드'라는 웹사이트입니다.
백문이 불여일견이라고, 글로 배우는 게 아니라 직접 버튼을 눌러가며 눈으로 보는 방식이더군요.
오늘은 이 가이드 내용을 바탕으로, 우리가 꼭 알아야 할 핵심만 쏙 뽑아서 이야기해볼까 합니다.
커피 한 잔 들고 편하게 들어보세요.
가장 먼저, 주소창에 무언가를 입력하는 순간부터 시작해볼까요?
우리는 그냥 google.com이나 pizza라고 대충 칩니다.
하지만 브라우저는 꽤 똑똑한 비서입니다.
pizza라고 치면 검색 엔진 URL로 변환해주고,
example.com이라고 치면 알아서 https://를 붙여서 완전한 URL로 만들어줍니다.
이 과정을 '정규화(Normalization)'이라고 부르죠.
주소가 확실해지면 이제 서버를 찾아가야 합니다.
문제는 브라우저가 example.com이라는 영어 이름을 모른다는 겁니다.
컴퓨터는 숫자, 즉 IP 주소만 알아듣거든요.
그래서 DNS(Domain Name System)라는 전화번호부에 물어봐서 IP를 알아냅니다.
여기까지는 많이들 아실 겁니다.
진짜 재미있는 건 그 다음, TCP 연결입니다.
이 가이드 사이트에서는 패킷이 날아가는 걸 시각적으로 보여주더군요.
서버와 데이터를 주고받기 전에 "나 보낼 준비 됐어?", "어, 나도 준비 됐어!" 하고 확인하는 과정이죠.
이걸 3-way Handshake라고 합니다.
SYN 보내고, SYN-ACK 받고, 다시 ACK 보내고.
이 과정이 있어야 데이터가 중간에 유실되지 않고 순서대로 도착한다는 걸 보장할 수 있습니다.
네트워크가 불안정하면 이 과정에서 시간이 걸리고, 사용자는 흰 화면만 보게 되는 거죠.
연결이 되면 드디어 HTML을 받아옵니다.
그런데 받아온 HTML은 그냥 텍스트 덩어리일 뿐입니다.
브라우저는 이걸 해석해서 DOM 트리라는 구조를 만듭니다.
이 과정이 꽤 너그럽다는 사실, 알고 계셨나요?
개발자가 실수로 닫는 태그(</h1>)를 빼먹어도 브라우저는 최대한 알아서 고쳐서 트리를 만듭니다.
파싱 중에 <script> 태그를 만나면 자바스크립트를 실행하기 위해 잠시 멈추기도 하고요.
자, 이제 아까 그 주니어 개발자의 고민으로 돌아가 볼까요?
화면이 왜 버벅거렸을까요?
범인은 바로 렌더링 파이프라인에 있었습니다.
DOM 트리가 완성되면 브라우저는 화면을 그리기 시작합니다.
이때 Layout(레이아웃), Paint(페인트), Composite(컴포지트) 단계를 거칩니다.
Layout은 요소의 크기와 위치를 계산하는 단계입니다.
기하학적인 계산이 들어가기 때문에 비용이 아주 비쌉니다.
Paint는 색을 칠하는 단계, Composite는 레이어를 합치는 단계죠.
그 친구 코드를 보니, 스크롤 할 때마다 요소의 width(너비)를 변경하고 있었습니다.
너비가 바뀌면?
브라우저는 위치와 크기를 처음부터 다시 계산해야 합니다.
즉, 가장 비싼 Layout 단계를 계속 다시 실행하고 있었던 겁니다.
이걸 리플로우(Reflow)라고 부릅니다.
단순히 색상(color)만 바꿨다면 Layout을 건너뛰고 Paint만 하면 돼서 훨씬 빨랐을 텐데 말이죠.
이 원리를 알고 나면 최적화 포인트가 보입니다.
"아, 애니메이션 줄 때는 width나 height 대신 transform을 써야겠구나."
왜냐하면 transform은 Layout과 Paint를 건너뛰고 바로 Composite 단계로 넘어가거든요.
GPU의 도움을 받으니 훨씬 부드럽고요.
이 가이드 사이트에서는 슬라이더를 움직여서 직접 테스트해볼 수 있습니다.
너비를 바꿨을 때와 색상을 바꿨을 때, 브라우저가 어떤 일을 수행하는지 눈으로 보여줍니다.
이런 게 진짜 공부죠.
단순히 "리액트 잘해요", "뷰 잘해요"보다 중요한 건 기반 지식입니다.
프레임워크는 계속 바뀌지만, 브라우저의 기본 동작 원리는 쉽게 변하지 않으니까요.
오늘 점심 먹고 나서 5분만 투자해서 이 과정을 한 번 눈으로 따라가 보세요.
머릿속에 뿌옇게 있던 개념들이 선명한 그림으로 그려질 겁니다.
우리는 코더가 아니라 엔지니어니까요.
