
AI 시대이기 때문에 더욱 Design by Contract와 불변 조건(Invariant)을 배워야 하는 이유
요약
AI가 코드를 작성하는 시대에는 '어떻게 구현할 것인가'보다 '무엇을 지켜야 하는가'를 정의하는 능력이 중요합니다. 이를 위해 Design by Contract(DbC)와 Invariant(불변 조건)를 통해 명확한 비즈니스 규칙을 설계해야 합니다.
핵심 포인트
- AI는 구현 능력은 뛰어나지만 비즈니스 규칙을 스스로 추측할 수 없음
- Design by Contract를 통해 사전 조건과 사후 조건을 명확히 정의해야 함
- 시스템의 안정성을 위해 도메인 모델 수준에서 Invariant(불변 조건)를 보장해야 함
- 단순한 입력 검증(Validation)을 넘어 도메인 규칙 자체를 설계에 반영해야 함
AI가 코드를 작성하는 시대가 되었습니다.
Claude Code나 GitHub Copilot을 사용하면 CRUD 구현이나 API 생성은 몇 분 만에 완료됩니다.
하지만 최근, AI에게 구현을 맡길수록 강하게 느끼는 점이 있습니다.
"AI는 코드를 작성할 수 있지만, 올바른 코드는 인간이 정의해야 한다"
라는 것입니다.
그리고 이를 위해 중요해지는 것이 바로 Design by Contract (계약에 의한 설계) 와 Invariant (불변 조건) 입니다.
예를 들어 AI에게 다음과 같이 의뢰합니다.
회원가입 API를 구현해 주세요
그러면 AI는 높은 정밀도로 구현합니다.
@PostMapping("/users")
public ResponseEntity<Void> register(
@RequestBody RegisterUserRequest request) {
...
하지만 여기서 AI가 알 수 없는 것들이 있습니다.
- 이메일 주소는 중복 가능한가
- 탈퇴한 사용자는 재가입이 가능한가
- 미성년자는 가입이 가능한가
- 법인 사용자는 대상에서 제외인가
이것들은 코드만으로는 추측할 수 없습니다.
즉 AI는,
"어떻게 구현할 것인가"
는 잘하지만,
"무엇을 지켜야 하는가"
는 인간이 정의해야 합니다.
Design by Contract (DbC)는 소프트웨어를 "계약"으로 설계하는 사고방식입니다.
대표적인 계약은 3가지가 있습니다.
| 종류 | 내용 |
|---|---|
| 사전 조건 (Precondition) | 호출 전에 충족해야 하는 조건 |
| ... |
예를 들어 은행 송금이라면,
송금 금액 > 0
잔액이 송금 금액만큼 감소함
계좌 잔액은 항상 0 이상
입니다.
DDD에서도 중요하게 여겨지는 것이 Invariant입니다.
왜냐하면,
시스템이 망가지는 원인의 대부분은 불변 조건의 파괴이기 때문입니다.
예를 들어 환불 시스템을 생각해 봅시다.
환불 상태는 다음과 같이 관리되고 있다고 가정합니다.
public enum RefundStatus {
WAITING,
PROCESSING,
...
하지만 실제로는,
환불 성공인데 환불 금액이 0원
이라는 상태는 허용되지 않습니다.
즉 정말로 지켜야 할 규칙은
SUCCESS라면 환불 금액 > 0
입니다.
이것이 Invariant입니다.
흔히 사용하는 구현 방식은 DTO 검증 (Validation)입니다.
@NotNull
@Positive
private BigDecimal amount;
물론 유효합니다.
하지만 이것은 입력 체크일 뿐입니다.
정말로 중요한 것은 도메인 모델 (Domain Model) 측입니다.
public class Refund {
private final RefundStatus status;
private final BigDecimal amount;
...
이렇게 하면,
어떤 API에서 호출되더라도,
어떤 배치 (Batch)에서 호출되더라도,
Invariant가 지켜집니다.
실제 업무 시스템에는 방대한 양의 Invariant가 있습니다.
예를 들어 EC 사이트.
주문 확정 후에는 상품 수량을 변경할 수 없음
회원 관리.
탈퇴한 사용자는 로그인할 수 없음
결제 시스템.
환불 금액 <= 결제 금액
은행 송금.
잠금(Lock) 상태인 계정은 송금할 수 없음
이것들은 단순한 검증 (Validation)이 아닙니다.
업무 규칙 그 자체입니다.
그리고 AI는 업무 규칙을 추측할 수 없습니다.
기존에는 인간이 코드를 작성했습니다.
그렇기 때문에,
구현자 스스로가 암묵적으로 규칙을 이해하고 있었습니다.
하지만 AI 시대는 다릅니다.
구현 담당은 AI가 됩니다.
AI는 계약이 주어지면 그것을 지킵니다.
반대로 계약이 없다면 마음대로 해석합니다.
예를 들어 Claude Code에게 의뢰할 때,
/**
* Invariant:
*
...
라고 적어두면,
AI는 그 제약 사항을 고려하여 구현할 수 있습니다.
즉 Design by Contract는,
인간 사이를 위해서뿐만 아니라,
AI에게 설계 의도를 전달하기 위한 사양서 (Specification)
가 되기도 합니다.
AI에 의해 코드를 작성하는 비용은 대폭 낮아졌습니다.
하지만,
무엇을 지켜야 하는지를 정의하는 책임은 인간에게 남습니다.
따라서 앞으로는,
- 사전 조건 (Precondition)
- 사후 조건 (Postcondition)
- 불변 조건 (Invariant)
를 명확하게 정의할 수 있는 엔지니어의 가치가 높아질 것입니다.
AI 시대에 필요한 것은,
코드를 작성하는 능력만이 아닙니다.
"시스템이 지켜야 할 계약을 정의하는 능력"
입니다.
그리고 그 기초가 되는 것이 Design by Contract와 불변 조건 (Invariant)이라고 생각합니다.
※ 본 기사는 2026년 5월 개최되는 JJUG CCC 2026 Spring에서 얻은 배움을 바탕으로 정리한 내용입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기