소프트웨어 아키텍처 기초

<아키텍처>

 - 시스템 구성과 동작원리 그리고 시스템의 구성환경 등을 설명하는 설계도

 - 최적화

 - 총체적이고 종합적이고 상세하게 개발을 준비하는 것

 

 

<시스템 아키텍처>

 - 하드웨어와 소프트웨어 아키텍처를 기반으로

    시스템이

    서비스를 제공

    하기 위한 아키텍처

 - 스토리지, 서버, 네트워크의 요소들을

    어떻게 배치키는지에 따라

    시스템 아키텍처 종류가 나뉜다.

 - 웹 애플리케이션(서비스)이 돌아가기 위해서는 여러 아키텍처가 통신을 한다.

 - 시스템의 구조와 성능 및 신뢰도 등에 영향을 미치는 중요한 요소

 - 아키텍처를 이해하면 코드를 더욱 체계적으로 작성할 수 있고, 장기적으로는 시스템 유지 보수와 확장을 용이하게 할 수 있다.

 - 시스템의 전체적인 구조를 정의하고 각 요소 간의 관계와 설계 지침을 세우는 데 초점을 둔다.

 

 

<소프트웨어 아키텍처 원칙>

 - 소프트웨어 설계 및 구현 과정에서 발생하는 복잡성을 관리하고, 유지 보수와 확장을 용이하게 해주는 지침

 - 관심사 분리, 모듈화 , 추상화, 캡슐화 등이 있음

    -- 관심사 분리(Separation of Concerns) :

      소프트웨어 시스템을 독립된 부분으로 나누어 각 부분이 특정 관심사에만 집중하도록 하는 설계 원칙

      ex> UI 로직과 비즈니스 로직을 분리, 환경 설정과 애플리케이션 코드를 분리..

    -- 모듈화(Modularity) : 

      시스템을 여러 모듀로 분할하고, 각 모듈이 특정 기능을 담당하도록 하는 방식

      느슨한 결합(Coupling)과 높은 응집도(Cohesion) : 모듈 간의 결합도 낮추고 각 모듈 내부의 응집도 높이

      ex> 전자상거래 시스템 => 제품 관리, 주문 처리, 결제 등으로 모듈화

      -- 추상화와 캡슐

 

<아키텍처 선택시 중요한 고려 사항>

 - 시스템의 규모와 복잡도

 - 팀의 기술 역량

 - 예산과 리소스

 - 변경 가능성

 - 배포와 운영의 편의

 

---

First. 

 - 모노리틱 아키텍처와 RESTful API 설계

 - 클린 아키텍처 익히기

Second.

 - 마이크로서비스, 이벤트 기반 아키텍처, 서버리스 아키텍처

 - AWS, Kafka, Docker 익히기

Third.

 - CQRS, 분산 아키텍처, 서비스  메시 익히기

 - 성능 최적화와 확장성 설계

 

 

 

1. 모노리틱 아키텍(Monolithic Architecture)

  - 애플리케이션을 하나의 단일 코드베이스로 개발, 배포하는 소프트웨어 설계 방식

  - 애플리케이션의 모든 구성 요소가 하나의 통합된 코드베이스와 실행 환경에서 함께 작동

  - 많은 레거시 시스템이 이 구조로 설계

  - 계층적 설계( Presesntation, Business, Data Access Layers)

  - 특징 :

    -- 단일 코드베이스 구성

    -- 단일 배포 단위(애플리케이션을 실행하기 위해 하나의 실행 파일만 있으면 됨)

    -- 강한 결합(모듈들이 서로 밀접하게 연결)

    -- 단순한 개발 초기(상대적으로 접근 쉬움, 초기 프로토타입 개발시 유용함)

  - 장점:

    -- 쉬운 개발 및 디버깅

    -- 일관된 성능

    -- 간단한 배포 : 애플리케이션 한 번에 빌드하고 배포

  - 단점:

    -- 확장성 부족 : 특정 기능만 확장하기 어려움

    -- 유지 보수의 어려움 : 변경 사항이 전체 시스템에 영향을 미칠 가능성이 있음

    -- 배포의 위험성 : 재배포시 전체 시스템 중단해야 함

    -- 기술 스택 제한 : 일부에서 더 적합한 기술만 변경 불가

  - 알아야 할 도구 : 서버 애플리케이션 프레임워크(Spring Boot, Django, Express.js)

 

