[레벨 3 회고] 하루스터디 5주차 회고
5주차는 리팩토링 + 버그 수정에만 전념한 한 주였는데요, 마찬가지로 무엇을 느꼈는지 무엇을 경험했는지 회고하고자 합니다.
패키지 구조 변경
이번주 들어 가장 큰 변화가 있다면 패키지 구조를 변경했다는 것입니다. 사실 이전까지는 패키지 구조에 대해 신경쓰지 않고 개발을 진행했던 터라, 한번 즈음은 패키지 구조에 대한 고민을 진행해야만 했습니다.
// 이전 구조
└── backend
├── config
├── controller
│ └── exception
├── dto
│ ├── request
│ └── response
├── entity
├── exception
├── repository
│ └── dto
└── service
└── dto패키지 구조 변경에 있어 하루스터디 팀의 선택지는 크게 두 가지로 좁혀졌었는데요.
- 계층형 구조
- 기능별 패키지 구조
제가 주장하는 쪽은 2번인 '기능별 패키지 구조'였습니다. 사실 기능별 패키지 구조가 엄청 좋다! 라고 느껴져서 주장한 것은 아니고 계층형 구조의 단점이 명확해 보였기 때문입니다.
계층형 구조를 선택하는 경우 계층 간의 의존성은 매우 잘 드러나기 때문에 좋으나, 작은 프로젝트가 아니면 그다지 적합하다고 생각하지는 않습니다. 또한 도메인 별 패키지 구조를 선택하더라도 계층 간 의존성은 어느정도 잘 드러나는 편입니다.
오히려 객체가 많아진다면 관리하기가 어렵고, 패키지 구조만 보고 원하는 기능을 쉽게 찾아갈 수 없습니다. 반면 기능별 패키지 구조의 경우 원하는 기능을 찾아가기까지의 depth를 현저히 줄여줍니다. 스터디 진행에 관한 기능을 수정하고 싶다면, 'progress' 패키지를 찾아가면 됩니다.
└── backend
├── common
├── config
├── content
│ ├── controller
│ ├── domain
│ ├── dto
│ ├── repository
│ └── service
├── member
│ ├── domain
│ ├── exception
│ └── repository
...
하지만 이런 근거들을 바탕으로 팀원들과 논의하는 과정에서, 기능별 패키지 구조의 몇가지 단점도 드러났습니다.
- 여러 기능을 내부적으로 사용하는 기능이 추가된다고 한다면 상당히 애매해집니다.
- 순수 객체지향적 협력 구조에서 벗어나기가 쉽습니다. 각각의 패키지를 자연스레 모듈처럼 바라보기 때문에 다른 패키지를 참조하는 것에 대한 거부감이 생깁니다.
우선은 팀원들 모두 가시성을 가장 큰 이유로 기능별 패키지 구조를 선택했습니다. 모두가 패키지 가시성에 대해 불편함을 느끼고 있던 상황이었으니까요. 하지만 기능별 패키지 구조가 주는 파급효과에 유의해야 할 것으로 보입니다.
도메인 설계에 관한 고민
패키지 구조와 어느정도 이어지는 내용입니다. 패키지 구조를 고민하면서 팀원들과 자연스레 도메인 객체에 관한 이야기도 나누게 되었는데요. 사실 이 내용은 따로 아티클로 정리할 예정이긴 합니다(방대해서).
순수 객체지향으로 모든 로직을 도메인 객체에 캡슐화할 것인지 말 것인지에 대한 고민이었는데요. 다른 팀원이 제안해준 덕분에 깊게 고민해볼 수 있었고 아직까지는 확실한 저만의 결론이 나지 않은 상태인데 추후 결론이 나면 아티클을 작성하도록 하겠습니다.
레벨 1부터 느끼는거지만 도메인 설계 너무 어렵네요 .. 🥲 특히 영속성에 대한 고민을 안할 수가 없어서 더 그렇습니다.
API가 설계에 미치는 영향
또한 이번주는 API에 대한 고민을 정~말 많이 했던 것 같습니다. 대략적으로 고민했던 부분은 다음과 같습니다.
- API는 클라이언트 중심이어야 할까?
이전에 설계했던 API는 한 페이지에서 필요한 데이터를 바탕으로 구성되었습니다. 하지만 이렇게 API를 구성하니 하나의 API에서 여러 도메인의 정보를 참조하는 일이 발생했습니다.
위 예시를 보면 아시겠지만 DTO 이름이 '~And~' 형식입니다. 그러니까 여러 도메인에 걸쳐 있는 DTO라는 것이죠. 내용을 보더라도 스터디 방에 대한 정보 + 특정 멤버에 대한 진행도를 갖고 있습니다.
이런 API가 존재하니 서비스 코드가 굉장히 지저분해졌습니다(여러 도메인을 참조하므로). 앞서서 도메인 별 패키지 구조를 선택했다고 했는데, 이런 API는 어느 도메인 패키지에 둘지도 상당히 모호했습니다.
이런 생각이 들자 백엔드 크루들은 'API는 자원 단위로 쪼개지고, 클라이언트가 잘 사용하게 하는게 맞다!' 라는 결론에 도달했는데 프론트엔드 크루들은 컴포넌트 설계 시 여러 API를 호출하는 것 자체에 대한 성능 문제를 우려하는 상황입니다.
아직 결론은 나지 않았지만, 상당히 고통스러운 작업이 될 것으로 예상됩니다. 어느 쪽으로 결론이 나든 API가 대대적으로 변경될 것 같다는 생각이 듭니다. 만약 자원 단위로 쪼개지지 않고 monolithic한 API를 구성하는게 맞다고 한다면 백엔드 측에서는 파사드 패턴등을 고려할 것 같은데, 이는 나중에 논의해봐야 할 것 같습니다. 🙄
기타
- 데이터베이스 형상관리를 위해 flyway를 도입했습니다.
- 젠킨스 파이프라인을 직접 구축해보는 경험을 가졌습니다.
- 트러블슈팅을 하면서 웹 브라우저 캐싱, Cloudflare CDN 캐싱에 대해 알게 되었습니다.
되돌아보기
일정 추산은 1.5 배로
프로젝트를 진행하면서 가장 어렵다고 느껴지는 일은 바로 일정 추산입니다. 사실 배포 작업을 월요일까지 마쳤어야 했는데 자잘한 버그 수정 및 리팩토링으로 인해 한 주가 걸렸습니다.. 앞으로 일정 추산을 할 때 코치분들이 말씀해주신 것처럼 조금 넉넉하게 시간을 잡으려는 연습을 해야 할 것 같습니다.