빠르고 안정적인 인터넷 만들기

연결만으로는 부족하다

지금까지 우리는 인터넷이 어떻게 연결되는지 배웠다. 비트가 길을 지나가고, IP 주소가 목적지를 가리키고, 라우터가 다음 길을 고르고, DNS가 이름을 주소로 바꾸고, 웹 서버가 요청에 응답했다. 여기에 HTTPS와 방화벽까지 더해 안전한 통신의 기본도 갖추었다.

하지만 실제 인터넷 서비스는 여기서 끝나지 않는다. 한 사람이 접속할 때는 잘 열리던 웹사이트도, 수천 명이 동시에 접속하면 느려지거나 멈출 수 있다. 서버 한 대가 고장 나면 서비스 전체가 사라질 수도 있다. 길이 하나뿐이면 그 길이 끊겼을 때 돌아갈 방법이 없다.

그래서 인터넷 서비스는 두 가지 질문에 답해야 한다.

첫째, 어떻게 더 빨리 응답할 것인가.

둘째, 어디가 고장 나도 어떻게 계속 동작하게 할 것인가.

이 장에서는 캐시, CDN, 로드 밸런서, 중복 구성을 살펴본다. 이 네 가지는 인터넷을 단순히 "연결되는 상태"에서 "많은 사람이 동시에 써도 버티는 상태"로 바꾸는 핵심 도구다.

AI 생성 이미지

캐시: 자주 쓰는 것은 가까이 둔다

캐시는 자주 쓰는 데이터를 가까운 곳에 잠시 저장해 두는 방식이다. 집 앞 편의점에 자주 사는 물건이 있으면 매번 먼 창고까지 갈 필요가 없는 것과 같다. 컴퓨터 세계에서는 이 가까운 임시 보관소를 캐시라고 부른다.

웹페이지를 볼 때도 같은 일이 일어난다. 로고 이미지, 글꼴 파일, 자주 바뀌지 않는 CSS 파일은 매번 원래 서버에서 다시 받을 필요가 없다. 브라우저가 이미 받은 파일을 자기 컴퓨터에 저장해 두었다가 다시 사용할 수 있다. 이것이 브라우저 캐시다.

서버 쪽에도 캐시가 있다. 예를 들어 사용자가 "인기 게시글 목록"을 요청할 때마다 데이터베이스를 처음부터 뒤질 필요는 없다. 서버는 한 번 계산한 결과를 잠시 저장해 두고, 다음 요청에는 저장된 결과를 바로 돌려줄 수 있다.

캐시가 있으면 응답 시간이 줄어든다. 먼 서버까지 왕복하지 않아도 되고, 서버가 같은 일을 반복하지 않아도 된다. 사용자는 더 빨리 화면을 보고, 서버는 더 적은 힘으로 더 많은 요청을 처리한다.

다만 캐시에는 조심할 점이 있다. 저장해 둔 데이터가 오래되면 실제 내용과 달라질 수 있다. 편의점에 예전 가격표가 붙어 있으면 손님이 혼란스러운 것과 같다. 그래서 캐시에는 보통 유효 시간이 붙는다. 이를 TTL, 즉 Time To Live라고 한다. "이 데이터는 몇 초 또는 몇 분 동안만 믿고 써도 된다"는 뜻이다. 시간이 지나면 다시 원래 서버에 확인하거나 새 데이터를 받아 온다.

캐시는 빠르게 만들지만, 오래된 내용을 보여 줄 위험도 만든다. 그래서 캐시를 쓸 때는 "얼마나 빨라져야 하는가"와 "얼마나 최신이어야 하는가"를 함께 생각해야 한다. 자주 바뀌지 않는 로고 이미지는 오래 저장해도 괜찮지만, 방금 수정한 게시글이나 결제 금액 같은 정보는 함부로 오래 저장하면 안 된다.

CDN: 콘텐츠를 사용자 가까이에 놓는다

