프로젝트 중간 회고

서비스 기획의 중요성

새롭게 팀을 짜고 프로젝트를 진행한지 어느덧 4~5주가 지났다.
나름 기획 부분이 어느정도 확정된 선에서 개발팀을 꾸렸다고 생각했었는데, 개발을 진행하면서 계속해서 기획의 부족함을 느꼈다.

그래서 새롭게 디자이너분도 모시고, 나도 계속해서 기획에 시간을 투자하고 있는거같다. 스타일키 서비스의 시그니처는 바로 "패션 성향 테스트"이다. 간단한 테스트를 통해 나의 패션 성향을 파악하고, 그 결과를 통해 나의 대표 스타일포인트를 알게 된다.

Mbti 테스트랑 비슷하다. 패션 유형을 8가지로 나눴고, 질문을 통해 사용자의 성향을 파악하여 이 8가지의 종류 중에 나와 가장 비슷한 유형을 배정해주면 된다.
그런데 중요한 것은 이 서비스의 주 사용층 중에 바로 패션에 관심이 어느정도 있고, 자신에게 어울리는 스타일이 뭔지 잘 알고 있는 사람들도 포함된다. 즉, 테스트 자체의 질이 낮거나 본인이 납득되지 않는 결과가 나오면 서비스 자체에 대한 신뢰도는 보장받지 못할것이다.

이처럼 테스트 자체에 대해 흥미와 신뢰도 모두 잡기 위해 구성을 굉장히 오래 고민중이다. 더불어 어떤 기준으로 결과를 선정해야되는지 많은 고민이 있었다.

개발 진행상황

이 서비스는 관리자페이지와 서비스페이지 두 가지 모두 개발을 계획했다. 관리자페이지는 지속적으로 코디룩과 아이템을 시즌별로 업로드 하고, 회원을 관리하기 위한 용도로 제작을 결심했다.

먼저 관리자페이지는 패션 콘텐츠인 코디룩, 아이템, 브랜드 목록을 관리하는 기능이 필요했다. 코디룩과 아이템은 강한 연관관계를 가지고 있다. 코디룩 안에 아이템이 포함되고, 아이템은 브랜드와 카테고리와 연관관계를 가지고 있다. 이처럼 코디룩을 생성할 때 연관된 모든 데이터를 한꺼번에 등록할 수 있도록 간단한 CRUD 기능에서 더 많은 부분까지 신경 쓰며 구현했다. 이 부분은 프론트 작업이 아직 완성되지 않아 나 혼자 postman으로 api 요청을 보내고 응답을 확인하며 테스트 해봤다. 일단 이전에 1차적으로 기능 구현 위주로 개발을 끝냈고, 이번에 다시 전체적으로 리팩토링 작업을 진행했다.

시간이 지나고 나서 보는 내 코드는 정말로.. 쓰레기 같았다. 그때는 보지 못했던 부분까지 보이니 얼마나 내가 낮은 수준이었는지 확인할 수 있었다. 다른 의미로 그만큼 개발 실력과 여러 부분까지 볼 수 있는 안목이 길러졌다고 생각하고, 다시 리팩토링을 했다.

리팩토링 과정에서 가장 크게 수정된 부분은 다음과 같다.

1. Optional을 활용하여 null 객체 처리 및 코드 안정성을 강화
2. Swagger를 적용하여 API를 문서화 작업 진행
3. Request, Response DTO 형식 통일
4. 코디룩과 아이템을 함께 생성할 수 있도록 수정
5. 스타일포인트 아이디 별 코디룩 목록 조회 추가, 코디룩 별 아이템 목록 조회 추가

이와 관련된 PR들
Feature: 브랜드, 스타일포인트, 카테고리 관련 기능 추가
Feature: 관리자페이지 패션 콘텐츠 관리 기능 추가
Feature: 스타일포인트 서비스페이지 조회 API 기능 추가

