[패스트캠퍼스 X 야놀자: 백엔드 개발 부트캠프] Spring Boot 기반 토이 프로젝트 후기

정의정·2023년 11월 1일

FC

목록 보기

4/6

나는 2023. 07. 10 ~ 2024. 01. 30 기간동안 내일배움카드로 수강하는 국비지원교육 중 K-digital training(패스트캠퍼스 X 야놀자: 백엔드 개발 부트캠프 4기)에 참여하고 있다.

💡 토이 프로젝트 2

토이 프로젝트는 총 세 단계로 진행된다.
1 단계 : 09. 04 ~ 09. 10
2 단계 : 10. 23 ~ 10. 29
3 단계 : 11. 13 ~ 11. 19

지난 주 10. 23 ~ 10. 29 토이 프로젝트 2단계를 진행했다.
이번 토이 프로젝트를 어떻게 진행했고, 어떤 어려움이 있었는지 후기를 남겨보려고 한다.

🌟 Spring Boot 기반 토이 프로젝트

이번 토이 프로젝트는 Spring Boot를 기반으로 여행 여정을 기록하고 관리하는 SNS 서비스를 개발하는 프로젝트였다.
지난 1단계 토이 프로젝트와 같은 팀원들과 진행하였고, 이번에도 조장으로 활동하여 프로젝트를 총괄하며 회의 및 개발을 수행했다.

요구사항 분석🧐

개별 여행은 여러 여정 정보로 구성됩니다. (여행 : 여정 = 1:n)
여행 정보에는 다음 정보가 필수 항목으로 포함되어야 합니다.
여행의 이름, 일정(출발 날짜, 도착 날짜), 국내/외 여부
여정 정보에는 다음 항목으로 분류됩니다.
- 이동 (이동 수단, 출발지(장소명), 도착지(장소명), 출발 일시, 도착 일시)
- 숙박 (숙소명, 체크인 일시, 체크아웃 일시)
- 체류 (장소명, 도착 일시, 출발 일시)

기능 명세서 작성✏️

RFP와 지난 프로젝트 기능 명세서를 참고하며 작성했다.

API 설계와 역할 분담👥

기능명세서에서 확인할 수 있듯 각 기능을 누가 구현할 것인지는 회의를 통해 정했다.

※ 처음 기획 단계에서 작성한 문서가 아닌 이후 수정된 문서입니다.

나는 아래 기능 구현을 맡았다.

전체 여행 조회

특정 여행 조회

여행 수정

CI 구축

Spring REST Docs 도입

프로젝트 진행 중 추가적으로 몇 가지 공통 기능을 구현했다.

Global Exception Handling

일시 Formatter

LocalDate, LocalDateTime 타입을 String 타입으로 변환하는 기능

그리고...
프로젝트 중 개인 사정으로 인해 맡은 기능 구현을 하지 못한 팀원이 있어, 이를 커버하기 위해 추가적으로 다음 기능을 추가적으로 구현했다.

여정 기록

여정 수정

프로젝트 일정📅

프로젝트 일정은 아래 이미지와 같이 수행되었다.

DB 설계 (ERD + Class Diagram)💾

DB를 설계함에 있어서 정규화와 JPA 매핑에 관련해 고민이 많았는데, 자세한 내용은 따로 포스팅했다. 여기에서 확인 가능하다.
고민 끝에 JPA 상속 관계 매핑에 SINGLE TABLE 전략을 사용했다.

DB 테이블은 다음과 같은 모습을 띈다.

그리고 자바 객체(Entity)의 모습은 아래와 같다.

패키지 구조 설계📁

DDD(Domain Drivn Design)과 MVC구조를 살려 패키지를 설계했다.

main
	├── java
	│   │   
	│   ├── docs/asciidoc
	│   │   
	│   ├── domain
	│   │   ├── trip
	│   │   │   ├── controller
	│   │   │   ├── dto
	│   │   │   ├── entity
	│   │   │   ├── Repository
	│   │   │   ├── exception
	│   │   │   └── service
	│   │   │ 
	│   │   └── itinerary
	│   │       ├── controller
	│   │       ├── dto
	│   │       ├── entity
	│   │       ├── exception
	│   │       ├── Repository
	│   │       ├── exception
	│   │       └── service
	│   │   
	│   ├── global
	│   │    ├── dto
	│   │    ├── exception
	│   │    └── util
	│   │ 
    │   └── ToyProject2Appplication 
	│
	└── resources
	    └── applicion.yaml
			└── applicion-secret.yaml

