[Postgresql]친구 관계 테이블 설계/aquerytool/프로젝트 적응기

INTRO

메타버스(unity) 프로젝트의 백엔드 개발자로 참여한지 한 달정도 되었다.

기존 팀에는 백엔드 개발을 전담하는 분이 없었고, 유니티 개발자 분들이 백엔드를 맡았었다. 

상대적으로 백엔드 부분에는 관심이 덜할 수 밖에 없었고, 팀에 들어오고 난 후 다른 개발자미처 신경쓰지 못한 부분들을 찾고,

보완하려고 했다. 

팀에 들어오고 난 후 내가 진행한 것들은 다음과 같다. 

 

• 리뷰
  • 테이블 설계, API 구성 확인
  • 어떤 방식으로 서버/DB를 사용하고 있는지 확인
  • 코드를 읽어보며 설계가 이해가 가지 않는 부분은 팀원들께 물어보기
• API 테스트
  • API 명세서에 작성되어있는 API들을 POSTMAN으로 테스트 해보았다
    • REQ(요청)에 맞는 RES(응답)가 올바르게 오는지
    • 응답코드는 올바르게 오는지
    • 작동하지 않는 API는 없는지
  • 확인하는 과정을 거쳤다.

 

이 과정에서 발견했던 이슈들은 다음과 같다.

• 팀 구성원을 조회하는 API가 존재하지 않음 => 개발 완료
• 유저의 관심 분야를 조회하는 API 테스트 시 모든 유저의 관심 분야를 출력하는 매우! CRITICAL한 에러 => 쿼리문 수정으로 해결 완료
• index 입력 시 범위에 벗어나는 index가 입력되는 문제 => 콤보박스를 이용하여 굳이 처리하지 않아도 될 것으로 결론
• user 테이블에 A컬럼이 존재하지만, 회원가입 시에도 A 컬럼을 입력하지 않고, A컬럼을 추가/수정하는 API가 존재하지 않음 => 회원가입에 A컬럼을 추가하는 res를 만들기로 논의 완료. 개발예정
• 응답코드(400, 500)이 통일되어있지 않음
  • Server에서 error시 주는 응답코드는 400으로만 넘기기로 통일.
  • 500번 응답코드는 서버 에러 응답코드로, api 실패 등의 문제로 주는 것이 아닌, 서버가 작동하지 않는 등의 에러를 처리하는 코드이므로 백엔드 측에서는 작성 X(프론트에서 처리)
  • 400번 응답코드와 함께 에러 메시지(에러 원인)도 함께 넘기도록 개발 완료(EX : 존재하지 않는 유저입니다.)
• 친구테이블 관련 
  • 친구 요청 시 : 요청을 보내면 바로 친구가 됨(수락, 거절 기능이 없음)
  • 요청 보낸 후 sender와 reveiver를 반대로 보내면 친구 테이블에 중복 추가 됨
  • 친구 취소 기능 : 보낸 사람만 친구를 보낼 수 있음

 

발견했던 대부분의 이슈는 해결을 했고, 가장 대공사(?)가 필요한 친구 테이블 관련 문제는 개발자+기획자 분들과 함께 의논한 결과 테이블 구조 자체를 바꾸는 것으로 논의가 되었다. 

 

따라서 이번 글에서는 기존의 테이블과 API가 어떤 구조를 가지고 있고, 나는 어떤 방식으로 테이블을 설계할 것인지에 관해 기술해보고자 한다. 

 

 

---

Friend
요청 보낸 유저 인덱스	sender_index	NOT NULL/INTEGER
요청 받은 유저 인덱스	receiver_index	NOT NULL/INTEGER

sender_index가 user테이블의 user_index를 참조하는 형태로 설계되었다. 

 

API 설계 방식은 다음과 같다

1. sender_index와 receiver_index가 존재하는 유저인지 확인하는 쿼리 진행 후 문제가 없으면 테이블에 (sender_index,receiver_index) 형태로 추가한다. 
2. 두 유저 A/B가 친구가 되는 방식은 (A, B) / (B, A) 형태의 데이터가 존재하면 둘은 친구가 된다.
   1. 수락/거절하는 API가 존재하는 대신, 서로 친구 요청을 보내면 친구가 되는 방식으로 구현이 된 것이다. 

내가 생각한 이 방식의 문제점은 

1. 전반적인 친구 관리가 어렵다
   
   1. A와 B가 친구 관계라는 것을 확인하기 위해서는 쿼리 문을 보내면 되지만, 친구 관계 확인을 하기 위해서는 (A,B), (B,A) 데이터가 모두 존재하는지 확인해야 하므로, 초기 설계는 간단할지라도 친구 수가 늘어날수록 매우 비효율적이다.
2.  더불어, 둘이 친구임을 확인하는 아직 API가 존재하지 않았기 때문에 이 방식을 고수할 이유가 없었고
3. 친구를 취소하는 기능을 구현하는 것 또한 복잡해진다

=> 이 문제를 해결하기 위해서 Status 테이블을 추가한다. 

 

• friend테이블의 index column(Auto Increment 속성 이용, PK)
  • 전체 친구의 index를 나타낸다
