Study
oriented
구루마3단
2025. 4. 15. 18:39
"oriented"는 "기초한"이라는 의미로 쓰이기도 하지만, 더 정확하게는 "지향하는", "중심을 두는"이라는 뜻입니다.
문맥에 따라 약간씩 해석이 달라지긴 하지만, 단순한 기초(based on)보다 더 능동적인 성향을 포함합니다.
✅ oriented의 기본 의미
| 표현 | 의미 | 해석 방식 |
|---|---|---|
| oriented | ~을 지향하는, 중점을 둔 | 중심이 어디에 맞춰져 있는가 |
📌 주요 예시
| 용어 | 의미 | 해석 |
|---|---|---|
| Object-Oriented Programming | 객체 중심 프로그래밍 | "객체를 중심으로 설계된" |
| Customer-Oriented | 고객 지향적 | "고객을 우선시하는", "고객 중심의" |
| Goal-Oriented | 목표 지향적 | "목표를 달성하는 데 초점을 맞춘" |
✅ vs. based on (기초한)
| 표현 | 의미 차이 |
|---|---|
| based on | 단순한 기반, 기초 위에 있음 → 수동적 |
| oriented | 지향, 방향성, 목적성 포함 → 능동적 |
예를 들어:
Object-based는 단순히 객체 구조만 따르는 것Object-oriented는 객체라는 개념 자체를 설계의 중심 철학으로 삼음
🔁 기억법
oriented= "어디를 바라보고 있느냐"based= "어디 위에 서 있느냐"
✅ "Oriented"가 포함된 IT 용어 정리표
| 용어 | 해석 | 의미 및 설명 |
|---|---|---|
| Object-Oriented Programming (OOP) | 객체 지향 프로그래밍 | 객체(데이터+행동)를 중심으로 프로그램 구성. 클래스, 캡슐화, 상속, 다형성 특징 포함 |
| Service-Oriented Architecture (SOA) | 서비스 지향 아키텍처 | 독립적인 서비스 단위로 시스템 구성. 모듈 간 느슨한 결합 |
| Aspect-Oriented Programming (AOP) | 관점 지향 프로그래밍 | 공통 기능(로깅, 보안 등)을 모듈화하여 핵심 로직과 분리 |
| Event-Oriented Programming | 이벤트 지향 프로그래밍 | 사용자/시스템 이벤트에 따라 동작하는 방식. UI나 JS에서 자주 사용 |
| Data-Oriented Design | 데이터 지향 설계 | 데이터의 메모리 접근 효율을 중심으로 설계. 게임 엔진에서 많이 사용 |
| Domain-Oriented Design (DDD) | 도메인 중심 설계 | 비즈니스 도메인(업무 영역)을 모델링 중심으로 시스템 구성 |
| Behavior-Oriented Design | 행동 지향 설계 | 시스템의 '행동' 중심으로 구조화. 로봇, 에이전트 시스템에서 사용됨 |
| Model-Oriented Architecture | 모델 지향 아키텍처 | 코드보다 모델(예: UML)을 중심으로 설계 및 생성 |
| Task-Oriented UI | 작업 지향 UI | 사용자 목표(task)를 중심으로 설계된 인터페이스. 사용성이 핵심 |
| Customer-Oriented Strategy | 고객 지향 전략 | 고객 만족과 맞춤형 서비스를 중심으로 한 IT 전략 |
🧠 시각 요약: Oriented = "중심 철학"
Object-Oriented → 객체 중심
Service-Oriented → 서비스 중심
Event-Oriented → 이벤트 중심
Data-Oriented → 데이터 중심
Domain-Oriented → 업무 모델 중심
...🧩 추가 정리: -based와 비교
| 용어 | 의미 | 차이점 |
|---|---|---|
| Object-based | 객체 개념은 있지만 OOP 특성(상속 등)은 없음 | 구조만 따른다 |
| Object-oriented | 객체 개념을 중심 철학으로 구현 | 철학까지 따른다 |
OOP vs AOP vs DDD (객체 지향 / 관점 지향 / 도메인 중심 설계)
📊 OOP vs AOP vs DDD 비교표
| 항목 | OOP (Object-Oriented Programming) |
AOP (Aspect-Oriented Programming) |
DDD (Domain-Driven Design) |
|---|---|---|---|
| 핵심 개념 | 객체(데이터+행위)를 중심으로 설계 | 공통 관심사를 별도로 분리하여 설계 | 도메인 지식을 코드 중심으로 모델링 |
| 목표 | 코드 재사용, 추상화, 계층화 | 핵심 로직과 부가 로직의 분리 | 비즈니스 도메인에 부합하는 시스템 설계 |
| 주 대상 | 클래스, 객체, 메서드 | 로깅, 보안, 트랜잭션, 에러처리 등 횡단 관심사 | 엔티티, 값 객체, 도메인 서비스 등 |
| 중심 철학 | "모든 것은 객체다" | "관심사는 분리되어야 한다" | "복잡한 도메인은 모델에서 해결" |
| 코드 구조 | 클래스/상속 중심 | Advice + Pointcut + Joinpoint 구조 | 애그리거트, 리포지터리, 유비쿼터스 언어 |
| 적용 기술 | Java, C++, Python 등 | Spring AOP, AspectJ, .NET PostSharp | DDD 프레임워크, Java, C#, Kotlin 등 |
| 장점 | 이해 쉬움, 유지보수 편리 | 횡단 관심사 분리로 코드 간결 | 복잡한 도메인 일관된 관리 |
| 단점 | 중복 로직 발생 가능 | 디버깅 난이도 있음 | 도메인 이해 부족 시 설계 실패 위험 |
| 대표 사용처 | 대부분의 일반 프로그램, UI | 로깅, 인증, 트랜잭션 처리 | 대규모, 복잡한 기업 시스템 (ERP 등) |
🧠 핵심 요약 문장
- OOP: 객체 단위로 책임 분산 → 클래스 설계가 중요
- AOP: "중복되는 관심사"는 한곳에 모아 관리
- DDD: "비즈니스 전문가가 말하는 개념"을 모델에 그대로 반영
🔁 적용 흐름 (현업 예시)
하나의 프로젝트에서도 셋을 함께 사용하는 경우가 많습니다:
DDD: 설계 구조를 도메인 개념 중심으로 → 도메인 모델
OOP: 구현할 때는 도메인 모델을 객체로 나눔 → 클래스/객체
AOP: 보안/트랜잭션/로그 같은 부가 기능 → 횡단 관심사로 분리예시 시나리오: 온라인 쇼핑몰
| 관심사 | 적용 설계 방식 |
|---|---|
| 상품, 주문, 결제 같은 비즈니스 로직 | DDD (도메인 모델: Order, Product, Payment) |
| 주문 처리 시의 트랜잭션, 로깅 | AOP (Joinpoint: 주문 메서드, Advice: 로그/보안) |
| 각 기능 구현 클래스 | OOP (OrderService, ProductRepository 등) |