2. RESTful API 아키텍처 & GraphQL

  - REST는 표준화된 설계 방식, GraphQL은 유연한 데이터 쿼리 제공

  - REST API 설계 원칙 (HTTP Method, 상태 코드 , HATEOAS)

  - GraphQL 스키마 설계 및 Resolver 구현

  - API 버전 관리와 보안 (OAuth2, JWT)

  - 알아야 할 도구

    --  API Gateway (Kong, AWS API Gateway)

    -- REST 및 GraphQL 서버 구현 라이브러리 ( Express.js, Apollo Server )

 

3. 클린 아키텍처 (Clean Architecture)

  - 애플리케이션의 비즈니스 로직을 외부 의존성(API, 데이터베이스 등)으로부터 격리하는 구조

  - 비즈니스 로직을 외부 의존성으로부터 격리해 유연성과 테스트 가능성을 제공

  - 아키텍처가 각각 의존성이 높게 설계되어 있다면 여러 개의 아키텍처를 통합하는 것이 쉽지 않다

  - 아키텍처부터 재구축해야 한다면 리소스가 많이 투여되어야 하거나 통합 자체가 되지 않을 수도 있다

  - 만약 의존성이 줄어든 클린 아키텍처로 설계되어있었다면 기능이 추가 및 서비스가 통합될 때마다 필요한 아키텍처만 뗐다 붙였다 하기 용이할 수 있다

  - 중대형 프로젝트에서 코드 구조를 체계적으로 유지 가능

  - 특징

    -- 도메인 중심 설계 (Domain-Driven Design, DDD)

    -- Ports and Adapters(Hexagonal Architecture)

    -- 계층 간의 의존성 규칙 (안쪽 계층은 바깥 계층을 참조하지 않음)

  - 알아야 할 도구

    -- 클린 아키텍처 템플릿

  - 구성

    -- 안쪽 : 엔티티(비즈니스 로직)

    -- 중간 : 유스케이스

    -- 바깥쪽 : 인터페이스 어댑터 및 외부 프레임 워크

  - 활용 사례

    -- 장기적으로 유지보수가 필요한 프로젝트

    -- 다양한 UI나 데이터베이스를 쉽게 교체해야 하는 경우

  - 장점

    -- 테스트 가능성이 뛰어나고 코드 재사용성을 높임

    -- 유지보수 및 확장이 용이

  - 단점

    -- 초기 설계가 복잡하고 구현에 시간이 걸림

 

4. 마이크로 서비스 아키텍처( MicroService Architecture )

https://kimyhg.tistory.com/39

마이크로 서비스 아키텍처(MSA)

 

 

