<div id="readability-page-1" class="page"><article>
    

<p><a href="/archivers/summarize-hexagonal-architecture">Hexagonal Architecture 정리</a> 이 후, 실제 Hexagonal Architecture(이하 육각형 아키텍처)를 적용하여 프로젝트를 수행하며 배우고 느꼈던 점, 성과와 실패를 정리해 본다.</p>

<h2 id="주의">주의</h2>

<p>어떤 기술이나 도구든 팀과 조직의 역량, 그리고 프로젝트 일정과 성향에 따라서 적합한지 확인해야 한다. 이 글은 개인의 경험에 기반한 내용일 뿐 육각형 아키텍처의 객관적 지표가 아님을 분명히 한다. 개인의 역량 부족, 잘못된 활용, 프로젝트 상황 및 다른 기술 스택의 영향 등이 있을 수 있다. 또한, 여기서 작성된 장단점은 육각형 아키텍처”만” 가진 특징이 아님을 짚고 넘어간다.</p>

<p>해당 프로젝트는 계속 진행 중(2023년 11월 기준)이므로 향후 의견이 추가되거나 바뀔 수 있다.</p>

<blockquote>
  <p>도메인 로직, 비즈니스 로직 - 육각형 아키텍처에서는 도메인 계층이 존재한다. 여기에 구현되어야 하는 로직, 결국 가치를 일으키는(돈을 벌어다 주는) 로직에 대해서 비즈니스 로직으로 통칭한다.</p>

</blockquote>

<h2 id="좋았던-점">좋았던 점</h2>

<ul>
  <li>의존성으로부터의 독립 그리고 테스트
    <ul>
      <li>육각형 아키텍처를 유지하기 위해 의식적으로 의존성 분리, 가급적 서버 컨테이너 설정도 분리하려고 노력함</li>
      <li>의존성이 분리되니 테스트가 너무 간편해짐 - 인터페이스는 mocking 하고 요청과 그 결과를 검증하는 반복적인 단계</li>
      <li>테스트가 쉬우니 테스트 코드 작성도 빨라지고 많아짐, TDD 적용 가능</li>
    </ul>
  </li>
  <li>프로젝트의 모듈화
    <ul>
      <li>프로젝트의 각 계층을 모듈로 분리할 수 있음, 즉, 모듈별로 업무를 나누어 R&amp;R 관리 쉬움</li>
      <li>기능 또는 업무를 잘게 쪼갤 수 있음 - 빠른 커밋과 피드백 가능</li>
    </ul>
  </li>
  <li>비즈니스 로직에 집중
    <ul>
      <li>도메인 계층은 비즈니스만 고민 - 기획자와 함께 고민 가능(DDD…)</li>
      <li>코드 구조나 라이브러리, 리소스를 어떻게 쓸지 고민하기 보다 요구사항을 어떻게 구현할지에 대해 집중</li>
    </ul>
  </li>
  <li>외부 서비스와 연계를 최대한 지연시킬 수 있음
    <ul>
      <li>연동해야 할 외부 서비스가 아직 준비되지 않았다면 이 부분을 dummy 로 대체하여 우리 비즈니스 로직부터 개발할 수 있음, 느슨한 연결</li>
      <li>나중에 외부 서비스가 준비되면(또는 변경되면) 연동 부분에서만 대응하면 됨</li>
    </ul>
  </li>
  <li>완성되어 가면서 느끼는 안정감
    <ul>
      <li>지극히 단순한 구조 유지 가능, 복잡한 부분도 결국은 모듈 단위로 추상화되어 격리됨</li>
      <li>그냥 만들었다면 기능에 따라 각기 다른 구조(structure)가 나오거나 변경될 수 있지만, 육각형 아키텍처의 철학에 맞추면서 지속해서 단순하고 일관된 구조를 지향하게 됨</li>
      <li>테스트가 많이 만들어져 신뢰감 생성</li>
    </ul>
  </li>
  <li>나쁘지 않은 구조를 강제
    <ul>
      <li>육각형 아키텍처보다 효율적인 구조였지만, 라이프사이클이 진행되며 점점 나빠지다 최악으로 빠지는 것을 사전 차단</li>
      <li>구조를 유지할 아키텍처의 기준이 없으면 그때그때 필요한 모양으로 변하고 차후에는 일관성 없고 가독성이 떨어지는 구조로 변하게 되어 기술 부채가 되어버림, 특히, 외부 연동 또는 DB entity 에 의해 비즈니스 로직이 흔들려 버릴 수 있음</li>
      <li>여러 기능을 구현하더라도 일정한 틀을 유지해 주므로 시간이 흐르더라도 깨끗한 구조가 유지될 가능성이 높음</li>
    </ul>
  </li>
