소프트웨어 아키텍처란?

외부에서 인식할 수 있는 특성이 담긴 소프트웨어의 골격이 되는 기본 구조이다.

필요성

사용자의 요구를 만족시키려면 다음 특성을 갖춰야 한다.

  • 적시성(time to market): 사용자는 매우 복잡한 소프트웨어라도 빠른 시간에 만들기를 원한다.
  • 유연성(flexibility): 사용자는 급변하는 환경에도 잘 적응할 수 있는 시스템을 원한다.
  • 통합(integration): 개발된 시스템은 기존 시스템과도 쉽게 통합할 수 있어야 한다.

이를 위해서는 전체 시스템의 구조를 생각하며 균형과 조화를 이루도록 설계해야 한다.

복잡한 대규모 소프트웨어를 개발하려면 전체적인 구조가 유기적으로 잘 구성되어야 하고, 요구 분석, 설계 단계에서부터 품질 특성을 고려하여 개발해야 한다. 따라서 잘 정의된 전체적인 구조와 품질 좋은 소프트웨어를 만들려면 소프트웨어 아키텍처가 필요하다.

공통적인 특징

  • 개발할 소프트웨어에 대한 전체적인 구조를 다룬다.
  • 소프트웨어를 이루고 있는 여러 구성 요소(서브시스템, 컴포넌트)를 다룬다.
  • 구성 요소들이 인터페이스를 통해서 어떻게 상호작용하는지 정의해야 한다.
  • 세부 내용보다는 중요한 부분만을 다룬다. → 추상화
  • 시스템 설계와 개발 시 적용되는 원칙과 지침이 있어야 한다.
  • 의사소통 도구로 활용할 수 있어야 한다.
  • 구현에 대한 제약 사항을 정의해야 한다.
  • 품질 속성을 결정해야 한다.
  • 재사용할 수 있게 설계해야 한다.

종류

리포지토리 패턴 (Repository pattern)

  • 리포지토리와 리포지토리에 접근하는 서브시스템으로 구성된다.
  • 리포지토리에 공동으로 활용하는 데이터를 보관하고, 모든 서브시스템은 리포지토리에 정보를 요청하여 가져와 연산한 후 그 결과를 다시 리포지토리에 저장한다.
  • 대량의 데이터를 공유하는 은행 업무 시스템에 유용하다.
  • 장점
    • 데이터가 한 군데에 모여 있어 일관성 있게 관리할 수 있다.
    • 새로운 서브시스템을 추가하기 쉽다.
  • 단점
    • 리포지토리가 병목현상을 일으킬 수 있다.
    • 서브시스템들과 리포지토리 간 결합도가 높아 리포지토리를 변경하면 서브시스템에 영향을 줄 수 있다.

클라이언트-서버 패턴 (Client-Server pattern)

  • 네트워크를 이용하는 분산 시스템 형태의 모델로, 데이터와 처리 기능을 클라이언트와 서버에 분할하여 사용한다.
  • 서버, 서비스, 클라이언트로 구성되며, 클라이언트가 서버에게 서비스를 요청하면서 상호작용한다.
  • 분산 아키텍처 유형에 유용하다.
  • 서버
    • 클라이언트(서브시스템)에 서비스를 제공한다.
  • 클라이언트
    • 메시지나 원격 프로시저 호출을 통해 서버가 제공하는 서비스를 요청한다.
    • 서비스를 요청할 때는 서버의 이름과 서버가 제공하는 서비스의 이름을 알아야 한다.
  • 단점
    • 성능이 네트워크에도 영향을 받아 성능 예측이 어렵다.

계층화 패턴 (Layered pattern)

  • 계층 하나를 서브시스템으로 생각하여, 하위 계층은 서버(서비스 사용), 상위 계층은 클라이언트(서비스 제공) 역할을 하도록 구성한다.
  • 상호작용하는 계층 간 프로토콜을 정의해야 한다.
  • 장점
    • 계층 간 역할 분담을 명확히 하여 각 계층을 필요에 따라 쉽게 변경할 수 있다.
    • 연결된 계층의 인터페이스만 문제없이 만들면 특정 계층을 쉽게 재사용할 수 있다.

MVC 패턴 (Model-View-Controller pattern)

  • 시스템을 세 개의 서브시스템(Model, View, Controller)으로 나누어 구성하며, 중앙 데이터 구조를 갖는다.
  • 각 서브시스템은 독립적으로 존재한다. 따라서 뷰는 모델의 데이터를 직접 변경할 수 없고, 모델이 제공하는 데이터를 가져올 수만 있다. 모델 또한 뷰에 대한 정보를 알 수 없고, 여러 개의 뷰가 어떻게 처리되는지도 알 필요가 없다.
  • 같은 모델의 서브시스템에 대해 여러 뷰 서브시스템을 필요로 하는 상호작용 시스템에 적합하다.
  • 모델(Model)
    • 뷰, 컨트롤러와 독립되어 모든 데이터 상태와 로직을 처리한다. 따라서 특정 입∙출력 방식에 영향을 받지 않고, 무언가의 호출에 응답만 한다.
  • 뷰(View)
    • 웹 앱의 사용자와 직접 대화가 이루어지는 부분이다.
    • 모델이 제공한 데이터를 사용자에게 보여주는 역하을 한다.
    • 뷰마다 컨트롤러 서브시스템이 각각 하나씩 연결된다.
  • 컨트롤러(Controller)
    • 뷰를 통한 사용자의 요청을 적절한 모델에게 넘겨주고, 모델로부터 받은 응답을 뷰를 통해 사용자에게 돌려준다.
  • 장점
    • 관심사의 분리: 데이터를 화면에 표현하는 디자인과 로직을 분리하여 느슨한 결합이 가능하다. 따라서 동일한 데이터로 서로 다른 형태의 디자인을 추가할 수 있고, 구조 변경 요청 시 수정이 쉽다.
  • 단점
    • 기본 기능 설계로 인한 클래스 수 증가로 복잡도가 증가할 수 있다.
    • 속도가 중요한 프로젝트에는 적합하지 않을 수 있다.

파이프-필터 패턴 (Pipe-Filter pattern)

  • 필터에 해당되는 서브시스템이 하나의 데이터를 입력받아 처리한 후 그 결과를 다음 서브시스템으로 넘겨주는 과정을 반복한다.
  • 데이터를 변환하는 시스템에서 주로 사용한다.
  • 사용자의 개입 없이 데이터의 흐름이 전환되는 경우에 사용한다.
  • 파이프와 필터를 조합하여 만드는 아키텍처에 적합하다.
    (ex. 이미지 프로세싱 시스템, 컴파일러의 순차적인 변환 처리기, 유닉스의 셸(Shell))
  • 필터(Filter)
    • 데이터 스트림을 한 개 이상 입력받아 처리(변환) 한 후 데이터 스트림 하나를 출력한다.
    • 하나의 필터는 여러 포트로 데이터를 보낼 수 있다.
  • 파이프(Pipe)
    • 필터를 거쳐 생성된 데이터 스트림 하나를 다른 필터의 입력에 연결한다.
  • 장점
    • 필터나 파이프 단위로 나누어 개발할 수 있기 때문에 동시 개발이 가능하다.

참고 문헌

  • 쉽게 배우는 소프트웨어 공학 / 김치수 저 / 한빛아카데미 / 2019년 01월 25일