기술사 학습노트 | imt-log

기술사 학습노트›소프트웨어공학›객체지향·CBD·AOP·MDA

Software Engineering · 정보관리기술사 / 컴퓨터시스템응용기술사

객체지향·CBD·AOP·MDA

소프트웨어 복잡도와 변경 비용을 줄이기 위해 객체 단위 캡슐화, 컴포넌트 조립, 횡단 관심사 분리, 모델 기반 자동화를 적용하는 대표 개발 패러다임 비교

정보관리기술사컴퓨터시스템응용기술사객체지향CBDAOPMDA컴포넌트기반개발관심사분리모델기반개발재사용성

Ⅰ. 개요 및 등장배경

가. 객체지향·CBD·AOP·MDA의 정의

객체지향(Object-Oriented)은 현실 세계의 개념과 업무 책임을 객체로 모델링하고, 객체가 상태와 행위를 함께 보유하도록 설계하는 개발 패러다임이다. 캡슐화, 상속, 다형성, 추상화를 통해 데이터와 기능을 결합하고, 객체 간 메시지 협력으로 시스템을 구성한다. 객체지향은 구조적 개발보다 변경 영향 범위를 줄이고 업무 개념을 코드 구조에 반영하기 쉬운 장점이 있다.

CBD(Component Based Development)는 독립적으로 배포·조립 가능한 컴포넌트를 중심으로 시스템을 개발하는 방식이다. 컴포넌트는 명확한 인터페이스와 계약을 제공하고 내부 구현을 감춘다. 개발자는 모든 기능을 처음부터 구현하기보다 검증된 컴포넌트를 선택, 조립, 확장하여 시스템을 구성한다. CBD는 재사용성, 생산성, 품질 일관성, 유지보수성을 높이는 데 목적이 있다.

AOP(Aspect Oriented Programming)는 핵심 업무 로직과 여러 모듈에 흩어지는 횡단 관심사를 분리하는 개발 기법이다. 로깅, 보안, 트랜잭션, 예외처리, 성능 측정, 감사, 캐싱처럼 여러 클래스에 반복 삽입되는 기능을 Aspect로 모듈화하고, Join Point, Pointcut, Advice, Weaving을 통해 필요한 실행 지점에 적용한다. AOP는 중복 코드 제거와 관심사 분리를 통해 유지보수성을 높인다.

MDA(Model Driven Architecture)는 플랫폼 독립 모델을 중심으로 시스템을 설계하고, 모델 변환을 통해 플랫폼 종속 모델과 코드 산출물을 생성하는 개발 접근이다. MDA는 OMG에서 제안한 모델 기반 아키텍처 개념으로, 비즈니스 모델과 기술 구현을 분리하여 플랫폼 변화에 대한 대응력을 높인다. 핵심 산출물은 CIM, PIM, PSM이며, 모델 변환 규칙과 코드 생성 도구가 중요한 역할을 수행한다.

나. 등장 배경

• 소프트웨어 복잡도 증가: 대규모 업무 시스템에서 기능, 데이터, 인터페이스, 운영 요구가 증가하며 단순 절차 중심 개발로 한계가 발생했다.
• 변경 대응 요구: 업무 규칙과 기술 플랫폼이 계속 변화하면서 변경 영향 범위를 줄이는 설계 방식이 필요해졌다.
• 재사용성 요구: 프로젝트마다 유사 기능을 반복 개발하는 비효율을 줄이기 위해 객체, 컴포넌트, 모델 재사용이 강조되었다.
• 관심사 혼재 문제: 보안, 로그, 트랜잭션 같은 공통 기능이 핵심 업무 코드에 섞이며 중복과 결합도가 증가했다.
• 플랫폼 변화 대응: 특정 언어와 프레임워크에 종속된 설계는 기술 전환 비용이 커서 모델 중심 추상화가 요구되었다.
• 개발 생산성 향상: 자동화, 표준화, 재사용, 코드 생성, 프레임워크 활용으로 개발 기간과 결함을 줄일 필요가 커졌다.

객체지향은 객체 책임, CBD는 컴포넌트 조립, AOP는 횡단 관심사 분리, MDA는 모델 기반 자동화에 초점을 둔다.

네 패러다임은 서로 대체 관계만이 아니라 대규모 시스템에서 함께 적용되어 재사용성, 유지보수성, 확장성을 높인다.

Ⅱ. 구성도 및 구성요소

가. 구성도

객체지향·CBD·AOP·MDA 연계 구조: 객체 책임에서 모델 자동화까지 구성도는 네 기법을 병렬 비교만 하지 않고, 객체가 컴포넌트로 묶이고, 공통 관심사가 Aspect로 분리되며, 상위 모델이 플랫폼 구현으로 변환되는 흐름을 보여준다.