캐시가 가까운 보관소라면, CDN은 전 세계 곳곳에 둔 큰 물류 창고망에 가깝다. 한국 사용자가 미국 서버에 있는 이미지를 매번 받는다면 데이터는 먼 길을 지나야 한다. 거리가 멀수록 시간이 늘어나고, 중간 경로가 복잡할수록 지연도 커질 수 있다.

CDN은 Content Delivery Network의 줄임말이다. 쉽게 말해, 이미지·동영상·JavaScript 파일처럼 많은 사람이 반복해서 받는 콘텐츠를 사용자 가까운 서버에 복사해 두는 네트워크다. 사용자가 웹사이트에 접속하면 모든 요청이 원래 서버까지 가지 않는다. 가까운 CDN 서버가 이미 가지고 있는 파일은 그 자리에서 바로 보내 준다.

예를 들어 원래 웹 서버가 한 곳에 있다고 하자. 서울의 사용자, 부산의 사용자, 도쿄의 사용자, 파리의 사용자가 모두 같은 서버에서 이미지를 받으면 원래 서버에 부담이 집중된다. CDN을 쓰면 각 지역 가까이에 있는 CDN 서버가 이미지를 대신 제공한다. 원래 서버는 모든 사용자에게 직접 응답하지 않아도 된다.

CDN이 동작하려면 보통 DNS와 함께 움직인다. 사용자가 static.example.com 같은 이름을 조회하면, DNS는 사용자 위치나 네트워크 상황에 따라 가까운 CDN 서버 주소를 알려 줄 수 있다. 이후 브라우저는 그 CDN 서버에서 파일을 받는다.

만약 가까운 CDN 서버에 필요한 파일이 없다면 어떻게 될까? 그때는 CDN이 원래 서버에 파일을 요청해 가져온 뒤 사용자에게 보내고, 필요하면 그 파일을 잠시 저장해 둔다. 다음 사용자가 같은 파일을 요청하면 이번에는 원래 서버까지 가지 않고 CDN에서 바로 받을 수 있다.

여기서 비유의 한계를 분명히 하자. CDN은 단순히 "복사본을 많이 두는 창고"만은 아니다. 실제 CDN은 캐시 정책, 압축, TLS 처리, 장애 우회, 공격 완화 같은 여러 기능을 함께 제공할 수 있다. 하지만 핵심 원리는 단순하다. 자주 쓰는 콘텐츠를 사용자 가까이에 놓아 먼 길을 덜 가게 하는 것이다.

CDN이 특히 잘하는 일은 잘 바뀌지 않는 파일을 빠르게 전달하는 것이다. 로고, 사진, 영상 조각, 내려받기 파일, 웹페이지를 꾸미는 정적 파일이 대표적이다. 반대로 사용자마다 내용이 크게 다른 장바구니, 개인 메시지, 결제 화면 같은 데이터는 조심해서 다루어야 한다. 다른 사람의 개인 정보가 캐시에 남으면 안 되기 때문이다.

로드 밸런서: 요청을 여러 서버에 나눈다

서버 한 대가 모든 요청을 받으면 언젠가는 한계에 닿는다. 식당 계산대가 하나뿐이면 손님이 몰릴 때 줄이 길어진다. 계산대를 여러 개 만들고 안내 직원이 손님을 빈 계산대로 보내면 줄이 줄어든다.

이 안내 직원 역할을 하는 장비나 소프트웨어가 로드 밸런서다. 로드 밸런서는 들어오는 요청을 여러 서버에 나누어 보낸다. 여기서 로드는 부하, 즉 서버가 처리해야 하는 일의 양을 뜻한다. 밸런싱은 균형 있게 나눈다는 뜻이다.

작은 인터넷 예제로 보면 이렇다. 사용자는 web.example.local에 접속한다. 이 이름은 실제 웹 서버 한 대가 아니라 로드 밸런서의 주소를 가리킨다. 로드 밸런서 뒤에는 웹 서버 1, 웹 서버 2, 웹 서버 3이 있다. 사용자는 서버가 여러 대인지 몰라도 된다. 요청은 먼저 로드 밸런서에 도착하고, 로드 밸런서가 적절한 서버를 골라 넘긴다.

