[SW Architecture] 소프트웨어 아키텍처 패턴들을 탐구해보자

소프트웨어 아키텍트 패턴 탐구

소프트웨어 아키텍처 패턴에 대하여..

소프트웨어 아키텍처는 단순히 코드를 작성하는 것을 넘어, 시스템의 구조와 설계를 결정하는 중요한 작업입니다. 올바른 아키텍처는 애플리케이션의 유지보수성, 확장성, 성능 등을 크게 향상시킬 수 있습니다. 하지만 모든 상황에 적합한 만능 아키텍처는 존재하지 않으며, 각 상황에 맞는 아키텍처 패턴을 선택하는 것이 중요합니다.

---

소프트웨어 아키텍처 선택 시 고려해야 할 요소

• 성능 (Performance)
• 확장성 (Scalability)
• 탄력성 (Elasticity)
• 유연성 (Flexibility)
• 단순성 (Simplicity)
• 신뢰성 (Reliability)
• 비용 (Cost)
• 팀의 기술 역량 (Team Technical Capability)

이러한 요소를 고려하여 적합한 아키텍처 패턴을 선택하는 것이 중요합니다. 이 글에서는 내가 가장 선호하는 아키텍처 패턴들과 그들이 어떻게 실용적으로 적용될 수 있는지에 대해 이야기해 보겠습니다.

---

1. Bounded Contexts (경계 컨텍스트)

Bounded Context는 도메인 주도 설계(DDD)에서 나온 개념이지만, DDD를 사용하지 않는 프로젝트에서도 널리 활용됩니다. 이 개념은 애플리케이션 내에서 서로 다른 도메인 모델들이 명확히 구분되도록 도와줍니다.

Bounded Context란?

경계 컨텍스트는 도메인 모델의 경계를 정의하여 해당 모델 내에서 일관성과 응집력을 유지할 수 있도록 합니다. 이 경계 내에서는 용어, 규칙, 데이터 표현 방식이 모두 일치합니다.

예시:

전자상거래 앱에서는 다음과 같은 경계를 설정할 수 있습니다:

• Catalogue (카탈로그)
• Ordering (주문)
• Payments (결제)
• Identity (사용자 인증)

이렇게 Bounded Context를 정의하면, 시스템이 확장되더라도 복잡성 증가를 효율적으로 관리할 수 있습니다. 또한, 모놀리식 아키텍처에서 마이크로서비스로의 전환이 용이해집니다.

---

2. Clean Architecture와 Bounded Context

Clean Architecture는 도메인 중심 아키텍처를 강조합니다. 도메인을 중심으로 시스템을 설계하고, 각 Bounded Context를 독립적인 모듈로 분리하여 관리합니다.

이 접근 방식은 코드의 변경이 도메인 모델에만 영향을 미치도록 하여, 시스템의 유지보수를 용이하게 만듭니다.

---

3. Vertical Slice Architecture (수직 분할 아키텍처)

수직 분할 아키텍처는 기존의 레이어드 아키텍처와는 달리, 애플리케이션을 독립적인 수직 슬라이스로 나누어 관리합니다. 각 슬라이스는 기능 단위로 개발되고 배포되며, Bounded Context의 정의가 핵심이 됩니다.

특징:

• 각 슬라이스는 독립적으로 개발, 배포, 확장 가능합니다.
• 기능 단위로 코드를 관리하므로 유지보수가 용이합니다.

---

4. Event Storming (이벤트 스토밍)

이벤트 스토밍은 Bounded Context를 정의하는 데 매우 유용한 기법입니다. 이 방법은 팀이 도메인 모델을 시각화하고, 시스템의 주요 이벤트들을 파악할 수 있도록 도와줍니다. 특히 도메인 주도 설계를 채택하거나 복잡한 시스템을 모델링할 때 강력한 도구가 됩니다.

---

5. 사이드카 (Sidecar)

사이드카 패턴은 동일한 호스트 내에서 다른 애플리케이션의 앞에 위치하는 보조 애플리케이션입니다. 주로 보안 기능을 추가하거나, 여러 애플리케이션 간의 공통 기능을 표준화하는 데 사용됩니다.

사이드카 패턴의 특징:

• 다운스트림 애플리케이션을 수정하지 않고도 기능을 확장할 수 있습니다.
• 공통 관심사를 여러 애플리케이션에 걸쳐 적용할 수 있습니다. (예: 로깅, 성능 모니터링, 인증 등)