5. 이벤트 기반 아키텍처 ( Event-Driven Architecture )

  - 애플리케이션이 이벤트(데이터의 상태 변화) 중심으로 작동하도록 설계

  - 이벤트의 상태 변화에 대응하는 소프트웨어 설계 패턴 / 이벤트 : 시스템의 외부 또는 외부에서 시스템에 영향을 주는 상황들(ex> 사용자가 로그인 버튼을 누른다, 문서를 열람한다, 구매한다. 등)

  - 고성능 및 비동기 처리가 요구되는 시스템에 적합

  - 시스템 간의 느슨한 결합과 실시간 데이터 처리가 가능

  - 비동기 작업 처리 방식(Publish/Subscribe, Message Queue)을 알아야 함

  - 알아야 할 도구

    -- 메시징 플랫폼 ( Apache Kafka, Amazon SNS/SQS )

    -- 클라우드 이벤트 서비스(GCP Pub/Sub, AWS EventBridge)

  - 활용 사례 : 

    -- 실시간 알림 시스템 ( Slack, WhatsApp )

    -- IoT 애플리케이션 ( 스마트 홈 기기 ) 

    -- 주식 거래 시스템 ( 실시간 거래 데이터 전송 )

  - 구조 :

    -- 프로듀서(이벤트를 생성)와 컨슈머(이벤트를 처리)로 구성

    -- 메시지 브로커 (Kafka, RabbitMQ )를 사용해 비동기적으로 통신 (이벤트 대기열을 관리하는 이벤트 중재자(Broker) )

    -- ex> 결제 서비스가 결제 이벤트를 처리하고 결제 완료 이벤트를 발생시키면, 다시 재고 관리 서비스로 이벤트가 전달되어 재고를 업데이트하는 

  - 장점 : 

    -- 비동기 작업으로 높은 확장성과 반응성 제공

    -- 느슨한 결합으로 변경에 유연

    -- 실시간성 시스템 (빠르게 반응해야 하는 시스템)

  - 단점 : 

    -- 디버깅과 문제 추적이 어려움

    -- 메시지 처리 실패 시 복구 로직이 필요

    -- 비동기 처리하므로 이벤트 순서 보장 어려움 --> 이벤트를 새로 받을지, 무시할지, 에러 처리를 할지 고려해야 함

 

6. 서버리스 아키텍처 ( Serverless Architecture )

  - 서버 관리 없이 클라우드 플랫폼의 이벤트 기반 함수(FaaS, Functions as a Service)를 통해 애플리케이션 실행

  - 코드가 이벤트에 의해 실행

  - AWS Lambda, Google Cloud Functions 등이 대표적

  - 변동적인 트래픽: 사용량이 예측하기 어려운 경우

  - 비용 효율성: 실제 실행 시간만큼만 비용을 지불하고 싶은 경우

  - 비용 효율적이며 특정 이벤트 기반 작업에 유용

  - FaaS(Function as a Service) 개념과 AWS Lambda, Google Cloud Functions 사용법

  - 서버리스와 데이터베이스의 결합(DynamoDB, Firebase)

  - 서버리스 배포와 모니터링 방법

  - 알아야 할 도구 : 

    -- AWS Lambda, Azure Functions

    -- 서버리스 프레임워크(Serverless Framework, AWS SAM)

  - 활용 사례:

    -- 데이터 변환 작업(ETL 파이프라인)

    -- 간단한 API 서버

    -- 비정기적 트리거 작업(예: 보고서 생성)

  - 장점 : 

    -- 인프라 관리 불필요

    -- 필요할 때만 실행되므로 비용 효율적

  - 단점 : 

    -- 클라우드 제공 업체에 의존적

    -- 긴 실행 시간이 필요한 작업에는 부적합

 

7. CQRS ( Command and Query Responsibility Segregation )

  - 쓰기 작업(Command)와 읽기 작업(Query)을 분리하여 각각 다른 모델로 처리

  - 읽기와 쓰기가 명확히 분리되는 경우, 읽기 작업 최적화가 중요한 시스템

  - 대규모 시스템에서 성능 최적화와 유연성을 제공

  - 쓰기 모델과 읽기 모델의 분리 방법, 이벤트 소싱과의 조합 설계, 데이터 동기화 전략

  - 알아야 할 도구 : 

    -- 이벤트 스토어(Event Store DB)

    -- 데이터베이스(Elasticsearch, MongoDB)

  - 활용 사례 :

    -- 대규모 데이터 조회가 많은 시스템

    -- 고성능 요구가 있는 금융 거래 시스템

    -- 이벤트 소싱과 함께 사용되는 애플리케이션

  - 특징 : 

    -- 쓰기와 읽기에 최적화된 데이터 모델 사용 가능

  - 장점 : 

    -- 읽기 성능과 쓰기 성능을 개별적으로 최적화 가능

  - 단점 : 

    -- 설계가 복잡하며, 데이터 동기화가 필요함

    -- 데이터 모델이 두 개 필요(쓰기 모델, 읽기 모델)

 

