4_짧_프로토콜과 인터페이스

* 비유는 접근성을 늘릴지라도 본질을 흐리기 마련입니다.

해당 포스트는 실습 과정 중 학습을 정리하는 글이기에 주관적인 내용이 포함되어 있을 수 있습니다.

잘못된 부분이 있다면 걸러들으시거나 댓글로 남겨주시면 감사하겠습니다.

 

* 잘 모르시는 기술은 로그인 필요없이 이 곳에서 AI에게 물어보세요! 

 

---

공부 중 여러 댓글들을 보며 프로토콜을 좀 잘못 알고 넘어가시는 분이 많은 것 같아서 정리도 할 겸 인터페이스와 엮어 짧게 포스팅해보려고 합니다.

 

우선 맨 먼저 개발에 대한 배경지식이 아예 없는 분들을 위해 정말 이해하기 쉽게 예시를 들어보겠습니다. 만약 여러분이 물건을 파는 판매자입니다. 그런데 물건을 판매하고 받은 게 바나나 1개라고 합시다. 그럼 여러분은 뭐라고 말하겠습니까? '아니 돈으로 줘야지 바나나는 뭐에요 도대체?' 정도일 것 같습니다. 현대 사회에선 당연히 물건에 값을 지불하는 수단이 돈이죠? 여기서 돈, 정확히는 화폐가 프로토콜에 대응됩니다. 그리고 나라마다 쓰는 화폐의 종류가 다르죠? 원화나 달러화 같은 단위가 우리가 자주 들어본 HTTP나 SSH와 같은 프로토콜 종류에 대응될겁니다.

 

프로토콜(Protocol)과 구성 요소

 

일단 Protocol이라는 용어가 생소할 수 있기때문에 좀 더 쉽게 다가가고자 단어 자체의 의미 먼저 살펴보겠습니다. 정말 처음으로 간다면 이 프로토콜은 그리스어에서 파생된 'Proto'+'Kollen'의 합성어로 볼 수 있는데 너무 상세한 유래을 알 필요 없이 우리는 프로토콜의 접두사인 Pro가 '앞으로 향하다'라는 의미라는 것을 알며 주위에서 쉽게 Process, Program 등의 단어를 접할 수 있습니다. 그래서 일반적으로 프로토콜은 '절차'의 의미에서 시작해 분야별로 뜻이 확장된다고 보시면 됩니다.

 

정보통신쪽에서 프로토콜의 사전적 의미를 살펴 보면 '복수의 컴퓨터 사이나 중앙 컴퓨터와 단말기 사이에서 데이터 통신을 원활하게 하기 위해 필요한 통신 규약'입니다. 하지만 사전적인 의미는 보통 바로 와닿지 않으니 비유와 예시를 통해 정리해보겠습니다. 참고로 규약이란 서로 지키기로 한 약속이나 규칙을 의미합니다.

 

약속이라는 것은 현대에 특정 분야와 결합함으로 가치를 지니게 됩니다. 예를 들어 수학에서 정의란 약속이고 그 정의는 수학의 토대입니다. 또한 경제에서 돈이란 약속이며 숫자로 나타난 금액들은 실물이 아닌 신용임과 동시에 지급하겠다는 약속입니다. 이처럼 프로토콜도 통신에서의 약속이기에 가치를 지닐 것입니다.

 

가치를 지니게 되면 많은 이들을 거치게 되고 시간이 흘러가며 오용되기에 그 개념에 살이 붙기 시작합니다. 때문에 사람들에게 프로토콜이 사양, 기능, 프로그램 등 약속이라는 개념을 넘어서는 의미로 받아들여지는 것이라 생각합니다. 하지만 프로토콜을 처음 이해할 때 그렇게 통칭할 수 있는 개념으로 받아들이기 보다는 약속 그 자체로 이해하는 것이 맞다고 생각됩니다. 조금 어려운 얘기였죠? 그래서 비유를 들어보려고합니다.

 

