불변 조건 (Invariant)

정의

객체/시스템이 어떤 시점에도 반드시 만족해야 하는 규칙입니다.

“변하지 않는 값”이 아니라, 변화가 있더라도 항상 지켜져야 하는 상태의 조건을 말합니다.

예를 들어 계좌 잔액은 입금/출금으로 계속 변하지만, 잔액은 0 미만이 되면 안 된다 같은 규칙은 항상 유지되어야 합니다.

객체지향에서 불변 조건은 품질을 좌우합니다.

불변 조건이 깨지면 그 순간부터 데이터는 “신뢰할 수 없는 상태”가 되고, 버그는 화면이 아니라 정합성(데이터 무결성) 문제로 커집니다.

핵심 메시지

“불변 조건은 객체의 신뢰도다.
한 번 깨지면, 이후 계산은 전부 의심해야 한다.”

- 데이터는 ‘항상 맞다’는 믿음 위에 쌓인다 -

왜 중요한가?

불변 조건은 버그를 “발생 후” 잡는 게 아니라, “발생 자체를” 막습니다.

👍 GOOD (불변 조건이 살아있는 코드)

• 객체가 생성될 때부터 유효한 상태만 허용
• 상태 변경은 메서드를 통해서만 가능(검증 포함)
• 불변 조건이 코드로 강제되어 “깨질 수가 없음”
• 호출자는 객체를 믿고 로직을 단순하게 작성 가능

👎 BAD (불변 조건이 깨지기 쉬운 코드)

• setter로 아무나 상태 변경 가능
• 검증이 서비스/컨트롤러 등 외부로 흩어짐
• “나중에 검증” → 이미 DB에 잘못된 값이 들어감
• 결국 코드 곳곳에 if로 방어 로직이 늘어남

대표 예시

실무에서 자주 등장하는 불변 조건들

도메인	불변 조건	깨지면 생기는 문제
계좌/포인트	잔액/포인트는 0 이상	음수 포인트, 정산 오류, 금전 사고
주문(Order)	상태 전이는 순서를 지켜야 함	PAID 없이 SHIPPED, 취소 불가 상태에서 취소 등
재고(Stock)	재고 수량은 0 이상	초과 판매, 환불/클레임 폭증
권한/보안	권한 없으면 접근 불가	보안 취약점, 데이터 유출

실전 예시

불변 조건을 “객체 내부”에서 강제하기

// 예시: 잔액(balance)은 어떤 상황에서도 0 미만이 될 수 없다 (불변 조건)
class Account {
	private int balance;
    public Account(int initial) {
    	if (initial < 0) throw new IllegalArgumentException("balance must be >= 0");
        this.balance = initial;
    }
    public void deposit(int amount) {
    	if (amount <= 0) throw new IllegalArgumentException("amount must be > 0");
        this.balance += amount; 
    }
    public void withdraw(int amount) {
    	if (amount <= 0) throw new IllegalArgumentException("amount must be > 0");
        if (this.balance < amount) throw new IllegalStateException("insufficient balance");
        this.balance -= amount;
    }
    public int balance() {
    	return balance;
    }
} 
// 핵심: "balance >= 0" 규칙이 객체 밖으로 새지 않게 만든다.

💡 TIP / 참고사항

불변 조건을 지키는 가장 강력한 방법은 “상태 변경 경로를 줄이는 것”입니다.
즉, 필드 직접 수정 금지 + 의미 있는 메서드로만 변경 + 생성 시점부터 유효한 값만 허용이 3종 세트입니다.

 

불변 조건 vs 불변 객체

둘은 비슷해 보이지만 개념이 다릅니다.

구분	의미	예시
불변 조건	항상 만족해야 하는 규칙	잔액은 0 이상, 주문 상태는 순서대로 전이
불변 객체	생성 후 상태가 안 바뀌는 객체	Money(금액), LocalDateTime, 값 객체(Value Object)

✅ 핵심 요약

• ✔️ 불변 조건은 객체/시스템이 언제나 만족해야 하는 규칙이다.
• ✔️ 불변 조건이 깨지면 데이터 신뢰가 무너지고, 정합성/보안/금전 사고로 이어질 수 있다.
• ✔️ 가장 좋은 방법은 객체 내부 메서드로만 상태를 변경하게 해서 규칙을 강제하는 것이다.