표기
좌측: 객체지향 기반
중앙: CBD 조립·AOP 분리
우측: MDA 모델 변환
하단: 품질속성

객체지향업무 개념과 책임을 객체로 표현해 캡슐화, 다형성, 메시지 협력 구조를 만든다.

CBD명확한 인터페이스를 가진 컴포넌트를 조립해 재사용성과 배포 독립성을 높인다.

AOP로그, 보안, 트랜잭션처럼 여러 모듈에 흩어진 횡단 관심사를 Aspect로 분리한다.

MDA업무 모델과 플랫폼 구현을 분리하고 모델 변환으로 코드·설정 산출을 자동화한다.

나. 구성요소

구분	요소	설명
객체지향	Class·Object	속성과 행위를 함께 가지는 객체를 중심으로 업무 개념과 책임을 표현한다.
객체지향	캡슐화·상속·다형성	정보 은닉, 재사용, 동적 바인딩을 통해 변경에 유연한 구조를 제공한다.
CBD	Component	독립 배포와 재사용이 가능한 기능 단위로, 내부 구현보다 제공 인터페이스가 중요하다.
CBD	Interface·Contract	컴포넌트 간 연동 규격, 제공 기능, 요구 기능, 품질 조건을 명시한다.
AOP	Aspect	여러 모듈에 흩어지는 횡단 관심사를 하나의 모듈로 분리한 단위다.
AOP	Join Point·Pointcut·Advice	적용 가능한 실행 지점, 적용 대상 조건, 실제 삽입될 부가 기능을 정의한다.
MDA	CIM·PIM·PSM	업무 관점 모델, 플랫폼 독립 모델, 플랫폼 종속 모델로 추상화 수준을 구분한다.
MDA	Model Transformation	상위 모델을 하위 모델이나 코드로 변환하여 일관성과 자동화 수준을 높인다.
공통	재사용·유지보수·생산성	네 접근법 모두 복잡도 완화와 변경 대응, 재사용, 생산성 향상을 목표로 한다.

구성요소는 객체·클래스, 컴포넌트·인터페이스, Aspect·Pointcut·Advice, CIM·PIM·PSM·모델변환으로 정리된다.

객체지향의 최소 단위가 객체라면 CBD는 컴포넌트, AOP는 관심사, MDA는 모델을 중심 단위로 삼는다.

Ⅲ. 동작방식 및 아키텍처

가. 객체지향 동작방식

객체지향은 시스템을 기능 절차의 집합으로 보지 않고 상호작용하는 객체들의 협력 구조로 본다. 분석 단계에서는 업무 도메인에서 주요 객체를 식별하고, 설계 단계에서는 객체의 책임과 관계를 정의한다. 구현 단계에서는 클래스, 인터페이스, 상속, 조합, 다형성을 활용해 변경에 유연한 코드를 만든다. 예를 들어 결제 시스템에서 카드결제, 계좌이체, 포인트결제는 공통 결제 인터페이스를 구현하는 서로 다른 객체로 설계할 수 있다.

나. CBD 동작방식

CBD는 시스템을 재사용 가능한 컴포넌트 단위로 분해하고, 각 컴포넌트가 제공하는 인터페이스와 요구하는 인터페이스를 명확히 한 뒤 조립한다. 컴포넌트는 내부 구현을 감추고 외부에는 계약만 제공하므로 교체와 업그레이드가 상대적으로 쉽다. 컴포넌트 저장소를 통해 공통 컴포넌트를 재사용하고, 컴포넌트 간 의존성을 관리하며, 배포 단위를 분리할 수 있다. 현대 서비스 환경에서는 라이브러리, 패키지, 마이크로서비스, API, 플러그인 구조가 CBD 개념과 연결된다.

다. AOP 동작방식

AOP는 핵심 업무 로직과 횡단 관심사를 분리하여 실행 시점 또는 컴파일 시점에 결합한다. 예를 들어 주문 서비스, 결제 서비스, 회원 서비스마다 트랜잭션 시작·종료, 로그 기록, 권한 검사 코드가 반복된다면 유지보수 비용이 증가한다. AOP는 이 공통 기능을 Aspect로 정의하고, 특정 메서드 실행 전후 또는 예외 발생 시점에 Advice가 실행되도록 한다. 스프링 프레임워크의 선언적 트랜잭션, 보안 권한 검사, 로깅 인터셉터가 대표적 응용이다.

라. MDA 동작방식

MDA는 모델을 개발의 중심 산출물로 삼는다. 먼저 업무 요구와 비즈니스 프로세스를 CIM으로 표현하고, 기술 플랫폼에 독립적인 구조와 기능을 PIM으로 설계한다. 이후 Java, .NET, 클라우드, 모바일, DBMS 같은 특정 플랫폼을 반영한 PSM으로 변환하고, 코드와 설정 파일을 생성한다. 모델과 코드의 일관성을 유지하려면 모델 변환 규칙, 메타모델, 모델 검증, 코드 생성 템플릿, 수동 수정 통제가 필요하다.

