지난 글에서 TCP는 데이터를 보내기 전에 연결을 만든다고 정리했다. 그런데 연결을 만들었다고 해서 데이터가 항상 안전하게 도착하는 것은 아니다.

네트워크에서는 패킷이 중간에 사라질 수도 있고, 순서가 뒤바뀔 수도 있고, 받는 쪽이 너무 바빠서 데이터를 감당하지 못할 수도 있다. TCP는 이런 상황을 고려해서 데이터를 보낸다.

여기서 중요한 건 TCP가 단순히 “보냈다”가 아니라, “상대가 제대로 받았는지까지 확인한다”는 점이다.

데이터에는 순서가 필요하다

TCP는 데이터를 보낼 때 각 데이터에 번호를 붙인다. 이 번호를 순서 번호라고 한다.

예를 들어 서버가 클라이언트에게 긴 데이터를 보내야 한다고 해보자. 이 데이터를 한 번에 통째로 보내는 것이 아니라 여러 조각으로 나누어 보낸다.

그런데 네트워크를 지나가다 보면 먼저 보낸 조각이 늦게 도착하고, 나중에 보낸 조각이 먼저 도착할 수도 있다.

받는 쪽 입장에서는 이런 상황이 된다.

“어? 두 번째 조각이 먼저 왔네?” “첫 번째 조각은 아직 안 왔는데?” “그럼 일단 기다렸다가 순서대로 맞춰야겠다.”

이때 필요한 것이 순서 번호다. TCP는 각 데이터 조각에 번호를 붙여두기 때문에, 받는 쪽은 도착한 데이터들을 순서대로 다시 맞출 수 있다.

택배로 비유하면 여러 박스에 나누어 물건을 보낼 때, 각 박스에 “1번 박스, 2번 박스, 3번 박스”라고 적어두는 것과 비슷하다. 박스가 순서대로 도착하지 않아도 번호를 보면 다시 정리할 수 있다.

ACK는 잘 받았다는 신호다

TCP에서는 데이터를 받은 쪽이 그냥 조용히 있지 않는다. 잘 받았으면 “여기까지 받았다”는 응답을 보내준다.

이 응답이 ACK다.

ACK는 확인 응답이라고 생각하면 된다. 보낸 쪽 입장에서는 ACK를 받아야 안심할 수 있다.

예를 들어 데이터를 보낸 쪽이 이렇게 생각한다고 해보자.

“100번부터 데이터를 보냈다.” “상대가 150번까지 잘 받았다고 알려줬다.” “그럼 이제 151번부터 보내면 되겠네.”

실제 TCP의 ACK 번호는 보통 “다음에 기대하는 번호”를 의미한다. 즉, 받는 쪽이 ACK 151을 보냈다면 “150까지는 받았고, 다음은 151부터 보내줘”라는 의미로 볼 수 있다.

여기서 TCP가 판단하는 방식은 꽤 단순하다.

“내가 보낸 데이터에 대한 ACK가 왔는가?” “왔다면 그 데이터는 도착한 것으로 본다.” “오지 않았다면 중간에 문제가 생겼을 가능성이 있다.”

이런 식으로 TCP는 데이터를 하나하나 추적한다.

ACK가 오지 않으면 다시 보낸다

네트워크에서는 데이터가 중간에 사라질 수 있다. 케이블이 끊어진 것처럼 극단적인 상황이 아니어도, 혼잡하거나 오류가 발생하면 패킷이 유실될 수 있다.

TCP는 데이터를 보낸 뒤 일정 시간 동안 ACK를 기다린다. 그런데 ACK가 오지 않으면 이렇게 판단한다.

“상대가 데이터를 못 받았나?” “아니면 ACK가 돌아오는 길에 사라졌나?” “어쨌든 확인이 안 됐으니 다시 보내야겠다.”

이것이 재전송이다.

여기서 중요한 건 TCP가 데이터 유실을 완전히 막는 것은 아니라는 점이다. 대신 유실이 발생했을 때 이를 감지하고 복구하려고 한다.

즉, TCP의 신뢰성은 “절대 안 잃어버린다”가 아니라 “잃어버렸을 가능성이 있으면 다시 보내서 맞춘다”에 가깝다.

오류 제어는 잘못된 데이터를 걸러내는 과정이다

TCP는 데이터가 도착했다고 해서 무조건 믿지 않는다. 전송 과정에서 데이터가 손상될 수도 있기 때문이다.

그래서 TCP는 데이터에 오류가 있는지 확인하고, 문제가 있다고 판단되면 해당 데이터를 정상적으로 받은 것으로 처리하지 않는다. 그러면 결국 ACK가 제대로 가지 않거나, 필요한 데이터가 다시 전송된다.

이 흐름을 오류 제어라고 볼 수 있다.

정리하면 오류 제어는 이런 질문에 대한 TCP의 대응이다.

“데이터가 중간에 사라지지 않았는가?” “데이터가 깨지지 않았는가?” “순서가 어긋나지는 않았는가?” “문제가 있다면 다시 받을 수 있는가?”

TCP는 순서 번호, ACK, 재전송을 이용해서 이런 문제를 해결하려고 한다.

너무 많이 보내도 문제다

데이터를 정확히 보내는 것도 중요하지만, 속도 조절도 중요하다.

보내는 쪽이 너무 빠르게 데이터를 밀어 넣으면 받는 쪽이 감당하지 못할 수 있다. 예를 들어 서버 성능은 좋은데 클라이언트의 처리 속도가 느리다면, 클라이언트는 받은 데이터를 버퍼에 쌓아두다가 결국 넘칠 수 있다.

이 문제를 해결하기 위한 것이 흐름 제어다.

흐름 제어는 간단히 말하면 받는 쪽이 감당할 수 있는 만큼만 보내도록 조절하는 것이다.

받는 쪽은 자신이 받을 수 있는 여유 공간을 알려준다. 보내는 쪽은 그 정보를 보고 전송량을 조절한다.

비유하면 물을 컵에 따르는 것과 비슷하다. 물을 따르는 사람이 아무리 빠르게 따를 수 있어도, 컵이 작으면 넘친다. 그러면 컵의 크기에 맞춰 천천히 따라야 한다.

TCP도 마찬가지다.

“상대 버퍼에 여유가 있나?” “있다면 더 보내도 되겠다.” “여유가 적다면 잠깐 줄여야겠다.”

이런 식으로 받는 쪽의 상태를 고려한다.

네트워크도 감당할 수 있는 양이 있다

흐름 제어가 받는 쪽의 상태를 보는 것이라면, 혼잡 제어는 네트워크 전체의 상태를 보는 것이다.

받는 쪽 컴퓨터가 아무리 충분히 받을 수 있어도, 중간 네트워크가 혼잡하면 문제가 생긴다. 라우터나 링크에 트래픽이 몰리면 패킷이 지연되거나 유실될 수 있다.

이때 TCP는 이렇게 판단한다.

“ACK가 늦게 오네?” “패킷이 유실된 것 같네?” “네트워크가 혼잡한가 보다.” “그럼 보내는 속도를 줄이자.”

혼잡 제어는 네트워크가 감당할 수 있는 만큼만 보내도록 조절하는 것이다.

흐름 제어와 혼잡 제어는 비슷해 보이지만 기준이 다르다.

흐름 제어는 받는 쪽을 보호한다. 혼잡 제어는 네트워크를 보호한다.

여기서 중요한 건 TCP가 자기 마음대로 최대 속도로 보내지 않는다는 점이다. 상대방의 처리 능력과 네트워크 상황을 보면서 전송량을 조절한다.

슬라이딩 윈도우: 하나 보내고 하나 기다리면 너무 느리다

만약 TCP가 데이터를 하나 보내고, ACK가 올 때까지 가만히 기다린다면 어떻게 될까?

신뢰성은 있을 수 있지만 너무 느리다. 특히 거리가 먼 서버와 통신할 때는 ACK가 돌아오는 시간만큼 계속 기다려야 한다.

그래서 TCP는 여러 데이터를 연속으로 보낼 수 있게 한다. 이때 사용하는 방식이 슬라이딩 윈도우다.

슬라이딩 윈도우는 말 그대로 “보낼 수 있는 데이터의 범위”를 창문처럼 정해두는 방식이다.

예를 들어 현재 1번부터 5번까지 보낼 수 있다고 해보자. 보내는 쪽은 ACK를 기다리지 않고 1, 2, 3, 4, 5번 데이터를 연속으로 보낼 수 있다.

이후 받는 쪽에서 “1번 잘 받았고 다음은 2번부터 필요해”라고 알려주면, 창문이 한 칸 옆으로 이동한다. 그러면 이제 6번 데이터를 추가로 보낼 수 있다.

이렇게 윈도우가 옆으로 밀리듯 이동하기 때문에 슬라이딩 윈도우라고 부른다.

이 방식 덕분에 TCP는 매번 하나씩 멈춰서 확인하지 않고도, 여러 데이터를 효율적으로 보내면서 신뢰성을 유지할 수 있다.

TCP의 신뢰성은 여러 장치가 함께 만든다

TCP의 신뢰성은 하나의 기능으로 만들어지는 것이 아니다.

순서 번호는 데이터의 순서를 맞추기 위해 필요하다. ACK는 데이터가 잘 도착했는지 확인하기 위해 필요하다. 재전송은 유실된 데이터를 다시 보내기 위해 필요하다. 오류 제어는 잘못된 데이터를 걸러내기 위해 필요하다. 흐름 제어는 받는 쪽이 감당 가능한 만큼 보내기 위해 필요하다. 혼잡 제어는 네트워크가 감당 가능한 만큼 보내기 위해 필요하다. 슬라이딩 윈도우는 효율적으로 여러 데이터를 보내기 위해 필요하다.

결국 TCP는 이런 식으로 움직인다고 볼 수 있다.

“이 데이터는 몇 번째 데이터인가?” “상대가 여기까지 받았다고 했는가?” “ACK가 안 왔으면 다시 보내야 하는가?” “받는 쪽이 더 받을 수 있는가?” “네트워크가 지금 버틸 수 있는가?” “얼마나 한 번에 보내도 되는가?”

TCP는 계속 이런 판단을 하면서 데이터를 보낸다.

그래서 TCP는 UDP보다 단순히 “느리다”라고만 볼 수는 없다. TCP는 더 많은 확인과 조절을 하면서 안정적인 전송을 목표로 한다.

웹 페이지를 불러오거나, 파일을 다운로드하거나, 로그인 요청을 보내는 상황에서는 데이터가 빠지는 것보다 정확히 도착하는 것이 더 중요하다. 이런 상황에서 TCP의 신뢰성은 꽤 큰 의미를 가진다.

결국 TCP는 네트워크 위에서 데이터를 보내는 동안 계속 확인한다. 보냈는지, 도착했는지, 순서가 맞는지, 다시 보내야 하는지, 너무 많이 보내고 있지는 않은지.

이런 과정을 통해 TCP는 불안정할 수 있는 네트워크 위에서 최대한 안정적인 통신을 만들어낸다.

여기서 말하는 연결은 물리적으로 선을 새로 꽂는다는 뜻은 아니다. 클라이언트와 서버가 서로 통신할 준비가 되었는지 확인하고, 데이터를 주고받을 상태를 맞추는 과정에 가깝다.

UDP는 일단 데이터를 던져놓고 시작하는 느낌이라면, TCP는 먼저 상대에게 말을 건다.

“너 받을 준비 됐어?” “응, 나 준비됐고 너도 준비됐지?” “응, 그럼 이제 보내자.”

이렇게 서로 확인한 뒤에야 본격적인 데이터 전송이 시작된다.

TCP는 왜 연결을 먼저 만들까

TCP는 신뢰성을 중요하게 생각하는 전송 방식이다.

데이터가 중간에 사라질 수도 있고, 순서가 뒤섞일 수도 있고, 상대가 아직 받을 준비가 안 됐을 수도 있다. 그래서 TCP는 데이터를 보내기 전에 최소한의 약속을 먼저 맞춘다.

비유하자면 전화를 거는 상황과 비슷하다.

내가 상대에게 전화를 건다. 상대가 받는다. 서로 목소리가 들리는지 확인한다. 그제야 본격적인 대화를 시작한다.

TCP 연결도 비슷하다. 데이터를 보내기 전에 양쪽이 서로의 존재와 준비 상태를 확인한다.

이 과정을 3-way handshake라고 한다.

3-way handshake

3-way handshake는 TCP 연결을 시작하기 위한 3단계 확인 과정이다.

이름 그대로 세 번의 메시지가 오간다.

첫 번째, 클라이언트가 서버에게 SYN을 보낸다.

SYN은 “연결을 시작하고 싶다”는 의미다.

클라이언트 입장에서는 이런 느낌이다.

“서버야, 나 너랑 TCP 연결하고 싶어.”

두 번째, 서버는 SYN/ACK를 보낸다.

SYN/ACK는 두 가지 의미를 함께 담고 있다.

“네 요청을 받았어.” “나도 연결할 준비가 됐어.”

여기서 ACK는 확인 응답이다. 상대가 보낸 메시지를 잘 받았다고 알려주는 표시다.

세 번째, 클라이언트가 다시 ACK를 보낸다.

“나도 네 응답을 잘 받았어. 이제 연결하자.”

이 세 단계가 끝나면 TCP 연결이 수립된다.

정리하면 흐름은 이렇게 볼 수 있다.

클라이언트 → 서버 : SYN
클라이언트 ← 서버 : SYN/ACK
클라이언트 → 서버 : ACK

여기서 중요한 건, TCP 연결은 한쪽이 일방적으로 “연결됐다”고 선언하는 구조가 아니라는 점이다. 클라이언트와 서버가 서로 메시지를 주고받으면서 양쪽 모두 준비됐다는 사실을 확인한다.

장비가 판단하듯이 보면

클라이언트가 서버에 접속하려고 한다.

예를 들어 브라우저가 웹 서버의 443번 포트에 TCP 연결을 맺으려고 한다고 생각해보자.

클라이언트는 먼저 SYN을 보낸다.

“나는 이 서버의 443번 포트와 연결하고 싶다.”

서버는 이 요청을 받는다. 그리고 자신이 해당 포트에서 요청을 받을 수 있는 상태라면 SYN/ACK를 돌려준다.

“요청 받았다. 나도 연결 가능하다.”

클라이언트는 마지막으로 ACK를 보낸다.

“확인했다. 이제 데이터를 보내겠다.”

이후에야 HTTP 요청 같은 실제 애플리케이션 데이터가 TCP 연결 위에서 오갈 수 있다.

즉, 우리가 브라우저에서 웹사이트에 접속할 때 바로 HTTP 요청부터 날아가는 것이 아니다. 그 전에 TCP 연결을 위한 준비 과정이 먼저 있다.

TCP 상태를 흐름으로 이해하기

TCP에는 여러 상태가 있다.

CLOSED, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED 같은 상태들이 나오는데, 처음 보면 외울 게 많아 보인다. 하지만 지금 단계에서는 상태 이름을 전부 암기하기보다 연결의 흐름을 이해하는 게 더 중요하다.

서버는 보통 연결 요청을 기다리는 상태에 있다.

이 상태를 LISTEN이라고 볼 수 있다.

클라이언트가 SYN을 보내면 클라이언트는 연결 요청을 보낸 상태가 된다. 서버는 SYN을 받고 SYN/ACK를 보낸 상태가 된다. 마지막 ACK까지 오가면 양쪽은 ESTABLISHED 상태가 된다.

ESTABLISHED는 TCP 연결이 실제로 맺어진 상태다.

이제 이 연결을 통해 데이터를 주고받을 수 있다.

흐름으로 보면 이렇게 이해할 수 있다.

서버: 연결 요청을 기다림
클라이언트: SYN 전송
서버: SYN/ACK 응답
클라이언트: ACK 응답
양쪽: 연결 성립

여기서 중요한 건 TCP 상태가 단순한 이름표가 아니라는 점이다. 각 상태는 “지금 연결 과정에서 어디까지 왔는지”를 나타낸다.

연결이 끝날 때도 절차가 있다

TCP는 연결을 시작할 때만 절차가 있는 것이 아니다. 연결을 끝낼 때도 절차가 있다.

데이터를 다 주고받았다고 해서 그냥 아무 말 없이 끊어버리면 문제가 생길 수 있다.

상대는 아직 보낼 데이터가 남아 있을 수도 있고, 마지막 데이터가 도착하지 않았을 수도 있다. 그래서 TCP는 연결 종료도 서로 확인하면서 진행한다.

대표적으로 FIN과 ACK가 사용된다.

FIN은 “이제 보낼 데이터가 없다. 연결을 종료하고 싶다”는 의미다. ACK는 “그 종료 요청을 확인했다”는 의미다.

보통 한쪽이 FIN을 보내면, 상대가 ACK로 확인한다. 그리고 상대도 더 보낼 데이터가 없으면 FIN을 보낸다. 처음 FIN을 보냈던 쪽은 다시 ACK를 보내면서 종료를 마무리한다.

흐름만 보면 이런 느낌이다.

A → B : FIN
A ← B : ACK
A ← B : FIN
A → B : ACK

연결을 시작할 때 서로 준비됐는지 확인했다면, 연결을 끝낼 때는 서로 더 이상 보낼 데이터가 없는지 확인하는 셈이다.

왜 종료는 더 복잡해 보일까

연결 시작은 3단계인데, 종료는 보통 4단계처럼 보인다.

이유는 TCP 연결이 양방향 통신이기 때문이다.

A가 B에게 “나는 이제 보낼 데이터가 없어”라고 말해도, B는 아직 A에게 보낼 데이터가 남아 있을 수 있다.

그래서 한쪽 방향의 종료와 반대쪽 방향의 종료를 따로 확인해야 한다.

전화를 끊는 상황으로 비유하면 이렇다.

내가 “나는 할 말 다 했어”라고 말해도, 상대가 “잠깐, 나는 아직 할 말이 있어”라고 할 수 있다.

상대도 할 말을 다 끝낸 뒤에야 둘 다 통화를 종료할 수 있다.

TCP 연결 종료도 비슷하다. 각 방향의 데이터 전송이 끝났는지 확인하면서 연결을 닫는다.

개발할 때 이 흐름이 왜 중요할까

웹 개발을 하다 보면 “서버는 떠 있는데 접속이 안 된다”는 상황을 만날 수 있다.

이때 단순히 서버 프로세스만 볼 것이 아니라, TCP 연결이 실제로 맺어지는지도 생각해야 한다.

클라이언트가 SYN을 보냈는데 서버가 SYN/ACK를 주지 않는다면, 중간에 방화벽이 막고 있을 수도 있다. 서버 포트가 열려 있지 않을 수도 있다. 로드밸런서나 보안 그룹 설정이 잘못됐을 수도 있다.

반대로 TCP 연결은 잘 맺어졌는데 HTTP 응답이 이상하다면, 문제는 그보다 위쪽인 애플리케이션 계층에 있을 가능성이 커진다.

여기서 중요한 건 TCP 연결 수립은 웹 요청이 실제로 오가기 전의 관문이라는 점이다.

브라우저에서 서버로 요청을 보낸다고 할 때, 그 아래에서는 먼저 TCP 연결이 만들어진다. 그리고 그 연결 위에서 HTTP 요청과 응답이 오간다.

흐름으로 다시 보기

TCP 연결은 시작부터 종료까지 하나의 대화처럼 볼 수 있다.

처음에는 연결하고 싶은 쪽이 SYN을 보낸다. 상대는 SYN/ACK로 준비됐다고 답한다. 다시 ACK가 오가면 연결이 성립된다.

연결이 성립된 뒤에는 데이터를 주고받는다.

데이터 전송이 끝나면 FIN과 ACK를 주고받으며 연결을 종료한다.

TCP 상태는 이 과정에서 현재 연결이 어디에 있는지를 나타내는 표시다. 처음부터 상태 이름을 전부 외우려고 하기보다, 연결이 생기고 유지되고 끝나는 흐름을 먼저 잡는 게 더 이해하기 좋다.

TCP는 그냥 데이터를 보내는 방식이 아니다. 보내기 전에 확인하고, 주고받는 동안 관리하고, 끝낼 때도 확인하는 방식이다.

그래서 TCP는 UDP보다 느리고 복잡하지만, 그만큼 안정적인 통신을 만들 수 있다.

그런데 포트만 안다고 통신이 끝나는 것은 아니다.

데이터를 보낼 때 이런 문제들이 남는다.

“상대방이 받을 준비가 되었는가?” “보낸 데이터가 중간에 사라지지는 않았는가?” “데이터가 순서대로 도착했는가?” “굳이 이런 것까지 확인하지 않고 빠르게 보내도 되는가?”

이 질문에 대해 서로 다른 방식으로 대답하는 대표적인 프로토콜이 TCP와 UDP다.

TCP는 신뢰성을 중시한다

TCP는 데이터를 보낼 때 정확하게 도착하는 것을 중요하게 생각하는 전송 방식이다.

비유하면 택배를 보낼 때 등기 배송을 사용하는 느낌에 가깝다. 보내기 전에 상대가 받을 수 있는지 확인하고, 보낸 뒤에도 잘 도착했는지 확인한다. 중간에 문제가 생기면 다시 보내는 방식도 사용한다.

TCP는 데이터를 그냥 던지지 않는다.

먼저 통신할 상대와 연결을 만들고, 데이터를 나누어 보내고, 상대가 잘 받았는지 확인한다. 그리고 필요하다면 다시 보낸다.

그래서 TCP는 다음과 같은 특징을 가진다.

• 연결을 수립한 뒤 통신한다.
• 데이터가 도착했는지 확인한다.
• 데이터 순서를 맞추려고 한다.
• 손실된 데이터는 재전송할 수 있다.

여기서 중요한 건 TCP가 “빠르게 보내는 것”보다 믿고 받을 수 있게 보내는 것에 더 집중한다는 점이다.

웹 페이지를 요청하거나, 파일을 다운로드하거나, 로그인 요청을 보내는 상황을 생각해보면 데이터가 조금 빠지는 것은 꽤 큰 문제다. HTML 일부가 빠지거나, 결제 요청 데이터가 중간에 사라지거나, 파일 내용이 틀어지면 안 된다.

이런 상황에서는 속도보다 정확성이 중요하기 때문에 TCP가 잘 어울린다.

UDP는 단순하고 빠르다

UDP는 TCP보다 훨씬 단순하다. UDP는 연결을 먼저 만들지 않고, 데이터를 바로 보낸다.

비유하면 편지를 우편함에 넣고 끝내는 느낌이다. 상대가 지금 받을 준비가 되었는지, 중간에 사라지지는 않았는지, 순서대로 도착했는지까지 직접 챙기지 않는다.

그래서 UDP는 다음과 같은 특징을 가진다.

• 연결 수립 과정이 없다.
• 데이터 도착 여부를 보장하지 않는다.
• 순서 보장도 기본적으로 제공하지 않는다.
• 구조가 단순해서 빠르게 보낼 수 있다.

처음에는 “그럼 UDP는 불안정한 거 아닌가?”라는 생각이 들 수 있다. 맞다. TCP에 비해 신뢰성은 낮다.

하지만 모든 통신에서 완벽한 신뢰성이 필요한 것은 아니다.

예를 들어 실시간 음성 통화나 영상 스트리밍을 생각해보면, 중간에 아주 짧은 데이터가 하나 빠졌다고 해서 그 데이터를 다시 받아오는 것이 항상 좋은 선택은 아니다. 이미 지나간 음성 조각을 뒤늦게 다시 받는 것보다, 조금 끊기더라도 현재 데이터를 계속 받는 편이 더 자연스럽다.

온라인 게임도 비슷하다. 캐릭터의 위치 정보가 아주 빠르게 계속 바뀌는 상황에서, 오래된 위치 정보를 뒤늦게 정확히 받는 것이 오히려 의미가 없을 수 있다.

여기서 중요한 건 UDP가 “대충 보내는 프로토콜”이라기보다, 연결과 확인 과정을 최소화해서 빠르게 보내는 방식이라는 점이다.

TCP는 연결형, UDP는 비연결형

TCP를 설명할 때 자주 나오는 말이 연결형 통신이다. 연결형이라는 말은 데이터를 보내기 전에 먼저 통신할 준비 과정을 거친다는 뜻이다.

반대로 UDP는 비연결형 통신이다. 상대와 미리 연결을 맺는 과정 없이 데이터를 보낸다.

이 차이는 실제 통신 방식에서 꽤 크게 느껴진다.

TCP는 이렇게 생각할 수 있다.

“너 받을 준비 됐어?” “응, 받을 수 있어.” “그럼 이제 보낼게.” “받았어.” “혹시 못 받은 부분 있으면 다시 보낼게.”

UDP는 훨씬 짧다.

“보낸다.”

이 차이 때문에 TCP는 더 꼼꼼하지만 상대적으로 무겁고, UDP는 덜 꼼꼼하지만 가볍다.

TCP 세그먼트와 UDP 데이터그램

전송 계층에서도 데이터를 부르는 이름이 있다.

TCP에서 사용하는 데이터 단위를 TCP 세그먼트라고 한다. UDP에서 사용하는 데이터 단위를 UDP 데이터그램이라고 한다.

이 이름 자체를 외우는 것보다 중요한 건, 각각의 데이터 안에 어떤 성격의 정보가 담기느냐다.

TCP 세그먼트에는 신뢰성 있는 통신을 위한 정보들이 들어간다. 예를 들어 데이터 순서를 맞추기 위한 번호, 확인 응답과 관련된 정보, 제어 정보 등이 포함될 수 있다.

UDP 데이터그램은 상대적으로 단순하다. 출발지 포트, 목적지 포트, 길이, 오류 확인을 위한 정보 정도를 담고 데이터를 보낸다.

즉 TCP 세그먼트는 “이 데이터를 안정적으로 주고받기 위한 관리 정보”가 더 많이 붙는 느낌이고, UDP 데이터그램은 “최소한의 정보만 붙여서 빠르게 보내는” 느낌에 가깝다.

장비는 무엇을 보고 판단할까

