소프트웨어 공학 개념과 AWS로 보는 TCP/IP 4계층

카테고리 없음

소프트웨어 공학 개념과 AWS로 보는 TCP/IP 4계층

심리밀당남 2025. 6. 16. 21:22

기술면접 단골 질문

"TCP/IP 4계층에 대해서 설명해주세요."

이 질문은 웹 백엔드 개발자 기술면접에서 빠지지 않는 단골 질문입니다. 대부분의 개발자들은 이렇게 답변합니다.

"TCP/IP 4계층 모델은 현대 인터넷의 동작을 논리적으로 나누어 설명하는 데 사용됩니다. 각 계층에는 고유한 역할이 있습니다.
응용 계층은 HTTP나 DNS 같은 애플리케이션 프로토콜을 다루고 사용자의 요청/응답을 처리합니다.
전송 계층은 TCP/UDP를 통해 신뢰성 있는 데이터 전달과 순서 제어를 담당하며, 흐름 제어와 오류 검출/복구를 수행합니다.
인터넷 계층은 IP 프로토콜을 통해 주소 지정과 라우팅을 담당하여 패킷이 여러 네트워크를 거쳐 목적지까지 전달되도록 합니다.
네트워크 계층은 이더넷 같은 로컬 네트워크 기술과 물리 매체 인터페이스를 포함하며, 상위 계층의 데이터를 실제 네트워크 망을 통해 전달합니다."

TCP/IP 모델은 왜 계층으로 나누어져 있나요?

이러한 고민을 해보신 적이 있으신가요? 사용자가 웹사이트에 접속할 때, 단순히 "데이터를 보내고 받는 것"인데 굳이 이렇게 복잡하게 여러 단계로 나누어야 할 이유가 있을까요?

브라우저 → [복잡한 4계층 과정] → 서버

기술적으로는 모든 네트워크 기능을 하나의 거대한 시스템으로 통합해서 만들 수도 있을 텐데 말이죠.

이 글에서는 웹 환경에서 데이터 전송 과정을 계층으로 나누어야 하는 실질적인 이유와 실무에서의 활용을 깊이 있게 살펴보겠습니다.

소프트웨어 공학 관점에서 본 계층화

크래프톤 정글 과정 중, PintOS 프로젝트 직전에 들었던 카이스트 교수님의 운영체제 특강에서 인상 깊었던 말이 있습니다.

"개발이란, 복잡한 문제를 작은 단위로 나누고(problem decomposition), 각 단위를 추상화된 계층으로 구성(set layers of abstraction)하는 과정이다"

이는 소프트웨어 공학의 핵심 원칙인 모듈화(Modularity)와 추상화(Abstraction)를 설명하는 말입니다.

모듈화는 복잡한 시스템을 독립적인 기능 단위로 나누는 것이고, 추상화는 각 모듈의 내부 구현은 숨기고 외부에는 단순한 인터페이스만 제공하는 것입니다. 이 두 개념이 소프트웨어 개발에서 가져다주는 장점은 명확합니다:

개발 복잡도 감소: 전체 시스템을 한 번에 이해할 필요 없이, 각 모듈에 집중할 수 있음
재사용성 향상: 잘 정의된 인터페이스를 가진 모듈은 다른 시스템에서도 활용 가능
유지보수성 개선: 특정 모듈의 변경이 다른 모듈에 영향을 주지 않음
병렬 개발 가능: 각 모듈을 독립적으로 개발할 수 있어 개발 효율성 증대

데이터 전송, 생각보다 복잡한 문제

그런데 네트워크를 통한 데이터 전송이 얼마나 복잡한 문제인지 생각해본 적이 있나요?

단순히 "A에서 B로 데이터를 보낸다"고 하지만, 실제로는 이런 복잡한 고려사항들이 있습니다:

