헥사고날, 클린 아키텍쳐 등 으로 득을 보신 분이 계실까요..?

Question

안녕하세요. 어느 덧 6년차인 서버 개발자 입니다. 개인적인 고민이 들어서 주저리 주저리 휘갈겨봅니다 요즘 들어 개발자들 사이에서 로버트 마틴이 쏘아올린 큰 공에 대해서 배구도 하고 농구도 하는 것을 많이 보았습니다그래서 회사 내에서 여기 저기 팀에서도 너도 나도 도입하겠다고 하더군요저희 팀에서도 현재 도입을 해서 헥사고날로 코드가 짜여있는 상태이고, 실제로 완성해서 운영도 나가있는 상태입니다 다만 궁금한 것은 볼 때 마다, 짤 때 마다 과연 이게 맞는 것인가 라는 의문이 끊이질 않습니다 저와 저희 팀이 잘못 쓰고 있는 것 일수도 있지만변경 가능성이 보이지도 않을 정도로 작은 DB 변경에 대해서, 변경 될 수 있으니, 껍데기 뿐인 콘크리트와 1:1 인 인터페이스를 만들고그 인터페이스를 의존해라. 라던지.. (port) 그리고, 이렇게 인터페이스에 의존하면 콘크리트 클래스와 의존하는 것이 사라진다고 믿는 것도 사실 저는 동의하지 않습니다.. (손으로 하늘을 가리는 느낌이랄까요..)또한 성능과 편의성은 모두 제쳐두고, 불 필요한 DI와 DTO와 VO의 변환 작업 등... 성능이나 메모리 상에서는 비효율의 극치 같지만,사람들이 말하길 이렇게 하면 유지보수성과 테스트가 용이해진다고 합니다.. 마지막으로 가장 중요한 것인데.. 제가 득을 본적이 없어서 공감이 되지 않습니다도입을 해서 테스트가 용이해진 것을 모르겠고 (기존에 Transaction Script 구조의 테스트와 별 다를게 없어 보입니다) 2년동안 운영하면서 외부세계가 사실 바뀐 적이 없습니다. 그리고 추가가 있으면 추가가 있었지, 변경이 사실 있던 적도 없습니다그래서 인터페이스가 1:n 인 것은 하나도 없는 상태입니다.그래서 궁금한 부분은.여러분들도 똑같은 상황이지만, 나중에 분명 빛을 볼 날이 있을 것이다 라고 고수하시는지아니면 정말로 득이 되는 상황을 많이 보셨거나, 경험하셨는지 (서비스 특성상 저희 팀이 득을 못보는 것인지)선 후배님들의 생각이 궁금해지는 밤이네요..어떤 의견이라도 좋습니다. 긴 뻘 글 읽어주셔서 감사합니다.

oioioi · Answer

성능이나 메모리에 유의미한 영향을 줄지는 측정을 해봐야 알 수 있을 것 같구요.transaction script 구조에 비해 테스트는 확실히 쉬워졌어야 할 거 같아요.외부 세계가 안 바뀐 것에 대해서는 관점의 차이일 것 같은데요. 예를 들어 우리 서비스에 적합한 db를 찾자라는 목표가 있다면 헥사고날이 도움이 될 것이구요, 쓰던 것만 쓴다고 생각하면 별로 의미가 없겠죠

장독깨기 · Answer

ㅎㅎㅎ 당연히 드는 의문입니다. 실리가 있어야 하는데 그게 없는거죠.전 저런 거 일절 쓰지 않습니다.그래서, 제가 짠 소스 코드는 구조가 디게 간단해요. :)

카카오콘 · Answer

