소프트웨어 아키텍처 패턴 (Software Architecture Patterns)
핵심 인사이트 (3줄 요약)
시스템 전체 구조를 결정하는 고수준 설계 패턴. 계층형·MVC·마이크로서비스·이벤트 드리븐 등 주요 패턴이 있다. 기술사 시험에서는 각 패턴의 특징과 적합한 상황을 비교해서 설명해야 한다.
📝 기술사 모의답안 (2.5페이지 분량)
📌 예상 문제
"소프트웨어 아키텍처 패턴 (Software Architecture Patterns)의 개념과 구성 요소를 설명하고, 소프트웨어 품질 및 생산성 향상 측면에서의 적용 방안을 기술하시오."
Ⅰ. 개요
1. 개념
소프트웨어 아키텍처 패턴이란 반복적으로 나타나는 설계 문제에 대한 검증된 구조적 해결 방식이다.
비유: "건물 설계 유형" - 아파트·단독주택·빌딩은 각각 다른 구조 패턴을 따름
Ⅱ. 구성 요소 및 핵심 원리
2. 주요 아키텍처 패턴 비교표
| 패턴 | 구조 | 장점 | 단점 | 적합 케이스 |
|---|---|---|---|---|
| 계층형 | 수직 계층 분리 | 단순, 유지보수 | 성능, 결합 | 엔터프라이즈 앱 |
| MVC | Model-View-Controller | 관심사 분리 | 복잡 컨트롤러 | 웹 앱 |
| 마이크로서비스 | 독립 서비스 분리 | 확장성, 독립 배포 | 분산 복잡성 | 대규모 서비스 |
| 이벤트 드리븐 | 이벤트 발행/구독 | 느슨한 결합 | 추적 어려움 | 실시간 처리 |
| 파이프-필터 | 단계별 처리 | 재사용, 직렬화 | 공유 상태 불가 | ETL, 컴파일러 |
| 클라이언트-서버 | 요청-응답 | 중앙 관리 | 서버 병목 | 웹/앱 서비스 |
| SOA | 서비스 지향 | 재사용, 결합 | ESB 병목 | 기업 통합 |
3. 계층형 아키텍처 (Layered Architecture)
┌─────────────────────────────────┐
│ 프레젠테이션 계층 (UI/API) │ → 사용자 요청 처리
├─────────────────────────────────┤
│ 비즈니스 로직 계층 (Service) │ → 핵심 업무 규칙
├─────────────────────────────────┤
│ 데이터 접근 계층 (Repository) │ → DB 쿼리 추상화
├─────────────────────────────────┤
│ 데이터 계층 (Database/Cache) │ → 실제 데이터 저장
└─────────────────────────────────┘
규칙: 상위 계층은 바로 아래 계층만 호출
장점: 각 계층 독립 교체 가능
단점: 요청마다 모든 계층 통과 (sinkhole antipattern)
6. 이벤트 드리븐 아키텍처 (EDA)
발행자(Publisher)
│
▼
[이벤트 브로커] ← Kafka, RabbitMQ, AWS SNS
│
├──► 구독자A (주문 처리 서비스)
├──► 구독자B (재고 차감 서비스)
└──► 구독자C (알림 서비스)
장점: 느슨한 결합, 새 구독자 추가 용이
단점: 이벤트 추적 어려움, 최종 일관성
Event Sourcing:
- 상태 변경 자체를 이벤트로 저장
- 이벤트 재생으로 상태 복원 가능
- CQRS와 주로 함께 사용
CQRS (Command Query Responsibility Segregation):
- Command(쓰기)와 Query(읽기) 모델 분리
- 읽기/쓰기 최적화 별도 수행
7. 클린 아키텍처 (Clean Architecture)
외부 (Framework, DB, UI)
↓
Interface Adapter (Controller, Presenter, Gateway)
↓
Application Business Rules (Use Cases)
↓
Enterprise Business Rules (Entities)
의존성 방향: 외부 → 내부 (안쪽으로만)
중심의 Entities는 외부에 의존하지 않음
→ 프레임워크 교체 시 핵심 비즈니스 로직 불변
Ⅲ. 기술 비교 분석
4. 마이크로서비스 vs 모놀리식 vs SOA
모놀리식 (Monolithic):
┌───────────────────────────────────┐
│ 단일 배포 단위 │
│ [UI][Business][Data][Auth][Order]│
│ → 하나의 거대한 앱 │
└───────────────────────────────────┘
장점: 단순, 개발 빠름 (초기)
단점: 규모 커지면 유지보수·확장 어려움
SOA (Service Oriented Architecture):
[서비스A] ─┐
[서비스B] ─┤ → [ESB(Enterprise Service Bus)] → [소비자]
[서비스C] ─┘
단점: ESB가 단일 장애점, 병목
마이크로서비스 (Microservices):
[주문서비스] [결제서비스] [상품서비스] [사용자서비스]
↓ ↓ ↓ ↓
DB1 DB2 DB3 DB4
API Gateway → 각 서비스 직접 호출
장점: 서비스별 독립 확장·배포·기술 선택
단점: 분산 시스템 복잡성, 네트워크 지연
5. MVC vs MVP vs MVVM
MVC (Model-View-Controller):
사용자 → Controller → Model → View → 사용자
↘ View 직접 업데이트
Controller가 View와 궤 업데이트
MVP (Model-View-Presenter):
View ↔ Presenter ↔ Model
View와 Model이 완전 분리, 테스트 용이
MVVM (Model-View-ViewModel):
View ←→ ViewModel ↔ Model
(데이터 바인딩)
양방향 바인딩, Angular/Vue/WPF 사용
8. 다른 것과 비교 (선택 기준)
| 상황 | 추천 패턴 | 이유 |
|---|---|---|
| 스타트업 MVP | 모놀리식 | 빠른 개발 |
| 팀 독립 주요 | 마이크로서비스 | 팀별 독립 |
| 기업 시스템 통합 | SOA | 레거시 연동 |
| 실시간 반응 | 이벤트 드리븐 | 느슨한 결합 |
| 데이터 처리 파이프 | 파이프-필터 | ETL |
| 웹앱 UI 분리 | MVC/MVVM | 관심사 분리 |
Ⅳ. 실무 적용 방안
9. 실무에선? (기술사적 판단)
- 넷플릭스: 500+ 마이크로서비스, 서비스 메시(Istio)
- AWS: 이벤트 드리븐 + 서버리스
- 단계적 전환: 모놀리식 → Strangler Pattern으로 MSA 전환
- API Gateway: 인증·라우팅·레이트 리미팅 중앙화
- 기술사 포인트: MSA vs 모놀리식 trade-off, 각 패턴 적합 케이스
Ⅴ. 기대 효과 및 결론
| 효과 영역 | 내용 | 정량적 목표 |
|---|---|---|
| 개발 품질 | 체계적 방법론·테스트로 결함 조기 발견 및 수정 | 결함 밀도(Defect Density) 50% 감소 |
| 개발 생산성 | 자동화·표준화로 반복 작업 제거 및 협업 효율 향상 | 개발 속도 30~50% 향상 |
| 유지보수성 | 모듈화·문서화로 이후 변경·확장 비용 절감 | 유지보수 비용 40% 절감 |
결론
**소프트웨어 아키텍처 패턴 (Software Architecture Patterns)**은(는) 소프트웨어 공학 방법론은 AI 보조 코딩(GitHub Copilot), 로우코드 플랫폼, 플랫폼 엔지니어링의 부상으로 개발자의 인지 부하를 줄이면서 품질과 속도를 동시에 확보하는 방향으로 진화하고 있다.
※ 참고 표준: ISO/IEC 25010(SQuaRE), IEEE 830, CMMI v2.0, OWASP
어린이를 위한 종합 설명
소프트웨어 아키텍처 패턴를 쉽게 이해해보자!
시스템 전체 구조를 결정하는 고수준 설계 패턴. 계층형·MVC·마이크로서비스·이벤트 드리븐 등 주요 패턴이 있다. 기술사 시험에서는 각 패턴의 특징과 적합한 상황을 비교해서
왜 필요할까?
기존 방식의 한계를 넘기 위해
어떻게 동작하나?
복잡한 문제 → 소프트웨어 아키텍처 패턴 적용 → 더 빠르고 안전한 결과!
핵심 한 줄:
소프트웨어 아키텍처 패턴 = 똑똑하게 문제를 해결하는 방법
비유: 소프트웨어 아키텍처 패턴은 마치 요리사가 레시피를 따르는 것과 같아. 혼란스러운 재료들을 정해진 순서대로 조합하면 → 맛있는 요리(최적 결과)가 나오지! 🍳