[PUDDY] 첫 프로젝트 마무리

4월 20일 첫 팀 프로젝트가 마무리되었다.

 

지금 멤버들을 만나기 전, 팀 프로젝트 경험이 없어서 잘할 수 있을까에 대한 고민을 수십 번 더 하고 참여를 했지만,

회고를 작성하는 지금, 되돌이켜보면 하길 잘 한 경험인 것 같다.

 

우여곡절 끝에 프론트 개발자 2명, 백엔드 개발자는 나 혼자서 프로젝트를 마무리하게 되었다.

다른 백엔드 개발자와의 협업을 초반에 잠깐 해본 것이 아쉽지만, 프런트 - 백을 나누어서 팀 프로젝트의 모든 백엔드 파트를 담당할 수 있었기에 값진 경험이 되었다.

 

또한, 모든 단계를 직접 해야 했기에 어떤 부분에서 내가 부족함이 있는지, 앞으로 어떻게 개선해야 할지 다는 아니지만 어느 정도 내가 부족한 부분을 알 수 있었다.

 

그래서 이 글에서는 내가 부족했다고 느꼈던 순간, 현재 프로젝트에서의 개선 사항에 대해서 기록을 하고자 작성하게 된 글이다.

 

도메인 테이블을 구성하는데 더 많은 시간을 사용할 것

퍼디 프로젝트는 타인의 프로젝트를 레퍼런스 한 것도 아니고, 기획부터 모든 팀원들이 함께한 프로젝트이다.

그러다 보니 도메인 테이블도 직접 ERD CLOUD로 작성하게 되었는데, 이전에는 JPA의 엔티티 클래스로 먼저 만들어보고 살을 붙여나간 나에게 도메인 테이블을 먼저 구성해야 한다는 것이 중요하다는 것이 추상적으로 느껴졌다.

 

팀 프로젝트인 만큼 내가 이해하는 것뿐만 아니라, 다른 팀원에게 이해를 시켜야 하고, 더 좋은 방법으로 풀어낼 수 있을까 수없이 고민이 필요하기 때문이다.

그래서 모든 테이블의 컬럼에 대해서 이것이 왜 필요한지, 명칭이 적절한지를 더 고민하는 것이 좋았음을 나중에 개발을 진행하면서 깨닫게 되었다.

명칭이 불분명해서 프론트와 매핑하는데 차질이 발생하기도 하고, 제삼자가 봤을 때 이해하기 어려운 명칭들이 있었기 때문이다.

결국 백엔드 파트를 내가 혼자 다 하게 되면서, 명칭을 바꾸고, 컬럼을 없애고, 관계도를 수정하는 것은 오로지 내 몫이 되어 위 문제에 대한 어려움을 크게 느끼진 못했다.

그러나 추후 백엔드 개발을 다른 팀원과 같이 하게된다면 ERD를 작성하는 것에 더 중요도를 높여야 함을 깨달았다.

 

더 좋은 코드란 무엇일까

회고를 작성하는 지금도 고민중인 사안이며, 클린 코드를 읽게 된 계기이기도 하다.

프로젝트가 진행될수록 테이블이 증가하고, 로직이 복잡해지면서 나중에 어떤 기능을 추가하면서 든 고민이다.

혼자 개발을 진행하면서, 타인에게 피드백을 받을 수 없었기도 하고, 팀 프로젝트이다 보니 최대한 조심스레 기능을 구현하게 된 이유 중에 하나이다.

내가 지금 짜고있는 코드가 프런트의 요구사항에 맞게 요청을 수행하고, 응답을 반환하는 것이 되고, 테스트 코드도 통과한다.

그러나 계속 더 좋은 코드가 있지 않을까? 필드 명칭은 타인이 봤을 때 이해할 수 있을까? 계속해서 고민이 생겼다.

그래서 구글링도 해보고 챗 GPT한테도 피드백을 받아가며 구현을 했지만, 찜찜한 것은 어쩔 수 없었다.

그래서 클린코드라는 책을 프로젝트 후반부에 가서야 읽게 되었다.

 

N+1 문제를 완전히 해결할 수 없다.

기존에 접했던 예제들은 간단한 테이블간에 N+1 문제를 해결하는 것을 보여주었지만, 실제 프로젝트에서 N+1 문제를 해결하는 것은 불가능했다.

 

예를 들어 Question 엔티티는 Image 엔티티와 일대다, Answer 엔티티와 일대다 관계에 있는데,

하나 이상의 컬렉션을 페치조인을 할 경우 MultiBagFetchException을 발생시킨다.

 

그래서 배치 사이즈를 조절하거나, 조회시 2개 정도 쿼리가 더 나가는 것을 묵인했다.

 

또한, 페치조인 문제는 Article 엔티티를 리스트로 조회할 때 문제가 발생했다.

Article과 일대다 관계인 Image 엔티티가 있는데, 이를 페치조인을 통해 쿼리를 줄이려고 하면 일대다에서 다쪽을 기준으로 페이징이 되기 때문에 중복된 값이 조회되었다.

 

결국 페이징을 할 때에는 N+1 문제가 발생하는 것 배치사이즈를 조절하거나, 묵인할 수 밖에 없었다.

 

테스트 코드는 꼼꼼히 작성하자

TDD TDD..참 어렵다.

테스트 코드를 먼저 작성한다는 것 자체가 개인적으로 너무 비효율적으로 느껴졌고, 실제 비즈니스 코드에 대한 생산성이 적다 보니

개발하는 것이 재미가 없게 느껴졌다.

 

그렇게 개발의 재미를 찾아 결국 비즈니스 코드를 중심으로 코드를 구현했고, 우여곡절로 포스트맨으로 수많은 테스트를 해가며 프로젝트 요구사항을 맞춰나갈 수 있었다.

그리고 프로젝트 후반부에 여유가 생겨 모든 API, 비즈니스 로직에 대한 테스트 코드를 작성하게 되었다.

 

모킹이라는 것도 제대로 알지 못했지만, 의외로 테스트 코드가 통과하지 못하는 빨간 에러가 초록색으로 변해가는 것이 정말 뿌듯했다.

그전에는 실제 비즈니스 코드를 먼저 구현해 나갔기 때문에, 클라이언트의 요청에 따라 값이 제대로 오는지 실제 운영 서버에서 확인할 수 있었다.

즉, 내가 맞게 구현했는지 입증이라는 것을 할 수 없었다고 생각한다. 

그리고 비즈니스 로직을 테스트해가며, 마지막으로는 API 컨트롤러 테스트까지 다 끝내고, 내가 코드를 제대로 짜긴 짰구나 하는 안심과 테스트 코드의 중요성을 깨달을 수 있었다.

 

테스트 코드를 어떻게 하면 더 효율적으로 짤 수 있을지, 더 많은 케이스가 있을지 고민하는 경험을 할 수 있었다.