그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Network
Network

인터넷 창에 www.google.com를 입력하면 무슨 일이 일어나는지 설명해주세요

실무4/5
설계3/5
인간3/5
기초4/5

면접관의 질문 의도

외운 흐름만 읊는 사람인지, 실제 느린 페이지 앞에서 어디부터 의심하는지를 가르는 질문이다.

큐레이션 답변

학습 자료

도메인을 입력하면 브라우저는 먼저 캐시·hosts·재귀 DNS로 IP를 얻는다. 그다음 TCP 3-way handshake로 연결을 맺고 HTTPS면 TLS 핸드셰이크까지 거친 뒤 HTTP 요청을 보낸다. 서버가 HTML/CSS/JS와 서브리소스를 응답하면 브라우저는 이를 파싱해 렌더링 파이프라인(DOM/CSSOM → 레이아웃 → 페인트 → 컴포지팅)을 돌려 화면을 그린다. 즉 네트워크 계층과 렌더링 계층이 직렬로 이어진 과정이고, 어느 한 단계라도 길어지면 첫 화면이 늦는다.

좋은 답변 구조

  1. 01URL 파싱·DNS·TCP/TLS·HTTP·렌더링의 각 단계 역할을 먼저 정의한다
  2. 02캐시 히트, HSTS, 0-RTT 같은 분기 조건과 예외 동작을 짚는다
  3. 03각 단계가 길어졌을 때 발생하는 증상과 측정 지점을 연결한다
  4. 04실무에서 어느 구간을 어떤 도구(DevTools waterfall, RUM)로 본 적 있는지 마무리한다

자주 실수하는 포인트

DNS와 TCP/TLS 단계를 생략하고 바로 HTTP 요청부터 설명한다
HTTPS에서 TLS 핸드셰이크 비용을 무시한다
HTML 파싱과 JS 평가, 렌더 차단 리소스의 영향을 구분하지 못한다
캐시 히트가 어느 단계를 건너뛰게 하는지 설명하지 못한다

실무 맥락

  • 첫 화면이 느리다는 신고가 들어와 DevTools Network로 구간별 시간을 봐야 하는 상황
  • 글로벌 서비스에서 지역별로 TTFB가 들쑥날쑥할 때 DNS/CDN 경로를 의심해야 하는 상황
  • API 응답은 빠른데 화면 표시가 늦어 렌더 차단 리소스를 골라내야 하는 상황

본인 경험에 녹이는 힌트

DevTools waterfall로 "DNS는 짧은데 TTFB가 길더라"처럼 구간을 갈라본 적이 있다면 어떻게 우선순위를 잡았는지 연결할 수 있다

CDN/캐시 정책 변경으로 초기 로딩이 줄어든 경험이 있다면 어느 단계를 건너뛰게 했는지로 말할 수 있다

서버 응답 시간과 렌더 비용을 분리해 팀에 보고한 적이 있다면 단계별 분해 능력을 보여주는 후크가 된다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1DNS 캐시가 있으면 어떤 단계가 생략되나요
Q2HTTP/2나 HTTP/3는 이 흐름에 어떤 차이를 만드나요
Q3TLS 핸드셰이크 비용을 줄이는 방법은 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문