클린아키텍쳐를 사용하면서.. 클린했나?

안녕하세요. 오랜만에 블로그를 방문해 글을 남겨봅니다. 오늘은 클린 아키텍처(Clean Architecture)에 대한 저의 지극히 주관적인 생각을 나누고자 합니다.

다이어그램

클린 아키텍처를 나름대로 사용하고 고민한 지 어느덧 3년이 넘었습니다. 다른 분들은 어떤 이유로 클린 아키텍처에 입문하셨는지 모르겠지만, 제가 처음 클린 아키텍처의 세계로 들어갔던 과정을 돌아보면 다음과 같습니다:

1. Activity에 모든 코드를 작성하던 주니어 시절
2. Google을 탐험하며 만들었던 나름대로의 Model 구조
3. 데이터 관리를 편하게 하기 위한 Singleton 사용 구조 (뭔가 기술을 쓴 듯 뿌듯)
4. 유지보수의 어려움을 느껴 찾아 헤맸던 시간 (기획자와 대표는 왜 이렇게 변덕이 심한지...)
5. 주변으로부터 추천받은 Effective Java나 OOP (봐도 봐도 무슨 소린지...)
6. 우여곡절 끝에 진입한 MVC (분리하니까 뭔가 좋은 것도 같지만...)
7. MVC를 잘 사용하고 있는지에 대한 의문 (이상하게 코드가 더 많아지는 것 같기도 하고, 모델이 이게 맞나?)
8. 등장한 MVP, MVVM과 Kotlin (솔직히 MVC 쓰면서도 Dependency와 SRP 등 잘 모르겠는데 이게 뭐지?)
9. MVP와 MVVM의 러닝커브를 보고 기겁한 나 (무슨 소린지 당최 모르겠군)
10. 이직하려고 보니 대부분의 요구사항은 MVVM (해야겠는데 MVP와 MVVM 중 무엇을?)
11. 트렌드에 맞춰 시작해본 MVVM (VM 분리와 Model, Databinding 너무너무 편한데?!)
12. MVVM도 버거운데 들리는 Clean Architecture (아키텍처..? 아키텍처가 뭐지?)
13. 트렌드를 따라가지 못하면 뒤쳐지는 것이 아닌가 하는 불안함에 시작된 Clean Architecture (일단 해보자)

사실 더 많은 과정들이 있었지만, 이런 과정을 통해 요즘 유행하는 클린 아키텍처 + MVVM 유형의 기법들을 사용하게 되었습니다.

초기에는 암기 과목을 공부하듯 이해는 안되지만, 단순 무식하게 코드를 작성하고 커뮤니티에서 '이러면 된다.', '저러면 된다.', '클린 아키텍처는 이래야 한다.' 등의 파편적인 정보들과 나름대로 공부한 정보들을 통해 익숙함을 높였습니다. 그러나 필요에 의해 사용하는 것이 아닌 맹목적인 사용이다 보니 이해의 영역과는 멀어지게 되었습니다. 때론 MVVM과 클린 아키텍처는 항상 세트구나, MVVM == 클린 아키텍처구나 하는 시기도 있었던 것 같습니다.

클린 아키텍처는 정말 클린한가?

본론으로 돌아와 클린 아키텍처는 정말 클린한가? 라는 질문을 생각해보면, 여러분들은 어떠신가요? 정말 클린한가요?

• 하나의 기능을 만들기 위해 클린 아키텍처의 기조를 따를 때 Presentation / Domain / Data 레이어에 생성되는 무수한 파일들... Clean한가요?
• Layer 간 만들어놓은 Mapper들. 왜 사용하는지에 대한 이해가 Clean한가요?
• Domain Layer의 Usecase와 Entity의 차이의 이해, Clean한가요?
• Usecase의 Input value와 Output value와 Entity의 필요성, Clean한가요?
• Domain이라는 개념, Clean한가요?
• Presentation 로직과 Business Logic의 차이, Clean한가요?
• 인터넷에 떠도는 Clean Architecture Diagram의 이해, Clean한가요?
• Usecase는 N개의 Repo를 받아도 되는가에 대한 질문, Clean한가요?
• Usecase는 어느 정도의 단위로 나누어야 할까요, Clean한가요?
• Domain레이어에 플랫폼 프레임웍을 반드시 배제해야한다. 다른 플랫폼에도 삽입할 수 있을만큼.. → 정말 다른 플랫폼에 삽입을 해본적!? , Clean한가요?
• 하다 보니 Presentation, Domain, Data에 동일한 속성의 DataClass들... Clean한가요?
• Repository와 DataSource의 차이, Clean한가요?
• Clean Architecture를 사용해서 정말로 유용한가, Clean한가요?
• DI (Hilt), 무수히 사용하는 Interface, Impl 구조의 구현의 유용성, Clean한가요?