• sender/receiver 대신 유저인덱스/친구 인덱스를 사용한다. 
• 상태(status) 컬럼을 추가하여 친구 상태 관리를 더 편하게 한다
  • A가 B에게 요청을 보낸다 -> 상태 1
  • B가 A의 친구 요청을 수락한다 -> 상태 2로 변경
  • 만약 친구 관계를 끊는다면 상태2를 상태 1로 변경해주면 쉽게 관리할 수 있다. 

API 설계

• 친구 추가
  • A->B에게 친구를 요청을 보낼 때
  • 유저 인덱스 A / 친구 인덱스 B / 상태 인덱스 0(요청상태)
  • 유저 인덱스 B / 친구 인덱스 A / 상태 인덱스 1(대기상태)
• 친구 수락
  • B가 A의 친구 요청을 수락할 때
  • 유저 인덱스 A / 친구 인덱스 B / 상태 인덱스 2로 변경(친구 상태)
  • 유저 인덱스B / 친구 인덱스 A / 상태 인덱스 2로 변경(친구 상태)
• 친구 거절
  • 유저 인덱스 A / 친구 인덱스 B / 상태 인덱스 3로 변경(거절 상태)
  • 유저 인덱스B / 친구 인덱스 A / 상태 인덱스 3로 변경(친구 상태)
• 유저 A의 친구 리스트 조회
  • friend 테이블에서 상태 인덱스 2인 목록을 불러오는 쿼리 사용

SELECT index from Friend
WHERE user_index = A and status = 2

 

컬럼 하나를 추가하는 간단한 테이블 수정이지만 더욱 편리하게 친구 관계를 관리할 수 있다!

이제 설계를 기반으로 API를 개발한 후, 테스트 후 배포하면 된다. 

 

 

**AQUERY TOOL을 사용하면 테이블 생성 SQL을 자동으로 생성해줘서 아주 편리하게 테이블을 생성할 수 있다!

-- 테이블 생성 SQL - friend
CREATE TABLE friend
(
    index           int    GENERATED BY DEFAULT AS IDENTITY NOT NULL, 
    user_index      int    NOT NULL, 
    friend_index    int    NOT NULL, 
    status          int    NOT NULL, 
     PRIMARY KEY (index)
);

AQUERYTOOL이 내가 만든 테이블을 기반으로 써준 SQL문이다. 이걸 DB에 복사 후 붙여넣기 하면 friend table을 자동으로 생성해준다!

기존의 존재하는 프로젝트를 수정할 때 보다는, 처음 프로젝트를 생성할 때 사용하면 굉장히 편리하다!

 

 

 

OUTTRO

지금까지 내가 해왔던 프로젝트는 모두 내가 시작한 프로젝트였다. 내가 개발환경을 구축하고, 내가 코드를 작성하곤 했다.

 

기존에 존재하던 팀에 합류한 경험은 없었는데, 이번에는 6개월 이상 기존에 개발을 해오던 팀에 합류하게 되었다.

 

처음에는 팀의 분위기/개발 방법/의사소통 방법/회의 방법 등의 익숙해지는 과정이 필요했고,

새로운 환경에 적응하는 것은 늘 은근 스트레스를 유발하지만,

 

앞으로 나의 미래는

-내가 새로 조직을 만드는 경우가 많을 것인가

-내가 이미 존재하는 조직에 들어가서 적응하는 경우가 많을 것인가

생각해 보았을 때 당연히 후자가 많을 것이므로

질문을 적극적으로 하고, 팀원과 의사소통을 많이 하면서 잘 적응하려는 노력을 해야겠다고 생각했다. 

 

그리고 처음부터 내가 만들어나가는 프로젝트랑 비교해보면, 이미 존재하는 프로젝트를 보며 공부하는 것이 정말 배워가는 점이 많다. 내가 몰랐던 부분을 빨리 습득하게 되는 것 같다. 

 

내가 쓴 코드가 아닌, 남이 쓴 코드를 읽으면서 역시 팀 프로젝트를 할때는 주석!!을 친절하게 달아놓으면 정말 읽기 편하구나. 하는 생각을 했고, 나 역시도 친절하고 깔끔한 주석을 달아야겠다는 다짐을 하게 되었다. 

(잘 정리된 API 명세서도 포함.) 

 

내가 쓴 코드를 리뷰하다보면 약간은 관대해지기 마련인데, 다른 사람이 쓴 코드를 읽을 때는 왜인지 냉정해진다. 그러다보면 내 코드도 조금 더 예리하게 보게되는 듯 하다. 상호간의 코드리뷰의 중요성도 느끼게 되었다. 

 

웹과의 협업만 하다가 이번에는 웹/유니티(메타버스)와 협업을 하게 되었는데, 유니티와의 협업은 처음 해봐서 신기하다(필요한 response가 다르다던지). socket 통신도 아직 사용해본 적이 없어서 공부할 예정이다. 

나의 다음 미션도 socket 통신으로 채팅 구현하기이다!!

 

우리 팀이 이번에 예창패에 지원했는데 잘 됐으면 좋겠다 화이팅!