다음으로 백엔드 기술을 소개하겠습니다.
기술 스택
개발 언어로는 자바 11을 사용하였고 Springboot로 WAS를 구축하였습니다.
빌드 도구로 Gradle(그레들)을 선택하였고 JPA(제이피에이)로 객체 지향 데이터 로직을 작성,
개발환경에서는 H2 Database(데이타베이스)를 배포 환경에서는 MySQL(마이에스큐엘) 사용하여 데이터 베이스를 구축하였습니다.
Spring Security 환경에서 JWT를 사용해 토큰 기반 인증/인가 기능을 구현하였습니다.
마지막으로 QueryDsl(쿼리디즐)을 사용하여 동적 쿼리로 필터 조회 API를 구현하였습니다.
ERD
다음은 저희 프로젝트의 데이터 베이스 테이블 관계를 표현한 EXID(위아래) 입니다. 매치, 팀 , 유저, 용병 게시글 중심으로 설계했습니다.
인프라 아키텍처
백엔드 인프라 아키텍처는 Github Actions에서 프로젝트 빌드 후 jar 파일을 압축해서 S3에 업로드하게 됩니다.
이어서 CodeDeploy에서 배포가 진향되고 EC2 인스턴스에서 이전에 S3에 업로드한 S3에 jar 파일을 받아 배포를 진행합니다.
클라이언트는 SSL이 적용된 NginX와 https로 요청과 응답을 주고 받게 됩니다.
GitFlow
다음은 백엔드의 Git Flow 전략입니다.
기능 개발은 develop에서 생성한 feature 브랜치에서 진행하였으며 개발한 기능들을 배포하기 위해 release 브랜치를 만들어 main 브랜치로 merge 했습니다.
급히 해결이 필요한 버그는 develop이 아닌 main 브랜치로부터 hotfix 브랜치를 생성, 수정 후 반영했습니다.
마지막으로 최종 배포는 main 브랜치에서 진행하였습니다.
컨벤션
Git Hook과 Husky를 적용하여 commit 컨벤션을 지킬 수 있도록 강제하였습니다.
Google 자바 코드 스타일을 기반으로 커스텀한 코드 스타일을 개발환경에 적용하여 개발하였고 최종적으로는 상호간의 코드 리뷰를 통해 코드의 통일성을 유지할 수 있도록 노력하였습니다.
API 문서화
설계와 기획 단계에서는 GitBook을 사용한 API 문서화를 진행하였습니다.
하지만 지속적으로 변경사항을 최신화 시켜야 한다는 점에서 비용이 발생하였고, 작성한 API가 코드와 불일치 하는 잔실수가 일어나기도 했습니다.
이후 이러한 단점을 해결하기 위해 구현 단계에서는 Swagger을 도입하였습니다.
Swagger를 통해서 API를 자동으로 문서화할 수 있었고, 최신화에 대한 비용과 실수로 인한 오해 없이 클라이언트와 소통할 수 있었습니다.
문서정리
프로젝트 진행에 있어서 공유해야할 공지나 회고록, 또는 기획,설계에서 나온 자료들은 노션을 사용하여 문서화하였습니다.
스프린트&스크럼
팀간의 소통도구로 지라와 칸반보드를 사용하여 스프린트 관리와 이슈 추적을 진행했습니다.
Jira를 처음 사용해보는 팀원들이 많았지만 쉽게 익숙해질 수 있었고 어렵지 않게 일정을 관리하고 이슈를 공유할 수 있었습니다.
스크럼은 오프닝 스크럼과 엔딩 스크럼으로 일 2회 진행하였고 주로 게더에서 진행하였습니다.
스프린트 진행의 변화
첫 스프린트를 시작하고 평일 오후 1시에 오프닝 스크럼, 밤 9시에 이슈 공유와 회고를 위한 엔딩 스크럼을 진행하였습니다.
총 2번의 스프린트 후 느꼈던 문제는, JIRA에 상세한 일정 공유가 이루어지지 않아 상호간 개발 진도 파악이 어렵다는 점과 스크럼 회의가 시간을 너무 많이 잡아먹어 기능 개발시간에 대한 부담이 생긴다는 점이었습니다. 가장 심각한 문제는 스프린트 내에 일처리를 하지 못해 다음 스프린트로 개발 일정이 밀린다는 점이었습니다.
이를 해결하기 위해 Jira 이슈 등록 시 소요시간을 설정하는 방법을 사용했습니다. 이를 통해 본인의 업무에 걸리시는 시간을 객관적으로 생각해볼 수 있었고 자세하게 이슈를 적음으로서 해야 할 일에 대한 책임감을 가질 수 있었습니다.
더 나아가 효율적인 소통과 협업을 위해 동일 도메인을 맡은 프론트 2명과 백엔드 1명이 페어를 형성하도록 하였고, 페어 단위로 일정을 공유하면서 개발을 하며 생기는 작은 이슈를 해결해나갈 수 있었습니다.
매일 진행하였던 스크럼 회의를 페어 단위의 소통을 통해 스프린트 마무리 회고로 대체 할 수 있었고 회고에서 직접 구현한 코드를 시연함으로써 현재 상황과 업무를 이해하는데 큰 도움이 되었습니다.
백엔드 느낀점
구현을 하다 보니 기획 단계에서 목표하였던 기능이 기간과 가능한 업무량에 비해 많아서 테스트 코드와 많은 엣지 케이스들을 해결하지 못하였던 부분이 아쉬웠습니다. 하지만 일정에 맞춰 목표로 하였던 필수 기능은 전부 구현하였다는 점과 프론트엔드분들과 협업하여 하나의 서비스를 만드는 경험을 할 수 있어서 좋았습니다.