2달차 - 기술적 선택 회고

기술적 선택

이번 프로젝트에서는 세 가지 방식을 새로 도입했다.

첫 번째는 보조 객체 분리였다. 기존 코드에서는 입력값 처리, 검증, 화면 흐름에 필요한 데이터가 한곳에 섞이는 느낌이 있었다. 파일 수가 늘어나는 부담은 있었지만, 역할을 나눠두는 편이 이후 수정에 더 안전하다고 판단했다. 그래서 Form, Request 같은 보조 객체를 분리했다. 다만 이 선택을 할 때 다른 대안을 충분히 비교하지 못한 점은 아쉬웠다.

두 번째는 정적 팩토리 메서드였다. 이전 프로젝트에서 다른 사람의 PR을 보며 처음 알게 된 방식이었지만, 당시에는 직접 적용하지 못했다. 이번에는 객체 생성 의도를 메서드 이름으로 드러내고 싶어서 적용했다. 단순히 생성자를 호출하는 것보다 어떤 목적의 객체 생성인지 코드에서 더 잘 보이게 만들 수 있다고 판단했다.

세 번째는 오케스트레이션 레이어 도입이었다. 이 부분은 팀에서 함께 결정했다. 컨트롤러가 여러 Service를 직접 호출하면 흐름은 빠르게 만들 수 있지만, 컨트롤러 책임이 커지고 서비스 간 흐름이 흩어질 수 있다고 봤다. 그래서 AppService에서 전체 흐름을 조율하고, 각 Service는 자신의 역할에 집중하도록 구조를 잡았다.

구현 과정에서 마주친 문제

기능 구현 자체에서 큰 오류가 발생하진 않았다. 하지만 구조를 끝까지 일관되게 가져가는 데는 어려움이 있었다.

특히 AppService를 도입했음에도 일부 컨트롤러에서는 여전히 Service를 직접 호출하는 부분이 남아 있었다. MVP 구현을 먼저 끝내고 이후 리팩터링하려 했지만, 시간이 부족해서 구조를 완전히 정리하지 못했다.

또 AppService 테스트도 작성하지 못했다. AppService가 여러 흐름을 조율하는 역할이라면 테스트를 통해 흐름이 의도대로 동작하는지 확인했어야 하는데, 이번에는 그 단계까지 가지 못했다.

트레이드오프

보조 객체를 분리하면서 Form, Request 파일이 늘어났고 구조적 복잡도도 올라갔다. 처음 보는 사람 입장에서는 확인해야 할 파일이 많아졌을 수 있다.

그래도 입력값 처리와 도메인 흐름이 한곳에 섞이는 것보다는 역할을 나눠두는 편이 유지보수에 더 유리하다고 판단했다. 특히 프로젝트가 조금만 커져도 하나의 객체나 메서드에 책임이 몰리는 문제가 생길 수 있기 때문에, 이번 상황에서는 감수할 만한 복잡도였다고 본다.

AppService도 마찬가지였다. 계층이 하나 늘어나기 때문에 단순 CRUD에서는 과한 구조처럼 보일 수 있다. 하지만 여러 Service를 조합해야 하는 흐름에서는 컨트롤러를 얇게 유지하고, 애플리케이션 흐름을 한곳에서 볼 수 있다는 장점이 있었다.

현재 구조의 한계

현재 구조에서 가장 큰 한계는 일관성 부족이다.

AppService를 도입했지만 모든 흐름이 AppService를 거치도록 정리되지는 못했다. 일부 컨트롤러는 AppService를 사용하고, 일부 컨트롤러는 Service를 직접 호출하는 상태가 남아 있다. 이 상태가 길어지면 팀원마다 흐름을 작성하는 기준이 달라질 수 있고, 구조를 이해하는 비용도 올라갈 수 있다.

또한 AppService 테스트가 없기 때문에 여러 Service를 조합하는 흐름이 의도대로 동작하는지 검증하기 어렵다. 단위 기능은 동작하더라도, 전체 애플리케이션 흐름에 대한 신뢰도는 충분히 확보하지 못했다고 본다.

다음에 다르게 할 것

다음 프로젝트에서도 MVP를 먼저 구현하고 이후 리팩터링하는 큰 방향은 유지할 것 같다. 다만 이번처럼 구현 이후에 구조를 맞추는 방식만으로는 한계가 있었다. 다음에는 최소한 주요 흐름에 대해서는 구현 전에 책임 범위를 먼저 정리하고 시작하고 싶다.

특히 AppService를 사용할지, Controller에서 직접 Service를 호출할지, Domain Service가 필요한지 같은 기준을 팀 차원에서 먼저 맞춰야 한다고 느꼈다. 그래야 구현 중에 “이 로직이 어디에 있어야 하지?”라는 고민으로 시간을 덜 쓰게 될 것 같다.

정적 팩토리 메서드, 보조 객체 분리, 오케스트레이션 레이어는 다음 프로젝트에서도 우선 검토할 것이다. 다만 무조건 그대로 적용하기보다는, 도메인 복잡도와 팀 규모에 비해 과한 구조가 아닌지 먼저 판단하고 선택하려 한다.

또 다음 프로젝트에서는 DDD와 TDD도 단순히 개념으로만 가져가는 것이 아니라, 작은 범위라도 실제로 적용해보고 싶다. 특히 AppService 테스트를 작성해서 여러 Service가 조합되는 흐름을 검증하는 경험을 해보는 것이 다음 목표다.