어떤 형식으로 데이터를 주고받을지 (HTTP, FTP, DNS 등)
신뢰성 있게 전달하려면 어떻게 할지 (순서 보장, 에러 검출, 재전송)
어떤 경로로 데이터를 라우팅할지 (수많은 네트워크를 거쳐서)
물리적으로 어떤 매체를 통해 전달할지 (이더넷, WiFi, 광케이블)

이 모든 문제를 하나의 거대한 시스템으로 해결하려고 한다면, 복잡도가 기하급수적으로 증가할 것입니다. TCP/IP 4계층은 바로 이 문제를 모듈화와 추상화 원칙을 적용해 해결한 결과입니다:

Application Layer: 응용 프로그램 간 통신 방식
Transport Layer: 신뢰성 있는 데이터 전달
Internet Layer: 네트워크 간 라우팅
Network Access Layer: 물리적 데이터 전송

다음으로는 네트워크를 통한 데이터 전송을 여러 계층으로 나눔으로써 얻을 수 있는 장점에 대해 살펴보겠습니다.

1. 재사용성과 호환성

각 계층이 명확한 인터페이스로 분리되어 있어, 특정 계층의 구현을 바꾸어도 다른 계층에는 영향을 주지 않습니다.

같은 웹 애플리케이션이 다양한 환경에서 동작 가능:

HTTP 요청 (Application Layer)
├── TCP (Transport Layer) + 이더넷 (Network Access)
├── TCP (Transport Layer) + WiFi (Network Access)
├── QUIC (Transport Layer) + 이더넷 (Network Access)
└── QUIC (Transport Layer) + 5G (Network Access)

웹 개발자는 HTTP 요청을 보낼 때 하위 계층이 TCP인지 QUIC인지, 이더넷인지 WiFi인지 전혀 신경 쓸 필요가 없습니다. Application Layer의 관점에서는 단순히 "데이터를 보내줘"라고 요청하기만 하면, 하위 계층들이 각자의 역할에 맞게 알아서 처리해줍니다.

2. 문제 격리와 디버깅 용이성

각 계층이 독립적인 책임을 가지고 있어, 문제가 발생했을 때 어느 계층에서 발생한 문제인지 체계적으로 추적할 수 있습니다.

네트워크 문제는 본질적으로 복잡합니다. 하지만 계층별로 나누어져 있기 때문에, 우리는 다음과 같이 순차적으로 접근할 수 있습니다:

웹사이트가 열리지 않을 때 문제 파악 방법 예시:

4층 (Application): HTTP 응답 코드는 정상인가? (200, 404, 500 등)
3층 (Transport): TCP 연결은 성공했는가?
2층 (Internet): IP 라우팅 경로에 문제는 없는가?
1층 (Network Access): 물리적 네트워크 연결은 되어 있는가?

만약 계층이 나누어져 있지 않았다면, 이 모든 가능성을 동시에 고려해야 해서 문제의 원인을 찾는 것이 훨씬 어려웠을 것입니다. 독립된 모듈화 덕분에 거대한 "네트워크 문제"를 구체적인 "특정 계층의 특정 문제"로 좁혀나갈 수 있습니다.

실무에서의 계층별 디버깅 접근법

TCP/IP 4 Layer 각각에 대해 잘 이해해하고 있으면 실무에서 어떤 점이 좋을까요?

특정한 에러 코드 없이, 서비스 접속이 안되는 장애상황이 발생했다고 가정해봅시다. 서비스 장애의 원인이 한번에 특정 대상으로 좁혀지면 참 좋겠지만, 실제로는 원인을 찾기도 어려운 ‘블랙박스’ 상황도 충분히 일어날 수 있습니다. 이러한 상황은 특정 계층을 먼저 의심할 단서가 없으므로, 모든 가능성을 열어두고 논리적인 순서에 따라 하나씩 배제해 나가는 Top-Down 방식이 적절할 수 있습니다. TCP/IP 4계층을 위에서부터 한 단계씩 내려가보면서 디버깅하는 것이죠. 계층별 디버깅 방법에는 수많은 방식이 있지만, 그 중 대표적인 예시만 짚고 넘어가겠습니다.

