클린 아키텍처(Clean Architecture) 요약

클린 아키텍처(Clean Architecture) 요약

 

1. 클린 아키텍처란 무엇인가?

클린 아키텍처는 소프트웨어를 더 오래 유지하고 변화에 유연하게 대응하기 위한 설계 철학이다.

특히, 시간이 지나면서 기능이 늘어나고 복잡도가 증가할 때 구조가 쉽게 무너지지 않는 것을 목표로 한다.

핵심 철학은 다음 두 가지이다:

1. 의존성 규칙 (Dependency Rule)
   • 소스코드의 의존성은 항상 안쪽(도메인)으로 향해야 한다.
   • UI, 프레임워크, DB 등이 도메인 계층을 의존해서는 안 된다.
2. 관심사의 분리 (Separation of Concerns)
   • UI, 비즈니스 규칙, 데이터 접근 로직을 서로 명확하게 분리한다.

---

2. 일반적인 아키텍처와의 비교

영상에서는 MVC, MVVM 등 흔히 사용하는 구조와 클린 아키텍처를 비교하며 문제점을 설명한다.

2.1 MVC의 문제

• ViewController가 비대해지고(“Massive VC”), 역할이 모여 유지보수가 어려움
• UI 로직 + 비즈니스 로직 + 네트워크 + 상태 관리가 섞임
• 테스트하기 어려움(특히 비즈니스 로직)

2.2 MVVM의 문제

• ViewModel로 일부 로직을 분리할 수 있지만,
• 비즈니스 로직이 여전히 ViewModel에 몰리는 경향
• Repository나 UseCase를 따로 분리하지 않으면 구조가 오염되기 쉬움

2.3 왜 Clean Architecture인가?

• 규모가 커질수록 MVC/MVVM은 “관리 비용이 증가”
• 클린 아키텍처는 변화에 강하고 테스트 친화적인 구조를 제공
• 프레임워크 교체(UI, DB 등), 저장소 변경, UI 변경에도 핵심 로직이 흔들리지 않음

---

3. 클린 아키텍처의 4계층 (동심원 구조)

영상에서 설명하는 전통적인 Clean Architecture 구조는 다음과 같다.

Entities (도메인 규칙)
Use Cases (애플리케이션 규칙)
Interface Adapters (DB/API/UI와 연결)
Frameworks & Drivers (UI, DB, 외부 환경)

3.1 Entities (엔티티)

• 시스템의 핵심 비즈니스 규칙을 포함
• 외부 시스템(UI, 네트워크, DB)에 의존하지 않는 순수 모델
• 가장 안정적이며 가장 적게 변해야 하는 계층

3.2 Use Cases (유스케이스)

• 앱에서 실행되는 고수준 비즈니스 규칙
• 엔티티를 사용해서 특정 작업을 수행
• Repository 인터페이스를 호출하여 저장/로드는 추상화

3.3 Interface Adapters

• UseCase와 외부 시스템(네트워크, 디스크, UI)을 연결하는 어댑터 계층
• DTO, Mapper, Repository 구현체 등이 위치
• 외부 데이터를 엔티티 형태로 변환하거나 그 반대 수행

3.4 Frameworks & Drivers

• SwiftUI, UIKit, Alamofire, CoreData, Firebase, Keychain 등
• 외부 프레임워크에 의존적이며 언제든 교체될 수 있어야 하는 계층

---

4. 의존성 규칙 (Dependency Rule)

“안쪽 계층(Entities, UseCases)은 바깥 계층(UI, DB, Framework)을 몰라야 한다.”

즉,
- UseCase는 SwiftUI를 몰라야 하고

- Entities는 Repository 구현체나 CoreData를 몰라야 한다.

이를 통해:

• UI 교체 가능
• 저장 방식(CoreData → Keychain → 서버) 교체 가능
• 테스트가 쉬워짐
• 비즈니스 로직이 프레임워크에 잠식되지 않음

---

5. 클린 아키텍처가 해결하는 문제

영상에서 강조하는 클린 아키텍처의 장점:

5.1 유지보수 편리

• 특정 기능이 어디에 있는지 구조적으로 명확
• 기능 추가/변경 시 영향 범위가 줄어듦

5.2 테스트가 매우 용이

• UseCase와 Domain이 UI/DB와 분리되어 있어 테스트가 간단

5.3 외부 프레임워크로부터의 독립

• SwiftUI → UIKit 전환, CoreData → Realm 전환 등이 로직 변경 없이 가능

5.4 수명 긴 애플리케이션에 적합

• 앱 규모가 커져도 구조가 쉽게 무너지지 않음

---

6. 클린 아키텍처는 언제 과한가?

영상에서는 다음과 같은 경고도 포함한다:

• 너무 작은 앱에서는 오히려 구조가 과할 수 있음
• 팀의 경험이 없으면 초기에 러닝커브가 있음
• 잘못 도입하면 계층만 많고 실리는 없어짐

즉, 적절한 복잡도와 규모에 맞춰 적용해야 한다는 메시지를 전달한다.

---

7. 예시: 보안카드 앱에 적용해 보면?

보안카드 앱(SecurityCardZ)을 기준으로 클린 아키텍처를 적용하면 다음처럼 구성할 수 있다.

Entities

• SecureCard
• CardField
• CreditCard / MembershipCard
• Domain 에러 타입

Use Cases

• LoadCardsUseCase
• CreateCardUseCase
• DeleteCardUseCase
• ScanQRCodeUseCase

Interface Adapters

• KeychainSecureCardRepository
• JSON / DTO Mapper
• QRScannerAdapter

Frameworks (가장 바깥)

• SwiftUI Views
• TCA Reducer / ViewStore
• Keychain API
• System QR Scanner
• CoreData / FileStorage

결과적으로 얻는 장점:

• UI를 SwiftUI → UIKit으로 변경해도 비즈니스 로직은 그대로 유지
• 저장 방식(Keychain → CoreData → Supabase) 변경이 쉬움
• 테스트 코드 작성이 쉬워짐
• 기능 확장 시 기존 코드의 영향 최소화

 

8. 결론

클린 아키텍처는 큰 프로젝트에서 “무너지지 않는 구조”를 만드는 기술이다.
UI나 프레임워크에 의존하지 않는 핵심 로직을 만들고,
변화에 강하고, 테스트하기 쉬운 앱을 만들 수 있다.

작은 앱에서는 과할 수 있지만,
앱이 성장하면 반드시 필요한 구조적 기반이 된다.