전송 계층 관점에서 데이터를 받는 쪽을 시뮬레이션해보면 이런 흐름이다.

먼저 IP 계층을 통해 패킷이 내 컴퓨터까지 도착한다. 그러면 이제 컴퓨터는 생각한다.

“이 데이터는 내 컴퓨터로 온 건 맞다. 그런데 내 안의 어떤 프로그램에게 넘겨야 하지?”

이때 확인하는 것이 목적지 포트 번호다.

목적지 포트가 80이면 웹 서버 프로세스일 수 있고, 443이면 HTTPS 요청을 처리하는 프로세스일 수 있다. 포트 번호를 보고 적절한 애플리케이션으로 데이터를 넘긴다.

그런데 여기서 TCP냐 UDP냐에 따라 처리 방식이 달라진다.

TCP라면 연결 상태를 확인하고, 순서가 맞는지 보고, 필요한 경우 응답을 보낸다. UDP라면 연결 상태를 따로 관리하지 않고, 도착한 데이터그램을 해당 포트를 사용하는 애플리케이션에 넘긴다.

즉 IP가 “어느 컴퓨터로 갈 것인가”를 판단한다면, 포트는 “그 컴퓨터 안의 어느 프로그램으로 갈 것인가”를 판단한다. 그리고 TCP와 UDP는 “그 데이터를 어떤 방식으로 주고받을 것인가”를 결정한다.

TCP와 UDP는 우열의 관계가 아니다

TCP와 UDP를 보면 TCP가 더 좋아 보일 수 있다. 연결도 하고, 확인도 하고, 재전송도 해주기 때문이다.

하지만 네트워크에서는 항상 “더 많은 기능”이 정답은 아니다. 기능이 많다는 것은 그만큼 처리할 것도 많고, 시간이 더 걸릴 수 있다는 뜻이다.

정확성이 중요한 통신에서는 TCP가 적합하다. 빠른 전달과 실시간성이 중요한 통신에서는 UDP가 더 적합할 수 있다.

웹 요청, 파일 전송, 이메일처럼 데이터가 정확히 도착해야 하는 경우에는 TCP가 잘 어울린다. 음성 통화, 영상 스트리밍, 온라인 게임처럼 실시간성이 중요한 경우에는 UDP가 사용될 수 있다.

여기서 중요한 건 TCP와 UDP를 “좋고 나쁨”으로 나누는 것이 아니라, 어떤 통신에 어떤 성격이 더 필요한가로 바라보는 것이다.

TCP는 꼼꼼한 전달 방식이다. UDP는 가볍고 빠른 전달 방식이다.

전송 계층은 결국 이 선택지를 제공한다. 데이터를 안정적으로 주고받을 것인지, 아니면 조금 단순하더라도 빠르게 주고받을 것인지.

이 차이를 이해하면 네트워크 통신을 볼 때 단순히 “데이터가 간다”가 아니라, 그 데이터가 어떤 방식으로, 어떤 책임 범위 안에서 이동하는지 조금 더 선명하게 보인다.

여기서 호스트는 쉽게 말해 네트워크에 연결된 컴퓨터, 서버, 스마트폰 같은 장비라고 볼 수 있다. 그런데 실제 통신은 호스트까지만 도착한다고 끝나는 게 아니다.

내 컴퓨터가 어떤 서버에 요청을 보낸다고 해보자. IP 주소를 이용하면 “어느 서버로 갈지”는 정할 수 있다. 하지만 그 서버 안에는 여러 프로그램이 동시에 실행되고 있을 수 있다.

웹 서버도 떠 있을 수 있고, 데이터베이스도 있을 수 있고, SSH 접속을 받는 프로그램도 있을 수 있다. 그러면 도착한 데이터는 그중 어떤 프로그램에게 전달되어야 할까?

이 문제를 해결하기 위해 등장하는 개념이 포트다.

IP 주소의 한계

IP 주소는 목적지 호스트를 찾는 데 사용된다.

예를 들어 택배로 비유하면 IP 주소는 건물 주소에 가깝다.

서울시 어딘가에 있는 특정 건물까지 택배를 보내는 것. 여기까지가 IP 주소의 역할이라고 볼 수 있다.

그런데 건물에 도착했다고 해서 택배 전달이 끝나는 것은 아니다. 그 건물 안에는 여러 사무실이 있을 수 있다.

1층 카페로 가야 할 수도 있고, 3층 회사 사무실로 가야 할 수도 있고, 5층 관리실로 가야 할 수도 있다.

IP 주소만 있으면 “건물”까지는 갈 수 있지만, “건물 안의 어느 사무실”로 가야 하는지는 알 수 없다.

네트워크에서도 비슷하다.

IP 주소는 서버라는 호스트까지 데이터를 보내는 데 필요하다. 하지만 서버 안에서 실행 중인 어떤 애플리케이션이 이 데이터를 받아야 하는지는 IP 주소만으로 구분할 수 없다.

여기서 중요한 건, 네트워크 통신의 최종 도착지는 단순히 컴퓨터가 아니라 그 안에서 실행 중인 프로그램이라는 점이다.

포트란 무엇인가

포트는 호스트 내부에서 애플리케이션이나 프로세스를 구분하기 위한 번호다.

IP 주소가 “어느 컴퓨터로 갈 것인가”를 나타낸다면, 포트는 “그 컴퓨터 안의 어떤 프로그램으로 갈 것인가”를 나타낸다.

다시 택배 비유로 보면 이렇다.

IP 주소: 건물 주소 포트 번호: 건물 안의 사무실 번호

데이터가 서버까지 도착했을 때 운영체제는 포트 번호를 확인한다.

“이 데이터는 80번 포트로 왔네?” “그럼 웹 서버 프로세스에게 전달해야겠다.”

“이 데이터는 22번 포트로 왔네?” “그럼 SSH 서버 프로세스에게 전달해야겠다.”

이런 식으로 포트 번호를 보고 데이터를 넘겨줄 프로그램을 결정한다.

즉, 포트는 네트워크 데이터를 실제 애플리케이션까지 이어주는 마지막 구분자라고 볼 수 있다.

전송 계층은 왜 필요할까

포트는 전송 계층에서 다루는 중요한 개념이다.

이전까지 IP를 보면서 네트워크 계층의 역할을 살펴봤다. 네트워크 계층은 목적지 호스트까지 데이터를 보내는 데 관심이 있다.

하지만 호스트에 도착한 데이터가 어떤 프로세스로 가야 하는지는 또 다른 문제다. 이 역할을 맡는 계층이 전송 계층이다.

전송 계층은 호스트와 호스트 사이의 통신을 넘어서, 실제로는 프로세스와 프로세스 사이의 통신을 가능하게 해준다.

브라우저가 웹 서버에 요청을 보낸다고 할 때, 겉으로 보면 “내 컴퓨터가 서버에 요청한다”라고 말한다.

하지만 조금 더 정확히 보면 이렇다.

내 컴퓨터의 브라우저 프로세스가 서버의 웹 서버 프로세스에게 데이터를 보내는 것이다.

이때 필요한 정보가 IP 주소와 포트 번호다.

IP 주소로 서버를 찾고, 포트 번호로 서버 안의 웹 서버 프로그램을 찾는다.

웹 서버는 보통 80번과 443번 포트를 사용한다

웹에서 자주 만나는 포트 번호가 있다.

HTTP는 보통 80번 포트를 사용한다. HTTPS는 보통 443번 포트를 사용한다.

그래서 브라우저에서 http://example.com에 접속하면 기본적으로 80번 포트로 요청을 보낸다. https://example.com에 접속하면 기본적으로 443번 포트로 요청을 보낸다.

물론 URL에 포트 번호를 직접 적을 수도 있다.

예를 들어 이런 식이다.

http://localhost:3000

여기서 localhost는 내 컴퓨터를 의미하고, 3000은 포트 번호다.

개발할 때 React, Vite, Express, Spring 같은 서버를 실행하면 3000, 5173, 8080 같은 포트를 자주 보게 된다.

이 말은 결국 내 컴퓨터 안에서 특정 개발 서버 프로세스가 해당 포트 번호로 요청을 기다리고 있다는 뜻이다.

예를 들어 localhost:3000에 접속한다는 것은 “내 컴퓨터의 3000번 포트에서 기다리고 있는 프로그램에게 요청을 보내겠다”는 의미에 가깝다.

포트 번호는 아무렇게나 쓰는 걸까

포트 번호는 0번부터 65535번까지 있다.

이 포트 번호들은 크게 몇 가지 범위로 나누어 볼 수 있다.

Well-known Port는 잘 알려진 포트다. 보통 0번부터 1023번까지를 말한다.

대표적으로 HTTP는 80번, HTTPS는 443번, SSH는 22번 포트를 사용한다. 이런 포트들은 많은 시스템에서 관례적으로 정해진 용도로 사용된다.

Registered Port는 특정 애플리케이션이나 서비스에서 사용하기 위해 등록된 포트 범위다. 보통 1024번부터 49151번까지다.

개발하면서 자주 보는 3306번 MySQL, 5432번 PostgreSQL, 6379번 Redis 같은 포트도 이 범위에 들어간다.

Dynamic Port 또는 Ephemeral Port는 임시로 사용되는 포트다. 보통 49152번부터 65535번까지다.

이 포트는 클라이언트 쪽에서 일시적으로 사용되는 경우가 많다.

예를 들어 내 브라우저가 웹 서버의 443번 포트로 접속한다고 해보자. 서버의 목적지 포트는 443번이다.

그런데 서버가 응답을 다시 보내려면 내 컴퓨터의 어느 포트로 보내야 할지도 알아야 한다. 이때 내 컴퓨터는 임시 포트를 하나 열어서 사용한다.

즉, 통신에는 보통 출발지 포트와 목적지 포트가 함께 들어간다.

서버 포트와 클라이언트 포트

처음에는 포트라고 하면 서버 포트만 떠올리기 쉽다.

“웹 서버는 80번 포트를 연다.” “Spring 서버는 8080번 포트에서 실행된다.” “DB는 3306번 포트를 사용한다.”

이런 식으로 많이 보기 때문이다.

하지만 실제 통신에서는 클라이언트도 포트를 사용한다.

예를 들어 내 브라우저가 웹 서버에 접속한다고 해보자.

내 컴퓨터는 임시 포트 하나를 사용한다. 서버는 443번 포트에서 HTTPS 요청을 기다리고 있다.

그러면 통신은 대략 이런 모양이 된다.

내 컴퓨터 임시 포트 → 서버 443번 포트

서버가 응답할 때는 반대로 돌아온다.

서버 443번 포트 → 내 컴퓨터 임시 포트

이렇게 해야 내 컴퓨터도 여러 통신을 동시에 구분할 수 있다.

브라우저 탭을 여러 개 열고, 메신저도 켜고, 게임도 실행하고, 백그라운드에서 업데이트도 진행할 수 있는 이유는 각 통신을 포트 정보로 구분할 수 있기 때문이다.

포트가 닫혀 있다는 말

개발이나 배포를 하다 보면 이런 표현을 자주 듣는다.

“포트가 열려 있나요?” “방화벽에서 8080 포트 허용했나요?” “서버는 떠 있는데 접속이 안 돼요.”

여기서 포트가 열려 있다는 말은 보통 해당 포트에서 요청을 받을 프로그램이 실행 중이고, 외부에서 접근할 수 있는 상태라는 뜻이다.

반대로 포트가 닫혀 있다면 몇 가지 가능성이 있다.

해당 포트에서 실행 중인 프로그램이 없을 수 있다. 프로그램은 실행 중이지만 다른 주소에만 바인딩되어 있을 수 있다. 운영체제 방화벽이 막고 있을 수 있다. 클라우드 보안 그룹이나 네트워크 ACL에서 막고 있을 수도 있다.

그래서 “서버가 살아 있다”는 말과 “서비스에 접속할 수 있다”는 말은 다르다.

서버 자체는 켜져 있을 수 있다. IP로 ping도 될 수 있다. 하지만 내가 접속하려는 애플리케이션 포트가 열려 있지 않으면 서비스는 사용할 수 없다.

여기서 중요한 건, 네트워크 문제를 볼 때 IP 도달성과 포트 접근 가능성을 구분해서 봐야 한다는 점이다.

포트를 기준으로 통신을 다시 보면

이제 브라우저에서 웹사이트에 접속하는 흐름을 포트 관점으로 다시 볼 수 있다.

브라우저는 먼저 목적지 서버의 IP 주소를 알아낸다. 그리고 HTTPS라면 목적지 포트를 443번으로 정한다.

그다음 데이터에는 이런 정보가 포함된다.

출발지 IP 출발지 포트 목적지 IP 목적지 포트

목적지 서버에 데이터가 도착하면 운영체제는 목적지 포트를 확인한다.

“443번 포트로 들어온 데이터네.” “그럼 HTTPS 요청을 처리하는 웹 서버 프로세스로 넘기자.”

웹 서버는 요청을 처리한 뒤 응답을 만든다. 그리고 응답은 다시 클라이언트의 IP와 임시 포트를 향해 돌아간다.

이렇게 보면 포트는 단순한 숫자가 아니다. 호스트 안에서 실제 데이터를 받아야 할 프로그램을 찾기 위한 주소 같은 역할을 한다.

IP 주소가 네트워크상의 위치를 찾는 주소라면, 포트는 그 위치 안에서 실행 중인 프로그램을 찾는 번호다.

네트워크 통신은 결국 “어느 컴퓨터로 갈 것인가”와 “그 컴퓨터 안의 어떤 프로그램으로 갈 것인가”를 함께 해결해야 한다.

IP만으로는 첫 번째 질문까지만 답할 수 있다. 두 번째 질문에 답하기 위해 포트가 필요하다.

스위치는 같은 네트워크 안에서 MAC 주소를 보고 프레임을 전달했다.

하지만 우리가 접속하는 서버가 항상 내 집, 내 회사, 내 와이파이 안에 있는 것은 아니다. 대부분의 웹 서버는 내 네트워크 바깥에 있다. 이때 필요한 장비가 라우터다.

라우터는 간단히 말하면 서로 다른 네트워크 사이에서 패킷이 갈 길을 정해주는 장비다.

같은 LAN 안에서는 MAC 주소를 보고 다음 장비를 찾았다면, LAN을 넘어갈 때부터는 IP 주소를 보고 목적지 네트워크를 찾아가야 한다. 라우터는 이 IP 주소를 기준으로 “이 패킷을 어느 방향으로 보내야 하지?”를 판단한다.

비유하자면 스위치가 같은 건물 안에서 방 번호를 보고 사람을 찾아주는 안내 데스크라면, 라우터는 도시와 도시 사이에서 목적지까지 가는 길을 알려주는 내비게이션에 가깝다.

라우터는 감으로 보내지 않는다

라우터가 패킷을 받을 때마다 그냥 대충 가까운 곳으로 보내는 것은 아니다.

라우터 안에는 라우팅 테이블이라는 것이 있다.

라우팅 테이블은 말 그대로 길 목록이다. 어떤 네트워크로 가려면 어느 방향으로 보내야 하는지 적어둔 표라고 보면 된다.

예를 들어 라우터 입장에서는 이런 식으로 생각한다.

목적지 IP: 172.16.10.25

이 IP는 172.16.10.0/24 네트워크에 속하네.
그 네트워크로 가려면 이 인터페이스로 내보내야겠다.
다음 라우터는 10.0.0.2 쪽이네.

여기서 중요한 건 라우터가 최종 목적지까지의 모든 길을 한 번에 다 아는 것이 아니라는 점이다.

라우터는 보통 “다음에 어디로 보낼지”를 판단한다. 즉, 패킷을 목적지까지 직접 데려다주는 게 아니라, 다음 라우터에게 넘겨주는 식으로 길을 이어간다.

마치 택배가 한 번에 우리 집까지 오는 것이 아니라, 여러 물류 허브를 거쳐 이동하는 것과 비슷하다.

라우팅 테이블은 어떻게 생겼을까

라우팅 테이블에는 대략 이런 정보들이 들어간다.

목적지 네트워크        다음 홉          나가는 인터페이스
192.168.1.0/24       직접 연결됨       eth0
10.0.0.0/8           172.16.0.1       eth1
0.0.0.0/0            192.168.1.1      eth0

여기서 목적지 네트워크는 패킷이 가고자 하는 IP 대역이다. 다음 홉은 다음으로 넘겨야 할 라우터의 주소다. 나가는 인터페이스는 어떤 네트워크 포트로 패킷을 내보낼지에 해당한다.

라우터는 패킷의 목적지 IP를 보고 라우팅 테이블에서 가장 알맞은 항목을 찾는다.

이때 중요한 기준은 가장 구체적인 경로를 우선한다는 것이다.

예를 들어 목적지 IP가 192.168.1.50이라면 192.168.0.0/16보다 192.168.1.0/24가 더 구체적인 경로다. 그래서 라우터는 더 좁고 정확한 경로를 선택한다.

기본 게이트웨이는 첫 번째 라우터다

내 컴퓨터도 라우터처럼 모든 네트워크의 경로를 알고 있지는 않다.

내 컴퓨터가 아는 것은 보통 이것 정도다.

내 IP 주소
서브넷 마스크
기본 게이트웨이
DNS 서버 주소

여기서 기본 게이트웨이가 중요하다.

기본 게이트웨이는 내 컴퓨터 입장에서 다른 네트워크로 나가기 위해 처음으로 패킷을 보내는 라우터다.

예를 들어 내 컴퓨터가 192.168.0.10이고, 접속하려는 서버가 142.250.207.14라고 해보자. 이 서버는 내 로컬 네트워크에 없다.

그러면 내 컴퓨터는 이렇게 판단한다.

목적지 IP가 내 네트워크에 있나?
아니네.

그럼 내가 직접 보낼 수 없겠네.
기본 게이트웨이에게 보내자.

그래서 패킷은 먼저 공유기나 사내 라우터로 간다. 우리가 집에서 쓰는 공유기도 이 기본 게이트웨이 역할을 한다.

여기서 헷갈리기 쉬운 부분이 있다.

내 컴퓨터가 외부 서버로 패킷을 보낼 때, 목적지 IP는 외부 서버 IP다. 하지만 같은 LAN 안에서 실제로 프레임을 전달할 때 필요한 목적지 MAC 주소는 기본 게이트웨이의 MAC 주소다.

즉, 이런 식이다.

IP 목적지: 외부 서버
MAC 목적지: 기본 게이트웨이

지난번 ARP에서 봤던 “IP는 최종 목적지 관점, MAC은 다음 홉 관점”이 여기서 다시 이어진다.

패킷이 라우터를 만났을 때

패킷이 라우터에 도착하면 라우터는 대략 이런 순서로 판단한다.

1. 패킷의 목적지 IP를 확인한다.
2. 라우팅 테이블을 조회한다.
3. 가장 적절한 경로를 찾는다.
4. 다음 홉을 결정한다.
5. 다음 네트워크로 패킷을 내보낸다.

조금 더 시뮬레이션하듯 보면 이렇다.

라우터: 목적지 IP가 203.0.113.10이네.

라우터: 내 라우팅 테이블에 203.0.113.0/24로 가는 경로가 있나?
라우터: 있네. 다음 홉은 10.1.1.2 쪽이네.

라우터: 그럼 이 패킷을 해당 인터페이스로 내보내자.

만약 라우팅 테이블에 정확한 경로가 없다면 어떻게 될까?

그때는 기본 경로를 사용할 수 있다. 기본 경로는 보통 0.0.0.0/0으로 표현한다.

이것은 “위에 해당하는 경로가 없으면 일단 이쪽으로 보내라”는 의미다. 내 컴퓨터의 기본 게이트웨이와 비슷한 역할을 라우터끼리도 할 수 있는 것이다.

정적 라우팅은 사람이 직접 길을 적어주는 방식이다

라우팅 테이블을 만드는 방법 중 하나는 정적 라우팅이다.

정적 라우팅은 관리자가 직접 경로를 설정하는 방식이다.

10.10.0.0/16 네트워크로 가려면 192.168.1.254로 보내라.

이렇게 사람이 직접 라우터에 알려주는 것이다.

장점은 단순하고 예측하기 쉽다는 점이다. 작은 네트워크에서는 오히려 이런 방식이 깔끔할 수 있다.

하지만 네트워크가 커지면 문제가 생긴다.

라우터가 많아지고, 네트워크 경로가 복잡해지고, 중간 장비에 장애가 나면 사람이 일일이 경로를 수정해야 한다. 네트워크 구조가 자주 바뀌는 환경에서는 관리 부담이 커진다.

즉, 정적 라우팅은 작은 지도에 길 몇 개 직접 표시해두는 느낌이다. 길이 적을 때는 편하지만, 도시 전체 도로망을 손으로 계속 수정해야 한다면 꽤 힘들어진다.

동적 라우팅은 라우터들이 서로 길 정보를 나누는 방식이다

동적 라우팅은 라우터들이 서로 경로 정보를 주고받으면서 라우팅 테이블을 갱신하는 방식이다.

관리자가 모든 경로를 직접 입력하지 않아도, 라우터들이 서로 대화하면서 이런 정보를 공유한다.

라우터 A: 나는 10.1.0.0/16 네트워크에 갈 수 있어.
라우터 B: 나는 172.16.0.0/16 네트워크에 연결되어 있어.
라우터 C: 그러면 172.16.0.0/16으로 가려면 B 쪽으로 보내면 되겠네.

이런 식으로 라우터들이 네트워크 정보를 교환하면, 장애가 발생했을 때 다른 경로를 찾는 것도 가능해진다.

물론 자동이라고 해서 무조건 단순한 것은 아니다. 동적 라우팅은 라우팅 프로토콜의 동작 방식, 우선순위, 비용 계산 방식 등을 이해해야 한다. 하지만 지금은 깊게 들어가기보다 “라우터들이 서로 길 정보를 공유하는 방식” 정도로 잡아두면 충분하다.

RIP, OSPF, BGP는 무엇이 다를까

동적 라우팅에도 여러 방식이 있다. 대표적으로 RIP, OSPF, BGP가 있다.

RIP는 비교적 단순한 라우팅 프로토콜이다. 목적지까지 몇 개의 라우터를 거치는지를 기준으로 경로를 판단한다. 이때 거치는 라우터 수를 홉 수라고 한다. 단순하지만 큰 네트워크에는 한계가 있다.

OSPF는 네트워크의 상태 정보를 바탕으로 더 효율적인 경로를 계산한다. 단순히 몇 번 거치는지만 보는 것이 아니라, 링크 상태를 기반으로 경로를 선택한다. 회사나 기관 내부 네트워크처럼 하나의 조직 안에서 많이 사용되는 방식으로 이해하면 된다.

BGP는 인터넷 규모에서 사용되는 라우팅 프로토콜이다. 인터넷은 하나의 거대한 네트워크가 아니라, 수많은 독립적인 네트워크들이 연결된 구조다. BGP는 이런 큰 네트워크들 사이에서 경로 정보를 주고받는 데 사용된다.

간단히 정리하면 이렇다.

RIP  : 단순하게 홉 수를 기준으로 길을 고른다.
OSPF : 네트워크 상태를 보고 더 적절한 길을 계산한다.
BGP  : 인터넷을 이루는 큰 네트워크들 사이의 길을 조율한다.

여기서 중요한 건 지금 당장 RIP, OSPF, BGP의 세부 동작을 외우는 것이 아니다.

라우터가 혼자 모든 길을 알고 있는 것이 아니라, 필요에 따라 사람이 직접 경로를 넣거나, 라우터들끼리 정보를 주고받으며 길을 만든다는 흐름을 이해하는 것이다.

라우터를 지나도 목적지 IP는 바뀌지 않는다

라우터를 공부할 때 헷갈렸던 부분은 이것이다.

패킷이 여러 라우터를 지나가면 목적지 IP가 계속 바뀌는 걸까?

기본적으로 목적지 IP는 최종 목적지를 가리킨다. 그래서 라우터를 여러 개 지나도 목적지 IP는 계속 서버 IP를 가리킨다.

대신 매 구간마다 다음 장비에게 전달하기 위한 MAC 주소는 바뀔 수 있다.

예를 들어 내 컴퓨터에서 외부 서버로 간다고 하면 흐름은 이런 식이다.

내 컴퓨터
→ 기본 게이트웨이
→ ISP 라우터
→ 여러 중간 라우터
→ 서버 쪽 네트워크
→ 서버

IP 패킷의 목적지는 계속 서버다. 하지만 이 패킷을 감싸는 이더넷 프레임은 각 구간마다 새로 만들어질 수 있다.

즉, 라우터는 패킷을 다음 네트워크로 넘길 때 다음 홉에 맞는 데이터 링크 계층 정보를 다시 사용한다.

이 부분이 계층 구조와 연결된다.

IP는 전체 여정의 목적지를 본다. MAC은 지금 이 구간에서 다음에 전달할 장비를 본다. 라우터는 이 둘 사이를 이어주는 장비처럼 동작한다.

웹 요청도 결국 라우터를 지나간다

브라우저에서 어떤 웹사이트에 접속할 때도 이 흐름은 그대로 적용된다.

우리는 주소창에 도메인을 입력하지만, 실제 통신에서는 IP 주소를 찾아야 한다. 그리고 그 IP가 내 네트워크 밖에 있다면 패킷은 기본 게이트웨이로 간다.

기본 게이트웨이는 라우팅 테이블을 보고 다음 라우터로 보낸다. 다음 라우터도 자기 라우팅 테이블을 보고 또 다음으로 보낸다. 이 과정을 반복하면서 패킷은 목적지 서버가 있는 네트워크까지 이동한다.

라우터 입장에서 생각하면 계속 같은 질문을 반복하는 셈이다.

이 목적지 IP로 가려면 어디로 보내야 하지?

라우터는 이 질문에 대한 답을 라우팅 테이블에서 찾는다.

그래서 네트워크 장애를 볼 때도 라우팅은 중요하다.