계층별 디버깅 방법론

Layer 4. 애플리케이션 계층 (Application Layer) - 서비스 동작 확인

사용자에게 서비스를 제공하는 애플리케이션과 관련 프로토콜(HTTP, DNS 등)의 정상 동작 여부를 확인합니다. 여기서 문제가 발견되면 하위 계층은 정상일 가능성이 높습니다.

1. DNS 조회 확인
- Domain name과 IP 주소가 잘 매핑되어 조회가능한지 점검합니다. 이 과정에 문제가 있다면, 통신 시작 자체가 불가능합니다.
- 대표 명령어: nslookup, dig
- 체크포인트:
  - DNS 해석 실패 여부, 의도하지 않은 IP로 해석되는지 확인
  - AWS 환경: Route 53 설정 확인
2. HTTP 응답 상태 확인
- DNS에 문제가 없다면, 해당 IP의 웹 애플리케이션이 정상적인 HTTP 응답을 주는지 확인합니다.
- 대표 명령어:
  - curl -I <https://example.com> (헤더 정보 확인),
  - curl -v <https://example.com> (상세 과정 확인)
- 주요 응답 코드
  - 2xx OK: 정상. 클라이언트 측 문제일 가능성.
  - 4xx Client Error: 클라이언트 요청 오류 (e.g., 404 Not Found).
  - 5xx Server Error: 서버 측 애플리케이션 로직, DB 연결 등에 문제 발생.
- 체크포인트:
  - 서버 애플리케이션 로그, 웹 서버(Nginx, Apache) 설정 및 에러 로그.
  - AWS 환경: CloudWatch Logs, EC2 인스턴스 내 애플리케이션 로그

Layer 3. 전송 계층 (Transport Layer) - 포트 연결 확인

애플리케이션이 사용하는 특정 포트(TCP/UDP)까지의 경로가 열려 있는지 확인합니다. 방화벽 문제의 대부분이 여기서 발견됩니다.

TCP 포트 연결 테스트
- 서버의 특정 포트가 연결 요청을 수락하는지 직접 확인합니다.
- 대표 명령어: telnet example.com 443
- 결과 분석
  - Connected: 성공. 포트가 열려 있고 서비스가 대기 중.
  - Connection refused: 거부. 포트는 열려 있으나 해당 포트를 사용하는 프로그램이 없거나, 방화벽이 거부함.
  - Timeout: 타임아웃. 중간 경로의 방화벽이 패킷을 버리거나(drop), 서버까지의 경로에 문제가 있음.
체크포인트
- 서버 방화벽: OS 방화벽(iptables, ufw) 규칙 확인.
- 클라우드 방화벽: Security Group의 인바운드 규칙에 해당 포트(e.g., 80, 443)가 허용되어 있는지 확인.
- 로드밸런서: ALB/NLB의 리스너 및 대상 그룹(Target Group) 헬스체크 상태 확인.

Layer 2. 인터넷 계층 (Internet Layer) - IP 도달 가능성 확인

IP 주소를 기반으로 목적지 서버까지 패킷이 정상적으로 전달되는지, 즉 라우팅 경로의 유효성을 확인합니다.

1. 기본 연결성 확인
- ICMP 프로토콜을 이용해 목적지 서버의 네트워크 스택이 살아있는지 확인합니다.
- 대표 명령어: ping
- 체크포인트: ping 실패 시 서버 자체의 문제이거나, ICMP를 차단하는 방화벽(네트워크 ACL 등)이 있을 수 있음.
2. 네트워크 경로 추적
- 목적지까지 어떤 라우터(hop)들을 거쳐 가는지 추적하여 어느 구간에서 문제가 발생하는지 확인합니다.
- 대표 명령어: traceroute example.com (Linux/macOS) 또는 tracert example.com (Windows)
- 체크포인트:
  - 특정 hop에서 응답이 멈추거나 지연이 급증하면 해당 라우터 또는 구간에 문제 발생.
  - AWS 환경: VPC 라우팅 테이블, 네트워크 ACL(NACL), 인터넷 게이트웨이(IGW) 설정 확인

