갹체가 사는 법 #2. 계약 - 자유를 줄이고 예측 가능성을 만드는 방식

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

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)

계약은 약속이 아니라, 예측 가능성을 만드는 설계의 장치다.

이전 글에서 메서드 시그니처를 계약에 남긴 서명이라고 했다. 그렇다면 자연스럽게 이런 질문이 따라온다. 도대체 이 코드 속에서 말하는 '계약'이란 무엇일까.

contract라는 단어는 단순히 '계약'으로 번역하면 그 의미가 충분히 와닿지 않는다. 그래서 그 어원을 따라가 보면, 라틴어 contrahere는 '함께(con-)'와 '끌다(trahere)'의 결합으로 이루어져 있다. 이 단어는 결국, '서로를 하나의 관계 안으로 끌어당긴다'는 의미를 갖는다.

그리고 이렇게 형성된 관계는, 그 안에서 각자의 행동에 일정한 제한을 만든다. 그래서 contract는 단순한 약속이 아니라, '서로를 하나의 관계 안으로 묶고 그 안에서 행동의 범위를 제한하는 약속'이다.

복잡한 시스템을 사람이 이해하고 다룰 수 있는 수준으로 유지

이때 중요한 것은, 이러한 제한이 단순한 제약으로 끝나지 않는다는 점이다. 계약은 자유를 줄이는 대신, 그 대가로 예측 가능성을 만들어낸다. 그리고 이 예측 가능성은, 소프트웨어를 설계하는 데 있어 생각보다 훨씬 중요한 의미를 갖는다.

소프트웨어 공학의 본질은 결국, 복잡한 시스템을 사람이 이해하고 다룰 수 있는 수준으로 유지하는 데 있기 때문이다. 시스템이 커질수록, 모든 것을 자유롭게 두는 방식은 더 이상 작동하지 않는다. 각 구성 요소가 어떻게 동작할지 예측할 수 있어야 하고, 그 위에서 다른 요소들이 안심하고 의존할 수 있어야 한다.

그런 의미에서 contract는 단순한 약속이 아니라, 서로를 신뢰할 수 있게 만드는 최소한의 조건이다. 결국 그 신뢰 위에서만, 우리는 필요한 만큼의 자유를 내려놓고 통제 가능한 복잡성을 만들어낼 수 있다.

메서드 시그니처, 계약 그리고 인터페이스

메서드 시그니처라는 서명은, 바로 이 계약을 코드 위에 드러내는 방식이다. 이렇게 드러난 계약들이 모여 하나의 구조를 이룰 때, 우리는 그것을 인터페이스라고 부른다. 소프트웨어 설계에서 말하는 또 하나의 중요한 개념, 바로 그 interface 말이다.