IT Knowledge/Architecture/images/클린-아키텍처-diagram.svg
🧅 “양파처럼 층층이! 가장 중요한 건 가장 안쪽에 보호해요.”
클린 아키텍처가 뭐예요?
쉬운 비유: 양파
양파를 잘라보면 층이 있어요:
- 겉껍질: 쉽게 벗겨짐
- 안쪽 심: 가장 중요!
클린 아키텍처도 양파처럼:
- 겉 = 바꾸기 쉬운 것 (화면, DB)
- 속 = 바꾸면 안 되는 핵심 (규칙)
왜 필요해요?
문제: 뒤죽박죽 코드
화면 코드 안에 계산도 있고, DB 코드도 있고… → 전부 엉켜있어서 하나 고치면 다 터져요! 💥
해결: 층으로 분리
| 층 | 역할 |
|---|---|
| 화면 | 보여주기만 |
| 계산 | 계산만 |
| 저장 | 저장만 |
→ 각자 할 일만 해요!
4개의 층
안쪽부터 바깥쪽 순서로:
| 층 | 역할 | 비유 | 바뀌는 정도 |
|---|---|---|---|
| 💎 엔티티 | 핵심 규칙 | 양파 심 | 거의 안 바뀜 |
| 🎬 유스케이스 | 사용자 행동 | 레시피 | 가끔 바뀜 |
| 🔌 어댑터 | 번역기 | 플러그 | 자주 바뀜 |
| 🌐 프레임워크 | 도구들 | 도구함 | 언제든 바뀜 |
각 층 쉽게 설명
💎 엔티티 (가장 안쪽)
= 절대 안 바뀌는 규칙
쇼핑몰 예시:
- “가격은 0원 이상”
- “재고 없으면 주문 불가”
→ 화면이 앱→웹으로 바뀌어도 이 규칙은 그대로!
🎬 유스케이스
= 사용자가 하는 행동
- “상품 주문하기”
- “장바구니에 담기”
- “리뷰 작성하기”
🔌 어댑터
= 외부와 내부 연결하는 번역기
- 웹 요청 → 내부가 이해하는 형태로 변환
- DB 데이터 → 내부가 이해하는 형태로 변환
🌐 프레임워크
= 사용하는 도구들
- React, Vue (화면)
- MySQL, MongoDB (DB)
→ 이건 쉽게 바꿀 수 있어요!
가장 중요한 규칙
”안쪽은 바깥을 몰라요!”
| 층 | 아는 것 | 모르는 것 |
|---|---|---|
| 엔티티 | 규칙만 | DB가 뭔지 몰라요 |
| 유스케이스 | 규칙 + 행동 | React가 뭔지 몰라요 |
왜 중요해요?
만약 엔티티가 MySQL을 알면: → MySQL을 MongoDB로 바꿀 때 엔티티도 고쳐야 함 😭
엔티티가 DB를 모르면: → DB를 뭘로 바꾸든 엔티티는 안 고쳐도 됨! 🎉
장점
| 장점 | 설명 |
|---|---|
| 🔧 유지보수 쉬움 | DB 바꿔도 핵심 코드 그대로 |
| 🧪 테스트 쉬움 | 진짜 DB 없이도 테스트 가능 |
| 📖 이해 쉬움 | 규칙은 엔티티, 행동은 유스케이스 |
| 🔄 기술 교체 쉬움 | React→Vue 해도 핵심 안 건드림 |
단점
| 단점 | 설명 |
|---|---|
| 📚 코드 많아짐 | 간단한 것도 여러 층으로 나눠야 함 |
| 🎓 배우기 어려움 | 처음엔 “왜 이렇게 복잡하게?” |
언제 쓰면 좋아요?
클린 아키텍처가 좋은 경우
- ✅ 오래 유지할 프로젝트
- ✅ 기술이 바뀔 수 있음
- ✅ 팀이 큼
- ✅ 테스트가 중요
그냥 간단하게 해도 되는 경우
- ❌ 1회용 코드
- ❌ 혼자 빠르게 만들 때
- ❌ 아주 작은 프로젝트
핵심 정리
- 클린 아키텍처 = 양파처럼 층 나누기
- 4개 층 = 엔티티 → 유스케이스 → 어댑터 → 프레임워크
- 핵심 규칙 = 안쪽은 바깥을 모른다!
- 장점 = 유지보수, 테스트, 기술 교체 쉬움