저는 까마득한 후배고, 그러다보니 백지를 채우기 위해 최근 화제인 &#34;클린코드&#34;, &#34;아키텍쳐&#34; 에 대해 깊게 고민해본 적 있습니다.(둘은 다르지만 편의상 이하 &#34;클린코드&#34; 로 통일하겠습니다. 제가 전하고자 하는 의도에서는 둘 다 맥락 상 동일하기 때문입니다.)그리고 제가 내린 결론은 이랬습니다.&#34;클린코드는 이상향에 불과하다.&#34;모든 클린코드를 소개하는 글은 그 클린코드의 효과가 극대화 되는 부분만 콕 집어 설명합니다.99가지의 잘못된 쓰임새 또는 적절하지 못한 형태의 구현이 강요되는 부분은 뒤로 한채, 단 한가지의 장점만을 끄집어내어(부작용을 동반하지만 그건 모르겠고) 이렇게 좋은 방법입니다.라고 소개하고 있다, 저는 그렇게 보고 있습니다.또한 그 클린코드를 사용한 전체 프로젝트를 소개한 글 역시 찾아보기 매우 힘듭니다.왜 일까 생각해보면, 그렇게 모든 상황이 딱 맞아 떨어지는 프로젝트는 세상에 존재하기 힘들기 때문입니다.만약 너도 나도 도입할 수 있고, 누구나 도입만 한다면 러닝커브가 있을지언정 100% 이득이 되었다면,그건 갑자기 떠오른 이슈가 아닌 이미 전세계에 보편적으로 적용되어 괜히 특별하게 여겨지고 언급 될 방법론이 아니었을겁니다.그러면 클린코드가 잘못되었다? 틀렸다? 그것 역시 당연히 아닙니다.모든 방법론에 있어 장점과 단점은 명확합니다.그렇기에, 그 장점과 단점의 트레이드 오프를 따져 적절하게 프로젝트에 적용하면 될 뿐 인거죠.이 방법을 사용해보세요! 당신은 깨끗한 코드를 구현한 아주 훌륭한 개발자 입니다!요약을 해보면 위의 문장처럼 가스라이팅 하는 듯한 내용에 진저리가 났고,그렇기에 클린코드에 대한 집착과 환상은 갖다 버렸습니다.

kiel · Answer

헥사고날 관련 책 중에 하나에 있던 내용인데, 규모에 따라 구조를 진화시켜야 한다는 내용입니다.무조건 이 구조 적용한다고 이득 보는건 아닙니다. Domain, DTO 분리하지 않으면 구조가 개판나기 시작하는 규모가 있습니다.. 그 정도 전에는 굳이 복잡한 구조를 가져갈 필요가 없죠. 그리고 사실 우리나라 대부분 서비스는 그 정도 규모까지 가지 않습니다.

집킨 · Answer

헥사고날의 핵심은 모든 계층에서 도메인 계층 방향으로 의존성을 갖게하자 입니다요구사항이(자의든 타의든) 자주 바뀌는 환경에선 헥사고날이 유효합니다아주 간단한 예로 검색 기능을 처음엔 일정과 리소스 문제로 DB에서 처리했다가 나중에 엘라스틱서치로 마이그레이션할 수 있는데 처음에 영속성 계층에 있는 모듈의 인터페이스를 도메인 계층에서 직접 썼다면 도메인 계층의 수정이 필요해지겠죠도메인 계층의 수정이 필요하다는건 테스트의 수정도 필요하다는 뜻입니다그래서 의존성을 port로 역전시킵니다그럼 영속성 계층에 어댑터가 추가되고 이 어댑터는 port를 구현하기만 하면 되는거죠이로써 어댑터를 자유롭게 바꿀수있게 되었습니다ㅎㅎ이제 고민이 하나 생기겠죠미래에 생길지도 모르는 변수들을 고려해서 처음부터 오버해서 헥사고날을 구현해야하나, 아니면 나중에 변수가 생길 확률이 올라가면 그때 수정해야하나..(오버라고 표현한건 헥사고날을 적용하기로 했으면 완벽하게 적용해야해서 입니다 어중간하게 하면 안하느니만 못하게 됩니다 그래서 archunit 을 꼭 쓰는걸 추천드려요)근데 아시다시피 정답은 없습니다..ㅎ중요한건 조직의 리소스와 동료의 상황에 맞는 아키텍처가 가장 좋은 아키텍처죠DDD를 모르고 MSA도 아니고 헥사고날을 잘 모르는 팀원이 대다수라면 안쓰는게 훨씬 좋은 방법입니다아마 그냥 좋다고 하니, 트랜드라고 하니 공부할겸 적용한 케이스가 더 많을거라고 봅니다ㅎ.. 이런건 필요에 의해 적용하는게 맞는데..ㅎ

kotliner · Answer

헥사고날은 유행했던 여러 디자인 패턴중의 하나일뿐입니다. 디자인패턴의 몰락이 시작된걸 보면 좋은 설계인것은 맞지만 불필요하고 과도한 설계로 인해 지나치게 추상화되어 오히려 이해가 어렵고 작성하기도 불편한 코드가 되어버렸죠.결국 중요한것은 정말 규모가 크고 자주 변경이 일어나는 프로젝트에서 헥사고날에서 좋은 패턴들을 적절하게 사용하는것이고 처음 프로젝트를 시작할때부터 특정 패턴을 가져가는것은 프로젝트에 불필요한 코드들과 복잡성만 불러일으킵니다.정말 대규모 프로젝트가 있다고 치더라도 그냥 모듈이나 서버 자체를 분리하면 깔끔한데 굳이 패턴에 집착할 필요가 하나도 없습니다. 특히 db를 쉽게 대체하는 것 자체가 말도 안되는 생각입니다.인터페이스는 의도를 드러내야하는데, 어떠한 db로 영속화하는지 모르고 쓰는건 성능이나 생명주기를 모르고 개발하겠다는 말도 안되는 소리입니다. redis에서 쓰던 로직들을 모두 그대로 rdb에 적용할 수 있을까요? 결국 개발자도 인터페이스에서 쓰이는 인프라를 모르고 개발하는건 말도 안되는 이상향입니다.결론을 말씀드리면 패턴보다는 좋은 코드를 위한 원칙들에 집중하시는게 맞습니다.

