주소창에 URL을 치면 생기는 일 — 비전공자를 위한 웹 서비스 동작 원리

브라우저 주소창에 쇼핑몰 주소를 입력하고 엔터를 누르면 1~2초 만에 화면이 뜹니다. 그 짧은 시간 동안 DNS, 네트워크 연결, 암호화, 로드밸런서, 웹 서버, 데이터베이스가 차례로 일을 합니다. 웹 서비스 동작 원리를 이 한 바퀴로 이해해 두면, 개발자와 회의할 때 "DNS 문제 같아요", "502가 나요", "DB가 느려요" 같은 말이 각각 어느 지점을 가리키는지 바로 그려집니다.

이 글은 비전공자도 따라올 수 있도록 요청 하나가 지나가는 길을 다섯 구간으로 나누고, 구간마다 장애가 나면 어떤 증상이 보이는지 함께 정리합니다.

🚀 큰 그림 — 요청 하나가 지나가는 다섯 구간

전체 흐름을 먼저 한 줄로 요약하면 이렇습니다. 이름을 주소로 바꾸고(DNS), 그 주소로 안전한 통로를 열고(TCP·TLS 또는 QUIC), 입구에서 요청을 나눠 받고(CDN·로드밸런서·방화벽), 서버가 데이터를 꺼내 답을 만들고(웹·애플리케이션 서버·DB), 브라우저가 그 답을 화면으로 그립니다.

구간	하는 일	비유
1. 이름 풀이(DNS)	도메인을 IP 주소로 변환	상호로 가게 주소 찾기
2. 연결과 암호화	서버와 통신 통로를 열고 암호화 합의	문을 열고 암호 정하기
3. 입구 관리	CDN·로드밸런서·방화벽이 요청을 걸러 분배	안내 데스크와 보안 검색대
4. 처리	웹·애플리케이션 서버가 DB에서 데이터를 꺼내 응답 생성	주방에서 창고 재료로 요리
5. 표시	브라우저가 HTML·CSS·이미지를 받아 화면 구성	요리를 접시에 담아 내기

💡 1구간 — DNS, 이름을 주소로 바꾸기

컴퓨터끼리는 www.example.com 같은 이름이 아니라 IP 주소로 통신합니다. 그래서 브라우저는 먼저 이름에 해당하는 주소를 찾습니다. 순서는 가까운 곳부터입니다. 브라우저가 기억해 둔 캐시, 운영체제의 캐시를 먼저 보고, 없으면 통신사나 회사가 운영하는 리졸버에 묻습니다. 리졸버는 필요하면 루트 네임서버, .com 같은 최상위 도메인(TLD) 서버, 그 도메인을 실제로 관리하는 권한 있는 네임서버 순서로 물어 답을 얻어 옵니다.

대부분의 경우 이 과정은 거의 시간이 들지 않습니다. 답이 이미 어딘가의 캐시에 있기 때문입니다. 캐시가 얼마나 오래 유지될지는 DNS 레코드의 TTL 값이 정합니다. 서버를 옮기면서 DNS를 바꿨는데 일부 사용자만 예전 서버로 접속하는 현상이 생기는 이유가 바로 이 캐시입니다. DNS가 실패하면 브라우저는 "사이트에 연결할 수 없음", "서버 IP 주소를 찾을 수 없음" 같은 메시지를 보여 줍니다.

🔐 2구간 — 연결을 열고 암호화하기

주소를 알았으면 통로를 엽니다. 전통적으로는 TCP가 세 번 신호를 주고받는 3-way handshake로 연결을 만들고, 그 위에서 TLS가 서버 인증서를 확인하고 암호화 방식을 합의합니다. 주소창의 자물쇠 표시가 이 단계가 성공했다는 뜻입니다. 인증서 기간이 지나면 브라우저가 경고 화면을 띄우는데, 실무에서 꽤 자주 일어나는 장애 유형입니다.

최근에는 HTTP/3가 빠르게 퍼지고 있습니다. HTTP/3는 TCP 대신 UDP 위의 QUIC 프로토콜을 써서 연결과 암호화 합의를 더 적은 왕복으로 끝냅니다. 웹 기술 조사 사이트 W3Techs의 2026년 3월 집계에서는 전체 웹사이트의 약 38.6%가 HTTP/3를 지원했습니다. 암호화도 진화하고 있어, Cloudflare는 2025년 연간 보고서에서 자사 네트워크를 지나는 사람의 웹 트래픽 중 52%가 양자 컴퓨터 시대를 대비한 암호(post-quantum)로 보호됐다고 밝혔습니다. 연초 29%에서 크게 늘어난 수치입니다.

🏗️ 3구간 — CDN, 로드밸런서, 방화벽과 DMZ

규모 있는 서비스는 요청을 서버 한 대가 직접 받지 않습니다. 이미지·동영상·스크립트 같은 정적 파일은 사용자와 가까운 곳에 복사본을 둔 CDN이 대신 응답해 원본 서버의 부담을 줄입니다. 나머지 요청은 로드밸런서가 받아 여러 대의 서버에 고르게 나눠 줍니다. 서버 한 대가 고장 나도 로드밸런서가 그 서버를 빼고 나머지로 보내면 서비스는 계속됩니다.

