이 글에서 얻는 것
- OSI 7계층을 단순히 외우는 것이 아니라, “문제가 발생했을 때 어느 계층을 봐야 하는지” 알게 됩니다.
- L4 vs L7 로드밸런서의 차이를 통해 아키텍처 설계의 기본을 익힙니다.
- TCP Handshake가 왜 필요한지, 연결 비용이 왜 비싼지 실무적으로 이해합니다.
0. 왜 계층을 나눴을까?
복잡한 네트워크 통신 과정을 역할별로 쪼개서 관리하기 위함입니다.
- 랜선이 끊어지면(1계층 문제), 유튜브 앱(7계층)을 고칠 필요 없이 랜선만 바꾸면 됩니다.
- 이것이 캡슐화와 모듈화의 전형적인 예시입니다.
1. 실무에서 중요한 4가지 계층 (TCP/IP 모델)
OSI 7계층은 이론에 가깝고, 실무에서는 TCP/IP 4계층 위주로 사고합니다.
L7: 응용 계층 (Application)
- 우리가 만드는 코드: HTTP, JSON, HTML, DNS
- 장비: L7 로드밸런서 (Nginx, AWS ALB), WAF(웹 방화벽)
- 특징: “패킷의 내용"을 볼 수 있습니다. (URL
/login은 A서버로,/search는 B서버로)
L4: 전송 계층 (Transport)
- 연결과 포트: TCP, UDP, Port
- 장비: L4 로드밸런서, 방화벽(Port 제어)
- 특징: 내용(HTTP 헤더 등)은 모르고, IP와 Port만 보고 배달합니다. “이 패킷은 8080 포트로 가는구나”
L3: 네트워크 계층 (Network)
- 주소와 경로: IP, 라우터
- 특징: 목적지 컴퓨터를 찾아가는 네비게이션 역할입니다. (서울시 강남구…)
L2/L1: 데이터 링크/물리 계층
- 랜선과 MAC: 이더넷, 와이파이, 스위치
- 특징: 옆 컴퓨터(공유기 등)로 물리적 신호를 전달합니다.
2. L4 vs L7 로드밸런서 (면접 단골, 실무 필수)
| 구분 | L4 로드밸런서 (AWS NLB) | L7 로드밸런서 (AWS ALB, Nginx) |
|---|---|---|
| 기준 | IP 주소 + 포트 번호 | URL, HTTP 헤더, 쿠키 |
| 속도 | 빠름 (패킷 내용을 안 까보니까) | L4보다 느림 (내용 분석 비용) |
| 기능 | 단순 부하 분산 | SSL 종료, URL 라우팅, 인증 처리 가능 |
| 용도 | 대규모 트래픽 단순 분산, TCP 베이스 | 마이크로서비스 라우팅, HTTPS 처리 |
실무 팁:
- “서비스가 너무 느린데 HTTPS 복호화 비용 때문인가?” -> L7 앞단에 L4를 둬서 부하를 줄이기도 합니다.
- MSA 환경에서는 **L7(Ingress)**가 필수입니다.
/users요청과/orders요청을 찢어줘야 하니까요.
3. TCP 3-way Handshake: “연결은 비싸다”
TCP는 신뢰성이 생명입니다. “나 보낸다?” “어, 보내!” “오케이 쏜다!” 확인이 필요합니다.
- SYN: (클라 -> 서버) “접속해도 돼?”
- SYN+ACK: (서버 -> 클라) “어, 내 말 들려? 너도 준비 됐어?”
- ACK: (클라 -> 서버) “어 잘 들려. 이제 데이터 보낸다.”
실무 포인트:
- 이 과정이 0.1초씩 걸린다면, HTTP 요청 하나 보낼 때마다 낭비가 심합니다.
- 그래서 HTTP Keep-Alive (연결 재사용)나 Connection Pool (미리 연결해둠)을 씁니다.
- “커넥션 맺는 비용"을 줄이는 것이 성능 최적화의 첫걸음입니다.
4. 주소창에 도메인을 입력했을 때, 계층별로 무슨 일이 일어날까?
면접이나 실무에서 네트워크를 진짜 이해했는지 보려면, 계층 이름을 외우는 것보다 한 번의 요청이 어느 계층을 지나가는지 설명할 수 있어야 합니다.
- L7 관점: 브라우저가
https://example.com요청을 준비합니다. - L7 → L3 관점: 먼저 DNS 질의를 날려서 도메인에 대응되는 IP를 알아냅니다.
- L4 관점: 알아낸 IP로 TCP 연결을 맺습니다. 여기서 3-way handshake가 발생합니다.
- L4/L7 사이 실무 포인트: HTTPS라면 TLS 핸드셰이크가 추가됩니다. 즉, 체감 속도는 TCP만의 문제가 아닙니다.
- L7 관점: 이제 HTTP GET 요청이 전송됩니다.
- L7/L4/L3 관점: 응답도 반대 방향으로 같은 계층을 타고 돌아옵니다.
이 흐름을 머리에 넣어두면, “왜 첫 요청만 느리지?”, “왜 특정 리전에서만 느리지?”, “왜 연결 수가 갑자기 폭증했지?” 같은 질문에 훨씬 빨리 접근할 수 있습니다.
5. 장애가 났을 때, 계층별로 어디부터 볼까?
네트워크 글을 읽고도 실무에 못 써먹는 가장 흔한 이유는 계층을 진단 순서로 바꾸지 못해서입니다. 아래처럼 증상 기준으로 보면 훨씬 유용합니다.
| 증상 | 먼저 의심할 계층 | 확인할 것 | 흔한 원인 |
|---|---|---|---|
| 서버 접속 자체가 안 됨 | L3/L4 | 보안그룹, 라우팅, 포트 오픈 여부 | 잘못된 방화벽 규칙, 라우팅 누락 |
| 연결은 되는데 응답이 매우 느림 | L4/L7 | handshake 지연, keep-alive, 서버 처리 시간 | 커넥션 재생성 과다, TLS 비용, 애플리케이션 병목 |
| 특정 URL만 404/502 발생 | L7 | 프록시 라우팅, upstream 설정, 리버스 프록시 로그 | 잘못된 path rule, 배포 누락 |
| 일부 클라이언트만 실패 | L3/L7 | DNS 전파, 캐시, 지역별 엔드포인트 | 오래된 DNS 캐시, 리전 라우팅 문제 |
| 트래픽 급증 때만 장애 | L4/L7 | 커넥션 수, 큐 길이, LB 설정, 타임아웃 | connection storm, 스레드/커넥션 풀 고갈 |
빠른 진단 순서
- 1단계: DNS가 맞는가?
- 도메인이 기대한 IP로 가는지 먼저 확인합니다.
- 2단계: 포트가 열려 있는가?
- 애플리케이션 문제라고 단정하기 전에 네트워크 경로를 봅니다.
- 3단계: TCP 연결이 비정상적으로 많이 새로 맺어지는가?
- keep-alive 미적용, 프록시 설정 오류, readiness/healthcheck 이상이 자주 원인입니다.
- 4단계: HTTP 레벨 라우팅이 틀어졌는가?
/api만 실패한다면 보통 L7 문제일 가능성이 큽니다.
6. 백엔드 개발자를 위한 실무 체크리스트
설계할 때
- 이 서비스는 L4 분산만으로 충분한가, 아니면 L7 라우팅이 필요한가?
- TLS 종료를 어디서 할지, 그 비용을 누가 감당할지 정했는가?
- 연결 수가 늘었을 때 애플리케이션의 커넥션 풀/스레드 풀/타임아웃이 버틸 수 있는가?
장애 대응할 때
- “앱이 느리다"고 바로 코드부터 열지 말고 DNS → 연결 → 라우팅 → 애플리케이션 순서로 좁히고 있는가?
- 502/504가 났을 때 로드밸런서 타임아웃과 업스트림 처리 시간을 같이 보고 있는가?
- 헬스체크가 정상이어도 실제 사용자 요청 경로가 같은지 확인했는가?
성능 최적화할 때
- 짧은 요청을 많이 보내는 서비스라면 연결 재사용이 적용되어 있는가?
- 관측 지표를 볼 때 RPS만 보지 말고 connection/sec, active connections, handshake latency도 같이 보는가?
- 병목이 L7 처리인지, TLS인지, 네트워크 레벨 재시도인지 분리해서 보고 있는가?
7. 정리
OSI 7계층은 시험용 암기표가 아니라, 장애를 어디서부터 좁혀야 하는지 알려주는 지도에 가깝습니다.
실무에서는 보통 이렇게 기억하면 충분합니다.
- L3: 어디로 가야 하지?
- L4: 연결은 제대로 맺어졌나?
- L7: 요청 내용이 올바르게 처리됐나?
이 세 층만 명확하게 구분해도 로드밸런서 선택, 성능 최적화, 장애 대응 속도가 확실히 좋아집니다.
💬 댓글