[Project] Pre-Project(StackOverflow Clone Coding) 회고

Gogh·2023년 1월 2일

project stack overflow

Project

목록 보기

2/5

🎯 2주간 프론트 & 백엔드 협업 Pre Project 회고

📒 프로젝트 Intro

그간 학습한 내용을 바탕으로 Stack Overflow 플랫폼 클론 코딩.
프로젝트 기간 : 2022.12.19 ~ 2022.01.02
프로젝트 목표
- 프론트,백엔드 협업으로 실무에 준한 협업과 개발역량을 향상 목적
- 개발 목표는 요구사항 정의서 참고
프론트 배포링크 : S3 버킷 배포
백엔드 API Rest Docs : API 명세서
프로젝트 관리 Sheet
- 요구사항 정의서, 화면 정의서, ERD, 테이블 명세서, API Resource
- Google Sheet
GitHub Branch 전략 Git Flow : main,dev(feat,test,refactor)
Frontend Stack : Javascript, React, Redux, CSS, HTML, TailwindCSS, AWS S3
Backend Stack : Java, Spring Boot, Spring DATA JPA, Spring Security, JWT, MySQL, H2, QueryDSL, AWS EC2, AWS RDS

📌 Comment

목표와 달성률을 간략하게 나타내고 After Action Review 방식의 회고를 작성.
무난하게 프로젝트를 마무리 한것 같아 회고를 작성 하는 동안에도 마음이 가볍고 즐거웠다.
어찌 저찌 팀장을 맡게 되었는데... 팀장으로서의 간단한 회고 작성.

📒 After Action Review

📌 Project Goal

사용자 요구사항 정의서

개인 목표
- 처음 해보는 프론트, 백엔드 협업에서 실무에 준한 경험을 해 보고 그간 학습 내용들을 모두 적용해 보고자 하였다.
- 여지껏 협업 툴을 다체롭게 경험 해 보지 못하였기에 팀원들과 의사 소통을 하며 협업시 사용하게 되는 툴들을 적극적으로 활용해 보고자 하였다.
- 사용자 요구 사항 정의서에 기술된 기능들을 모두 구현하는 것이 목표 였다.
- 학습한 내용 이외 새로운 기술을 공부하며 접목해 보고 싶었다.
  - QueryDSL 라이브러리를 활용하여 동적 쿼리를 Java 스럽게 작성하고 적용하기.
  - Nginx Reverse Proxy를 적용하고 로드 밸런싱 대응하기.
  - Redis In-Memory DB를 활용하여 Refresh JWT Token 관리, 로그아웃 기능 구현하기.

📌 Result

API Resource 와 요구사항 정의서에 있는 기능들은 모두 구현하였다.
QueryDSL 라이브러리를 활용하여 동적 쿼리 및 1+N 쿼리 이슈를 개선 하였다.
API 구현중 학습한 기술 외 새로운 기술을 접목해 보지 못하였다.
- Redis 활용 로그아웃, Error Logger 외부 메세지 전송 기능, Nginx Reverse Proxy 배포 등
프론트 쪽에서의 기능은 80프로 이상 구현 되었는데 충분했고 만족스러웠다.
- 내가 구현한 API가 실제로 눈으로 확인되고 동작하는걸 보니 신기하기도 하며, 흥미로웠다.
- 구현 되지 못한 기능들은 직접 눈으로 보지 못하여 조금 아쉽지만 짧은 시간 대비 충분 했고, 완성도 높은 결과물을 만든것 같다.

📌 Learned

협업 프로젝트를 하며 가장 중요하다 생각되는 협업과 팀원간 의사소통.
- 팀원들 간 분위기가 너무 좋았다. 각자의 위치에서 할 수 있는 역량만큼 최선을 다 해 주셨다.
- 최선을 다하는 분위기에 좋은 자극이 되어 나 또한 더 잘해보려고 노력하게 되었다.
- 매일 아침 간단한 데일리 스크럽을 하고 디스코드로 항시 소통할 수 있도록 하였다.
- 매일 모각코를 하며, 라이브로 현황에 대해 의논할 수 있어서 좋았다.
협업 툴
- 노션을 이용하여 주요 회의록 내용 기록.
- 디스코드를 통한 커뮤니케이션.
- GitHub Branch
  - Git Flow 전략으로 관리 하였고, 각 브랜치와, 기능 단위로 업무를 세분화 관리 할 수 있었다.
