[SWE-008][중급] 프로그램 경계를 알맞게 나누기
페이지 정보
본문
[이번 수업]
모놀리스, 모듈러 모놀리스, 마이크로서비스의 경계와 비용을 비교하고 구조 선택 기준을 익힙니다.
[선수지식]
함수와 클래스, HTTP 요청, 데이터베이스 트랜잭션의 뜻을 알면 좋습니다. 트랜잭션은 여러 변경을 한 작업처럼 성공시키거나 되돌리는 장치입니다.
[학습목표]
1. 세 구조의 배포 단위와 통신 방식을 구분한다.
2. 업무 기능을 기준으로 모듈 경계를 설계한다.
3. 독립 배포의 이점과 분산 시스템의 비용을 함께 판단한다.
[핵심개념]
모놀리스는 애플리케이션 전체를 한 단위로 빌드하고 배포하는 구조입니다. 한 덩어리라고 나쁜 코드는 아닙니다. 시작이 단순하고 같은 프로세스에서 함수를 호출하며 하나의 트랜잭션을 쓰기 쉽습니다. 다만 경계를 관리하지 않으면 주문 코드가 재고 내부 상태를 직접 바꾸는 식으로 결합이 커집니다.
모듈러 모놀리스는 배포 단위는 하나로 유지하되 주문, 재고처럼 업무 기능별 모듈을 나눕니다. 각 모듈은 공개 API와 내부 구현을 구분하고, 다른 모듈은 공개 기능만 사용합니다. 운영은 단순하면서 경계를 찾기 좋은 출발점입니다.
마이크로서비스는 기능을 독립 배포할 수 있는 여러 서비스로 나눕니다. 서비스마다 데이터 소유권을 두고 네트워크로 통신하는 것이 일반적입니다. 독립 배포·확장과 장애 격리에 유리하지만 네트워크 지연, 부분 실패, API 버전, 관측, 데이터 일관성, 인증 관리가 추가됩니다. 코드 크기보다 이런 독립성이 필요한지가 선택 기준입니다.
[따라하기]
재고와 주문 경계를 한 프로세스에 둔 모듈러 모놀리스 예제입니다. `architecture_demo.py`로 저장하세요.
```python
from dataclasses import dataclass
class Inventory:
def __init__(self):
self._stock = {"notebook": 3}
def reserve(self, sku, quantity):
if quantity <= 0:
raise ValueError("quantity must be positive")
available = self._stock.get(sku, 0)
if available < quantity:
return False
self._stock[sku] = available - quantity
return True
@dataclass
class Order:
order_id: str
status: str
class Ordering:
def __init__(self, inventory):
self.inventory = inventory
def place(self, order_id, sku, quantity):
ok = self.inventory.reserve(sku, quantity)
return Order(order_id, "accepted" if ok else "rejected")
inventory = Inventory()
ordering = Ordering(inventory)
for order_id, quantity in (("o1", 2), ("o2", 2)):
order = ordering.place(order_id, "notebook", quantity)
print(f"{order.order_id}: {order.status}")
```
Windows에서는 `py architecture_demo.py`, macOS와 Linux에서는 `python3 architecture_demo.py`를 실행합니다. 예상 결과입니다.
```text
o1: accepted
o2: rejected
```
주문 코드는 `_stock`을 직접 읽지 않고 공개 기능 `reserve()`만 호출합니다. 실제 프로젝트에서는 클래스를 별도 패키지에 두고 의존 규칙을 테스트나 구조 검사로 확인합니다.
[흔한 실수]
클래스마다 서비스를 만들면 호출만 늘고 업무 경계는 흐려집니다. 여러 서비스가 같은 데이터베이스 테이블을 수정해도 독립성이 약해집니다. 모든 경로를 동기 HTTP 호출로 연결하면 한 서비스의 지연이 전체로 번집니다. 먼저 업무 기능과 데이터 소유자를 정하고 측정된 문제에 맞춰 분리하세요.
[보안 주의]
실습은 본인 소유의 로컬 환경에서만 진행합니다. 서비스가 나뉘면 통신 경로와 서비스 신원이 늘어납니다. 내부망도 그대로 신뢰하지 말고 각 호출의 인증·권한 확인, 전송 암호화, 최소 권한, 입력 검증, 비밀의 안전한 보관을 설계하세요.
[직접 해볼 과제]
예제를 `inventory.py`, `ordering.py`, `main.py`로 나누세요. 주문 모듈이 `_stock`에 접근하지 않는지 확인하고, 수량 0에 `ValueError`가 나는 테스트를 추가하세요.
[확인문제]
1. 모놀리스와 모듈러 모놀리스의 배포 단위는 어떻게 같은가요?
2. 마이크로서비스에서 서비스별 데이터 소유권이 중요한 이유는 무엇인가요?
3. 독립 배포가 필요하지 않은 작은 팀이 먼저 고려할 수 있는 구조는 무엇인가요?
[다음 학습]
다음은 MOBILE-008에서 카메라·위치 같은 기기 기능의 권한과 개인정보 처리 원칙을 배웁니다.
[공식 참고 자료]
- 마이크로서비스 공식 용어집: https://glossary.cncf.io/microservices-architecture/
- 아키텍처 스타일 공식 지침: https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
- 모듈 경계 공식 프로젝트 문서: https://docs.spring.io/spring-modulith/reference/fundamentals.html
- Python 데이터클래스 공식 문서: https://docs.python.org/3/library/dataclasses.html
모놀리스, 모듈러 모놀리스, 마이크로서비스의 경계와 비용을 비교하고 구조 선택 기준을 익힙니다.
[선수지식]
함수와 클래스, HTTP 요청, 데이터베이스 트랜잭션의 뜻을 알면 좋습니다. 트랜잭션은 여러 변경을 한 작업처럼 성공시키거나 되돌리는 장치입니다.
[학습목표]
1. 세 구조의 배포 단위와 통신 방식을 구분한다.
2. 업무 기능을 기준으로 모듈 경계를 설계한다.
3. 독립 배포의 이점과 분산 시스템의 비용을 함께 판단한다.
[핵심개념]
모놀리스는 애플리케이션 전체를 한 단위로 빌드하고 배포하는 구조입니다. 한 덩어리라고 나쁜 코드는 아닙니다. 시작이 단순하고 같은 프로세스에서 함수를 호출하며 하나의 트랜잭션을 쓰기 쉽습니다. 다만 경계를 관리하지 않으면 주문 코드가 재고 내부 상태를 직접 바꾸는 식으로 결합이 커집니다.
모듈러 모놀리스는 배포 단위는 하나로 유지하되 주문, 재고처럼 업무 기능별 모듈을 나눕니다. 각 모듈은 공개 API와 내부 구현을 구분하고, 다른 모듈은 공개 기능만 사용합니다. 운영은 단순하면서 경계를 찾기 좋은 출발점입니다.
마이크로서비스는 기능을 독립 배포할 수 있는 여러 서비스로 나눕니다. 서비스마다 데이터 소유권을 두고 네트워크로 통신하는 것이 일반적입니다. 독립 배포·확장과 장애 격리에 유리하지만 네트워크 지연, 부분 실패, API 버전, 관측, 데이터 일관성, 인증 관리가 추가됩니다. 코드 크기보다 이런 독립성이 필요한지가 선택 기준입니다.
[따라하기]
재고와 주문 경계를 한 프로세스에 둔 모듈러 모놀리스 예제입니다. `architecture_demo.py`로 저장하세요.
```python
from dataclasses import dataclass
class Inventory:
def __init__(self):
self._stock = {"notebook": 3}
def reserve(self, sku, quantity):
if quantity <= 0:
raise ValueError("quantity must be positive")
available = self._stock.get(sku, 0)
if available < quantity:
return False
self._stock[sku] = available - quantity
return True
@dataclass
class Order:
order_id: str
status: str
class Ordering:
def __init__(self, inventory):
self.inventory = inventory
def place(self, order_id, sku, quantity):
ok = self.inventory.reserve(sku, quantity)
return Order(order_id, "accepted" if ok else "rejected")
inventory = Inventory()
ordering = Ordering(inventory)
for order_id, quantity in (("o1", 2), ("o2", 2)):
order = ordering.place(order_id, "notebook", quantity)
print(f"{order.order_id}: {order.status}")
```
Windows에서는 `py architecture_demo.py`, macOS와 Linux에서는 `python3 architecture_demo.py`를 실행합니다. 예상 결과입니다.
```text
o1: accepted
o2: rejected
```
주문 코드는 `_stock`을 직접 읽지 않고 공개 기능 `reserve()`만 호출합니다. 실제 프로젝트에서는 클래스를 별도 패키지에 두고 의존 규칙을 테스트나 구조 검사로 확인합니다.
[흔한 실수]
클래스마다 서비스를 만들면 호출만 늘고 업무 경계는 흐려집니다. 여러 서비스가 같은 데이터베이스 테이블을 수정해도 독립성이 약해집니다. 모든 경로를 동기 HTTP 호출로 연결하면 한 서비스의 지연이 전체로 번집니다. 먼저 업무 기능과 데이터 소유자를 정하고 측정된 문제에 맞춰 분리하세요.
[보안 주의]
실습은 본인 소유의 로컬 환경에서만 진행합니다. 서비스가 나뉘면 통신 경로와 서비스 신원이 늘어납니다. 내부망도 그대로 신뢰하지 말고 각 호출의 인증·권한 확인, 전송 암호화, 최소 권한, 입력 검증, 비밀의 안전한 보관을 설계하세요.
[직접 해볼 과제]
예제를 `inventory.py`, `ordering.py`, `main.py`로 나누세요. 주문 모듈이 `_stock`에 접근하지 않는지 확인하고, 수량 0에 `ValueError`가 나는 테스트를 추가하세요.
[확인문제]
1. 모놀리스와 모듈러 모놀리스의 배포 단위는 어떻게 같은가요?
2. 마이크로서비스에서 서비스별 데이터 소유권이 중요한 이유는 무엇인가요?
3. 독립 배포가 필요하지 않은 작은 팀이 먼저 고려할 수 있는 구조는 무엇인가요?
[다음 학습]
다음은 MOBILE-008에서 카메라·위치 같은 기기 기능의 권한과 개인정보 처리 원칙을 배웁니다.
[공식 참고 자료]
- 마이크로서비스 공식 용어집: https://glossary.cncf.io/microservices-architecture/
- 아키텍처 스타일 공식 지침: https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
- 모듈 경계 공식 프로젝트 문서: https://docs.spring.io/spring-modulith/reference/fundamentals.html
- Python 데이터클래스 공식 문서: https://docs.python.org/3/library/dataclasses.html
- 이전글[MOBILE-008][중급] 카메라와 위치 권한 안전하게 다루기 26.09.03
- 다음글[DATA-008][중급] 데이터를 꺼내고 바꾸고 저장하기 26.09.03
댓글목록
등록된 댓글이 없습니다.