간단하게 시작하죠. 여기 철수와 사토 두 사람이 있습니다. 이름대로 철수는 한국인이고 사토는 일본인입니다. 이 때 두사람이 모국어만 써서 대화한다고 생각해봅시다. 생각만해도 답답하죠? 그래서 이제부터 두 사람은 대화할 때 쓰는 언어를 영어로 하기로 약속했습니다. 여기서 '영어' 그 자체는 프로토콜의 종류이며 프로토콜이 아닌 '대화 언어를 영어로 통일한 약속'이 프로토콜이 됩니다.

 

여기서  '대화 언어를 영어로 통일한 약속'이라는 프로토콜에서 자칫 초점을 영어에 두고 넘어갈 수도 있습니다. 하지만 저 프로토콜은 '대화', '언어', '통일' 이라는 문장의 뼈대가 더 중요합니다. 저 프로토콜로 우리가 약속한 것은 '대화'를 할 때 이 프로토콜이 성립하며 이 프로토콜은 대화에 사용되는 언어에 대한 규약이며 여러 언어가 아닌 영어라는 한 언어로의 통일을 조건으로 한다는 약속을 담고 잇죠. 여기서 영어는 그냥 언어의 한 옵션일 뿐입니다. 비유에서 보이듯 문장에 포함된 단어들이 서로 연관성을 가지는 것처럼 프로토콜을 이루는 정보들은 구문(Syntax), 의미(Semantic), 순서(timing) 이 3가지 요소를 충족해야 합니다. 

 

구문(Syntax) : 전송하고자 하는 데이터의 형식(Format), 부호화(Coding), 신호 레벨(Signal Level)등을 규정
의미(Semantic) : 두 기기 간의 효율적이고 정확한 정보 전송을 위한 협조 사항과 오류 관리를 위한 제어 정보를 규정
순서(timing) : 두 기기 간의 통신 속도, 메시지의 순서 제어 등을 규정

 

위의 프로토콜을 이 요소에 매칭해봅시다. '언어, 영어, 약속'처럼 조사를 빠뜨린 경우처럼 프로토콜이 정해진 문법을 지키지 않으면 문장이 성립하지 않는 것처럼 구문에 위배되고 대화 언어를 영어나 한국어 등이 아닌 C++로 정할 경우 프로그래밍 지식 여부에 따라서 언어로 인지하냐 못하냐의 정보 불균형이 발생하므로 의미에 위배되며 한 명이 먼저 말하면 다른 한명이 그를 다 듣고 대답하는 당연한 소통 과정을 무시하고 서로 동시에 할 말만 한다면 순서에 위배될 겁니다.

 

 

프로토콜 계층

 

한 단계 더 나아가보겠습니다. 철수와 사토를 모여서 대화가 불가능하게 서로 다른 국가로 떨어뜨려 놨습니다. 이제 둘에게 다시 대화를 하도록 시키면 이제 어떻게 해야하나요? 스마트폰을 써서 통화하거나 컴퓨터로 디스코드를 하던가 해야겠죠? 근데 사토는 컴퓨터를 잘 다루지 못해서 편지를 부친 후 답장을 기다리고 있는데 동시에 철수는 디스코드를 켜서 한없이 기다리는 불상사가 벌어지면 안되기에 통화하는 수단을 하나로 통일해야 대화가 가능할겁니다. 이 원거리 대화 수단을 정하는 약속 역시 프로토콜입니다. 어? 그런데 앞 문단에서도 프로토콜이 있는데 여기도 프로토콜이 있네요? 당연합니다. 원거리 통신 수단을 정하는 약속을 함과 동시에 통신 언어를 정하는 약속은 동시에 지킬 수 있습니다. 따라서 프로토콜은 동시 중첩, 공존이 가능합니다.

 

