영상 내용에 100%동감합니다. 저는 작은 개발팀 테크리드를 하고있는데요 결론적으로 저는 헥사고날을 선택했습니다. 처음 합류했을때 Controller-service-repository 의 전형적인 구조였는데, Service 계층이 엄청 비대해진 상태였고, 그런 상태가 고착화된 상태였습니다. 이러한 형태를 개선하는 과정에서 헥사고날이 큰 도움이 되었습니다. 주니어들이 port를 정의하고 adapter를 구현하면서 외부(통신, db 등등)와 비즈니스를 격리시키는 방법을 배우고, db entity 모델과 실제 도메인모델을 분리시키는 과정에서 도메인정의도 어느정도 해내게 되더라구요. 의도적으로 격리해서 생각하게끔 강제시킴으로써 헥사고날의 도움을 많이 받은 케이스였습니다. 다음에는 어떻게 설명해야 Layered 로 저런 개념들을 설명할 수 있을지 고민을 해봐야겠다고 생각이 들었네요. 잘봤습니다
점진적 접근으론 도메인 모듈만 추출했어도 어느정도 이점을 볼 수 있었을 거로 어느정도 호전이 있을 것 같다고 생각은 되긴하네요! 그치만 저도 상황을 정확히 아는 것은 아니다 보니 섣부른 판단일 것 같고, 말씀해주신 문제를 해결하기 위해서 조치하신 거라면 충분히 타당하다고 느껴지기도 합니다🙂 효과를 보시고 개선 되셨다니 다행이고, 말씀하신 것 처럼 다른 문제해결 루트도 생각해보셔도 좋을 것 같습니다! 공감 감사드리고, 봐주셔서 감사합니다!
지금 개인 토이 프로젝트를 백엔드 3명이서 진행 중이에요. 다들 약 2개월 정도 예상하면서 시작했는데, 개발 시작 직전에 헥사고날을 결정 해버린 결과 7개월 째 개발중입니다.. 스스로 헥사고날형에 처하는 여러분이 되지 않기를.. 근데 또 한 번 해보니까 좋은점이 뭔지는 알겠고, 왜 안해야 하는지를 몸소 알겠다는 점은 있네요
공감합니다. 저는 긍정적인 부분은 토이프로젝트로 하셨다는 점 같습니다. 만약 어떤 회사의 실무 프로젝트였다면, 그 결과물에 대한 유산은 상당한 피해가 될 수 있다고 보여집니다. 오히려 토이프로젝트를 통해서 장/단점을 느끼셨다니 시간을 낭비한 부분은 있으시겠지만 긍적적으로 보입니다. :D 또 하나 흥미롭게 해보실만한 부분은 헥사고날을 직관적 아키텍처로 해체하는 작업을 날 잡아서 한번 해보시면 생각보다 빠르게 가능하고, 결과물에 대해서도 꽤나 흥미로운 감상+경험이 되실 것 같습니다.
영상 잘 봤습니다. 🙏 소프트웨어의 본질이 중요하다고 생각해요. 소프트웨어는 결국 문제를 풀기 위함이고, 그러기 위해 문제 영역 즉, 도메인을 잘 이해하고 정의하는 것이 중요하다고 생각합니다. 도메인을 코드로 잘 표현하고 잘 테스트하기 위해 헥사고날이든 어니언이든 디자인 패턴이나 아키텍처 패턴을 이용하는 것이죠. 그런데 주객이 전도되는 경우를 많이 보게 되는 것 같네요. 그런 의미에서 이런 영상을 만드셨다고 이해가 되구요.
저도 헥사고날 처음 들었을때 한번 찍먹해보고 어휴 왜이리 복잡해지나? 하고 때려쳤습니다. 서비스 레이어에 CRUD하는 코드를 C,R,U,D 4개 클래스로 쪼개고, 앞단에 인터페이스까지 만들어서, 1개짜리 서비스 클래스가 8개 파일(인터페이스4개 클래스4개)가 되더군요. 거기에 더해지는 인터페이스 어답터들과 패키지까지 하면, 엄청 볼륨이 커지기도 하고, 코드 읽을 때도, 뭐 하나 보려면 타고 타고 넘어가는걸 여러번 해야해서 번거롭더군요. (이해수준이 낮아서 틀린 얘기일 수도 있겠습니다) 그런데 시간이 지나서 클린코드를 어떻게 해야하나 고민할 때가 되니, 어쩌면 헥사고날 아키텍처가 클린코드를 프레임워크처럼 강제하는 패턴이 아닐까? 라는 생각이 들었습니다. 클린코드라는게 1. 이 코드를 처음보는 타인이 이해하기 쉽고, 변경하기 쉽게 짜야한다. 2. 디버깅 때, 이 부분을 고치면 다른 연관없는 부분이 깨지지 않도록 모듈화 해놔야 한다. 3. 확장 가능해야 한다. 4. 변경하기 쉬워야 한다. 큰 개념은 이런 것들에, 세부 규칙들(ex. 변수/함수/클래스 네이밍 컨벤션 등) 까지를 클린코드라고 정의를 한다면, 기존에는 프로젝트 시작전에 프로젝트 리더가 하나하나 세부 규칙을 정해서 인지 시키고, 팀원 각자가 개발을 시작해도, 개개인이 세부 규칙을 미스할 수도 있고, 각자의 코드 잘짜는 것에 대한 스킬 성숙도, 클린코드에 대한 이해도 등이 다 다르고, 각자 몸에 벤 코드 스타일이 다 다를텐데, 이런 것들을 모든 팀원들이 통일하면서 1~4까지 큰 개념을 지키기가 사실상 어려우니까, 헥사고날 아키텍처를 도입하면, 생소할 때 조금 헤메도 한번 익숙해지기만 하면 코드 스타일도 통일되고, 모듈화도 자연스럽게 되고, 위에 1~4까지 큰 개념들이 자연스럽게 헥사고날을 아키텍처에 녹아져있지 않나? 라는 생각이 드네요. (물론 여러 개발자들이 협업하는 어느정도 규모가 큰 프로젝트에 한에서 입니다. 작은 프로젝트에서 헥사고날은 오히려 복잡도만 증가해서 득보다는 실이 큰 느낌인 듯 합니다.) 저는 이런 이유 때문에 클린코드를 하기 위해서 헥사고날 아키텍처를 쓰는게 좋지 않을까? 라는 생각을 요즘 하고 있는데, 제미니님의 의견이 궁금합니다.
약간 드루뭉술하게 쓴것 같아, 예시를 하나 붙이자면, 기존 controller-service-repository 구조에서는 CRUD와 비즈니스 로직을 서비스 클래스 하나에 모조리 담아놓고, 여러 다른 클래스들에서 다양한 경로로 참조해서 쓰기 때문에, 해당 서비스 클래스의 함수를 변경하면, 그 클래스를 참조하는 온갖 클래스들을 모두 고려해야 한다면, 헥사고날 아키텍처를 써서 CRUD를 C,R,U,D 4개의 클래스로 모듈화해서 구현되어있다고 했을 때, Update 관련 코드를 수정해야 한다고 하면, 서비스 레이어 전체가 아니라, Update 클래스를 참조하는 파일로 범위를 좁힐 수 있기 때문에, 유지보수 측면에서 유리하지 않을까? 라는 생각이 드네요.
'클린코드'를 한다는 것 자체가 의미가 있을지를 먼저 생각해 보시면 좋을 것 같습니다. 비단 '클린 코드' 외에도 '클린**' 이런 것들이 정말 유의미한지에 대해서도 생각해 보시면 좋을 것 같습니다. 우리가 해야 하는 건 문제 상황에 대하여 가장 적절한 수준의 조치를 하는 것입니다. 그 외에는 모두 의미가 없습니다. 대부분 패턴이 '닭 잡는데 소 잡는 칼을 쓰는 형태'가 99% 같긴 합니다. 만약 팀 수준이 모든 걸 강제해야 할 정도고, 어떤 수준의 문제를 코드 리뷰로써도 해결 못한다면 그 팀은 일단 다른 관점에서 문제가 있다고 생각되긴 합니다. 적어주신 1~4는 클린코드/헥사고 날을 하지 않아도 충분히 달성할 수 있는 것들이라고 생각합니다. 오히려 클린코드/헥사고 날 한다고 구성해놓고 1~4를 다 못 달성하는 경우도 많이 본 것 같고요. 제 의견을 물어보셨으니 '클린 코드를 하기 위해서 헥사고날 아키텍처를 쓰는 게 좋지 않을까?'라고 생각하신다면 저는 아니라고 생각하고 전제 자체가 잘못됐다고 생각합니다. 주객이 전도된 느낌이 듭니다, '지금 있는 문제를 풀기 위해서 최소한으로 조치해야 하는 건 무엇일까?'를 생각하시면 좋을 것 같습니다.
"""CRUD를 C,R,U,D 4개의 클래스로 모듈화해서 구현되어있다고 했을 때, Update 관련 코드를 수정해야 한다고 하면, 서비스 레이어 전체가 아니라, Update 클래스를 참조하는 파일로 범위를 좁힐 수 있기 때문에""" 이 문제를 헥사고날을 안 쓰고 해결을 못하는 걸까요? 한번 생각 또는 코딩해 보시면 좋을 것 같습니다.
@@geminikims """CRUD를 C,R,U,D 4개의 클래스로 모듈화해서 구현되어있다고 했을 때, Update 관련 코드를 수정해야 한다고 하면, 서비스 레이어 전체가 아니라, Update 클래스를 참조하는 파일로 범위를 좁힐 수 있기 때문에""" 헥사고날을 안쓰고도 해결할 수 있을 것 같네요. 예를들어 CRUD를 하는 서비스 레이어가 좀 커진다 싶으면 read랑 write 두개로 쪼갠다거나 하는 식으로요. 그렇게 read/write 쪼개고도 write가 너무 비대해지면, read/write/update/delete로 쪼갤 수 있겠네요. 그런데 질문의 요지는 약간 이쪽에 더 가까웠습니다. '복잡도가 높아져서 쪼개야 하는 시점이 오기 전에, 미리 쪼개놨었으면, 쪼개야하는 시점이 왔을 때 드는 수고를 미리 덜어둔게 아닐까?' 만약에 회사단위에서 여러명이 작업하는 규모가 좀 되는 프로젝트에서, phase1이 서비스 레이어에 CRUD가 모두 있고, phase2가 read/write 둘로 쪼갠거고, phase3이 C/R/U/D 4개로 쪼갠거라고 했을 때, 어짜피 phase3 갈꺼면, 처음부터 쪼갠다음에 시작하는게 낫지 않을까? 라는 생각입니다. 예를들어 phase1로 가다가 기능추가를 했는데, 해당 클래스를 참조하던 다른 예상못한 곳에서 에러가 난 상황을 가정합니다. 이 서비스 클래스를 온갖곳에서 참조했기 때문에, 여기가 문젠가? 저기가 문젠가? 삽질하는 기간이 길어지고, 슬슬 쪼갤 필요성을 느껴서 phase2(read/write) 단계로 갔다고 합시다. phase2로 바꾸고, 몇달 뒤에 비슷한 상황이 반복되어, 음... 좀 더 쪼개야겠는데요? 하면서 phase3로 더 쪼갠다고 했을 때, 애초부터 phase3으로 쪼개면서 짰으면, 전환기의 스트레스/비용/삽질을 좀 덜 할 수 있지 않을까? 라는 궁금증이 드네요. 아니면 이게 흔히들 말하는 섵부른 최적화의 예시일 수 있겠네요. 경험없는 추측일 뿐인지라 실제 경험이 풍부하신 제미니님의 의견이 더 진실과 가까울거라 믿습니다. 시간내주셔서 답글 달아주셔서 감사합니다.
영상 잘 봤습니다. 저는 테스트코드를 처음 접했을 때, 단순히 mock 객체를 stub하는 행위가 반복되는코드가 짜지는 것 같아서 고민이었는데요. 그 때 찾아본 테스트강의가 레이어드 아키텍처를 개선해 나가면서 문제점을 해결하는 식의 내용이었습니다. (이것이 헥사고날인게 오늘 알았지만요) 동시에 도메인 엔티티랑 영속성 엔티티를 분리하는 것도 알게 되었습니다. 그래서 그런지 계층구조의 추상화 의존이나 도메인,jpa 엔티티 분리하는거나 이런 흐름이 크게 다르지 않다고 느꼈습니다. 또한, 이런 지향점들에 좀 크게 공감이 갔습니다. 실제로 테스트 하는 방법과 의의를 알게되었고, 서비스 계층에 대부분 로직이 들어있었던 예전 제 코드에 비해서는 개인적으로 이해하기 쉽고 깔끔하게 바뀌었다고 생각합니다. 아직 혼자서 공부하는 단계라 복잡성 같은거는 크게 와닿지가 않아서 헷갈리네요. 대부분 회사에서 이를 부정적으로 보는 편인가요?
회사가 부정적으로 보냐?에 대해선 결국 케바케입니다. 적절한 상황에 적절한 아키텍처 선택이 아니면 당연히 부정적으로 보입니다. 말씀해 주신 내용들이 꼭 헥사고날을 선택해야지만 얻을 수 있는 것은 아닙니다, 도메인 모듈만 분리한다던가 중간 과정의 형태에서도 어느 정도의 이점을 얻을 수 있습니다. 학습하시는 단계라면 두 개의 아키텍처에서 같은 문제를 어떻게 해결할 수 있는지 / 그리고 어디까지 효율을 얻을 수 있는지에 대해서 고민해 보시면 좋을 것 같습니다. 이미 아실 거라 믿지만 '모든 상황에서 모든 문제를 해결할 수 있는 마스터 피스는 이 세상에 없습니다.' 결국 회사에서 긍정적으로 보는 것은 '적합한 상황에 적합한 조치' 를 취할 수 있는가 없는가 같습니다. 예술을 하려고 모인 게 아니니까요. 단편적으로 '테스트 와 도메인 분리' 때문에 헥사고날을 썼다 하면 저는 과하다고 느껴지긴 할 것 같습니다.
그런 이유라해도 헥사고날이 제일 좋다고 보진 않습니다. 또한 헥사고날 자체가 유지보수가 쉬워진다고 주장하지만 그 만큼 복잡도를 수반하기 때문에 모순적인 말이라고 생각 하기도 합니다. 결국 상황에 맞게 적절한 선택이 필요하다고 봐야합니다. '헥사고날 하면 유지보수가 원할하다' 라고 말하면서 적절하게 쓰는 곳을 본적이 없습니다. -- 가장 유지보수 하기 쉬운 결과물은 '코드 자체가 적고, 가장 단순한 구조' 를 유지한 형태 입니다. 다만 비즈니스나 시스템이 커짐에 따라 확장이 일어나야하는데, 쿠폰 서비스가 그만한 크기가 되지도 않았는데 유지보수를 위해 헥사고날을 쓴다라면, 필수 존재 코드 보다 '구조를 위한 코드 구조를 위한 구조' 만 남게 됩니다. 유지보수가 원할하다는 말 자체가 상황과 규모를 이해하지 못한 형태라면 반박할 가치가 없다고 생각합니다
개발 공부를 하다가 궁금한 점이 생겨서 질문 남깁니다 로컬환경은 별다른 설정 없이(DBMS 설치 등) 코드를 받은 즉시 실행할 수 있으면 좋다고 생각하는데요. 만약 프로젝트에서 MySQL, Redis를 사용했다면 이를 H2, Embedded Redis로 대체할 수 있을 것 같은데 이에 대해 어떻게 생각하시는지 궁금합니다! 항상 도움 되는 영상 제공해 주셔서 감사합니다!
좋은 영상 감사합니다! 혹시 재민님은 실무에서 레이어드나 헥사고날 이외의 아키텍처로 웹 프로젝트 해보신적 있으신가요?? 지금까지 제가 겪었던 웹 플젝은 모두 레이어드 였던것 같은데, 개인적으로 일반적인 웹 서비스 구조(클라이언트-애플리케이션-DB)를 생각하면 적절하다고 생각은 했지만 이거말고는 없을까? 하는 생각이 종종 들었던 것 같아 단순한 궁금증에 여쭤봅니다!
저 두 개의 아키텍처를 제외하더라도 도메인 모듈만 나와있다던가 등의 두 개의 중간 형태의 모습으로 프로젝트를 진행하는 경우는 있는 것 같습니다. 큰 그림에서는 저 두 개의 아키텍처도 비슷한 면이 있는 것 같아요. 대부분 웹 프로젝트 성향상 큰 틀에서 벗어나지는 않는 것 같습니다.