서버는 살아 있는데 접속이 안 된다면, 중간 어딘가에서 경로가 잘못되었을 수도 있다. 내 컴퓨터의 기본 게이트웨이 설정이 틀렸을 수도 있고, 라우터의 라우팅 테이블에 잘못된 경로가 있을 수도 있다. 또는 방화벽이나 보안 장비가 중간에서 막고 있을 수도 있다.

아직 장애 분석을 깊게 들어가지는 않지만, “패킷이 목적지까지 가려면 중간 라우터들이 계속 다음 길을 선택해야 한다”는 감각은 중요하다.

라우터는 길을 선택하는 장비다

라우터는 서로 다른 네트워크를 연결한다. 그리고 라우팅 테이블을 보고 패킷을 다음 어디로 보낼지 결정한다.

내 컴퓨터 입장에서 기본 게이트웨이는 외부 네트워크로 나가기 위한 첫 번째 라우터다. 라우터는 목적지 IP를 보고 다음 홉을 고른다. 라우팅 테이블은 사람이 직접 설정할 수도 있고, 라우터들이 동적 라우팅 프로토콜을 통해 서로 정보를 주고받으며 만들 수도 있다.

결국 라우팅을 이해한다는 것은 패킷이 “어디로 가야 하는지”를 네트워크 장비가 어떻게 판단하는지 이해하는 것이다.

스위치가 같은 LAN 안에서 MAC 주소를 보고 움직였다면, 라우터는 네트워크와 네트워크 사이에서 IP 주소를 보고 길을 고른다.

이 정보들이 있어야 내 컴퓨터는 이런 판단을 할 수 있다.

“내 IP는 무엇인가?” “상대방이 나와 같은 네트워크에 있는가?” “다른 네트워크라면 어디로 보내야 하는가?” “도메인 이름은 어떤 IP 주소로 바꿔야 하는가?”

그런데 여기서 한 가지 문제가 남는다.

IP 주소를 알아냈다고 해서 바로 데이터를 보낼 수 있을까?

결론부터 말하면, 같은 LAN 안에서 실제로 프레임을 보내려면 MAC 주소가 필요하다.

IP 주소는 목적지를 찾기 위한 주소이고, MAC 주소는 지금 이 네트워크 안에서 실제로 프레임을 전달하기 위한 주소다.

IP 주소만으로는 프레임을 보낼 수 없다

예를 들어 내 컴퓨터가 어떤 서버로 데이터를 보내려고 한다고 해보자.

브라우저는 도메인을 입력받고, DNS를 통해 서버의 IP 주소를 알아낸다.

이제 내 컴퓨터는 이렇게 생각할 수 있다.

“좋아. 최종 목적지 IP 주소는 알겠어.”

하지만 실제 이더넷 LAN 안에서 데이터는 IP 패킷 그대로 날아다니지 않는다. IP 패킷은 이더넷 프레임 안에 담겨서 이동한다.

그리고 이더넷 프레임에는 출발지 MAC 주소와 목적지 MAC 주소가 들어간다.

여기서 문제가 생긴다.

내 컴퓨터는 최종 목적지 IP 주소는 알고 있지만, 지금 당장 프레임을 보낼 대상의 MAC 주소는 모를 수 있다.

이때 필요한 과정이 ARP다.

ARP란 무엇인가

ARP는 IP 주소에 해당하는 MAC 주소를 알아내는 프로토콜이다.

조금 더 정확히 말하면, 같은 LAN 안에서 어떤 IP 주소를 가진 장비의 MAC 주소를 알아내기 위한 과정이다.

비유하자면 IP 주소는 사람의 집 주소에 가깝고, MAC 주소는 지금 눈앞에서 직접 물건을 건네줄 사람의 이름표 같은 느낌이다.

택배를 보낼 때 최종 주소를 아는 것도 중요하지만, 실제로는 중간중간 물건을 넘겨줄 대상이 필요하다. 네트워크에서도 마찬가지다.

IP 주소는 최종 목적지를 가리킨다. 하지만 이더넷 프레임을 보내려면 “지금 같은 LAN 안에서 누구에게 프레임을 건네야 하는지”를 알아야 한다.

여기서 중요한 건, ARP가 아무 IP의 MAC 주소나 알아내는 마법 같은 기능은 아니라는 점이다.

ARP는 같은 LAN 안에서만 동작한다.

같은 네트워크에 있는 경우

내 컴퓨터의 IP가 192.168.0.10이고, 같은 네트워크 안에 있는 다른 컴퓨터의 IP가 192.168.0.20이라고 해보자.

내 컴퓨터가 192.168.0.20으로 데이터를 보내려면 먼저 판단한다.

“목적지 IP가 나와 같은 네트워크에 있나?”

서브넷 마스크를 기준으로 계산해보니 같은 네트워크라고 판단되었다.

그러면 내 컴퓨터는 이렇게 생각한다.

“그럼 게이트웨이로 보낼 필요는 없고, 저 IP를 가진 장비에게 직접 프레임을 보내면 되겠네.”

그런데 아직 192.168.0.20의 MAC 주소를 모른다.

이때 ARP Request를 보낸다.

ARP Request

ARP Request는 쉽게 말하면 이런 질문이다.

“192.168.0.20 쓰는 장비 있으면, 네 MAC 주소 좀 알려줘.”

이 요청은 브로드캐스트로 전송된다.

브로드캐스트라는 것은 같은 LAN 안에 있는 모든 장비에게 보내는 방식이다.

즉, 내 컴퓨터가 스위치에게 프레임을 보내면 스위치는 이 프레임을 같은 네트워크 안의 여러 포트로 뿌린다.

각 장비는 이 요청을 받아보고 이렇게 판단한다.

“ARP 요청이 왔네.” “찾는 IP가 내 IP인가?” “아니면 무시.” “내 IP라면 응답.”

여기서 192.168.0.20을 가진 장비만 응답한다.

ARP Reply

192.168.0.20을 가진 장비는 ARP Reply를 보낸다.

내용은 대략 이렇다.

“내가 192.168.0.20이고, 내 MAC 주소는 AA:BB:CC:DD:EE:FF야.”

ARP Reply는 보통 요청을 보낸 장비에게 직접 전달된다.

이제 내 컴퓨터는 알게 된다.

“아, 192.168.0.20으로 보내려면 목적지 MAC 주소를 AA:BB:CC:DD:EE:FF로 넣으면 되겠구나.”

그 다음부터는 이 MAC 주소를 이더넷 프레임의 목적지 MAC 주소로 넣고 데이터를 보낸다.

다른 네트워크에 있는 경우

이번에는 목적지 서버 IP가 8.8.8.8이라고 해보자.

내 컴퓨터는 먼저 서브넷 마스크를 보고 판단한다.

“8.8.8.8은 나와 같은 네트워크가 아니네.”

그러면 내 컴퓨터는 목적지 서버에게 직접 프레임을 보내지 않는다. 대신 기본 게이트웨이로 보낸다.

여기서 헷갈리기 쉬운 부분이 있다.

최종 목적지 IP는 여전히 8.8.8.8이다. 하지만 이더넷 프레임의 목적지 MAC 주소는 8.8.8.8 서버의 MAC 주소가 아니다.

내 컴퓨터와 같은 LAN 안에 있는 기본 게이트웨이, 즉 라우터의 MAC 주소가 들어간다.

왜냐하면 지금 내 컴퓨터가 직접 프레임을 건넬 수 있는 대상은 같은 LAN 안에 있는 라우터이기 때문이다.

그래서 내 컴퓨터는 다시 ARP를 사용한다.

“기본 게이트웨이 IP를 쓰는 장비야, 네 MAC 주소가 뭐야?”

게이트웨이가 ARP Reply로 자신의 MAC 주소를 알려주면, 내 컴퓨터는 그 MAC 주소를 목적지 MAC 주소로 넣어 프레임을 보낸다.

IP 패킷의 목적지는 8.8.8.8이지만, 이더넷 프레임의 목적지는 게이트웨이의 MAC 주소다.

여기서 중요한 건 이 문장이다.

IP는 최종 목적지 관점이고, MAC은 다음 홉 관점이다.

다음 홉이라는 관점

네트워크에서 다음 홉은 패킷이 다음으로 전달될 장비를 의미한다.

내 컴퓨터에서 같은 LAN 안의 다른 PC로 보낼 때는 그 PC가 다음 홉이다. 내 컴퓨터에서 인터넷 서버로 보낼 때는 기본 게이트웨이가 다음 홉이다.

즉, MAC 주소는 최종 목적지 전체 경로를 표현하는 주소가 아니다. 지금 이 LAN 안에서 다음으로 누구에게 프레임을 넘길지를 나타내는 주소다.

그래서 라우터를 한 번 지날 때마다 이더넷 프레임의 MAC 주소는 바뀔 수 있다.

하지만 IP 패킷의 출발지 IP와 목적지 IP는 기본적으로 최종 통신 주체를 나타내므로, 라우팅되는 동안 계속 목적지 판단의 기준이 된다.

정리하면 이런 느낌이다.

내 컴퓨터가 데이터를 보낼 때 IP 주소를 보고 최종 목적지를 판단한다. 그리고 실제로 프레임을 보내기 직전에는 ARP를 통해 다음 홉의 MAC 주소를 알아낸다. 그 MAC 주소를 이더넷 프레임에 넣고 같은 LAN 안에서 전달한다.

ARP Cache

그런데 매번 데이터를 보낼 때마다 ARP Request를 날리면 비효율적이다.

같은 장비와 여러 번 통신할 때마다

“너 MAC 주소 뭐였지?”

라고 계속 물어보는 셈이기 때문이다.

그래서 운영체제는 ARP로 알아낸 IP 주소와 MAC 주소의 매핑 정보를 잠시 저장해둔다.

이 저장 공간을 ARP Cache라고 한다.

예를 들어 한 번 192.168.0.1 게이트웨이의 MAC 주소를 알아냈다면, 이후에는 매번 ARP Request를 보내지 않고 ARP Cache에 저장된 정보를 사용한다.

물론 이 정보가 영원히 유지되는 것은 아니다.

네트워크 환경은 바뀔 수 있다. 장비가 교체될 수도 있고, IP 주소를 다른 장비가 사용할 수도 있다.

그래서 ARP Cache의 항목은 일정 시간이 지나면 사라지거나 갱신된다.

내 컴퓨터는 이렇게 판단한다

브라우저에서 어떤 서버에 접속한다고 생각해보면, 내 컴퓨터는 대략 이런 식으로 움직인다.

먼저 DNS 등을 통해 목적지 IP 주소를 알아낸다.

그 다음 서브넷 마스크를 기준으로 목적지 IP가 나와 같은 네트워크인지 판단한다.

같은 네트워크라면 목적지 IP를 가진 장비의 MAC 주소를 ARP로 찾는다.

다른 네트워크라면 기본 게이트웨이의 MAC 주소를 ARP로 찾는다.

MAC 주소를 알아내면 IP 패킷을 이더넷 프레임에 담고, 목적지 MAC 주소를 채워서 전송한다.

이 흐름을 보면 ARP가 왜 필요한지 조금 더 분명해진다.

IP 주소는 “어디까지 가야 하는가”를 알려준다. MAC 주소는 “지금 누구에게 넘겨야 하는가”를 알려준다. ARP는 그 둘을 연결해주는 과정이다.

처음에는 IP 주소만 알면 통신이 될 것 같았다.

하지만 실제 네트워크에서는 계층마다 필요한 주소가 다르다.

네트워크 계층에서는 IP 주소를 보고 목적지를 판단하고, 데이터 링크 계층에서는 MAC 주소를 보고 같은 LAN 안에서 프레임을 전달한다.

ARP는 이 두 세계를 이어주는 다리 같은 역할을 한다.

네트워크에 제대로 참여하려면 내 컴퓨터는 최소한 몇 가지 정보를 알고 있어야 한다.

내 IP 주소는 무엇인지, 내가 속한 네트워크의 범위는 어디까지인지, 다른 네트워크로 나가려면 누구에게 보내야 하는지, 도메인 이름을 IP 주소로 바꾸려면 누구에게 물어봐야 하는지.

이 정보들이 제대로 설정되어야 비로소 컴퓨터는 “나도 이 네트워크에서 통신할 준비가 됐다”고 말할 수 있다.

정적 IP와 동적 IP

IP 주소를 설정하는 방식은 크게 두 가지로 볼 수 있다.

하나는 사람이 직접 IP 주소를 지정하는 방식이다. 이걸 정적 IP라고 한다.

예를 들어 내 컴퓨터에 직접 이런 식으로 설정하는 것이다.

IP 주소: 192.168.0.10
서브넷 마스크: 255.255.255.0
기본 게이트웨이: 192.168.0.1
DNS 서버: 8.8.8.8

이 방식은 주소가 고정되어야 하는 서버나 네트워크 장비에서 자주 사용된다. 항상 같은 주소로 접근해야 하기 때문이다.

반대로 일반적인 노트북이나 스마트폰은 보통 IP 주소를 직접 설정하지 않는다. 와이파이에 연결하면 어느 순간 자동으로 IP 주소가 잡혀 있다.

이처럼 네트워크에 연결될 때 자동으로 IP 주소와 관련 설정을 받아오는 방식을 동적 IP라고 한다.

여기서 등장하는 것이 DHCP다.

DHCP는 네트워크 설정을 자동으로 나눠주는 방식이다

DHCP는 Dynamic Host Configuration Protocol의 약자다.

이름은 길지만 역할은 단순하게 생각하면 된다. 네트워크에 새로 들어온 컴퓨터에게 필요한 설정값을 자동으로 나눠주는 방식이다.

비유하자면 새로 이사 온 사람에게 관리사무소가 이렇게 안내해주는 느낌이다.

“당신 집 주소는 여기입니다.” “이 아파트 단지는 여기까지입니다.” “밖으로 나가려면 정문을 이용하세요.” “주소를 찾고 싶으면 이 안내소에 물어보세요.”

네트워크에서도 비슷하다.

컴퓨터가 네트워크에 연결되면 DHCP 서버는 컴퓨터에게 IP 주소, 서브넷 마스크, 기본 게이트웨이, DNS 서버 주소 같은 정보를 알려준다.

그래서 우리는 대부분의 상황에서 직접 IP 주소를 입력하지 않아도 된다. 와이파이에 연결하기만 하면 알아서 네트워크 설정이 잡히는 이유가 바로 여기에 있다.

내 컴퓨터는 왜 IP 주소를 알아야 할까

IP 주소는 네트워크 안에서 내 컴퓨터를 식별하는 주소다.

편지를 보내려면 받는 사람의 주소도 필요하지만, 보내는 사람의 주소도 필요하다. 그래야 상대방이 답장을 보낼 수 있다.

네트워크 통신도 마찬가지다.

내 컴퓨터가 서버에 요청을 보낼 때는 출발지 IP 주소와 목적지 IP 주소가 필요하다. 서버 입장에서는 응답을 다시 보내야 하므로 “이 요청을 보낸 컴퓨터가 누구인지” 알아야 한다.

즉, IP 주소는 내 컴퓨터가 네트워크 안에서 자기 자신을 설명하는 기본 정보다.

IP 주소가 없으면 내 컴퓨터는 네트워크에 제대로 참여할 수 없다. 말을 걸 수는 있어도, 상대가 나에게 다시 답장을 보낼 방법이 없는 상태에 가깝다.

서브넷 마스크는 같은 네트워크인지 판단하기 위해 필요하다

IP 주소만 있다고 끝나는 것은 아니다.

내 컴퓨터는 목적지 IP를 봤을 때 먼저 이런 판단을 해야 한다.

“이 목적지는 나와 같은 네트워크 안에 있나?” “아니면 다른 네트워크로 나가야 하나?”

이 판단을 할 때 필요한 정보가 서브넷 마스크다.

예를 들어 내 IP가 192.168.0.10이고 서브넷 마스크가 255.255.255.0이라면, 보통 192.168.0.x 범위를 같은 네트워크로 볼 수 있다.

그러면 목적지가 192.168.0.20이면 같은 네트워크 안에 있다고 판단한다. 하지만 목적지가 142.250.196.142 같은 외부 IP라면 같은 네트워크가 아니라고 판단한다.

여기서 중요한 건 서브넷 마스크가 단순한 부가 정보가 아니라는 점이다. 내 컴퓨터가 패킷을 어디로 보낼지 결정하기 위해 반드시 필요한 판단 기준이다.

같은 네트워크라면 내부에서 직접 찾아보면 된다. 다른 네트워크라면 밖으로 나가는 길을 찾아야 한다.

기본 게이트웨이는 밖으로 나가는 문이다

기본 게이트웨이는 내 컴퓨터가 다른 네트워크로 나갈 때 사용하는 첫 번째 출구다.

집 안에서 다른 방으로 이동할 때는 그냥 걸어가면 된다. 하지만 집 밖으로 나가려면 현관문을 지나야 한다.

네트워크에서도 비슷하다.

같은 LAN 안에 있는 장비와 통신할 때는 스위치를 통해 직접 전달할 수 있다. 하지만 인터넷에 있는 서버처럼 다른 네트워크로 가야 한다면 내 컴퓨터 혼자서는 갈 수 없다.

이때 기본 게이트웨이로 패킷을 보낸다.

보통 집이나 회사 네트워크에서는 공유기나 라우터가 기본 게이트웨이 역할을 한다.

내 컴퓨터 입장에서는 이렇게 판단하는 셈이다.

“목적지가 내 네트워크 안에 있네? 그러면 내부에서 찾아보자.” “목적지가 내 네트워크 밖이네? 그러면 일단 게이트웨이에게 보내자.”

기본 게이트웨이가 설정되어 있지 않으면 같은 네트워크 안에서는 통신이 될 수 있지만, 인터넷으로 나가는 통신은 막힐 수 있다.

서버는 살아 있고 와이파이도 연결되어 있는데 외부 사이트 접속이 안 되는 경우, 게이트웨이 설정 문제를 의심할 수 있는 이유도 여기에 있다.

DNS 서버 주소는 이름을 IP 주소로 바꾸기 위해 필요하다

사람은 보통 IP 주소를 외우지 않는다.

우리는 브라우저에 google.com 같은 도메인 이름을 입력한다. 하지만 실제 네트워크 통신에서는 결국 IP 주소가 필요하다.

이때 도메인 이름을 IP 주소로 바꿔주는 시스템이 DNS다. 그리고 내 컴퓨터는 DNS 서버 주소를 알고 있어야 한다.

그래야 이렇게 물어볼 수 있다.

“google.com의 IP 주소가 뭐야?”

DNS 서버가 응답해주면, 그때부터 내 컴퓨터는 해당 IP 주소를 목적지로 삼아 통신을 시작할 수 있다.

DNS 서버 주소가 잘못되어 있으면 인터넷 연결 자체는 되어 있어도 도메인 기반 접속이 안 될 수 있다.

예를 들어 IP 주소로 직접 접속하면 되는데, 도메인으로 접속하면 안 되는 상황이 생길 수 있다. 이런 경우에는 네트워크가 완전히 끊긴 것이 아니라 DNS 조회 과정에 문제가 있을 수 있다.

DHCP가 없다면 어떤 일이 생길까

DHCP가 없다면 네트워크에 연결되는 장비마다 사람이 직접 설정해야 한다.

노트북 한 대라면 괜찮을 수 있다. 하지만 회사에 컴퓨터가 수십 대, 수백 대 있다면 이야기가 달라진다.

각 장비마다 IP 주소를 하나씩 정하고, 중복되지 않게 관리하고, 서브넷 마스크와 게이트웨이와 DNS 서버까지 직접 입력해야 한다.

문제는 IP 주소가 중복되면 통신 문제가 생긴다는 점이다. 같은 네트워크 안에서 두 장비가 같은 IP를 사용하면, 네트워크 입장에서는 “이 주소가 누구 것인지” 헷갈리게 된다.

DHCP는 이런 일을 줄여준다.

새 장비가 네트워크에 들어오면 사용 가능한 IP 주소를 하나 빌려주고, 필요한 설정을 함께 전달한다. 사용 시간이 끝나거나 네트워크에서 나가면 그 주소를 다시 회수해서 다른 장비에 줄 수도 있다.

그래서 DHCP는 단순히 편의 기능이 아니라, 네트워크 설정을 안정적으로 관리하기 위한 방식이라고 볼 수 있다.

내 컴퓨터가 네트워크에 연결될 때의 흐름

노트북이 와이파이에 연결되는 상황을 머릿속으로 그려보면 DHCP의 역할이 조금 더 자연스럽게 보인다.

처음에 내 컴퓨터는 아직 IP 주소를 모른다. 그래서 네트워크에 대고 묻는다.

“저 네트워크에 들어왔는데, 제가 사용할 설정을 받을 수 있을까요?”

그러면 DHCP 서버가 응답한다.

“이 IP 주소를 사용하세요.” “이 서브넷 마스크를 사용하세요.” “외부로 나갈 때는 이 게이트웨이를 사용하세요.” “도메인 이름을 물어볼 때는 이 DNS 서버를 사용하세요.”

이 정보를 받은 뒤에야 내 컴퓨터는 제대로 판단할 수 있다.

목적지가 같은 네트워크인지 다른 네트워크인지 판단하고, 다른 네트워크라면 기본 게이트웨이로 보내고, 도메인 이름이 주어지면 DNS 서버에 물어보고, 응답을 받을 수 있도록 자기 IP 주소를 출발지로 적는다.

여기서 중요한 건 네트워크 연결이 “선만 연결되면 끝”이 아니라는 점이다.

물리적으로 연결되는 것과, 통신에 필요한 설정을 갖추는 것은 다르다. 랜선이나 와이파이는 길을 열어주는 것이고, IP 주소와 게이트웨이와 DNS 설정은 그 길 위에서 어떻게 움직일지 알려주는 정보에 가깝다.

개발자 관점에서 이 설정들이 중요한 이유

개발을 하다 보면 이런 상황을 자주 만난다.

서버는 떠 있는데 접속이 안 된다. 내 로컬에서는 되는데 다른 사람 컴퓨터에서는 안 된다. IP로는 접속되는데 도메인으로는 안 된다. 같은 네트워크에서는 되는데 외부에서는 안 된다.

이럴 때 무작정 “인터넷이 안 된다”고만 보면 원인을 좁히기 어렵다.

IP 주소가 제대로 잡혔는지, 서브넷 마스크가 맞는지, 기본 게이트웨이가 설정되어 있는지, DNS 서버가 정상인지 나누어 보면 문제를 훨씬 구체적으로 볼 수 있다.

예를 들어 내 컴퓨터에 IP 주소가 없다면 네트워크에 제대로 참여하지 못한 상태일 수 있다. 게이트웨이가 없다면 외부 네트워크로 나가지 못할 수 있다. DNS 서버가 이상하다면 도메인 이름을 IP 주소로 바꾸지 못할 수 있다.

결국 DHCP와 네트워크 설정은 장애를 볼 때 가장 처음 확인해야 하는 기본 정보에 가깝다.

네트워크 통신은 멀리 있는 서버를 향해 바로 날아가는 것이 아니다. 내 컴퓨터가 자기 주소를 알고, 같은 네트워크인지 판단하고, 밖으로 나갈 문을 알고, 이름을 주소로 바꾸는 과정을 거친다.

DHCP는 이 과정에 필요한 출발 정보를 자동으로 준비해주는 역할을 한다.

결론부터 말하면 그렇지 않다.

우리가 집이나 회사에서 사용하는 대부분의 장비는 인터넷에서 직접 보이는 IP 주소가 아니라, 내부 네트워크에서만 사용하는 IP 주소를 가진다. 이때 등장하는 개념이 공인 IP, 사설 IP, 그리고 NAT다.

공인 IP는 인터넷에서 사용하는 주소다

공인 IP는 인터넷에서 직접 사용할 수 있는 IP 주소다.

웹 서버, 클라우드 서버, 공유기, 회사의 외부망 장비처럼 인터넷과 직접 통신해야 하는 장비는 공인 IP를 사용한다.

비유하자면 공인 IP는 실제 우편 주소에 가깝다.

누군가 인터넷을 통해 특정 서버에 접속하려면, 결국 그 서버를 찾아갈 수 있는 주소가 필요하다. 이 주소가 인터넷에서 유일하게 식별되어야 한다. 그래야 여러 네트워크를 거쳐도 “아, 이 목적지는 저쪽으로 보내야 하는구나” 하고 라우터들이 판단할 수 있다.

예를 들어 어떤 서버가 공인 IP 203.0.113.10을 가지고 있다고 해보자.

클라이언트가 이 서버로 요청을 보내면, 인터넷의 라우터들은 목적지 IP를 보고 패킷을 전달한다.

“203.0.113.10으로 가야 하네.” “그럼 다음 라우터는 이쪽이야.” “이 네트워크까지 왔으니 이제 해당 서버로 넘기면 되겠네.”

이런 식으로 공인 IP는 인터넷 전체에서 목적지를 찾기 위한 주소로 사용된다.

사설 IP는 내부 네트워크에서 사용하는 주소다

반면 사설 IP는 내부 네트워크에서만 사용하는 IP 주소다.

집에서 와이파이에 연결된 내 노트북의 IP를 확인해보면 보통 이런 주소가 나온다.

192.168.0.10
192.168.1.15
10.0.0.5
172.16.0.20

이런 주소들은 인터넷 전체에서 유일한 주소가 아니다. 다른 집, 다른 회사, 다른 카페에서도 똑같은 192.168.0.10을 사용할 수 있다.

처음에는 이게 이상하게 느껴졌다.

“IP 주소는 장비를 구분하는 주소라면서, 중복되어도 되는 건가?”

여기서 중요한 건 사설 IP는 내부 네트워크 안에서만 의미가 있다는 점이다.

우리 집 안에서 192.168.0.10은 내 노트북일 수 있다. 하지만 옆집의 192.168.0.10은 전혀 다른 사람의 스마트폰일 수 있다.

마치 아파트 안에서 “101호”라는 번호가 여러 건물에 존재할 수 있는 것과 비슷하다. A아파트 101호와 B아파트 101호는 같은 101호지만, 서로 다른 공간 안에 있기 때문에 충돌하지 않는다.