예시: 서비스 메시 (Service Mesh)

서비스 메시는 사이드카 개념을 확장한 형태로, 모든 애플리케이션이 자체 사이드카 프록시를 사용하여 통신합니다. 이를 통해 트래픽을 표준화된 방식으로 관리할 수 있습니다.

---

6. 퍼블리셔-서브스크라이버 (Publisher-Subscriber)

이 패턴은 비동기 통신을 지원하며, 퍼블리셔와 서브스크라이버 간에 메시지를 전달합니다. 메시지 브로커는 특정 토픽을 관리하고, 메시지는 큐에 저장되어 서브스크라이버에게 전달됩니다.

특징:

• 경쟁 소비자: 메시지는 한 번만 소비됩니다.
• 팬아웃: 메시지는 모든 서브스크라이버에게 전달됩니다.

언제 사용하면 좋을까요?

• 비동기 통신이 필요한 경우
• 장기 실행 작업을 확장해야 할 때
• 여러 애플리케이션 간 데이터 변경을 동기화해야 할 때

반응형

---

7. 애플리케이션 게이트웨이 (Application Gateway)

애플리케이션 게이트웨이는 네트워크 트래픽을 여러 애플리케이션으로 라우팅하는 역할을 합니다. 이 방식은 패킷을 깊이 분석하고, 요청 호스트명, 경로, 헤더 등을 기준으로 라우팅을 수행합니다.

특징:

• 경로 기반 라우팅을 사용하여 다양한 서비스들을 관리할 수 있습니다.
• SSL 종료와 웹 애플리케이션 방화벽(WAF) 기능을 추가할 수 있습니다.

---

8. 마이크로서비스 (Microservices)

마이크로서비스는 애플리케이션을 독립적인 서비스로 분할하는 아키텍처입니다. 각 서비스는 자체 API와 데이터베이스를 가지며, 독립적으로 배포되고 확장 가능합니다.

언제 사용하면 좋을까요?

• 성능, 확장성, 가용성에 대한 요구 사항이 다른 애플리케이션이 있을 때
• 다양한 데이터베이스 기술을 사용할 필요가 있을 때
• 독립적인 배포와 확장이 필요할 때

---

9. 마이크로프론트엔드 (Microfrontends)

마이크로프론트엔드는 마이크로서비스와 유사하게 웹 애플리케이션을 여러 개의 작은 프론트엔드로 분리하는 접근 방식입니다. 이 방법을 통해 각 팀은 독립적으로 UI를 개발하고 배포할 수 있습니다.

언제 사용하면 좋을까요?

• 여러 팀이 웹 애플리케이션 UI의 다양한 섹션을 유지보수해야 할 때
• 각 섹션을 독립적으로 배포할 필요가 있을 때

---

10. 명령과 조회 책임 분리 (CQRS)

CQRS는 데이터 쓰기 측과 읽기 측을 분리하여 각 부분에 대해 최적화된 기술을 사용할 수 있도록 합니다. 이 패턴은 복잡한 도메인 로직을 분리하고, 서로 다른 데이터베이스를 사용할 수 있게 해줍니다.

특징:

• Write Side와 Read Side에 대해 다른 데이터베이스 기술을 사용할 수 있습니다.
• Eventual Consistency를 사용하여 두 측면 간의 일관성을 유지합니다.

---

11. 폴리글롯 아키텍처 (Polyglot Architecture)

폴리글롯 아키텍처는 각 Bounded Context에 최적화된 기술을 선택하여 시스템을 구축하는 방식입니다. 이를 통해 각 서비스가 독립적으로 최적화되며, 복잡한 시스템을 효율적으로 관리할 수 있습니다.

예시: 전자상거래 폴리글롯 아키텍처

• 카탈로그: Redis로 성능 최적화
• 주문: PostgreSQL로 관계형 일관성 유지
• 결제: CQRS와 이벤트 소싱을 사용한 복잡한 결제 흐름 모델링

---

결론

소프트웨어 아키텍처 패턴은 특정 상황에 맞게 적절히 활용되었을 때 매우 큰 효과를 발휘합니다. 각 패턴이 어떤 상황에서 유용한지 이해하고, 프로젝트의 요구 사항에 맞는 아키텍처를 선택하는 것이 중요합니다. 여러 아키텍처 패턴을 조합하고 적용하면 복잡한 시스템을 더 효율적으로 설계하고 관리할 수 있습니다.