이제 두 프로토콜은 공존이 가능하니 철수와 사토 둘 사이의 프로토콜은 '원거리 대화 수단은 스마트폰을 이용하고 대화 언어는 영어로 통일하자'가 되겠네요. 네? 프로토콜이 너무 길다고요? 맞습니다. 너무 길어요. 그래서 프로토콜은 유형에 따라 분리되어야하기에 계층이 분리되어 있습니다. 하지만 단순히 이처럼 길어진다고 분리하는 것이 아닙니다. 이 계층 분리는 프로토콜의 요소가 서로에게 연관성이 얼마나 되는지에 따라 갈립니다. 위의 예에서 언어가 영어인 것과 수단이 스마트폰인 것 사이에는 큰 연관성이 없어 만약 대화하기로 한 영어가 불어로 수정되더라도 수단은 그에 독립적이기에 두 계층은 분리되어야 합니다.

인터페이스(Interface)

 

이제 '대화 언어는 영어', '대화 수단은 스마트폰' 두가지 프로토콜을 분리해서 정해놨습니다. 그런데 이 때 철수의 스마트폰 내장 언어에 영어가 없는 불상사가 일어납니다. 혹은 영어 단어에 스마트폰이라는 어휘 자체가 없을 수도 있겠죠.(몇년 전까진 있을 수 있는 일입니다) 이 경우 대화 수단이 스마트폰으로 문자를 하는 것이라면 두 사람의 목표인 대화는 정상적으로 이뤄지지 않습니다. 이 때 철수에게 영어가 내장된 스마트폰을 준다면 이 문제는 해결됩니다. 이 전달된 스마트폰은 끊어졌던 언어와 대화 수단을 이어줬고 이 스마트폰을 인터페이스이자 인터페이스의 구현체라고 할 수 있습니다.

프로토콜과 인터페이스

 

인터페이스(Interface)는 사전적으로 '서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면'입니다. 위의 예의 경우 '정보나 신호를 주고받는 경우의 접점'이라는 의미의 인터페이스일 것입니다.

 

예를 하나 들어보자면 트위터를 스마트폰으로 이용하고 있다고 할 때 트위터 앱 내의 버튼, 트위터 앱 자체, 앱이 깔린 스마트폰 모두 인터페이스라 할 수 있을 것입니다. 하지만 정확히 말하자면 그것들은 인터페이스보단 인터페이스의 구현체라고 불러야합니다. 만약 사용자가 트위터를 통해 다른 사람과 상호작용하기 위해 필요한 인터페이스는 '트위터 앱을 작동시킬 수 있는 장치'겠지만 이것은 추상적인 조건이며 문장입니다. 하지만 그 조건이자 문장을 만족하는 구체적인 컴퓨터, 스마트폰 등은 현실에 구현된 사물입니다. 개발에서도 이처럼 모든 인터페이스는 추상과 구현이라는 특성을 가지며 좁은 범위의 인터페이스에선 추상적인 특성이 인터페이스를 정의하며 넓은 범위에서 인터페이스는 구현체까지 포함합니다.

 

프로토콜 계층과 인터페이스

 

이제 프로토콜에 계층이 존재하고 이 계층들 사이를 연결해주는 인터페이스가 있음을 알았습니다. 이제 위의 예에서 한단계 더 나아가겠습니다. 대화 프로토콜 계층에는 지금 언어와 수단 두가지가 존재합니다. 하지만 수단의 경우 '스마트폰으로 문자를 통해' 같이 '어떤 장치를 써서 어떤 방식으로'와 같은 계층이 정확히 분리되지 않은 문제가 존재합니다. 따라서 기존 수단 프로토콜을 둘로 쪼개서 언어, 통신 방식, 통신 장치 세 가지로 나누겠습니다.

 

이제 계층 구조가 세 개가 존재합니다. 이제 조금 예를 달리 바꿔보겠습니다. 이번엔 철수가 영어를 아예 할 줄 모르는데 이것을 고려하지 않고 미리 모든 프로토콜을 정했다고 가정해보겠습니다. 이 때 프로토콜을 적용하는 순서를 어떻게 정해야 올바를까요? 먼저 통신 방식 프로토콜부터 언어 프로토콜 순으로 적용한다고 생각해보겠습니다. 프로토콜을 다 정해버렸는데 뒤늦게 철수가 영어를 못한다는 것을 깨달았습니다. 그러면 대화 프로토콜에서 영어블 불어로 바꿔야하고 이 때 인터페이스는 마지막 한 계층간만 변경하면 됩니다.