Layer 1. 네트워크 액세스 계층 (Network Access Layer) - 물리/논리적 연결 확인

PC나 서버의 네트워크 카드(NIC)부터 스위치까지의 가장 기본적인 물리적, 논리적 연결 상태를 확인합니다.

1. 네트워크 인터페이스 상태 확인
- 로컬 장비의 네트워크 인터페이스가 활성화되어 있고 IP 주소를 할당받았는지 확인합니다.
- 대표 명령어: ip addr (Linux) 또는 ifconfig (macOS), ipconfig (Windows)
- 체크포인트:
  - 인터페이스가 UP 상태인지, 유효한 IP 주소를 가지고 있는지 확인.
2. ARP 테이블 확인
- 설명: 동일 네트워크 대역 내에서 IP 주소에 맞는 정확한 MAC 주소를 알고 있는지 확인합니다. (게이트웨이 등)
- 대표 명령어: arp
- 체크포인트:
  - 게이트웨이 IP에 대한 MAC 주소가 없거나 잘못되었다면 로컬 네트워크(LAN) 통신에 문제 발생.
  - AWS 환경: EC2 인스턴스의 running 상태, VPC 및 서브넷의 기본 설정 확인
물리적 점검
- 체크포인트: (물리 서버 환경) 랜 케이블 연결 상태, 스위치의 포트 상태 LED 등.

면접 질문으로 다시 돌아가서

글의 처음에는 아래와 같은 단순한 암기식 질문에서 시작했습니다.

"TCP/IP 4계층에 대해서 설명해주세요."

단순한 질문에서 시작해서, 소프트웨어 공학의 핵심 주제인 ‘모듈화’, ‘추상화’와, TCP/IP 4계층 모델의 실무에서의 적용 예시까지 살펴보았습니다. 그렇다면 아래의 질문에 대한 답변을 고민해보세요.

질문: "TCP/IP 모델은 왜 계층으로 나누어져 있나요? 그 이유는 무엇이라고 생각하세요?"

"TCP/IP 4계층으로 나눈 이유는 소프트웨어 공학의 모듈화와 추상화 원칙을 네트워크라는 복잡한 시스템에 적용하기 위함입니다.

네트워크 통신은 데이터 형식 정의, 신뢰성 보장, 라우팅, 물리적 전송이라는 서로 다른 성격의 복잡한 문제들을 동시에 해결해야 합니다. 이를 하나의 거대한 시스템으로 구현한다면 복잡도가 기하급수적으로 증가할 것입니다.

하지만 각각을 독립적인 계층으로 분리함으로써 두 가지 핵심 이점을 얻을 수 있습니다.

첫째, 재사용성과 호환성입니다. 특정 계층만 교체해도 다른 계층에 영향을 주지 않아 기술 발전에 유연하게 대응할 수 있습니다. 예를 들어, HTTP/3에서 Transport Layer만 TCP에서 QUIC으로 변경해도 Application Layer의 웹 애플리케이션은 수정 없이 그대로 동작합니다.

둘째, 문제 격리와 디버깅 용이성입니다. 네트워크 문제를 계층별로 체계적으로 분석하여 복잡한 문제의 원인을 빠르게 특정할 수 있습니다.

결국 TCP/IP 4계층은 단순한 이론적 모델이 아니라, 복잡한 네트워크 시스템을 효율적으로 설계하고 운영하기 위한 실용적인 아키텍처입니다."