사설 IP도 마찬가지다.

내부 네트워크라는 범위 안에서만 유효하기 때문에 여러 곳에서 같은 사설 IP를 사용해도 문제가 되지 않는다.

왜 사설 IP가 필요할까?

가장 큰 이유는 IPv4 주소가 부족하기 때문이다.

IPv4 주소는 32비트로 구성되어 있고, 이론적으로 약 43억 개 정도를 만들 수 있다. 처음에는 이 정도면 충분해 보였을 수도 있다.

하지만 지금은 컴퓨터, 스마트폰, 태블릿, 서버, IoT 기기, 네트워크 장비까지 너무 많은 장비가 인터넷에 연결된다.

모든 장비에 공인 IPv4 주소를 하나씩 나눠주기에는 주소가 부족하다.

그래서 나온 방식이 이렇다.

내부 네트워크에서는 사설 IP를 사용한다. 인터넷으로 나갈 때만 공인 IP를 사용한다.

즉, 집 안에서는 노트북, 스마트폰, 태블릿이 각각 사설 IP를 가진다.

노트북: 192.168.0.10
스마트폰: 192.168.0.11
태블릿: 192.168.0.12

하지만 인터넷 입장에서 보면 이 장비들이 직접 보이는 것이 아니라, 보통 공유기의 공인 IP 하나만 보인다.

공유기 공인 IP: 203.0.113.5

내부에서는 여러 장비가 존재하지만, 외부 인터넷과 통신할 때는 하나의 공인 IP를 함께 사용하는 구조가 되는 것이다.

NAT는 사설 IP를 공인 IP로 바꿔주는 기술이다

NAT는 Network Address Translation의 약자다. 말 그대로 네트워크 주소를 변환하는 기술이다.

보통은 내부 네트워크의 사설 IP를 외부 인터넷에서 사용할 공인 IP로 변환할 때 사용한다.

예를 들어 내 노트북의 IP가 192.168.0.10이고, 공유기의 공인 IP가 203.0.113.5라고 해보자.

내 노트북이 웹 서버 93.184.216.34에 접속하려고 한다.

처음 패킷은 이렇게 만들어질 수 있다.

출발지 IP: 192.168.0.10
목적지 IP: 93.184.216.34

그런데 이 패킷이 그대로 인터넷으로 나가면 문제가 생긴다.

192.168.0.10은 사설 IP이기 때문에 인터넷에서 직접 찾아갈 수 없는 주소다. 외부 서버가 응답을 보내려고 해도 192.168.0.10이 어디에 있는지 알 수 없다.

그래서 공유기가 중간에서 출발지 IP를 바꾼다.

변환 전
출발지 IP: 192.168.0.10
목적지 IP: 93.184.216.34

변환 후
출발지 IP: 203.0.113.5
목적지 IP: 93.184.216.34

외부 서버 입장에서는 요청이 203.0.113.5에서 온 것처럼 보인다. 서버는 이 공인 IP로 응답을 보낸다.

응답이 다시 공유기로 돌아오면, 공유기는 기억해둔 정보를 보고 판단한다.

“아까 192.168.0.10이 이 서버에 요청을 보냈었지.” “그러면 이 응답은 다시 192.168.0.10에게 전달해야겠다.”

이렇게 NAT는 내부 사설 IP와 외부 공인 IP 사이에서 주소를 바꿔주는 역할을 한다.

그런데 내부 장비가 여러 대라면?

여기서 한 번 더 생각해볼 문제가 있다.

집 안에 노트북만 있는 것이 아니라 스마트폰, 태블릿도 있다고 해보자.

노트북: 192.168.0.10
스마트폰: 192.168.0.11
태블릿: 192.168.0.12

이 세 장비가 동시에 같은 웹 서버에 접속하면 어떻게 될까?

외부 서버 입장에서는 세 요청이 모두 같은 공인 IP에서 온 것처럼 보일 수 있다.

공유기 공인 IP: 203.0.113.5

그러면 응답이 돌아왔을 때 공유기는 어떻게 구분할까?

“이 응답은 노트북에게 가야 하나?” “스마트폰에게 가야 하나?” “태블릿에게 가야 하나?”

단순히 IP 주소만 바꾸는 NAT만으로는 부족해진다. 그래서 함께 사용되는 것이 포트 기반 NAT, 또는 NAPT다.

NAPT는 IP와 포트를 함께 변환한다

NAPT는 Network Address Port Translation의 약자다. IP 주소뿐만 아니라 포트 번호까지 함께 변환하는 방식이다.

우리가 흔히 말하는 NAT 환경에서는 실제로 NAPT가 사용되는 경우가 많다.

예를 들어 내부 장비들이 각각 웹 서버에 요청을 보낸다고 해보자.

노트북
192.168.0.10:50001 → 93.184.216.34:443

스마트폰
192.168.0.11:50002 → 93.184.216.34:443

태블릿
192.168.0.12:50003 → 93.184.216.34:443

공유기는 이 요청들을 외부로 내보내면서 출발지 IP를 자신의 공인 IP로 바꾼다. 그리고 필요하다면 포트 번호도 바꾼다.

203.0.113.5:61001 → 93.184.216.34:443
203.0.113.5:61002 → 93.184.216.34:443
203.0.113.5:61003 → 93.184.216.34:443

외부 서버 입장에서는 모두 203.0.113.5에서 온 요청으로 보이지만, 포트 번호가 다르다.

공유기는 내부적으로 이런 변환 테이블을 기억한다.

203.0.113.5:61001 ↔ 192.168.0.10:50001
203.0.113.5:61002 ↔ 192.168.0.11:50002
203.0.113.5:61003 ↔ 192.168.0.12:50003

이제 응답이 돌아오면 공유기는 목적지 포트를 보고 판단할 수 있다.

“목적지 포트가 61001이네. 이건 노트북으로 보내야겠다.” “61002면 스마트폰이었지.” “61003은 태블릿으로 보내면 되겠네.”

여기서 중요한 건, 여러 내부 장비가 하나의 공인 IP를 공유할 수 있는 이유가 포트 번호를 함께 사용하기 때문이라는 점이다.

공인 IP 하나만 보면 모두 같은 집에서 나간 요청처럼 보인다. 하지만 공유기 입장에서는 포트 번호까지 함께 보면 각각의 요청을 구분할 수 있다.

NAT는 일종의 안내 데스크처럼 동작한다

NAT를 안내 데스크에 비유하면 이해하기 쉽다.

회사 건물 안에는 여러 직원이 있다.

개발팀 민수
디자인팀 지연
인프라팀 현우

하지만 외부 사람은 이 직원들의 자리 번호를 직접 알지 못한다. 외부에 공개된 대표 번호만 알고 있다.

회사 대표 번호: 02-1234-5678

직원이 외부에 전화를 걸면, 외부 사람에게는 회사 대표 번호가 보인다. 나중에 외부에서 응답 전화가 오면 안내 데스크가 기억하고 있다가 해당 직원에게 연결해준다.

“아까 이 번호로 전화한 건 개발팀 민수였어.” “그러면 이 응답 전화는 민수에게 돌려주자.”

NAT도 비슷하다.

내부 장비의 사설 IP는 외부에 직접 노출되지 않는다. 대신 공유기의 공인 IP로 바뀌어 나간다. 그리고 돌아오는 응답은 NAT 테이블을 보고 원래 내부 장비로 전달된다.

NAT를 거치면 내부 장비는 직접 보이지 않는다

NAT를 사용하면 내부 장비들은 외부 인터넷에 직접 노출되지 않는다.

외부에서 보면 내 노트북의 192.168.0.10이 보이는 것이 아니라, 공유기의 공인 IP만 보인다.

이 점은 보안적으로도 어느 정도 장점이 있다. 외부에서 내부 장비로 바로 접근하기 어렵기 때문이다.

하지만 이것이 방화벽을 완전히 대체한다는 뜻은 아니다. NAT는 기본적으로 주소 변환 기술이다. 보안 장비라기보다는, 내부 주소와 외부 주소 사이를 변환하면서 결과적으로 내부 장비가 직접 드러나지 않는 효과가 생긴다고 보는 편이 좋다.

또 하나 중요한 점은 NAT 환경에서는 외부에서 내부 장비로 먼저 접속하기가 어렵다는 것이다.

내부 장비가 먼저 요청을 보낸 경우에는 공유기가 변환 테이블을 만들기 때문에 응답을 돌려줄 수 있다. 하지만 외부에서 갑자기 203.0.113.5로 접속한다고 해서 공유기가 그 요청을 내부의 어떤 장비로 보내야 할지 알 수는 없다.

이럴 때는 포트 포워딩 같은 설정이 필요하다. 특정 포트로 들어온 요청은 내부의 특정 장비로 보내라고 미리 정해두는 방식이다.

예를 들면 이런 식이다.

공인 IP 203.0.113.5:8080으로 들어온 요청
→ 내부 192.168.0.10:80으로 전달

이렇게 하면 외부에서 공유기의 특정 포트로 접근했을 때 내부 서버로 연결할 수 있다.

개발할 때 NAT를 왜 알아야 할까?

개발을 하다 보면 “내 컴퓨터에서는 되는데 외부에서는 안 된다”는 상황을 자주 만난다.

로컬에서 서버를 띄우면 보통 이런 주소로 접속한다.

localhost:3000
192.168.0.10:3000

내 컴퓨터 안에서는 잘 된다. 같은 와이파이에 연결된 다른 장비에서도 192.168.0.10:3000으로 접속할 수 있을 수 있다.

하지만 외부 인터넷에서는 이 주소로 접속할 수 없다.

왜냐하면 192.168.0.10은 사설 IP이기 때문이다. 인터넷에서는 이 주소를 목적지로 찾아올 수 없다.

외부에서 접근하려면 공인 IP가 필요하고, 공유기나 방화벽에서 해당 요청을 내부 서버로 전달하도록 설정해야 한다.

클라우드 환경에서도 비슷한 개념이 계속 등장한다.

서버 인스턴스가 사설 IP만 가지고 있으면 인터넷에서 직접 접근할 수 없다. 외부에서 접속해야 한다면 공인 IP를 붙이거나, 로드밸런서나 NAT Gateway 같은 장비를 거쳐야 한다.

반대로 내부 서버가 외부 인터넷으로 패키지를 다운로드하거나 API 요청을 보내야 할 때도 NAT가 필요할 수 있다. 서버 자체는 사설 IP만 가지고 있지만, NAT Gateway를 통해 외부 인터넷으로 나갈 수 있는 구조를 만드는 것이다.

즉 NAT는 단순히 집 공유기에서만 쓰는 개념이 아니다. 개발 환경, 배포 환경, 클라우드 네트워크 구조를 이해할 때도 계속 등장한다.

공인 IP, 사설 IP, NAT를 하나의 흐름으로 보면

내 컴퓨터가 인터넷의 웹 서버에 접속하는 흐름을 다시 보면 이렇다.

먼저 내 컴퓨터는 내부 네트워크에서 사설 IP를 가지고 있다.

내 컴퓨터: 192.168.0.10

웹 서버는 인터넷에서 접근 가능한 공인 IP를 가지고 있다.

웹 서버: 93.184.216.34

내 컴퓨터가 웹 서버로 요청을 보내면, 패킷은 공유기를 지나간다.

공유기는 NAT를 수행한다.

192.168.0.10:50001
→ 203.0.113.5:61001

웹 서버는 203.0.113.5:61001로 응답을 보낸다.

공유기는 NAT 테이블을 보고 다시 내부 장비를 찾는다.

203.0.113.5:61001
→ 192.168.0.10:50001

결국 내 컴퓨터는 사설 IP를 사용하고 있지만, 인터넷과 통신할 수 있다. 그 사이에서 공유기가 공인 IP와 포트 번호를 이용해 요청과 응답을 이어주고 있기 때문이다.

여기서 중요한 건 NAT가 단순히 “IP를 바꾼다”에서 끝나는 개념이 아니라는 점이다.

NAT는 내부 네트워크와 외부 인터넷 사이의 경계에서 동작한다. 내부 장비들이 사설 IP를 사용하면서도 인터넷과 통신할 수 있게 해준다. 그리고 여러 장비가 하나의 공인 IP를 공유할 수 있도록 포트 번호까지 함께 활용한다.

그래서 공인 IP, 사설 IP, NAT를 이해하면 “내 컴퓨터는 분명 IP가 있는데 왜 외부에서 접속이 안 되지?”, “클라우드 서버는 왜 공인 IP가 있어야 하지?”, “NAT Gateway는 왜 필요하지?” 같은 질문들이 조금씩 연결되기 시작한다.

그런데 IP 주소를 그냥 하나의 숫자처럼 보면 조금 헷갈린다. 예를 들어 192.168.10.25라는 주소가 있다고 해보자.

처음 보면 이 주소 전체가 한 대의 컴퓨터를 가리키는 것처럼 보인다. 하지만 실제로 IP 주소는 크게 두 부분으로 나누어 생각한다.

네트워크 주소와 호스트 주소다.

네트워크 주소는 “어느 네트워크에 속해 있는가”를 나타내고, 호스트 주소는 “그 네트워크 안에서 어떤 장비인가”를 나타낸다.

비유하자면 주소에서 동네 이름과 집 번호를 나누는 느낌이다.

서울시 강남구 어떤 동네까지가 네트워크 주소라면, 몇 번 집이 호스트 주소에 가깝다.

컴퓨터가 통신할 때도 비슷하게 생각한다.

“상대방이 나와 같은 동네에 있나?” “아니면 다른 동네라서 게이트웨이를 통해 나가야 하나?”

이 판단을 하기 위해 IP 주소를 네트워크 부분과 호스트 부분으로 나누어 본다.

IPv4 주소

IPv4 주소는 우리가 흔히 보는 이런 형태의 주소다.

192.168.10.25

숫자 4개가 점으로 구분되어 있다. 각 숫자는 0부터 255까지의 값을 가질 수 있다.

사람이 보기에는 192, 168, 10, 25처럼 나뉘어 보이지만, 컴퓨터 입장에서는 결국 0과 1로 이루어진 32비트 값이다.

즉 IPv4 주소는 총 32비트 주소다.

다만 블로그 글을 쓰면서 매번 2진수로 풀어 쓰면 너무 피곤해진다. 지금은 이렇게만 잡고 가도 충분하다.

IPv4 주소는 32비트이고, 그 안에서 앞쪽 일부는 네트워크를 나타내고, 뒤쪽 일부는 그 네트워크 안의 호스트를 나타낸다.

여기서 중요한 건 IP 주소만 봐서는 어디까지가 네트워크 부분인지 알 수 없다는 것이다.

그래서 필요한 것이 서브넷 마스크다.

서브넷 마스크

서브넷 마스크는 IP 주소에서 어디까지가 네트워크 주소인지 알려주는 값이다.

예를 들어 이런 설정이 있다고 해보자.

IP 주소:        192.168.10.25
서브넷 마스크: 255.255.255.0

255.255.255.0이라는 서브넷 마스크는 앞의 세 묶음, 즉 192.168.10까지를 네트워크 부분으로 보겠다는 뜻으로 이해할 수 있다.

그러면 이 IP 주소는 이렇게 나누어 볼 수 있다.

네트워크 부분: 192.168.10
호스트 부분: 25

그래서 192.168.10.25는 192.168.10.0 네트워크에 속한 25번 호스트처럼 볼 수 있다.

물론 실제 내부에서는 비트 단위로 계산하지만, 처음에는 이 정도 감각이 더 중요하다.

같은 네트워크인지 판단하기

내 컴퓨터가 어떤 서버로 데이터를 보내려고 한다고 해보자.

목적지 IP가 192.168.10.50이다.

내 설정은 이렇다.

내 IP 주소:      192.168.10.25
서브넷 마스크:   255.255.255.0
목적지 IP 주소:  192.168.10.50

서브넷 마스크가 255.255.255.0이므로 앞의 세 묶음이 네트워크 부분이다.

내 네트워크는 192.168.10.0이다. 목적지도 192.168.10.0 네트워크에 있다.

그러면 컴퓨터는 이렇게 판단할 수 있다.

목적지가 나와 같은 네트워크 안에 있네.
그럼 굳이 라우터를 타고 밖으로 나갈 필요는 없겠다.
같은 LAN 안에서 직접 보내면 되겠다.

반대로 목적지 IP가 192.168.20.50이라면 어떨까?

내 IP 주소:      192.168.10.25
서브넷 마스크:   255.255.255.0
목적지 IP 주소:  192.168.20.50

내 네트워크는 192.168.10.0이다. 목적지는 192.168.20.0 네트워크에 있다.

앞의 세 묶음이 다르다.

그러면 컴퓨터는 이렇게 판단한다.

목적지가 내 네트워크 안에 없네.
그럼 내가 직접 보낼 수 없겠다.
기본 게이트웨이로 보내야겠다.

여기서 중요한 건 IP 주소와 서브넷 마스크가 단순히 “내 주소가 뭔지”를 알려주는 용도만은 아니라는 점이다.

이 둘은 함께 사용되어 목적지가 같은 네트워크에 있는지, 다른 네트워크에 있는지 판단하는 기준이 된다.

CIDR 표기법

서브넷 마스크는 255.255.255.0처럼 쓸 수도 있지만, CIDR 표기법으로 더 간단하게 표현하기도 한다.

예를 들면 이런 식이다.

192.168.10.25/24

여기서 /24는 앞에서부터 24비트가 네트워크 부분이라는 뜻이다.

IPv4 주소는 총 32비트다. 그중 앞의 24비트를 네트워크 주소로 쓰고, 나머지 8비트를 호스트 주소로 쓰겠다는 의미다.

/24는 255.255.255.0과 같은 의미로 볼 수 있다.

자주 보게 되는 예시는 이런 것들이다.

/8
/16
/24
/32

/8은 앞의 8비트가 네트워크 부분이다. /16은 앞의 16비트가 네트워크 부분이다. /24는 앞의 24비트가 네트워크 부분이다. /32는 주소 전체 32비트가 딱 하나의 호스트를 가리키는 경우라고 볼 수 있다.

처음에는 /24 정도부터 익숙해지는 게 좋다.

개발이나 인프라 설정을 보다 보면 이런 표현을 자주 만난다.

192.168.0.0/24
10.0.0.0/16
172.16.0.0/12
0.0.0.0/0

특히 클라우드나 쿠버네티스, 보안 그룹, 라우팅 테이블 같은 걸 보다 보면 CIDR 표기법이 자주 나온다.

처음엔 그냥 알 수 없는 숫자처럼 보이지만, 결국 의미는 이것이다.

이 IP 범위를 하나의 네트워크 범위로 보겠다.

서브네팅

서브네팅은 하나의 큰 네트워크를 더 작은 네트워크들로 나누는 것이다.

예를 들어 192.168.10.0/24라는 네트워크가 있다고 해보자.

이 네트워크 안에는 여러 호스트를 둘 수 있다. 그런데 모든 장비를 하나의 네트워크에 다 넣는 것이 항상 좋은 것은 아니다.

부서별로 나누고 싶을 수도 있고, 서버 영역과 사용자 PC 영역을 분리하고 싶을 수도 있고, 보안 정책을 다르게 적용하고 싶을 수도 있다.

이럴 때 큰 네트워크를 더 작은 단위로 쪼갠다.

비유하자면 하나의 큰 사무실을 칸막이로 나누는 느낌이다.

공간은 하나의 건물 안에 있지만, 개발팀 자리, 운영팀 자리, 회의실, 서버실처럼 구역을 나누는 것이다.

네트워크도 마찬가지다.

하나의 큰 IP 대역을 목적에 맞게 더 작은 네트워크로 나누면 관리하기가 쉬워진다.

예를 들어 이런 식으로 나눌 수 있다.

192.168.10.0/24

이 큰 네트워크를 더 작은 네트워크로 나누면

192.168.10.0/25
192.168.10.128/25

처럼 나눌 수 있다.

여기서 /24보다 /25는 네트워크 부분이 1비트 더 길다. 네트워크 부분이 길어졌다는 것은, 호스트에 사용할 수 있는 부분이 줄어든다는 뜻이다.

즉 더 작은 네트워크가 된다.

처음부터 서브네팅 계산을 깊게 파고들 필요는 없다고 생각한다. 중요한 흐름은 이거다.

네트워크 부분을 더 길게 잡으면,
하나의 네트워크 안에 들어갈 수 있는 호스트 수는 줄어든다.

대신 네트워크를 더 잘게 나눌 수 있다.

반대로 네트워크 부분을 짧게 잡으면, 하나의 네트워크 안에 더 많은 호스트를 넣을 수 있다.

대신 네트워크 단위가 커진다.

네트워크 장비는 어떻게 판단할까

내 컴퓨터가 어떤 목적지로 데이터를 보내려고 할 때, 머릿속에서는 대략 이런 판단이 일어난다고 볼 수 있다.

1. 내 IP 주소를 확인한다.
2. 내 서브넷 마스크를 확인한다.
3. 목적지 IP 주소를 확인한다.
4. 내 네트워크 주소와 목적지의 네트워크 주소를 비교한다.
5. 같은 네트워크면 같은 LAN 안에서 보낸다.
6. 다른 네트워크면 기본 게이트웨이로 보낸다.

여기서 서브넷 마스크가 빠지면 판단 기준이 사라진다.

IP 주소가 192.168.10.25라고 해서 무조건 192.168.10까지가 네트워크라는 뜻은 아니다.

/24라면 192.168.10.0 네트워크로 볼 수 있지만, /16이라면 192.168.0.0 네트워크로 볼 수도 있다.

같은 IP 주소처럼 보여도 서브넷 마스크에 따라 네트워크 범위가 달라진다.

여기서 중요한 건 IP 주소는 혼자 쓰이지 않는다는 점이다.

IP 주소는 서브넷 마스크와 함께 봐야 한다.

IP 주소 = 내 위치
서브넷 마스크 = 어디까지를 같은 네트워크로 볼지 정하는 기준
CIDR = 그 기준을 짧게 표현하는 방법
서브네팅 = 네트워크를 목적에 맞게 더 잘게 나누는 작업

결국 IP 주소를 나눈다는 것은 단순히 숫자를 쪼개는 일이 아니다.

컴퓨터가 통신하기 전에 “이 목적지가 내 주변에 있는가, 아니면 밖으로 나가야 하는가”를 판단하기 위한 기준을 세우는 일이다.

그런데 실제 인터넷 통신은 대부분 같은 LAN 안에서 끝나지 않는다.

내 컴퓨터에서 브라우저를 열고 어떤 웹사이트에 접속하면, 그 서버는 보통 내 방 안에도 없고, 같은 사무실 스위치에 연결되어 있지도 않다. 다른 지역, 다른 회사, 다른 나라의 네트워크에 있을 수도 있다.

그러면 질문이 생긴다.

같은 LAN을 벗어나 다른 네트워크에 있는 서버까지 가려면 무엇이 필요할까?

MAC 주소만으로는 멀리 갈 수 없다

MAC 주소는 네트워크 장비를 식별하는 주소다. 특히 이더넷 환경에서는 프레임을 보낼 때 출발지 MAC 주소와 목적지 MAC 주소가 들어간다.

하지만 여기서 중요한 건, MAC 주소는 같은 LAN 안에서 다음 장비를 찾는 데 주로 사용된다는 점이다.

예를 들어 내 컴퓨터와 같은 스위치에 연결된 다른 컴퓨터로 데이터를 보낸다면, 스위치는 목적지 MAC 주소를 보고 어느 포트로 보낼지 판단할 수 있다.

스위치 입장에서는 이런 식이다.

“이 프레임의 목적지 MAC 주소가 A네. 내 MAC 주소 테이블을 보니까 A는 3번 포트에 있군. 그러면 3번 포트로 보내자.”

이 흐름은 같은 LAN 안에서는 잘 동작한다.

그런데 목적지가 외부 웹 서버라면 이야기가 달라진다.

내 컴퓨터가 example.com 같은 외부 서버에 접속하려고 한다고 해보자. 그 서버의 MAC 주소를 안다고 해서 바로 보낼 수 있을까?

그럴 수 없다.

왜냐하면 그 서버는 내 LAN 안에 있는 장비가 아니기 때문이다. 내 스위치가 전 세계 모든 서버의 MAC 주소를 알고 있을 수도 없고, 알 필요도 없다.

MAC 주소는 마치 “아파트 단지 안에서 몇 동 몇 호로 찾아가는 정보”에 가깝다. 단지 안에서는 유용하지만, 다른 도시의 목적지를 찾아가기에는 부족하다.

다른 도시로 가려면 먼저 도시 이름, 도로망, 경로 같은 더 큰 단위의 주소 체계가 필요하다.

네트워크에서는 그 역할을 IP 주소가 한다.

데이터 링크 계층의 한계

데이터 링크 계층은 같은 네트워크 안에서 데이터를 전달하는 데 초점이 있다.

이더넷, MAC 주소, 스위치, VLAN 같은 개념들이 여기에 가까웠다. 이 계층의 관심사는 대략 이런 느낌이다.

“같은 LAN 안에서 이 프레임을 누구에게 전달해야 하지?” “이 MAC 주소는 어느 포트에 있지?” “이 VLAN 안에서만 브로드캐스트를 보내야겠군.”

즉, 데이터 링크 계층은 가까운 범위의 전달에 강하다.

하지만 인터넷은 하나의 거대한 LAN이 아니다. 수많은 네트워크가 서로 연결된 구조다.

집 네트워크, 회사 네트워크, 통신사 네트워크, 클라우드 사업자 네트워크, 데이터센터 네트워크가 서로 이어져 있다. 이렇게 여러 네트워크를 건너가야 할 때는 단순히 MAC 주소만 보고 판단할 수 없다.

여기서 필요한 계층이 네트워크 계층이다.

네트워크 계층은 무엇을 해결할까

네트워크 계층은 말 그대로 네트워크와 네트워크 사이의 이동을 다룬다.

같은 LAN 안에서 끝나는 통신이 아니라, 다른 네트워크에 있는 목적지까지 데이터를 보내기 위해 필요한 계층이다.

