소프트웨어 아키텍처 모델

왜 배우는가: 소프트웨어 아키텍처 모델은 시스템의 구조와 기능 분할 방식을 결정하는 설계의 출발점이다. 데이터 중심형, 클라이언트-서버, 계층, MVC 모델은 품질 속성과 유지보수 방향을 좌우하므로 실무 설계 검토에서 반복적으로 쓰인다. 기술사 시험에서도 모델의 정의와 기능 분할·배치 관점의 차이를 묻는 문항이 반복해서 출제된다.

출제 이력: 제120회 3교시 5번, 제116회 4교시 4번

1. 한 줄 정의와 핵심 키워드

소프트웨어 아키텍처 모델은 시스템을 구성 요소로 나누고 그 기능의 분할과 배치, 상호작용 방식을 정한 구조적 설계 틀이다.

• 소프트웨어 아키텍처(Software Architecture)
• 아키텍처 모델(Architecture Model)
• 기능 분할(Functional Partitioning)
• 기능 배치(Functional Allocation)
• 클라이언트-서버(Client-Server)
• 계층 모델(Layered Model)
• MVC(Model-View-Controller)
• 데이터 중심형(Data-Centered)

2. 개념 풀이

쉽게 말하면 프로그램을 어떤 덩어리로 나누고, 그 덩어리를 어느 위치에서 실행하며 서로 어떻게 주고받을지 정하는 설계 그림이다. 집을 지을 때 방의 배치와 배관 경로를 먼저 정하는 것과 같다.

소프트웨어 아키텍처는 프로그램의 구조, 기능, 동작 방법을 포함한 시스템을 설계하는 과정이다. 이 과정에서 기능을 어떤 단위로 나누고(분할), 그 단위를 어떤 실행 위치에 두며(배치), 단위 사이의 관계를 어떻게 맺을지 정한 것을 아키텍처 모델이라 한다. 모델은 시스템 전체 조직을 정하는 상위 수준의 구조이므로 세부 설계 패턴보다 추상화 수준이 높다.

아키텍처 스타일(Architecture Style)은 컴포넌트와 커넥터의 종류, 그 조합 규칙을 뜻한다. 아키텍처 패턴(Architecture Pattern)은 반복되는 시스템 수준 문제에 대한 검증된 해법이다. 두 용어의 경계는 문헌에 따라 모호하다고 알려져 있으며, 시험에서는 기능 분할과 배치 관점으로 모델을 나누어 설명하는 것이 안전하다.

기능 분할 관점은 기능을 데이터, 표현, 제어, 업무 로직 등으로 나누는 방식이다. 기능 배치 관점은 나뉜 기능을 클라이언트나 서버 등 물리적 또는 논리적 위치에 두는 방식이다. 같은 시스템이라도 분할 기준과 배치 위치에 따라 모델이 달라진다.

계층 수 제한 없음이 아니라, 계층 모델은 기능을 상하위 레벨로 쌓아 한 계층이 바로 아래 계층만 호출하는 구조를 가리킨다.

3. 등장 배경과 필요성

초기 소프트웨어는 단일 시스템에서 모든 기능을 한 덩어리로 구현했다. 시스템이 커지면서 변경 영향이 전체로 번지고, 유지보수 비용이 급증하는 문제가 생겼다. 이를 해결하려고 기능을 분리하고 역할을 나누는 구조적 사고가 필요해졌다.

네트워크와 분산 환경이 보편화되면서 기능을 여러 컴퓨터에 나누어 배치할 필요도 커졌다. 클라이언트-서버 구조가 등장해 사용자 단말과 서버가 역할을 나누었고, 서버 부하와 확장성 문제를 해결하기 위해 3계층 이상의 구조로 발전했다. 이 과정에서 구조 선택이 성능과 유지보수에 영향을 줄 수 있다는 인식이 자리 잡았다.

사용자 화면과 업무 로직이 섞이면 화면 변경이 업무 로직을 깨뜨리는 문제가 생긴다. 이를 막기 위해 관심사의 분리(Separation of Concerns) 원칙이 중요해졌고, MVC 같은 패턴이 이 요구에서 나왔다. 아키텍처 모델은 결국 품질 속성인 성능, 유지보수성, 확장성, 이식성을 설계 단계에서 확보하려는 도구다.

