이전에 요구사항을 정리하는 회의를 가지고,
다음 회의까지 FE를 진행하는 친구는 화면 레이아웃, 나는 API 명세와 DB 테이블을 설계 해 오기로 하였다.
ERD 설계
요구사항을 보고 먼저 ERD를 만들기로 결정하였고, 1차적으로 만든 ERD는 다음과 같다.
만들면서 애매했던 부분이 많아서 검색을 통해 찾아보면서 작업했지만, 확신이 없는 부분도 많다.
개발 단계에서 구현해보면서 수정할 부분이 생각나면 바로 수정해야겠다.
1. 레시피 테이블에 있는 회원 ID fk
회원과 비회원 둘 다 레시피를 추천받을 수 있고, 회원의 경우 본인이 추천받은 레시피 목록을 조회할 수 있다. 따라서 레시피에 user_id 외래 키에 null을 허용하는 방식으로 구현했다.
2. 다대다 관계 테이블의 pk
회원, 레시피와 같은 다대다 관계에서는 관계 테이블을 만들고, 대리 키로 pk를 두어 auto_increment로 숫자가 올라가게끔 만들었었다.
이렇게 설계한 이유를 그 동안은 JPA에서의 개발 편의를 위해서 라고만 생각하고 마땅한 근거가 떠오르지 않았다. 따라서 이번에는 식별 관계의 복합 키를 pk로 설정해서 대리 키를 설정했을 때와의 개발 난이도 차이를 체감해볼 예정이다.
3. 채팅 내역 저장
추가적인 기능 구현으로 레시피를 추천받은 뒤 chatGPT와의 채팅 기능을 제공할 예정이다.
그 때 채팅 내역에 대한 기록이 저장되어 있어야 하는데, 어떻게 한 채팅으로 묶을 지 고민하다가
채팅내역을 레시피에 종속되게 만들면 그 레시피에 해당하는 채팅 내역이 남아있도록 만들 수 있을 것 같아 레시피와 채팅을 일대다 관계로 설정하였다.
4. 이미지 저장
이미지는 S3를 이용해서 업로드하고 관리하려고 한다. 이전에 부트캠프에서 진행했던 팀 프로젝트에서는 이미지를 자체 클라우드 서비스를 이용해서 업로드했었다. 따라서 이번에 S3를 처음 써보게 되었는데, 어떤 양식으로 테이블을 설계해야 할 지 몰라 일단은 이미지 url만 필드로 넣어놓았다.
현재는 댓글에 댓글 이미지 테이블로 만들어 놓았는데, 식재료에도 이미지가 필요해서 이미지 테이블을 따로 빼는 방법도 생각해봐야 할 것 같다.
피드백 사항
프론트엔드 친구에게 ERD를 보여주고 얻은 피드백 몇 가지가 있었다.
- 레시피 조회수 추가
- 식재료와 옵션에 카테고리 추가(육류, 한식 등)
컬럼 몇 개 추가하고, 식재료와 옵션에 각각 카테고리 테이블을 만들어서 일대다 관계로 설정하면 될 것 같다. 하지만 프로필 사진도 이미지를 업로드해서 관리하게 될 것이기 때문에 이미지 테이블을 따로 만들어서 관리하는 것이 좋을 것 같다는 생각이 들었다.
수정된 ERD
따라서 수정된 ERD는 다음과 같다.
이미지 테이블을 따로 분리하였고,
성별, 프로필 사진 등 누락했던 필드들을 추가하고
이미지 테이블 분리, 식재료 카테고리 테이블 추가 등의 작업을 진행했다.
이전에 교육을 받을 때는 애매한 부분이 생겼을 때 물어볼 멘토님이 있어도 잘 물어보지 않았었는데, 막상 교육이 끝나고 혼자 만들게 되니까 애매한 것들이 많고 물어볼 사람이 있으면 좋겠다는 생각이 들었다. 적극적으로 질문하는 태도가 얻어가는 것이 많다는 것을 다시 한번 느끼게 되었다. 따라서 이번 프로젝트에서는 더 확실하게 찾아보고 공부해서 확실한 근거를 가지고 설계하는 태도로 작성해야겠다.
API 명세
그동안 프로젝트를 경험했을 때는 API 명세가 계속 바뀌고, 관리도 제대로 이루어지지 않아 불편한 점이 많았었다.
따라서 이번엔 API 명세를 한번에 확실하게 정리하고 최소한의 수정으로 프로젝트를 진행하고 싶었다.
추후에 컨트롤러가 개발된 뒤에는 Swagger를 통해 관리하겠지만, 그 전에 설계 단계에서 어떻게 관리할 지 고민이 많았다.
저번 프로젝트에서는 따로 외부 툴을 이용하지 않고 Github Projects를 이용해서 Github 안에서 모든 것을 다 해결했었는데,
이번에는 Notion을 이용해서 체계화된 문서를 만들어보고자 했다.
찾아보니 API 명세서에 대해 깔끔한 템플릿도 있어서 해당 템플릿을 사용해서 진행했다.
(출처) https://puleugo.tistory.com/135
이번에는 회원 기능이 추가되기 때문에 접근 권한에 대해 확인이 필요 없는 경로는
/public/ 을 달아서 추후 Spring Security를 적용할 때 .permitAll() 처리를
용이하게 할 수 있도록 했다.
공통 응답 및 예외처리
프론트엔드 쪽에서의 개발 편의, 그리고 예외 케이스와 성공 케이스를 공통적인 포맷으로 반환하기 위해 공통 응답을 만들었다.
기존에 진행했던 프로젝트에서 사용한 방식이 마음에 들었기에 그대로 사용했다.
{
"header": {
"isSuccessful": true,
"resultCode": 0,
"resultMessage": ""
},
"result": {
"id": "{id}"
}
}header에는 응답 성공 여부, 응답 코드와 메시지가 들어가고, 반환할 데이터가 있다면
result 에 담아서 반환하는 방식이다.
이전 프로젝트에서는 ResponseEntity로 감싸지 않고 그대로 반환하여
예외 응답과 성공 응답 모두 200 OK로 반환했었는데,
이번에는 HTTP Status Code에 대해 학습을 하고자 ResponseEntity로 감싸서 상황에 맞는 코드로 응답하도록 했다.
우선적으로 정리한 코드는 다음과 같다.
Status Code
- 200: 성공
- 400: 사용자 입력 오류
- 401: 인증되지 않은 요청인 경우
- 403: 권한이 없는 경우
- 404: 존재하지 않는 데이터를 요청하는 경우
- 409: 중복 데이터 생성 요청의 경우
- 415: Content-Type 이 맞지 않는 경우
- 500: 서버에서 에러가 발생한 경우
결론
이렇게 초기 ERD와 API 설계를 마쳤다. 오랜만에 하는 작업이고, 또 혼자 처음부터 끝까지 다 해본 것은 처음이기 때문에 맞게 했는지에 대한 확신도 없고 좋은 설계인지 잘 모르겠지만,
내가 주도적으로 만든 결과물이라는 것에 의의를 두어야겠다.
이 다음에는 EC2와 RDS 인스턴스 생성, Docker를 이용한 배포 및 Github Actions를 이용한 CI/CD 작업을 하려고 한다.
기존에는 EC2 인스턴스에 java를 설치해서 jar 파일을 실행시키는 방식으로 구현했었는데, Docker를 사용하면 어떤 차이가 있는지 공부하고 적용해봐야겠다.
