UMC 6th 데모데이가 끝난 지도 한참 됐지만 많은 일들이 있었어서... 😅 이제서야 정리해보려고 한다.
ERD 설계 (ERDCloud) & Entity 설계 (Spring Boot)
PM님께서 작성하신 서비스 정책서, IA와 디자이너님의 WF을 바탕으로 ERDCloud에서 ERD를 설계했다.
1. 서비스 정책서
기능 명세서라고도 부르며, 아래 사진처럼 프론트엔드와 백엔드가 개발을 진행할 때 필요한 정보들을 나열해 둔 것이다. 기능을 크게 분류해 두고 세부적인 기능들의 정의와 제약 조건, 기능들끼리의 연결(상호작용) 등의 정보를 작성해둬야 번거롭게 소통하지 않아도 개발을 효율적으로 진행할 수 있다.
2. WF(Wire Frame)
기능 구조도를 시각화해 서비스를 대략적으로 표현한 디자인의 프로토타입으로, 선(Wire)을 이용해 윤곽선(Frame)을 잡는 것을 의미한다. 피그마로 작업하기 때문에 디자인을 코드로도 바꾸기도 쉽고, 버튼과 페이지를 연결하는 등의 상호작용을 쉽게 나타낼 수 있어서 기능의 흐름도 볼 수 있기 때문에 개발을 진행할 때 WF를 가장 많이 참고했다.
3. IA(Information architecture)
서비스의 뼈대를 만들기 위해 작성하는 문서로, 사용자가 이용할 수 있는 기능들을 나열해 트리 형식으로 만드는 경우가 많다. 예를 들어 홈 화면에서 내비게이션 바에 있는 각각의 메인 기능들을 누르면 어떤 기능을 사용할 수 있는지와 그에 다른 선택지와 결과 등을 나타내면 기능의 흐름을 전체적으로 파악할 수 있다.
4. ERD 설계 (ERDCloud)
처음부터 꼼꼼하게 설계해두는 게 좋을 것 같아서 서비스 정책서와 WF를 보면서 이해가 안 되는 부분을 PM님께 질문드리면서 설계했는데, 20개쯤 넘게 질문드린 것 같다. 사소하게는 닉네임 글자수 제한부터 핵심 기능에 대한 추가 설명까지 부탁드렸다. UMC 서버 스터디에서 프로젝트를 진행할 땐 최대한 PM님을 괴롭히면서 하는 게 좋다고 배워서... 최선을 다했던 것 같다. 😅
초반엔 애플 소셜 로그인을 구현하기로 해서 소셜 로그인(애플) 테이블을 만들었지만, 런칭보단 데모데이 발표에 제대로 시연하는 걸 목표로 하게 됐고 로컬 로그인 방식을 사용하기로 했다. 우리끼리 시연해 볼 수만 있으면 되지만 최대한 런칭할 수 있는 방향으로 구현하고 싶어서 이메일(인증) + 비밀번호로 회원가입할 수 있게 테이블을 설계하기로 했다.
JWT에 대해선 잘 몰랐지만 구글에 찾아보니 이런 테이블이 필요하다고 해서 일단 만들어놨다. 근데 나중에 Redis에 저장하도록 바꾸게 돼서 테이블도 삭제했다.
백엔드에서 가장 초보인 두 명이서 설계한 거로 확신이 안 서서 나머지 팀원들한테 물어보면서 여러 번 검토하고 계속해서 수정했고, 최종적으로 설계한 결과는 아래 사진과 같다. ERD 설계도 버전을 기록해뒀으면 좋았을 것 같아서 조금 아쉽다. ERD는 기획이 바뀌면서 계속해서 수정하게 될 수밖에 없으니까 그렇게 크게 집중할 필요는 없다는 걸 알 수 있었다.
5. Entity 설계 (Spring Boot)
루베의 프로젝트 초기 세팅과 제아의 CI/CD 파이프라인 구축 등 기초 commit이 끝나고 앤드와 Entity를 나눠서 설계했다. 한 명이 다 하기엔 부담이 될까봐 Entity 간 연관관계는 나중에 설계하기로 하고 Entity (+Enum)를 4~5개씩 나눠서 작업하고 합친 뒤 그 위에 연관관계를 설계했다.
나중에 회원탈퇴 시 탈퇴 사유도 기록해두기로 해서 Withdrawer 테이블을 추가했다. 근데 다른 테이블과 연관관계도 없는 테이블이라 이걸 어떻게 하면 다른 테이블에 합치거나 할 수 있을지... 고민이다. 자세한 코드는 GitHub에서 확인할 수 있다.
API 명세서 작성 (Notion)
API 명세서도 서비스 정책서와 WF를 참고해서 노션에 작성했다.
1. Spring 노션 페이지
백엔드끼리 정한 일정이나 문서 등을 공유하기 위해 Spring 노션 페이지를 만들었다. 이후 개발 진행 상황을 공유하기 위해 프론트엔드분들도 같이 사용하게 됐다. 보안문서에는 Spring Boot 프로젝트의 환경변수 설정에 들어가는 것들을 넣어놨고, 에러코드엔 API마다 발생할 수 있는 에러들이 어떤 의미인지 더 자세히 적어놨다.
2. API 명세서 작성
API 명세서는 노션의 데이터베이스 기능을 이용해 만들었다. 앤드가 기존 프로젝트에서 썼던 템플릿을 가져와 그 위에 수정만 해서 사용할 수 있었다. 데이터베이스를 버전마다 기록하고 싶었는데 쉽지 않아서 날짜별로 변경사항이나 질문들을 추가로 적어놨다. 이런 기능은 프론트엔드 쪽에서 만드는 건지 백엔드의 역할인지와 URI 수정 등을 백엔드 팀원분들께 질문드렸던 것 같다.
최종적으로 완성한 API 명세서는 아래와 같다.
7.15(월) GitHub 컨벤션 정하기
UMC 스터디에서 배운 GitHub 관련 내용을 프로젝트에도 적용하기로 했다. Issues와 PR 모두 사용하기로 했고, 그에 맞춰 컨벤션을 정했다. 제목 형식은 commit할 때와 동일하다.
[타입] 간략한 설명
# 예시: [FEAT] 로그인 기능 구현
1. Labels
Issue와 PR을 등록할 때 쓸 라벨부터 설정해뒀다. 라벨을 통해 제목이나 설명을 읽지 않더라도 변경사항을 쉽게 파악할 수 있다.
2. Issue Template
Issue는 만들고자 하는 기능과 구현 내용, 예상 기간을 쓰도록 만들어놨다. Assignees에 본인으로 설정하고 적절한 라벨을 붙이면 된다. 개발이 끝난 Issue는 알아서 닫기로 했다.
3. PR(Pull Request) Template
PR엔 관련 이슈 번호(#으로 시작), 작업 내용, 리뷰 요구사항, 체크리스트로 채우기로 했다. #을 치면 이슈 번호가 쭉 뜨고 관련된 이슈 번호를 입력하면 이동할 수 있는 링크가 생긴다. 리뷰 요구사항은 궁금한 점이나 주의사항 등을 적기로 했다. 물론 쓸 말이 없다면 넘겨도 된다. PR 조건은 최소 2명이 승인해야 머지할 수 있도록 설정했다. 오른쪽 위에 Reviewers에 벡엔드 팀원을 모두 등록하면 메일로 알림이 가고, 본인을 제외한 2명이 Approve를 해야 머지할 수 있다. 사소한 오류를 고쳤거나 테스트까지 해봤고 문제가 없는 상황이라면 리뷰 없이 바로 머지하기로 했다.
4. Branch 전략
대충 크게 3가지로 나눠서 개발을 진행했다. 이슈에서 브랜치를 만들 경우 develop을 기반으로 만들도록 했고, API 테스트는 로컬이나 EC2의 swagger에서 진행하기로 했다.
| main | 실제 배포용 | 프로젝트 마무리 후 1.0.0 버전으로 develop에서 main으로 머지 |
| develop | 개발용 | 각각 feat에서 개발 후 승인을 받아 develop으로 머지 |
| feat | 기능 구현용 | 도메인으로 역할을 분배하고 이슈를 통해 각자 브랜치를 만들어 집중 개발 |
CI/CD 파이프라인은 develop에 머지된 경우 동작하도록 만들었고, feat 브랜치는 아래처럼 더 세부적으로 나눴다.
- feat/1-entity
- feat/2-member#1
- feat/2-member#2
