코드 땜장이

CSS Flexbox와 Grid, 무엇이 다르고 언제 선택해야 할까 빠른 답 한 줄 정렬, 버튼 그룹, 메뉴 바처럼 콘텐츠 흐름이 먼저 보이는 화면은 Flexbox 쪽이 더 단순하게 풀리는 경우가 많습니다. 페이지 골격, 카드 목록, 대시보드처럼 행과 열 규칙을 먼저 정해야 하는 화면은 Grid가 더 읽기 쉽고 배치도 안정적으로 유지됩니다. 둘은 대체재라기보다 함께 쓰는 경우가 많습니다. 바깥 구조는 Grid로, 카드나 헤더 내부 정렬은 Flexbox로 나누면 역할이 또렷해집니다. 1차원 과 2차원 이라는 구분만 외우기보다, 콘텐츠 크기 변화가 먼저인지 배치 규칙이 먼저인지로 보면 선택이 한결 쉬워집니다. Flexbox와 Grid는 둘 다 CSS 레이아웃 도구이지만, 브라우저가 레이아웃을 계산하는 출발점이 다릅니다. 브라우저는 DOM과 CSSOM을 합쳐 렌더 트리를 만든 뒤 레이아웃 단계에서 박스의 크기와 위치를 정하는데, 이때 Flexbox는 아이템 흐름을 중심에 두고, Grid는 트랙 구조를 중심에 둡니다. 목차 한눈에 비교 시간 흐름으로 이해하기 브라우저 안에서 실제로 무슨 순서로 일어날까 왜 둘 다 정렬 도구처럼 보여 헷갈릴까 선택 기준 매트릭스 Flexbox가 먼저 떠오르는 장면 Grid가 먼저 떠오르는 장면 함께 쓰는 구성이 더 자연스러운 경우 DevTools로 확인하는 포인트 자주 헷갈리는 지점 더 읽을 거리 한눈에 비교 출발점 Flexbox는 아이템의 순서와 크기를 따라 남는 공간을 분배하고, Grid는 컨테이너의 행과 열을 먼저 선언한 뒤 아이템을 그 위에 올립니다. 계산 축 Flexbox는 주 축과 교차 축이라는 한 축 중심 계산이 기본이고, Grid는 행과 열을 함께 다루는 2차원 배치가 기본입니다. 줄바꿈 이후 Flexbox는 flex-wrap 이 걸려도 각 줄이 독립적으로 공간을 나누고, Grid는 같은 열 트랙을 공유하므로 열 폭이 더 일정하게 유지됩니다. 제어 위치 Flexbox는 flex-grow , flex-sh...

웹 애플리케이션 성능 최적화, 로딩 경로별로 정리하는 핵심 방법 빠른 답 첫 화면에 필요 없는 JavaScript는 분리하고 늦게 불러와야 초기 로딩이 빨라집니다. 이미지와 비디오는 화면에 보일 때 로드하고, 크기와 포맷을 먼저 줄여야 체감 성능이 좋아집니다. 캐시는 단순 저장이 아니라 정적 자산과 HTML의 정책을 다르게 가져가야 효과가 큽니다. 최적화는 감으로 하지 말고 Network, Performance, Lighthouse 같은 측정 결과로 우선순위를 잡아야 합니다. 목차 왜 웹 성능은 로딩 경로로 봐야 할까 흐름으로 보기 요청 시작과 리소스 다운로드에서 생기는 병목 파싱과 실행: DOM, CSSOM, JavaScript가 서로 만나는 지점 렌더링: 렌더 트리, 레이아웃, 페인트, 컴포지팅의 비용 초기 로딩을 줄이는 설정 무거운 자산을 늦게 가져오는 방법 재방문 속도를 높이는 캐시 전략 DevTools로 병목을 반복 측정하는 방법 흔한 오해와 함께 보는 정리 포인트 왜 웹 성능은 로딩 경로로 봐야 할까 같은 300KB라도 언제 내려오고 무엇을 막느냐에 따라 체감은 크게 달라집니다. 첫 화면에 바로 필요한 CSS 300KB와, 아직 열지 않은 설정 페이지의 JavaScript 300KB는 사용자 경험에 미치는 영향이 다릅니다. 그래서 성능 최적화는 파일 크기를 줄이는 일에만 머물지 않고, 어떤 자원이 어떤 단계의 병목이 되는지 파악하는 작업에 가깝습니다. 브라우저 관점에서 병목은 보통 세 갈래로 나타납니다. 네트워크에서 늦게 내려오는 경우, JavaScript 파싱과 실행 때문에 메인 스레드가 오래 묶이는 경우, 렌더링 단계에서 레이아웃과 페인트가 반복되는 경우입니다. 이 세 지점을 로딩 경로 하나로 묶어 보면 코드 스플리팅, 레이지 로딩, 캐시, CSS 최적화가 각각 어디에 영향을 주는지 자연스럽게 연결됩니다. 흐름으로 보기 이 순서를 먼저 잡아두면 최적화 기법의 위치가 정리됩니다. 코드 스플리팅과 defer 는 초기 다운로드와...

브라우저 주소창에 URL을 입력하면 화면이 뜨기까지: DNS부터 렌더링까지 빠른 답 주소 입력 뒤 바로 화면이 뜨는 것이 아니라 DNS 조회, 연결 수립, TLS 협상, HTTP 요청, 렌더링이 순서대로 진행됩니다. 첫 화면 속도는 서버 응답 시간만이 아니라 CSS 다운로드, JavaScript 실행, 레이아웃·페인트 비용에도 크게 영향을 받습니다. HTTPS 사이트는 요청 전에 인증서 검증과 키 협상이 들어가므로 TLS 단계가 별도 병목이 될 수 있습니다. 병목은 Chrome DevTools의 Network와 Performance 탭으로 네트워크 지연과 렌더링 비용을 나눠 확인하는 것이 가장 빠릅니다. 목차 흐름으로 보기 왜 이 과정을 같이 봐야 하나 연결이 열리기 전: DNS, TCP, TLS, HTTP 응답이 화면이 되는 핵심: DOM, CSSOM, 렌더 트리 레이아웃, 페인트, 컴포지팅은 각각 무엇을 하나 첫 화면을 늦추는 흔한 비용 DevTools로 병목을 어떻게 찾나 구성과 설정으로 줄일 수 있는 비용 면접과 실무에서 자주 틀리는 설명 흐름으로 보기 1 DNS 조회 ↓ 2 TCP 연결 ↓ 3 TLS 협상 ↓ 4 HTTP 요청/응답 ↓ 5 DOM·CSSOM 생성 ↓ 6 레이아웃·페인트·컴포지팅 이 여섯 단계는 웹 페이지 로딩의 가장 큰 뼈대입니다. 앞쪽은 리소스를 받아오는 네트워크 흐름이고, 뒤쪽은 받은 데이터를 실제 화면으로 바꾸는 브라우저 렌더링 흐름입니다. 페이지가 느릴 때 원인을 정확히 찾으려면 이 둘을 섞지 말고 끊어서 봐야 합니다. 왜 이 과정을 같이 봐야 하나 브라우저 주소창에 https://www.google.com 을 입력하는 행동은 단순히 “서버에 요청한다”로 끝나지 않습니다. 브라우저는 먼저 어디로 연결할지 찾아야 하고, 안전한 연결을 만들어야 하며, HTML과 정적 자원을 받아온 뒤 그것을 다시 화면용 구조로 바꿔야 합니다. 사용자가 보는 첫 화면은 서버 응답 그 자체가 아니라, 브라우저가 수행한 렌더링 파이...