소프트웨어 아키텍처는 쉽게 말하면,
**'소프트웨어를 만드는 설계도이자 구조'**입니다.
비유를 들어볼게요.
건물을 지을 때 만드려는 집의 모양을 그리고, 기둥을 세우고, 벽돌을 쌓는 방식으로는 작은 집은 만들 수 있습니다.
그렇지만, 복잡한 건물이나, 고층 건물은 이렇게 단순한 지식만으로 만들 수 없죠.
고층 건물을 만들려면 건물의 구조 설계, 공간 설계(업무 공간, 생활 공간, 휴식/편의/문화 공간, 주차 공간, 관리 공간 등), 유동량에 따른 도로 설계, 전기/수도 등 설비, 각 설계에 맞는 적합한 자재 선정,
건물을 가장 효율적으로 지어 올리기 위한 일정관리(작업 일정에 맞춘 자재 납품, 인력, 장비),
건물이 완성된 이후 인테리어, 유지보수 설계(점검/교체 주기)
건축가(아키텍트)가 설계도를 만든다는 개념은 대부분 쉽게 이해합니다.
S/W 아키텍처는 건축의 아키텍처에서 유래했습니다.
S/W 아키텍처를 설계하는 것은 건물 설계만큼이나 전문지식과 경험이 필요하고, 전문성이 있는 건축가로부터 멋진 건축물이 만들어지는 것처럼 S/W 아키텍트의 전문성(역량)에 따라 대량의 서비스가 문제없이 원활하게 서비스되면서도, 사용하기 편리하고, 확정성, 유지보수성까지 뛰어난 S/W가 될수도 있고,
성능도 느리고, 장애도 많고, 확장도 어렵고, 사용하기 불편하고, UX도 촌스럽고, 유지보수성도 떨어지는 하자가 많은 S/W가 만들어 질수도 있습니다.
S/W 개발은 단순히 개발 언어를 이용해서 코딩을 하는 것이 아니라,
클라이언트(S/W 개발을 요청한 고객 - 건축주와 같은 개념)의 요구사항에 맞는 S/W를 설계하고, 개발해 나가는 과정은 요구사항에 맞춰, 전체 구조를 설계하고, 각 구조 영역에 세부 설계를 하고, 각 세부설계에 적합한 기술(Tools)을 선정하고, 각 기술을 보유한 개발자를 일정에 맞춰 투입해서 완성해 나가는 광대한 지식과 경험이 필요한 분야 입니다.
이 과정을 우리는 **'아키텍처를 설계한다'**라고 부릅니다.
아키텍처가 중요한 이유는 이렇습니다.
- 처음에 잘못 설계하면: 건물처럼, 나중에 문제가 생겼을 때 고치는 데 막대한 비용과 시간이 듭니다.
- 처음에 잘 설계하면: 소프트웨어가 쉽게 확장되고, 문제가 생겨도 빠르게 대응할 수 있습니다.
특히, 사업 환경이 빠르게 변하는 S/W를 개발해야 하는 경우라면
**"변화에 잘 대응할 수 있도록 유연하고 견고하게 만드는 것"**이 정말 중요합니다.
그 중심에 바로 이 소프트웨어 아키텍처가 있습니다.
정리하면,
소프트웨어 아키텍처는 소프트웨어라는 건물을 튼튼하고, 안전하고, 오랫동안 쓰기 좋게 만드는 설계와 구조라고 이해하시면 됩니다.
소프트웨어 아키텍처 세부 구성과 필요 전문 지식
시스템 아키텍처 (System Architecture)
소프트웨어 전체 시스템의 큰 구조를 설계하는 것
- 전문 지식
- 모놀리식 vs 마이크로서비스(MSA) 구조 이해
- 계층형 아키텍처 (Layered Architecture) 설계
- 이벤트 기반 아키텍처 (Event-driven Architecture) 설계
- 필요 기술
- 클라우드 네이티브 설계(AWS, Azure, GCP)
- 컨테이너 오케스트레이션 (Docker, Kubernetes)
- API Gateway 및 메시지 브로커 (Kafka, RabbitMQ)
데이터 아키텍처 (Data Architecture)
데이터의 흐름, 저장, 관리 방법을 설계하는 것
- 전문 지식
- 데이터베이스 설계
- 관계형 데이터베이스(RDBMS) : MySQL, Oracle, MS-SQL 등
- 비관계형 데이터베이스(NoSQL) : Redis, MongoDB
- 데이터 모델링 (ERD 설계)
- 데이터 통합 및 파이프라인 설계
- 데이터베이스 설계
- 필요 기술
- MySQL, PostgreSQL, MongoDB, Redis
- 데이터 웨어하우스 (BigQuery, Redshift)
- 도메인 설계 기술
- DB 튜닝(Index, Hint, Join의 이해, 반정규화)
- 캐싱
- 정적 콘텐츠 호스팅
- 검색 엔진
애플리케이션 아키텍처 (Application Architecture)
소프트웨어 기능을 어떻게 구성하고 연결할지 설계하는 것
- 전문 지식
- 디자인 패턴
- OOP
- 도메인 주도 설계(DDD)
- MVC, MVVM, Clean Architecture
- Refactoring
- TDD
- 서비스 분리 및 인터페이스 설계
- 필요 기술
- OOP, DDD, TDD, Refactoring 등
- Spring Boot, .NET Core, Django
- GraphQL, REST API 설계
- 기타 : OAuth2, JWT 인증 방식 ...
인프라 아키텍처 (Infrastructure Architecture)
소프트웨어가 구동될 하드웨어, 네트워크를 설계하는 것
- 전문 지식
- 서버 및 스토리지 구성
- 네트워크 구성 (VPC, VPN, Load Balancer)
- 모니터링과 로깅 전략
- 필요 기술
- Cloud 설계 / 관리 기술
- Terraform, Ansible (IaC: Infrastructure as Code)
- Prometheus, Grafana, ELK Stack
- CDN, WAF 설정
보안 아키텍처 (Security Architecture)
시스템과 데이터의 보안을 설계하는 것
- 전문 지식
- 암호화, 인증, 권한 부여 설계
- 보안 취약점 분석 및 대응
- SSL
- 인증서 운영 기술
- 개인정보보호법, GDPR 등 규제 준수
- 필요 기술
- HTTPS, TLS/SSL, OAuth2
- WAF, IAM (Identity Access Management)
- 보안 스캐너 (OWASP ZAP, SonarQube)
운영/배포 아키텍처 (DevOps Architecture)
소프트웨어를 어떻게 빠르고 안정적으로 운영하고 배포할지 설계하는 것
- 전문 지식
- CI/CD 파이프라인 설계
- 블루그린 배포, 롤링 업데이트 전략
- 무중단 배포, 장애 복구 전략
- 서비스 모니터링, H/W 성능 모니터링
- 장애 감지 / 통보
- S/W, H/W 장애 대응 전략
- 장애 대응 훈련 및 장애 대응 전략 업데이트
- 필요 기술
- Jenkins, GitHub Actions, GitLab CI
- Docker, Kubernetes (Helm 포함)
- Canary Release, Feature Toggle
📋 표로 정리
| 시스템 아키텍처 | MSA, 계층형 설계, 이벤트 기반 설계 | AWS, Docker, Kubernetes, Kafka |
| 데이터 아키텍처 | 데이터베이스 설계, 데이터 모델링, 파이프라인 설계 | MySQL, MongoDB, BigQuery, Airflow |
| 애플리케이션 아키텍처 | 디자인 패턴, DDD, 인터페이스 설계 | Spring Boot, REST API, GraphQL, OAuth2 |
| 인프라 아키텍처 | 서버/네트워크 구성, 모니터링 전략 | Terraform, Prometheus, ELK Stack, CDN |
| 보안 아키텍처 | 암호화/인증/권한, 규제 준수 | TLS, OAuth2, WAF, IAM, OWASP ZAP |
| 운영/배포 아키텍처 | CI/CD, 무중단 배포, 장애 복구 | Jenkins, GitHub Actions, Kubernetes, Canary Release |
요약
소프트웨어 아키텍처는 단순히 구조를 짜는 것이 아니라,
시스템, 데이터, 애플리케이션, 인프라, 보안, 운영
이 여섯 가지 관점에서 각각 깊은 전문성과 기술적 선택이 필요한 일이며,
S/W 아키텍처는 위의 모든 항목에 대해 전문지식과 경험을 가지고 있어야 합니다.
'프로그래밍 > 아키텍처_DDD' 카테고리의 다른 글
| 표현 영역과 응용 영역 (0) | 2024.11.29 |
|---|---|
| DDD 용어 개념 정리 (0) | 2024.10.22 |
| 왜 지금 도메인 주도 설계가 필요한가? (0) | 2024.10.18 |
| DDD - 이벤트 명명 규칙 (3) | 2024.09.30 |