API 문서(Spring REST Docs)📜

API는 Spring REST Docs를 도입하여 문서화 했다.
관련 포스팅에서 Spring REST Docs를 어떻게 설정하고 도입했는지 자세히 살펴볼 수 있다.
테스트 후 빌드 및 실행하면 http://localhost:8080/docs/index.html를 통해 API 문서 인덱스를 확인할 수 있고, 여행을 선택하면 아래처럼 API 문서를 성공적으로 확인할 수 있다.

다른 API들도 궁금하다면 여기에서 전체 API 문서를 확인할 수 있다.

어려움과 극복🤯

이번 프로젝트를 진행하면서 무엇이 어려웠고 이를 어떻게 극복했는지 기록하려고 한다.

1. DB 설계를 수정해야 했다.

Trouble

DB를 설계하며 JPA 상속 관계 매핑 전략으로 JOINED 전략을 가져갔는데, JPA N+1 문제가 발생했다.

Solution

다른 매핑 전략들과 N+1 문제의 해결 방안을 찾아봤다. 하지만 해결 방안으로 찾은 fetch join 방법도 추가로 N번의 조인이 이뤄지는 문제가 있었다.

프로젝트의 규모가 작고 확장 가능성이 낮은 점을 고려하여 SINGLE TABLE 전략을 선택하여 수정하였다.

관련 포스팅: 링크

2. 프로젝트가 주말까지 이어졌다.

Trouble

팀원 중 한 분이 기존에 계획한 기능 구현 마감일인 목요일을 넘기셨고, 마감일을 두 차례 늘려드렸으나 결국 토요일까지 구현을 못하셨다. 도움을 드리고 싶어도 연락이 잘 되지 않았고, 약속한 시간에 PR을 올리시지 않아서 상황을 파악하기도 힘들었다.

Solution

정해진 기한 내에 프로젝트를 마무리하고, 제출을 해야 하는 상황이 었기 때문에 회의를 한 후 내가 해당 팀원이 담당했던 기능을 구현했다. 시간이 얼마 없었기 때문에 새벽까지 개발을 해야만 했다. 해당 팀원 분은 사과와 함께 추후 발표 자료를 만들겠다고 하셨고, 다음 프로젝트에서는 좀 더 적극적으로 소통해주시겠다는 약속을 해주시면서 마무리 되었다.

잘한 점👍

프로젝트를 진행하며 잘했고, 앞으로도 적용할 부분을 정리해봤다.

Git Flow 브랜치 전략을 사용하여, 효과적으로 브랜치를 운용할 수 있었다.

GitHub Action을 통한 CI 도입으로, develop 브랜치를 안정적으로 유지할 수 있었다.

Spring REST Docs를 도입하여, API를 문서화했다. 테스트 코드 기반이기 때문에 실제 API 설계에 맞게 구현되었는지, 잘 작동하는지 확인할 수 있어 좋았던 것 같다.

회의 시간과 회의 안건, 개발 일정을 미리 계획하여, 효과적으로 회의를 진행할 수 있었다.
오후 2시, 오후 5시에 매일 회의를 진행하였고, 이후 더 회의가 필요한 경우에만 추가적인 회의를 진행했다. 이를 통해 개발할 시간을 좀 더 확보할 수 있었다.

🎀 느낀 점

이번 프로젝트에서도 협업에 있어서 몇 가지 어려움이 있었는데, 팀장으로서 커뮤니케이션에 좀 더 신경을 써야겠다는 생각이 들었다.

다음 프로젝트에서는 Security, JWT 등 다양한 기술들을 적용한 개발이 요구되는데, 역할 분배를 신중하게 해야할 것 같다.

프로젝트 종료 후 프로젝트 발표회를 통해 다른 팀들이 어떻게 프로젝트를 진행했는지, 어떤 어려움이 있었고 어떻게 해결했는지 들을 기회가 있었는데, 다양한 관점과 문제 해결 방법, 기술들을 알 수 있어서 유익했던 것 같다.

다음 토이 프로젝트는 마지막 토이 프로젝트로서 또 새로운 기술들을 여럿 사용하게 되어 기대가 많이 된다.

지금까지 1, 2단계 토이 프로젝트가 마지막 토이 프로젝트를 위한 빌드업이었다고 생각하고 지금까지 파악한 개선 사항들을 적용해봐야겠다.