[Project] 슬랙 봇 연동 게시판 프로젝트 - 세부 사항 및 DB설계와 API명세 작성

Intro

같이 프로젝트를 하는 팀원분이 잠시 바쁜 일이 있던 사이, AWS에 대해 간단히 공부하고 연결확인하는 것까지 해보았다.

이후에 바쁘신 일이 어느 정도 끝나게 되어 만나서 세부 사항을 결정하게 되었고, Erdcloud를 이용하여 DB를 설계하고, notion에 API명세를 작성을 진행하였다.

아래 글은 그 과정들을 적을 것이다.

---

프로젝트 세부 사항

• 메인페이지
• 로그인 : 일반 로그인, 42Seoul Oauth로그인
  • 이메일 찾기, 비밀번호 찾기
• 찾습니다 페이지
• 보관중입니다 페이지
• 검색 기능
  • 카테고리
  • 상태 : 보관중, 처리완료, 폐기(상태에 따라 보이거나 보이지 않음) / 폐기의 경우 글 등록 이후 일정 기간이 지나면 자동 변경(현재 30일 정도로 생각중)
  • 최신순, 이름순
  • 기간
• 계정 역할
  • Admin: 글 등록, 수정, 삭제 및 보관중인 물품 수령 시 처리완료
  • User: 모든 글 조회 / 찾습니다 페이지 글 등록, 수정, 삭제 가능
  • Guest: 글 조회만 가능
• 슬랙 메시지
  • Admin 계정이 보관중입니다에 글 게시 -> 자동으로 슬랙 채널에 메시지 전송 
  • 물품이 등록되면 유저가 등록한 키워드에 따라 자동으로 슬랙 DM으로 유저에게 메시지 전송
• 일정
  • 11/8 ~ 12/31(약 8주)

---

DB설계

• MEMBER 테이블
  • 일반로그인 시도 시에 Id 대신 email로 결정 : 기존에 42Seoul의 인트라 아이디를 Id로 사용을 하려 했음.
    
    • 생각되는 문제점 : 만약 내 42seoul 아이디가 abcd인데, 일반 회원이 abcd로 가입을 하면 어떻게 처리할 것인가?
    • 그렇다고 42Seoul 관련된 모든 계정을 파악하여 미리 예외처리를 해두는 것은 비효율적이라고 생각함
    • Email을 아이디로 사용하고, 회원가입 시에 이메일 인증 등을 구현하면 좋을 것이라고 의견을 나눔
  • Password 컬럼: DB에 저장시에 암호화하여 저장. 프론트 및 백엔드 2차 검증
    • 프론트에서만 검증을 하게 된다면, 웹 사이트가 아닌 postman등으로 요청을 날릴 때 처리할 수 없을 것이라 생각
  • Contract 컬럼: 010-0000-0000 에 해당하는 전화번호만 입력받게 할 예정
  • Oauth_id, Oauth_client: 일반 회원과 Oauth 가입 회원을 분리하기 위함.
    
    • 추후 Naver, Kakao, Google 등 Oauth를 확장하게 된다면 유용하게 쓰일듯함.
    • 일반 회원의 경우 null로 지정
  • role: GUEST, USER, ADMIN 3가지를 구분하기 위함
• BOARD 테이블
  • 보관중입니다 게시판과 찾습니다 게시판을 구분함에 있어서 2개의 테이블을 사용할 것인지, 1개의 테이블을 type으로 나눌 것인지 생각해보았음.
  • 겹치는 부분이 많기 때문에 1개의 테이블로 해도 큰 이상이 없을 것이라고 생각
    • 추후에, 1개의 테이블로 하였을 때의 처리 속도와, 2개의 테이블로 하였을 때의 처리 속도를 비교해볼 예정
  • image 컬럼: AWS S3를 이용할 예정이기 때문에, URL 방식으로 들어가게 될 것이라 예상(공부가 더 필요한 부분)
• CATEGORY 테이블
  • 유저가 등록할 수 없고, 직접 지정된 카테고리만 사용할 수 있게 할 예정
  • 이에 따라, 미리 DB에 데이터를 insert하는 작업이 필요함
