<aside> ☁️

클라우드웨이브 네트워크 1주차 · 1/5 · 약 5분

클라우드웨이브 부트캠프: 네트워크에서 클라우드 네이티브까지

</aside>

네트워크 교육 첫날, 가장 먼저 든 생각은 “OSI 7계층을 다시 외워야 하나?”였다. 물리 계층부터 응용 계층까지 이름은 익숙했지만, 막상 API 요청이 실패했을 때 어느 계층부터 확인해야 하는지는 선명하지 않았다.

수업을 들으며 관점이 조금 바뀌었다. 계층 이름을 순서대로 외우는 것보다, 애플리케이션이 만든 데이터가 목적지까지 가면서 어떤 정보로 포장되는지 따라가는 편이 훨씬 이해하기 쉬웠다.

이 글에서 확인할 것

HTTP 요청은 그대로 이동하지 않는다

백엔드 애플리케이션이 HTTP 요청을 만들면 그 문자열이 네트워크를 그대로 날아가는 것은 아니다. 아래 계층으로 내려갈 때마다 통신에 필요한 정보가 붙는다.

flowchart LR
    A["HTTP 데이터"] --> B["TCP 세그먼트<br/>포트·순서 정보"]
    B --> C["IP 패킷<br/>출발지·목적지 IP"]
    C --> D["이더넷 프레임<br/>현재 구간의 MAC"]
    D --> E["비트와 신호"]

이 과정을 캡슐화라고 한다. 수신 측에서는 반대로 헤더를 하나씩 확인하고 벗겨 애플리케이션에 데이터를 전달한다.

여기서 가장 헷갈렸던 부분은 IP 주소와 MAC 주소의 차이였다. 둘 다 목적지를 나타내는 것처럼 보였기 때문이다.

다른 네트워크로 요청을 보낼 때 프레임의 목적지 MAC은 최종 서버가 아니라 기본 게이트웨이의 MAC이 된다. 라우터를 지날 때마다 링크 계층 정보는 다음 구간에 맞게 바뀌지만, 일반적인 라우팅에서는 최종 목적지 IP가 유지된다. NAT가 있다면 주소나 포트가 중간에 변환될 수 있다.

이 차이를 알고 나니 “같은 서버로 가는데 왜 MAC 주소는 계속 달라질까?”라는 의문이 풀렸다. IP는 여행의 최종 목적지이고, MAC은 지금 구간에서 찾아갈 다음 정류장에 가까웠다.

TCP와 UDP, 무엇이 더 좋은가가 아니라 무엇이 필요한가

TCP는 순서가 보장되는 바이트 스트림과 손실 복구 기능을 제공한다. 그래서 API 호출이나 데이터베이스 연결처럼 데이터의 순서와 정확성이 중요한 통신에서 자주 사용된다.

UDP는 연결 상태와 재전송을 기본으로 관리하지 않는다. 대신 애플리케이션이 지연 시간과 복구 방식을 직접 선택할 수 있다. 따라서 TCP는 안전하고 UDP는 위험하다고 단순하게 구분하기보다, 서비스가 어떤 전달 특성을 요구하는지 먼저 봐야 한다.

내가 기억하기로 한 질문은 하나다.