Linkocean 프로젝트 회고

2022.07.21 ~ 22022.8.16까지 기획과 첫 번째 버전의 Linkocean 서비스를 개발했다.

Linkocean 서비스는 소셜북마킹 서비스다. Linkocean 서비스를 개발하면서 좋았던 경험과 아쉬웠던 경험을 공유하려 한다.

 

좋았던 경험

 

Querydsl 제대로 사용하기 (feat : 테스트 코드의 중요성)

Linkocean은 사용자가 원하는 북마크를 쉽게 찾을 수 있게 하려면 다양한 필터링 기능을 개발해야 했다.

 

다양한 필터링 기능을 순수 JPQL을 이용하면 중복 코드가 많아지는 단점이 있어 Querydsl을 사용했다. 하지만 Querydsl에 익숙하지 않아 첫 버전의 코드는 Querydsl의 장점 중 하나인 동적 쿼리를 제대로 활용하지 못했다. 그 결과 아래 그림과 같이 수많은 메서드가 생겼고, 각각의 메서드에는 중복 코드가 무수히 많이 존재했다.

 

이런 문제점을 해결하기 위해 리팩토링을 진행했다.

 

ver1

 

첫 번째 리팩토링은 메서드에서 List를 반환하는 게 아니라 Page를 반환하도록 변경했다. 이를 통해 전체 개수를 조회하는 메서드를 private 메서드로 바꿀 수 있었다. 덕분에 8개의 public 메서드를 4로 줄여 코드 응집도를 높였다. 하지만 아직도 내부적으로 많은 중복 코드가 존재했다.

 

ver2

 

두 번째 리팩토링은 Querydsl의 동적 쿼리를 활용해 4개였던 메서드를 하나로 줄이는 것이 목표였다. 이 과정에서 우리 팀은 applyPagenation, joinIf 라는 util성 메서드를 개발해 활용했다. 그 결과 아래 그림처럼 중복 코드를 최소화하고 코드 응집도를 높일 수 있었다.

 

ver3

 

대규모 리팩토링을 진행하면서 테스트 코드의 중요성을 몸으로 느꼈다. 리팩토링 하기 전 테스트 코드를 꼼꼼히 작성한 덕분에 리팩토링을 더 과감하게 할 수 있었고, 리팩토링으로 생긴 사이트 이팩트도 테스트 코드를 통해 빠르게 잡을 수 있었다.

 

 

아키텍처 고민

북마크 서비스를 개발하면서, 북마크 서비스에서 다른 도메인인 profile, linkmetadata 엔티티 정보가 필요한 상황이 있었다. 이때 북마크 서비스에서 다른 도메인의 레포지토리를 주입 받을지, 아니면 서비스를 주입 받을지 고민했다. 고민한 결과 서비스에서 다른 레포지토리에 바로 접근하면 특정 도메인의 정보가 다른 도메인의 서비스 때문에 변경될 가능성이 있어 위험한 설계라고 판단했다. 그렇다고 서비스에 의존하기에는 순환 참조 문제도 있었고, 단순 조회를 위해 다른 도메인의 서비스에 의존하는 게 과하다고 생각했다.

 

이러한 문제를 해결하기 위해 우리 팀은 @Query라고 하는 영속성 계층에 속해 있는 컴포넌트를 만들었다. @Query는 단순 조회 기능을 수행하는 컴포넌트로 정의했다. 이를 활용해 서비스에서 다른 도메인 엔티티가 필요한 경우 레포지토리가 아닌 @Query 컴포넌트에 의존해 다른 도메인 엔티티를 가져오는 방식으로 설계해 안전성을 높였다.

 

 

아래는 예시 코드이다.

 

@Query 컴포넌트 덕분에 하나의 서비스에서는 다른 도메인 정보를 안전하게 가져올 수 있었고, 만약 데이터 수정과 관련된 작업이 필요한 경우는 다른 서비스를 주입받아 특정 도메인이 다른 도메인의 최소한의 영향을 주도록 설계할 수 있었다.

 

PO 경험

프로젝트 기획 단계에서 내 기획안이 선택받았다. 덕분에 PO 역할을 수행할 수 있었고, 값진 경험이었다.

 

PO로서 초기 기획안을 어떻게 팀원들과 구체화할 수 있을지 고민했다. 단지, 나의 서비스가 팀의 서비스를 만들고 싶었다. 고민 끝에 팀원 다 같이 브레인스토밍을 거쳐 초기 기획안을 기반으로 서비스의 핵심 가치와, 그에 필요한 기능들을 정했다. 이 과정에서 내가 생각했던 것보다 더 다양한 의견이 나왔고 덕분에 내가 제안한 초기 기획안보다 더 멋진 기획안이 만들어질 수 있었다.

 

기획이 구체와 되고는 팀에 애자일 방법론을 도입했다. 우리 팀은 스프린트 기간을 일주일로 잡고 개발을 진행했다. 그리고 스프린트 종료일에 다 같이 스프린트 회고를 진행했다. 덕분에 서로의 작업물을 공유할 수 있었고, 팀의 방향성을 파악할 수 있었다.

 

아쉬운 부분

 

개인적으로 아쉬운 부분

설계 지식의 부족함을 느꼈다. 설계와 관련된 고민에서 관련 배경지식과 경험이 부족해 어떤 게 좋은 방법인지 선택하는 데 많은 시간이 걸렸다. 만약 설계에 대한 지식과 경험이 있었더라면 빠르게 좋은 선택을 할 수 있었을 같아 아쉬웠다. 덕분에 설계 공부를 해야겠다는 필요성을 강하게 느낄 수 있었다.

 

이번 프로젝트에서 Querydsl을 처음 사용해봤다. 처음 사용하는 기술이다 보니 많은 시행착오를 겪었다. 이 시행착오가 값진 경험이었지만 아쉬움이 남는다. Querydsl도 부족한 부분을 추가 학습해 다음에는 시행착오 겪는 시간을 아낄 것이다.

 

프로젝트관련 아쉬운 부분

짧은 시간에 기획에서 개발까지 하느라 서비스의 기능도 많지 않고, 완성도도 떨어지는 것 같다. 이런 부분은 다음에 보완할 것이다.

기능 관점에서는 팔로우 기능, 알림 기능이 있긴 하지만 단순히 데이터베이스에 저장하고 조회하는 방식으로 구현했다. 이를 좀 더 고도화해 보고 싶다. 쿼리도 페이징 쿼리와 카운트 쿼리에 최적화할 수 있는 포인트가 남아있다. 코드도 더 통일성 있고, 중복되는 코드를 줄이는 방향으로 리팩토링하고 싶다.

 

마무리

혼자 기획부터 개발을 하는 게 아니라, 팀 단위로 기획부터 개발까지 경험해 보는 값진 경험이었다. 혼자였다면 절대 못 했을 것 같다. 같이 고생한 팀원들 모두에게 감사의 인사를 전하고 싶다.