네트워크 계층의 핵심 질문은 이렇다.

“이 데이터의 최종 목적지는 어느 네트워크에 있지?” “그 목적지로 가려면 다음에는 어느 장비로 보내야 하지?” “지금 내가 직접 보낼 수 있는 곳인가, 아니면 라우터에게 넘겨야 하나?”

여기서 등장하는 대표적인 주소가 IP 주소다.

IP 주소는 최종 목적지를 찾기 위한 주소다

IP 주소는 다른 네트워크에 있는 목적지를 찾기 위한 주소 체계다.

MAC 주소가 같은 LAN 안에서 다음 장비를 찾는 데 사용된다면, IP 주소는 더 넓은 범위에서 최종 목적지를 찾기 위해 사용된다.

비유하자면 이렇다.

MAC 주소는 택배 기사가 아파트 단지 안에서 특정 집을 찾는 정보에 가깝고, IP 주소는 택배가 어느 나라, 어느 도시, 어느 동네로 가야 하는지 알려주는 주소에 가깝다.

인터넷에서 데이터를 보낸다는 것은 결국 여러 네트워크를 거쳐 목적지까지 가는 과정이다. 이때 각 네트워크 장비는 IP 주소를 보고 방향을 판단한다.

내 컴퓨터가 외부 서버로 데이터를 보낼 때도 마찬가지다.

내 컴퓨터는 먼저 생각한다.

“목적지 IP가 내 네트워크 안에 있나?” “아니라면 내가 직접 보낼 수 없겠네.” “그러면 일단 밖으로 나가는 장비에게 보내야겠다.”

이때 밖으로 나가는 장비가 보통 라우터이고, 내 컴퓨터 입장에서는 기본 게이트웨이가 된다.

아직 라우터를 깊게 다루지는 않지만, 흐름만 보면 된다.

내 컴퓨터가 외부 네트워크로 가야 한다고 판단하면, 최종 목적지 IP는 외부 서버를 가리키고 있지만, 실제 같은 LAN 안에서 프레임을 넘겨받는 대상은 라우터가 된다.

여기서 중요한 구분이 나온다.

IP 주소는 최종 목적지를 바라보고, MAC 주소는 지금 당장 같은 LAN 안에서 전달할 다음 장비를 바라본다.

IP와 MAC은 경쟁 관계가 아니다

처음에는 IP 주소와 MAC 주소가 둘 다 “주소”라서 헷갈린다.

둘 중 하나만 있으면 되는 것 아닌가 싶기도 하다. 하지만 둘은 역할이 다르다.

외부 서버에 요청을 보낸다고 해보자.

목적지 IP 주소는 외부 서버의 IP 주소다. 이 주소는 데이터가 최종적으로 어디까지 가야 하는지를 나타낸다.

하지만 내 컴퓨터가 그 서버까지 한 번에 프레임을 날릴 수는 없다. 내 컴퓨터가 실제로 직접 통신할 수 있는 범위는 같은 LAN 안이다.

그래서 일단 같은 LAN 안에 있는 라우터에게 프레임을 보내야 한다. 이때 이더넷 프레임의 목적지 MAC 주소는 외부 서버의 MAC 주소가 아니라, 보통 라우터의 MAC 주소가 된다.

정리하면 이런 느낌이다.

“이 IP를 가진 서버까지 가고 싶어.” “그런데 지금 당장은 저 멀리 있는 서버에게 직접 못 보내.” “그러니까 우선 우리 LAN의 출구인 라우터에게 넘기자.” “라우터야, 이 목적지 IP로 가는 길을 찾아줘.”

IP 주소는 목적지를 계속 유지하면서 이동 방향을 잡는 데 사용되고, MAC 주소는 매 구간마다 다음 장비에게 넘겨주기 위해 사용된다.

이걸 도로 여행으로 비유하면, IP 주소는 최종 목적지 주소이고 MAC 주소는 다음 톨게이트나 다음 환승 지점을 통과하기 위한 정보에 가깝다.

인터넷 프로토콜, IP

IP는 Internet Protocol의 약자다.

이름 그대로 인터넷에서 데이터를 목적지까지 보내기 위한 핵심 프로토콜이다. 물론 IP 혼자 모든 것을 해결하지는 않는다.

IP는 기본적으로 “어디에서 어디로 보낼 것인가”에 관심이 있다. 출발지 IP 주소와 목적지 IP 주소를 가지고 패킷이 어느 방향으로 가야 하는지 판단할 수 있게 해준다.

여기서 IP가 하는 일을 너무 거창하게 볼 필요는 없다.

IP는 이런 질문에 답하기 위한 규칙에 가깝다.

“이 패킷의 출발지는 어디인가?” “이 패킷의 최종 목적지는 어디인가?” “목적지 네트워크로 가려면 어느 쪽으로 보내야 하는가?”

스위치가 MAC 주소 테이블을 보고 같은 LAN 안에서 프레임을 전달했다면, 네트워크 계층의 장비는 IP 주소와 경로 정보를 보고 다른 네트워크로 패킷을 전달한다.

IPv4와 IPv6

IP 주소에는 대표적으로 IPv4와 IPv6가 있다.

IPv4는 우리가 흔히 보는 형태의 주소다.

예를 들면 이런 식이다.

192.168.0.10

숫자 4개가 점으로 구분된 형태다. 현재도 매우 널리 사용되고 있다.

하지만 IPv4는 만들 수 있는 주소 개수에 한계가 있다. 인터넷에 연결되는 장비가 폭발적으로 늘어나면서 IPv4 주소만으로는 부족해졌다.

그래서 등장한 것이 IPv6다.

IPv6는 IPv4보다 훨씬 더 많은 주소를 표현할 수 있는 방식이다. 형태도 다르다.

예를 들면 이런 느낌이다.

2001:db8::1

IPv6는 주소 공간을 크게 늘려서 더 많은 장비가 고유한 주소를 가질 수 있도록 만든 방식이다.

다만 지금 단계에서는 IPv4와 IPv6의 구조를 깊게 외우기보다, IP 주소 체계에도 버전이 있고, IPv4의 한계를 보완하기 위해 IPv6가 등장했다 정도로 이해하면 충분할 것 같다.

LAN 안의 이동과 LAN 밖의 이동

지금까지의 흐름을 다시 연결해보면 이렇다.

같은 LAN 안에서는 MAC 주소가 중요했다. 스위치는 MAC 주소를 보고 프레임을 어느 포트로 보낼지 판단했다.

하지만 목적지가 다른 네트워크에 있다면 MAC 주소만으로는 부족하다. 그때는 IP 주소를 보고 최종 목적지가 어디인지 판단해야 한다.

내 컴퓨터 입장에서는 먼저 목적지 IP를 확인한다.

“이 목적지가 내 LAN 안에 있나?” “아니네. 그러면 직접 보낼 수 없겠다.” “기본 게이트웨이에게 보내자.”

그리고 같은 LAN 안에서 게이트웨이에게 프레임을 보내기 위해 MAC 주소가 다시 필요해진다.

여기서 중요한 건, 네트워크 통신은 어느 한 주소만으로 이루어지는 게 아니라는 점이다.

IP 주소는 최종 목적지를 찾기 위한 큰 지도이고, MAC 주소는 현재 구간에서 다음 장비에게 전달하기 위한 지역 안내판에 가깝다.

그래서 인터넷 통신은 이런 식으로 움직인다.

“최종 목적지는 이 IP야.” “지금 구간에서는 이 MAC 주소를 가진 장비에게 넘기자.” “다음 네트워크로 넘어가면 또 그 구간에 맞는 방식으로 넘기자.”

이렇게 보면 IP와 MAC의 역할이 조금 분리되어 보인다.

MAC 주소는 가까운 곳을 향하고, IP 주소는 먼 목적지를 향한다.

LAN 안에서의 통신을 이해했다면, LAN을 넘어가는 순간부터는 IP 주소와 네트워크 계층을 함께 봐야 한다.

지난 글에서는 스위치가 MAC 주소 테이블을 만들고, 목적지 MAC 주소를 기준으로 포워딩, 플러딩, 필터링을 한다는 흐름을 정리했다. 그런데 여기서 한 가지 문제가 생긴다.

스위치에 연결된 장비가 많아지면 어떻게 될까?

처음에는 단순하다.

하나의 스위치에 PC, 노트북, 서버, 프린터가 연결되어 있다. 이 장비들은 모두 같은 네트워크 안에 있다고 볼 수 있다. 그래서 서로 이더넷 프레임을 주고받을 수 있고, 브로드캐스트도 같은 공간 안에서 퍼진다.

그런데 회사 네트워크를 생각해보면 이야기가 조금 달라진다.

개발팀 PC, 인사팀 PC, 게스트용 노트북, 서버 장비가 모두 같은 스위치에 연결되어 있다고 해보자. 물리적으로는 편하다. 케이블을 스위치에 꽂기만 하면 되니까.

하지만 논리적으로도 전부 같은 네트워크에 둬도 괜찮을까?

게스트용 노트북이 사내 서버와 같은 네트워크에 있는 건 조금 찝찝하다. 인사팀 장비와 개발팀 장비가 굳이 같은 브로드캐스트 공간을 공유할 필요도 없다. 트래픽 관리나 보안 정책을 생각하면 네트워크를 나누고 싶어진다.

이때 사용하는 개념이 VLAN이다.

VLAN은 스위치 안에서 네트워크를 논리적으로 나누는 방법이다

VLAN은 Virtual LAN의 줄임말이다.

말 그대로 가상의 LAN이다. 물리적인 스위치는 하나지만, 그 안에서 여러 개의 LAN이 있는 것처럼 나누는 방식이다.

비유하면 하나의 큰 사무실에 칸막이를 세우는 것과 비슷하다.

건물은 하나다. 하지만 칸막이를 기준으로 개발팀 공간, 인사팀 공간, 회의실 공간을 나눌 수 있다. 사람들이 같은 건물 안에 있어도, 각 공간은 어느 정도 분리된 영역처럼 동작한다.

VLAN도 비슷하다.

스위치 하나에 여러 장비가 연결되어 있어도, VLAN을 나누면 장비들은 서로 다른 네트워크에 있는 것처럼 동작한다.

예를 들어 이렇게 나눌 수 있다.

VLAN 10 → 개발팀
VLAN 20 → 인사팀
VLAN 30 → 게스트

이렇게 설정하면 같은 스위치에 연결되어 있어도 VLAN 10에 속한 장비들은 VLAN 10끼리, VLAN 20에 속한 장비들은 VLAN 20끼리 통신하는 식으로 구분된다.

여기서 중요한 건 VLAN이 물리적인 분리가 아니라 논리적인 분리라는 점이다.

스위치를 여러 대 사서 네트워크를 나눌 수도 있지만, VLAN을 사용하면 하나의 스위치 안에서도 네트워크를 나눈 것처럼 구성할 수 있다.

VLAN 하나는 하나의 브로드캐스트 도메인이다

VLAN을 이해할 때 같이 봐야 하는 개념이 브로드캐스트 도메인이다.

브로드캐스트는 같은 네트워크 안의 모든 장비에게 보내는 통신이다.

“이 IP 주소 가진 장비 누구야?” “이 정보를 같은 네트워크 안에 있는 모두에게 알려야 해.”

이런 식의 메시지는 특정 한 명에게만 가는 것이 아니라, 같은 네트워크 안에 있는 장비들에게 퍼진다.

문제는 같은 네트워크에 장비가 많아질수록 브로드캐스트의 영향 범위도 커진다는 것이다. 불필요한 트래픽이 늘어날 수 있고, 네트워크를 관리하기도 어려워진다.

VLAN은 이 브로드캐스트가 퍼지는 범위를 나눠준다.

VLAN 10에서 발생한 브로드캐스트
→ VLAN 10 안에서만 전달됨

VLAN 20에서 발생한 브로드캐스트
→ VLAN 20 안에서만 전달됨

즉, VLAN 하나는 하나의 브로드캐스트 도메인이라고 볼 수 있다.

여기서 중요한 건 스위치가 단순히 “같은 스위치에 꽂혀 있네?”라고 판단하지 않는다는 점이다.

스위치는 프레임을 처리할 때 이렇게 생각한다.

이 프레임은 어느 VLAN에서 들어온 거지?
목적지 MAC 주소는 어디에 있지?
그 목적지가 같은 VLAN 안에 있나?
같은 VLAN이면 전달하고, 다른 VLAN이면 그냥 L2 수준에서는 보내지 않는다.

스위치 입장에서는 MAC 주소만 보는 것이 아니라, VLAN이라는 논리적인 구역도 같이 보는 셈이다.

같은 VLAN끼리는 L2 통신이 가능하다

같은 VLAN에 속한 장비들은 같은 LAN 안에 있는 것처럼 동작한다.

예를 들어 PC A와 PC B가 둘 다 VLAN 10에 속해 있다고 해보자.

PC A → VLAN 10
PC B → VLAN 10

PC A가 PC B에게 이더넷 프레임을 보내면, 스위치는 목적지 MAC 주소를 확인한다. 그리고 MAC 주소 테이블을 보고 PC B가 연결된 포트로 프레임을 전달한다.

이 흐름은 일반적인 스위치의 동작과 크게 다르지 않다.

다만 판단 조건에 VLAN이 추가된다.

출발지: VLAN 10의 PC A
목적지: VLAN 10의 PC B

같은 VLAN이다.
MAC 주소 테이블을 확인한다.
목적지 포트로 포워딩한다.

이 경우에는 라우터가 필요하지 않다. 같은 VLAN 내부에서는 데이터 링크 계층, 즉 L2 수준에서 통신할 수 있다.

다른 VLAN끼리는 바로 통신할 수 없다

이번에는 PC A는 VLAN 10, PC C는 VLAN 20에 있다고 해보자.

PC A → VLAN 10
PC C → VLAN 20

물리적으로는 같은 스위치에 연결되어 있을 수 있다. 하지만 논리적으로는 다른 네트워크에 있는 것처럼 분리되어 있다.

그래서 PC A가 PC C에게 바로 이더넷 프레임을 보낼 수 없다.

스위치 입장에서는 이렇게 판단한다.

출발지: VLAN 10
목적지: VLAN 20

서로 다른 VLAN이다.
L2 스위칭만으로는 전달하지 않는다.

이 부분이 VLAN에서 헷갈리기 쉬운 지점이다.

같은 스위치에 꽂혀 있다고 해서 무조건 통신할 수 있는 게 아니다. VLAN이 다르면 논리적으로 다른 네트워크에 있는 것처럼 취급된다.

그럼 서로 다른 VLAN끼리는 절대 통신할 수 없을까?

그건 아니다. 다만 라우팅이 필요하다.

서로 다른 VLAN 간 통신에는 라우팅이 필요하다

VLAN이 다르다는 것은 네트워크가 나뉘었다는 뜻이다.

그리고 서로 다른 네트워크 사이를 연결하는 역할은 라우터가 한다. 또는 L3 스위치처럼 라우팅 기능을 가진 장비가 처리할 수도 있다.

예를 들어 VLAN을 이렇게 나누었다고 해보자.

VLAN 10 → 192.168.10.0/24
VLAN 20 → 192.168.20.0/24

VLAN 10의 PC가 VLAN 20의 서버와 통신하려면, 단순히 스위치가 MAC 주소를 보고 넘겨주는 것으로는 부족하다.

이때는 네트워크 계층의 판단이 필요하다.

이 목적지는 내 네트워크 밖에 있네.
그러면 기본 게이트웨이로 보내야겠다.
게이트웨이가 라우팅해서 다른 VLAN으로 전달해주겠지.

즉, 같은 VLAN 내부 통신은 L2 스위칭으로 가능하지만, 다른 VLAN 간 통신은 L3 라우팅이 필요하다.

여기서 중요한 건 VLAN이 네트워크를 나누는 역할을 하지만, 나뉜 네트워크를 다시 연결해주는 역할까지 자동으로 해주지는 않는다는 점이다.

VLAN은 분리한다. 라우팅은 연결한다.

이렇게 생각하면 조금 편하다.

Access Port는 하나의 VLAN에 속한 포트다

스위치 포트에는 역할이 있다. 그중 하나가 Access Port다.

Access Port는 보통 하나의 VLAN에 속한 포트다.

일반 PC, 노트북, 프린터 같은 장비를 스위치에 연결할 때 주로 사용한다. 이 장비들은 자신이 VLAN 몇 번에 속하는지 알 필요가 없다.

예를 들어 어떤 포트를 VLAN 10의 Access Port로 설정했다고 해보자.

스위치 1번 포트 → VLAN 10 Access Port

그러면 1번 포트에 연결된 PC는 VLAN 10에 속한 장비처럼 동작한다.

PC 입장에서는 그냥 랜선을 꽂았을 뿐이다. 하지만 스위치는 이렇게 판단한다.

1번 포트로 프레임이 들어왔다.
1번 포트는 VLAN 10에 속해 있다.
그러면 이 프레임은 VLAN 10의 프레임으로 처리해야겠다.

Access Port의 핵심은 단순하다.

연결된 장비에게 VLAN을 의식시키지 않고, 스위치 포트 설정으로 VLAN을 정해주는 방식이다.

Trunk Port는 여러 VLAN의 프레임이 지나가는 포트다

Access Port가 하나의 VLAN만 담당한다면, Trunk Port는 여러 VLAN의 트래픽을 함께 전달하는 포트다.

주로 스위치와 스위치 사이, 또는 스위치와 라우터 사이를 연결할 때 사용한다.

예를 들어 스위치 A와 스위치 B가 있다고 해보자.

스위치 A
- VLAN 10 장비들 연결
- VLAN 20 장비들 연결

스위치 B
- VLAN 10 장비들 연결
- VLAN 20 장비들 연결

두 스위치 사이를 연결해야 한다. 그런데 VLAN 10도 지나가야 하고, VLAN 20도 지나가야 한다.

이때 VLAN마다 케이블을 따로 연결하면 비효율적이다.

VLAN 10용 케이블 하나
VLAN 20용 케이블 하나
VLAN 30용 케이블 하나
...

VLAN이 많아질수록 케이블도 계속 늘어난다.

그래서 Trunk Port를 사용한다.

Trunk Port는 하나의 링크를 통해 여러 VLAN의 프레임을 전달할 수 있게 해준다.

비유하면 Access Port는 특정 팀 전용 출입문이고, Trunk Port는 여러 팀의 물류가 함께 이동하는 공용 통로에 가깝다.

다만 공용 통로를 지나가려면 표시가 필요하다.

“이 박스는 개발팀 거야.” “이 박스는 인사팀 거야.” “이 박스는 게스트망 거야.”

이 표시 역할을 하는 것이 VLAN Tag다.

VLAN Tag는 이 프레임이 어느 VLAN 소속인지 알려준다

Trunk Port에서는 여러 VLAN의 프레임이 함께 지나간다. 그러면 스위치는 프레임을 받을 때 구분할 수 있어야 한다.

이 프레임은 VLAN 10의 프레임인가?
아니면 VLAN 20의 프레임인가?

이때 프레임에 VLAN 정보를 붙인다. 이 정보를 VLAN Tag라고 한다.

VLAN Tag는 프레임이 어느 VLAN에 속하는지 알려주는 표시다.

Access Port로 일반 PC와 통신할 때는 보통 PC가 VLAN Tag를 신경 쓰지 않는다. 스위치가 포트 설정을 보고 VLAN을 판단하면 된다.

하지만 Trunk Port를 지날 때는 이야기가 다르다. 여러 VLAN의 프레임이 같은 링크를 지나가기 때문에, 프레임마다 VLAN 정보를 표시해줘야 한다.

스위치 입장에서는 이렇게 처리한다.

Trunk Port로 프레임이 들어왔다.
VLAN Tag를 확인한다.
아, VLAN 10 프레임이구나.
그럼 VLAN 10 안에서 목적지 MAC 주소를 찾아 전달하자.

여기서 중요한 건 VLAN Tag가 “이 프레임이 어느 논리 네트워크에 속하는지” 알려주는 정보라는 점이다.

스위치는 VLAN을 기준으로 더 좁게 판단한다

VLAN이 없는 환경에서 스위치는 주로 MAC 주소 테이블을 기준으로 판단했다.

목적지 MAC 주소가 어디 포트에 있지?
알면 포워딩
모르면 플러딩
필요 없으면 필터링

VLAN이 추가되면 판단 기준이 조금 더 좁아진다.

이 프레임은 어느 VLAN 소속이지?
그 VLAN 안에서 목적지 MAC 주소가 어디 있지?
같은 VLAN 안에서만 전달하자.

즉, 스위치가 보는 범위가 전체 스위치가 아니라 VLAN 단위로 나뉜다.

예를 들어 목적지 MAC 주소를 모르는 경우에도 모든 포트로 플러딩하지 않는다. 같은 VLAN에 속한 포트들로만 플러딩한다.

VLAN 10에서 목적지 MAC 주소를 모름
→ VLAN 10 포트들로만 플러딩

VLAN 20 포트로는 보내지 않음

이렇게 VLAN은 브로드캐스트나 플러딩의 범위를 제한한다. 그 결과 네트워크를 더 깔끔하게 나눌 수 있고, 불필요한 트래픽이 다른 영역으로 퍼지는 것을 막을 수 있다.

VLAN을 쓰면 물리 구조와 논리 구조를 분리해서 생각할 수 있다

VLAN이 중요한 이유는 물리적인 연결과 논리적인 네트워크 구성을 분리할 수 있기 때문이다.

예전에는 네트워크를 나누려면 물리적으로 장비를 나눠야 한다고 생각하기 쉽다.

개발팀용 스위치
인사팀용 스위치
게스트용 스위치

이런 식으로 말이다.

하지만 VLAN을 사용하면 하나의 스위치 안에서도 논리적으로 네트워크를 나눌 수 있다.

하나의 스위치
├─ VLAN 10 개발팀
├─ VLAN 20 인사팀
└─ VLAN 30 게스트

물리적으로는 같은 장비를 공유하지만, 논리적으로는 서로 다른 네트워크처럼 관리할 수 있다.

이게 VLAN의 핵심이다.

스위치를 단순히 “랜선을 많이 꽂는 장비”로만 보면 VLAN이 잘 와닿지 않는다. 하지만 스위치를 “프레임을 보고 어느 포트로 보낼지 판단하는 장비”로 보면 VLAN이 자연스럽게 붙는다.

스위치는 이제 이렇게 판단한다.

어느 포트에서 들어왔지?
그 포트는 어느 VLAN이지?
목적지 MAC 주소는 같은 VLAN 안에 있나?
Access Port로 내보낼까?
Trunk Port로 보낼 거면 VLAN Tag를 붙여야 하나?
다른 VLAN이면 라우팅이 필요한 상황인가?

VLAN은 스위치의 판단 범위를 나누는 기준이다. 하나의 스위치를 여러 개의 작은 네트워크처럼 사용할 수 있게 해주는 방법이다.

그래서 VLAN을 이해하면 “같은 스위치에 꽂혀 있는데 왜 통신이 안 되지?” 같은 상황도 조금 다르게 보인다.

물리적으로 연결되어 있는지뿐만 아니라, 논리적으로 같은 VLAN에 있는지도 봐야 한다. 그리고 VLAN이 다르다면, 그 사이에 라우팅이 가능한 구조가 있는지도 확인해야 한다.

누가 받아야 하는지 판단하지 않고, 일단 모두에게 보내는 방식이었다. 그래서 같은 네트워크 안에 장비가 많아질수록 불필요한 전달이 많아지고, 충돌 문제도 생길 수 있었다.

스위치는 이 문제를 줄이기 위해 등장한 장비라고 볼 수 있다.

스위치는 같은 LAN 안에서 이더넷 프레임을 전달하는 데이터 링크 계층 장비다. 여기서 중요한 건 스위치가 아무 포트로나 막 보내는 게 아니라, MAC 주소를 보고 어느 포트로 보낼지 판단한다는 점이다.

쉽게 말하면 허브가 “일단 다 불러보는 사람”이라면, 스위치는 “주소록을 보면서 필요한 사람에게만 전달하는 사람”에 가깝다.

스위치가 보는 것

스위치가 이더넷 프레임을 받으면 가장 먼저 프레임 안의 MAC 주소를 본다.

이더넷 프레임에는 출발지 MAC 주소와 목적지 MAC 주소가 들어 있다.

• 출발지 MAC 주소: 이 프레임을 보낸 장비의 주소
• 목적지 MAC 주소: 이 프레임을 받아야 하는 장비의 주소

스위치는 이 두 주소를 같은 방식으로 사용하지 않는다.

출발지 MAC 주소는 학습할 때 사용한다. 목적지 MAC 주소는 어디로 보낼지 판단할 때 사용한다.

이 차이가 꽤 중요하다.

스위치는 프레임을 받자마자 이렇게 생각한다고 보면 된다.

“이 프레임이 1번 포트로 들어왔네?” “출발지 MAC 주소가 AA:AA:AA라고?” “그럼 AA:AA:AA 장비는 1번 포트 쪽에 있구나.”

이렇게 스위치는 출발지 MAC 주소와 들어온 포트 번호를 기억한다.

이 정보를 저장해두는 표가 MAC 주소 테이블이다.

MAC 주소 테이블

MAC 주소 테이블은 스위치가 가지고 있는 일종의 주소록이다.

이 테이블이 있으면 스위치는 프레임을 받을 때마다 모든 포트로 뿌릴 필요가 없다.

예를 들어 목적지 MAC 주소가 BB:BB:BB라면, 스위치는 MAC 주소 테이블을 보고 이렇게 판단한다.

“BB:BB:BB는 2번 포트에 있네.” “그럼 이 프레임은 2번 포트로만 보내면 되겠다.”

이게 스위치가 허브보다 효율적인 이유다.

허브는 모든 포트로 보낸다. 스위치는 알고 있는 목적지라면 해당 포트로만 보낸다.

스위치는 출발지를 보고 학습한다

처음에는 스위치의 MAC 주소 테이블이 비어 있다.

