Hardware & Observability Mechanics

1. Overview

하드웨어 및 관측 메커니즘(Hardware & Observability Mechanics)은 추상적인 코드와 화려한 클라우드 다이어그램 밑바닥에 숨겨진 차가운 물리 장비(Hardware)의 세계로 내려가, "도대체 네트워크 어디서 병목이 터졌는가?"를 찾아내는 네트워크 탐정의 도구 상자를 해부합니다.

학습자는 스위치, 라우터, 방화벽 같은 물리적 **L2/L3 하드웨어(Hardware)**의 본질적 역할과 한계를 뜯어봅니다. 나아가 눈에 보이지 않는 전파와 패킷의 흐름을 엑스레이처럼 투시하는 **옵저버빌리티(Observability)**의 핵심인 Ping, Traceroute, Wireshark의 작동 물리학을 장악합니다. 마지막으로, DNS 쿼리가 실패했는지, 방화벽(Firewall)이 포트를 막았는지, 아니면 케이블이 끊어졌는지 계층별로 쪼개어 범인을 찾아내는(Troubleshooting) 장애 격리 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Network Hardware: Switch(L2), Router(L3), Firewall(L4/L7), Load Balancer.
• Diagnostic Tools (CLI): Ping(ICMP), Traceroute, Netstat, nslookup/dig.
• Packet Analysis: Wireshark/tcpdump를 이용한 L2~L4 패킷 스니핑 및 딥 다이브.
• Layered Troubleshooting: 물리 계층(랜선)부터 애플리케이션 계층(HTTP)까지 상향식/하향식 장애 원인 격리.

Out-of-Scope

• 마이크로서비스 분산 추적 (Distributed Tracing): Jaeger, Zipkin을 이용한 앱 레벨의 Span/Trace $\rightarrow$ 07-05-01 Observability & SLI-SLO 영역으로 위임.
• 방화벽(Firewall) 규칙 자동화 설정: Palo Alto/Fortinet 장비 벤더 특화 세팅 $\rightarrow$ 보안 장비 운영 매뉴얼 영역.

Boundaries

• Network Observability vs App Observability: 앱 옵저버빌리티(APM)가 "어느 Java 함수에서 3초가 걸렸는가?"를 찾는다면, 네트워크 옵저버빌리티는 "클라이언트와 서버 사이의 15개 라우터 중 7번째 라우터에서 패킷 30%가 드롭(Drop)되고 있다"를 찾는 행위입니다. 이 문서는 코드의 로직이 아니라 패킷이 굴러가는 '배관(Plumbing)'의 누수를 탐지하는 저수준(Low-level) 도구에 집중하여 경계를 긋습니다.

3. Counterexample

• 장님 코끼리 만지기 (No Packet Capture): 유저가 "서버에 접속이 안 돼요"라고 클레임을 겁니다. 백엔드 개발자는 무작정 서버 램(RAM)을 늘리고 아파치(Apache)를 재시작합니다. 그래도 안 됩니다. 알고 보니 회사 앞도로 공사로 광케이블이 끊어져 트래픽 자체가 안 들어오고 있었습니다. tcpdump로 서버 랜카드에 패킷이 들어오는지 1초만 찍어봤어도(Observability) 삽질을 안 했을 텐데, 네트워크 가시성을 확보하지 않고 감으로만 디버깅하는 인프라 초보의 전형적인 참사입니다.
• 방화벽과 포트의 오해: DB 서버(10.1.1.5)에 접속이 안 됩니다. 개발자가 ping 10.1.1.5를 쳤더니 응답이 잘 옵니다. "어? 네트워크는 정상인데 DB가 죽었나?" 하고 DB를 내렸다 올립니다. 그래도 접속이 안 됩니다. 핑(Ping)은 ICMP 프로토콜(L3)이고 DB 통신은 TCP 3306 포트(L4)라는 기본 지식을 무시한 짓입니다. 중간에 있는 방화벽(Firewall)이 ICMP는 허용하고 TCP 3306 포트는 막아놨을 확률이 99%인데, 계층별(Layered) 트러블슈팅을 할 줄 모르는 오류 격리의 부재입니다.