8. 분산 아키텍처 ( Distributed Architecture )

  - 애플리케이션의 여러 구성 요소를 물리적으로 분산된 시스템에서 실행

  - 대규모 시스템의 핵심 아키텍처로 높은 가용성과 확장성을 보장

  - 데이터 분산과 일관성 정리 (CAP 이론)

  - 분산 트랜잭션과 Saga 패턴

  - 서비스 간의 로드 밸런싱과 장애 복구

  - 알아야 할 도구

    -- 데이터베이스(Spanner, Cassandra)

    -- 분산 트레이싱 (Jaeger, Zipkin)

  - 활용 사례 : 

    -- 클라우드 기반 애플리케이션 ( ex> AWS, Google Cloud )

    -- 글로벌 사용자 기반의 애플리케이션

  - 장점 : 

    -- 높은 가용성과 확장성 : 장애 시에도 시스템을 지속적으로 운영 가능

    -- 다양한 지역의 사용자에게 낮은 지연을 제공

  - 단점 : 

    -- 분산 시스템의 복잡성 (데이터 일관성 문제, 네트워크 지연 등)

    -- 네트워크 지연, 데이터 일관성 문제 ( 캡 정리 - Consistency, Availability, Partition tolerance)를 해결해야 함

    -- 복잡한 모니터링과 디버깅 도구 필요

 

9. 서비스  메시 아키텍처 ( Service Mesh Architecture)

  - 마이크로서비스 간 통신, 보안, 트래픽 관리가 점점 중요해짐

  - 서비스 메시 도구 (Istio, Linkerd)

  - 트래픽 라우팅, 로드 밸런싱 설정

  - 보안 인증 ( MTLS, TLS )

  - 알아야 할 도구 : 
    -- Istio, Consul

    -- 오브저버빌리티 도구 ( Prometheus, Grafana )

 

10. 헥사고날 아키텍처 (Hexagonal Architecture , Ports and Adapters Architecture)

  - 애플리케이션 코어를 외부 의존성으로부터 격리 / 외부 의존성 : ex) 데이터베이스, UI )

  - 외부 의존성을 제거하고 비즈니스 로직을 테스트하기 용이한 구조

  - 장기적으로 안정적이고 유지보수가 쉬움

  - 어댑터 설계(ex> 데이터베이스 어댑터, API 어댑터)

  - 비즈니스 로직 중심의 설계

  - 언어별 클린 아키텍처 라이브러리 활

  - 활용 사례 : 

    -- 테스트 가능성을 높이고 싶은 프로젝트

    -- 비즈니스 로직을 외부 의존성으로부터 격리하고 싶은 경우

  - 테스트 주도 개발(TDD) : 비즈니스 로직을 독립적으로 테스트하고 싶은 경우

  - 특징 : 

    -- 코어 애플리케이션은 독립적으로 테스트 가능

  - 장점 : 

    -- 유지보수가 쉽고 테스트 친화적

    -- 유연한 구조 : 새로운 외부 시스템(API, DB 등) 을 쉽게 연결할 수 있음

  - 단점 : 

    -- 초기에 설계 복잡도가 높음

    -- 경험이 부족한 팀에는 낯설 수 있음

 

11. 그 밖의 아키텍처

  - 계층형 아키텍처(Layered Architecture)

  - 플러그인 아키텍처(Plugin Architecture)

  - 서비스 지향 아키텍처(Service-Oriented Architecture, SOA)

  - Peer to Peer(P2P) 아키텍처

  - Pipe and Filter 아키텍처

  - Pipeline 아키텍처

  - 마이크로커널 아키텍처(microkernel architecture)

  - 공간 기반 아키텍처(space-based architecture)

  - 공유 데이터 아키텍처(Shared Data Architecture)

  - 리액티브 아키텍처 (Reactive Architecture)

  - 객체 기반 아키텍처 (Object-Oriented Architecture)

  - 블록체인 아키텍처

  - 플랫폼 아키텍처(Platform Architecture) : 여러 애플리케이션이나 서비스를 통합해 작동하도록 설계된 플랫폼 중심의 구조