몇 가지 질문을 던졌는데요.

혹시 클린하게 대답할 만한 질문이 있을까요?

또는 스스로 Clean하다고 생각하시나요? 저 중에 몇 가지는 지금까지도 고민하는 문제이기도 합니다.

안드로이드 개발자들과 이야기를 나누다 보면, 조금은 맹목적인 분위기를 많이 느끼곤 합니다. 무조건 시작부터 클린 아키텍처를 써야 좋다는 의견, 클린 아키텍처가 아키텍처의 왕이라는 의견, 클린 아키텍처를 쓸 거면 반드시 클린 아키텍처의 정의들대로 코드를 작성해야 한다는 의견 등 다양한 의견들이 있습니다.

 

사실 클린 아키텍처를 사용하다 보면 위에서 던진 질문 이외에도 굉장히 모순적이거나, 비효율적이거나 의미 없어 보이는 과정들을 많이 겪게 됩니다.

또한 대부분의 블로그에서는 근본적인 개념의 대한 설명이 아닌 "사용법"에 대한 글이 많습니다.

- Domain의 Entity가 하는 역할이 매우 빈약하고, Usecase의 구현법에만 치중함.

- 단순히 레이어 간 분리에만 포커스를 맞추어 Presentation / Domain / Data에 동일한 DataClass가 모든 피쳐마다 존재하는 것을 원래 레이어를 분리하려면 이렇다거나

- Domain이 가장 안쪽의 영역인데, API의 응답에 따라 어떻게 받을지를 고민하거나 (이러면 Domain이 Data에 의존성이 생기게 됩니다)

 

위 고민들은 이렇게 짜면 안될것 같은데... 라고 스스로 아이러니 함을 느끼면서도 관성처럼 코드를 짜는 중의 제 고민이기도 했습니다.

 

클린 아키텍처가 정말로 클린한가? 라는 질문에 대해 스스로도 명확한 답을 내리기 어렵지만, 중요한 것은 트렌드에 맹목적으로 따르기보다는, 각자의 상황과 필요에 맞게 유연하게 적용하는 것이 아닌가 생각합니다. 클린 아키텍처가 모든 상황에서 완벽한 해결책은 아니며, 오히려 불필요한 복잡성을 가져올 수도 있습니다. 중요한 것은 기본 원칙을 이해하고, 그것을 상황에 맞게 활용하는 것입니다.

 

저는 요즘 클린 아키텍처의 핵심은 익히 알고있는대로 Domain과 레이어링이고 이때 도메인이라는 계층을 나누는것 보다 중요한것이

Domain이라는 추상적인 개념이 무엇을 의미하는지 이해하고, 이 Domain의 특성에 따른 Entity를 구체적으로 설계한는 것이 가장 중요하다고 생각하고 있습니다.

 

Domain, DDD, Entity, Event등에 관해 고민을 이어나가고 있습니다.  이러한 고민이 없으면 오히려 Domain계층으로 인해 내 전체 프로젝트의 코드가 지저분해지기만 하는 현상을 겪으실 수 있습니다. 또한 정말 데이터를 담기만 하는 Immutable한 DataClass들이 비슷한 네이밍으로 이것저것 만들어져있는 카오스를 경험하시게 될것입니다.

 

또한 DI까지 도입해가며 레이어링과 인터페이스 분리를 해도 이 과정을 통해 테스트 코드를 작성해 내 코드를 검증하지 않으면 이것은 단순히 코드를 복잡하게 짜는 것일 뿐입니다. TDD를 적용하라는 이야기는 아닙니다. 다만, 우리가 OOP에 입각해 클린 아키텍처를 적용했다면 이 코드들이 잘 작성되었는지 “검증”까지 하는 것이 진정한 클린 아키텍처를 사용한다고 할 수 있을 것입니다.

 

지금은 제 나름대로 시행착오를 겪어, Domain Entity설계, Event분리,  Domain Layer에서의 ErrorHandling등 어느정도 고정된 포맷을 가지고 코드를 작성하고 있습니다. 더불어 모든 상황에 클린아키텍쳐를 사용하진 않으리라는 확신이 있습니다.

 

이런 과정들로 꼭 유행중인 클린아키텍쳐의 사용 이라는 고민에서 끝나지 않고 각자의 결론을 낼 수 있도록 끝까지 고민해보시길 바라겠습니다.

여러분들은 클린 아키텍처에 대해 어떻게 생각하시나요? 여러분의 경험과 생각을 나누어 주시면 감사하겠습니다.