객체가 사는 법 #4. 프로토콜 - 상호작용의 질서

이 글은 객체지향 설계 개념을 차례로 살펴보는 작은 시리즈의 네 번째 글입니다.

1. 메서드 시그니처 - 계약에 남긴 서명(https://likebnb.tistory.com/183)
2. 계약 - 자유를 줄이고 예측가능성을 만드는 방식(https://likebnb.tistory.com/184)
3. 인터페이스 - 경계를 지키는 이름(https://likebnb.tistory.com/185)
4. 프로토콜 - 상호작용의 질서(https://likebnb.tistory.com/186)
5. 스테이트 머신 - 시공간의 맥락(https://likebnb.tistory.com/187)
6. 이벤트 - 코드의 흐름을 삼키다(https://likebnb.tistory.com/188)

 

 

인터페이스가 약속의 구조라면, 프로토콜은 그 약속이 작동하는 방식이다.

앞선 글에서 메서드 시그니처와 계약, 그리고 인터페이스에 대해 이야기했다. 이들이 약속의 구조라고 한다면 프로토콜은 약속이 실제로 작동하는 방식이다.

인터페이스는 계약들의 묶음이고 각 계약은 메서드 시그니처로 식별된다. 인터페이스에 묶여 있는 이 계약들은 서로 무관하지 않아서 상관관계나 종속관계 또는 인과관계를 갖기도 한다. 즉 서로 영향을 주고받는다.

그러므로 인터페이스를 구성하는 메서드 시그니처를 호출할 때에는 - 계약을 실행할 때에는 - 나름의 절차를 따라야 뒷탈 없이 깔끔하게 실행된다. 이러한 절차를 우리는 프로토콜이라 부른다.

그럼 왜 프로토콜이라는 단어를 썼을까?

그리스어 protokollon(πρωτόκολλον)에서 시작해 라틴어 protocolum을 거쳐 영어 protocol로 정착한 이 단어는 원래 문서 앞에 붙는 공식 기록을 뜻했고, 시간이 지나며 외교 의전과 같은 공식적인 절차나 시스템 사이의 상호작용 규칙을 의미하게 되었다.

인터페이스는 “무엇을 할 수 있는가”를 말하고,
프로토콜은 “어떻게 해야 하는가”를 말한다.

인터페이스가 있는데 프로토콜이 왜 또 필요한가에 대해서는 이렇게 말할 수 있겠다. 인터페이스는 "무엇을 할 수 있는가"를 정한다면 프로토콜을 "어떻게 사용해야 하는가"를 정한다고 말이다. 다음의 간단한 예를 하나 보면 직관적으로 어느 것이 올바른 흐름인지 이해할 수 있을 것이다.

이런 인터페이스가 있다고 하자.

connect()
send(message)
close()

위 인터페이스를 다음과 같이 1), 2)로 각각 호출 했다.

1) send(message) → connect() → close()
2) connect() → send(message) → close()

문제는 기능이 아니라 순서다.

고민하지 않고 봐도 1)은 거슬린다. 인터페이스 입장에서 보면 메서드 하나 하나는 아무 문제가 없다. 이들 메서드들을 호출하는 순서가 문제가 되는 것이다. 흐름의 질서를 지키지 않으면 거슬린다.

개발자는 프로토콜을 따른다. 설계자는 프로토콜을 만든다.

프레임워크는 인터페이스에 내재하는 프로토콜을 코드 구조로 강제하는 장치다. 개발자가 정해진 흐름 안에 코드를 넣도록 프로토콜을 설계한 것이다. 설계자는 프레임워크를 설계하기 전에 다음과 같은 질문을 먼저 해야 한다.

• 어떤 행위들이 존재하는가(계약)
• 각 행위는 어떻게 식별되는가(메서드 시그니처)
• 그 행위들이 어디에서 경계를 이루는가(인터페이스)
• 그 행위들이 어떤 흐름으로 연결되는가(프로토콜)

훌륭한 설계 원칙이 많이 있겠지만 이 원칙들을 관통하는 것은 "직관성"과 "흐름" 이 두 가지다.

시니어 개발자이자 아키텍트로서 소프트웨어의 근간이 되는 설계를 그 근본부터 되새기자는 의미로 네 개의 글을 썼다.

signature, contract, interface, protocol.
이 네 단어가 서로 맞물릴 때 비로소 하나의 아키텍처가 모습을 드러낸다.