[학습기록] 소프트웨어 아키텍처: (1) 도메인,모듈,컴포넌트,아티팩트 그리고 퀀텀
소프트웨어 아키텍처 101, 한빛미디어
소프트웨어 아키텍처를 공부해보고 싶어서 소프트웨어 아키텍처 101이라는 책을 읽어보고 있습니다.
사실 한참 전에 구입했었는데, 솔직히 손이 잘 가지 않았던 책입니다. 내용이 딱딱해 보이기도 하고, 어렵게 느껴지기도 했기 때문입니다.
오랜만에 책장에서 꺼내서 읽어보고 있지만, 여전히 어렵습니다. 이해하기 어려운 것도 동일했습니다.
개념이 낯설기보다는 기초가 제대로 정립되어 있지 않은 상태라서 그런것 같습니다.
책에서 반복적으로 등장하는 용어들:
도메인(domain), 모듈(module), 컴포넌트(component),아티팩트(artifact), 퀀텀(quantum)
분명 익숙하게 사용하던 단어들이지만, 막상 정확히 설명하려고 하면 경계가 흐릿해졌습니다.
그래서 우선 이 용어들에 대한 개념부터 정리해보기로 했습니다.
1. 핵심개념
1.1. 도메인(domain)
소프트웨어가 해결하려는 현실 세계의 문제 영역
도메인은 코드 구조가 아닙니다. 기술적인 단위도 아닙니다. 비즈니스 관점에서 바라본 문제의 영역입니다.
배달 서비스를 생각해보면 다음과 같은 것들을 도메인으로 분류할 수 있을 것입니다.
- 주문
- 결제
- 배달
- 정산
- 회원
이것들은 패키지 구조가 아니라, 현실 세계의 업무를 기준으로 구분한 영역입니다.
즉, 도메인은 기술을 나누기 위한 기준이 아니라 문제를 이해하기 위한 기준입니다.
1.2. 모듈(module)
하나의 책임을 중심으로 묶인 코드 단위
모듈은 개발 관점의 개념입니다. 하나의 책임(Responsibility)을 중심으로 묶인 코드의 집합으로 볼 수 있습니다.
아래와 같은 것들이 모듈에 해당됩니다.
- Java 패키지
- C# 네임스페이스
- Gradle 멀티모듈 구조
모듈은 코드가 어떻게 조직되어 있는지를 보여주는 단위입니다. 컴파일 시점에 그 경계가 결정되며, 실행 이전에 이미 형태가 정해집니다.
여기서 중요한 목표는 두 가지입니다.
- 응집도는 높이고,
- 결합도는 낮추는 것
결국, 모듈을 잘 나누는 일은 코드의 복잡도를 통제하는 첫 단계라고 볼 수 있습니다.
1.3. 컴포넌트(component)
독립적으로 실행되는 런타임 단위
모듈이 코드 묶음이라면, 컴포넌트는 실제로 실행되는 단위입니다.
아래와 같은 것들이 컴포넌트에 해당됩니다.
- 인증 API
- 결제 배치
- Kafka Consumer
- Gateway
컴포넌트는 보통 하나의 프로세스로 실행되며, 네트워크를 통해 다른 컴포넌트와 상호작용합니다.
👉 모듈: 코드의 구조
👉 컴포넌트: 실행 구조
1.4. 아티팩트(artifact)
빌드 결과로 생성되는 물리적 산출물(파일 단위)
아래와 같은 것들이 아티팩트에 해당됩니다.
- jar 파일
- war 파일
- dll 파일
- Docker Image 파일
결국, 아티팩트는 배포 대상으로 가장 구체적이고 물리적인 개념입니다.
1.5. 퀀텀(quantum)
물리학에서 퀀텀은 “더 이상 나눌 수 없는 최소 단위”를 의미합니다.
소프트웨어 아키텍처에서도 이 개념이 등장합니다.
독립적으로 배포되고, 독립적으로 확장되며, 독립적으로 변경될 수 있는 최소 실행 단위
즉, 소프트웨어에서 퀀텀은 “함께 움직일 수밖에 없는 최소 단위”라고 이해하면 됩니다.
모놀리식(monolith) 구조
하나의 기능만 수정하더라도 애플리케이션 전체를 다시 빌드하고 재배포해야 합니다.
👉 퀀텀 = 애플리케이션 전체
마이크로서비스(microservice) 구조
각 서비스(컴포넌트)가 독립적으로 배포되고 확장될 수 있습니다.
👉 퀀텀 = 서비스 단위
1.6. 핵심개념 요약
| 개념 | 기준 |
|---|---|
| 도메인 | 문제 영역 |
| 모듈 | 코드 구조 |
| 컴포넌트 | 실행 단위 |
| 아티팩트 | 배포 산출물 |
| 퀀텀 | 함께 움직이는 최소 단위 |
1. 도메인 정의 (무엇을 해결할 것인가?)
↓
2. 모듈 설계 (코드를 어떻게 나눌 것인가?)
↓
3. 컴포넌트 구성 (무엇이 실행될 것인가?)
↓
4. 아티팩트 생성 (무엇을 배포할 것인가?)
↓
5. 퀀텀 결정 (무엇이 함께 변경될 것인가?)
2. 배포단위
한 번에 배포되는 물리적 묶음
그러면 배포단위는 무엇인가요? 아티팩트와는 어떻게 다른가요?
아래와 같은 것들이 배포단위에 해당됩니다.
- Docker Container
- VM 배포 패키지
- 배포 파일들이 하나로 묶인 압축 파일(예 : zip)
배포단위는 운영과 CI/CD 관점에서 정의된 개념입니다.
배포단위를 이해하기 위해서는 이런 질문을 던져볼 수 있습니다.
- 무엇을 한 번에 배포하는가?
- 무엇을 한 번에 롤백하는가?
- 무엇을 한 번에 버전 업그레이드하는가?
이 질문에 대한 해답이 바로 배포단위입니다.
참고로 아티팩트는 빌드의 산출물이고, 배포단위는 그 산출물들을 어떻게 묶어 운영 환경에 올릴 것인가를 정의하는 단위입니다.
두 개념은 겹칠 수 있지만, 반드시 동일한 것은 아닙니다.
2.1. 컴포넌트와 배포단위의 관계
많은 경우, 1 컴포넌트 = 1 배포단위로 구성됩니다.
하나의 애플리케이션이 하나의 Docker 이미지로 배포되는 경우, 실행 단위와 배포 단위가 모두 1개로 구성됩니다.
하지만 항상 그런 것은 아닙니다.
예시) 컴포넌트 1개, 배포단위 1개
payment-api (컴포넌트)
→ payment-api.jar (배포단위)
예시) 컴포넌트 n개, 배포단위 n개
payment-api (컴포넌트)
payment-batch (컴포넌트)
→ payment-api.jar (배포단위)
→ payment-batch.jar (배포단위)
배포단위는 “물리적인 묶음”이고, 컴포넌트는 “실행 단위”입니다.
2.2. 퀀텀과 배포단위의 관계
배포단위는 기술적·운영적 묶음이고, 퀀텀은 변화의 경계입니다.
모놀리식 구조에서는 배포단위가 1개이고, 퀀텀도 1개이기 때문에 두 개념이 동일해 보입니다.
하지만, 마이크로서비스 구조에서는 배포단위가 여러 개라도 항상 함께 변경된다면 퀀텀은 1개일 수 있습니다.
배포단위는 “어떻게 배포되는가”에 대한 답이고, 퀀텀은 “무엇이 함께 움직이는가”에 대한 답입니다.
겉으로 보면 퀀텀은 배포단위처럼 보이기도 합니다. 하지만, 완전히 같은 개념은 아닙니다.
- 배포단위 → “어떻게 배포되는가?” (운영 관점)
- 퀀텀 → “어떻게 함께 움직이는가?” (변화 관점)
예시) 권텀과 배포단위가 다른 경우: 논리적 결합
user-service.jar(배포단위)
order-service.jar(배포단위)
물리적으로는 2개의 배포단위지만, user-service.jar를 변경 시 order-service.jar의 변경도 필요하다면 퀀텀은 1개가 됩니다.
예시) 퀀텀과 배포단위가 다른 경우: 내부 플러그인
app.jar (배포단위)
├─ core
├─ plugin-A
├─ plugin-B
배포단위는 1개이지만, plugin-A만 교체가 가능하다면 퀀텀은 plugin 단위로 범위가 축소됩니다.
2.3. 컴포넌트,배포단위,퀀텀 차이점 요약
| 개념 | 기준 |
|---|---|
| 컴포넌트 | 무엇이 실행되는가? |
| 배포단위 | 무엇을 한 번에 배포하는가? |
| 퀀텀 | 무엇이 함께 움직이는가? |
3. 서비스(service)
아키텍처를 공부하다 보면 서비스와 컴포넌트라는 용어가 같은 의미로 사용되기도 하고, 문맥에 따라 혼용되기도 합니다.
서비스는 기능 또는 가치 제공 단위입니다. 아래 예시처럼 “무엇을 제공하는가?”에 초점을 둔 개념입니다.
- 결제 서비스
- 구독 서비스
- 알림 서비스
이것은 비즈니스 기능을 기준으로 구분한 논리적 단위에 해당합니다.
하지만 컴포넌트는 실제 프로세스로 실행되며, 배포와 확장의 대상이 됩니다.
서비스와 컴포넌트 비교
| 구분 | 서비스 | 컴포넌트 |
|---|---|---|
| 기준 | 무엇을 제공하는가? | 무엇이 실행되는가? |
| 관점 | 기능/비즈니스 | 구조/런타임 |
| 형태 | 논리적 단위 | 물리적 실행 단위 |
4. 마무리
단순히 서버가 몇 대로 구성되어 있는지를 아는 것만으로는 아키텍처를 이해했다고 볼 수는 없을 것입니다.
아키텍처를 제대로 이해하기 위해서는 도메인, 모듈, 컴포넌트, 아티팩트, 그리고 퀀텀을 기반으로
- 시스템이 어떤 단위로 구성되어 있고,
- 어떻게 실행되며,
- 무엇이 함께 움직이는지
를 설명할 수 있어야 한다는 생각이 들었습니다.
5. 포스팅 시리즈
- [학습기록] 소프트웨어 아키텍처: (1) 도메인,모듈,컴포넌트,아티팩트 그리고 퀀텀
- [학습기록] 소프트웨어 아키텍처: (2) 계약에 의한 설계(Design by Contract)
- [학습기록] 소프트웨어 아키텍처: (3) 서비스 기반 아키텍처 스타일
- [학습기록] 소프트웨어 아키텍처: (4) 서비스 디스커버리 with 마이크로서비스 아키텍처(MSA)
- [학습기록] 소프트웨어 아키텍처: (5) 아키텍처 결정 레코드(Architecture Decision Record, ADR) 문서 작성법
- [학습기록] 소프트웨어 아키텍처: (6) 토폴로지(Topology)
#소프트웨어아키텍처101 #한빛미디어 #소프트웨어 #아키텍처 #도메인 #모듈 #컴포넌트 #아티팩트 #퀀텀 #배포단위 #서비스