20241205_팀 프로젝트 1일차

팀 프로젝트 발제

어제 개인 과제가 끝났지만, 바로 팀 프로젝트 발제가 있었다. 발제 내용은 이전보다 친절하게 작성되어 있었지만, 분량이 워낙 많아서 이해하는 데 시간이 꽤 걸렸다. 발제가 끝난 후에는 본격적으로 요구사항을 분석하는 시간을 갖기로 했다.

MSA 특강

분석을 시작하고 얼마 지나지 않아 MSA 특강이 있어 논의를 잠시 멈췄다. 이 특강에서는 MSA에 근간인 서비스 디스커버리와 게이트웨이에 대해 다뤘다. 설정 옵션을 활용해 적용하는 방법과 Java로 직접 구현하는 방법을 모두 배울 수 있었다. 특히 직접 구현하는 방식은 큰 도움이 될 것 같아 흥미롭게 들었다.

LoadBalancer Weight

마지막에는 개인 과제에서 다뤘던 로드밸런싱의 가중치에 대해 설명을 들었다. 내가 사용했던 방식이 실제로 동작하지 않는다는 사실을 알고 충격을 받았다. 테스트할 때는 얼추 가중치대로 요청이 나뉜 것처럼 보였지만, 실제로는 서비스 엔드포인트가 모두 동일했기 때문에 로드밸런서가 가중치를 적용하지 못한 것이었다. 결국 모든 요청이 동일한 URI로 연결되었다는 점을 알게 되었다.

가중치를 적용하기 위한 특정 서비스 지정

특강이 끝난 후 튜터님께 추가로 질문을 드렸다. 특정 서비스 인스턴스를 지정해서 설정하는 것은 MSA의 기본 원칙인 유연성과 독립성을 훼손하기 때문에 제공되지 않는다는 설명을 들었다. 대신 성능에 따라 서비스 인스턴스를 그룹화하고 그룹 단위로 가중치를 설정하는 방법이 적합하다고 하셨다. 예를 들어, 성능이 좋은 그룹에는 7의 가중치를, 성능이 낮은 그룹에는 3의 가중치를 적용하는 방식이 있다. 이 방식은 MSA의 유연성을 유지하면서도 성능 차이를 반영할 수 있는 좋은 방법이라는 생각이 들었다.

요구사항 분석 및 설계 논의

발제 이후에는 팀원들과 요구사항을 논의하며 분석을 진행했다. 논의 중 특히 비활성화를 기준으로 사용할 수 있는 3가지 유사 컬럼과 같이 모호한 요구사항이 있어 다양한 의견을 나눴다.

그리고 요구사항에서 제시된 DDD 스타일의 패키지 구조를 보며 새로운 접근 방식을 알게 되었다. application 레이어와 presentation 레이어에서 각각 DTO를 따로 사용하는 구조였는데, 기존 프로젝트에서 겪었던 문제를 해결해주는 방식이라 신선하게 다가왔다. 이전 프로젝트에서는 DTO를 서비스 레이어로 가져오지 않으려고 노력했지만, 그 결과 다양한 데이터를 전달할 때 엔티티를 사용할 수밖에 없었다. 이번에 제시된 구조는 레이어마다 서로 다른 DTO를 사용함으로써 데이터 전달 문제와 역류 참조를 방지할 수 있었다. 팀원들은 기존에 뷰와 컨트롤러에서 사용하던 DTO를 그대로 비즈니스 로직으로 전달하던 방식과 달라져 혼란스러워했지만, 새로운 구조의 장점을 설명하며 함께 설계를 진행했다.

DTO 도출

숙지가 끝나고 ERD를 바로 작성하려던 중 튜터님이 제안해준 설계 플로우를 따르기로 했다. 기획에서 내용을 숙지한 후 화면 설계 단계에서 DTO를 도출하고, 이를 바탕으로 DB 설계와 서버 설계를 진행하는 방식이다.

그러나 이상하게도 어떤 필드를 가지고 있고 어떤 기능이 있어야 할지 정의되지 않은 상태라서 DTO를 뽑아내기가 어려웠다. 필드와 기능이 명확하게 정의되지 않으면 DTO를 설계하는 것도 불가능하다는 점에서 순서가 어딘가 잘못되었다는 느낌이 들었다. 그래서 간소화된 API 명세서를 작성하며 필요한 데이터와 기능을 정리했다.

지금 와서 보니 설계 플로우에서 기능을 정의하는 단계에 대한 구체적인 언급이 없었고, 내가 이를 생략해버린 것이 원인이었다. 기능 정의가 포함되지 않은 상태에서 설계를 시도하다 보니 막막할 수밖에 없었던 것이다. 이후에는 명세 작성 단계에서 기능을 먼저 정의한 뒤 설계 플로우를 이어가기로 했다.