객체가 사는 법 #1. 메서드 시그니처 - 계약에 남긴 서명

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

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)

객체지향 언어에 대한 글을 읽다 보면 다형성의 한 가지로 오버로딩(overloading)이라는 용어를 만나게 된다. 오버로딩은 메서드 이름은 같지만 매개변수의 개수, 순서, 형식이 다른 경우를 말한다. 그리고 이를 설명할 때 흔히 이렇게 말한다.

“메서드 시그니처가 다르다.”

그렇다. 메서드의 시그니처가 다르기 때문에 오버로딩이 가능하다. 매개변수의 구성이 다른 것을 시그니처가 다르다라고 설명하는 것이다. 그런데 여기서 문득 궁금해진다.

왜 하필 “시그니처(signature)”라는 단어를 쓴 것일까?

안타깝게도 많은 글들이 개념 설명은 해주지만 왜 이런 용어가 쓰였는지까지는 잘 이야기하지 않는다. 그래서 이 단어의 의미를 한 번 거슬러 올라가 보았다. 우선 signature의 어원을 살펴보자. 라틴어 signatura에서 중세 라틴어를 거쳐 프랑스어와 영어 signature로 정착했다.

이를 형태소로 나누어 보면 다음과 같다.

sign + ature

• sign : 표시, 기호
• ature : 행위의 결과나 상태를 나타내는 접미사

그래서 signature는 문자 그대로

“표시한 결과물”, “어떤 것을 표시하는 행위”

라는 뜻을 갖는다. 우리가 흔히 말하는 서명도 바로 여기에서 나왔다. 문서에 서명을 한다는 것은 단순히 이름을 쓰는 행위가 아니다. 그 문서의 내용을 누가 책임지는지, 즉 그 누구의 정체성을 남기는 표시다. 이렇게 생각해 보면 메서드 시그니처라는 표현이 자연스럽게 이해된다.

메서드 시그니처는 단순한 문법 요소가 아니라

어떤 메서드인지를 식별하는 표시

라고 볼 수 있기 때문이다. 그래서 같은 이름의 메서드라도

• 매개변수의 개수
• 매개변수의 타입
• 매개변수의 순서

가 다르면 서로 다른 시그니처가 되고, 결과적으로 서로 다른 메서드로 식별된다. 그런데 시그니처라는 단어를 채택한 한 가지 더 흥미로운 배경이 있다. 바로 메서드는 일종의 계약(contract)이라는 관점이다.

메서드는 호출하는 쪽과 실행하는 쪽 사이의 약속이다.

• 어떤 이름으로 호출하고
• 어떤 형태의 입력을 받으며
• 어떤 결과를 돌려주는지

에 대한 암묵적인 계약인 셈이다. 이렇게 보면 두 개념의 역할이 분명해진다.

signature : "어떻게 부르는가", "어떤 메서드를 식별하는가"
contract  : "무엇을 보장하는가", "어떤 결과를 기대할 수 있는가"

즉 signature는 계약을 식별하는 표식이고, contract는 그 계약의 내용이라고 볼 수 있다.

결국 메서드 시그니처는 단순한 문법이 아니라, 코드속 계약에 남겨진 하나의 서명이다. 그리고 그 서명이 바뀌는 순간, 그 메서드의 계약도 함께 바뀐다.