Skip to main content

​
네트워크 기초

네트워크 문제를 빨리 잡으려면 “어디까지 정상인지”를 계층적으로 확인해야 합니다.

​
학습 목표

  • DNS, 포트, TLS, 지연시간 개념을 구분할 수 있습니다.
  • OSI 7계층 모델을 활용하여 문제 계층을 식별할 수 있습니다.
  • 연결 실패와 애플리케이션 오류를 분리할 수 있습니다.
  • 기본 진단 명령으로 원인 범위를 줄일 수 있습니다.

​
OSI 7계층 간략 요약

네트워크 문제를 진단할 때 “어느 계층 문제인지”를 먼저 파악하면 원인을 빠르게 좁힐 수 있습니다.
계층이름역할AI/ML 관련 예시
7Application앱 프로토콜 (HTTP, gRPC)REST API 호출, LLM 응답
6Presentation데이터 인코딩/암호화TLS/SSL, JSON 직렬화
5Session세션 관리WebSocket, 스트리밍 연결
4Transport포트, TCP/UDP포트 충돌, 연결 타임아웃
3NetworkIP 라우팅VPN 경로, 서브넷 설정
2Data LinkMAC 주소, 스위칭로컬 네트워크 연결
1Physical물리 케이블, 신호케이블 불량, NIC 장애
실무에서는 7계층 전체를 외울 필요 없이, 네트워크(3-4계층) 문제와 애플리케이션(7계층) 문제를 구분하는 것만으로도 진단 속도가 크게 빨라집니다.

​
핵심 개념

  • DNS: 도메인을 IP로 해석합니다. 잘못된 DNS 설정은 모든 API 호출을 실패시킵니다.
  • 포트: 서비스 프로세스의 진입점입니다. 예: 80(HTTP), 443(HTTPS), 5432(PostgreSQL).
  • TLS: 전송 구간 암호화와 서버 신뢰 검증을 담당합니다.
  • Latency: 요청-응답 왕복 시간(RTT)입니다.
  • Throughput: 일정 시간 동안 처리 가능한 데이터 양입니다.

​
주요 포트 번호 목록

포트프로토콜/서비스용도
22SSH원격 서버 접속
80HTTP웹 서비스 (비암호화)
443HTTPS웹 서비스 (암호화)
3306MySQL데이터베이스
5432PostgreSQL데이터베이스
6379Redis캐시/메시지 브로커
8080HTTP (대체)개발/프록시 서버
8888JupyterLab노트북 서버
9090Prometheus메트릭 수집
9200OpenSearch/ES검색 엔진

​
DNS 동작 흐름

1

로컬 캐시 확인

브라우저와 OS가 이전에 해석한 DNS 결과를 캐시에서 먼저 찾습니다.
2

DNS 재귀 질의

캐시에 없으면 설정된 DNS 서버(예: 8.8.8.8)에 질의합니다. DNS 서버는 루트 → TLD → 권한 DNS 순서로 재귀 질의합니다.
3

IP 주소 반환

최종 IP 주소가 반환되고, 클라이언트는 해당 IP로 TCP 연결을 시작합니다.
4

TTL 기반 캐싱

반환된 결과는 TTL(Time To Live) 동안 캐시됩니다. DNS 변경 후 TTL이 지나야 새 IP가 적용됩니다.

​
실무 진단 순서

1

DNS 확인

도메인 해석 자체가 실패하면 애플리케이션 로직을 봐도 해결되지 않습니다.
nslookup api.example.com
dig api.example.com +short
2

포트 연결 확인

방화벽/보안그룹/네트워크 ACL 때문에 연결이 막혔는지 확인합니다.
nc -zv api.example.com 443
telnet api.example.com 443
3

TLS 확인

인증서 만료, 체인 오류, 호스트명 불일치를 점검합니다.
openssl s_client -connect api.example.com:443 -servername api.example.com
4

경로 추적

어느 구간에서 지연이 발생하는지 홉(hop)별로 확인합니다.
traceroute api.example.com    # macOS/Linux
tracert api.example.com       # Windows
5

애플리케이션 레벨 확인

여기까지 정상이면 서버 로그와 API 응답을 확인합니다.
curl -I https://api.example.com/health

​
방화벽 규칙 기본

서버 간 통신이 막히는 가장 흔한 원인은 방화벽/보안그룹 설정입니다. 
# Linux iptables - 현재 규칙 확인
sudo iptables -L -n

# ufw (Ubuntu) - 포트 허용
sudo ufw allow 8080/tcp
sudo ufw status

# 클라우드 보안그룹 (AWS 예시)
# Inbound: TCP 443 from 0.0.0.0/0 (HTTPS)
# Inbound: TCP 8080 from 10.0.0.0/16 (내부 API)
# Outbound: All traffic (기본 허용)
GPU 서버 간 통신(분산 학습)이 안 될 때 가장 먼저 확인할 것은 방화벽/보안그룹입니다. NCCL은 고대역폭 포트 범위를 사용하므로, 필요한 포트 범위를 미리 열어야 합니다.
ping은 ICMP 프로토콜이고, API는 TCP/HTTPS입니다. 즉, ICMP가 열린 상태와 TCP 443 포트가 열린 상태는 별개입니다. 방화벽이 ICMP는 허용하되 특정 TCP 포트를 차단하는 경우가 많습니다.
평균 지연시간만 보면 일부 느린 요청을 놓칩니다. 사용자 체감 장애는 보통 긴 꼬리 지연(p95/p99)에서 먼저 드러납니다. LLM API 호출처럼 응답 시간 분산이 큰 경우 특히 중요합니다.
벡터DB, LLM API, 내부 API를 연쇄 호출하면 각 구간 지연이 누적됩니다. 호출 체인을 단계별로 타이밍 기록해야 실제 병목을 찾을 수 있습니다. OpenTelemetry 같은 분산 트레이싱 도구를 도입하면 구간별 지연을 시각화할 수 있습니다.
DHCP는 네트워크 접속 시 자동으로 IP를 할당받는 방식입니다. 서버는 재부팅마다 IP가 바뀌면 안 되므로 고정 IP를 사용합니다. 개발 환경에서 DHCP를 사용하면 서버 주소가 변경되어 연결이 끊기는 문제가 생깁니다.

​
체크리스트

  • 서비스별 도메인/포트/프로토콜이 문서화되어 있나요?
  • TLS 인증서 만료 알림이 있나요?
  • 지연시간 지표에 p95/p99가 포함되어 있나요?
  • 방화벽/보안그룹 규칙이 최소 권한 원칙을 따르나요?
  • DNS 변경 시 TTL 영향을 고려하고 있나요?

​
다음 문서