4. Prerequisites

• OSI 7계층 (Basic): 각 계층의 역할과 프로토콜 맵핑. (08-01 OSI Stack)
• L3/L4 프로토콜 (Basic): IP, ICMP, TCP 포트 개념. (08-01-02, 08-01-03)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 배관공의 공구함, 하드웨어 장비들 (The Hardware Zoo)

• Why to Learn: 패킷이 클라이언트에서 서버까지 날아갈 때 만나는 물리적 관문(관절)들의 특성을 이해해야, 병목 지점을 논리적으로 좁혀갈 수 있기 위함입니다.
• What to Learn:
  • Concepts: L2 Switch (MAC 기반), L3 Router (IP 기반), L4/L7 Firewall (포트 및 애플리케이션 기반), Load Balancer.
  • Skills: 사내 네트워크 구성도(Topology)를 보고 각 장비가 작동하는 OSI 계층(Layer)을 매핑하기.
• How to Learn:
  • 1단계: 스위치와 라우터 (L2/L3): 스위치는 같은 사무실(네트워크) 안에 있는 직원들끼리 MAC 주소를 보고 데이터를 꽂아주는 우편 배달부입니다. 라우터는 우체국장입니다. 서울에서 부산으로 갈 때, 목적지 IP를 보고 "아, 이쪽 국도로 타라"며 외부망으로 쏴주는 역할을 해부합니다.
  • 2단계: 방화벽 (L4/L7): 방화벽은 경비원입니다. 패킷이 라우터를 통과해도, L4 방화벽은 "너 포트 80(웹) 맞아? 22(SSH)는 막혀있어 돌아가"라고 검사합니다. 최신 L7 방화벽(WAF)은 아예 택배 상자를 까서 "안에 SQL 인젝션 폭탄 들었네?" 하고 버려버리는 계층별 철권통치를 뜯어봅니다.
• Implement: 장비별 패킷 필터링 시뮬레이터. 패킷 [MAC: A->B, IP: 10.1->10.2, TCP: 80, Payload: 'SELECT *'].
  • Switch: MAC B가 어딘지 포트를 찾음.
  • Router: 10.2 대역으로 라우팅.
  • Firewall(L4): TCP 80이 허용(Allow) 룰에 있는지 확인.
  • WAF(L7): Payload의 'SELECT' 문자열을 탐지하여 Drop 처리하는 파이프라인 콘솔 렌더링.

Recommended

Core Topic 02: 핑과 트레이스라우트의 물리학 (Ping & Traceroute Physics)

• Why to Learn: 유저가 "서버가 죽은 거 같아요"라고 할 때, 진짜 서버가 죽었는지 아니면 가는 길에 있는 통신사(KT) 라우터가 죽었는지 1초 만에 감별해 내기 위함입니다.
• What to Learn:
  • Concepts: ICMP (Internet Control Message Protocol), Echo Request/Reply, TTL (Time To Live), ping, traceroute (tracert).
  • Skills: traceroute 실행 결과를 해석하여 패킷이 버려지는(Drop) 특정 라우터 홉(Hop)의 IP를 짚어내기.
• How to Learn:
  • 1단계: 핑(Ping)의 메아리: 핑은 TCP도 UDP도 아닌 ICMP라는 특별한 프로토콜입니다. "야 들려?"(Echo Request)를 쏘면 "어 들려"(Echo Reply)가 옵니다. 응답 시간(ms)을 보면 물리적 거리(RTT)와 회선 상태를 단번에 알 수 있는 심장 박동기 역할을 해부합니다.
  • 2단계: 트레이스라우트(Traceroute)의 영악함: 서버까지 가는 데 라우터 15개를 거쳐야 합니다. 7번째 라우터가 죽은 것 같습니다. 트레이스라우트는 패킷의 TTL을 1로 세팅해서 쏩니다. 1번째 라우터가 죽이고 에러를 보냅니다. 그다음 TTL을 2로 쏩니다. 2번째 라우터가 응답합니다. 이 짓을 반복해서 TTL 7을 쐈는데 응답이 없으면 "범인은 7번 라우터다!"라고 족집게처럼 찾아내는 해킹에 가까운 원리를 뜯어봅니다.