• MEMBER_KEYWORD 테이블
  • 유저가 키워드로 등록한 카테고리에 관한 글이 등록될 시 자동으로 슬랙 메시지를 보낼 예정
  • 일반 회원의 경우 힘들 것이라 생각하고, 42Seoul Oauth유저의 경우에 한하여 작동될 것 같음
  • 테이블을 1개 더 사용하지 않고, 카테고리의 개수가 고정되어 있을 것이라 생각되기 때문에 MEMBER에 컬럼을 추가하여 비트마스킹 방법으로 해보는것은 어떠한지에 대한 의견을 나눔(등록된 키워드 자리 1 / 등록되지 않은 키워드 자리 0. ex: 100010...)
    • 신박한 방법이라고 생각했고, 핵심 기능들을 구현한 이후에 도전해보기로 함

사실, 글로 고민했던 부분들을 적고 나니 크게 어려워보이지 않는다. 프로젝트 세부 계획을 짤 때에는 이것저것 많이 필요할 것 같았는데 실제로 핵심 기능들만 구현했을 때는 MEMBER, BOARD, CATEGORY 3가지만 나오게 되어 추가로 KEYWORD라는 기능을 추가해보았다. 

---

API 명세서 작성

API 명세서에 관련된 내용은, 어떤 url에 request를 어떻게 보내고, response를 어떻게 줄 것인지에 대한 내용을 다루기 때문에 직접적으로 내용을 적지는 않을 예정이다. 하지만 2일에 걸쳐 작성을 진행하고 많은 고민을 했기 때문에, 어떠한 고민들을 했는지 여부를 적어보고자 한다.

1. 모든 delete 메소드의 경우 soft delete 메소드로 진행하고자 한다(MEMBER, BOARD)
   • 실제 게시판 서비스의 경우에도 삭제된 데이터의 경우에도 필요에 따라 사용할 일이 있을 것이라 생각하엿다.
   • 테이블의 deleted_dt를 기준으로 삭제된 데이터인지 아닌지에 대한 판별을 진행하려고 한다
2. jwt Token 방식을 이용할 것이다
   • jwt 토큰에는 어떠한 데이터들을 담아야 할까? (User의 Role을 담아도 되는걸까?)
   • access 토큰과 refresh 토큰을 구분하여 사용해보자
   • 요즘은 Secure Cookie라는 것을 이용해 보안상의 이점을 취하지만, 프론트에서 이를 열어볼 수 없다고 함
   • 그렇다면, 일반 GUEST 유저도 상세 게시글 조회는 가능해야 하는데 토큰을 가지고 있지 않다. 이 부분을 어떻게 처리할 수 있을까?
3. 유저 데이터 찾기와 변경은 다르다
   • 유저 데이터를 찾을 때에는 token값을 가지고 있지 않을 것이기 때문에 별도로 처리해야 함.
   • 변경의 경우 token을 기반으로 유저를 찾을 수 있을 것이다.
4. 여러 게시글 조회 기능(1개 X)
   • 조회 시에 단순히 모든 데이터를 가져오는 것이 아닌 검색 기능이 포함된 조회 기능으로 구현
   • 따라서 GET이 아닌 POST 방식을 사용.
   • 이점: request에 따라 검색을 해서 데이터를 줄 것인지 / 모든 데이터를 넘길 것인지 한번에 구분할 수 있어 편리할 것이라고 생각함
   • response를 보냄에 있어서, 검색된 글의 총 개수와 page 넘버도 같이 보내줌
5. Response의 경우 JSend 방식으로 작성하여 보내준다.

추가로 조금의 세부적인 내용들이 있지만, 큰 범주에서 고민했던 부분들을 적어보았다.

 

1프론트, 1백으로 프로젝트를 진행하는 것이 처음이고, Spring에 대해 능숙하게 다루지 못하는 것이 현재 내 상황이라고 생각한다.

일정 또한 8주라는 길다면 길지만 짧다면 짧은 기간동안 열심히 해볼 생각이기 때문에, 8주라는 기간이 지났을 때 성장한 내 모습이 조금씩 기대가 되기 시작했다.

이 다음 글부터는 본격적으로 작성된 코드를 토대로 분석(?), 리뷰(?), 고민에 대한 나만의 해결책 등을 하나씩 적어보도록 하겠다.