2023년 4월 7일 - SSAFY 2번째 프로젝트 종료

들어가며

SSAFY 8기 두번째 프로젝트(특화)가 종료됐습니다.

프로젝트를 진행하면서 스스로 회고를 해보면 좋겠다는 생각이 들었어요.

잘한 점

1. MSA(Micro Service Architecture)

이번 프로젝트에서 처음으로 MSA를 활용하면서 Eureka, Spring Cloud Gateway, 각 어플리케이션 서비스 서버와 데이터베이스를 따로 두는 경험을 했습니다.

다같이 학습을 위해 기간 중 일주일을 공부하는데 시간을 쏟았습니다. 확실히 그 주에 끝내겠다는 생각으로 강의를 접하니까 어떻게 구현해야할 지 보이고 설계도 편했습니다.

다만 실제로 여러 서비스가 함께 구동되며 동작하다보니 타 어플리케이션에서 Transaction 중 Request를 받으면 검증 차 방문해도 데이터를 읽어올 수 없어 동기화 문제도 발생했었습니다.

| 카프카를 통해서 데이터베이스의 Sync를 맞춘다던지, Read, Write를 나누어 하나의 데이터베이스에서 필요한 내용을 읽게 한다는 등 다른 방법들을 알아보는 시간이 필요할 것 같아서 마지막 프로젝트에서 적용해볼 예정입니다.

그 밖에 필요한 API 호출에 대해서 문서정리를 잘 했다는 게 뿌듯했습니다.

필요한 서비스에 따라 Tag로 구분지어 필요한 API를 상세보기 구현해 두었습니다.

서비스간 시퀀스 다이어그램을 통해 전달되는 과정을 간략히 설명, Request, Response 그 밖에 DTO에 대해 작성해두어 FE, 다른 어플리케이션에서 수월히 사용하는데 지장이 없었고 질문도 적었습니다.

이 부분은 다음번에도 잘 챙겨가야겠습니다.

2. JPA

1. 이번에는 queryDSL을 사용하지 않고 JPA, JPQL만으로 개발을 해봤습니다. 이번에 새롭게 배운 건 hibernate에서 CRUD에 대한 쿼리가 한 트랜잭션에서 발생할 때, 순서가 정해진다는 걸 알았습니다.

어떻게 확인했었냐면 바로 delete 후, insert를 새롭게 하는데 중복 ID에 걸렸던 상황이 있었기 때문입니다. 검색읉 통해 좀 새로운 부분을 알았습니다.

2. 집계 함수(group by) 사용 시, JPQL에서 리턴은 Object[]로 받는 다는 점입니다. 그렇기 때문에 해결하는 방법으로는

   2-1. interface dto를 만들어서 받는 방법(이번)
   2-2. queryDSL

앞으로도 queryDSL을 사용할 기회가 많다고 생각해 직접 JPQL + interfaceDTO를 만들어서 진행해봤습니다.

3. JPA에서 deleteAll에 대해서 여러번 요청이 발생하는 것을 방지하기 위해서 deleteAllInBatch를 통해서 지운 방법이 신선했습니다. 다만 놀란 건 아래와 같은 쿼리 처리..?

Hibernate: delete from deposit_transaction_history where 
transaction_history_id=? or 
transaction_history_id=? or 
transaction_history_id=? or 
transaction_history_id=? or 
transaction_history_id=? or 
transaction_history_id=?

이럴거면 직접 JPQL로 작성하는 게 더 이득이라고 판단하기까지 했었죠.

4. 순환참조 무한루프

양방향관계에 대해서는 여전히 어렵다고 느껴지긴 하는데 무조건 좋다고는 생각이 안들더군요. 어짜피 Lazy로딩을 하는 경우도 있을 것이고 또한 어딘가로 PK를 넘겨서 바로 전체조회를 하는 경우도 있었기에 적절한 JOIN을 고려하는 생각도 해봐야겠습니다.

이번에 무한루프는 ToString을 양방향관계의 1부분에서 막아서 해결했습니다. 운영상 알 필요가 없는 부분이었죠.

5. delete에 대한 flush를 할 필요성

레코드를 삭제하다보면 특정경우에 select문만 수행하고 제거를 안합니다. 제가 파악했을 땐, 연관관계에 속해있거나 어딘가에 참조가 되어있어 스스로 삭제가 못하게 된 것으로 보여 flush를 통해 entityManager를 DB와 적절한 동기화를 수행해야 한다고 생각합니다.

Sonarqube

소나큐브를 통해 codesmell을 많이 줄여나갈 수 있었습니다. 덕분에 스스로도 정적인 부분의 코드를 수정하고 필요한 annotation을 재정비할 수 있었습니다.
기회가 되면 테스트 코드까지 검증을 받아야겠습니다.

부족한 점

1. 엔티티 설계 대한 고민을 많이 하지 못한 점

항상 모든걸 다 만들고 할 수는 없지만 적어도 entity에 대한 모델 검증은 확실히 진행해야겠다고 생각했습니다. 안그러면 시간이 지나 모델이 무너져 애매하게 쿼리와 코드를 작성하기 때문입니다. 사전에 방지할 수 있도록 모델은 신중해야 겠습니다.

2. TEST code의 부족함

테스트 코드를 이번에 많이 작성하지 못했는데 그 이유로 꼽은 건 OCP, LSP, DIP를 많이 지키지 못했던 것 같습니다. MVC 패턴에서도 각 모델 간에 운영할 코드가 있을 텐데 service레이어에서만 다루는게 맞을 까 고민하다보니 구분을 잘 짓지 못했던게 아닐까 싶습니다.

3. WebClient

WebFlux에서 WebClient는 RestTemplate를 대체할 중요한 요소라고 생각합니다. 이번에 사용은 했지만 적절한 API 핸들링이 부족했다고 판단되어 시간되면 공부가 필요할 것 같습니다.

앞으로

앞으로 위에 나온 부족한 점을 채우고 팀원과 프로젝트에 대한 충분한 소통과 함께 격려할 수 있는 프로젝트를 진행해야겠습니다.