통신 방식 프로토콜부터

하지만 언어 프로토콜부터 선택한 경우는 다릅니다. 언어 프로토콜에서 영어를 불어로 교체해버리면 그 하위 계층간 인터페이스 전체를 교체해야합니다. 지금은 계층이 3개라 다행이지만 계층이 n개로 늘어난다면 인터페이스를 n-1번 교체해야 할겁니다. 

 

생각해볼 것이 하나 더 있습니다. 마주보는 두 계층간 인터페이스는 자연스럽게 구현체가 정해지지만 언어와 통신 방식 계층 사이의 인터페이스 구현체의 경우를 생각해봅시다. 특정 언어를 사용하는 통신방식? 특정 통신 방식을 사용하는 언어? 구현체가 있을 수는 있겠지만 딱 뭐다라고 떠오르진 않습니다. 이처럼 여러 계층을 뛰어넘어 게층 간 연결을 하는 것이 불가능할 때가 있습니다. 만약 가능하다고 치더라도 근접하지 않은 계층간 인터페이스를 계속 정의하다보면 계층이 많아졌을 때 프로토콜이 제 기능을 효율적으로 할 수 있을까요? 효율적인 정보 교환을 위해 맺은 약속에 정보량이 너무 많아질 뿐입니다. 

 

그렇기 때문에 프로토콜 계층은 1 계층 간 상속 구조가 단계별로 정확히 규정되어 있어야 함 2 접하는 계층간의 인터페이스만 정의해야 함 을 지켜야합니다. 또한 지금껏 살펴본 예시에서 철수와 사토가 프로토콜을 정하던 각각의 계층을 Layer라 합니다. 이 Layer들은 단계가 같다면 수평적으로 프로토콜이 적용됩니다. 또한 각 계층을 이어주던 인터페이스들을 매개로 단계를 거쳐 Layer들은 수직적으로 연결됩니다.

 

네트워크 프로토콜

 

마지막으로 여기까지 오신 분들이라면 지금까지 든 철수와 사토의 비유는 조금 아리송하게 느껴질 수도 있습니다. 비유에선 언어, 통신 장치, 통신 방식을 각각 하나의 Layer로 봤지만 통신 자체를 하나의 Layer로 본다면 언어, 통신 장치, 통신 방식이 프로토콜에 포함된 내용이 될 수 있으니까요. 이것은 네트워크에서의 프로토콜을 현실에서의 비유로 바꿨기에 생긴 괴리입니다. 그렇기에 네트워크 프로토콜은 가장 먼저 주고받을 통신의 목적과 그 범위에 따라 적용될 Layer가 먼저 결정되어야 합니다.

 

또한 네트워크에서 프로토콜은 기술된 형식이 대략적으로 정해진 경우가 대부분입니다. 따라서 앞서 언급한 Layer가 먼저 결정되고 다음과 같은 내용이 기술되어 있다면 하나의 프로토콜이라 생각하시면 됩니다,

물리적 측면: 자료 전송에 쓰이는 전송 매체, 접속용 단자 및 전송 신호, 회선 규격 등.
논리적 측면: 프레임(Frame, 자료의 표현 형식 단위) 구성, 프레임 안에 있는 각 항목의 뜻과 기능, 자료 전송의 절차 등

 

프로토콜 중 우리에게 제일 유명한 HTTP을 예시로 마치겠습니다. HTTP(HyperText Transfer Protocol)은 'HyperText(주로 html)을 통신을 목적으로 하고 인터넷이란 범위 안에서 사용되기에 Application Layer에 적용됩니다. 또한 HTTP는 요청/응답 메시지포맷, 응답코드에 대해 기술되어 있습니다. 

 