개발자이씨 · Answer

답글 달아주신 것 모두 정독하고 생각하면서 유심히 보았습니다역시 많은 생각을 하게 되네요 어느정도 궁금했던 내용도 해소가 되었고, 다들 비슷한 생각을 하고 있구나 라는 나름의 안도도 되네요다들 공통된 의견은, 자기 서비스에 맞는 아키텍쳐를 가져가야 한다는 부분인 것 같습니다 저 역시 동의하구요 ㅎㅎ 생각한 내용을 정리해서 팀원들께 공유하는 자리를 한 번 가지면 좋을 것 같네요

초무쿤 · Answer

유행은 이름만 바껴서 돌고 도는듯 하네요. (물론 조금의 양념들이 쳐지긴 합니다만..)

캐티 · Answer

완벽하게 이해한 것이 아니라면 건드리지 않는 것이 좋아요.안이 .. 완벽하게 이해 했더라도 각오를 한 다음 건드리는 것이 좋다고 보아요.지구 끝까지 따라가며 중간에 포기 하지 않는 것 말이어요.

셀립 · Answer

소잡는 칼로 닭 잡으면 좀 허무할 수 있겠지요. 다만 1. 훗날에 제대로 써먹을 수 있으니까 (모르는 것 보다는 알면 선택지가 넓어진다) 2. 구루들의 생각을 쫒아가면 그것 자체로도 의미가 있으며 배울게 있다. 3. 재미로 이 정도 생각하면 될 거 같습니다. 지나치게 오버엔지니어링을 경계하면 단순한(수준낮은) 사고관에서 벗어나기 힘들어 집니다. 추가적으로 DDD나 헥사고널 아키텍쳐를 그냥 기계적으로 하지 마시고, 웹백엔드 개발에 객체지향적,함수지향적 코드가 어떻게 적용되는지를 고민을 좀 해보면 재밌을 거 같습니다. 어차피 데이터베이스로 CRUD 일뿐 이라는 마인드를 갖는 것과는 다른 시각을 갖게 해 줄 것이니까요.

빙수빙수 · Answer

di를 안쓰면 유닛테스트를 어떻게 하나요? (Transaction Script 구조의 테스트란걸 첨들어보는데 어떤식의 테스트인가요?)

InTheFlow · Answer

일리가 있는 말입니다. 개인적으로는 매우 크고 복잡한 프로젝트에 한해서 적합한 것 같습니다.

훈마로 · Answer

