인프런 커뮤니티 질문&답변

만들면서 배우는 클린 아키텍처 책에서 헥사고날 아키텍처에 대해서 어떻게 설명했는지와 상관없이, 책의 내용은 이야기해볼 좋은 주제를 많이 다루고 있습니다. 좀 더 깊이 생각해볼 거리도 많고요. 기회가 되면 온라인에서 이 책에 대해 깊이 이야기하는 시간을 준비해보겠습니다.

저는 이 책의 저자인 Tom Hombergs가 책이 나오기 전인 2019년에 Clean Architecture with Spring이라는 주제의 발표를 Spring I/O에서 처음 할 때 그 현장에 있었습니다. 저도 헥사고날, 포트/어댑터, 클린아키텍처 등에 관해서 전부터 많은 관심이 있었고, 특히 스프링 애플리케이션에 적용할 때의 실용적인 접근 방법에 대해서 많은 고민을 해오고 있었던 터라 당시 그 발표를 매우 흥미롭게 들었고, 이후에 원서가 나왔을 때 읽어봤고, 지인을 통해서 국내에 번역이 되는 과정을 모두 지켜보고, 이 책을 통해서 헥사고날 아키텍처에 대해서 많은 분들이 관심을 가지게 되는 것에 무척 기뻤습니다.

하지만 한편으로는 아쉬움도 많았습니다. 꽤 의견이 갈리는 여러가지 매핑 전략에 관해서 책에서는 이건 상황에 따른 선택이 필요하다고 이야기 했음에도 많은 분들이 책에서 소개한 대표적인 방법 한가지만이 정답이라는 식으로 받아들이는 것이 불편했습니다. 또 패키지 구조, 네이밍룰도 저자가 선택한 특정 방법일 뿐임에도 헥사고날 아키텍처는 책의 예제를 따라야 한다는 식의 이야기도 맘에 들지 않았습니다.

근본적으로 이 책은 원래 헥사고날 아키텍처가 소개됐을 때의 명확한 의도와 정의를 넘어서 이후에 등장한 헥사고날 아키텍처와는 분명히 구분되는 클린 아키텍처와 뭉뚱그려서 설명했습니다. 이게 용어나 아키텍처의 이해에 대해 여러 오해를 불러오기도 했다고 생각합니다. 책의 예제와 저자의 설명이 주는 여러 유익과 함께 너무 복잡한 구조의 헥사고날 + 클린 아키텍처가 미묘하게 짬뽕된 예제, 그리고 그걸 기계적으로 받아들이는 현상, 그 때문에 헥사고날 아키텍처는 다시는 안 쓰겠다는 적지 않은 개발팀의 불만 등을 지켜봤습니다.

이번 강의에서 제가 접근한 방법은 헥사고날 아키텍처를 적용하기 위해서 적용하는 것이 아니라, 도메인의 문제를 푸는 방법을 찾으면서 가장 단순하고 명확한 선택을 하는 과정에서 원래 헥사고날 아키텍처가 의도했던 것이 단순한 접근 방법이 잘 맞는다는 판단을 하는 과정을 보여드리고 싶었을 뿐입니다. 그리고 그 책을 중심으로 퍼져있는 헥사고날 아키텍처에 대한 오해에 대해서도 한번은 지적하고 싶었던 것이고요.

지름길이라는 것이 무슨 말씀인지 잘 모르겠습니다만, 제가 선택한 방법은 그 책에 소개된 방법중 하나를 고른게 아닙니다. 원래 헥사고날 아키텍처를 처음 창안하고 제안한 알리스타 코번의 글과 책을 통해서 선명하게 드러난 내용을 문제를 푸는 전략의 하나로 선택한 것입니다. 도대체 어떤 헥사고날 아키텍처에 대한 정도가 있길래 제가 선택한 방법이 지름길로 불리어야 하는지 이해할 수 없습니다.

그 책이 주는 많은 가치가 있고, 그 내용 중에서 현장의 문제를 푸는데 도움이 되는 것을 찾아서 선택하는 것은 개발팀의 자유입니다만, 그 책이 지지하는 모든 방식이 바로 헥사고날 아키텍처라고 말씀하시면 저는 전혀 동의할 수 없습니다.

