Eiffel — 계약에 의한 설계(Design by Contract)를 언어 차원에서 박은 OO 언어

1. 요약

Eiffel은 1986년 Bertrand Meyer가 설계·발표한 순수 객체지향 언어이다. Design by Contract (DbC) — *사전 조건(precondition)·사후 조건(postcondition)·클래스 불변식(invariant)*을 언어 문법 차원에서 박은 — 사상으로 가장 잘 알려져 있다. Meyer가 1988년 박은 *Object-Oriented Software Construction(OOSC)*은 OO 시대의 가장 영향력 있는 교과서 중 하나가 되었다(2판 1997). ISO 표준은 ECMA-367(2005, 개정 2006)으로 기록되었다. 산업적 보급은 C++/Java보다 훨씬 작았지만, 사상적 영향은 이후 모든 OO 언어와 형식적 방법론에 깊이 기록되었다.

2. 등장 배경

Bertrand Meyer는 1985년 Eiffel을 구상했고, 상용 소프트웨어의 신뢰성 향상을 명시적 목표로 삼았다. 다른 OO 언어들의 한계를 그가 본 시각:

• Smalltalk: 사상은 좋지만 동적 타입이라 컴파일 시점에 오류를 잡지 못함.
• C++: C와의 호환성에 묶여 깔끔한 OO를 만들지 못함. 다중 상속의 Diamond 문제.
• Ada (당시): 절차형에서 OO로의 전환이 부분적.

Meyer는 Hoare Logic(C.A.R. Hoare, 1969)의 사전조건·사후조건 검증을 실용 언어로 옮겨오자는 결심으로 Eiffel을 설계했다. 프랑스 토목공학자 Gustave Eiffel(에펠탑 설계자)에서 이름을 따 — 공학적 신뢰성을 강조하는 의미.

1986년 첫 버전 발표 → 1988년 OOSC 1판 출간. Meyer가 설립한 Eiffel Software(원래 ISE — Interactive Software Engineering)가 처리계 개발과 보급을 담당.

3. 핵심 특징

1. 계약에 의한 설계 (Design by Contract) — 가장 결정적 특징.
   • require (사전 조건): 메소드 호출 시 만족해야 할 조건.
   • ensure (사후 조건): 메소드 실행 후 보장해야 할 조건.
   • invariant (클래스 불변식): 객체 수명 동안 항상 참이어야 할 조건.
   • 이 셋이 주석이 아니라 언어 문법. 컴파일러가 런타임 검증을 자동 삽입.
2. 다중 상속 + 이름 변경(Multiple Inheritance with Renaming) — Diamond 문제를 renaming·redefining·undefining 으로 해결. C++보다 형식적이고 명확.
3. 제네릭 프로그래밍(Generics) — 매개변수화된 타입(LIST [INTEGER]). C++ 템플릿보다 *제약 있는 제네릭(constrained generics)*을 형식적으로 지원.
4. 균일한 접근 + 명령-질의 분리(Uniform Access & Command-Query Separation) — 속성과 계산된 값이 동일한 표기로 접근. 질의는 상태를 바꾸지 않고·명령은 값을 반환하지 않음. 이 원칙은 후일 함수형 프로그래밍과 불변성 사상의 직접 조상.
5. 정적 타입 + Void Safety — 컴파일 시점 null reference 차단(attached types). Java/C#의 Optional·Kotlin의 Nullable Type보다 30년 앞섬.

4. 주 용도

• 금융·은행 시스템: 신뢰성이 결정적인 영역. EiffelStudio가 대형 금융 백엔드에 사용됨.
• 방위 산업: 일부 유럽 방위 프로젝트.
• 교육: Meyer가 ETH Zürich에서 가르친 대규모 소프트웨어 공학 과정의 표준 언어. OOSC 책이 OO 교과서로 광범위하게 사용됨.

5. 그 시대 설계 도구 매핑

Eiffel은 언어와 설계 사상이 거의 분리되지 않은 또 다른 사례이다. 언어 자체가 설계 도구의 형식화에 가깝다.

→ Hoare Logic → Eiffel → 현대 정형 검증의 다리: Hoare Logic의 사전·사후조건 검증은 순수 수학적 형식 방법이었다. Eiffel은 이것을 실용 OO 언어로 박은 거의 유일한 사례. 이 다리는 후일 Spec#(Microsoft, 2003)·JML (Java Modeling Language)·Dafny(Microsoft, 2008)·Liquid Haskell·Rust + Prusti 등 현대 정형 검증 언어로 이어진다.

6. 강의 활용

핵심 명제와의 연결: Eiffel은 No Design, No Code의 극단적 해석이다 — 명세 자체를 코드 안에 기록한다. 즉 설계 문서가 따로 있지 않고, 코드의 require/ensure/invariant가 곧 설계. 언어가 설계 도구를 흡수한 거의 유일한 사례.

강의에서의 위치: G4 시리즈의 형식적 정점. Smalltalk(사상)·C++(산업)·Java(대중)·Python(AI 시대 공용어)가 주류 흐름이라면, Eiffel은 형식 검증의 다리 역할 — 산업적으로 작지만 사상적으로 결정적.

오늘날의 흔적:

• JML (Java Modeling Language): Java 메소드 위에 주석으로 requires/ensures를 기록. Eiffel의 정신이 Java로 옮겨감.
• Spec#·Dafny·F*: Microsoft Research가 Eiffel + Hoare Logic을 더 깊게 박은 정형 검증 언어들.
• Rust의 assert!·debug_assert!·계약 검증 라이브러리: Eiffel 계약 사상의 일부.
• TypeScript의 type predicate·assertion function: 정적 검증으로 약화된 형태의 계약.
• Pre/Post-Condition Testing: 모든 단위 테스트 프레임워크의 Arrange-Act-Assert는 Eiffel 계약의 정신.

오늘 LLM 시대로의 다리: 본 강의에서 가장 중요한 사상적 다리. Spec-Driven Development for AI Agent는 Eiffel의 Design by Contract의 직접 후예다.

즉 Eiffel이 인간 프로그래머에게 박은 명세 사상을 AI Agent에게 기록하는 프롬프트 + Spec 마크다운이 LLM 시대 그대로 옮겨오고 있다. No Design, No Code는 No Contract, No Method Call이라는 Eiffel 정신의 LLM 시대 표현.

출처

• Wikipedia, "Eiffel (programming language)", https://en.wikipedia.org/wiki/Eiffel_(programming_language)
• Meyer, B. (1988/1997). Object-Oriented Software Construction (1st/2nd ed.). Prentice Hall.
• Meyer, B. (1992). "Applying 'Design by Contract'". IEEE Computer, 25(10), 40-51.
• Hoare, C. A. R. (1969). "An Axiomatic Basis for Computer Programming". Communications of the ACM, 12(10), 576-580.
• ECMA-367. (2006). Eiffel Analysis, Design and Programming Language (2nd ed.).
• Walden, K., & Nerson, J.-M. (1995). Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems. Prentice Hall.

그룹 시리즈

→ synthesis/group-g4 (시대 그룹 종합 카드)