개발하다보면 항상 느끼는 거지만 은탄환은 없습니다작성자분이나 댓글 작성하신 분들 모두 각자가 처한 상황에 맞춰 최선의 선택을 하기를 바랄 뿐입니다.최선의 선택은, 하고 있는 비즈니스의 가치를 창출하기 위한 목적으로 리소스를 고려하여 기술을 선택하는 거지요기술이다보니 리소스 고려는 당연 휴먼 리소스에 대한 고려가 제일 크고요특정 기술을 도입하기 위한 학습부터 유지보수성, 확장성까지 다 고려를 해야하는 것을 말합니다.여기서, 특정 아키텍쳐나 패턴을 적용하는 것에서 결국 우리 팀원들이 당장 충분히 할 수 있는 것인지, 학습이 좀 필요한지, 도입 했을 때 유지보수성, 확장성이 올라가는지, 생산성이 있는지, 확장성은 현재 시점에 어느 정도 고려해야하는지 등을 판단해야겠죠.제 사례를 들어보면,저는 현재 다니고 있는 회사에 입사했을 때 일반적인 HTTP API, Spring MVC 기반 코드였습니다.JSP 구조이고 B2B 서비스이다보니 트래픽이 많지는 않습니다.트랜잭션 스크립트 방식이라 서비스 코드가 비대해져있고, 컨트롤러와 서비스에 로직이 파편화 되어있고, 도메인은 단순히 VO/DTO 역할을 하는 늒미이였죠.5년된 오래된 코드이지만 나름 시장에서 비즈니스 가치를 창출하고 있는 소중한 코드이기도 합니다.제가 들어온 시점에 스타트업이 흔히 겪는(?) 개발자 물갈이가 되는 상황이었고, 저 포함 완전 새로운 사람들이 인수인계나 정책 문서도 없이 서비스를 성장시켜야 하는 책임을 가지게 되었죠.실제로 조직적으로 마케팅과 영업 인력을 확충해서 사업을 확장하고 있었고, 그에 따른 각종 자잘한 버그, 유지보수 문제, 새로운 기능 개선시 레거시 코드로 인한 발목 잡힘, 인프라 문제 등 다양한 문제들이 산발적으로 터져나왔습니다.그 때 택한게 헥사고날 아키텍쳐였는데요. 이 아키텍쳐 덕에 많은 도움을 받았습니다.물론 이 아키텍쳐가 아닌 클린 아키텍쳐, 오니언 아키텍쳐 등.. 다양한 아키텍쳐가 있는데요. 저는 다음과 같은 이득을 봤습니다.도메인 중심 OOP를 통한 코드 응집도를 높이고 도메인간 결합도를 낮춰 유지보수성을 높이는 것 (핵심 로직에만 집중, 특정 도메인 로직에 대한 변경이 다른 로직으로 전파 되지 않음 = 변경에 대한 격리)인프라 레이어의 구현을 DIP 적용하여 도메인에서는 인터페이스를 통해 소통레거시 로직에서 max+1로 PK를 잡는 로직이 있었음 -> 동시성 이슈 발생이를 redis를 통해서 해결하는 과정에서 getMaxNo 와 같은 함수를 인터페이스로 빼놓고 구현체를 DB가 아닌 Redis로 변경하는 과정에서 도메인 로직에 영향이 없어짐컨트롤러 / 애플케이션 / 도메인 로직을 분리하여 레이어별 역할을 명확히함단위 테스트 작성이 쉬워짐통합 테스트 작성시 외부 연동이 필요한 곳에서 모킹이 쉬워짐사실 아키텍쳐라고 해서 뭐 대단한건 아니고, 그냥 패키지 구조 잘 짜고 그에 맞는 컨벤션 만들어서 가이드하고코드 리뷰 과정에서 지속적으로 합을 맞추면 어렵지 않게 됩니다.특별한 기술이나 알고리즘이 전혀 필요한 것도 아니고요.근데 이 간단한 것을 도입함으로 인해 그 이득은 크더라고요물론 앞서 말씀드린 것처럼 은탄환은 없습니다. 또, 항상 기술에는 트레이드 오프가 있고요.고민하셨던 것처럼 정말 단순한 로직인데도 이 아키텍쳐를 따르려면 필요한 클래스 수가 늘어나는 것은 어쩔 수 없습니다.그리고 정말 이 만든 로직이 나중에 변경될까? DB가 갑자기 오라클에서 몽고디비로 바뀔까? 이를 위해 인터페이스로 빼두는게 좋은가? 이런 고민들이 들기도 하죠하지만 막상 그러한 상황이 닥쳤을 때 후회가 될 수도 있어요.실제로 저희 회사 다른 서비스 팀에서는 DB를 여러번 바꾸기도 했습니다.그럼 인터페이스 하나 빼놓고 시작하고, 패키지 구조 맞추고 개발하는게 그렇게 어려운 일인가? 하고 반문해봤을 때 드는 느낌을 가지고 하시면 될 것 같습니다.근데 회사가 특정 기술에 종속되어서 바꿀 확률이 1% 이하이라면 좀 더 단순한 형태로 가도 무방하겠죠!결국 케바케입니다! 본인이 속한 조직의 비즈니스와 기술적 상황을 충분히 검토하셔서 적절히 선택하시면 될거에요그리고 한번에 바꾸면 어려우니 하나씩 시범적으로 해보고 같이 동료들과 결과에 대해 이야기 주고받으면서 적용하면 좋습니다!

캐츠비 · Answer

자기 서비스에 맞는 아키텍처를 잘 선택하는게 중요한 것 같다는점과, 아키텍처를 서비스 트래픽이나 미래 예측에따라 전환타이밍을 잘 잡고 빠르게 결정하는게 중요하다는게 요즘 제 결론입니다. 저는 반대로 이직한 현 회사에서 맡게된 솔루션이 8년~9년정도 된 레거시 스프링 프로젝트인데, 초창기 모두 트랜잭션 스크립트 패턴과 모놀리틱 아키텍처 + 테스트 코드의 부재등의 이유로 유지보수가 너무 힘든 상황이거든요 ㅠㅠ.. 헥사고날 아키텍처 아니면 msa기반의 클린 아키텍처라도 도입하고싶다는 생각이 가득이며, 계속해서 기능단위로 쪼개서 모듈로 분리하면서 최신화 하려고 시도하고있네요..

헥사고날, 클린 아키텍쳐 등 으로 득을 보신 분이 계실까요..?

14개의 답변

Q&A 목록