스위치가 처음부터 모든 장비의 MAC 주소를 알고 있는 건 아니다. 프레임이 들어오는 과정을 보면서 하나씩 배운다.

예를 들어 A 컴퓨터가 B 컴퓨터에게 프레임을 보낸다고 해보자.

A의 MAC 주소는 AA:AA:AA이고, A는 스위치의 1번 포트에 연결되어 있다.

스위치가 이 프레임을 1번 포트에서 받으면, 먼저 출발지 MAC 주소를 확인한다.

“AA:AA:AA가 1번 포트로 들어왔네.” “그러면 AA:AA:AA는 1번 포트 쪽에 있구나.”

이렇게 테이블에 기록한다.

여기서 중요한 건 스위치가 목적지 MAC 주소를 보고 학습하는 게 아니라는 점이다. 스위치는 프레임이 들어온 포트와 출발지 MAC 주소를 묶어서 학습한다.

왜냐하면 프레임이 어느 포트에서 들어왔다는 건, 그 포트 방향에 출발지 장비가 있다는 뜻이기 때문이다.

목적지를 알면 포워딩한다

스위치가 목적지 MAC 주소를 이미 알고 있다면, 해당 포트로만 프레임을 보낸다.

이걸 포워딩이라고 한다.

예를 들어 MAC 주소 테이블이 이렇게 되어 있다고 하자.

이번에는 A가 B에게 프레임을 보낸다.

스위치는 프레임을 받으면서 이렇게 판단한다.

“출발지 AA:AA:AA는 1번 포트구나. 이미 알고 있네.” “목적지 BB:BB:BB는 어디 있지?” “테이블을 보니 2번 포트에 있네.” “그럼 2번 포트로만 보내자.”

이게 포워딩이다.

프레임이 필요한 곳으로만 이동하니까 네트워크가 훨씬 조용해진다. 불필요하게 다른 장비들이 프레임을 받을 필요도 줄어든다.

목적지를 모르면 플러딩한다

그런데 스위치가 항상 목적지를 알고 있는 건 아니다.

처음 보는 MAC 주소라면 MAC 주소 테이블에 정보가 없다.

예를 들어 A가 C에게 프레임을 보내려고 한다. 그런데 스위치의 MAC 주소 테이블에는 아직 C의 MAC 주소가 없다.

스위치는 목적지 CC:CC:CC를 찾으려고 테이블을 본다.

“CC:CC:CC가 어디 있지?” “테이블에 없네.” “그럼 어디 있는지 모르니까 일단 다른 포트로 다 보내보자.”

이렇게 들어온 포트를 제외한 나머지 포트로 프레임을 보내는 동작을 플러딩이라고 한다.

플러딩은 허브처럼 무작정 모든 포트로 뿌리는 것과 비슷해 보이지만, 차이가 있다.

허브는 항상 뿌린다. 스위치는 목적지를 모를 때만 뿌린다.

그리고 이후 C가 응답을 보내면, 스위치는 그 프레임의 출발지 MAC 주소를 보고 다시 학습한다.

“CC:CC:CC가 3번 포트에서 들어왔네.” “그러면 C는 3번 포트 쪽에 있구나.”

이제 MAC 주소 테이블은 이렇게 된다.

다음부터 C에게 가는 프레임은 굳이 플러딩하지 않아도 된다. 스위치는 3번 포트로만 보내면 된다.

보낼 필요가 없으면 필터링한다

스위치는 프레임을 무조건 전달하지 않는다.

목적지 MAC 주소를 확인했는데, 그 목적지가 프레임이 들어온 포트와 같은 포트에 있다고 판단하면 굳이 다시 내보낼 필요가 없다.

이런 경우 스위치는 프레임을 버린다. 이 동작을 필터링이라고 한다.

처음에는 조금 이상하게 느껴질 수 있다.

“프레임을 전달하는 장비인데 왜 버리지?”

하지만 스위치 입장에서 생각하면 자연스럽다.

예를 들어 어떤 프레임이 1번 포트로 들어왔다. 그런데 목적지 MAC 주소도 1번 포트 쪽에 있다고 테이블에 기록되어 있다.

그러면 스위치는 이렇게 판단한다.

“이 프레임의 목적지도 1번 포트 쪽에 있네.” “그럼 굳이 다른 포트로 보낼 필요가 없겠다.” “내가 보내면 오히려 불필요한 전달이 되겠네.”

이렇게 불필요한 전달을 막는 것이 필터링이다.

여기서 중요한 건 스위치가 단순히 전달만 하는 장비가 아니라, 전달할지 말지도 판단한다는 점이다.

MAC 주소 테이블은 계속 유지되지 않는다

스위치가 한 번 학습한 MAC 주소를 영원히 기억하면 편할 것 같지만, 실제 네트워크에서는 장비 위치가 바뀔 수 있다.

노트북을 다른 포트에 연결할 수도 있고, 장비가 꺼질 수도 있고, 네트워크 구성이 바뀔 수도 있다.

그래서 스위치는 MAC 주소 테이블의 항목을 일정 시간 동안만 유지한다.

오랫동안 사용되지 않은 항목은 삭제된다. 이 과정을 에이징이라고 한다.

에이징은 오래된 주소록을 정리하는 작업이라고 보면 된다.

예전에 1번 포트에 있던 장비가 지금도 1번 포트에 있다는 보장은 없다. 스위치가 오래된 정보를 계속 믿고 있으면 잘못된 포트로 프레임을 보낼 수 있다.

그래서 스위치는 일정 시간이 지나도록 해당 MAC 주소에서 프레임이 들어오지 않으면 테이블에서 지운다.

그리고 나중에 다시 프레임이 들어오면 새롭게 학습한다.

스위치의 판단 흐름

스위치의 동작을 하나의 흐름으로 정리하면 이렇다.

스위치가 프레임을 받는다.

먼저 출발지 MAC 주소를 본다. 그리고 이 프레임이 들어온 포트와 출발지 MAC 주소를 MAC 주소 테이블에 기록한다.

그 다음 목적지 MAC 주소를 본다.

목적지 MAC 주소가 테이블에 있으면 해당 포트로만 보낸다. 이것이 포워딩이다.

목적지 MAC 주소가 테이블에 없으면 들어온 포트를 제외한 나머지 포트로 보낸다. 이것이 플러딩이다.

목적지가 프레임이 들어온 포트와 같은 포트에 있다고 판단되면 굳이 보내지 않는다. 이것이 필터링이다.

그리고 오래된 MAC 주소 테이블 항목은 시간이 지나면 삭제된다. 이것이 에이징이다.

스위치를 공부할 때는 이 용어들을 따로 외우기보다, 스위치가 프레임을 받았을 때 머릿속으로 어떤 판단을 하는지 따라가보는 게 더 이해하기 좋다.

스위치는 이렇게 생각한다.

“누가 보냈지?” “어느 포트에서 들어왔지?” “그럼 이 MAC 주소는 이 포트에 있다고 기억하자.” “목적지는 어디지?” “알면 그 포트로만 보내고, 모르면 일단 퍼뜨리자.” “보낼 필요가 없으면 보내지 말자.” “오래된 정보는 지우자.”

결국 스위치의 핵심은 MAC 주소 테이블이다.

허브가 신호를 단순히 반복해서 뿌리는 장비였다면, 스위치는 MAC 주소를 학습하고, 그 정보를 바탕으로 프레임의 이동 방향을 결정하는 장비다.

같은 LAN 안에서 프레임이 어디로 가야 하는지 판단하는 것. 이게 스위치가 하는 가장 중요한 일이다.

그런데 여기서 질문이 하나 생긴다.

프레임을 만들었다고 해서 끝일까?

아니다. 프레임은 결국 실제 네트워크 장비를 지나 목적지까지 이동해야 한다. 이때 같은 네트워크 안의 장비들을 연결해주는 대표적인 장비가 있었다.

바로 허브와 스위치다.

지금은 대부분 스위치를 사용하지만, 예전에는 허브도 많이 사용되었다고 한다. 그래서 이번에는 “허브는 왜 사라지고 스위치가 남았을까?”라는 흐름으로 정리해보려고 한다.

허브는 들어온 신호를 모두에게 뿌린다

허브는 물리 계층 장비다.

물리 계층 장비라는 말은, 데이터를 프레임 단위로 해석해서 판단한다기보다는 들어온 신호를 그대로 전달하는 장비에 가깝다는 뜻이다.

예를 들어 컴퓨터 A, B, C, D가 하나의 허브에 연결되어 있다고 해보자.

A가 B에게 데이터를 보내고 싶다.

그러면 A는 허브로 신호를 보낸다. 허브는 그 신호를 보고 이렇게 판단하지 않는다.

“목적지가 B구나. 그러면 B가 연결된 포트로만 보내야겠다.”

허브는 그런 판단을 하지 못한다. 대신 이렇게 동작한다.

“어? 1번 포트로 신호가 들어왔네? 그럼 나머지 포트로 다 뿌려야겠다.”

그래서 A가 B에게 보낸 데이터는 B뿐만 아니라 C와 D에게도 전달된다.

물론 C와 D는 자신에게 온 데이터가 아니라고 판단하고 버릴 수 있다. 하지만 어쨌든 허브 입장에서는 일단 모두에게 보내는 방식이다.

비유하면 허브는 단톡방에 가깝다.

A가 B에게만 말하고 싶어도, 허브 환경에서는 일단 방 안에 있는 모두에게 말이 들린다. B만 그 말을 받아들이고, 나머지는 “내 얘기 아니네” 하고 무시하는 구조다.

허브의 문제는 충돌이다

허브 방식의 가장 큰 문제는 충돌이다.

허브는 들어온 신호를 모든 포트로 뿌린다. 그런데 여러 장비가 동시에 데이터를 보내면 어떻게 될까?

예를 들어 A도 데이터를 보내고, C도 거의 동시에 데이터를 보낸다고 해보자.

허브는 신호를 구분해서 똑똑하게 처리하지 못한다. 결국 같은 통신 공간 안에서 신호들이 서로 부딪힐 수 있다.

이런 충돌을 콜리전이라고 한다.

여기서 중요한 건, 허브에 연결된 장비들이 하나의 충돌 가능 영역을 공유한다는 점이다. 이 영역을 콜리전 도메인이라고 한다.

콜리전 도메인은 말 그대로 충돌이 발생할 수 있는 범위다. 허브에 연결된 장비들이 많아질수록 누군가 동시에 말할 가능성도 커진다. 그러면 충돌도 더 자주 발생한다.

교실에서 모두가 동시에 말하면 아무 말도 제대로 들리지 않는 것과 비슷하다.

한 명이 말할 때는 괜찮다. 두세 명이 동시에 말하기 시작하면 내용이 섞인다. 사람이 많아질수록 “잠깐, 한 명씩 말해!”라는 규칙이 필요해진다.

허브 환경에서도 비슷한 문제가 생긴다.

반이중 통신: 동시에 말하고 듣기 어렵다

허브 환경에서는 기본적으로 반이중 통신이 사용된다.

반이중 통신은 송신과 수신을 모두 할 수는 있지만, 동시에 하지는 못하는 방식이다.

무전기를 생각하면 쉽다.

무전기는 말할 수도 있고 들을 수도 있다. 하지만 내가 말하는 동안에는 상대방 말을 동시에 듣기 어렵다. 그래서 보통 한 사람이 말하고, 끝나면 다른 사람이 말한다.

허브 환경도 이와 비슷하다.

한 장비가 데이터를 보내는 동안 다른 장비가 동시에 데이터를 보내면 충돌이 발생할 수 있다. 그래서 “지금 누가 말하고 있는지”를 신경 써야 한다.

이 구조에서는 네트워크가 커질수록 비효율이 커진다.

장비가 적을 때는 그럭저럭 괜찮을 수 있다. 하지만 장비가 많아지면 기다려야 하는 시간도 늘고, 충돌 가능성도 커지고, 다시 보내야 하는 일도 많아진다.

CSMA/CD: 말하기 전에 듣고, 충돌하면 다시 시도한다

허브 환경에서는 충돌을 줄이기 위한 규칙이 필요했다.

그중 하나가 CSMA/CD다.

이름은 길지만, 흐름만 보면 생각보다 단순하다.

CSMA/CD는 대략 이런 느낌이다.

먼저 장비는 데이터를 보내기 전에 네트워크 상태를 들어본다.

“지금 누가 말하고 있나?”

아무도 말하고 있지 않으면 데이터를 보낸다.

“조용하네. 그럼 내가 보낼게.”

그런데 동시에 다른 장비도 같은 판단을 할 수 있다.

A도 조용하다고 생각해서 보내고, C도 조용하다고 생각해서 보낸다. 그러면 충돌이 발생한다.

충돌을 감지하면 장비들은 전송을 멈추고, 잠깐 기다린 뒤 다시 시도한다.

즉 CSMA/CD는 이런 규칙이다.

“말하기 전에 먼저 들어보고, 아무도 말하지 않으면 말한다. 만약 말이 겹쳐서 충돌이 나면 멈췄다가 나중에 다시 말한다.”

여기서 중요한 건 CSMA/CD가 충돌을 없애는 기술이라기보다는, 충돌이 발생할 수 있는 환경에서 그 충돌을 처리하기 위한 규칙이라는 점이다.

애초에 충돌이 자주 나는 구조라면, 충돌 후 다시 보내는 과정 자체가 낭비가 된다.

스위치가 필요한 이유

허브의 한계는 명확하다.

허브는 목적지를 판단하지 못한다. 들어온 신호를 모든 포트로 뿌린다. 같은 허브에 연결된 장비들이 하나의 콜리전 도메인을 공유한다. 그래서 동시에 데이터를 보내면 충돌이 발생할 수 있다.

이 문제를 해결하기 위해 스위치가 사용된다.

스위치는 허브보다 똑똑하게 동작한다.

허브가 “들어온 건 일단 모두에게 뿌린다”에 가깝다면, 스위치는 “이 프레임을 어느 포트로 보내야 하지?”를 판단하려고 한다.

물론 스위치가 처음부터 모든 목적지를 아는 것은 아니다. 하지만 스위치는 MAC 주소를 기반으로 학습하고, 목적지에 맞는 포트로 프레임을 전달할 수 있다.

이 덕분에 허브처럼 모든 장비에게 무조건 뿌리는 방식보다 훨씬 효율적으로 통신할 수 있다.

비유하면 허브는 전체 방송이고, 스위치는 안내 데스크에 가깝다.

허브는 누군가를 찾을 때 건물 전체에 방송한다.

“B님 계신가요? B님 계신가요?”

반면 스위치는 점점 정보를 기억한다.

“B는 2번 방에 있구나. 다음부터 B에게 가는 건 2번 방으로 보내면 되겠다.”

이 차이가 커진다.

장비가 많아질수록, 통신량이 많아질수록, 모두에게 뿌리는 방식은 부담이 된다. 반대로 목적지를 보고 필요한 곳으로만 보내는 방식은 훨씬 효율적이다.

허브에서 스위치로 넘어간 흐름

결국 허브가 사라지고 스위치가 남은 이유는 단순히 “스위치가 더 최신 장비라서”가 아니다.

네트워크에서 데이터가 많아지고, 연결되는 장비가 많아지면서 허브 방식의 한계가 분명해졌기 때문이다.

허브는 물리 계층에서 신호를 단순히 전달한다. 이 구조에서는 충돌이 발생할 수 있고, 충돌을 처리하기 위해 CSMA/CD 같은 방식이 필요했다.

하지만 스위치는 프레임을 더 효율적으로 전달할 수 있다. 모든 포트로 무작정 뿌리는 것이 아니라, 목적지를 기준으로 어디로 보낼지 판단할 수 있다.

여기서 중요한 건 허브와 스위치의 차이를 단순히 장비 이름으로 외우는 것이 아니라, 네트워크 장비가 데이터를 얼마나 이해하고 판단할 수 있는지의 차이로 보는 것이다.

허브는 신호를 본다. 스위치는 프레임을 보고 판단하려고 한다.

이 관점으로 보면 왜 허브보다 스위치가 현대 LAN에서 더 적합한지 자연스럽게 이해된다. LAN 안에서 프레임을 더 효율적으로 전달하려면, 단순히 모두에게 뿌리는 장비보다 목적지를 보고 전달하는 장비가 필요하기 때문이다.

“내 컴퓨터에서 보낸 데이터는 같은 네트워크 안의 다른 장비를 어떻게 찾아갈까?”

지난 글에서는 0과 1이 전기 신호, 빛 신호, 전파 같은 물리적인 신호로 바뀌어 이동한다는 이야기를 했다. 그런데 신호가 이동할 수 있다는 것만으로는 충분하지 않다.

사람이 말을 할 수 있다고 해서 대화가 바로 되는 건 아니다. 누가 누구에게 말하는지, 말의 형식은 어떤지, 내용이 손상되지는 않았는지 확인하는 규칙이 필요하다.

같은 네트워크 안에서 이런 역할을 해주는 대표적인 기술이 이더넷(Ethernet) 이다.

이더넷은 같은 LAN 안에서 통신하기 위한 규칙이다

이더넷은 현대 유선 LAN에서 가장 널리 쓰이는 네트워크 기술이다.

여기서 LAN은 Local Area Network의 줄임말로, 비교적 가까운 범위 안에서 구성된 네트워크를 말한다. 집, 학교, 회사 사무실처럼 하나의 공간 안에서 여러 장비가 연결된 네트워크를 떠올리면 된다.

내 노트북, 데스크톱, 공유기, 프린터, 서버가 같은 네트워크에 연결되어 있다면, 이 장비들은 LAN 안에 있다고 볼 수 있다.

그런데 같은 LAN 안에 장비가 여러 대 있으면 문제가 생긴다.

“이 데이터는 누구에게 보내는 거지?” “받는 쪽은 이 데이터가 자기 것인지 어떻게 알지?” “전송 중에 데이터가 깨졌는지는 어떻게 확인하지?”

이더넷은 이런 문제를 해결하기 위해 데이터의 형식과 전달 방식을 정해둔 규칙이라고 볼 수 있다.

여기서 중요한 건, 이더넷은 단순히 케이블을 꽂는 기술이 아니라는 점이다. 같은 네트워크 안에서 데이터를 주고받기 위해 어떤 형식으로 포장할지, 누구에게 보낼지, 손상 여부를 어떻게 확인할지까지 포함한 약속이다.

이더넷에서는 데이터를 프레임으로 보낸다

네트워크 계층 구조에서 데이터는 계층을 내려갈수록 각 계층의 목적에 맞게 포장된다.

데이터 링크 계층에서는 데이터를 프레임(Frame) 이라는 단위로 다룬다. 이더넷에서 사용하는 프레임을 이더넷 프레임이라고 한다.

프레임은 택배 상자와 비슷하다.

택배 상자 안에는 실제 물건이 들어 있고, 상자 겉면에는 보내는 사람, 받는 사람, 송장 번호 같은 정보가 붙어 있다. 이더넷 프레임도 비슷하다. 실제 데이터만 덜렁 보내는 게 아니라, 데이터를 전달하기 위해 필요한 정보를 앞뒤에 붙여서 보낸다.

크게 보면 이더넷 프레임은 이렇게 나눌 수 있다.

Header | Payload | Trailer

Header에는 이 프레임을 어디로 보낼지, 누가 보냈는지 같은 정보가 들어간다. Payload에는 실제로 전달하려는 데이터가 들어간다. Trailer에는 데이터가 전송 중에 손상되었는지 확인하기 위한 정보가 들어간다.

즉, 이더넷 프레임은 “실제 데이터”에 “전달을 위한 정보”를 붙인 포장 단위라고 이해하면 된다.

MAC 주소는 같은 네트워크 안에서 장비를 구분하는 주소다

이더넷에서 중요한 주소가 하나 나온다. 바로 MAC 주소다.

MAC 주소는 같은 네트워크 안에서 장비를 식별하기 위한 주소다. 정확히는 네트워크 인터페이스 카드, 즉 NIC에 부여되는 하드웨어 주소에 가깝다.

우리가 흔히 IP 주소를 많이 들어서 네트워크 주소라고 하면 IP부터 떠올리기 쉽다. 하지만 같은 LAN 안에서 실제로 프레임을 전달할 때는 MAC 주소가 중요하게 사용된다.

IP 주소가 “최종적으로 어디에 있는 호스트로 가야 하는가”에 가깝다면, MAC 주소는 “지금 이 LAN 안에서 어떤 장비에게 프레임을 전달해야 하는가”에 가깝다.

비유하자면 IP 주소는 도시와 건물 주소에 가깝고, MAC 주소는 같은 건물 안에서 특정 사람을 찾기 위한 출입증 번호에 가깝다.

물론 이 비유가 완벽한 건 아니지만, 지금 단계에서는 이렇게 구분해두면 좋다.

IP는 네트워크를 넘어 목적지를 찾아갈 때 중요하고, MAC은 같은 네트워크 안에서 실제 장비를 구분할 때 중요하다.

이더넷 프레임 안에는 출발지와 목적지 MAC 주소가 들어간다

이더넷 프레임의 Header에는 대표적으로 두 가지 MAC 주소가 들어간다.

목적지 MAC 주소
출발지 MAC 주소

목적지 MAC 주소는 이 프레임을 받을 장비의 MAC 주소다. 출발지 MAC 주소는 이 프레임을 보낸 장비의 MAC 주소다.

장비 입장에서 프레임을 받으면 먼저 이런 식으로 생각할 수 있다.

프레임이 들어왔다.
목적지 MAC 주소를 확인한다.
이 MAC 주소가 내 MAC 주소인가?
맞으면 위 계층으로 넘긴다.
아니면 버린다.

즉, 같은 LAN 안에서 장비들은 흘러들어오는 프레임을 무조건 다 처리하지 않는다. 프레임 안의 목적지 MAC 주소를 보고 “이게 나한테 온 건가?”를 판단한다.

여기서 중요한 건, 이더넷은 같은 네트워크 안에서 데이터를 아무렇게나 흘려보내는 방식이 아니라는 점이다. 프레임 안에 목적지와 출발지 정보를 넣고, 장비는 그 정보를 기준으로 자신이 처리할 프레임인지 판단한다.

Payload에는 실제 데이터가 들어간다

Header가 배송 정보라면, Payload는 실제 내용물이다.

예를 들어 웹 요청을 보낸다고 해보자. 브라우저에서 만든 HTTP 요청 데이터는 여러 계층을 거치면서 포장된다. 그리고 데이터 링크 계층까지 내려오면 이더넷 프레임의 Payload 안에 들어간다.

이더넷 입장에서는 Payload 안에 HTTP가 들어 있는지, TCP가 들어 있는지, IP가 들어 있는지 자세한 내용까지 신경 쓰지 않는다.

이더넷의 관심사는 이것이다.

이 프레임을 같은 LAN 안에서 누구에게 전달할 것인가?
프레임이 깨지지 않았는가?

각 계층은 자기 역할에 집중한다. 이더넷은 데이터 링크 계층의 기술이기 때문에, 같은 네트워크 안에서 프레임을 전달하는 데 집중한다.

Trailer와 FCS는 프레임이 깨졌는지 확인한다

이더넷 프레임의 뒤쪽에는 Trailer가 붙는다. 여기에는 대표적으로 FCS(Frame Check Sequence) 라는 값이 들어간다.

FCS는 프레임이 전송 중에 손상되었는지 확인하기 위한 값이다.

네트워크를 통해 데이터가 이동하다 보면 신호 간섭이나 여러 이유로 데이터가 깨질 수 있다. 받는 장비는 프레임을 받았을 때 FCS를 확인해서 “이 프레임이 정상적으로 도착했는지” 검사한다.

흐름을 단순하게 보면 이렇다.

송신 측:
프레임 내용을 바탕으로 FCS 값을 계산한다.
프레임 뒤에 FCS를 붙여 보낸다.

수신 측:
받은 프레임 내용을 다시 계산한다.
프레임에 붙어 있던 FCS 값과 비교한다.
값이 맞으면 정상으로 판단한다.
값이 다르면 손상된 프레임으로 보고 버린다.

여기서 중요한 건, FCS가 데이터를 복구해주는 장치는 아니라는 점이다. FCS는 “깨졌는지 확인”하는 역할에 가깝다.

깨진 프레임을 고쳐서 다시 살리는 것이 아니라, 문제가 있다고 판단되면 해당 프레임을 버린다. 그 이후 다시 보낼지 말지는 더 위 계층의 프로토콜이 담당할 수 있다.

같은 LAN 안에서 프레임이 이동하는 흐름

이제 내 컴퓨터가 같은 네트워크 안의 다른 장비에게 데이터를 보낸다고 생각해보자.

내 컴퓨터는 먼저 데이터를 이더넷 프레임으로 포장한다.

목적지 MAC 주소: 받는 장비의 MAC 주소
출발지 MAC 주소: 내 컴퓨터의 MAC 주소
Payload: 실제로 보내려는 데이터
FCS: 오류 확인용 값

그다음 NIC를 통해 이 프레임을 신호로 바꿔 네트워크로 내보낸다.

받는 쪽 장비는 프레임을 수신한 뒤 목적지 MAC 주소를 확인한다.

목적지 MAC 주소가 나인가?
맞다 → Payload를 위 계층으로 넘긴다.
아니다 → 이 프레임은 내가 처리할 게 아니라고 판단한다.

그리고 FCS를 통해 프레임이 손상되지 않았는지도 확인한다.

이 과정을 보면 이더넷이 하는 일이 조금 더 선명해진다.

이더넷은 같은 LAN 안에서 데이터를 보내기 위해, 데이터를 프레임이라는 형식으로 포장한다. 그리고 그 프레임 안에 MAC 주소와 오류 확인 정보를 넣어, 장비들이 데이터를 올바르게 주고받을 수 있게 한다.

처음에는 네트워크 통신을 “그냥 데이터가 간다” 정도로 생각하기 쉽다. 하지만 실제로는 데이터가 그냥 이동하는 게 아니다.

같은 LAN 안에서도 데이터는 이더넷 프레임이라는 형식으로 포장된다. 프레임 안에는 목적지 MAC 주소, 출발지 MAC 주소, 실제 데이터, 오류 확인 정보가 들어간다.