• Implement: 나만의 Traceroute 스크립트 작성 (Python). scapy 라이브러리 사용. IP 패킷의 ttl 필드를 1부터 30까지 1씩 늘려가며 ICMP Request를 쏨. 중간 라우터들이 돌려주는 ICMP Time Exceeded 메시지의 소스 IP를 캡처하여, 목적지까지 거쳐 가는 라우터들의 IP 목록을 차례대로 터미널에 그려주는 로직 렌더링.

Practical

Core Topic 03: 패킷 엑스레이, 와이어샤크 (Packet Sniffing - Wireshark)

• Why to Learn: "네트워크가 이상해요"라는 막연한 미신을 버리고, 실제로 선을 타고 흘러가는 0과 1의 패킷 헤더를 직접 두 눈으로 까보며 증거 기반(Evidence-based) 디버깅을 하기 위함입니다.
• What to Learn:
  • Concepts: Packet Capture, Promiscuous Mode, tcpdump, Wireshark, BPF (Berkeley Packet Filter), TCP Handshake Analysis.
  • Skills: 리눅스 서버에서 tcpdump port 443으로 패킷을 떠서(.pcap), 로컬 Wireshark로 열고 TCP 3-Way Handshake 실패 지점 분석하기.
• How to Learn:
  • 1단계: 도청의 원리 (Sniffing): 내 랜카드(NIC)는 원래 나한테 오는 MAC 주소 패킷만 받고 나머지는 버립니다. 하지만 Promiscuous Mode(무차별 모드)를 켜면, 공중에 떠다니는 모든 와이파이 패킷이나 스위치의 미러링 포트 패킷을 몽땅 긁어모아 볼 수 있습니다. 패킷 캡처의 저수준 원리를 해부합니다.
  • 2단계: 엑스레이 판독 (Wireshark): 캡처된 수만 개의 패킷을 엽니다. 너무 많아서 안 보입니다. ip.addr == 10.1.1.5 && tcp.flags.syn == 1 필터를 겁니다. 클라이언트가 SYN을 쐈는데 서버가 SYN-ACK를 안 주고 아무 대답이 없습니다. "아! 방화벽이 SYN을 먹어버렸구나(Drop)"라고 확신하는 시각적 증명 과정을 뜯어봅니다.
• Implement: 가상의 pcap 로그 분석기. 터미널 로그 배열 [SYN(A->B), SYN(A->B), SYN(A->B), ICMP(B->A, Port Unreachable)]. 코드가 이 패턴을 파싱하여, "방화벽은 뚫렸으나, B 서버에 해당 포트를 리스닝(Listening)하는 애플리케이션(프로세스)이 죽어있음"을 자동으로 진단(Diagnose)해 주는 디버깅 어시스턴트 로직.

Advanced

Core Topic 04: 양파 까기, 계층적 트러블슈팅 (Layered Troubleshooting)

• Why to Learn: 장애가 터졌을 때 허둥대며 아무 설정이나 막 고치는 삽질을 멈추고, L1부터 L7까지 차근차근 계단을 밟아 올라가며 완벽하게 범인을 색출해 내기 위함입니다.
• What to Learn:
  • Concepts: Bottom-Up Troubleshooting, Top-Down Troubleshooting, Divide and Conquer (분할 정복), Fault Isolation (장애 격리).
  • Skills: 브라우저에 사이트에 연결할 수 없음 에러가 떴을 때, 5단계 체크리스트(케이블 $\rightarrow$ IP 할당 $\rightarrow$ Ping $\rightarrow$ DNS $\rightarrow$ Port $\rightarrow$ HTTP Log)를 기계적으로 수행하기.