- GitHub Project 칸반과 Issue 를 활용하여 프로젝트 진척 현황 관리
  - Issue 등록을 함으로서 각 팀원들이 어떤 과업을 진행중인지 파악하기 수월 했다.

프로젝트 관리 문서
- 요구사항 정의서, 화면 정의서, ERD, 테이블 명세서, API Resource
- 프로젝트 구현에 앞서 관리하고 구현해야 하는 모든 부분들을 문서화 하여 작성 해 두니, 프로젝트 중간 중간중간 내가 뭘 해야될지, 어떤 부분이 부족한지 정확히 파악할 수 있었다.
일정 관리
- 기본적인 일정 목표를 수립하여 크게 Stub Data 컨트롤러 -> 임시 API 명세서 -> 서비스 로직 구현 -> 컨트롤러 구현 -> 테스트 코드 작성 -> API 명세서 -> 리팩토링 순으로 일정 관리를 하였다.
- 일정 목표를 수립후 작업을 하니, 각 부분에서 어느정도 일정이 소요될 것인지 가늠할 수 있었고 그에 맞춰 대응할 수 있었다.
- 일정 목표에 따라 정확히 수행되지 않는 부분도 있었으나, 처음부터 조금 타이트하게 일정 목표를 수립 하였기에 초과되는 기한도 대응할 수 있었다.
- 일정 목표를 타이트하게 잡은 덕에 각 단계에서 집중도를 최대치로 끌어 올릴수 있었고, 부족한 부분도 체크를 하며 추후 TODO 사항으로 남기며 작업 할 수 있었다.
- 남은 시간에는 리팩토링 등 추가적으로 보완해야될 부분에 집중할 수 있었다.
개발 기술
- 학습을 하며 배운 내용들을 모두 적용하고자 하였다. 배운 내용만으로 부족한 부분은 새로운 기술을 적용하여 프로젝트를 마무리 하고 싶었다.
- 학습 내용 대부분 적용하였으며, 전체적으로 복습하는 기회가 되어 다음 프로젝트에 대한 자신감이 조금 더 생겼다.
- 전체적으로 복습하며 만들어 나간 프로젝트에서 나의 부족한 점을 찾을수 있었고 부족한 부분을 찾아가며 공부할 수 있는 기회가 되었다.

🧨 트러블 슈팅

✅ 하나의 Entity에서 다중 Eager Fatch Join 문제

1+N 쿼리 문제를 해결하기 위해 QueryDSL로 동적 쿼리를 작성하는 중에 발생한 문제로,
OneToMany, ManyToMany 인 Bag 두 개 이상을 EAGER로 Fatch 할때 발생한다.

Bag은 Set과 같이 순서가 없고, List와 같이 중복을 허용하는 자료 구조다.
자바에서는 Bag 자료구조가 없기 때문에 List를 Bag으로 사용하고 있다.
List 형태로 OneToMany 매핑을 한 필드들을 LinkedHashSet으로 변경 해 주면 Fatch Join을 문제 없이 사용할 수 있다.

✅ CORS 설정 문제

웹 개발을 하다보면 CORS 문제는 자주 만나게 된다.
초기 Security 설정에 CORS Origin을 '*' 와일드 카드로 모두 허용해 놓은 상태로 프론트 엔드 쪽에서 접근하려고 하니 문제가 발생 하였다.

브라우저는 모두 허용된 CORS Origin도 CORS 위반으로 받아 들여 문제가 발생 하였는데, 출처를 명확하게 설정 해 주어 해결되었다.

✅ Cascade Type 설정 문제

CascadeType 설정을 누락한 문제로, 초기 Entity 매핑시 CacadeType을 ALL로 설정 해 두고 다시 설정하는 것을 빼먹었다.
그 결과... 사용자가 등록한 질문 한건을 삭제하니 사용자 까지 삭제되며 사용자가 작성한 질문들과 답변들이 모두 삭제되는 현상을 발견했다.

CascadeType에 대해 다시 한번 더 학습하고, 영속성 전이가 필요없는 엔티티에는 DETACH로 설정하여 수정 하였다.

📌 Improve