Internet protocol suite : OSI 7 Layer, TCP/IP 4 Layer

 

 

지금까지 프로토콜 계층간 특성과 그 인터페이스에 대해 살펴봤습니다. 하지만 비유만 보고 넘어가자니 조금 추상적입니다. 그렇기에 가장 자주쓰이는 네트워크 프로토콜, 그리고 그 집합인 Internet protocol suite에 대해서 가볍게 알아보고 마치도록 하겠습니다. 네트워크 프로토콜을 알아보는 이 시점부터는 위의 비유는 잊는걸 추천합니다. 

 

Internet protocol suite은 말 그대로 인터넷 프로토콜 집합입니다. 그리고 그 집합의 모델은 OSI 7계층(Open Systems Interconnection Reference Model 7 Layer)과 TCP/IP 4계층으로 대표되는데 사실상 두 모델은 비슷한 집합이라고 봐도 되고 각 계층이 유사하게 매핑됩니다. 다만 정의가 서로 다르고 아래와 같은 차이점이 있을 뿐입니다.

OSI 7계층과 TCP/IP 계층

1. OSI 7 Layer는 ISO(국제 표준 기구)에서 발표, TCP/IP는 미 국방부에서 개발 시작
2. 위 그림처럼 3Layer를 OSI는 네트워크, TCP/IP는 인터넷 계층이라 표현
3. TCP/IP의 Network Interface(Link Layer)를 OSI에선 1, 2 Layer로 분할 

눈에 띄는 차이점은 위와 같고 일단 두 모델의 정의부터가 OSI는 컴퓨팅 시스템 이론에 사용되는 개념적인 이론이고 실제 통신에선 구현되지 않지만 TCP/IP는 네트워크에서 데이터를 전송하는 Client-Server 표준 모델으로 서로 다릅니다.

 

먼저 등장한 모델은 OSI Model이지만 이는 시스템 아키텍처를 이해하는데 도움이 되도록 ISO가 정한 참조 모델이며 실제 인터넷이 발달하고 네트워크 통신에서 각종 프로토콜의 필요성이 절감되자 만들어진 표준 프로토콜 집합이 TCP/IP Model입니다 따라서 웹 통신쪽에서 프로토콜을 다루는 분이라면 다루는 프로토콜의 대부분은 TCP/IP Model일 것입니다.

 

TCP/IP Model엔 TCP, IP, HTTP, UDP, SMTP 등 유명한 프로토콜들이 많고 각각을 알 필요성이 있긴하지만 글이 너무 길어지는 관계로 계층별 상세 내용은 생략하도록 하겠습니다. 다만 위에서 나열한 차이점 말고도 TCP/IP는 위에서부터, OSI는 아래에서부터 접근하며 OSI 모델은 각 계층간 수평 접근을 지원하는 것과 같이 이번 포스트 내내 다뤘던 부분들과 상통하는 부분은 짚고 넘어가야합니다. 계층 분리시 특정 계층을 수정하면 다른 계층에 영향이 가지 않도록 유연하게 설계되어 있고 계층간에 특정 방향으로 접근해야한다는 것입니다. 이것이 지켜져야 프로토콜 사용에 있어서 오류 추적과 상태 관리가 더 명확해지기 때문이죠.

 

TCP/IP 모델은 웹 통신에서 매우 중요한 프로토콜 집합이기에 나중에 기회가 된다면 더 자세히 다루도록하겠습니다.

 

---

이번 포스트에선 프로토콜와 인터페이스를 이해해보기 위해 조금 다뤄봤습니다. 만약 각 용어의 더 자세한 설명이나 네트워크 프로토콜 등이 더 궁금하시다면 다른 포스트들을 참고해 더 공부해보시길 바랍니다.

 

refer

 

https://jhkang-tech.tistory.com/7

[네트워크] 프로토콜이란 무엇인가?

https://wonit.tistory.com/496

[Network] OSI 7 Layers와 TCP / IP 구조 비교