[Software Engineering] SW Architecture

 

Software Architecture란?

• 소프트웨어의 구조(structure)를 설계하는 것
• 시스템을 구성하는 요소(components)와 그 관계를 정의

 

아키텍처는 다음과 같은 질문에 답하는 과정이다.

• 시스템은 어떤 구성요소로 이루어져 있는가
• 각 구성요소는 어떤 역할을 하는가
• 이 구성요소들은 어떻게 연결되는가

이는 요구사항(추상적)과 구현(구체적) 사이를 연결하는 중간 단계이다.

 

Software System을 바라보는 다양한 관점

1. Structural (구조적 관점)

• 어떤 컴포넌트가 필요한가?
• 어떻게 구성할 것인가?

예: 계층 구조, 모듈 구조

 

2. Functional (기능적 관점)

• 시스템이 어떤 기능을 제공하는가?
• 외부 기능적인 관점

예: 로그인, 결제, 검색

 

3. Behavioral (행위적 관점)

• 컴포넌트들이 어떻게 상호작용하는가?

예: 요청 → 처리 → 응답 흐름

 

 

---

 

4+1 View Model

4+1 View Model은 소프트웨어 아키텍처를 다양한 관점에서 표현하는 대표적인 방법이다.

총 5개의 뷰로 구성된다.

 

1. Logical View

Logical View는 시스템의 핵심 기능과 추상 구조를 나타낸다.

• 클래스
• 객체
• 관계

대표적으로 클래스 다이어그램이 해당된다.

 

2. Process View

Process View는 시스템의 동적 동작을 나타낸다.

• 프로세스 간 상호작용
• 실행 흐름

대표적으로 시퀀스 다이어그램이 해당된다.

 

3. Development View

Development View는 시스템의 코드 구조를 나타낸다.

• 모듈 구조
• 패키지 구성

개발자가 실제로 작업하는 구조이다.  대표적으로 패키지 다이어그램이 해당된다. 

 

 

4. Physical View

Physical View는 시스템의 배포 구조를 나타낸다.

• 서버
• DB
• 네트워크

시스템이 실제로 어디에 어떻게 배치되는지를 보여준다. 대표적으로 deployment 다이어그램이 해당된다.

 

5. Scenario View (+1)

Scenario View는 시스템의 사용 시나리오를 나타낸다.

• 유스케이스
• 사용자 흐름

다른 4개의 뷰를 검증하는 역할을 한다.

 

 

---

 

 

왜 Software Architecture가 중요할까?

소프트웨어는 단순히 기능만 수행하면 되는 것이 아니다.

기능 요구사항과 함께 비기능 요구사항을 반드시 고려해야 한다.

 

기능 요구사항 (Funtional Requirements)

• 로그인
• 검색
• 결제

시스템이 무엇을 하는가에 대한 요구사항이다.

 

비기능 요구사항 (Non-functional Requirements)

• 성능 (Performance)
• 확장성 (Scalability)
• 유지보수성 (Maintainability)
• 보안 (Security)

이는 어떻게 잘 동작하는가에 대한 요구사항이다.

 

 

 

 

---

 

 

Architectural Patterns

Architectural Pattern은 시스템 구조를 설계하기 위한 검증된 템플릿이다.

이는 특정 요구사항을 만족하기 위해 반복적으로 사용되는 구조이다.

• 재사용 가능하다
• 검증된 구조이다
• 문제 해결을 위한 일반적인 방식이다

 

주요 아키텍처 패턴

1. MVC (Model-View-Controller)

MVC는 데이터, 화면, 입력 처리를 분리하는 구조이다.

 

Model

• 데이터와 비즈니스 로직을 담당한다

View

• 사용자에게 보여지는 UI를 담당한다

Controller

• 사용자 입력을 처리하고 Model과 View를 연결한다

 

동작 흐름

1. 사용자가 View에서 입력을 한다
2. Controller가 이를 처리한다
3. Model이 데이터를 변경한다
4. View가 변경된 데이터를 반영한다

 

특징

• 역할이 명확하게 분리된다
• 하지만 구성 요소 간 의존성이 존재한다

 

언제 사용하면 좋을까?

• 사용자 인터페이스(UI)가 빈번하게 변경되는 프로젝트
• 동일한 데이터를 여러 형태(웹, 앱 등)로 보여줘야 할 때
• 프론트엔드와 백엔드의 개발 영역을 명확히 나누고 싶을 때

 

2. Layered Architecture

Layered Architecture는 시스템을 계층으로 나누는 구조이다.

 

특징

• 각 계층은 아래 계층에만 의존한다 (one step in incremental development)
• 관심사 분리가 가능하다
• 유지보수가 용이하다
• 각 계층은 독립적으로 개발 및 테스트가 가능하다.

언제 사용하면 좋을까?

