Clean Architecture 정리 – 5부 16장 아키텍처의 독립성

좋은 아키텍처가 지원해야 하는 것

• 유스케이스
• 운영
• 개발
• 배포

---

1. 유스케이스 

아키텍처는 시스템이 어떤 목적을 달성하기 위한 도구인지, 그 의도를 잘 드러내야 한다.
이를 명확히 보여주는 게 유스케이스다.

좋은 아키텍처는 이 유스케이스가 중심에 있도록 구성되어야 한다.

따라서 클래스, 함수, 모듈 등에서 눈에 띄게 표현되어야 하며, 다른 구조 속에 감춰져 있으면 안 된다.

좋은 아키텍처는 유스케이스를 일급 요소(first-class element)로서 다루며, 개발자가 시스템 구조만 훑어도 어떤 유스케이스들이 있는지 파악할 수 있게 한다. (이후, 21장에서 다룰 예정)

 

2. 운영

유스케이스에 걸맞은 처리량과 응답 시간을 보장할 수 있는 아키텍처를 구조화할 수 있어야 한다.

ex) 모노리틱, 다중 스레드, 다중 프로세스, 마이크로 서비스, ...

하지만 컴포넌트가

• 적절히 격리되고
• 통신 방식을 특정 방식으로 제한하지 않는다면

요구사항이 바뀌더라도, 시스템을 전환하는 일이 쉬워질 것이다.

 

3. 개발

서비스 개발이 많은 팀으로 구성되어있다면,
아키텍처가 독립적으로 개발 가능한 컴포넌트 단위로 구성되어, 컴포넌트를 독립적으로 작업할 수 있는 팀에 할당하자.

 

4. 배포

시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야 한다.

---

결합 분리 모드

좋은 아키텍처는 시스템 구조를 상황에 맞게 다양하게 분리할 수 있어야 한다.
결합 분리 모드는 그런 분리 전략 중 하나다.

 

1. 운영 관점 예시

• UI, 업무규칙, 데이터베이스가 각각 다른 서버에서 동작할 수도 있다.
• 업무 규칙이 많은 처리량이 필요하다면, 여러 서버로 복제하여 실행할 수도 있다.
• ...

 

2. 개발 관점 예시

• UI에 중점을 둔 팀은 업무 규칙에 중점을 둔 팀에 영향을 줄 수 없다.
• 유스케이스도 서로 분리되면, A 유스케이스 팀과 B 유스케이스 팀은 개입할 가능성이 거의 없다.
• ...

 

3. 배포 관점 예시

• 운영 중인(런타임) 시스템에서도 계층과 유스케이스를 교체할 수 있다.
• 새로운 유스케이스를 추가하는 일은, 시스템의 나머지는 둔 채 새로운 컴포넌트 몇 개를 추가하는 정도이다.
• ...

 

4. 중복 판단

• 우발적인 중복에 대한 두려움이, 비효율을 가져올 수도 있다.
  • 중복처럼 보이는 코드 영역이라도, 이후에 다른 속도와 이유로 각자의 경로로 발전할 수 있다 → 진짜 중복 아님
  • 너무 이른 통합은 오히려 분리 비용만 만든다
• ex)
  1. 두 유스케이스 화면 구조가 매우매우 비슷 -> 코드를 통합하고 싶음
  2. 하지만 시간이 지나면서 화면 구조가 서로 다른 방향으로 분기할 가능성이 높다.
  3. 만약 통합을 했고 이후에 구조가 달라진다 -> 코드를 분리해야한다.
• ex) 데이터베이스 레코드 구조가 특정 화면의 데이터 구조와 유사하더라도, 이를 직접 결합하지 마라

 

계층과 유스케이스의 분리 전략 (FastAPI 기준)

 

1. 소스 수준 분리 모드 (코드 의존성 분리)

• 기능 단위로 라우터/서비스/모델을 나누고, 의존성 주입으로 내부 결합도 최소화
• 인터페이스만 의존하게 하면, 다른 모듈을 수정하지 않아도 된다
• 예시:

app/
  routers/
    add_order.py
    delete_order.py
  services/
    order_creator.py
    order_deleter.py

 

 

2. 배포 수준 분리 모드 (기능별 서버 조합 또는 컨테이너화)

• 기능별로 도커 이미지나 실행 스크립트를 따로 구성
• 한 기능이 수정돼도 다른 기능 서버는 재배포 필요 없음
• 단, 여전히 하나의 서버 프로세스 안에서 조합됨

 

3. 서비스 수준 분리 모드 (마이크로서비스)

• 아예 앱을 완전히 별도로 구성하고, Gateway나 Proxy를 통해 라우팅
• 기능별 서버 프로세스 완전 분리 → 코드, 런타임, 배포 전부 분리
•  

구분	배포 수준 분리	서비스 수준 분리
앱 구성	동일 앱 안에서 모듈 조합 분리	기능마다 완전 별개의 FastAPI 앱
실행 프로세스	보통 하나의 서버 프로세스	각 기능마다 독립된 서버 프로세스
빌드/배포 단위	기능 단위로 빌드 조합 조절 가능	완전히 분리된 앱을 각각 빌드 및 배포
장애 격리	완전하지 않음 (같은 프로세스 내 문제 공유됨)	완전한 격리 가능
운영 복잡도	비교적 단순함	복잡도 증가 (Gateway, 배포 파이프라인 필요)

 

보통 소스 분리 → 배포 분리 → 실행 단위 분리로 점진적으로 강화된다.

좋은 아키텍처는 이러한 분리 전략들을 선택할 수 있도록 구조화되어 있어야 한다.

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 5부 16장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.