서비스 로직 테스트 코드 미흡
- 서비스 로직 테스트 코드를 인증/비인증/예외의 경우로 나눠 모든 경우의 테스트 코드를 작성하고자 목표 하였지만, 리팩토링과 Rest Docs 작성을 하다 보니 시간이 부족하였다.
- 메인 프로젝트에서는 일정 관리에 조금더 신경써 꼭 모든 경우의 테스트 코드를 작성할 것이다.
- 프리 프로젝트에서 부족한 테스트 코드 부분은 추후 개인적으로 보완할 예정이다.
새로운 기술 접목 미흡
- Nginx Reverse Proxy를 적용하여 로드 밸런싱을 대응하려 하였다.
  - 배포 후 EC2 내부에서 Proxy Pass 까지 문제없이 진행 되었지만 Proxy 된 서버로 프론트에서 접근하니 CORS 문제가 발생하였다.
  - 해결하기 위해 Nginx Proxy를 다시 학습 해 보며 수정 해 보았지만 하고자 했던 BackLog를 처리 할 시간이 부족할 것 같아 해결하지 못하였다.
  - 프로젝트 마무리 후 수정 하며, Nginx conf 파일에서 proxy_pass와 proxy_set_header 부분이 Location 블럭 위치에 따라 적용 시점과 적용 방식이 달라지는것을 발견했고 정상적으로 적용 되는 것을 확인 하였다.
- Redis를 이용한 로그아웃 기능
  - Redis 메모리 DB를 적용하여 JWT Refresh Token을 관리 하고자 하였다.
  - Redis는 만료기한과 키,값 In-Memory NoSQL 저장소이며, 고성능으로 데이터에 접근 할 수있고 만료 기한 설정이 쉽게 가능하기에 프로젝트에 적용해 보고 싶었다.
  - 현재 프로젝트는, Refresh Token으로 Access Token을 재발급 받는 API를 생성 해 두었지만, 보안에 문제가 있다.
  - Token 들을 모두 클라이언트의 Local Storage 에서 보관하고 있으며, Access Token의 만료기한을 짧게 잡아 뒀다 한들, Refresh Token이 탈취되면 재 로그인을 할 수 있는 보안 문제가 발생한다.
  - 프로젝트 마무리 후 따로 Sample Project를 생성하여 Redis 동작 방식과 적용 방법에 대하여 학습 하였다.
  - 메인 프로젝트에서는 Redis를 활용하여 Refresh Token 관리 및 로그아웃 기능을 적용해 볼 것이다.
클린 코드 미흡과 기록 부재
- 중복 코드를 최대한 제거하고 리팩토링 하려고 노력하였지만, 생각보다 부족하게 마무리 한것 같아 아쉽다.
- 메인 프로젝트 때는 로직 구현 할때부터 조금더 신경 쓰며 작성 해야 겠다.
- 2주간 프로젝트하며 개발 일지를 작성하지 않아 찝찝한 느낌이다. 회고를 작성하면서 분명히 놓친 부분이 있을것 같은데 메인 프로젝트에서는 개발 단위로 일지를 작성하여 기록 관리에 신경을 써야겠다.

🎉 팀장으로서..

어찌 저찌 하다 팀장으로서 Pre-Project를 진행하게 되었다. 물론.. 팀장을 하고 싶었고 먼저 하겠다고 지원하였다....

프로젝트 시작 전 걱정 했지만, 팀원 간 소통이 너무 잘되고 다들 열정이 넘쳐 정말 수월하게 팀장 역할을 할 수 있었던것 같다.
사실, 팀장 역할이 필요 없을 정도로 서로간 의사 결정과 커뮤니케이션이 잘되었고, 분위기도 좋고, 개개인의 개발 능력도 갖추어 져 있었다.

백엔드 팀장과 프론트엔드 부팀장으로 나눠 활동 하였으며, 이 부분이 백엔드 프로젝트에 잘 집중 할 수 있도록 많은 도움이 되었던 것 같다.
한 팀으로서 협업을 하며, 정해진 시간 내에 프로젝트 결과물을 만들어 내기 위한 일정 관리를 어떻게 해야될지, 커뮤니케이션,협업 툴을 어떻게 활용하고 관리해야 될지 전체적인 흐름을 팀장으로서 느낄수 있어서 좋은 경험이 되었다.

마지막으로, 팀원 분들을 너무 잘만나 즐겁고 정말 만족스러운 프리 프로젝트 경험이 되었다. 다들 다시 만나 사이드 프로젝트를 할 수 있는 기회가 있었으면 좋겠다.

기회가 된다면 메인 프로젝트에서도 팀장을 하고싶다 -끝