• How to Learn:
  • 1단계: Bottom-Up (밑바닥부터 까기): 접속이 안 됨. L1: 랜선이 꽂혔나?(Link LED). L2: IP를 받아왔나?(ipconfig MAC 정상?). L3: 게이트웨이(공유기)로 핑이 나가나? 외부망 구글(8.8.8.8)로 핑이 나가나? 가장 기초적인 물리/네트워크 단절을 확인하는 철칙을 해부합니다.
  • 2단계: Divide and Conquer (범인 반갈죽): 8.8.8.8(IP)로는 핑이 가는데, google.com(Domain)으로는 핑이 안 갑니다. "범인은 DNS 서버(L7)다!" 네트워크 자체는 멀쩡한데 주소 번역기가 고장 난 겁니다. 만약 DNS도 멀쩡히 번역하는데 브라우저 접속만 안 되면? "범인은 TCP 포트(L4)나 방화벽이다!"라고 추론의 폭을 절반씩 좁혀가는 소거법을 뜯어봅니다.
• Implement: 트러블슈팅 챗봇(인터랙티브). 터미널에 "웹사이트 접속 불가 장애 발생" 텍스트. 유저가 입력창에 명령어를 침.
  1. 유저: ping 8.8.8.8 $\rightarrow$ 봇: [OK].
  2. 유저: ping example.com $\rightarrow$ 봇: [ERROR] Cannot resolve host.
  3. 유저: cat /etc/resolv.conf $\rightarrow$ 봇: nameserver 127.0.0.1 (Wrong). L3 네트워크는 정상이나 DNS 세팅이 망가졌음을 유도 심문으로 찾아내는 장애 격리 롤플레잉 게임.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Network Management and Troubleshooting
• [P5] SFIA - Network Support (NTAS) - Network diagnostics and troubleshooting

Secondary

• [TCP/IP Illustrated, Volume 1] Kevin R. Fall - Diagnostic Tools (Ping and Traceroute)
• [Practical Packet Analysis] Chris Sanders - Using Wireshark to Solve Real-World Network Problems

Industry

• [Cisco Learning Network] - Troubleshooting methodologies (Top-Down, Bottom-Up, Divide and Conquer)
• [Wireshark Official Documentation] - Capture and Display Filters

9. Final Checklist

Primary

• 같은 서브넷 내의 통신을 엮어주는 L2 스위치(Switch)와, 서로 다른 서브넷을 연결하여 외부 망으로 내보내는 L3 라우터(Router)의 아키텍처적 역할 차이를 물리 장비 관점에서 설명할 수 있는가?
• 서버에 접속되지 않을 때 ping 명령어를 사용하여 ICMP Echo Request를 쏘고, 응답 유무에 따라 물리적 네트워크 단절인지 서버 애플리케이션 장애인지 범위를 1차 격리(Isolation)할 수 있는가?

Secondary

• traceroute 명령어가 IP 헤더의 TTL(Time to Live) 값을 1씩 증가시켜 가며 패킷을 쏘는 원리를 이해하고, 이 결과값을 통해 특정 ISP(통신사) 구간에서 발생하는 트래픽 드롭(Drop)을 증명할 수 있는가?
• 리눅스 서버에서 원인을 알 수 없는 통신 타임아웃이 발생했을 때, tcpdump를 사용하여 패킷(pcap)을 캡처하고 Wireshark로 열어 TCP 3-Way Handshake가 완수되었는지 육안으로 해부할 수 있는가?

Industry

• "웹 페이지가 안 열린다"는 장애 접수에 대해, L1(물리 링크) $\rightarrow$ L3(핑 테스트) $\rightarrow$ L4(포트 열림 확인) $\rightarrow$ L7(DNS 질의 및 HTTP 로그) 순서로 올라가는 Bottom-up 트러블슈팅 파이프라인을 기계적으로 전개할 수 있는가?
• ping은 정상적으로 수신되나 데이터베이스(Port 3306) 접속은 거부되는 현상에 대해, 네트워크 계층(L3)은 정상이나 방화벽(Firewall/L4)에서 특정 포트만 차단(Drop/Reject)하고 있다는 아키텍처적 결론을 논증할 수 있는가?