[Spring_4기 본캠프] Spring 심화 - 아웃소싱 프로젝트 | Day 57

[목차]

1. 프로젝트 발제

- 요구사항 가이드

2. 프로젝트 설계

- 컨벤션 정하기

- 프로젝트 컨셉, 구조, 흐름 정하기

3. 프로젝트 기록

- 프로젝트 타임 라인 -> 트러블 슈팅 

4. 최종 마무리 단계

- 시사점 도출

- 이번 프로젝트의 중점 잡기

1월 6일부터 새로운 심화 팀 프로젝트가 발제되었다. 그래도 전까진 프로젝트 진행을 하면서 개인적인 기록도 하고 TIL도 꾸준히 작성할 시간이 있었는데, 이번 프로젝트에는 팀장을 맡기도 했고, 내가 구현하게 된 사용자 인증/인가 부분에 대해 지식이 없는 상태로 기능을 구현해야 했던 터라 급하게 아무렇게나 모아놓았던 기록들을 정리해보고자 한다.

 

<개발 목표>

1. 데이터베이스와 ORM

- 데이터베이스 스키마를 설계할 수 있다.

- JPA를 이용해 데이터베이스와 연동할 수 있다.

- JPA를 통해 CRUD 작업을 할 수 있다.

2. AOP

- AOP를 사용해 횡단 관심사를 분리하고, 코드 중복을 줄일 수 있다.

- AOP의 어드바이스와 포인트컷을 정의해 비즈니스 로직을 확장할 수 있다.

3. 테스트코드

- JUnit과 Mockito를 사용해 단위 테스트를 작성할 수 있다.

- 테스트 코드에서 다양한 예외 상황을 시뮬레이션하고 처리할 수 있다.

4. 협업 밑 버전 관리

- Git을 사용해 소스 코드 버전 관리를 할 수 있다.

- Git Branch를 이용해 브랜치 관리 밑 원활한 협업을 할 수 있다.

- Pull Request와 코드 리뷰 과정에 대해 이해할 수 있다.

 

1. 프로젝트 발제 - 요구사항 가이드

<아웃소싱 프로젝트>

배달 어플리케이션 개발에 대한 아웃소싱 프로젝트를 맡았다고 가정합니다. 

클라이언트는 배달 시장에 새롭게 진출하려는 스타트업으로, 내부에 개발 인력이 부족한 상황에서 전체 개발 과정을 외주로 맡기기로 결정했습니다.

기한은 단 일주일 입니다! 빨리 개발하지 않으면 클라이언트에게 위약금을 물어주어야 합니다! 

 

<필수 구현 기능>

1. 회원 

- 회원 C

- 권한 부여 (UserRole)

- 로그인 

2. 가게

- 가게 CRUD

3. 메뉴

- 메뉴 CRUD

4. 주문 

- 주문 CRUD

5. 리뷰

- 리뷰 CRUD

2. 프로젝트 설계 

- 컨벤션 (깃 허브 규칙, 커밋 규칙, 코드 컨벤션)

- 프로젝트 컨셉

: "Delivering the World, Team Top Ten", 우리는 당신에게 세상을 배달합니다. 

- 필수 기능 구현에 초점을 맞추고, 협업의 장점을 최대한 끌어올려 소통 역량을 강화하는 프로젝트를 진행하도록 한다.

- 로그인 시 사장과 일반고객으로 로그인 해 각 권한에서 사용할 수 있는 기능을 달리한다.

- 엔드포인트를 RESTful 하게 만든다.

- 트러블 슈팅은 바로바로 기록해 밀리지 않도록 한다.

- commit, pr은 단위를 작게 해 코드리뷰에 지장이 없도록 한다.

- 해당 기술을 사용한 이유와 로직 결정 과정을 명확하게 하고, 근거를 꼭 생각하도록 한다.

 

3. 프로젝트 기록

 

4. 최종 마무리 단계

- 시사점 도출

 

기술적 지식이 부족한 내가 이번 프로젝트에서 팀장이 되면서 적어도 다른 부분에서는 최선과 최고를 가져가자 라는 생각으로 스스로를 매우 강하게 몰아붙이게 되었다. 게다가 한 번도 해보지 못한 JWT를 사용한 인증/인가를 구현하게 되면서 공부와 기능 구현을 동시에 하려니 익숙하지 않은 코드를 작성하게 되어 여러 문제가 발생하기도 했다. 하지만 이번 프로젝트에서 소통을 가장 중요한 목표로 가져간 만큼, 이런 부족함을 여과없이 드러내고 팀원들에게 공유하면서 내가 부족한 점이 무엇인지 확실하게 파악하고 내가 할 수 있는 것을 최대한으로 끌어올리는 방법을 알게 되었다. 

'부족하면 채우면 되지!' 라는 마음가짐 하나로, 이틀 밤을 꼴딱 새우고 팀원들을 이끌어 나가면서 정말 힘들기도 했지만 보람찬 프로젝트 주간을 보낸 것 같다. 

소통은 아무리 강조해도 모자라다. 기능 구현도, 기술적 문제도 결국 소통이 되지 않으면 하나의 프로젝트로 이어질 수 없다. 

팀에서 설정한 목표를 팀원 모두가 인지하고 같은 방향을 보고 나아갈 때 하나의 '팀프로젝트'로서 양질의 결과물이 나올 수 있다고 느꼈다.

일주일간의 작은 프로젝트였지만 최종 프로젝트와 다른 마음가짐으로 대충하다보면 결국 나중에 정말 중요한 프로젝트를 맡았을 때는 마음을 제대로 먹을 수 있을까? 아니라고 생각한다. 규모와 상관없이 실전 연습을 한다고 생각하고 팀으로 움직일 때의 장점을 최대한으로 뽑아가야 한다.

 

이번 프로젝트로 '협업' 이라는 것에 다시 한 번 생각해보게 되어 좋은 기회였다고 생각한다.

타이트한 일정, 예민한 피드백 등 힘들었을텐데 다양한 부분에서 도와준 팀원들에게 진심으로 감사를 전한다. 

 

KPT 회고

[Keep]

• 정확한 프로젝트 진행 스케줄을 잡고 이를 이행하기 위해 모두가 몰두한 점
• 의사결정을 할 때 서로가 생각하는 장단점을 공유하고 설득해 최선의 방식을 선택한 점
• 디렉토리 구조를 Domain Driven Design 으로 설계해 충돌을 줄인 점
• 자유롭게 질문하고 정성껏 답변하는 팀 분위기를 다같이 만들어 나간 점
• 브랜치를 나누고 팀원들의 버전을 똑같이 맞추어 충돌을 피한 점

[Problem]

• 기능 구현에만 급급해 로직을 왜 이렇게 작성해야 하는 지를 파악하지 못해 연쇄적인 문제를 발생시킨 점
• 단순히 에러난 부분에서 트러블 슈팅을 작성해 근본적인 문제에 도달하지 못한 점
• 테스트 코드 커버리지가 100% 나오지 않은 점
• 기능 개선에 대해 생각하지 못한 점

[Try]

• 다양한 기술 추가해보기
• 현재 로직의 성능을 파악하고 개선해보기
• 5분 기록보드를 생활화 해보기