개발자라면 누구나 한 번쯤은 마주하는 고민이 있습니다. 처음에는 완벽해 보였던 시스템이 요구사항 변경에 휘청거리고, 작은 수정이 예상치 못한 버그를 유발하며, 새로운 기능을 추가하기가 점점 어려워지는 상황 말이죠. 저 역시 수많은 프로젝트를 거치면서 이런 문제에 부딪히곤 했습니다. 스프링 프레임워크나 닷넷 같은 특정 기술 스택에 종속되거나, 데이터베이스 스키마 변경 하나에 전체 시스템이 흔들리는 경험은 비단 저만의 이야기는 아닐 겁니다.
이런 상황에서 견고하고 유연한 소프트웨어 설계에 대한 갈증은 필연적으로 찾아옵니다. 그리고 그 갈증을 해소하는 데 큰 도움을 준 책이 바로 로버트 C. 마틴(Robert C. Martin)의
클린 아키텍처: 견고하고 유연한 소프트웨어 설계를 위한 핵심 원칙입니다. 이 책을 직접 읽고 제 프로젝트에 적용해 보면서 느꼈던 점들, 그리고 클린 아키텍처가 과연 어떤 가치를 주는지 실무적인 관점에서 공유해보고자 합니다.
📑 목차
Image by pixelcreatures on Pixabay
왜 클린 아키텍처인가? 변화에 대응하는 시스템의 중요성
소프트웨어 개발은 끊임없는 변화의 연속입니다. 고객의 요구사항은 시시각각 변하고, 새로운 기술은 계속 등장하며, 시장의 흐름 또한 예측하기 어렵습니다. 이런 환경에서 만들어진 시스템이 변화에 제대로 대응하지 못한다면, 결국 유지보수 비용은 기하급수적으로 늘어나고 개발팀의 생산성은 바닥을 치게 됩니다. 실제로 제가 참여했던 한 프로젝트에서는 기능 추가 요청이 있을 때마다 기존 코드를 너무 많이 건드려야 해서, 간단한 기능 하나를 구현하는 데도 며칠씩 걸리곤 했습니다. 이런 경험은 클린 아키텍처의 필요성을 더욱 절감하게 만들었습니다.
클린 아키텍처는 특정 프레임워크나 데이터베이스, UI 기술에 얽매이지 않고 비즈니스 규칙이 시스템의 핵심에 위치하도록 설계하는 것을 목표로 합니다. 이를 통해 시스템은 외부 기술의 변화에 유연하게 대응하고, 비즈니스 로직을 변경하는 데 드는 비용을 최소화할 수 있습니다. 예를 들어, 웹 프레임워크를 스프링에서 다른 프레임워크로 변경하거나, 데이터베이스를 관계형 DB에서 NoSQL로 전환해야 할 때, 클린 아키텍처가 적용된 시스템은 핵심 비즈니스 로직에 큰 영향을 주지 않고도 비교적 쉽게 대응할 수 있습니다. 직접 적용해 본 결과, 이런 유연성은 장기적인 관점에서 엄청난 이점으로 작용했습니다.
전통적인 아키텍처의 문제점과 한계
대부분의 개발자들이 가장 먼저 접하는 아키텍처는 아마도 흔히 말하는 N-Tier 아키텍처일 것입니다. UI, 비즈니스 로직, 데이터 접근 계층으로 나뉘는 구조죠. 이는 간단하고 직관적이지만, 대개 상위 계층이 하위 계층에 강하게 의존하는 구조를 가집니다. 예를 들어, 비즈니스 로직 계층이 데이터 접근 계층에, 데이터 접근 계층이 특정 데이터베이스 기술에 강하게 의존하게 됩니다. 이런 의존성은 처음에는 문제가 없어 보이지만, 특정 기술 스택에 대한 종속성을 심화시키고, 나중에 해당 기술을 변경하기 어렵게 만듭니다.
제가 경험했던 사례 중 하나는 기존 RDB 기반의 시스템에서 특정 기능만 NoSQL로 전환해야 하는 상황이었습니다. 하지만 기존 비즈니스 로직이 RDB의 ORM(Object-Relational Mapping) 구현체에 깊이 결합되어 있어, NoSQL 관련 코드를 추가하는 것이 아니라 비즈니스 로직 자체를 상당 부분 수정해야 했습니다. 이는 명백히 응집도와 결합도 측면에서 좋지 않은 설계였고, 결국 많은 시간과 비용을 들여 리팩토링해야만 했습니다. 클린 아키텍처는 이런 문제를 의존성 역전 원칙(Dependency Inversion Principle)을 통해 해결하려 합니다.
클린 아키텍처의 핵심 원칙 파고들기: 계층형 구조와 의존성 규칙
클린 아키텍처의 핵심은 바로 동심원의 계층형 구조와 엄격한 의존성 규칙입니다. 책에서는 이 구조를 원으로 표현하는데, 가장 안쪽 원에는 엔티티(Entities)와 유즈케이스(Use Cases)가, 바깥쪽 원에는 인터페이스 어댑터(Interface Adapters), 그리고 가장 바깥쪽 원에는 웹, DB, UI 등 프레임워크와 드라이버(Frameworks & Drivers)가 위치합니다.
- 엔티티 (Entities): 비즈니스 규칙 중 가장 일반적이고 높은 수준의 규칙을 담습니다. 애플리케이션에 특화되지 않은, 순수한 비즈니스 객체입니다.
- 유즈케이스 (Use Cases): 애플리케이션에 특화된 비즈니스 규칙을 담습니다. 사용자의 특정 행동(예: 상품 주문, 사용자 정보 업데이트)에 대한 응용 로직을 정의합니다. 엔티티를 조작하여 비즈니스 목표를 달성합니다.
- 인터페이스 어댑터 (Interface Adapters): 유즈케이스와 외부 세계(DB, UI, 웹 등) 사이의 데이터를 변환합니다. 프레젠터, 게이트웨이, 컨트롤러 등이 여기에 해당합니다.
- 프레임워크와 드라이버 (Frameworks & Drivers): 데이터베이스, 웹 프레임워크, UI 프레임워크 등 가장 바깥쪽의 세부 구현 기술들입니다.
가장 중요한 의존성 규칙은 "안쪽 원은 바깥쪽 원에 대해 아무것도 알아서는 안 된다"는 것입니다. 즉, 의존성의 방향은 항상 안쪽으로 향해야 합니다. 예를 들어, 유즈케이스는 데이터베이스의 존재를 몰라야 하고, 엔티티는 웹 프레임워크의 존재를 몰라야 합니다. 이런 엄격한 규칙을 통해 핵심 비즈니스 로직은 외부 기술 스택의 변화로부터 철저히 격리될 수 있습니다.
의존성 역전 원칙(DIP)의 실제 적용
이 의존성 규칙을 가능하게 하는 핵심이 바로 의존성 역전 원칙(DIP)입니다. DIP는 "추상화는 세부 사항에 의존해서는 안 된다. 세부 사항이 추상화에 의존해야 한다"고 말합니다. 즉, 고수준 모듈(유즈케이스)은 저수준 모듈(데이터베이스)에 직접 의존하는 대신, 추상화(인터페이스)에 의존해야 합니다. 그리고 저수준 모듈은 이 추상화를 구현해야 합니다.
예를 들어, 사용자 정보를 저장하는 유즈케이스가 있다고 가정해 봅시다. 이 유즈케이스는 특정 데이터베이스의 `UserRepositoryImpl` 클래스에 직접 의존하는 대신, `UserRepository` 인터페이스에 의존해야 합니다. 그리고 `UserRepositoryImpl`은 이 `UserRepository` 인터페이스를 구현합니다. 이렇게 하면 유즈케이스는 어떤 데이터베이스가 사용되는지 전혀 알 필요가 없게 됩니다.
// 1. 유즈케이스 (고수준 모듈)가 의존하는 추상화
public interface UserRepository {
User findById(Long id);
void save(User user);
}
// 2. 유즈케이스 (고수준 모듈)
public class UserService {
private final UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public User getUserInfo(Long id) {
return userRepository.findById(id);
}
public void registerUser(User user) {
// 비즈니스 로직
userRepository.save(user);
}
}
// 3. 데이터베이스 구현체 (저수준 모듈) - 추상화에 의존
public class JpaUserRepository implements UserRepository {
// JPA 관련 코드
@Override
public User findById(Long id) {
// JPA find 로직
return new User(id, "Test User"); // 예시
}
@Override
public void save(User user) {
// JPA save 로직
}
}
// 4. 컨트롤러 (바깥쪽 계층)에서 의존성 주입
// public class UserController {
// private final UserService userService;
//
// public UserController(UserService userService) {
// this.userService = userService;
// }
// // ...
// }
위 코드에서 UserService는 UserRepository 인터페이스에만 의존합니다. 만약 데이터베이스를 JPA에서 MongoDB로 변경해야 한다면, JpaUserRepository 대신 MongoUserRepository를 구현하고 주입하기만 하면 됩니다. UserService의 코드는 전혀 변경할 필요가 없습니다. 실제로 이런 구조를 통해 데이터베이스 마이그레이션이 훨씬 수월했던 경험이 있습니다.
SOLID 원칙, 실제 코드에 어떻게 녹여낼까?
클린 아키텍처는 SOLID 원칙과 뗄레야 뗄 수 없는 관계를 가집니다. SOLID는 객체 지향 설계의 5가지 핵심 원칙으로, 클린 아키텍처의 각 계층을 설계하고 구현하는 데 중요한 지침이 됩니다. 이 책은 SOLID 원칙을 단순히 설명하는 것을 넘어, 클린 아키텍처와 어떻게 연계하여 적용해야 하는지 깊이 있게 다룹니다.
- SRP (단일 책임 원칙): 하나의 클래스는 하나의, 오직 하나의 변경 이유만을 가져야 합니다. 유즈케이스는 단일 비즈니스 목표를, 엔티티는 단일 비즈니스 규칙을 책임지도록 설계합니다.
- OCP (개방-폐쇄 원칙): 확장에 대해서는 열려 있어야 하고, 변경에 대해서는 닫혀 있어야 합니다. 인터페이스를 통해 시스템을 확장하고, 기존 코드를 수정하지 않고 새 기능을 추가할 수 있도록 합니다.
- LSP (리스코프 치환 원칙): 서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 합니다. 다형성을 올바르게 활용하여 유연한 시스템을 구축합니다.
- ISP (인터페이스 분리 원칙): 클라이언트는 자신이 사용하지 않는 인터페이스에 의존해서는 안 됩니다. 큰 인터페이스보다는 작고 구체적인 인터페이스를 선호합니다.
- DIP (의존성 역전 원칙): 고수준 모듈은 저수준 모듈에 의존해서는 안 됩니다. 둘 다 추상화에 의존해야 합니다. (앞서 설명)
저는 특히 SRP를 유즈케이스 설계에 적용하면서 큰 효과를 보았습니다. 하나의 유즈케이스가 너무 많은 기능을 담당하지 않도록 세분화함으로써, 특정 기능의 변경이 다른 기능에 미치는 영향을 최소화할 수 있었습니다. 예를 들어, '상품 주문' 유즈케이스와 '상품 재고 관리' 유즈케이스를 분리하여, 주문 로직 변경이 재고 관리 로직에 영향을 주지 않도록 한 것입니다. 이는 코드의 가독성을 높이고, 테스트를 용이하게 하며, 궁극적으로는 시스템의 유지보수성을 크게 향상시켰습니다.
Image by shuraki on Pixabay
클린 아키텍처, 프로젝트에 적용해 본다면? 장점과 도전 과제
클린 아키텍처를 실제 프로젝트에 적용하는 것은 분명 쉬운 일은 아닙니다. 초기 설계 단계에서 더 많은 고민과 시간을 요구하며, 팀원들의 이해와 합의가 필수적입니다. 하지만 그만큼 얻게 되는 이점도 명확합니다.
클린 아키텍처의 실질적인 장점
- 독립적인 테스트 용이성: 핵심 비즈니스 로직(엔티티, 유즈케이스)이 프레임워크, DB, UI로부터 완전히 분리되어 있기 때문에, 이 부분만 독립적으로 테스트하기가 매우 쉽습니다. Mock 객체를 활용하면 데이터베이스나 외부 API 의존성 없이 유즈케이스를 빠르게 검증할 수 있습니다. 실제로 TDD(테스트 주도 개발)를 적용할 때 클린 아키텍처는 빛을 발했습니다.
- 프레임워크/DB/UI 독립성: 특정 기술 스택에 종속되지 않습니다. 기술 변화에 유연하게 대응할 수 있으며, 필요하다면 언제든지 다른 기술로 교체할 수 있는 기반을 마련합니다. 이는 장기적인 관점에서 시스템의 생명력을 연장시킵니다.
- 유지보수성 향상: 관심사의 분리가 명확하여 코드의 가독성이 높고, 특정 기능 수정 시 영향을 받는 범위가 최소화됩니다. 이는 버그 발생률을 낮추고, 신규 개발 및 기능 개선 속도를 높이는 데 기여합니다.
- 확장성 증대: 새로운 기능을 추가할 때 기존 코드를 건드리지 않고 새로운 유즈케이스를 추가하거나 어댑터를 구현하는 방식으로 확장할 수 있습니다.
클린 아키텍처 적용의 도전 과제
물론 장점만 있는 것은 아닙니다. 클린 아키텍처를 도입할 때 다음과 같은 도전 과제에 직면할 수 있습니다.
| 측면 | 설명 | 실제 경험 |
|---|---|---|
| 초기 학습 곡선 | 새로운 개념과 원칙(특히 DIP)에 대한 이해가 필요하며, 기존 개발 방식과 달라 혼란을 줄 수 있습니다. | 팀원들이 초기에 "왜 이렇게 복잡하게 해야 하는가?"라는 의문을 가졌으나, 점차 장점을 체감하며 적응했습니다. |
| 초기 개발 비용 | 추상화 계층을 더 많이 생성해야 하므로, 초기 설계 및 구현에 더 많은 시간과 노력이 필요합니다. | POC(개념 증명) 단계에서 시간 투자가 많았지만, 이후 기능 추가 및 변경 시 개발 속도가 확연히 빨라졌습니다. |
| 과도한 추상화 | 작은 프로젝트나 단순한 기능에 클린 아키텍처를 과도하게 적용하면 오히려 복잡성만 증가할 수 있습니다. | 프로젝트 규모와 요구사항의 변경 가능성을 고려하여 적절한 수준의 추상화를 적용하는 것이 중요했습니다. 'YAGNI' 원칙을 잊지 않아야 합니다. |
| 팀원 간 합의 | 아키텍처 스타일에 대한 팀원들의 이해와 합의 없이는 일관된 구현이 어렵고 혼란만 가중될 수 있습니다. | 정기적인 코드 리뷰와 아키텍처 스터디를 통해 팀 전체의 이해도를 높이는 데 주력했습니다. |
실무에서 마주친 고민과 해결 과정
이론은 언제나 아름답지만, 실무는 늘 예기치 못한 변수로 가득합니다. 클린 아키텍처를 적용하면서 저 역시 여러 고민에 부딪혔습니다.
가장 큰 고민 중 하나는 "어디까지 클린하게 가져갈 것인가?"였습니다. 모든 기능에 완벽하게 클린 아키텍처를 적용하려다 보니 초기 개발 속도가 너무 더뎌지는 문제가 발생했습니다. 특히 작은 CRUD성 기능에까지 굳이 유즈케이스를 분리하고 여러 인터페이스를 두는 것이 과연 효율적인가에 대한 의문이 들었습니다. 이 고민의 해결책은 점진적인 적용이었습니다.
저희 팀은 핵심 비즈니스 로직이 집중되고 변경 가능성이 높은 도메인에 우선적으로 클린 아키텍처를 적용하기로 합의했습니다. 예를 들어, 결제 시스템이나 상품 주문 로직처럼 복잡하고 변화가 잦은 부분은 철저히 원칙을 따랐습니다. 반면, 단순한 사용자 정보 조회와 같은 기능은 전통적인 N-Tier 방식에 가깝게 유지하거나, 유즈케이스를 간단하게 구현하여 초기 개발 속도를 확보했습니다. 이는 클린 아키텍처가 만능 해결책이 아니라, 적재적소에 사용되어야 할 도구라는 점을 깨닫게 해주었습니다.
또 다른 고민은 데이터 모델과 도메인 모델의 분리였습니다. 데이터베이스 스키마와 거의 동일한 엔티티를 도메인 계층에서 사용하는 경우가 많았습니다. 하지만 클린 아키텍처 관점에서는 순수한 도메인 엔티티는 데이터베이스의 제약사항으로부터 자유로워야 합니다. 그래서 도메인 엔티티와 데이터베이스 엔티티(ORM 엔티티)를 분리하고, 어댑터 계층에서 이 둘을 서로 변환하는 전략을 사용했습니다. 초기에는 매핑 작업이 번거롭게 느껴졌지만, 시간이 지날수록 도메인 엔티티가 비즈니스 규칙을 더 명확하게 표현하고, 데이터베이스 변경에 대한 부담이 줄어드는 장점을 체감할 수 있었습니다.
Image by Pexels on Pixabay
클린 아키텍처, 누구에게 추천할까?
이 책은 소프트웨어 아키텍처에 대한 깊이 있는 이해를 원하는 모든 개발자에게 추천합니다.
- 시니어 개발자 및 아키텍트: 프로젝트의 전체적인 구조를 고민하고, 유지보수성과 확장성을 고려한 설계를 해야 하는 분들에게는 필수적인 지침서입니다. 책에서 제시하는 다양한 아키텍처 패턴과 원칙들은 실무에서 마주하는 복잡한 문제들을 해결하는 데 큰 통찰력을 제공할 것입니다.
- 주니어 개발자: 당장 모든 내용을 이해하고 적용하기는 어려울 수 있지만, 클린 코드와 SOLID 원칙에 대한 탄탄한 기초를 다지고 싶은 주니어 개발자에게도 강력히 추천합니다. 처음부터 좋은 아키텍처 습관을 들이는 것은 나중에 큰 자산이 됩니다. 처음에는 책의 핵심 개념과 SOLID 원칙부터 집중해서 읽어보는 것을 권장합니다.
- 기술 부채로 고통받는 팀: 변경에 취약하고 버그가 잦은 시스템으로 인해 고통받는 팀이라면, 클린 아키텍처를 통해 근본적인 해결책을 모색해 볼 수 있습니다. 점진적인 리팩토링 전략을 세워 클린 아키텍처의 원칙을 적용해 나간다면, 서서히 시스템의 건강도를 회복할 수 있을 것입니다.
마무리하며: 지속 가능한 개발을 위한 선택
클린 아키텍처는 단순히 멋진 구조를 만드는 것을 넘어, 지속 가능한 소프트웨어 개발을 위한 철학이자 실천 방법론입니다. 처음에는 복잡하고 어렵게 느껴질 수 있지만, 책에서 제시하는 원칙들을 이해하고 실제 프로젝트에 적용해 본다면, 견고하고 유연한 시스템을 구축하는 데 필요한 지혜를 얻을 수 있을 것입니다. 제가 직접 이 책의 가르침을 따르며 개발해 본 결과, 시스템의 변경 비용이 현저히 줄어들고, 팀의 생산성이 향상되는 것을 분명히 경험했습니다.
물론 클린 아키텍처가 모든 프로젝트의 만능 해법은 아닙니다. 프로젝트의 규모, 팀의 역량, 요구사항의 복잡성 등을 고려하여 유연하게 적용하는 지혜가 필요합니다. 하지만 소프트웨어의 품질과 수명을 고민하는 개발자라면, 이 책은 분명 여러분의 사고방식을 한 단계 끌어올리는 소중한 경험을 선사할 것입니다.
여러분은 클린 아키텍처에 대해 어떻게 생각하시나요? 실제 프로젝트에 적용해 본 경험이 있으시다면 어떤 장점이나 어려움을 겪으셨는지 댓글로 공유해 주시면 좋겠습니다. 함께 더 나은 소프트웨어 설계를 고민해 봅시다!