나누는 방법은 여러 가지다. 가장 단순한 방식은 차례대로 보내는 것이다. 첫 번째 요청은 서버 1, 두 번째 요청은 서버 2, 세 번째 요청은 서버 3으로 보내는 식이다. 이를 라운드 로빈이라고 한다. 또 다른 방식은 현재 연결이 적은 서버에 보내는 것이다. 서버마다 처리 중인 일이 다를 때 유용하다.

로드 밸런서가 중요한 이유는 요청 분산만이 아니다. 서버가 살아 있는지도 확인한다. 이를 헬스 체크라고 한다. 건강 검진처럼 서버에 작은 요청을 보내 "응답할 수 있는 상태인가"를 확인한다. 서버 2가 고장 나면 로드 밸런서는 서버 2로 새 요청을 보내지 않는다. 사용자는 잠깐 느려질 수는 있어도 서비스 전체가 바로 멈추지는 않는다.

다만 로드 밸런서를 쓴다고 모든 문제가 자동으로 사라지지는 않는다. 서버들이 같은 데이터를 볼 수 있어야 한다. 로그인 상태를 한 서버의 메모리에만 저장하면, 다음 요청이 다른 서버로 갔을 때 사용자가 로그아웃된 것처럼 보일 수 있다. 그래서 여러 서버를 운영할 때는 세션 저장소, 데이터베이스, 파일 저장소 같은 공용 자원을 어떻게 둘지도 함께 설계해야 한다.

또 하나 기억할 점이 있다. 로드 밸런서가 서버 여러 대를 지켜 주더라도, 로드 밸런서 자체가 한 대뿐이면 그 장비가 새로운 단일 장애 지점이 될 수 있다. 그래서 중요한 서비스에서는 로드 밸런서도 둘 이상 두고, 앞단의 DNS나 네트워크 구성까지 함께 살핀다.

중복 구성: 하나가 고장 나도 길을 남긴다

안정적인 인터넷의 핵심은 "하나가 고장 나면 끝나는 지점"을 줄이는 것이다. 이런 지점을 단일 장애 지점이라고 한다. 영어로는 Single Point of Failure라고 부른다. 길이 하나뿐인 다리, 전원 하나에만 연결된 장비, 서버 한 대뿐인 서비스가 모두 여기에 해당한다.

중복 구성은 같은 역할을 할 수 있는 것을 둘 이상 준비하는 방식이다. 회선이 하나 끊겨도 다른 회선으로 나가고, 라우터 하나가 멈춰도 다른 라우터가 이어받고, 서버 하나가 죽어도 다른 서버가 응답하게 만든다.

회선 중복은 인터넷으로 나가는 길을 두 개 이상 두는 것이다. 회사나 데이터센터는 서로 다른 통신사의 회선을 함께 쓰기도 한다. 한 통신사 구간에 문제가 생겨도 다른 길로 통신할 수 있게 하기 위해서다.

장비 중복은 라우터, 스위치, 방화벽, 로드 밸런서 같은 장비를 한 대만 두지 않는 것이다. 두 장비가 동시에 일하는 방식을 액티브-액티브라고 하고, 한 대가 일하다가 고장 나면 대기 중이던 장비가 이어받는 방식을 액티브-스탠바이라고 한다. 이름은 어렵지만 원리는 간단하다. 계산대를 둘 다 열어 두느냐, 하나는 예비로 세워 두느냐의 차이다.

서버 중복은 같은 서비스를 제공하는 서버를 여러 대 두는 것이다. 로드 밸런서와 함께 쓰면 한 서버의 장애가 전체 장애로 번지는 것을 막을 수 있다. 여기에 데이터베이스 복제, 백업, 다른 지역의 예비 시스템까지 더하면 더 큰 장애에도 버틸 수 있다.

하지만 중복 구성에도 비용이 든다. 장비가 늘고, 설정이 복잡해지고, 감시해야 할 대상도 많아진다. 그래서 모든 것을 무조건 두 배로 만드는 것이 답은 아니다. 중요한 서비스부터, 고장 났을 때 영향이 큰 부분부터 중복해야 한다.

