클린 아키텍처 (Robert C. Martin) 핵심 정리·유지보수 가능한 설계 원칙

안녕하세요, DeepCode 입니다. 이번 글에서는 클린 아키텍처(Robert C. Martin)을 정리해보려고 합니다. 소프트웨어 설계의 근본적인 원칙을 고민하던 중, 더 견고한 시스템을 만들기 위한 이정표가 필요하여 이 책을 집어 들게 되었습니다.

출처: 알라딘

 

1. 클린 아키텍처 (Robert C. Martin), 어떤 책인가요

이 책은 소프트웨어 공학의 거장 로버트 C. 마틴(Uncle Bob)이 집필하였으며, 복잡한 소프트웨어 시스템을 어떻게 설계해야 유지보수가 쉽고 변화에 유연하게 대응할 수 있는지를 다룹니다. 시스템의 구성 요소들을 어떻게 분리하고, 그 사이의 의존성을 어떻게 관리해야 하는지에 대한 철학적, 기술적 근거를 제시합니다. 핵심 메시지는 소프트웨어의 핵심 비즈니스 로직을 외부 환경(DB, UI, 프레임워크)으로부터 독립시켜야 한다는 것입니다.

2. 소프트웨어의 경계를 나누고 의존성을 제어하는 설계 철학

클린 아키텍처가 관통하는 가장 중요한 명제는 의존성의 방향을 안쪽으로 향하게 만드는 것입니다. 시스템의 중심에는 비즈니스 규칙이 존재해야 하며, 데이터베이스나 웹 프레임워크 같은 세부 사항은 언제든 교체 가능한 부속품처럼 취급되어야 합니다. 즉, 소프트웨어의 가치는 기술 스택이 아니라 그 안에 담긴 도메인 로직의 순수성에서 결정된다는 관점을 견지합니다.

3. 인상 깊었던 챕터 3가지

1.1 컴포넌트 분리와 경계의 중요성

"경계가 없는 소프트웨어는 모든 것이 엉겨 붙어 결국 수정 불가능한 상태가 된다." (p.42)

설계에서 가장 중요한 것은 무엇을 연결할지가 아니라, 무엇을 분리할지를 결정하는 일임을 깨닫게 해줍니다. 경계가 명확하지 않으면 작은 수정 하나가 시스템 전체로 번지는 스파게티 코드가 됩니다.

1.2 의존성 역전 원칙(DIP)의 실전 적용

저자는 상위 수준의 모듈이 하위 수준의 모듈에 의존해서는 안 된다고 강조합니다. 제 기준으로 정리하면, 인터페이스를 활용해 제어의 흐름을 뒤집는 작업이 아키텍처의 유연성을 결정짓는 핵심 기술이라고 생각합니다. 이를 통해 프레임워크에 종속되지 않는 코드를 작성할 수 있습니다.

1.3 테스트 가능한 설계의 조건

"테스트하기 쉬운 코드는 곧 좋은 설계다." (p.158)

아키텍처의 목적 중 하나는 테스트 용이성입니다. 비즈니스 로직이 UI나 DB와 결합되어 있다면 단위 테스트는 불가능해집니다. 테스트가 가능하다는 것은 설계가 이미 올바른 방향으로 분리되어 있다는 강력한 증거입니다.

4. 실무와 일상에 적용하는 방법

1. 도메인 모델을 작성할 때 외부 라이브러리나 프레임워크의 어노테이션을 최소화하여 순수하게 유지합니다.
2. 데이터베이스 스키마를 먼저 설계하기보다, 비즈니스가 수행해야 할 행위와 규칙을 먼저 정의합니다.
3. 의존성 주입(DI) 컨테이너를 활용하여 객체 간의 결합도를 낮추는 연습을 반복합니다.
4. 새로운 기능을 추가할 때 기존 로직을 수정하는 대신, 새로운 계층이나 컴포넌트를 추가하는 방향을 고민합니다.

5. 추천 대상 / 비추천 대상

시스템의 구조적 결함으로 인해 유지보수에 어려움을 겪고 있는 시니어 개발자나, 코드의 품질을 높이고 싶은 주니어 개발자들에게는 필독서입니다. 객체지향 원칙(SOLID)을 실제 아키텍처로 확장하고 싶은 분들에게 매우 유익합니다. 반면, 당장 돌아가는 코드를 빠르게 찍어내는 것이 최우선인 환경에 있거나, 추상화 개념에 익숙하지 않은 완전 초보자에게는 다소 이론적이고 무겁게 느껴질 수 있어 학습 시간이 필요합니다.

자주 묻는 질문 5가지

Q1. 이 책이 초보 개발자에게도 읽힐 만큼 쉬운가요?

개념 자체는 명확하지만, 이를 뒷받침하는 객체지향 원칙에 대한 이해가 선행되어야 합니다. SOLID 원칙을 먼저 공부한 뒤 읽으시면 훨씬 수월하게 읽으실 수 있습니다.

Q2. 실무에서 이 아키텍처를 적용하면 개발 속도가 느려지지 않나요?

초기 설계 단계에서는 코드를 작성하는 시간이 더 걸릴 수 있습니다. 하지만 프로젝트가 커지고 변경 사항이 생길 때 발생하는 비용을 획기적으로 줄여주므로 장기적으로는 훨씬 빠릅니다.

Q3. 모든 프로젝트에 클린 아키텍처가 필요한가요?

단순한 CRUD 위주의 소규모 토이 프로젝트라면 과도한 설계(Over-engineering)가 될 수 있습니다. 비즈니스 로직이 복잡하고 수명이 긴 시스템일수록 그 가치가 빛을 발합니다.

Q4. 의존성 역전 원칙(DIP)을 이해하기 가장 좋은 방법은 무엇인가요?

인터페이스를 중간에 두어 상위 모듈이 하위 모듈의 구체적인 구현을 몰라도 동작하게 만드는 구조를 직접 코드로 구현해 보는 것이 가장 빠릅니다.

Q5. 책에서 말하는 계층 구조는 반드시 지켜야 하는 규칙인가요?

절대적인 법은 아니지만, 의존성의 방향이 안쪽(도메인)을 향한다는 원칙은 지키는 것이 좋습니다. 계층의 이름이나 개수는 프로젝트의 규모에 맞게 조정할 수 있습니다.

관련 글 추천

정리해보면, 클린 아키텍처는 소프트웨어의 핵심 로직을 외부 환경으로부터 격리하여 변화에 강한 시스템을 만드는 방법을 가르쳐줍니다. 의존성 관리와 경계 설정이 설계의 핵심이며, 이는 곧 테스트 가능한 코드로 이어집니다. 기술적인 도구보다 원칙에 집중하는 태도가 중요함을 배울 수 있습니다. 다음 글에서는 SOLID 원칙을 실제 코드로 구현하는 방법을 다뤄보겠습니다.