9. Design - Architecture

소프트웨어 아키텍쳐

Untitled

이전 단계에서 요구사항을 분석하고 이를 모델링하여 체계화했다면, 이제는 실제로 구현할 수 있도록 그 구조를 설계해야한다. 설계(Design)는 크게 3가지 부분으로 나누어서 볼 예정이다.

  • Design Architectures
  • Design Principles
  • Design Patterns ← 별도 정리

가장 먼저 소프트웨어 아키텍쳐에 대해서 알아보자. 소프트웨어 아키텍쳐는 두 가지 정의가 가능하다.

  • A Set of Principal Design Decisions about hte system(설계 결정의 집합)
  • BluePrint of a software system(설계 유형)

여기서 설계 유형은 Structure, Behavior, Interaction, non-functional properties로 분류할 수 있다. 왜 이렇게까지 아키텍쳐에 신경을 쓸까?

  • SW 시스템에서 요소들을 연결하고 구성 요소의 중요성을 강조하기 때문에.
  • SW 시스템에서 설계, 개발, 발전의 제어에 도움을 주기 때문에
  • 기능적, 비기능적 요구사항 모두에 영향을 미치기 때문에.

마지막 요소가 잘 이해되지 않을 수 있다. 기능적 요구사항은 이해해도 비기능적 요구사항에 아키텍쳐가 영향을 미칠수 있을까? → 유지보수를 생각하자.

Untitled

아키텍쳐를 왼쪽과 같이 설계한 상황에서 C4를 교체해야 한다면 써드파티 컴포넌트를 수정해야 할 것이다. 수정 사항마다 메인 코드에 손을 대는 것이다. 오른쪽과 같은 아키텍쳐 설계는 그런 상황을 방지한다. 메인 코드는 변하지 않고 래퍼 부분만 수정하여 사용하면 되기 때문이다.

아키텍쳐의 설계 방향

Untitled

Availability가 조금 애매하다. 시스템이 다운되지 않고 계속해서 서비스를 제공할 수 있는가를 의미한다. 서버 수를 늘리거나, 다운되더라도 빠르게 회복함을 통해 실현할 수 있다.

Untitled

위의 이미지를 통해 각 설계 방향이 어떤 모습으로 실현될 수 있는지 확인하자.

Architectural Representations

아키텍쳐가 무엇인지 알아보았다. 이를 어떻게 표현할 수 있을까? 형식이 정해져 있는 UML의 Package Diagram을 사용하거나, 좀 더 자유로운 형식의 여러 패턴들을 사용할 수 있다. 패키지 다이어그램부터 알아보자.

패키지 다이어그램

Untitled

패키지는 말 그대로 요소들의 묶음이다. 그것은 namespace일 수도, class일 수도, project일 수도 있다. 상속이나 연관등은 클래스다이어그램의 그것처럼 사용하면 된다. 중요한 것은 계층적 분할(Hierachical Decomposition)이 가능하다는 것이다.

Untitled

패키지 속의 서브패키지를 통해 아키텍쳐 구조를 나타낼 수 있다.

Architecture Patterns

아래에 설명할 6가지 패턴은 계층적 구조를 설명할 뿐, 크게 정해진 형식이 정해지지 않은 자유로운 패턴이다. 각각 알아보자.

Layout architecture

Untitled

시스템을 계층적으로 구성하고 각 계층에 연관된 기능을 배치한 패턴이다. 아래로 내려갈 수록 핵심 서비스이며, 계층을 뛰어넘는 이동이 금지된다. 이미 있는 시스템 위에 새로운 기능을 쌓거나, 보안성을 강화하고자 할 때 사용한다.

Window, Linux, Android platform 등에 사용된다.

장점

  • 인터페이스를 동일하게 유지하면 중간 시스템을 변경해도 괜찮다.

단점

  • 바로 아래 계층보다 더 아래의 계층을 사용할 수도 있다.
  • 명핵한 계층 구별이 어렵다.
  • 여러 계층을 통과해야 하므로 성능 문제가 발생할 수 있다.

Client-server architecture

Untitled

Client와 Server는 인터넷으로 연결되어있으며, 서버는 종류별로 나뉘어 있으므로 사용자가 원하는 서버에 접속하여 서비스를 이용할 수 있다. 여러 지역에서 공유 DB를 사용하거나 복제서버를 사용하는 경우에 사용한다. 넷플릭스를 생각하자.

장점

  • 네트워크를 통해 서버 부하를 분산할 수 있다.
  • 다수의 사용자가 동시 이용할 수 있다.

단점

  • 서버다운이나 공격에 취약하다.
  • 네트워크에 성능을 의존한다.
  • 타 기관이 서버를 관리할 경우 관리문제가 발생할 수 있다.

Model-View-Controller architecture(MVC)

Untitled

데이터를 보여주는 것과 처리하는 것을 분리했다. Model은 데이터의 처리를, View는 데이터를 보여주는 것을, Controller는 모델과 뷰를 조합하여 사용자 입력을 처리한다. 여러 데이터를 다양한 방법으로 보이고 싶을 때 사용한다.

장점

  • 데이터 처리와 보여주는 방법을 각각 쉽게 변경 가능하다
  • 관련자료를 하나하나 바꿀 것 없이 전체 변경이 용이하다.

단점

  • 코드가 간단할 때 굳이 MVC로 나누면 더 복잡해진다.

Event-Driven architecture

Untitled

사용하고자 하는 서비스에 바로 연결하는 것이 아닌, 메세지 핸들러에게 요청을 보내는 방식이다. 이벤트가 발생하면 모든 요소에게 전달되지만, 해당 이벤트 처리를 등록한 요소만 실행된다. 서로 다른 컴퓨터에 분산된 컴포넌트들을 통합하는데 사용된다.

장점

  • 각 요소는 개별적이기에 시스템 변경이 상대적으로 용이하다.

단점

  • 이벤트를 넘겨준 다음 대기하는 방식이라 언제 처리될 지 모른다.

Repository architecture

Untitled

소규모 서브시스템들이 하나의 Global repository를 공유한다. 모든 데이터는 중앙 저장소에서 관리하며, 컴포넌트간의 교환도 중앙 저장소를 사용한다. 대용량의 데이터를 오래 저장하는 시스템이나 IDE같은 경우에 사용한다.

장점

  • 컴포넌트들이 독립적이다
  • 중앙 저장소만 변경하면 모든 컴포넌트에게 영향을 미친다.
  • 데이터를 일관성 있게 관리할 수 있다.

단점

  • 중앙 저장소가이 다운되면 시스템 전체에 영향을 미친다.
  • 중앙이 저장소를 반드시 통해야 하기에 처리 효율이 낮다.
  • 여러 컴퓨터로 분산시키기 어렵다.

Pipe and Filter architecture

Untitled

각 컴포넌트들은 명확히 구분되어있으며, 한 컴포넌트가 처리한 데이터를 다른 컴포넌트의 입력으로 받는다. 배치나 트랜잭션처럼 순차적인 과정을 원할 때 사용한다.

장점

  • 구조가 직관적이어서 이해하기 쉽고 변환 필터의 재사용이 쉽다.
  • 새로운 변환을 추가하기 쉽다.
  • 순차, 동시 시스템으로 구현이 가능하다.

단점

  • 인접 변환간의 데이터 형식을 미리 약속해야한다.
  • 호환되지 않는 변환의 재사용이 어렵다.

참고자료

  • 소프트웨어 공학의 모든 것(최은만, 생능출판사, 2020)