그리고 중복은 만들어 두는 것만으로 끝나지 않는다. 예비 회선이 실제로 트래픽을 받을 수 있는지, 대기 장비가 정말 자동으로 이어받는지, 복제된 데이터가 필요한 순간에 제대로 읽히는지 시험해야 한다. 평소에는 멀쩡해 보이다가 진짜 장애가 났을 때 전환이 실패하면, 중복 구성은 그림 속 안전장치에 그치고 만다.

빠름과 안정성은 함께 설계한다

캐시, CDN, 로드 밸런서, 중복 구성은 서로 따로 움직이는 기술처럼 보이지만 실제로는 함께 동작한다.

사용자가 웹사이트에 접속하면 먼저 DNS가 가까운 CDN이나 로드 밸런서의 주소를 알려 줄 수 있다. 브라우저는 이미 저장된 파일이 있으면 캐시에서 읽는다. 없으면 CDN에서 받는다. CDN에도 없으면 CDN이 원래 서버에서 파일을 가져와 사용자에게 전달한다. 원래 서버 앞에서는 로드 밸런서가 여러 서버 중 하나를 고른다. 서버 한 대가 고장 나 있으면 헬스 체크 결과에 따라 다른 서버로 보낸다. 회선이나 장비가 중복되어 있다면 중간 길 하나가 끊겨도 다른 길로 우회할 수 있다.

이 흐름을 머릿속에 그리면, 인터넷 서비스가 왜 단순한 서버 한 대보다 훨씬 튼튼한지 보인다. 빠른 응답은 가까운 곳에서 처리하는 데서 나오고, 안정성은 대신할 수 있는 길과 장비를 준비하는 데서 나온다.

고장 나면 어디를 볼 것인가

빠르고 안정적인 구조는 문제를 숨기기도 한다. CDN 캐시 때문에 원래 서버의 수정 사항이 바로 보이지 않을 수 있다. 로드 밸런서 뒤의 서버 한 대만 고장 나면 어떤 요청은 성공하고 어떤 요청은 실패할 수 있다. 중복 회선 중 하나만 끊기면 평소보다 느리지만 완전히 끊기지는 않을 수 있다.

그래서 점검할 때는 구간을 나누어 봐야 한다.

먼저 캐시를 확인한다. 브라우저 캐시, DNS 캐시, CDN 캐시 중 오래된 데이터가 남아 있는지 본다. "서버에서는 고쳤는데 내 화면만 예전 그대로"라면 캐시가 원인일 수 있다.

다음으로 CDN을 확인한다. 가까운 CDN 서버가 응답하는지, 원래 서버까지 요청이 전달되는지, 특정 지역에서만 문제가 생기는지 살핀다. 전 세계 사용자가 모두 느린지, 한 지역 사용자만 느린지도 중요한 단서다.

그다음 로드 밸런서를 본다. 뒤쪽 서버들의 헬스 체크 상태가 정상인지, 특정 서버로 간 요청만 실패하는지 확인한다. 서버 여러 대 중 한 대만 설정이 다르면 장애가 간헐적으로 나타난다. 사용자는 "될 때도 있고 안 될 때도 있다"고 느낀다.

마지막으로 중복 구성을 본다. 예비 회선이 실제로 동작하는지, 대기 장비가 장애 시 자동으로 이어받는지, 서버가 여러 대 있어도 데이터 저장소가 하나뿐인 병목은 없는지 확인한다. 중복은 만들어 둔 것만으로 충분하지 않다. 실제로 전환되는지 주기적으로 시험해야 한다.

인터넷을 빠르고 안정적으로 만든다는 것은 마법 같은 가속 버튼을 누르는 일이 아니다. 자주 쓰는 것은 가까이 두고, 먼 길은 줄이고, 일을 여러 곳에 나누고, 고장 날 수 있는 곳에는 대체 경로를 마련하는 일이다. 이 원리를 알면 큰 인터넷 서비스도 결국 우리가 만든 작은 인터넷의 확장이라는 사실이 보인다.