</ul>

<h2 id="나빴던-점">나빴던 점</h2>

<ul>
  <li>불안하고 (심리적으로) 어려움
    <ul>
      <li>왜 해야 하냐에 대한 물음에 대쪽과 같이 응대할 수 없음 - 이론적으로는 말할 수 있겠지만, 주변에 활용 사례와 레퍼런스를 찾기 어려움(아키텍처의 대중화 필요?)</li>
      <li>스스로도 할 수 없을 것 같은, 괜히 한 것 같은 의구심이 끊이지 않음</li>
      <li>하고 나서도 뭔가 찜찜함 - 성공 사례와 비교할 수 없음</li>
      <li>상급자와 동료들의 지지가 필요함</li>
    </ul>
  </li>
  <li>프레임워크로부터의 완벽한 독립은 어렵거나 불가능
    <ul>
      <li>비즈니스 로직과 무관하지만 비즈니스 로직에 포함되어야 하는 애매한 데이터들(예를 들면 tracking id 등)을 어떻게 처리할지 의사결정 필요</li>
      <li>트랜잭션이나 컨텍스트 데이터 처리는 프레임워크를 활용할 수 밖에 없음 - 비즈니스 로직에 집중하려던 철학에 금이 가기 시작</li>
    </ul>
  </li>
  <li>비즈니스 로직 분리나 성능 개선 지점의 모호함으로 고민거리가 많아짐
    <ul>
      <li>추상화된 인터페이스의 구현체는 비즈니스 로직에서 최적화를 할 수 없음</li>
      <li>예를 들어 데이터의 종류에 따라 세밀한 처리가 필요할 때, 인터페이스를 성능적으로 세분화하는 것과 논리적으로 추상화 할지에 대한 의사결정 필요</li>
      <li>트랜잭션의 범위를 잡기 어려움, 글로벌 트랜잭션에 대한 수요가 생길 수 있음</li>
      <li>도메인 영역에서 어디까지 알아도 되고 몰라야하는지 판단이 필요</li>
    </ul>
  </li>
  <li>중복 코드 많아짐
    <ul>
      <li>모듈 단위에서 DTO 변환이 잦음</li>
      <li>포트와 어댑터로 분리된 모듈 사이에서 거의 동일한 멤버 프로퍼티를 갖는 DTO 간의 변환이 요구됨, 반복되는 코드로 인해 가독성이 저하됨</li>
      <li>코딩 작업 시 왔다 갔다 많이 해야 함</li>
    </ul>
  </li>
  <li>정말로 독립할 수 있을까?
    <ul>
      <li>어댑터들의 데이터 변경이 도메인에 영향을 미칠 수 밖에 없음</li>
      <li>데이터 타입이 변하거나 변수명이 변경되는 것 정도는 문제가 없으나, 중요 데이터가 추가/삭제 될 때에는 영향을 받을 수 밖에 없음</li>
      <li>도메인에 대한 강한 확신과 이를 유지하기 위한 로드맵이 필수, 이것이 없다면 변경되는 코드양이 엄청 많아짐</li>
    </ul>
  </li>
  <li>프로젝트가 방대해짐
    <ul>
      <li>별 기능이 없는데도 규모가 커짐, 간단하게 유지하고 싶지만 기본적으로 크기가 큼</li>
      <li>거대한 모노리스를 만든 것 같은 느낌</li>
      <li>그냥 서비스를 잘게 쪼개서 MSA 로 만든 것 보다 뭐가 더 좋지?</li>
    </ul>
  </li>
</ul>

<h2 id="생각과-고민들">생각과 고민들</h2>

<ul>
  <li>역시 만능키는 아님</li>
  <li>개발 자원(인력, 시간)을 상당히 많이 요구함 - 익숙해지면 괜찮음, 네이밍 룰이나 컨벤션이 중요!</li>
  <li>적고 보니 좋은 점 보다 나쁜 점이 많아 보임 - 그럼에도 해볼 만 하다</li>
  <li>단점을 수용하고 제어할 수 있으면 더 이상 단점이 아님, 어려울 뿐 나빠지는 것이 아님</li>
  <li>굳이 육각형이 아니라 그냥 계층형 아키텍처에서도 테스트를 충분히 잘 구축하고 비즈니스 로직을 잘 분리할 수 있음, 그러나 한 번 육각형을 경험한 뒤에는 계층형도 자연스레 육각형을 따라갈 것 같음</li>
  <li>앞으로도 계속 쓸 것이냐 묻는다면?
    <ul>
      <li>상술한 장단점과 프로젝트의 특성을 반드시 검토 - Trade-off 를 고려!</li>
      <li>동료들과 협의만 된다면 계속 쓰고 싶음</li>
    </ul>
  </li>