1. 이전 코드에서는 null을 전혀 신경 쓰지 않고, 무작정 생성이 완료되면 그 엔티티를 그대로 반환했었다. 이렇게 하면 엔티티 조회 시 null 값을 조회하려고 하면서 코드의 안전성이 무너질 문제가 발생한다. 이를 Optional을 활용하여 해결했다.
2. Swagger ui를 적용해서 새롭게 API 명세서를 작성했고, 이를 프론트 팀원분들께 공유하는 방식으로 개발을 진행했다.
3. 전에는 내가 DTO에 대한 명확한 개념이 잡혀 있지 않았던 때라, 단순히 데이터를 저장하고 조회 시 사용할 목적으로 Request, Response을 동일한 스펙으로 1개만 두고 구현했었다.
   이에 같은 팀원분께서 Request와 Response dto 항상 따로따로 구현하시길래, 이유를 물었더니 "API 요청과 응답 스펙은 언제든지 변경될 수 있어요. 무엇보다 가독성이 올라가고, 만드는데 드는 리소스에 비해 이점이 크다고 생각합니다."라고 말씀해주셨다. 그러고보니 나도 이전에 Response body에 넣을 값을 작성할 때, dto에 없는 값을 넣기 위해 ResponseEntity<Map<String, Object>>이러식으로 값을 하나씩 넣어줬었다. 이는 귀찮고 변경에 취약한 단점을 가지므로 보통 잘 사용하지 않는 방식이었다. 나는 몰랐다... 암튼 이러한 피드백과 깨달음을 얻고 모든 API에 Request, Response dto 각각 추가해서 구조를 리팩토링했다.
4. 기존의 코디룩과 아이템, 브랜드를 등록하는 과정은 매우 복잡했다. 브랜드를 먼저 등록하고, 이를 이용해서 아이템을 등록하고, 이를 조합해서 코디룩을 등록했다. 너무나도 복잡한 절차로 등록하는게 효율적이지 않다고 생각되었다. 그래서 코디룩을 등록할 때 아예 아이템을 함께 등록하도록 구조를 모두 바꿨다. 하지만 브랜드는 그대로의 방식대로 먼저 등록을 하는 것으로 유지했다.
   이유는 가장 큰 카테고리인 스타일포인트 안에 브랜드 목록이 종속되고, 이 브랜드에 속한 아이템을 조합하여 코디룩을 만드므로 브랜드 자체는 아이템을 결정하기 전, 맨 처음부터 리스트를 결정하므로 그냥 먼저 등록하는 방식이 옳다고 생각했다.
5. 스타일포인트 ID별 코디룩 조회 기능과, 이에 해당하는 아이템을 조회하는 기능을 추가했다. 서비스페이지와 관리자페이지에서 공통적으로 필요한 기능이다. 이전에는 프론트에서 모든 목록을 조회해서 거기서 필요한 정보를 가공하는 방식이었는데, 백엔드 단에서 이를 적절하게 처리해서 반환해주는게 맞다고 생각하여 다시 리팩토링 했었다.

내가 맡은 패션 콘텐츠 부분 개발은 이정도이다. 나머지 회원 부분 (소셜 로그인), 테스트 부분도 절반 넘게 진행 중이다.

앞으로의 계획

1. 먼저 이제까지 개발한 코드를 모두 단위 테스트 할 것이다. 항상 TDD를 목표했었는데, 비록 이상적인 TDD를 만족하긴 힘들어도 중간 중간 기능을 테스트하며 다음 개발을 이어나갈 것이다. 이를 위해 테스트 코드를 자체에 대한 학습이 필요할 것 같다. 항상 그냥 chat gpt를 사용해서 대충 테스트 코드를 작성했었는데, 이번에는 제대로 Junit 프레임워크를 공부해보며 독립적으로 테스트를 진행하는 방법을 알아봐야겠다.

2. 최근 본 아이템, 코디룩과 아이템 즐겨찾기 기능 등을 개발할 계획이다. 테스트 쪽은 먼저 질문이 완성되면 담당하시는 팀원분이 개발해주실거고, 소셜로그인 쪽도 앞으로 프론트와 연동만 하면 마무리 될 것 같다. 그리고 코디룩과 아이템의 페이징 처리도 필요할 것 같다.

3. 배포를 위해 AWS ec2 서버 환경 설정과, ci/cd를 위해 github actions 부분을 공부해야한다.

4. 코디룩 제작을 위해 필요한 데이터를 찾고, 디자인에 필요한 이미지를 제작해야 한다.

프로젝트 완성을 위해 팀을 이끌어가는 입장으로서, 책임감을 가지고 더욱 더 신경 써서 임하고자 한다!! 무엇보다 기능을 개발할 때 가장 즐겁지만, 기획을 하는 과정에서도 너무나도 즐겁다. 이번 회의에서는 나중에 사용자들이 어느정도 모이면 커뮤니티 기능을 추가해서 서비스를 확장해보자고 내 본심(?)을 말했다.😁 다행이 긍정적인 반응이었다.. 빨리 기능을 완성하고 서비스화 하고 싶다.

내 옆에 든든한 팀원들이 있으니 의지도 되고,, 많은 도움을 받는거같다. 😊
꼭 모두가 만족하는 결과물이 나왔으면 좋겠다!! 🙏