데이터 중심 관점도 필요하다. 여러 시스템이 같은 데이터를 공유하는 환경에서는 데이터 구조와 흐름을 먼저 정해야 일관성이 유지된다. 데이터 아키텍처는 저장되는 자료와 이동하는 자료, 자료 저장소를 설명하며, 데이터 중심형 모델은 이 요구를 구조화한 것이다.

4. 구성요소·원리·절차

아키텍처 모델은 기능을 어떤 단위로 나눌지와 그 단위를 어느 장치에 둘지를 정한다. 기능 분할은 역할 기준으로 기능을 쪼개는 일이다. 기능 배치는 쪼갠 단위를 클라이언트, 서버, 데이터 저장소 중 어디에서 실행할지 정하는 일이다. 두 결정을 모델별로 나누어 보면 답안의 구조가 잡힌다.

데이터 중심형은 자료를 한 곳에 모으고 여러 기능이 이를 읽고 쓴다. 자료 구조가 바뀌면 모든 기능이 영향을 받으므로 스키마 관리가 핵심이다. 클라이언트-서버 모델은 요청하는 쪽과 처리하는 쪽을 나눈다. 서버에 처리가 집중되므로 동시 요청이 많아지면 통신 병목이 생긴다.

계층 모델은 추상화 수준이 다른 기능을 아래위로 쌓는다. 한 계층의 변경이 다른 계층에 영향을 주지 않도록 인터페이스를 고정하는 것이 목적이다. 3계층 구조는 이를 배치에 적용한 대표 형태로, 프레젠테이션 계층, 애플리케이션 계층, 데이터 계층으로 나누어 서버 부하를 분담한다.

MVC 모델은 기능을 데이터, 표현, 제어의 세 역할로 분할한다. 모델은 데이터와 업무 로직을, 뷰는 화면 출력을, 컨트롤러는 사용자 입력과 두 요소 사이의 흐름을 담당한다. 이 분리 덕분에 화면을 바꿔도 업무 로직은 그대로 둘 수 있다.

설계 절차는 다음과 같다.

• 요구사항에서 기능을 식별한다.
• 기능을 역할 단위로 분할한다(자료, 요청, 처리, 표현 기준).
• 분할 단위를 배치 위치(클라이언트, 서버, 저장소)에 할당한다.
• 단위 간 인터페이스와 의존 방향을 정한다. 의존은 한 방향으로만 흐르게 한다.
• 성능, 변경 용이성, 확장성 측면에서 배치를 검토하고 조정한다.

기능 분할은 변경 영향 범위를 줄이고, 기능 배치는 부하와 통신 방식을 결정한다

아래 그림은 MVC 모델의 구성과 화살표 방향을 보여준다. 답안지에는 세 상자와 세 화살표만 그려도 충분하다.

5. 관련 법령·기준·표준

아키텍처 모델 자체를 정한 법령과 고시는 없다. 공공 사업이나 금융·의료 등 규제 분야에서는 해당 분야의 보안과 개인정보 관련 법령이 아키텍처 선택에 제약을 준다. 국제 표준으로는 아키텍처 기술 표준인 ISO/IEC/IEEE 42010이 있다. 이 표준은 아키텍처를 기술하는 관점과 뷰를 정의하는 기준이다.

위 표의 값은 법령 수치가 아니라 모델의 구조 원칙이다. 따라서 답안에는 계층 수와 분리 원칙을 근거로 쓴다. 수치 기준처럼 외워 쓰는 값은 없다.

6. 유형과 비교

소프트웨어 아키텍처 모델은 기능을 어떻게 나누고 어디에 배치하느냐에 따라 구분한다. 같은 시스템이라도 데이터 중심형, 클라이언트-서버형, 계층형, MVC형 중 무엇을 택하느냐에 따라 변경 범위와 성능 특성이 달라진다. 아래 표는 네 모델의 기능 분할 기준과 배치 방식을 비교한다.