클린 아키텍처 스터디 5주차 후기: 업무 규칙의 이데아, 경계의 비용, 그리고 실무적 딜레마 (20장~25장)
안녕하세요. 5주차에서는 로버트 C. 마틴의 『클린 아키텍처』 20장부터 25장까지의 내용을 다루었습니다. 이번 시간을 통해서는 클린 아키텍처 소프트웨어의 진정한 핵심이 되는 업무 규칙(Business Rules)과 이를 현실의 지저분한 기술 요소들로부터 분리해 내는 구체적인 전략에 대해 논의했습니다.
단순한 책거리 요약을 넘어, 철학적 메타포(플라톤의 이데아)부터 프론트엔드 아키텍처, 헥사고날 아키텍처가 낳는 'DTO 폭발' 현상, 그리고 테스트 코드데 대한 여러 인사이트가 오갔습니다. 스터디 발제와 토론 내용을 상세히 정리하여 공유합니다.
1. 철학과 본질: 업무 규칙의 '이데아'와 험블 객체
20장에서 25장까지의 내용은 결국 "무엇이 핵심이고, 무엇이 부가적인가"를 나누는 작업입니다. 스터디에서는 이를 플라톤의 '이데아(Idea)'에 빗대어 해석하는 흥미로운 관점이 제시되었습니다.
비즈니스 규칙은 이데아, 프레임워크는 그림자
소프트웨어가 없던 시절부터 존재했던 본질적인 가치와 데이터(예: 대출 이자 계산, 재고 차감)가 바로 시스템의 이데아(핵심 업무 규칙)입니다. 반면 우리가 매일 고민하는 MySQL, React, Spring Framework, HTTP 프로토콜 등은 이데아를 현실 세계에 투영하기 위한 그림자(세부 구현 사항)에 불과합니다. 클린 아키텍처는 그림자의 변화에 이데아가 흔들리지 않도록, 이데아(엔티티와 유스케이스)를 시스템의 가장 깊은 곳에 순수하게 격리하는 철학입니다.
이번 스터디에서 가장 많은 '아하(Aha!)' 모먼트를 자아낸 개념은 험블 객체였습니다. 테스트하기 어려운 행위와 쉬운 행위를 분리하는 이 패턴은 단순히 UI에만 국한되지 않습니다.
DB와 외부 API도 험블이다: 데이터베이스 통신이나 결제 API 호출 같은 영역 역시 우리가 완벽히 통제할 수 없는 '외부 요소'입니다. 이를 험블 객체로 취급하여 껍데기로 남겨두고, 모킹(Mocking)을 통해 핵심 로직만 테스트하는 것이 아키텍처의 기본입니다.
프론트엔드에서의 험블: 프론트엔드 역시 마찬가지입니다. 화면의 픽셀을 이동시키고 브라우저의 렌더링을 다루는 뷰(View) 영역은 '인간'이라는 변화무쌍한 존재와 상호작용하기 위한 험블 객체입니다. 따라서 화면을 그리는 일은 험블에게 맡기고, "어떤 데이터를 언제 노출할 것인가"를 결정하는 프리젠터(Presenter)의 행위 검증에 테스트 역량을 집중해야 합니다.
과거 EJB(Enterprise JavaBeans) 시절, 개발자들은 비즈니스 로직보다 프레임워크의 XML 설정을 맞추는 데 일주일을 허비하곤 했습니다. 이러한 '기술 침투적 아키텍처'에 대한 반발로 POJO(Plain Old Java Object) 기반의 애자일과 클린 아키텍처가 탄생했습니다.
ERD가 아닌 '유스케이스'가 시작점이다
도메인 설계를 할 때 여전히 DB 스키마(ERD)부터 그리는 관성이 남아있습니다. 하지만 현대의 설계는 이벤트 스토밍(Event Storming)을 통해 플로우와 맥락, 즉 유스케이스(Use Case)를 먼저 도출해야 합니다.
사용자가 어떤 트리거를 발생시키는가?
그로 인해 어떤 엔티티의 상태가 변경되는가?
부수적으로 어떤 외부 시스템(알림, 캐시 등)이 호출되어야 하는가?
이러한 유스케이스가 머릿속에 명확히 그려지고 시퀀스 다이어그램이 도출된 이후에야 "이 트래픽과 데이터 성격에는 RDB보다 DynamoDB가 맞겠다"는 식의 건설적인 기술 스택 논의(세부 사항 결정 지연)가 가능해집니다.
소리치는 아키텍처 (Screaming Architecture)
프로젝트 폴더를 열었을 때 Controller, Service, Repository가 보인다면 이는 프레임워크가 소리치는 것입니다. 잘 설계된 아키텍처는 Order, Payment, User 등 도메인(유스케이스)이 먼저 보여야 합니다. 이를 백엔드에서는 패키지(Package-by-Feature)로, 프론트엔드에서는 재렌더링 최적화를 고려한 컴포넌트 트리와 아토믹 디자인의 도메인 분리로 구현해 낼 수 있습니다.
3. 경계를 지키는 비용과 실무적 타협점
이론은 완벽하지만, 실무에 적용할 때는 비용이 발생합니다. 스터디에서는 한 가상의 개발자('김개발')의 여정을 통해 아키텍처의 진화와 딜레마를 짚어보았습니다.
1단계: 3-Tier Layered 아키텍처의 비극 서비스 계층에 절차적 로직이 집중되며(Transaction Script), 데이터는 그저 getter/setter 주머니로 전락합니다. 코드 오너십이 사라지고 사이드 이펙트 통제가 불가능해져, 코드 한 줄을 수정하기 위해 시스템의 80%를 읽어야 하는 상황이 발생합니다.
2단계: 도메인 모델(Domain Model)의 도입 상태 변경 로직을 도메인 객체 내부로 응집(캡슐화)시켜 서비스 계층을 얇게 만듭니다. 여기서부터 부수 효과가 차단되고 코드가 통제되기 시작합니다.
3단계: 헥사고날(클린) 아키텍처의 'DTO 폭발' 인바운드/아웃바운드 포트와 어댑터를 도입하여 계층을 완벽히 격리합니다. 하지만 이 과정에서 단순한 CRUD 하나를 구현하는 데에도 Request DTO, Command DTO, Entity, Response DTO 등 4개의 객체가 필요해지고, 경계를 넘을 때마다 무수한 매핑(Mapping) 코드를 작성해야 합니다.
딜레마와 대안: 경계를 완벽히 유지하는 것은 개발 속도를 늦추고 유지보수 비용을 급증시킵니다. 따라서 모든 곳에 헥사고날 아키텍처를 강제하기보다는, 복잡도가 낮은 영역에서는 의존성 역전을 일부 허용하는 릴랙스드 레이어드(Relaxed Layered)를 차용하거나, 스프링 모듈리스(Spring Modulith)를 활용해 물리적 서버 분리 없이 패키지 가시성(Visibility)과 애플리케이션 이벤트(Event)만으로 논리적 경계를 강제하는 실용적인 접근법이 훌륭한 대안으로 제시되었습니다.
4. 토론: 테스트 무용론, 그리고 인터페이스의 미래
발제 이후 이어진 자유 토론에서는 아키텍처를 둘러싼 조직 내의 인간적인 갈등과 산업의 미래에 대한 논의가 오갔습니다.
"테스트 코드는 굳이 왜 짜나요?" - 휴먼 엔지니어링으로서의 테스트
한 스터디원이 "테스트 코드는 비용 낭비이며 로직만 잘 돌면 된다"는 주장을 현업에서 마주했던 경험을 공유했습니다. 이를 계기로 이어진 논의에서 도출된 결론은, 테스트 코드는 단순히 '기능이 잘 도는가'를 확인하기 위한 장치가 아니라 '휴먼 엔지니어링'의 일환이라는 점이었습니다. 시스템이 커질수록 인간의 인지 능력만으로는 모든 사이드 이펙트를 예측할 수 없습니다. 테스트 코드는 미래의 나, 그리고 동료가 시스템을 변경할 때 기존 기능이 망가지지 않았음을 보장해 주는 최소한의 안전망이자 방파제입니다. 아키텍처의 경계를 강제하는 린트(Lint)나 ArchUnit 같은 도구 역시 인간의 실수를 시스템적으로 통제하기 위한 필수 장치입니다.
GUI의 쇠퇴와 LUI(Language User Interface)의 부상
클린 아키텍처가 UI를 세부 사항으로 취급했듯, 향후 소프트웨어 인터페이스의 패러다임 자체가 바뀔 것이라는 전망도 제기되었습니다. AI 에이전트와 LLM의 발달로 인해, 사용자가 직접 버튼을 누르고 화면을 탐색하는 GUI(Graphic User Interface) 시대에서, 자연어로 명령하면 시스템이 동적으로 UI와 결과를 생성해 주는 LUI(Language User Interface) 시대로 넘어가고 있습니다. 이는 프론트엔드와 디자인 직군에 거대한 변화를 예고하며, 앞으로의 아키텍처는 고정된 화면을 그리는 것보다 AI가 해석하고 조합할 수 있는 '순수한 도메인 API와 컨텍스트'를 제공하는 데 더욱 집중하게 될 것입니다.
마무리
"당신이 만드는 소프트웨어는 누군가에게 어떤 '선물(가치)'이 되고 있습니까?"
이번 스터디는 단순히 코드를 깔끔하게 짜는 법을 넘어, 아키텍처가 결국은 비즈니스 가치를 빠르고 안전하게 전달하기 위한 통제와 타협의 예술임을 다시 한번 논의하였습니다. 모든 시스템에 완벽한 아키텍처는 없습니다. 우리의 트래픽, 팀의 성숙도, 도메인의 복잡도에 맞춰 진화(Evolution)하는 구조를 그려나가는 것이 진정한 소프트웨어 엔지니어의 역할일 것입니다.
