계약에 의한 설계(design by contract)란 무엇인가요?

Question

Accepted Answer

**계약에 의한 설계(Design by Contract, DbC)**는 메서드와 호출자 사이의 관계를 형식적 합의로 취급하며, 세 가지로 정의됩니다: **선행 조건(precondition)**(호출자가 보장해야 하는 것), **후행 조건(postcondition)**(메서드가 그 대가로 보장하는 것), 그리고 **불변식(invariant)**(객체에 대해 항상 참인 것).

## 세 가지 의무

```text
선행 조건  → 호출자의 의무: 메서드가 올바르게 실행되기 위해 요구하는 입력/상태
후행 조건  → 메서드의 의무: 반환 시 약속하는 것 (선행 조건이 성립했다면)
불변식     → 객체의 항상 참인 속성, 모든 메서드 전후로
```

## 코드로

```python
class Account:
    def __init__(self, balance):
        self._balance = balance
        self._check_invariant()

def withdraw(self, amount):
        assert amount > 0, "PRE: amount must be positive"        # 선행 조건
        assert amount <= self._balance, "PRE: sufficient funds"  # 선행 조건
        old = self._balance
        self._balance -= amount
        assert self._balance == old - amount, "POST: balance reduced"  # 후행 조건
        self._check_invariant()

def _check_invariant(self):
        assert self._balance >= 0, "INVARIANT: balance never negative"
```

*선행 조건*이 실패하면 **호출자**에게 버그가 있습니다. *후행 조건*이나 *불변식*이 실패하면 **메서드**에 버그가 있습니다 — 계약은 책임을 정확히 짚어냅니다.

## LSP와의 관계

DbC는 Liskov를 정밀하게 만듭니다: 서브타입은 **선행 조건을 약화**하고 **후행 조건을 강화**할 수 있지만, 그 반대는 결코 안 됩니다. 그것이 정확히 대체 가능성 규칙을 계약으로 표현한 것입니다.

## 트레이드오프

```text
✓ 버그가 경계에서 명확한 책임과 함께 드러남   ✓ 계약은 문서 역할도 함
⚠️ 런타임 검사는 성능 비용 (흔히 assertion 으로 운영에서 비활성화)
⚠️ 모든 언어가 기본 지원하지 않음 (Eiffel 은 함; 대부분 assert/검증 사용)
```

## 왜 중요한가

계약은 모호한 가정("amount는 양수여야 할 것 같다")을 명시적이고 검사 가능한 규칙으로 바꾸며 — 무언가 깨질 때 책임을 정확히 할당합니다.

이들은 Liskov 대체와 견고한 API 설계의 기반이 됩니다: 메서드의 계약은 그 진정한 인터페이스이며, 타입 시그니처만보다 더 정직합니다.