</ul>

<h2 id="추천-대상">추천 대상</h2>

<ul>
  <li>기술적인 해결책보다 비즈니스 로직이 훨씬 더 중요하고 복잡할 경우</li>
  <li>비즈니스 요구사항에 대한 확신이 있을 경우</li>
  <li>큰 프로젝트</li>
  <li>개발 조직이 충분히 커서 리소스를 나누거나 여유있게 개발할 수 있을 경우</li>
</ul>

  </article></div>

Personal Tech Note

Hexagonal Architecture 는 정말 좋았을까?
Hexagonal Architecture 정리 이 후, 실제 Hexagonal Architecture(이하 육각형 아키텍처)를 적용하여 프로젝트를 수행하며 배우고 느꼈던 점, 성과와 실패를 정리해 본다.
주의
어떤 기술이나 도구든 팀과 조직의 역량, 그리고 프로젝트 일정과 성향에 따라서 적합한지 확인해야 한다. 이 글은 개인의 경험에 기반한 내용일 뿐 육각형 아키텍처의 객관적 지표가 아님을 분명히 한다. 개인의 역량 부족, 잘못된 활용, 프로젝트 상황 및 다른 기술 스택의 영향 등이 있을 수 있다. 또한, 여기서 작성된 장단점은 육각형 아키텍처”만” 가진 특징이 아님을 짚고 넘어간다.
해당 프로젝트는 계속 진행 중(2023년 11월 기준)이므로 향후 의견이 추가되거나 바뀔 수 있다.
도메인 로직, 비즈니스 로직 - 육각형 아키텍처에서는 도메인 계층이 존재한다. 여기에 구현되어야 하는 로직, 결국 가치를 일으키는(돈을 벌어다 주는) 로직에 대해서 비즈니스 로직으로 통칭한다.
좋았던 점
의존성으로부터의 독립 그리고 테스트
    
육각형 아키텍처를 유지하기 위해 의식적으로 의존성 분리, 가급적 서버 컨테이너 설정도 분리하려고 노력함
의존성이 분리되니 테스트가 너무 간편해짐 - 인터페이스는 mocking 하고 요청과 그 결과를 검증하는 반복적인 단계
테스트가 쉬우니 테스트 코드 작성도 빨라지고 많아짐, TDD 적용 가능
프로젝트의 모듈화
    
프로젝트의 각 계층을 모듈로 분리할 수 있음, 즉, 모듈별로 업무를 나누어 R&R 관리 쉬움
기능 또는 업무를 잘게 쪼갤 수 있음 - 빠른 커밋과 피드백 가능
비즈니스 로직에 집중
    
도메인 계층은 비즈니스만 고민 - 기획자와 함께 고민 가능(DDD…)
코드 구조나 라이브러리, 리소스를 어떻게 쓸지 고민하기 보다 요구사항을 어떻게 구현할지에 대해 집중
외부 서비스와 연계를 최대한 지연시킬 수 있음
    
연동해야 할 외부 서비스가 아직 준비되지 않았다면 이 부분을 dummy 로 대체하여 우리 비즈니스 로직부터 개발할 수 있음, 느슨한 연결
나중에 외부 서비스가 준비되면(또는 변경되면) 연동 부분에서만 대응하면 됨
완성되어 가면서 느끼는 안정감
    
지극히 단순한 구조 유지 가능, 복잡한 부분도 결국은 모듈 단위로 추상화되어 격리됨
그냥 만들었다면 기능에 따라 각기 다른 구조(structure)가 나오거나 변경될 수 있지만, 육각형 아키텍처의 철학에 맞추면서 지속해서 단순하고 일관된 구조를 지향하게 됨
테스트가 많이 만들어져 신뢰감 생성
나쁘지 않은 구조를 강제
    
