객체지향의 본질과 전 단계 적용 방안

초록

본 논문은 객체지향의 핵심 개념인 추상화를 구현 단계에만 국한하지 않고, 요구 분석, 설계, 테스트 등 소프트웨어 개발 전 단계에 적용할 수 있는 방법론을 제시한다. 객체지향이 혼동을 일으키는 원인과 추상화의 정의를 명확히 하고, 이를 기반으로 전 단계에서의 일관된 모델링과 의사소통을 가능하게 한다.

상세 분석

논문은 먼저 객체지향이 “추상화”라는 단일 핵심 개념에 의해 정의된다고 주장한다. 기존 문헌에서는 캡슐화, 상속, 다형성 등을 별개의 원칙으로 나열하지만, 저자는 이들을 모두 추상화의 구현 메커니즘으로 재해석한다. 추상화는 “관심사의 분리”와 “공통된 행동·속성의 일반화”를 의미하며, 이는 요구사항 정의 단계에서 도메인 개념을 식별하고, 설계 단계에서 클래스와 인터페이스를 도출하며, 구현 단계에서 실제 코드로 구체화되는 일련의 연속적인 과정이다.

다음으로 객체지향 적용의 혼란 요인을 두 가지로 구분한다. 첫째, 추상화 수준의 불명확성이다. 개발자는 종종 구현에 초점을 맞추어 추상화가 충분히 이루어지지 않은 상태에서 클래스 설계를 시작한다. 둘째, 객체지향을 특정 언어나 프레임워크에 종속시켜 생각하는 경향이다. 이러한 시각은 객체지향의 본질을 “코드 구조”에 국한시키고, 초기 단계인 요구 분석이나 테스트 설계에서 객체지향적 사고를 배제한다.

저자는 이러한 문제를 해결하기 위해 “전 단계 객체지향 모델링(OO‑Model‑Across‑Phases)”이라는 프레임워크를 제안한다. 이 프레임워크는 1) 도메인 추상화, 2) 책임과 협력 정의, 3) 인터페이스 계약 명세, 4) 구현 구체화의 네 단계로 구성된다. 각 단계는 이전 단계의 추상화를 그대로 이어받으며, UML 클래스 다이어그램, 시퀀스 다이어그램, 계약 기반 테스트 케이스 등 다양한 표현 수단을 활용한다. 특히 계약 기반 테스트는 객체의 행동을 사전에 명세함으로써 설계와 구현 사이의 간극을 메운다.

마지막으로 논문은 객체지향 추상화를 조직 문화와 프로세스에 통합하는 방안을 논의한다. 스프린트 회의에서 “객체 책임”을 토론하고, 코드 리뷰 시 “추상화 적합성”을 평가 지표로 삼는 것이 예시이다. 이러한 실천은 개발 팀이 객체지향을 기술적 선택이 아닌 사고 방식으로 내재화하도록 돕는다.