
클린 아키텍처(Clean Architecture): 변하지 않는 핵심을 지켜라
로버트 C. 마틴(Uncle Bob)이 제안한 클린 아키텍처의 핵심은 무엇일까요? 양파 껍질 같은 계층 구조와 의존성 규칙(Dependency Rule)을 통해 프레임워크와 UI로부터 독립적인 소프트웨어를 만드는 방법을 정리합니다.

로버트 C. 마틴(Uncle Bob)이 제안한 클린 아키텍처의 핵심은 무엇일까요? 양파 껍질 같은 계층 구조와 의존성 규칙(Dependency Rule)을 통해 프레임워크와 UI로부터 독립적인 소프트웨어를 만드는 방법을 정리합니다.
서로 다른 인터페이스를 연결해주는 변환기. 레거시 시스템과 신규 시스템을 이어주는 가장 강력한 디자인 패턴.

프링글스 통(Stack)과 맛집 대기 줄(Queue). 가장 기초적인 자료구조지만, 이걸 모르면 재귀 함수도 메시지 큐도 이해할 수 없습니다.

페이스북은 왜 REST API를 버렸을까? 원하는 데이터만 쏙쏙 골라 담는 GraphQL의 매력과 치명적인 단점 (캐싱, N+1 문제) 분석.

단순히 해시(Hash)만 하면 1초 만에 뚫립니다. 레인보우 테이블 공격을 막기 위해 소금(Salt)과 후추(Pepper)를 치는 원리.

우리는 프로젝트를 시작할 때 습관적으로 이렇게 말합니다. "우리는 React 프레임워크를 쓸 거야." "우리는 Spring Boot 기반 프로젝트야." 하지만 로버트 C. 마틴(Uncle Bob)은 이렇게 일침을 놓습니다. "아키텍처는 도구(프레임워크)에 관한 것이 아니다. 아키텍처는 비즈니스 로직에 관한 것이다."
소프트웨어의 핵심 가치는 "사용자의 문제를 해결하는 로직"에 있지, "어떤 DB를 쓰는지", "어떤 웹 서버를 쓰는지"에 있지 않습니다. DB나 UI는 언제든 바뀔 수 있는 세부 사항(Detail)일 뿐입니다. 클린 아키텍처(Clean Architecture)는 이 "지저분한 세부 사항"으로부터 "고귀한 비즈니스 로직"을 철저히 격리하고 보호하기 위한 설계 철학입니다. 프레임워크는 도구지, 여러분의 주인이 아닙니다.
클린 아키텍처를 설명하는 가장 유명한 그림은 동심원(양파) 모양입니다. 이 그림에서 가장 중요한 규칙은 단 하나입니다.
"소스 코드 의존성은 반드시 안쪽(Inward)으로만 향해야 한다."안쪽 원에 있는 코드는 바깥쪽 원에 대해 아무것도 몰라야 합니다. Use Case(안쪽)는 SQL 쿼리(바깥쪽)가 어떻게 생겼는지, 심지어 DB가 오라클인지 MySQL인지도 몰라야 합니다. 데이터 포맷(JSON, XML)도 몰라야 합니다. 반대로 바깥쪽(Controller)은 안쪽(Use Case)을 알고 호출할 수 있습니다. 이것이 핵심입니다.
일반적으로 4개의 계층으로 나뉩니다. (안쪽 -> 바깥쪽 순서)
User, Order, Loan 같은 도메인 객체들이 여기에 해당합니다."아니, Use Case가 데이터를 저장하려면 DB를 호출해야 하는데, 어떻게 DB를 모를 수가 있죠?" 여기서 의존성 역전 원칙(Dependency Inversion Principle)이 등장합니다. 이것이 클린 아키텍처를 가능하게 하는 기술적 토대입니다.
UserRepository라는 인터페이스(Interface)만 정의하고 호출합니다. ("나는 'save'라는 기능이 필요해! 누가 좀 해줘!")UserRepositoryImpl)이렇게 하면 소스 코드 상에서 Use Case는 DB 구현체를 import 하지 않습니다. 제어의 흐름(Flow of Control)은 안에서 밖으로 나가지만(호출하지만), 소스 코드 의존성은 밖에서 안으로 들어옵니다. 이것이 핵심입니다.
좋은 아키텍처는 시스템의 목적을 큰 소리로 외쳐야 합니다.
도서관 시스템의 최상위 폴더를 열었을 때 Books, Members, Loans가 보여야 합니다.
만약 Controllers, Views, Models 같은 프레임워크 폴더 구조만 보인다면, 그것은 "나는 Spring Boot 앱이야!"라고 외치는 꼴입니다.
"이 시스템은 도서 관리 시스템입니다"라고 외치게 만드세요. 프레임워크는 그저 세부 사항일 뿐입니다.
이 복잡한 짓을 왜 할까요?
"그럼 모든 프로젝트에 클린 아키텍처를 적용해야 하나요?" 아닙니다. 과유불급입니다. 간단한 CRUD 앱이나 토이 프로젝트, 수명이 짧은 프로토타입에 클린 아키텍처를 도입하면 파일 개수만 3배로 늘어나고 개발 속도는 느려집니다. (보일러플레이트 지옥)
하지만 프로젝트가 커지고, 팀원이 늘어나고, 유지보수 기간이 3년, 5년으로 길어진다면 클린 아키텍처는 빛을 발합니다. 처음에는 조금 느리더라도, 나중에는 기능을 추가하거나 수정하는 비용이 기하급수적으로 줄어들기 때문입니다. 유지보수 비용을 낮추는 것이 아키텍처의 진짜 목적입니다.
"빨리 가는 유일한 방법은, 제대로 가는 것이다." - Robert C. Martin