개발자는 왜 네트워크를 알아야 할까?
요청과 응답은 생각보다 단순하지 않다
웹 개발을 하다 보면 우리는 자연스럽게 이런 말을 많이 쓴다.
“API 요청을 보낸다.”
“서버에서 응답을 받는다.”
“프론트에서 백엔드로 요청이 간다.”
“배포했는데 접속이 안 된다.”
“서버는 살아 있는데 왜 안 되지?”
처음에는 이 말들이 꽤 단순하게 느껴졌다.
브라우저에서 버튼을 누르면 요청이 가고, 서버가 처리해서 응답을 준다.
프론트엔드는 화면을 만들고, 백엔드는 데이터를 내려준다.
도메인을 입력하면 웹사이트가 열린다.
이 정도로만 이해해도 개발을 시작하는 데 큰 문제는 없었다.
그런데 개발을 하다 보면 어느 순간부터 이상한 질문들이 생긴다.
요청이 간다고 하는데, 그 요청은 어디로 가는 걸까?
서버가 응답한다고 하는데, 그 응답은 어떤 길을 따라 다시 돌아오는 걸까?
내 컴퓨터는 서버의 위치를 어떻게 알고 있을까?
도메인을 입력했을 뿐인데 왜 IP 주소가 필요할까?
포트는 왜 붙고, 방화벽은 어디서 막고, 로드밸런서는 어떤 기준으로 서버를 고를까?
서버는 살아 있는데 접속이 안 될 수 있다
코드는 정상인데 요청이 서버까지 도착하지 않을 수 있다.
서버 프로세스는 살아 있는데 외부에서는 접속이 안 될 수 있다.
도메인은 맞는데 DNS 설정이 잘못되어 있을 수 있다.
포트가 닫혀 있을 수도 있고, 방화벽이나 보안 그룹에서 막힐 수도 있다.
로드밸런서는 살아 있지만 뒤에 있는 서버로 트래픽을 제대로 보내지 못할 수도 있다.
이런 상황이 오면 단순히 “안 된다”로 끝낼 수 없다.
어디까지는 정상이고, 어디서부터 문제가 생겼는지 좁혀가야 한다.
그러려면 요청이 어떤 과정을 거쳐 서버까지 가는지,
응답이 다시 클라이언트로 돌아오는 동안 어떤 장비와 규칙을 지나는지 알아야 한다.
네트워크는 요청의 이동 경로를 이해하는 일이다
예를 들어 브라우저에서 example.com에 접속한다고 해보자.
겉으로 보기에는 주소창에 도메인을 입력하고 엔터를 누른 것뿐이다.
하지만 내부에서는 꽤 많은 일이 일어난다.
도메인 이름을 IP 주소로 바꾸고,
목적지 서버까지 갈 수 있는 경로를 찾고,
중간 장비들을 지나고,
서버의 특정 프로그램이 기다리고 있는 포트로 도착하고,
서버는 요청을 해석한 뒤 다시 응답을 보낸다.
사용자는 그냥 웹페이지를 보는 것이지만,
그 뒤에서는 여러 장비와 규칙들이 계속 판단하고 있다.
“이 요청은 어디로 보내야 하지?”
“이 주소는 같은 네트워크 안에 있나, 밖에 있나?”
“이 데이터는 어떤 프로그램에게 전달해야 하지?”
“이 연결은 안전한가?”
“이 서버가 응답하지 않으면 다른 서버로 보내야 하나?”
네트워크 공부는 이런 판단 과정을 하나씩 이해하는 일에 가깝다.
처음부터 모든 용어를 완벽히 외우려고 하면 금방 지친다.
OSI 7계층, TCP/IP, IP 주소, MAC 주소, 포트, DNS, HTTP, TLS 같은 단어들이 한꺼번에 나오면 머릿속에서 서로 엉키기 쉽다.
그래서 나는 이 시리즈를 하나의 흐름으로 정리해보려고 한다.
출발점은 단순하다.
클라이언트가 요청을 보내고, 서버가 응답한다.
웹 개발을 하면서 가장 자주 마주치는 이 구조에서 시작해서,
그 요청과 응답이 실제 네트워크 안에서 어떻게 이동하는지 하나씩 따라가보는 방식이다.
큰 그림부터 다시 보기
처음에는 네트워크를 아주 큰 그림으로 바라본다.
정보를 주고받는 장치들이 있고,
그 장치들을 연결하는 통신 매체가 있고,
그 사이를 오가는 메시지가 있다.
이 단순한 구조 위에서 클라이언트와 서버가 등장하고,
요청과 응답이라는 흐름이 만들어진다.
그다음에는 통신에 필요한 규칙을 살펴본다.
사람끼리 대화할 때도 같은 언어와 약속이 필요하듯이, 컴퓨터끼리도 데이터를 주고받기 위한 규칙이 필요하다.
그 규칙들이 프로토콜이고,
데이터는 여러 단계를 거치며 형태를 바꿔가며 이동한다.
이후에는 같은 네트워크 안에서 데이터를 주고받는 방법,
다른 네트워크로 넘어가는 방법,
IP 주소와 포트가 필요한 이유,
TCP와 UDP의 차이,
DNS가 도메인을 IP로 바꾸는 과정,
HTTP 요청과 응답의 구조까지 차근차근 연결해보려고 한다.
결국 알고 싶은 것
결국 목표는 하나다.
브라우저에 주소를 입력했을 때,
그 뒤에서 어떤 일이 벌어지는지 내 머릿속으로 설명할 수 있는 것.
그리고 장애가 발생했을 때
“서버가 이상한가?”에서 멈추는 게 아니라,
“DNS는 정상인가?”
“IP까지 도달 가능한가?”
“포트는 열려 있는가?”
“로드밸런서는 정상적으로 전달하고 있는가?”
“서버 프로세스는 요청을 받고 있는가?”
이런 식으로 원인을 단계적으로 좁혀갈 수 있는 것이다.
네트워크는 처음 보면 추상적이다.
눈에 보이지 않는 요청과 응답이 어딘가로 이동한다고 하니 막연하게 느껴진다.
그래서 이 공부는 최대한 “패킷이 여행한다”는 느낌으로 바라보려고 한다.
내 컴퓨터에서 출발한 데이터가 어떤 장비를 만나고,
각 장비는 무엇을 보고 판단하고,
어떤 기준으로 다음 목적지를 정하는지 따라가보는 것이다.
완벽한 네트워크 전문가가 되기 위한 공부라기보다는,
개발자로서 내가 작성한 코드 바깥에서 무슨 일이 일어나는지 이해하기 위한 공부다.
요청을 보내는 코드 한 줄 뒤에 어떤 흐름이 숨어 있는지,
응답을 받기까지 얼마나 많은 약속과 판단이 필요한지,
그 전체 그림을 조금씩 내 말로 정리해보려 한다.