보안 구역도 이 구간에서 나뉩니다. 방화벽은 허용된 통신만 통과시키고, 외부 사용자가 직접 드나들어야 하는 웹 서버는 DMZ라는 완충 구역에 둡니다. 데이터베이스처럼 중요한 자원은 그보다 안쪽 내부망에 두어, 웹 서버가 뚫려도 바로 DB까지 닿지 않게 합니다. 이 구간에서 장애가 나면 사용자는 502 Bad Gateway(뒤쪽 서버가 이상한 응답을 줌), 503 Service Unavailable(지금 처리할 수 없음), 504 Gateway Timeout(뒤쪽 서버가 제때 답하지 않음) 같은 오류를 보게 됩니다.

🗄️ 4구간 — 서버와 데이터베이스가 답을 만들기

요청이 도착하면 웹 서버가 정적 파일은 바로 돌려주고, 로그인·장바구니처럼 사람마다 다른 화면은 애플리케이션 서버(WAS)로 넘깁니다. 애플리케이션 서버는 코드를 실행하며 데이터베이스에 "이 회원의 장바구니를 달라"고 묻고, 받은 데이터로 응답을 만듭니다. 자주 쓰는 데이터는 Redis 같은 메모리 캐시에 두어 DB까지 가지 않고 빠르게 꺼냅니다.

이 구간은 "사이트가 느려요"라는 민원의 단골 원인입니다. 인덱스가 없는 조회, 갑자기 몰린 트래픽, 디스크 공간 부족, 백업 작업과 겹친 시간대 등이 응답 시간을 늘립니다. 오늘날 이 서버들은 물리 서버 위의 가상머신, 클라우드 인스턴스, 또는 컨테이너로 돌아가는 경우가 많고, 컨테이너가 많아지면 쿠버네티스 같은 도구로 배치와 복구를 자동화합니다.

📊 증상으로 구간 짚어 보기

이제 회의에서 들리는 말을 다섯 구간에 대응시켜 봅시다. 어느 구간 문제인지만 맞혀도 누구에게 물어야 할지, 얼마나 걸릴지 감이 생깁니다.

들리는 말·증상	의심 구간	주로 보는 사람
"주소를 못 찾는대요", 일부 사용자만 옛 화면	1구간 DNS·캐시	인프라·네트워크 담당
"인증서 경고가 떠요"	2구간 TLS 인증서	인프라·보안 담당
502·503·504 오류	3구간 로드밸런서 뒤 서버 상태	인프라·백엔드
"이미지만 안 떠요"	3구간 CDN 또는 스토리지	인프라·프론트엔드
"특정 화면만 느려요"	4구간 애플리케이션 코드·DB 조회	백엔드·DBA

직접 확인해 보고 싶다면 크롬에서 F12로 개발자 도구를 열고 Network 탭을 보세요. 요청마다 상태 코드와 걸린 시간이 나오고, Protocol 열을 켜면 h2나 h3처럼 어떤 HTTP 버전으로 통신했는지도 보입니다. 터미널에서 nslookup 도메인 을 입력하면 DNS가 돌려주는 IP 주소를 확인할 수 있습니다.

❓ 자주 묻는 질문 (FAQ)

Q1. 비전공자도 이런 흐름을 알아야 하나요?

기획·영업·운영 직무라도 장애 공지, 일정 협의, 고객 응대에서 이 구간 이야기가 계속 나옵니다. 세부 설정까지는 몰라도 어느 구간 문제인지 구분할 수 있으면 대화가 훨씬 빨라집니다.

Q2. DNS를 바꿨는데 왜 바로 반영되지 않나요?

리졸버와 브라우저, 운영체제가 기존 답을 TTL 동안 캐시하기 때문입니다. 이전 계획이 있다면 미리 TTL을 짧게 줄여 두는 것이 일반적인 방법입니다.

Q3. HTTP/3를 쓰면 무조건 빨라지나요?

연결 수립이 빨라지고 패킷 손실이 잦은 모바일 환경에서 이점이 크지만, 서버·CDN·네트워크 장비가 모두 지원해야 하고 지원하지 않으면 이전 버전으로 자동 전환됩니다.

Q4. 502와 504는 어떻게 다른가요?

둘 다 로드밸런서나 프록시 뒤의 서버 문제입니다. 502는 뒤쪽 서버가 잘못된 응답을 준 경우, 504는 정해진 시간 안에 응답하지 않은 경우입니다.

Q5. 클라우드를 쓰면 이 구조가 바뀌나요?

구조는 같고, 각 구간을 직접 장비로 운영하느냐 클라우드 서비스로 빌려 쓰느냐가 달라집니다. 로드밸런서, DNS, CDN, DB 모두 클라우드 서비스 형태로 제공됩니다.

📚 인프라 전체 지도를 한 번에 잡으려면

이 글은 요청 하나의 길을 따라갔지만, 실제 인프라는 서버·네트워크·스토리지·DB 각각에 더 깊은 이야기가 있습니다. 누구나패스의 「모두를 위한 IT 인프라 기초」는 서버, 네트워크, 스토리지, 데이터베이스에서 출발해 온프레미스와 가상화, 클라우드 컴퓨팅, 컨테이너와 쿠버네티스, 개발 방법론과 DevOps, IT 운영과 보안, AI 인프라까지 10차시(총 4시간 26분)로 다룹니다. 『이토록 쉬운 IT 인프라 기초』의 저자 장두환 강사가 비유 중심으로 설명하는 입문 과정이라 실습 환경 없이 PC·모바일로 들을 수 있고, 수강 기간은 결제 후 30일입니다.

---

회의에서 들리는 인프라 용어를 하나의 흐름으로 정리하고 싶다면 IT 인프라 기초 과정 자세히 보기에서 차시 구성을 확인하세요.