마. 통합 적용 흐름 예시

전자상거래 시스템 통합 적용 예시 1. 객체지향: 주문, 결제, 회원, 배송, 쿠폰 객체와 책임 정의 2. CBD: 결제 컴포넌트, 배송 컴포넌트, 알림 컴포넌트를 인터페이스 기반으로 조립 3. AOP: 트랜잭션, 로그, 인증, 권한, 성능 측정을 Aspect로 분리 4. MDA: 주문 프로세스 모델과 도메인 모델을 PIM으로 설계 5. 변환: 특정 프레임워크와 DB에 맞는 PSM 및 코드 템플릿 생성 6. 효과: 핵심 업무 변경과 공통기능 변경, 플랫폼 변경의 영향 범위 축소

객체지향은 책임 배치, CBD는 조립과 재사용, AOP는 횡단 관심사 분리, MDA는 모델 변환과 자동화를 중심으로 동작한다.

현대 시스템에서는 객체지향 언어 위에서 컴포넌트와 Aspect를 활용하고, 모델·템플릿 기반 자동화로 생산성을 높이는 방식이 많다.

Ⅳ. 실무적용 및 사례

가. 엔터프라이즈 업무시스템 적용

대규모 업무시스템에서는 객체지향으로 도메인 책임을 분리하고, CBD로 공통 업무 컴포넌트를 구축하며, AOP로 트랜잭션과 보안을 분리한다. 예를 들어 인사관리 시스템에서 사원, 부서, 급여, 평가 객체를 설계하고, 인증 컴포넌트와 알림 컴포넌트를 공통으로 재사용한다. 급여 처리와 평가 승인에는 트랜잭션, 감사로그, 권한 검사를 AOP로 적용한다. 화면과 업무 프로세스는 모델링 도구로 정의하고 코드 템플릿을 생성하여 반복 개발을 줄일 수 있다.

나. 프레임워크 기반 개발 적용

스프링 기반 개발은 네 패러다임을 함께 활용하는 대표 사례다. Java 객체지향을 기반으로 도메인 객체와 서비스 객체를 설계하고, Bean과 모듈 단위로 컴포넌트를 구성한다. AOP를 통해 선언적 트랜잭션, 보안, 로깅, 모니터링을 적용한다. 또한 JPA Entity 모델, OpenAPI 명세, 코드 생성 도구, 템플릿 엔진을 활용하면 일부 MDA적 접근을 적용할 수 있다. 즉 프레임워크 자체가 객체지향, CBD, AOP, 모델 기반 개발 요소를 혼합 제공한다.

다. 마이크로서비스 적용

마이크로서비스 아키텍처에서는 서비스가 큰 컴포넌트 역할을 수행한다. 각 서비스는 독립 배포 가능하고 API 계약으로 연동된다. 내부 구현은 객체지향으로 구성되고, 공통 관심사인 인증, 로깅, 추적, 회복탄력성, 모니터링은 AOP, 인터셉터, 서비스 메시, API Gateway로 분리될 수 있다. 모델 기반 접근은 OpenAPI, AsyncAPI, 스키마 정의, 도메인 이벤트 모델을 기반으로 코드와 문서를 생성하는 방식으로 활용된다.

라. 실무 체크포인트

• 객체 책임 명확화: 데이터 중심 객체가 아니라 책임과 행위를 가진 도메인 객체로 설계해야 객체지향 효과가 난다.
• 컴포넌트 경계 정의: 컴포넌트 재사용을 위해 인터페이스, 버전, 의존성, 배포 단위, 품질속성을 명확히 한다.
• AOP 과용 방지: Advice가 많아지면 실행 흐름 추적이 어려워지므로 핵심 업무 로직과 직접 관련 없는 공통 기능에 제한적으로 적용한다.
• 모델-코드 일관성: MDA 적용 시 모델과 실제 코드가 분리되어 불일치하지 않도록 생성 범위와 수동 수정 규칙을 정한다.
• 도구 의존성 관리: 특정 모델링 도구나 코드 생성기에 과도하게 종속되면 장기 유지보수 위험이 발생한다.
• 재사용 경제성 검토: 재사용 가능성이 낮은 기능을 과도하게 컴포넌트화하면 오히려 설계 비용이 증가한다.
• 품질속성 균형: 재사용성, 성능, 단순성, 테스트 가능성, 배포 독립성 사이의 균형을 고려한다.