장비는 프레임을 받으면 목적지 MAC 주소를 보고 자신이 처리할 데이터인지 판단한다. 그리고 FCS를 통해 전송 중에 프레임이 손상되지는 않았는지 확인한다.

여기까지 이해하면 “같은 네트워크 안에서 데이터를 주고받는다”는 말이 조금 더 구체적으로 보인다.

단순히 케이블을 타고 신호가 흐르는 것이 아니라, 정해진 형식의 프레임이 이동하고, 그 안의 주소 정보를 보고 장비들이 판단하며, 오류 확인까지 거쳐 데이터가 다음 단계로 넘어가는 것이다.

그런데 한 가지 의문이 남는다.

컴퓨터 안에서 데이터는 결국 0과 1이다. 그렇다면 이 0과 1은 실제 네트워크 선을 타고 어떻게 이동할까?

여기서 등장하는 계층이 물리 계층이다.

물리 계층은 무엇을 담당할까

물리 계층은 아주 단순하게 말하면,

0과 1로 된 데이터를 실제 신호로 바꾸어 전달하는 계층

이라고 볼 수 있다.

컴퓨터 내부에서는 데이터를 비트, 즉 0과 1로 다룬다. 하지만 0과 1이라는 숫자 자체가 케이블을 타고 이동하는 것은 아니다.

실제 네트워크에서는 이 비트들이 상황에 따라 다른 형태의 신호로 바뀐다.

유선 케이블에서는 전기 신호가 될 수 있고, 광케이블에서는 빛 신호가 될 수 있고, 무선 네트워크에서는 전파가 될 수 있다.

즉, 물리 계층의 관심사는 이런 것이다.

이 0과 1을 어떤 신호로 바꿔서 보낼 것인가? 그리고 받은 신호를 다시 어떻게 0과 1로 해석할 것인가?

여기서 중요한 건 물리 계층은 데이터의 의미를 해석하지 않는다는 점이다. 이 데이터가 HTTP 요청인지, IP 패킷인지, MAC 주소가 무엇인지는 물리 계층의 관심사가 아니다.

물리 계층은 그저 “신호가 잘 이동할 수 있게 하는 것”에 집중한다.

0과 1을 신호로 바꾼다는 것

0과 1을 신호로 바꾼다는 말을 처음 들으면 조금 추상적으로 느껴진다.

그래서 아주 단순하게 생각해보면 좋다.

예를 들어 전기 신호를 사용한다고 해보자.

전압이 높은 상태를 1로 보고, 전압이 낮은 상태를 0으로 볼 수 있다.

그러면 1011이라는 데이터는 실제 선 위에서 이런 식으로 표현될 수 있다.

높음 → 낮음 → 높음 → 높음

물론 실제 네트워크 장비는 이것보다 훨씬 복잡한 방식으로 신호를 처리한다. 하지만 큰 그림은 이 정도로 잡아도 된다.

컴퓨터는 숫자 0과 1을 그대로 던지는 것이 아니라, 그 0과 1을 물리적인 신호 패턴으로 바꾸어 보낸다.

받는 쪽 장비는 반대로 동작한다.

“지금 들어온 신호는 높은 상태네? 그럼 1로 해석하자.” “이번 신호는 낮은 상태네? 그럼 0으로 해석하자.”

이런 식으로 신호를 다시 비트로 복원한다.

결국 네트워크 통신은 추상적으로 보면 데이터 이동이지만, 바닥까지 내려가면 신호의 이동이다.

유선 통신 매체

유선 통신은 말 그대로 선을 통해 신호를 전달하는 방식이다.

가장 흔하게 떠올릴 수 있는 것은 랜선이다. 보통 이더넷 케이블이라고 부르는 케이블을 사용해서 PC, 스위치, 라우터 같은 장비를 연결한다.

유선 통신에서는 주로 전기 신호가 케이블을 따라 이동한다. 그래서 케이블의 상태, 연결 여부, 케이블 종류, 포트 상태 같은 것들이 중요해진다.

개발자나 DevOps 관점에서도 이 부분은 완전히 남의 일이 아니다.

서버는 정상인데 접속이 안 된다. 서비스 프로세스도 살아 있고, 포트도 열려 있다. 그런데 알고 보니 랜선이 빠져 있거나, 스위치 포트가 죽어 있거나, 링크가 올라오지 않은 상태일 수도 있다.

이런 문제는 애플리케이션 로그를 아무리 봐도 나오지 않는다. 왜냐하면 애플리케이션까지 데이터가 도달하지 못했기 때문이다.

여기서 중요한 건 “네트워크 문제”가 항상 IP, DNS, 방화벽 같은 논리적인 문제만은 아니라는 점이다. 가끔은 정말 물리적으로 연결이 안 되어 있는 문제일 수 있다.

케이블 종류는 어느 정도만 알면 될까

케이블 종류를 깊게 파고들면 굉장히 많은 내용이 나온다. UTP, STP, Cat5e, Cat6, Cat6A, 광케이블 같은 용어들이 있다.

하지만 지금 단계에서는 모든 케이블 스펙을 외울 필요는 없다고 생각한다.

일단은 이렇게만 구분해도 충분하다.

랜선처럼 전기 신호를 사용하는 케이블이 있고, 광케이블처럼 빛 신호를 사용하는 케이블이 있다.

전기 신호 기반 케이블은 일반적인 사무실, 가정, 서버 장비 연결에서 많이 볼 수 있다. 광케이블은 더 먼 거리나 더 높은 대역폭이 필요한 환경에서 자주 사용된다.

DevOps나 백엔드 개발자 입장에서는 케이블의 세부 구조보다 이런 감각이 더 중요하다.

지금 장비와 장비 사이에 링크가 정상적으로 올라와 있는가? 물리 포트가 살아 있는가? 케이블이나 NIC 문제는 아닌가?

즉, 케이블을 전기공학적으로 이해하기보다는 네트워크 장애를 볼 때 물리 계층도 의심할 수 있어야 한다.

무선 통신 매체

유선이 케이블을 사용한다면, 무선은 공기를 매체로 사용한다.

와이파이를 생각하면 된다. 노트북이나 스마트폰은 랜선 없이도 공유기와 통신할 수 있다. 이때 데이터는 전파 형태로 이동한다.

여기서도 본질은 같다.

컴퓨터 내부의 0과 1이 무선 장비를 통해 전파 신호로 바뀌고, 상대 장비는 그 전파 신호를 다시 0과 1로 해석한다.

다만 무선은 유선보다 주변 환경의 영향을 많이 받는다.

거리가 멀어지거나, 벽이 있거나, 주변에 같은 주파수 대역을 쓰는 장비가 많으면 통신 품질이 나빠질 수 있다.

유선은 “선이 제대로 꽂혀 있는가?”가 중요하다면, 무선은 “신호가 충분히 잘 닿고 있는가?”가 중요하다.

그래서 무선 네트워크 문제를 볼 때는 단순히 인터넷이 되냐 안 되냐만 볼 것이 아니라, 신호 세기, 간섭, AP와의 거리 같은 요소도 함께 봐야 한다.

NIC는 컴퓨터와 네트워크 사이의 입구다

NIC는 Network Interface Card의 줄임말이다. 보통 네트워크 인터페이스 카드라고 부른다.

말이 조금 어렵지만, 역할은 단순하다.

컴퓨터가 네트워크에 연결되기 위한 출입구

라고 보면 된다.

우리가 랜선을 꽂는 포트, 와이파이에 연결되는 무선 어댑터도 넓게 보면 네트워크 인터페이스다.

컴퓨터 안의 데이터는 그냥 바로 네트워크로 나갈 수 없다. 네트워크로 나가려면 데이터를 신호로 바꿔줄 장치가 필요하다.

그 역할을 하는 것이 NIC다.

송신할 때 NIC는 컴퓨터가 만든 0과 1을 실제 통신 매체에 맞는 신호로 바꾼다. 수신할 때는 반대로 외부에서 들어온 신호를 다시 0과 1로 바꿔 컴퓨터가 이해할 수 있게 넘겨준다.

장비 입장에서 시뮬레이션하듯 보면 이런 느낌이다.

컴퓨터가 데이터를 보낸다.

“이 데이터를 네트워크로 내보내야 하네.” “내가 연결된 매체는 유선이니까 전기 신호로 바꿔서 보내자.” “상대 쪽에서 신호를 해석할 수 있도록 정해진 방식에 맞춰 내보내자.”

반대로 데이터를 받을 때는 이렇게 동작한다.

“포트로 신호가 들어왔다.” “이 신호 패턴을 0과 1로 해석하자.” “해석한 비트들을 위 계층으로 넘기자.”

이렇게 보면 NIC는 단순한 부품이 아니라, 컴퓨터와 네트워크 세계를 이어주는 번역기 같은 역할을 한다.

물리 계층을 왜 알아야 할까

처음 네트워크를 공부하면 IP 주소, 포트, DNS, HTTP 같은 개념이 더 눈에 들어온다. 실제로 개발할 때 자주 만나는 것도 이런 개념들이다.

하지만 그 모든 통신은 결국 물리 계층 위에서 동작한다.

아무리 IP 주소가 맞고, 포트가 열려 있고, 서버 프로세스가 정상이어도 물리적으로 신호가 이동할 수 없다면 통신은 실패한다.

그래서 장애를 볼 때는 이런 순서도 떠올릴 수 있어야 한다.

“애플리케이션 문제인가?” “포트 문제인가?” “IP 경로 문제인가?” “그 전에 링크는 정상인가?” “케이블, NIC, 스위치 포트는 살아 있는가?”

물리 계층은 평소에는 잘 보이지 않는다. 하지만 문제가 생기면 가장 먼저 확인해야 하는 영역이 되기도 한다.

네트워크를 공부한다는 건 단순히 위쪽의 HTTP 요청과 응답만 보는 것이 아니라, 그 요청과 응답이 실제로 어떤 신호가 되어 이동하는지까지 내려가 보는 일이다.

결국 물리 계층은 네트워크의 가장 아래에 있는 계층이지만, 모든 통신이 시작되는 출발점이기도 하다.

브라우저에서 서버로 요청을 보낸다고 할 때, 그 안에는 단순히 “데이터를 보낸다”는 말로 끝나지 않는 여러 단계가 숨어 있다. 웹에서는 HTTP가 필요하고, 데이터를 잘게 나누고 순서를 맞추는 데는 TCP가 관여하고, 목적지까지 찾아가는 데는 IP가 필요하고, 실제 같은 네트워크 안에서 장비끼리 주고받을 때는 이더넷 같은 규칙이 필요하다.

문제는 이걸 전부 한 번에 이해하려고 하면 머릿속이 너무 복잡해진다는 것이다.

그래서 네트워크는 보통 계층 구조로 나누어 이해한다.

네트워크를 계층으로 나누는 이유

계층 구조는 쉽게 말하면 역할 분담이다.

택배를 보낼 때를 생각해보면, 내가 직접 물류센터 위치를 계산하고, 배송 트럭을 고르고, 도로 상황을 판단하고, 받는 사람 집 앞까지 찾아가지는 않는다.

나는 물건을 포장하고 주소를 적는다. 택배사는 배송 경로를 정한다. 기사님은 실제로 물건을 이동시킨다. 받는 사람은 포장을 뜯고 내용물을 확인한다.

각 단계마다 관심사가 다르다.

네트워크도 비슷하다.

애플리케이션은 “무슨 요청을 보낼까?”에 관심이 있고, 전송 계층은 “이 데이터를 어떻게 안정적으로 전달할까?”에 관심이 있고, 네트워크 계층은 “어느 목적지까지 보내야 할까?”에 관심이 있고, 데이터 링크 계층은 “지금 연결된 네트워크 안에서 다음 장비에게 어떻게 넘길까?”에 관심이 있고, 물리 계층은 “0과 1을 어떤 신호로 바꿔 보낼까?”에 관심이 있다.

여기서 중요한 건, 각 계층은 자기 역할에 집중한다는 점이다.

HTTP가 케이블의 전기 신호까지 신경 쓰지 않고, IP가 웹 요청의 의미까지 해석하지 않는다. 각자 맡은 일을 하고, 아래 계층 또는 위 계층에 넘겨준다.

OSI 7계층은 왜 나올까

네트워크를 설명할 때 가장 자주 등장하는 모델이 OSI 7계층이다.

OSI 7계층은 네트워크 통신을 7개의 역할로 나누어 설명하는 모델이다.

위에서부터 보면 대략 이런 흐름이다.

• 애플리케이션 계층
• 표현 계층
• 세션 계층
• 전송 계층
• 네트워크 계층
• 데이터 링크 계층
• 물리 계층

처음 보면 외워야 할 표처럼 느껴진다. 나도 처음에는 “응표세전네데물” 같은 식으로 외우는 게 먼저 떠올랐다.

그런데 지금 단계에서 중요한 건 이름을 줄줄 외우는 게 아니다.

중요한 건 패킷이 이동할 때 각 계층이 어떤 역할을 맡는지다.

웹 요청을 예로 들면, 애플리케이션 계층에서는 HTTP 요청이 만들어진다. 전송 계층에서는 이 데이터를 어느 프로그램으로 보낼지, 어떻게 전달할지 다룬다. 네트워크 계층에서는 목적지 IP를 보고 어느 네트워크로 갈지 판단한다. 데이터 링크 계층에서는 같은 네트워크 안에서 다음 장비로 보내기 위한 정보를 붙인다. 물리 계층에서는 결국 이 데이터를 전기 신호, 빛 신호, 전파 같은 형태로 바꿔 보낸다.

즉 OSI 7계층은 실제 장비나 코드가 반드시 딱 7개로 나뉘어 동작한다는 뜻이라기보다, 복잡한 네트워크 통신을 역할별로 나누어 보기 위한 설명 도구에 가깝다.

TCP/IP 4계층은 더 현실적인 모델이다

실제 인터넷 통신을 설명할 때는 TCP/IP 4계층도 많이 사용한다.

TCP/IP 4계층은 보통 이렇게 나눈다.

• 애플리케이션 계층
• 전송 계층
• 인터넷 계층
• 네트워크 액세스 계층

OSI 7계층보다 덜 세분화되어 있다.

OSI의 애플리케이션, 표현, 세션 계층을 TCP/IP에서는 애플리케이션 계층으로 묶어서 보는 식이다. 그리고 데이터 링크 계층과 물리 계층도 네트워크 액세스 계층으로 묶어 설명하기도 한다.

개발자 입장에서는 TCP/IP 4계층이 더 현실적으로 느껴질 때가 많다.

예를 들어 웹 요청을 보낼 때 머릿속으로는 이렇게 생각할 수 있다.

“HTTP 요청이 만들어지고, TCP가 전달 방식을 잡고, IP가 목적지를 찾고, 이더넷이나 와이파이를 통해 실제 네트워크로 나간다.”

이 정도 흐름이 잡히면, 네트워크 문제를 볼 때도 어디쯤에서 문제가 생겼는지 나누어 생각할 수 있다.

HTTP 응답 코드 문제인지, TCP 연결 문제인지, IP 라우팅 문제인지, 같은 네트워크 안에서 전달이 안 되는 문제인지, 아니면 아예 물리적으로 연결이 안 된 문제인지 구분할 수 있게 된다.

캡슐화: 데이터를 아래로 내려보내며 포장하기

계층 구조에서 핵심이 되는 개념이 캡슐화다.

캡슐화는 데이터를 아래 계층으로 내려보내면서, 각 계층이 자기 역할에 필요한 정보를 헤더로 붙이는 과정이다.

처음에는 애플리케이션에서 보낼 데이터가 있다.

예를 들어 브라우저가 서버에 이런 요청을 만든다고 해보자.

GET /index.html

이 데이터는 먼저 애플리케이션 계층의 데이터다. 하지만 이 데이터만 덜렁 보내면 네트워크는 처리할 수 없다.

받는 서버의 어떤 프로그램으로 보내야 하는지, 목적지 컴퓨터는 어디인지, 같은 네트워크 안에서 다음 장비는 누구인지, 실제로 신호로 어떻게 보낼지에 대한 정보가 필요하다.

그래서 아래 계층으로 내려가면서 포장이 계속 추가된다.

전송 계층에서는 TCP 헤더가 붙는다. 여기에는 출발지 포트, 목적지 포트 같은 정보가 들어간다.

네트워크 계층에서는 IP 헤더가 붙는다. 여기에는 출발지 IP, 목적지 IP 같은 정보가 들어간다.

데이터 링크 계층에서는 이더넷 헤더와 트레일러가 붙는다. 여기에는 같은 네트워크 안에서 다음 장비에게 전달하기 위한 MAC 주소 정보 등이 들어간다.

비유하면 이런 느낌이다.

처음 데이터는 편지 내용이다. TCP는 “어느 방, 어느 담당자에게 전달할지” 적는 과정이고, IP는 “어느 건물, 어느 지역으로 보낼지” 적는 과정이고, 이더넷은 “지금 이 구간에서 다음 배달 지점은 어디인지” 붙이는 과정이다.

계층을 내려갈수록 데이터는 점점 더 여러 겹으로 포장된다.

[HTTP 데이터]

[TCP 헤더 [HTTP 데이터]]

[IP 헤더 [TCP 헤더 [HTTP 데이터]]]

[이더넷 헤더 [IP 헤더 [TCP 헤더 [HTTP 데이터]]] 이더넷 트레일러]

여기서 중요한 건, 각 계층은 위에서 내려온 데이터를 자신의 payload처럼 본다는 점이다.

TCP 입장에서는 HTTP 데이터가 payload다. IP 입장에서는 TCP 헤더와 HTTP 데이터 전체가 payload다. 이더넷 입장에서는 IP 헤더부터 그 안의 데이터 전체가 payload다.

즉, 아래 계층으로 갈수록 이전 계층의 데이터 전체를 감싸는 구조가 된다.

역캡슐화: 받은 쪽에서 포장을 하나씩 뜯기

데이터를 받는 쪽에서는 반대 과정이 일어난다.

이 과정을 역캡슐화라고 한다.

수신 측 장비는 물리 계층에서 신호를 0과 1의 데이터로 해석한다. 그다음 데이터 링크 계층에서 이더넷 헤더를 확인한다.

“이 프레임이 나에게 온 게 맞나?” “오류는 없나?” “그다음에는 위의 어떤 프로토콜로 넘겨야 하나?”

이런 판단을 한 뒤, 데이터 링크 계층의 헤더와 트레일러를 제거하고 위로 넘긴다.

네트워크 계층에서는 IP 헤더를 확인한다.

“목적지 IP가 나인가?” “위로는 TCP에게 넘기면 되나?”

이런 식으로 확인하고 IP 헤더를 제거한다.

전송 계층에서는 TCP 헤더를 확인한다.

“이 데이터는 몇 번 포트로 가야 하지?” “순서는 맞나?” “어느 애플리케이션으로 넘겨야 하지?”

그다음 TCP 헤더를 제거하고 애플리케이션으로 넘긴다.

마지막으로 애플리케이션은 HTTP 요청 내용을 해석한다.

즉, 보내는 쪽에서는 헤더를 하나씩 붙이고, 받는 쪽에서는 헤더를 하나씩 확인한 뒤 제거한다.

네트워크 장비 입장에서 보면 이런 시뮬레이션처럼 생각할 수 있다.

“일단 이더넷 헤더를 보자. 이 프레임을 내가 처리해야 하나?” “맞다면 안쪽의 IP 패킷을 확인하자. 목적지 IP는 어디지?” “내가 최종 목적지라면 TCP 정보를 확인하자. 몇 번 포트로 넘겨야 하지?” “이제 애플리케이션에게 실제 데이터를 넘기자.”

이 흐름이 잡히면 캡슐화와 역캡슐화가 단순한 암기 용어가 아니라, 실제 데이터가 이동하는 방식으로 보이기 시작한다.

PDU: 계층마다 데이터를 부르는 이름

네트워크를 공부하다 보면 PDU라는 말도 나온다.

PDU는 Protocol Data Unit의 약자다. 쉽게 말하면, 각 계층에서 다루는 데이터 단위를 의미한다.

같은 데이터라도 어느 계층에서 바라보느냐에 따라 이름이 달라진다.

전송 계층에서는 보통 세그먼트라고 부르고, 네트워크 계층에서는 패킷이라고 부르고, 데이터 링크 계층에서는 프레임이라고 부른다. 물리 계층에서는 비트 단위로 다룬다.

처음에는 이 용어들이 헷갈린다.

“패킷이라고 했다가, 세그먼트라고 했다가, 프레임이라고 했다가 왜 이름이 계속 바뀌지?”

이건 데이터 자체가 완전히 다른 것이 되었다기보다, 어느 계층의 관점에서 보고 있느냐가 달라졌기 때문이다.

전송 계층이 TCP 헤더를 붙여서 바라보면 세그먼트다. 네트워크 계층이 IP 헤더를 붙여서 바라보면 패킷이다. 데이터 링크 계층이 이더넷 헤더와 트레일러를 붙여서 바라보면 프레임이다.

비유하면 같은 물건이라도 상황에 따라 이름이 달라지는 것과 비슷하다.

내가 물건을 살 때는 상품이고, 상자에 담겨 배송되면 택배이고, 물류센터에서는 화물이고, 받는 사람 입장에서는 주문한 물건이다.

대상은 이어져 있지만, 보는 위치와 역할이 다르기 때문에 이름이 달라진다.

계층 구조를 알면 흐름이 보인다

지금까지의 내용을 하나의 흐름으로 다시 보면 이렇다.

클라이언트가 서버에 요청을 보내려고 한다. 애플리케이션 계층에서 HTTP 요청 데이터가 만들어진다. 전송 계층에서 TCP 헤더가 붙는다. 네트워크 계층에서 IP 헤더가 붙는다. 데이터 링크 계층에서 이더넷 헤더와 트레일러가 붙는다. 물리 계층에서 이 데이터는 신호로 바뀌어 네트워크를 타고 이동한다.

서버 쪽에서는 반대로 진행된다.

신호를 데이터로 해석하고, 프레임을 확인하고, IP 패킷을 확인하고, TCP 세그먼트를 확인하고, 마지막으로 HTTP 요청 내용을 애플리케이션이 읽는다.

여기서 중요한 건, 네트워크 통신을 하나의 덩어리로 보면 너무 복잡하지만, 계층으로 나누면 각 단계의 역할이 보인다는 점이다.

“요청이 서버로 간다”는 말 안에는 사실 여러 계층의 포장과 해석 과정이 들어 있다. 캡슐화는 보내는 쪽에서 포장하는 과정이고, 역캡슐화는 받는 쪽에서 포장을 뜯고 해석하는 과정이다.

이 관점이 생기면 앞으로 MAC 주소, IP 주소, 포트, TCP, HTTP 같은 개념을 볼 때도 조금 덜 흩어져 보인다. 각 개념이 어느 계층에서 어떤 판단을 하기 위해 필요한지 연결해서 볼 수 있기 때문이다.

그런데 여기서 한 가지 의문이 생긴다.

클라이언트와 서버가 서로 메시지를 주고받는다고 했는데, 그 둘은 어떤 방식으로 대화하는 걸까?

사람끼리도 대화하려면 같은 언어를 써야 한다. 한국어를 쓰는 사람에게 갑자기 프랑스어로 말하면 대화가 잘 이어지지 않는다. 말의 순서, 표현 방식, 질문과 답변의 형식도 어느 정도 맞아야 한다.

컴퓨터 통신도 마찬가지다.

클라이언트가 서버에 요청을 보낼 때, 그냥 아무렇게나 데이터를 던지는 것이 아니다. 서버가 이해할 수 있는 형식으로 보내야 하고, 서버도 클라이언트가 이해할 수 있는 형식으로 응답해야 한다.

이때 필요한 규칙이 프로토콜이다.

프로토콜은 통신을 위한 약속이다

프로토콜은 쉽게 말해 메시지를 주고받기 위한 약속이다.

어떤 형식으로 보낼지, 어떤 순서로 주고받을지, 어떤 의미로 해석할지, 문제가 생기면 어떻게 처리할지에 대한 규칙이라고 볼 수 있다.

웹에서 자주 듣는 HTTP도 프로토콜이다. 브라우저와 웹 서버가 요청과 응답을 주고받기 위한 약속이다.

예를 들어 브라우저가 서버에게 이렇게 말한다고 생각해볼 수 있다.

“나 이 페이지 보고 싶어.”

하지만 실제 네트워크에서는 이렇게 자연어로 말하지 않는다. HTTP라는 약속에 맞춰 요청 메시지를 만든다. 서버도 그 약속을 보고 “아, 이 클라이언트가 어떤 자원을 요청했구나” 하고 판단한다.

여기서 중요한 건, 프로토콜은 하나만 있는 게 아니라는 점이다.

웹 통신을 할 때는 HTTP만 쓰이는 것이 아니다. 도메인 이름을 IP 주소로 바꾸기 위해 DNS가 필요하고, 데이터를 상대방 프로그램까지 전달하기 위해 TCP가 쓰일 수 있고, 목적지 컴퓨터까지 찾아가기 위해 IP가 사용된다.

아직 각각을 깊게 이해할 필요는 없다. 지금은 이렇게만 잡고 가면 된다.

네트워크 통신은 여러 프로토콜이 각자 맡은 역할을 수행하면서 이루어진다.

HTTP는 웹 요청과 응답의 규칙, DNS는 도메인 이름을 IP 주소로 찾기 위한 규칙, TCP는 데이터를 안정적으로 주고받기 위한 규칙, IP는 목적지까지 데이터를 보내기 위한 규칙에 가깝다.

물론 이 설명은 아직 거칠다. 하지만 지금 단계에서는 “통신에는 역할별 규칙이 여러 개 필요하다” 정도로 이해하면 충분하다.

데이터를 통째로 보내지 않는 이유

이제 메시지를 보내는 방식으로 넘어가 보자.

클라이언트가 서버에 요청을 보낸다고 할 때, 우리는 보통 하나의 요청이 그대로 서버까지 이동한다고 상상하기 쉽다.