• 시스템이 복잡하여 유지보수성과 확장성이 최우선일 때 (대부분의 웹 백엔드)
• 단계별 검증이 중요하여 각 계층별로 독립적인 단위 테스트가 필요할 때
• 표준화된 구조를 통해 팀원 간의 협업 효율을 높이고 싶을 때

 

3 Repository Architecture

Repository Architecture는 중앙 데이터 저장소(repository)를 중심으로 구성되는 구조이다.

특징

• 모든 컴포넌트가 하나의 데이터 저장소를 공유한다.
• 컴포넌트 간 직접 통신이 없다. 컴포넌트들은 오직 Repository와 통신한다. 
• 업데이트를 모두 동일하게 볼 수 있다.

 

단점

• 데이터 구조에 강하게 의존한다 (coupling이 높다)
• 하나의 오류가 전체 시스템에 영향을 줄 수 있다

언제 사용하면 좋을까?

• 방대한 양의 데이터를 여러 컴포넌트가 공유해서 사용해야 하는 시스템.
• 데이터의 일관성과 무결성이 무엇보다 중요할 때 (예: 은행 시스템, 컴파일러의 심볼 테이블).
• 컴포넌트들이 서로의 존재를 몰라도 데이터만 공유하면 되는 구조를 만들 때.

 

 

4. Client-Server Architecture

Client-Server Architecture는 클라이언트와 서버로 역할을 분리한 구조이다.

• Client: 서비스를 요청하는 측
• Server: 서비스를 제공하는 측
• Network: 둘을 연결하는 구조

특징

• 역할이 명확하게 분리된다
• 프론트엔드와 백엔드를 독립적으로 개발할 수 있다

언제 사용하면 좋을까?

• 여러 클라이언트가 중앙의 자원이나 서비스를 공유해야 할 때.
• 서버의 강력한 성능을 활용하여 클라이언트의 부담을 줄여야 할 때.
• 클라이언트(UI)와 서버(데이터/로직)를 서로 다른 언어나 기술 스택으로 개발하고 싶을 때.

 

5. Pipe & Filter Architecture

Pipe & Filter Architecture는 데이터를 단계적으로 처리하는 구조이다.

 

데이터 변환의 연속

• 유닉스 파이프라인 예시: 터미널에서 cat file.txt | grep "error" | sort 같은 명령어를 쓰는 것과 같다. 파일 전체를 읽어서(cat), "error"가 포함된 줄만 찾고(grep), 그걸 정렬(sort)하는 과정이 마치 공장의 컨베이어 벨트처럼 이어지는 구조이다.
• Filter: 데이터를 처리하는 단계 
• Pipe: 데이터를 전달하는 통로 (stateless)

 

특징

• 각 단계가 독립적이다
• 병렬 처리에 유리하다
• 각 필터는 거의 동일한 input, ouput구조를 갖는다. 
• 사용자 인터랙션이 적은 시스템에 적합

 

언제 사용하면 좋을까?

• 사용자 상호작용이 적은 경우: 데이터가 한 방향으로 흐르기 때문에 실시간 인터랙션보다는 배치(Batch) 작업이나 데이터 분석에 유리
• 단계별 변환이 명확할 때: 이미지 처리, 컴파일러(어휘 분석 -> 구문 분석 -> 코드 생성), 로그 수집 시스템 등이 대표적이다.

 

주요 아키텍처 패턴 비교 요약

패턴	핵심 키워드	추천 상황
MVC	UI 분리	인터페이스(화면)가 자주 바뀌거나, 하나의 데이터를 여러 화면(웹/앱)으로 보여줘야 할 때
Layered	계층 분리	규모가 크고 표준적이며, 유지보수성과 안정성이 최우선인 엔터프라이즈 시스템
Repository	데이터 중심	방대한 데이터를 여러 컴포넌트가 공유하며, 데이터의 일관성과 무결성이 핵심일 때
Client-Server	역할 분담	중앙 서버의 자원을 여러 사용자가 공유하며, 프론트와 백엔드를 독립적으로 개발할 때
Pipe-and-Filter	데이터 흐름	사용자 개입 없이 데이터를 순차적으로 변환/가공하는 배치 작업이나 데이터 분석 시스템

 

 

 

---

 

 

Software Product Line Architecture

Software Product Line은 공통 기능을 공유하는 여러 시스템을 의미한다.

• 하나의 공통 기반에서 여러 제품을 만든다
• 재사용성이 높다

어려운 점

• 기능 간 의존성 관리
• 변형 관리
• 문서화 및 추적

 

Feature Model

Feature Model은 SPL에서 기능을 체계적으로 표현하는 방법이다.

• Mandatory: 반드시 포함되는 기능 (가장 기본적인 기능)
• Optional: 선택 가능한 기능
• Alternative: 하나만 선택
• OR: 여러 개 선택 가능
• Requires: 특정 기능이 다른 기능을 요구함
• Excludes: 특정 기능이 다른 기능과 동시에 존재할 수 없음

 

 

 

출처: 경북대학교 손정주 교수님, “소프트웨어공학" 강의 자료