여전히 저는 그 책을 좋아하고 예전부터 함께 일하는 개발팀에게 책을 읽고 그 중에서 프로젝트에 적용할 전략을 선택하라고 권장해왔습니다. 하지만 저자가 제시한 모든 방식이 최선이고, 그리고 그게 바로 "헥사고날 아키텍처"라고 한다면 그건 틀렸다고 말할 수 밖에 없습니다. 제목에서 조차 저자는 헥사고날 아키텍처는 클린 아키텍처가 아니라는 알리스타 코번의 이야기를 이해하지 못했다는게 분명히 드러나니까요. 제목 그대로 클린 아키텍처 책이라고 보시면 좋겠고, 거기 소개된 일부분은 헥사고날 아키텍처의 영감을 받았다 정도로 받아들이면 좋겠습니다. 클린 아키텍처 책에도 헥사고날 아키텍처에 대한 소개가 나오지만, 그 둘이 같은 거라고 설명하지는 않았고, 그래서 로버트 마틴은 클린 아키텍처라는 다른 이름의 자신이 주장하는 아키텍처를 명확히 불렀으니까요.

그 책의 주장에 대해서는 디테일을 가지고 하나씩 이야기해야 할 것이 많으므로 제 의견이 어떤지 지금 다 말씀드릴 수는 없습니다. 하지만 헥사고날 아키텍처에 관해서는 용어를 만든 사람이 설명하는 명확한 정의가 있으므로 여러 책의 저자마다 다른 설명을 하든, 개발자마다 다르게 이해하든 상관없이 용어를 만든 사람의 의견을 확인하고 존중하는 게 바람직하다고 생각합니다. 그 분이 쓴 책도 나와있으니 궁금하시면 참고하시면 좋겠습니다. https://www.amazon.com/Hexagonal-Architecture-Explained-Alistair-Cockburn/dp/173751978X/ref=tmm_pap_swatch_0?_encoding=UTF8&dib_tag=se&dib=eyJ2IjoiMSJ9.D-69ibClM5AAwwCo8nZnD33CYc92fxigRLaoxf9Od9_YSpDhEsy09fae1lYc9JJo7p-xQY1CCDLHJvFhjeyUClomLg3JU9TORa59hpjRq0Dhy-z81MFJkPMYml2eyBxDKtsPCM_sevkq26m5sRzl63vYVXWIBWXxjHRXHLoeH3cdaYormzsjOMRFTXZ4Fe214Fjan7Ey5nCuFPew3gKjZLquAVqOvg39Db8-8QbcuNjmUQDHiQWYew9YwVseSXa6WKkUIDI5h0qnDMsrKn4IM8JjbeQNX4WwS32hVFBDQaU.3e8SmCerUCTBIrQHEQonKcRijgnhIC-4BQTrN3yik6g&qid=1753277646&sr=8-1

안녕하세요, 인프런 AI 인턴입니다. dydalehdxo님께서 언급한 “만들면서 배우는 클린 아키텍처”와 토비님 강의의 차이점 및 헥사고날 아키텍처에 대한 관점에 대해 질문하셨네요.

클린 아키텍처와 헥사고날 아키텍처

토비님의 강의와 “만들면서 배우는 클린 아키텍처”는 결국 클린코드를 목표로 하며, 모듈성, 테스트 용이성, 유연한 설계를 지향합니다. 둘 다 지향점은 유사하지만, 구현 방법론에서 약간의 차이점이 있는 것은 사실입니다.

• 클린 아키텍처: 소프트웨어 설계에서의 독립성과 유연성을 강조합니다. 주로 함수형 인터페이스, 의존성 주입 등을 활용하여 코드의 변경에 민감하지 않도록 설계하는 것에 집중합니다.

• 헥사고날 아키텍처: 애플리케이션의 중심에 도메인 로직을 두고 외부 인터페이스로부터 격리하여, 여러 외부 요청과 경험한 사례들을 쉽게 대처할 수 있게 도와주는 마이크로서비스 구조의 하나입니다.

이 두 접근 모두 아키텍처의 유지보수성과 유연성을 높이는 훌륭한 방법론이지만, 특정 프로젝트의 요구사항, 팀의 성숙도, 그리고 비즈니스 필요에 따라 그 채택이 달라질 수 있습니다.

토비님의 관점

토비님은 “모든 이론에는 그에 맞는 적절한 시기와 상황이 있다”는 철학을 가지신 것 같습니다. 실제로, 헥사고날 아키텍처나 클린 아키텍처의 원칙이 모두 맞는 것은 아닙니다. 각 프로젝트의 배경과 목적에 따라 적절한 아키텍처를 선택하고 조율하는 것이 중요합니다.

이전에 비슷한 주제로 토비님께서 답변하신 내용이 있어 이를 추천드립니다:
- 토비님의 헥사고날 아키텍처에 대한 생각
- 클린 아키텍처와 기타 아키텍처 패턴에 대한 선택적 접근

저는 질문자님의 이해를 돕고자 이전에 관련된 답변 링크를 추천해드리고 있습니다. 이와 같은 유익한 토론과 질문을 이어가시면 많은 도움이 되실 것입니다.

현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.