마치 택배 상자 하나를 통째로 보내는 느낌이다.

하지만 실제 컴퓨터 네트워크에서는 큰 데이터를 그대로 한 번에 보내기보다, 작은 조각으로 나누어 보내는 방식이 일반적이다.

이 작은 조각을 패킷이라고 한다.

패킷은 네트워크에서 데이터를 주고받기 위해 나눈 작은 데이터 단위라고 볼 수 있다.

예를 들어 큰 파일 하나를 보낸다고 생각해보자. 그 파일을 통째로 하나의 덩어리로 보내면 중간에 문제가 생겼을 때 부담이 크다. 전송 중간에 오류가 나면 큰 덩어리 전체를 다시 보내야 할 수도 있다.

반면 작은 조각으로 나누어 보내면, 일부 조각에 문제가 생겼을 때 그 부분만 다시 처리할 수 있다. 또 여러 사용자가 같은 네트워크를 함께 사용할 때도 작은 조각 단위로 섞어 보내기 좋다.

여기서 중요한 건 패킷이 단순히 “쪼갠 데이터”만은 아니라는 점이다.

패킷은 실제 내용물뿐만 아니라, 이 데이터를 어떻게 처리해야 하는지 알려주는 정보도 함께 가진다.

회선 교환과 패킷 교환

패킷이 왜 등장했는지 이해하려면 먼저 통신 방식을 크게 두 가지로 비교해볼 수 있다.

하나는 회선 교환 방식이고, 다른 하나는 패킷 교환 방식이다.

회선 교환은 통신하는 두 대상 사이에 전용 길을 하나 잡아두는 방식이다.

전화 통화를 떠올리면 이해하기 쉽다. 내가 상대방과 통화하는 동안에는 그 연결이 유지된다. 통화가 끝날 때까지 둘 사이의 통신 경로가 계속 점유되는 느낌이다.

이 방식은 연결이 잡히면 안정적으로 대화할 수 있다는 장점이 있다. 하지만 사용하지 않는 순간에도 길을 계속 잡고 있다는 단점이 있다.

예를 들어 통화 중에 둘 다 아무 말도 하지 않는 시간이 있어도, 그 회선은 계속 그 통화에 묶여 있다.

반면 패킷 교환은 데이터를 작은 패킷으로 나누어 보내는 방식이다. 각 패킷은 네트워크 상황에 따라 이동하고, 목적지에서 다시 조립될 수 있다.

이 방식은 하나의 길을 계속 독점하지 않는다. 여러 사용자의 데이터가 작은 패킷 단위로 나뉘어 네트워크를 함께 사용할 수 있다.

비유하면 회선 교환은 한 사람이 도로 하나를 통째로 빌려서 이동하는 느낌이고, 패킷 교환은 여러 사람이 각자의 짐을 작은 상자에 나누어 실어 도로를 함께 사용하는 느낌이다.

인터넷처럼 수많은 사용자가 동시에 데이터를 주고받는 환경에서는 패킷 교환 방식이 훨씬 유연하다.

항상 같은 양의 데이터를 계속 보내는 것도 아니고, 어떤 순간에는 요청이 많고, 어떤 순간에는 거의 없을 수도 있다. 이런 환경에서 전용 회선을 계속 잡아두는 방식은 비효율적이다.

그래서 인터넷에서는 데이터를 패킷 단위로 나누어 보내는 방식이 사용된다.

패킷은 Header와 Payload로 볼 수 있다

패킷을 아주 단순하게 보면 두 부분으로 나눌 수 있다.

Header와 Payload다.

Payload는 실제로 보내고 싶은 내용이다. 예를 들어 사용자가 작성한 메시지, 요청 데이터, 파일의 일부 같은 것들이 여기에 해당한다.

Header는 그 데이터를 어떻게 처리해야 하는지 알려주는 정보다.

택배로 비유하면 Payload는 상자 안에 들어 있는 물건이고, Header는 상자 겉면에 붙은 송장에 가깝다.

상자 안의 물건만 있으면 배송할 수 없다. 어디로 보내야 하는지, 누가 보냈는지, 어떤 방식으로 처리해야 하는지 같은 정보가 필요하다.

네트워크 장비들도 비슷하게 판단한다.

패킷이 들어오면 장비는 Payload를 자세히 들여다보기보다, 주로 Header를 보고 판단한다.

“이 패킷은 어디로 보내야 하지?” “내가 처리해야 하는 패킷인가?” “다음 장비로 넘겨야 하나?” “어떤 규칙에 따라 해석해야 하지?”

이런 판단을 하기 위해 Header가 필요하다.

여기서 중요한 건 Header가 하나만 붙는다고 생각하면 안 된다는 점이다. 네트워크 통신에는 여러 프로토콜이 함께 동작하기 때문에, 각 프로토콜이 자기 역할에 필요한 Header를 붙일 수 있다.

다만 이 부분은 아직 깊게 들어가지 않는다. 지금은 패킷 안에 실제 내용물인 Payload가 있고, 그 내용을 처리하기 위한 부가 정보인 Header가 있다고 이해하면 된다.

클라이언트가 요청을 보낼 때 벌어지는 일

이제 다시 Request - Response 흐름으로 돌아와보자.

브라우저가 서버에 요청을 보낸다.

이 말은 사실 조금 더 풀어보면 이렇다.

브라우저는 서버와 약속된 프로토콜에 맞춰 요청 메시지를 만든다. 그 메시지는 네트워크를 통해 이동하기 좋은 크기의 패킷 단위로 나뉠 수 있다. 각 패킷에는 실제 요청 내용과 함께, 그 패킷을 처리하기 위한 Header 정보가 붙는다.

그러면 네트워크 장비들은 이 패킷을 보고 판단한다.

“이 패킷은 어디로 가야 하지?” “다음에는 어느 방향으로 보내야 하지?” “내가 아는 규칙에 맞는 정보가 Header에 있나?”

이런 판단들이 반복되면서 패킷은 목적지인 서버 쪽으로 이동한다.

서버에 도착하면 서버는 자신이 이해할 수 있는 프로토콜에 따라 요청을 해석한다. 그리고 그에 맞는 응답을 다시 만든다. 응답도 마찬가지로 네트워크를 통해 클라이언트에게 돌아간다.

결국 Request - Response는 단순히 “요청 하나가 가고 응답 하나가 온다”로 끝나는 일이 아니다.

그 안에는 약속이 있고, 그 약속에 맞춘 메시지가 있고, 그 메시지를 나눈 패킷이 있고, 패킷을 처리하기 위한 Header와 실제 내용인 Payload가 있다.

프로토콜과 패킷을 먼저 잡아야 하는 이유

네트워크를 공부하다 보면 용어가 계속 나온다.

HTTP, TCP, IP, DNS, Ethernet, ARP 같은 것들이다. 처음에는 각각이 따로 노는 개념처럼 느껴진다.

그런데 이들을 전부 “프로토콜”이라는 관점에서 보면 조금 정리가 된다.

각각은 통신 과정의 특정 문제를 해결하기 위한 규칙이다.

웹 요청과 응답을 어떻게 표현할 것인가. 목적지까지 어떻게 찾아갈 것인가. 도메인 이름을 어떻게 주소로 바꿀 것인가. 같은 네트워크 안에서 어떻게 데이터를 전달할 것인가.

이런 문제마다 필요한 약속이 있고, 그 약속들이 모여 실제 네트워크 통신을 만든다.

패킷도 마찬가지다.

패킷을 이해하면 네트워크를 더 이상 추상적인 선으로만 보지 않게 된다. “요청이 간다”는 말을 들었을 때, 그 안에서 작은 데이터 조각들이 Header를 달고 이동하는 그림을 떠올릴 수 있다.

여기서 중요한 건 네트워크를 외울 대상이 아니라 흐름으로 보는 것이다.

클라이언트는 규칙에 맞춰 메시지를 만들고, 그 메시지는 패킷이라는 작은 단위로 이동하고, 네트워크 장비들은 Header를 보고 다음 행동을 판단한다.

이 그림이 잡히면 이후에 나오는 계층, 캡슐화, IP, TCP, HTTP 같은 개념도 조금씩 같은 흐름 안에서 연결해서 볼 수 있다.

서버, 클라이언트, 라우터, 스위치, 주소, 포트, 계층 같은 말들이 한꺼번에 등장한다. 그런데 처음부터 이 용어들을 전부 외우려고 하면 오히려 전체 그림이 잘 안 잡힌다.

그래서 나는 네트워크를 먼저 아주 단순하게 바라보기로 했다.

네트워크는 정보를 주고받을 수 있도록 서로 연결된 구조다.

조금 더 풀어 말하면, 여러 장치들이 서로 연결되어 있고, 그 사이를 통해 어떤 정보가 이동하는 구조라고 볼 수 있다.

이때 네트워크를 그래프처럼 생각하면 이해하기 쉽다.

그래프에는 점과 선이 있다. 네트워크에서도 마찬가지로 볼 수 있다.

점은 정보를 주고받는 장치다. 선은 그 장치들을 이어주는 연결이다. 그리고 그 위를 오가는 것이 메시지다.

즉, 네트워크를 가장 단순하게 보면 이렇게 정리할 수 있다.

노드, 간선, 메시지.

노드는 정보를 주고받을 수 있는 장치다. 내 노트북, 스마트폰, 서버, 네트워크 장비 같은 것들이 모두 노드가 될 수 있다.

간선은 노드와 노드를 이어주는 연결이다. 유선 케이블일 수도 있고, 무선 신호일 수도 있다. 중요한 건 두 장치가 정보를 주고받을 수 있는 통로가 있다는 점이다.

메시지는 그 연결을 따라 이동하는 정보다. 우리가 웹사이트에 접속할 때 보내는 요청도 메시지고, 서버가 돌려주는 응답도 메시지라고 볼 수 있다.

여기서 중요한 건, 네트워크를 처음부터 복잡한 기술 묶음으로 보지 않는 것이다. 먼저 “장치들이 연결되어 있고, 그 사이로 정보가 이동한다”는 그림을 잡는 게 먼저다.

호스트는 네트워크의 가장자리에서 일한다

네트워크 안에는 여러 노드가 있지만, 모든 노드가 같은 역할을 하지는 않는다.

그중에서 호스트는 실제로 데이터를 만들거나 사용하는 주체다. 네트워크의 가장자리에서 정보를 생성하고 소비하는 장치라고 볼 수 있다.

예를 들어 내가 사용하는 노트북은 호스트다. 브라우저를 열고 어떤 웹사이트에 접속하면, 내 노트북은 서버에게 무언가를 요청한다.

웹 서버도 호스트다. 서버는 요청을 받고, 필요한 처리를 한 뒤 응답을 만들어 다시 보내준다.

즉, 호스트는 네트워크의 끝단에서 실제 대화에 참여하는 장치다.

비유하자면, 택배를 보내는 사람과 받는 사람에 가깝다. 중간에 도로와 물류센터가 있더라도, 실제로 물건을 보내고 받는 주체는 양쪽 끝에 있는 사람이다.

네트워크에서도 마찬가지다. 내 컴퓨터와 서버가 실제 메시지를 만들고 소비한다.

링크는 장치 사이를 이어주는 길이다

호스트가 서로 통신하려면 연결이 필요하다. 이 연결을 넓게 보면 링크라고 할 수 있다.

링크는 장치와 장치 사이에 데이터가 이동할 수 있는 통로다.

집에서 사용하는 랜선도 링크의 일부로 볼 수 있고, 와이파이처럼 무선으로 연결되는 것도 링크라고 볼 수 있다.

고속도로에 비유하면 링크는 도시와 도시를 이어주는 도로다. 아무리 자동차가 있어도 도로가 없으면 이동할 수 없다. 네트워크에서도 장치들이 아무리 많아도, 서로 연결되어 있지 않으면 정보를 주고받을 수 없다.

다만 실제 네트워크는 내 컴퓨터와 서버가 선 하나로 바로 연결되어 있는 단순한 구조가 아니다. 중간에 여러 장비를 거쳐서 이동한다.

네트워크 장비는 왜 필요할까?

내 노트북과 서버가 직접 연결되어 있다면 이야기는 간단하다. 내가 서버에게 메시지를 보내면 되고, 서버가 다시 나에게 메시지를 보내면 된다.

하지만 실제 인터넷은 그렇게 단순하지 않다.

수많은 컴퓨터, 스마트폰, 서버, 장비들이 서로 연결되어 있다. 모든 장치가 모든 장치와 직접 선으로 연결될 수는 없다.

그래서 중간에서 연결을 도와주는 장비들이 필요하다.

대표적으로 스위치와 라우터 같은 장비들이 있다. 지금은 이 장비들을 깊게 이해하려고 하지 않고, 일단 이렇게만 생각해도 충분하다.

네트워크 장비는 호스트들이 서로 통신할 수 있도록 중간에서 메시지가 이동할 길을 만들어주는 장치다.

장비 입장에서 생각해보면 이런 느낌이다.

“어떤 메시지가 들어왔네.” “이걸 어디 쪽으로 보내야 하지?” “내가 알고 있는 연결 방향을 기준으로 다음 위치로 넘기자.”

물론 실제로는 더 구체적인 기준과 규칙이 있지만, 지금 단계에서는 “중간에서 길을 이어주는 장비” 정도로 이해하고 넘어간다.

여기서 중요한 건 네트워크가 단순히 내 컴퓨터와 서버만의 관계가 아니라는 점이다. 그 사이에는 메시지를 전달하기 위한 여러 연결과 장비들이 존재한다.

클라이언트와 서버

웹 개발을 하다 보면 가장 많이 듣는 말이 클라이언트와 서버다.

클라이언트는 요청하는 쪽이다. 서버는 요청을 받고 응답하는 쪽이다.

예를 들어 브라우저에서 웹사이트 주소를 입력한다고 해보자. 이때 내 브라우저는 클라이언트 역할을 한다.

브라우저는 서버에게 말한다.

“이 페이지를 보고 싶어.” “이 데이터를 보내줘.” “로그인을 처리해줘.”

서버는 그 요청을 받고 처리한 뒤 다시 응답한다.

“여기 페이지 데이터야.” “요청한 데이터는 이거야.” “로그인 결과는 성공이야.”

이 관계를 너무 어렵게 생각할 필요는 없다. 식당에 비유하면 클라이언트는 손님이고, 서버는 주방에 가깝다.

손님이 주문한다. 주방은 주문을 받고 음식을 만든다. 그리고 다시 손님에게 결과물을 준다.

웹에서도 비슷하다. 클라이언트가 요청하고, 서버가 응답한다.

Request - Response 구조

웹 서비스의 기본 흐름은 Request - Response 구조로 이해할 수 있다.

Request는 클라이언트가 서버에게 보내는 요청이다. Response는 서버가 클라이언트에게 돌려주는 응답이다.

예를 들어 사용자가 게시글 목록 페이지에 들어간다고 해보자.

브라우저는 서버에게 요청한다.

“게시글 목록을 보여줘.”

서버는 요청을 받고, 필요한 데이터를 준비한 뒤 응답한다.

“여기 게시글 목록이야.”

사용자가 로그인 버튼을 눌러도 마찬가지다.

브라우저는 서버에게 요청한다.

“이 아이디와 비밀번호로 로그인할 수 있는지 확인해줘.”

서버는 확인한 뒤 응답한다.

“로그인 성공이야.”

또는

“아이디나 비밀번호가 틀렸어.”

이처럼 웹에서 일어나는 많은 일은 요청과 응답의 반복으로 볼 수 있다.

여기서 중요한 건 “요청이 간다”, “응답이 온다”는 표현을 막연하게 넘기지 않는 것이다.

요청은 클라이언트에서 만들어진 메시지다. 응답은 서버에서 만들어져 다시 클라이언트로 돌아오는 메시지다. 그리고 그 메시지는 네트워크의 연결과 장비들을 거쳐 이동한다.

즉, 웹 개발에서 자주 말하는 API 요청, 서버 응답, 페이지 로딩 같은 것들은 모두 이 큰 그림 안에 있다.

정리하자면 클라이언트가 요청한다. 네트워크를 통해 서버로 이동한다. 서버가 처리한다. 다시 네트워크를 통해 클라이언트로 응답한다.

네트워크는 정보를 주고받기 위한 연결 구조다. 그 구조 안에는 노드, 간선, 메시지가 있다. 호스트는 가장자리에서 데이터를 만들고 사용한다. 중간 장비는 통신이 가능하도록 길을 이어준다. 웹 서비스는 클라이언트가 요청하고 서버가 응답하는 구조로 동작한다.

요청과 응답은 생각보다 단순하지 않다

웹 개발을 하다 보면 우리는 자연스럽게 이런 말을 많이 쓴다.

“API 요청을 보낸다.” “서버에서 응답을 받는다.” “프론트에서 백엔드로 요청이 간다.” “배포했는데 접속이 안 된다.” “서버는 살아 있는데 왜 안 되지?”

처음에는 이 말들이 꽤 단순하게 느껴졌다.

브라우저에서 버튼을 누르면 요청이 가고, 서버가 처리해서 응답을 준다. 프론트엔드는 화면을 만들고, 백엔드는 데이터를 내려준다. 도메인을 입력하면 웹사이트가 열린다.

이 정도로만 이해해도 개발을 시작하는 데 큰 문제는 없었다.

그런데 개발을 하다 보면 어느 순간부터 이상한 질문들이 생긴다.

요청이 간다고 하는데, 그 요청은 어디로 가는 걸까? 서버가 응답한다고 하는데, 그 응답은 어떤 길을 따라 다시 돌아오는 걸까? 내 컴퓨터는 서버의 위치를 어떻게 알고 있을까? 도메인을 입력했을 뿐인데 왜 IP 주소가 필요할까? 포트는 왜 붙고, 방화벽은 어디서 막고, 로드밸런서는 어떤 기준으로 서버를 고를까?

서버는 살아 있는데 접속이 안 될 수 있다

코드는 정상인데 요청이 서버까지 도착하지 않을 수 있다. 서버 프로세스는 살아 있는데 외부에서는 접속이 안 될 수 있다. 도메인은 맞는데 DNS 설정이 잘못되어 있을 수 있다. 포트가 닫혀 있을 수도 있고, 방화벽이나 보안 그룹에서 막힐 수도 있다. 로드밸런서는 살아 있지만 뒤에 있는 서버로 트래픽을 제대로 보내지 못할 수도 있다.

이런 상황이 오면 단순히 “안 된다”로 끝낼 수 없다.

어디까지는 정상이고, 어디서부터 문제가 생겼는지 좁혀가야 한다. 그러려면 요청이 어떤 과정을 거쳐 서버까지 가는지, 응답이 다시 클라이언트로 돌아오는 동안 어떤 장비와 규칙을 지나는지 알아야 한다.

네트워크는 요청의 이동 경로를 이해하는 일이다

예를 들어 브라우저에서 example.com에 접속한다고 해보자.

겉으로 보기에는 주소창에 도메인을 입력하고 엔터를 누른 것뿐이다. 하지만 내부에서는 꽤 많은 일이 일어난다.

도메인 이름을 IP 주소로 바꾸고, 목적지 서버까지 갈 수 있는 경로를 찾고, 중간 장비들을 지나고, 서버의 특정 프로그램이 기다리고 있는 포트로 도착하고, 서버는 요청을 해석한 뒤 다시 응답을 보낸다.

사용자는 그냥 웹페이지를 보는 것이지만, 그 뒤에서는 여러 장비와 규칙들이 계속 판단하고 있다.

“이 요청은 어디로 보내야 하지?” “이 주소는 같은 네트워크 안에 있나, 밖에 있나?” “이 데이터는 어떤 프로그램에게 전달해야 하지?” “이 연결은 안전한가?” “이 서버가 응답하지 않으면 다른 서버로 보내야 하나?”

네트워크 공부는 이런 판단 과정을 하나씩 이해하는 일에 가깝다.

처음부터 모든 용어를 완벽히 외우려고 하면 금방 지친다. OSI 7계층, TCP/IP, IP 주소, MAC 주소, 포트, DNS, HTTP, TLS 같은 단어들이 한꺼번에 나오면 머릿속에서 서로 엉키기 쉽다.

그래서 나는 이 시리즈를 하나의 흐름으로 정리해보려고 한다.

출발점은 단순하다.

클라이언트가 요청을 보내고, 서버가 응답한다.

웹 개발을 하면서 가장 자주 마주치는 이 구조에서 시작해서, 그 요청과 응답이 실제 네트워크 안에서 어떻게 이동하는지 하나씩 따라가보는 방식이다.

큰 그림부터 다시 보기

처음에는 네트워크를 아주 큰 그림으로 바라본다.

정보를 주고받는 장치들이 있고, 그 장치들을 연결하는 통신 매체가 있고, 그 사이를 오가는 메시지가 있다.

이 단순한 구조 위에서 클라이언트와 서버가 등장하고, 요청과 응답이라는 흐름이 만들어진다.

그다음에는 통신에 필요한 규칙을 살펴본다. 사람끼리 대화할 때도 같은 언어와 약속이 필요하듯이, 컴퓨터끼리도 데이터를 주고받기 위한 규칙이 필요하다.

그 규칙들이 프로토콜이고, 데이터는 여러 단계를 거치며 형태를 바꿔가며 이동한다.

이후에는 같은 네트워크 안에서 데이터를 주고받는 방법, 다른 네트워크로 넘어가는 방법, IP 주소와 포트가 필요한 이유, TCP와 UDP의 차이, DNS가 도메인을 IP로 바꾸는 과정, HTTP 요청과 응답의 구조까지 차근차근 연결해보려고 한다.

결국 알고 싶은 것

결국 목표는 하나다.

브라우저에 주소를 입력했을 때, 그 뒤에서 어떤 일이 벌어지는지 내 머릿속으로 설명할 수 있는 것.

그리고 장애가 발생했을 때 “서버가 이상한가?”에서 멈추는 게 아니라,

“DNS는 정상인가?” “IP까지 도달 가능한가?” “포트는 열려 있는가?” “로드밸런서는 정상적으로 전달하고 있는가?” “서버 프로세스는 요청을 받고 있는가?”

이런 식으로 원인을 단계적으로 좁혀갈 수 있는 것이다.

네트워크는 처음 보면 추상적이다. 눈에 보이지 않는 요청과 응답이 어딘가로 이동한다고 하니 막연하게 느껴진다.

그래서 이 공부는 최대한 “패킷이 여행한다”는 느낌으로 바라보려고 한다.

내 컴퓨터에서 출발한 데이터가 어떤 장비를 만나고, 각 장비는 무엇을 보고 판단하고, 어떤 기준으로 다음 목적지를 정하는지 따라가보는 것이다.

완벽한 네트워크 전문가가 되기 위한 공부라기보다는, 개발자로서 내가 작성한 코드 바깥에서 무슨 일이 일어나는지 이해하기 위한 공부다.

요청을 보내는 코드 한 줄 뒤에 어떤 흐름이 숨어 있는지, 응답을 받기까지 얼마나 많은 약속과 판단이 필요한지, 그 전체 그림을 조금씩 내 말로 정리해보려 한다.

1. 데이터 타입 (Data Types)

Sass 는 7가지의 주요 데이터 타입을 지원하며, type-of 함수를 통해 확인할 수 있습니다.

2. 변수 (Variables)

변수는 $ 기호를 사용하여 선언하며, 코드의 재사용성을 높여줍니다.

2.1 변수 선언 및 사용

// 변수 선언
$font-size: 16px;
$primary-color: #333;

body {
  font-size: $font-size;
  color: $primary-color;

  // Property Nesting
  font: {
    family: Arial, sans-serif;
    weight: bold;
  }
}

2.2 변수의 유효 범위 (Scope)

• 전역 변수: 파일 최상위 레벨에서 선언된 변수.
• 지역 변수: 코드 블록 { } 내에서 선언된 변수.
• !global: 지역 변수를 전역 변수로 승격시킬 때 사용합니다.

3. 연산자 (Operators)

3.1 숫자 연산

산술 연산 시 왼쪽 피연산자의 단위를 기준으로 결과가 출력됩니다. 단, em 과 px 처럼 변환 불가능한 단위 간의 연산은 에러를 발생시킵니다.

주의: / 연산자는 다음 조건에서만 나눗셈으로 작동하며, 그 외에는 CSS 구분자로 인식됩니다.

1. 변수에 대해 사용될 때
2. 괄호 ( ) 내에서 사용될 때
3. 다른 연산의 일부로 포함될 때

3.2 컬러 및 문자열 연산

• 컬러: 각 RGB 성분별로 연산이 수행됩니다. (Alpha 값은 opacify, transparentize 함수 사용 권장)
• 문자열: + 연산자를 사용하여 연결 가능하며, 좌항의 따옴표 유무에 따라 결과 포맷이 결정됩니다.

4. 특수 기능

4.1 Interpolation: #{}

변수 값을 문자열 그대로 삽입합니다. 셀렉터 이름, 프로퍼티명, 혹은 연산을 피해야 하는 font 속성 등에 활용됩니다.

$name: alert;
$side: bottom;

// 셀렉터와 프로퍼티명에 적용
.#{$name} {
  border-#{$side}: 1px solid red;
  font: #{$font-size} / #{$line-height}; // 연산 방지
}

4.2 Ampersand (&)

부모 셀렉터를 참조할 때 사용합니다. 가상 요소, 가상 클래스, 혹은 부모를 포함하는 중첩 구조에서 유용합니다.

4.3 !default

변수에 값이 아직 할당되지 않은 경우에만 초기값을 설정합니다. 라이브러리나 테마 시스템의 기본값을 정의할 때 필수적으로 사용됩니다.

// 사용자 설정이 우선됨
$primary-conf: red;
$primary-conf: blue !default; // 이미 red가 있으므로 무시됨

Key Point: SassScript 는 변수, 데이터 타입, 연산 기능을 통해 CSS 를 프로그래밍 방식으로 제어하며, 특히 !default 와 #{} (인터폴레이션)은 효율적인 모듈화의 핵심입니다.