0. 들어가면서..
소프트웨어 아키텍처에서 트레이드 오프(trade-off)란
품질 속성 중 한 가지 장점을 강화하면 다른 품질이 희생되는 구조적 선택의 난제
아키텍처 설계는 정답을 찾는 게 아니라
무엇을 우선시하고, 무엇을 감수할 것인가를 결정하는 과정이다.
이번 주말(1/18) 서비스를 출시하면서
고민했던 주제와 그 과정을 개념과 함께 학습 차원에서 기록해본다.
1. 트레이드 오프는 필연적인가?
소프트웨어는 동시에 모든 걸 만족시킬 수 없다.
- 성능 (Performance)
- 확장성 (Scalability)
- 유지보수성 (Maintainability)
- 복잡도 (Complexity)
- 개발 속도 (Time to Market)
- 안정성 (Reliability)
- 비용 (Cost)
- 보안 (Security)
직접 서비스를 구현해보면 위 중 상당수가 서로 충돌한다.
- 예시 1) 성능 ↑ → 코드 복잡도 ↑ → 유지보수성 ↓
- 성능을 높이면 소스코드가 복잡해지고, 유지보수가 까다로워짐.
- 예시 2) 확장성 ↑ → 인프라 비용 ↑
- 서비스가 성장할 수 있게 확장성을 높이면 다양한 인프라가 초기부터 필요하며 비용이 높아짐.
- 예시 3) 빠른 개발 ↑ → 장기적 안정성 ↓
- MVP는 프로토타입일 뿐, 빠른 개발을 위한 서버리스로 수만명 동시 트래픽을 감당할 수는 없다.
2. 대표적인 아키텍처 트레이드오프 사례
① 모놀리식 아키텍처 vs 마이크로서비스 아키텍처(MSA)
| 관점 | 모놀리식 | 마이크로서비스 |
| 개발 속도 | 빠름 | 느림 |
| 초기 복잡도 | 낮음 | 높음 |
| 확장성 | 제한적 | 매우 높음 |
| 배포 | 단순 | 복잡 |
| 장애 전파 | 전체 영향 | 부분 영향 |
| 운영 비용 | 낮음 | 높음 |
핵심 구분
- 모놀리식 : 단순함 ↑ (확장성 ↓)
- 마이크로서비스 : 확장성 ↑ (운영 복잡도 ↑)
그래서 스타트업 초반엔 모놀리식이 합리적이고,
규모가 커지면 마이크로서비스가 의미를 가짐.
② 성능 vs 유지보수성
1. 단순한 로직 → 느리지만 이해하기 쉬움
2. 최적화 로직 → 빠르지만 이해하기 어려움
- 캐싱, 비동기 처리, 메모리 최적화
→ 성능 ↑
→ 코드 복잡도 ↑
→ 버그 가능성 ↑
결론
- 필요한 곳만 최적화하는 것이 원칙
- 모든 곳을 빠르게 만들면 시스템이 망가질 수 있음.
③ 일관성 vs 가용성 (CAP 이론)
분산 시스템에서 3개를 동시에 만족 불가
- Consistency: 항상 같은 데이터
- Availability: 언제나 응답
- Partition Tolerance: 네트워크 분리 허용
예시)
- 은행 시스템 → Consistency 우선
- SNS 타임라인 → Availability 우선
트레이드 오프 질문
“데이터가 조금 틀려도 빠른 게 중요한가?”
“느리더라도 정확해야 하는가?”
④ 보안 vs 사용성
- 인증 단계 증가 + 사용자 권한 분리 + 암호 강화
- → 보안 ↑ / 사용자 경험 ↓ / 개발 복잡도 ↑
예시)
- 금융 / 의료 → 보안 우선
- 내부 관리 도구 → 사용성 우선
⑤ 유연성 vs 복잡성
- 추상화 계층 다수
- 플러그인 구조
- 이벤트 기반 설계
→ 변경에 강함
→ 이해하기 어려움
→ 온보딩 비용 ↑
미래를 대비한 과도한 설계는
현재를 망가뜨리는 대표적 트레이드 오프
(참고) 오버 엔지니어링의 한계점
https://medium.com/@afonso.castro_27350/overengineering-a-complexidade-desnecessária-na-arquitetura-de-software-fba7b5e82bc4
3. 좋은 아키텍처란?
모든 걸 다 잘하는 구조? - X
우리 상황에서 가장 중요한 걸 잘하는 구조 - O
위대한 설계자는 이렇게 생각할 것.
- 이 시스템의 비즈니스 목표는 무엇인가
- 지금 가장 중요한 품질은 무엇인가
- 나중에 포기해도 되는 것은 무엇인가
4. 아키텍트라면 스스로에게 질문해야 할 것
아키텍처 결정 전에 스스로에게 물어야 할 질문들을 뽑는다면?
- 지금 가장 크리티컬한 실패는 무엇인가?
- 성능 저하?
- 장애?
- 개발 지연?
- 이렇게 복잡한 구조가 정말 필요한가?
- 지금 쓰는가?
- 6개월 내에 쓸 가능성이 있는가?
- 되돌릴 수 있는 선택인가?
- DB 선택, 분산 구조는 되돌리기 어려움
- 모듈 분리는 비교적 되돌리기 쉬움
소프트웨어 아키텍처 결정 Case Study
1. 인스타그램 (SNS)
일관성 ↓ ↔ 성능·가용성 ↑
- 초당 수천~수만 요청
- 사진 피드 빠른 로딩
- 약간의 데이터 지연은 허용 가능
- 전 세계 사용자
(1) 아키텍처 선택
Eventually Consistent + 캐시 중심 구조
- 피드 데이터는 즉시 일관성 포기
- Redis / Memcache 적극 도입
- 비동기 이벤트 처리 (좋아요, 조회수 등)
(2) 트레이드오프 분석
| 선택 | 포기 |
|
|
(3) 사용자 경험 기준 판단
SNS에서 숫자 1~2초 늦는 게 치명적인가? → X
피드가 느리면 치명적인가? → O
2. 쿠팡 (이커머스)
성능&확장성 ↓ <-> 정확성&신뢰성 ↑
- 주문 / 결제는 절대 틀리면 안 됨
- 트래픽은 시간대별로 급변
- 서비스 도메인이 매우 많음
(1) 아키텍처 선택
도메인 분리 + 높은 일관성
- 주문, 결제, 배송 도메인 분리
- 주문/결제는 높은 트랜잭션 보장
(2) 트레이드오프 분석
| 선택 | 포기 |
|
|
(3) 비즈니스 판단
결제 1건 오류는 신뢰도 붕괴
→ 성능보다 정확성이 압도적으로 중요
3. 넷플릭스 (OTT)
단순성 ↓ <-> 확장성&복원력 ↑
- 글로벌 트래픽
- 장애가 나도 서비스는 계속되어야
- 빠른 실험
(1) 아키텍처 선택
마이크로서비스 + 장애 허용 설계
- 서비스(기능) 수백 개
- Circuit Breaker, Bulkhead 패턴
- 장애를 전제로 한 설계
(2) 트레이드오프 분석
| 선택 | 포기 |
|
|
(3) 조직 구조 기반 판단
엔지니어 수백, 수천명 + 글로벌 서비스
→ 단순 구조는 오히려 병목
5. 한 문장으로 요약한다면..
소프트웨어 아키텍처의 본질은 기술 선택이 아니라, 트레이드오프를 이해하고 감수할 수 있는 결정.
대-AI 시대에
단순 엔지니어가 아니라 아키텍트가 되어야 한다.
코딩이 아니라 아키텍처를 만들 수 있어야 한다.
개발 Scene에서 자주 나오는 얘기다.
한번 경험해보니 왜 이런 말을 하는지 알겠다.
이제 코드 한줄 한줄 적는 코더의 자리는 없다.
사람이 10분 고민해서 작성할걸 AI는 3초면 한다.
그래서 AI가 조망하지 못하는 거시적 시야,
제품의 구조를 만드는 아키텍처링을 빠르게 섭렵해야 할 것이다.
나도 창업을 위해서 많이 공부해둬야겠다.