실무에서는 객체지향으로 도메인을 설계하고, CBD로 공통 기능을 조립하며, AOP로 공통 관심사를 분리하고, MDA로 반복 산출을 자동화한다.

효과를 얻으려면 패러다임 명칭보다 경계, 책임, 인터페이스, 공통기능 분리, 모델-코드 일관성 관리가 중요하다.

Ⅴ. 비교분석 및 발전전망

가. 객체지향·CBD·AOP·MDA 비교

구분	객체지향	CBD	AOP	MDA
중심 단위	객체·클래스	컴포넌트	Aspect	모델
주요 목적	업무 책임과 데이터 캡슐화	재사용 가능한 기능 단위 조립	횡단 관심사 분리	플랫폼 독립 설계와 자동 변환
핵심 개념	캡슐화, 상속, 다형성, 추상화	인터페이스, 계약, 조립, 배포	Join Point, Pointcut, Advice, Weaving	CIM, PIM, PSM, 모델변환
장점	도메인 표현력과 변경 대응력	재사용성, 생산성, 품질 일관성	중복 제거와 관심사 분리	플랫폼 변화 대응과 코드 생성
한계	상속 남용과 객체 과다 설계 위험	컴포넌트 경계 설정과 버전관리 어려움	흐름 추적 어려움과 디버깅 복잡도	도구 의존성과 모델-코드 불일치
대표 사례	도메인 모델, 디자인 패턴	라이브러리, 모듈, 마이크로서비스	트랜잭션, 로깅, 보안	UML 모델 변환, 코드 생성, DSL

나. 적용 관점 비교

관점	적합한 접근	설명
업무 개념 복잡	객체지향	도메인 객체와 책임을 명확히 하여 업무 규칙을 코드 구조에 반영한다.
공통 기능 반복 개발	CBD	인증, 알림, 결제, 파일, 로그 같은 기능을 컴포넌트화하여 재사용한다.
공통 관심사 산재	AOP	보안, 트랜잭션, 감사, 예외처리 같은 기능을 핵심 로직에서 분리한다.
플랫폼 전환 가능성 큼	MDA	비즈니스 모델과 플랫폼 구현을 분리하여 기술 변화에 대한 전환 비용을 줄인다.
대규모 표준 개발	CBD + MDA	표준 컴포넌트와 코드 생성 템플릿을 결합하여 생산성을 높인다.
엔터프라이즈 프레임워크	객체지향 + AOP + CBD	객체 모델과 컴포넌트 컨테이너, 선언적 공통 기능 적용을 결합한다.

다. 발전전망

• 마이크로서비스와 CBD 결합: 서비스가 독립 배포 가능한 컴포넌트로 기능하며 API 계약과 버전 관리가 중요해진다.
• 프레임워크 내 AOP 내재화: 트랜잭션, 보안, 관측가능성, 캐싱, 재시도 정책이 프레임워크와 서비스 메시로 흡수된다.
• 모델 기반 자동화 확산: OpenAPI, AsyncAPI, GraphQL Schema, IaC, DSL 기반 코드·문서·테스트 생성이 증가한다.
• 도메인 중심 객체지향 강화: 빈약한 데이터 객체보다 DDD 기반 도메인 모델과 책임 중심 설계가 강조된다.
• Low-code·No-code 연계: 모델 기반 화면, 워크플로우, 데이터 정의가 코드 생성과 운영 자동화로 이어진다.
• AI 기반 설계 보조: 생성형 AI가 모델 초안, 컴포넌트 후보, 공통 관심사 분리, 코드 생성 보조에 활용된다.

라. 답안 작성 관점

• 정의에서는 객체, 컴포넌트, Aspect, 모델을 각각 중심 단위로 하는 개발 패러다임이라고 정리한다.
• 구성도는 객체지향 기반 설계, CBD 조립, AOP 횡단 관심사, MDA 모델 변환을 연계 흐름으로 표현한다.
• 비교표는 중심 단위, 목적, 핵심 개념, 장점, 한계, 대표 사례를 기준으로 작성한다.
• 실무 사례는 스프링 기반 엔터프라이즈 시스템, 마이크로서비스, 코드 생성 도구, 공통 컴포넌트 플랫폼을 연결한다.
• 한계는 상속 남용, 컴포넌트 경계 오류, AOP 흐름 추적 어려움, MDA 도구 종속성과 모델 불일치를 제시한다.

객체지향·CBD·AOP·MDA는 소프트웨어 복잡도를 다른 관점에서 낮추는 상호 보완적 개발 패러다임이다.

기술사 답안에서는 네 개념의 중심 단위와 해결 문제를 비교하고, 현대 프레임워크와 마이크로서비스·모델 자동화 사례로 연결해야 한다.

블로그: 기술사 학습노트 · imt-log.tistory.com

← [소프트웨어공학] 목록