[Spring Boot] 헥사고날 아키텍처에 관한 고찰

이 내용은 소규모 프로젝트를 개발하며 느꼈던 아키텍처에 대한 저의 생각입니다. 여러 선택을 번복하며 느낀 점을 기록하고자 작성하였습니다.

 

저는 학교에서 사용하는 출석 서비스를 개발하는 동아리에 가입했고, 2024년 말부터 개발에 참여할 수 있었습니다. 처음 개발에 투입돼어 온보딩할 때 프로젝트 구조는 UseCase를 중심으로 개발된 '클린 아키텍처'에 가까웠습니다. 그리고 백엔드 개발을 주도하며, 이 코드가 UseCase와 Service의 불명확한 책임 분리, 도메인 로직의 비독립성이 문제가 된다고 느꼈습니다.

 

바꾸는 김에 완벽하게 해보자

그렇게 저는 2개월이라는 시간동안 팀원들과 헥사고날 아키텍처로 리팩토링하였습니다. 그 당시에는 자주 변경되는 요구사항에 빠르게 대응하기 위한 아키텍처라고 생각했고 적용해보고자 팀원들을 설득하였습니다.

 

그럼 이제부터 문제를 서술하겠습니다.

실제로 도메인 로직과 기술의 분리는 성공적이였습니다.

 

그럼 무엇이 문제였나? ->

비지니스 로직 인터페이스를 설계하고 구현하지 않는 실수가 반복되었습니다.  비슷한 로직을 두번이나 구현해야하다보니까 시간이 오래 걸렸고 비효율적이였습니다. 

이건 진짜 부끄러운 실수이긴한데 JPA의 더티 체킹 기능을 자주 이용하던 저인데, 서비스 코드에서 @Transactional 달아놓고 save() 메서드를 호출을 하는 걸 안 해서 여러 번 문제가 생겼습니다.....ㅎ.. (DB 독립적이라 기능 작동 안 함)

 

기능 수정 한 번에도 adapter까지 두 번 바꿔야하는 1+1이벤트 같았습니다. 정말 대규모 프로젝트에선 이 구조가 어떤식으로 도움이 될진 모르겠으나, 빠르게 개발해야하는 학생들에게는 독약같았습니다.

 

그리고는 레이어드 아키텍처로 다시 돌아왔습니다. 팀원 모두가 편하게 빨리 개발할 수 있는 구조로 말이죠. 실제로 이렇게 변경하는데에 하루밖에 안 걸렸습니다. 그리고 그 이후의 기능 수정은 더욱 빠르게 이루어졌고요.

 

느낀 점

이번 계기를 통해서 이론적인 사실들이 모두 맞는게 아니라는 사실을 깨달았습니다. 나의 상황과 팀의 상황 모두를 고려한 선택을 해야한다는 것을 체감했습니다. 다음부턴 이론적인 면보다 실제 상황에 합리적인 기술 선택을 할 것이라고 다짐했습니다.