Phase 1레슨 1

Software Architecture란?

Architecture vs Design, Architecture Decision, Trade-off, Evolutionary Architecture

💡ELI5·

Architecture를 건물 설계에 비유하면

핵심 질문: 좋은 아키텍처란 무엇인가? 답은 '중요한 설계 결정을 명시적으로 하고, 그 결정의 trade-off를 이해하는 것'이다.

Requirements
     ↓
  Architecture Decision (중요한 결정)
     ↓
  Trade-off 분석 (장단점)
     ↓
  Component 배치
     ↓
  검증 (Well-Architected 기준)

건물을 지을 때 건축가는 벽돌을 어떻게 쌓을지(Design)보다 먼저, 건물의 용도, 층수, 구조재, 배치를 결정한다(Architecture). 이 결정들은 나중에 바꾸기 매우 비싸다. 소프트웨어도 같다 — DB를 어떤 것을 쓸지, 서비스를 어떻게 나눌지, 동기/비동기 중 어떤 통신을 쓸지가 Architecture Decision이다.

💡 비유 — Architecture = 건물의 구조 설계도(어떤 기둥을 어디에 세울지). Design = 인테리어 설계(벽지 색, 조명 배치). 구조는 나중에 바꾸기 힘들지만, 인테리어는 비교적 쉽게 바꿀 수 있다.

🔬Deep Dive·

Architecture vs Design

Martin Fowler는 아키텍처를 '중요한 것(결정), 즉 변경 비용이 높은 것'으로 정의한다. 이 관점에서 Architecture와 Design의 경계는 고정되어 있지 않다. 프로젝트 초기에는 모든 것이 Architecture이고, 프로젝트가 성숙해지면 일부 결정이 Design 수준으로 내려온다.

구분	Architecture	Design
결정 대상	시스템 구조, 컴포넌트 배치, 통신 방식	클래스 구조, 함수 설계, 변수 명명
변경 비용	매우 높음 (전체 영향)	낮음 (국소적)
결정 시점	프로젝트 초기, 주요 마일스톤	구현 중 지속적
예시	Monolith vs Microservices, DB 선택	Repository 패턴, DTO 구조

🔬Deep Dive·

Architecture Decision과 Trade-off

모든 아키텍처 결정은 trade-off를 동반한다. 예를 들어 Microservices를 선택하면 독립 배포와 확장성을 얻지만, 분산 시스템의 복잡성(네트워크 장애, 데이터 일관성, 관측성)을 감당해야 한다. Trade-off를 명시적으로 문서화하는 것이 Architecture Decision Record(ADR)의 목적이다.

결정	얻는 것	잃는 것
Monolith	단순성, 빠른 개발, 디버깅 용이	확장성 제한, 팀 경계와 충돌
Microservices	독립 배포, 개별 확장	분산 복잡성, 네트워크 장애, 일관성
Cache 도입	읽기 성능, DB 부하 감소	일관성 문제, 운영 복잡성
Event-Driven	결합도 감소, 비동기 처리	디버깅 어려움, 순서 보장 복잡

🔬Deep Dive·

AWS Well-Architected Framework — 6가지 평가 기준

AWS는 아키텍처를 평가하는 6가지 핵심 관점을 제시한다. 이는 AWS에 종속된 기준이 아니라 일반적인 분산 시스템 설계 원칙으로 사용할 수 있다.

관점	핵심 질문	실습 체크리스트
Operational Excellence	운영이 효율적인가?	배포 자동화, 롤백, 인프라 as 코드
Security	보안이 강화되었는가?	최소 권한, 암호화, 감사 로그
Reliability	장애를 견딜 수 있는가?	SPOF 제거, Failover, Circuit Breaker
Performance Efficiency	성능이 효율적인가?	캐시, CDN, 비동기, 적절한 리소스
Cost Optimization	비용이 최적화되었는가?	사용량 기반 확장, 유휴 자원 제거
Sustainability	지속 가능한가?	리소스 효율성, 탄소 배출 최소화

Architecture Review Checklist: 장애가 발생하면 어떻게 되는가? 트래픽이 10배 증가하면? DB가 죽으면? 캐시가 죽으면? 단일 장애 지점(SPOF)이 있는가? 데이터 일관성은?

⚖️Trade-off·

단순함 vs 확장성

가장 단순한 구조로 요구사항을 만족시키고, 필요한 시점에만 복잡성을 추가하는 것이 좋은 아키텍처의 핵심 원칙이다. 처음부터 Microservices + Kafka + Kubernetes를 도입하는 것은 YAGNI(You Aren't Gonna Need It) 원칙에 위배된다.

단계	아키텍처	트리거
1	Monolith (단일 서버)	MVP, 트래픽 적음
2	Monolith + Cache (Redis)	읽기 병목 발생
3	Monolith + Read Replica	DB 읽기 병목
4	Modular Monolith	팀 확장, 코드 베이스 성장
5	Microservices	독립 배포 필요, 개별 확장 필요

❓ 체크포인트 질문

1.Architecture와 Design의 핵심 차이는 무엇인가?
2.Trade-off가 아키텍처 설계에서 왜 중요한가?
3.Evolutionary Architecture란 무엇인가?
4.AWS Well-Architected Framework의 6가지 핵심 관점은?
5.좋은 아키텍처의 'Golden Rule'은 무엇인가?

Client / Server