육각형 아키텍처보다 효율적인 구조였지만, 라이프사이클이 진행되며 점점 나빠지다 최악으로 빠지는 것을 사전 차단
구조를 유지할 아키텍처의 기준이 없으면 그때그때 필요한 모양으로 변하고 차후에는 일관성 없고 가독성이 떨어지는 구조로 변하게 되어 기술 부채가 되어버림, 특히, 외부 연동 또는 DB entity 에 의해 비즈니스 로직이 흔들려 버릴 수 있음
여러 기능을 구현하더라도 일정한 틀을 유지해 주므로 시간이 흐르더라도 깨끗한 구조가 유지될 가능성이 높음
나빴던 점
불안하고 (심리적으로) 어려움
    
왜 해야 하냐에 대한 물음에 대쪽과 같이 응대할 수 없음 - 이론적으로는 말할 수 있겠지만, 주변에 활용 사례와 레퍼런스를 찾기 어려움(아키텍처의 대중화 필요?)
스스로도 할 수 없을 것 같은, 괜히 한 것 같은 의구심이 끊이지 않음
하고 나서도 뭔가 찜찜함 - 성공 사례와 비교할 수 없음
상급자와 동료들의 지지가 필요함
프레임워크로부터의 완벽한 독립은 어렵거나 불가능
    
비즈니스 로직과 무관하지만 비즈니스 로직에 포함되어야 하는 애매한 데이터들(예를 들면 tracking id 등)을 어떻게 처리할지 의사결정 필요
트랜잭션이나 컨텍스트 데이터 처리는 프레임워크를 활용할 수 밖에 없음 - 비즈니스 로직에 집중하려던 철학에 금이 가기 시작
비즈니스 로직 분리나 성능 개선 지점의 모호함으로 고민거리가 많아짐
    
추상화된 인터페이스의 구현체는 비즈니스 로직에서 최적화를 할 수 없음
예를 들어 데이터의 종류에 따라 세밀한 처리가 필요할 때, 인터페이스를 성능적으로 세분화하는 것과 논리적으로 추상화 할지에 대한 의사결정 필요
트랜잭션의 범위를 잡기 어려움, 글로벌 트랜잭션에 대한 수요가 생길 수 있음
도메인 영역에서 어디까지 알아도 되고 몰라야하는지 판단이 필요
중복 코드 많아짐
    
모듈 단위에서 DTO 변환이 잦음
포트와 어댑터로 분리된 모듈 사이에서 거의 동일한 멤버 프로퍼티를 갖는 DTO 간의 변환이 요구됨, 반복되는 코드로 인해 가독성이 저하됨
코딩 작업 시 왔다 갔다 많이 해야 함
정말로 독립할 수 있을까?
    
어댑터들의 데이터 변경이 도메인에 영향을 미칠 수 밖에 없음
데이터 타입이 변하거나 변수명이 변경되는 것 정도는 문제가 없으나, 중요 데이터가 추가/삭제 될 때에는 영향을 받을 수 밖에 없음
도메인에 대한 강한 확신과 이를 유지하기 위한 로드맵이 필수, 이것이 없다면 변경되는 코드양이 엄청 많아짐
프로젝트가 방대해짐
    
별 기능이 없는데도 규모가 커짐, 간단하게 유지하고 싶지만 기본적으로 크기가 큼
거대한 모노리스를 만든 것 같은 느낌
그냥 서비스를 잘게 쪼개서 MSA 로 만든 것 보다 뭐가 더 좋지?
생각과 고민들
역시 만능키는 아님
개발 자원(인력, 시간)을 상당히 많이 요구함 - 익숙해지면 괜찮음, 네이밍 룰이나 컨벤션이 중요!
적고 보니 좋은 점 보다 나쁜 점이 많아 보임 - 그럼에도 해볼 만 하다
단점을 수용하고 제어할 수 있으면 더 이상 단점이 아님, 어려울 뿐 나빠지는 것이 아님
굳이 육각형이 아니라 그냥 계층형 아키텍처에서도 테스트를 충분히 잘 구축하고 비즈니스 로직을 잘 분리할 수 있음, 그러나 한 번 육각형을 경험한 뒤에는 계층형도 자연스레 육각형을 따라갈 것 같음
앞으로도 계속 쓸 것이냐 묻는다면?
    
상술한 장단점과 프로젝트의 특성을 반드시 검토 - Trade-off 를 고려!
동료들과 협의만 된다면 계속 쓰고 싶음
추천 대상
기술적인 해결책보다 비즈니스 로직이 훨씬 더 중요하고 복잡할 경우
비즈니스 요구사항에 대한 확신이 있을 경우
큰 프로젝트
개발 조직이 충분히 커서 리소스를 나누거나 여유있게 개발할 수 있을 경우

Hexagonal Architecture 후기

댓글