Clean Architecture에 대한 고찰 [3]

 

# Clean Architecture 과연 좋은 아키텍처인가?

우리나라 특성상 유행되는 것이라면 순식간에 번지는 경향이 있다.

특히 클린 아키텍처 같은 경우, 기업들도 많이 선호하고,

아키텍처 사이들 중에서도 선호되는 아키텍처이기 때문에

유행처럼 번지는 경향이 많다.

 

필자도 포트폴리오를 만들기 위한 프로젝트를 전부 클린 아키텍처로 구현한 경험이 있다.

하지만 소규모 플젝 같은 경우에도 클린 아키텍처로 구현하는 것이 과연 좋은 것일까?

절대 그렇지 않다.  

 

챗지피티한테 클린아키텍처의 장점과 단점을 물어보니 이렇게 답변해 주었다.

 

✅ 장점

1. 관심사의 분리 (Separation of Concerns)
   • UI, 비즈니스 로직, 데이터 접근 코드가 명확하게 분리되어 유지보수가 쉬워짐.
   • 기능 추가나 수정 시 다른 계층에 영향을 최소화.
2. 테스트 용이성 (Testability)
   • 비즈니스 로직이 외부에 의존하지 않기 때문에 단위 테스트가 쉬움.
   • UI나 DB 없이도 핵심 로직 테스트 가능.
3. 유연한 기술 교체
   • 프레임워크, UI, DB 등을 쉽게 교체할 수 있음. 예: Android → iOS, Firebase → REST API.
4. 높은 재사용성
   • 도메인 계층의 로직은 다양한 플랫폼(Android, iOS, Web 등)에서 재사용 가능.
5. 확장성과 유지보수성
   • 코드 구조가 명확해지고, 팀이 커져도 협업이 쉬움

 

클린 아키텍처 특성상 도메인을 통한 의존성과 관심사 분리로

테스트 및 유연한 기술 교체가 가능하다.

또한 높은 재사용성과 확장성, 유지보수성도 좋다.

 

하지만 이 같은 장점은 대규모 플젝에서나 유효하고,

실제로 소규모 플젝과 빠른 구현이 목표라면

클린 아키텍처가 아닌 다른 아키텍처를 사용하는 것이 좋다고 생각한다.

❌ 단점

1. 초기 개발 난이도 상승
   • 아키텍처 구성과 계층 설계에 대한 학습 곡선이 있음.
   • 초반에는 코딩보다 설계에 더 많은 시간 소요.
2. 복잡도 증가
   • 계층이 많아져서 파일 수 증가, 구조가 복잡해짐.
   • 소규모 프로젝트에는 오히려 과한 구조가 될 수 있음.
3. 생산성 저하 (초기)
   • 뼈대와 추상화 코드(인터페이스 등)를 먼저 작성해야 하므로 빠른 프로토타이핑에 불리함.
4. 개발자 간의 이해도 차이
   • 팀원들이 아키텍처에 대한 이해가 부족하면 오히려 잘못된 분리로 혼란을 유발할 수 있음.

 

이처럼 팀원들과 같이 플젝을 진행할 때,

팀원이 클린 아키텍처에 대한 이해가 부족한 경우, 

필자처럼 엄청난 무지의 실수를 저지를 수 있다고 생각한다.

 

또한 여러 구조로 나뉘어 불필요한 복잡도가 생기며

뼈대 있는 구조를 초기에 잡아야 하기 때문에 생산성이 지연될 수 있다.

비유하자면, 소규모 플젝 같은 경우 배보다 배꼽이 더 커질 수 있다는 이야기이다.

 

그리고 개발자 간의 이해도 또한 많은 차이가 있기 때문에

클린 아키텍처에 대한 완전한 이해가 아닌 경우

클린 아키텍처가 아닌 애매한 아키텍처로 변질될 수 있다.

 

따라서 무조건 좋다고 클린 아키텍처를 활용하는 것이 아닌

플젝의 규모와 팀원들이 클린 아키텍처를

얼마나 이해하고 있는지 확인한 후, 적용하는 것이 좋다고 생각한다.

 

물론 클린 아키텍처에 대한 이해가 목적이라면 플젝 규모에 상관없이 적용해도 좋다.

 

안드로이드 플젝을 진행하며, 클린 아키텍처를 눈으로만 보았었는데

막상 여러 시행착오를 겪으며 구현하니

이제 어떤 아키텍처인지 확실한 이해가 돼서 너무 좋았다.