OSI 모델

네트워크 장애를 만나면 가장 먼저 막히는 건 '지금 어디서 깨지고 있는지' 감이 안 잡힌다는 점입니다. 브라우저가 안 열리는 이유가 케이블 문제인지, IP 라우팅 문제인지, TCP 연결 문제인지, 애플리케이션 프로토콜 문제인지를 한 덩어리로 보면 손댈 곳이 없습니다. 제조사마다 구현 방식이 다르고, 프로토콜도 층층이 겹쳐 있으니 공통된 분해 기준 없이는 진단이 감으로 흘러갑니다. 네트워크 교육도 마찬가지입니다. 공통 언어 없이 프로토콜을 하나씩 외우면 전체 그림이 보이지 않습니다.

1970년대까지 네트워크는 IBM, DEC, Honeywell 같은 제조사마다 서로 다른 독자 프로토콜로 움직였습니다. 한 시스템에서 잘 되던 통신이 다른 시스템으로 넘어가면 바로 호환성 문제가 터졌고, 어디가 어긋났는지 설명할 공통 기준도 없었습니다. 네트워크가 커질수록 이 비호환성은 단순한 기술 차이를 넘어 기업 간 연결 비용으로 번졌습니다. ISO가 OSI 모델을 1984년에 제안한 이유는 새로운 장비를 하나 더 만드는 데 있지 않았고, 서로 다른 기술을 같은 층위에서 비교하고 가르치고 진단할 기준을 마련하는 데 있었습니다. 실제 인터넷은 결국 TCP/IP 중심으로 정착했지만, 왜 네트워킹 교육이 아직도 OSI로 시작하는지는 이 배경을 보면 자연스럽게 이해됩니다.

OSI 모델은 통신을 7개의 역할 층으로 분해합니다. 우편 시스템에 비유하면, 편지 내용을 쓰는 사람이 있고, 봉투에 담는 사람이 있고, 주소를 분류하는 사람이 있고, 트럭에 싣는 사람이 있습니다. 각자 자기 앞뒤 단계만 알면 됩니다. OSI도 마찬가지로, 7계층(애플리케이션)은 사용자와 가장 가까운 규약을 다루고, 아래로 내려갈수록 세션 관리, 표현 형식, 전송 보장, 라우팅, 프레임 전달, 물리 신호처럼 책임이 점점 구체적으로 쪼개집니다. 송신 측에서 데이터가 아래 계층으로 내려가며 각 층의 헤더를 덧붙이고, 수신 측에서는 반대로 위로 올라오며 그 정보를 벗겨 냅니다. 이렇게 층을 나누면 '문제는 3계층 라우팅에 있고 7계층 HTTP에는 문제가 없다'처럼 원인을 단계적으로 좁힐 수 있습니다.

OSI와 TCP/IP는 둘 다 네트워크를 계층으로 나눠 이해하려는 시도라는 공통점이 있습니다. 하지만 OSI는 역할을 세밀하게 분리한 참조 모델이라서 설명과 진단에 강하고, TCP/IP는 실제 인터넷에서 살아남은 프로토콜 묶음을 중심으로 한 실용 모델이라 구현과 운영에 더 가깝습니다. OSI는 세션 계층과 표현 계층까지 구분해 '어느 역할에서 문제가 생겼는가'를 말하기 좋고, TCP/IP는 그 둘을 애플리케이션 계층으로 묶어 현실 스택을 단순하게 다룹니다. 그래서 실무에서 패킷은 TCP/IP로 흐르지만 사람은 그 흐름을 OSI로 해석하는 경우가 많습니다. 통신 자체를 설계하거나 장비를 운용할 때는 실제 스택을 봐야 하고, 여러 프로토콜의 위치와 책임을 설명하거나 장애를 구조적으로 좁혀 갈 때는 OSI가 더 유용합니다.

OSI 모델은 장비 설정 명령어를 외우는 도구라기보다, 문제를 단계적으로 분리해 보는 사고 틀에 가깝습니다. DNS 이름은 풀리는데 페이지가 안 뜬다면 7계층이나 4계층 쪽으로 범위를 좁힐 수 있고, 같은 서브넷 장비끼리도 통신이 안 된다면 2계층이나 1계층을 의심할 수 있습니다. 새로운 프로토콜을 볼 때도 '이건 어느 계층의 책임인가'를 먼저 물으면 위치와 역할이 정리됩니다. 다만 OSI는 통신을 직접 수행하지 않습니다. 실제 서비스 배포나 장비 구성은 TCP/IP 스택이 담당합니다. OSI는 복잡한 네트워크를 머릿속에서 정리하고 설명하고 디버깅하게 해주는 기준선으로 쓸 때 가장 적절합니다.