질문: "AWS에 새로운 웹 서비스를 처음으로 배포했습니다. 아키텍처는 Route 53, ALB, EC2로 구성되어 있으며, 배포 후 할당된 도메인으로 접속을 시도했으나 페이지가 전혀 열리지 않습니다. 최초 배포 상황이라 모든 설정이 의심되는 상황입니다. 이 문제의 원인을 찾기 위해 어떤 순서로, 무엇을 점검하시겠습니까?"

웹페이지 접속 불가와 같은 장애가 발생했을 때, 저는 사용자와 가까운 애플리케이션 계층에서부터 하위 계층으로 내려가는 'Top-Down' 방식으로 체계적인 원인 분석을 진행하겠습니다. 이 접근 방식은 문제의 범위를 빠르고 효과적으로 좁히는 데 매우 유용합니다.

먼저 애플리케이션 계층에서는 DNS 조회가 정상적으로 이루어지는지 AWS Route 53 설정을 확인하고, nslookup 명령으로 올바른 IP 주소를 받아오는지 점검하겠습니다. 이후 curl 명령을 통해 HTTP 응답 코드를 확인하여, 만약 5xx 에러가 발생한다면 EC2 인스턴스에 접속하여 웹 서버(Nginx 등)의 로그나 CloudWatch Logs를 분석해 애플리케이션 자체의 오류를 찾아낼 것입니다.

애플리케이션에 이상이 없다면 전송 계층으로 내려와 서버의 서비스 포트(443 등)가 열려 있는지 확인합니다. telnet과 같은 명령어로 직접 접속을 시도해보고, 만약 연결이 거부된다면 AWS Security Group의 인바운드 규칙이 올바르게 설정되었는지 검토할 것입니다. 만약 로드밸런서를 사용 중이라면, ALB나 NLB의 헬스체크 상태와 대상 그룹(Target Group)의 포트 설정을 점검하여 트래픽이 EC2 인스턴스로 제대로 전달되는지 확인할 것입니다.

그 다음 인터넷 계층에서는 ping으로 서버 IP까지의 도달 가능성을 확인하고, traceroute를 실행하여 중간 경로의 문제를 추적하겠습니다. AWS 환경에서는 특히 VPC의 라우팅 테이블이 인터넷 게이트웨이(IGW)로 올바르게 설정되었는지, 그리고 서브넷에 연결된 네트워크 ACL(NACL)이 트래픽을 차단하고 있지는 않은지 면밀히 살펴보겠습니다.

마지막으로 네트워크 액세스 계층에서는 EC2 인스턴스 자체가 AWS 콘솔에서 'running' 상태인지 확인하고, 시스템 내에서 네트워크 인터페이스가 정상적으로 활성화되어 있는지 점검할 것입니다.

이처럼 상위 계층부터 하위 계층으로 체계적으로 점검하면, 문제의 원인이 애플리케이션 로직에 있는지, 방화벽 설정에 있는지, 아니면 네트워크 라우팅에 있는지를 논리적으로 좁혀나가며 신속하고 효율적으로 장애에 대응할 수 있습니다.

이러한 고민을 담은 기술면접 문제집을 만들었습니다

인터넷에선 단순한 암기형 예상 면접 질문은 쉽게 찾을 수 있습니다. 하지만 그에 대한 답변을 작성해도, 내 답변이 얼마나 정확한지 알기 어렵죠. 암기형을 넘어 깊이 있는 질문은 찾는 것조차 쉽지 않구요. 이러한 문제를 해결하기 위해 아래와 같은 AI를 사용한 기술면접 평가 서비스를 만들었습니다. 아래 링크에서 위 글에서 다룬 문제를 본인만의 답변으로 풀어보고, 자신의 답변이 얼마나 정확한지, 어떤 점을 개선해야 하는지 파악해보세요!

TCP/IP 4계층 대해 단순한 암기가 아닌, 소프트웨어 공학 원리와 실무 경험을 바탕으로 한 깊이 있는 답변을 준비할 수 있을 것입니다.

문제집: 소프트웨어 공학 개념과 AWS로 보는 TCP/IP 4계층