[개발자랑] ERD
2024년 8월 28일 쯤, 프로젝트를 시작했다.
8월 29일 주제를 선정했고
8월 30일부터 9월 3일까지는 MIRO를 통한 이벤트 스토밍,
9월 5일부터 9월 8일은 요구사항 명세서,
9월 10일부터 9월 12일은 ERD를 작성했다.
(수업 이외에 시간에 부담없이 조금씩 하다 보니 오래 걸린 것 같다.)
우리 팀이 정한 주제는
개발자를 위한 커뮤니티로, "개발자랑" 이라는 프로젝트명을 붙여주었다.
개발 + 자랑,
개발자 + 랑
두 가지 의미가 중의적으로 있는게 참 마음에 든다!
이 서비스의 가장 귀여운 점은
회원가입 시 성향테스트를 해서 나온 수식어와 희망 직무를 합쳐 별명(?)을 붙여준다는 점이다 ㅎㅎ
아래는 우리 팀에서 작성한 ERD이다.
연관관계를 쪼개고, 게시판도 여러개 있다보니 테이블이 내 기준 정말 많이 나오고
관계도 참 복잡하게 얽혀있어
연관관계 선도 참 복잡하다.
ERD를 작성하면서 마주했던 어려움이나 고민했던 지점, 피드백 받았던 지점 등에 대해 기록해보려 한다.
1. 장바구니와 굿즈
처음 내가 그린 ERD는 아래와 같다.
장바구니와 굿즈는 N:M의 관계를 갖기 때문에 중간 테이블을 만들어 줘야겠다고 생각해서
'장바구니굿즈' 라는 테이블을 만들어 줬었다.
'장바구니굿즈' 테이블은 장바구니에 담긴 굿즈라고 생각하면 되겠다.
그런데 그렇게 되면 장바구니에 '회원 코드' 컬럼만 있게 되는데, 이 테이블이 있는 것이 의미가 있는가 하는 생각이 들었다.
없애기에는 명시적으로 장바구니라는 게 필요할 것 같았는데...
피드백을 받을 때도 이 테이블에 대한 이야기가 나왔었다.
결국 테이블은 없애기로 했다.
왜냐, 장바구니는 회원 당 하나가 할당되고,
컬럼도 '회원 코드' 밖에 없기 때문에 테이블이 있을 의미가 없다는 것이다.
그래서 '장바구니' 테이블을 아예 없애고 '장바구니굿즈' 테이블을 회원과 연결해줬다.
(회원 코드대로 장바구니가 존재할 것이기 때문)
수정한 ERD는 아래와 같다.
2. 채용공고와 직무태그
우리 팀에 있는 도메인 중 하나가 채용공고로,
개발자 관련 채용공고를 올리는 게시판이다.
이 때 게시글을 올릴 때 '직무태그' 라는 것을 넣어주고 싶었다.
여기서 '직무태그'에 대해 잠깐 말하자면
채용공고에 이 공고가 어떤 직무인지(프론트엔드, 백엔드, 기획 등)를
표시해주는 태그인데,
스프레드 시트의 스마트칩이랑 비슷한 느낌인 것 같다.
일단 아래와 같이 채용공고에 필요한 컬럼들을 넣어줬는데
생각해보니 하나의 채용공고에 여러 직무가 올라올 경우 여러 직무태그 값이 들어가야 할텐데
그럴 경우엔 이 테이블 하나로는 우리가 의도한 바를 표현해내지 못할 것 같았다.
약간 ENUM인데 값이 여러 개 선택될 수 있는 그런 걸 원했는데 그런 기능을 찾지는 못했다.
그래서 아래와 같이 직무태그를 별도의 테이블로 만들어주고
채용공고와 직무태그도 N:M 관계이므로 중간 테이블로 '채용공고태그'를 만들어주었더니
의도한 느낌대로 ERD가 작성되었다.
3. 회원과 성향
우리 프로젝트에서 말하는 성향은
우선 회원가입 시 희무 직무(백엔드, 프론트엔드 등)를 선택하고
성향테스트(MBTI 테스트 느낌)를 통해 성향(꼼꼼한, 지적인 등)를 얻는데,
이 둘을 결합해서 '지적인 백엔드' 와 같은 게 탄생하는 것을 의미했다.
('성향'이라는 단어가 지금 두 가지에 모두 사용되고 있어 혼란이 올 수도 있겠다....)
우리는 단순히 성향 테이블을 하나만 만들고 회원과 연결시켜주었는데,
우리가 말하는 '성향' 에 대해 구체적으로 생각해보면
얘는 앞에 성향(접두어 같은 느낌?)과 직무가 합쳐져서 탄생한다.
그래서 단순히 '성향' 테이블 하나로 끝나는 게 아니라,
접두어 역할을 하는 '성향' 테이블과 '직무태그' 테이블이 필요하고,
이 둘이 합쳐져서 '수식어' 가 탄생한다고 생각되어야 하기 때문에
'수식어' 테이블도 필요하다.
따라서 처음에는 아래와 같이 작성한 ERD를
아래와 같이 수정해주었다.
'수식어' 테이블은 '회원' 테이블과 연결해서 한 회원이 하나의 수식어를 갖는 관계가 된다.
4. 배송
배송....
굿즈를 구매하는 기능이 있기 때문에 자연스럽게 배송에 대한 내용도 다루게 되었다.
아마 '스마트택배 API' 를 사용해볼 수 있을 것 같은데,
테스트를 해보려면 택배를 직접 보내봐야 할 것 같다....
그래서 실제 이용을 할 수 있을지는 모르겠지만 일단 ERD에는 넣어봤다.
사실 어떤 식으로 되어 있는지를 몰라서
테이블 컬럼을 적는 게 막막했는데,
우선 나중에 수정을 하더라도 일단 아래와 같이 작성해봤다.
처음에는 컬럼에 '현재 위치' 와 같은 택배 위치 추적 같은 컬럼도 넣었었는데,
(몇 시에 어디인지(ex. 곤지암 허브))
이런 건 우리가 다루는 게 아니라는 피드백을 받고 지웠다.
다시 생각해보니 진짜 우리가 다루는 게 아닌데 그땐 왜 넣었을까 하는 생각도 든다..
5. 게시글 테이블
우리 프로젝트에는 게시판 종류의 성격을 가진 게 4개가 있다.
프로젝트 자랑 게시판
팀모집 게시판
채용공고 게시판
커뮤니티 게시판
이 그 4개인데,
ERD를 구상하면서 나온 2가지 의견이
(1) 게시물 테이블 하나만 만들고, 어떤 게시판인지를 말해주는 컬럼을 넣어주자.
(2) 각 게시판 별로 4개의 테이블을 만들자.
였다.
먼저 게시물 테이블을 하나만 만들면
테이블의 구조가 단순해지고 관리가 용이한 장점이 있지만,
각 게시판 별로 특성이 조금씩 다른데
하나로 합쳐버리면 불필요한 필드가 계속 따라다니는 단점도 있고
한 테이블에 데이터가 많아질테니
성능에 영향을 미친다.
만약 게시판 별로 테이블을 따로 생성하게 되면
게시판마다 필요한 필드만 갖기 때문에 필드 최적화가 되고,
쿼리도 분리되기 때문에 성능적으로도 좋다.
하지만 관리가 복잡해지고, 댓글 등의 기능을 중복적으로 구현해야 할 수도 있다.
그 중 우리 팀은 두 번째 방식을 선택했다.
그 이유는 4가지 게시판의 특성이 꽤나 다르다고 판단했기 때문이다.
예를 들어 채용공고는 글을 작성한다 해서 바로 올라가는 것이 아니라
관리자한테 승인 요청을 해야하기 때문에
승인 여부, 등록 신청 날짜 등이 추가로 들어가고
수정이 불가능한 특징이 있고
프로젝트 자랑 게시글의 경우
url, 태그 등이 들어간다.
만약 이 4가지 테이블을 합치면 불필요한 컬럼이 꽤나 많이 생길 것이라고 판단해서 4개의 테이블로 쪼개게 되었다.
그런데 최근에 알게 된 방식으로는 두 가지 방법을 혼합(?)하는 방법도 있다.
기본적으로 게시글에 공통적으로 들어가는 필드를 담아 기본적인 게시글 구조를 하나로 만들고,
테이블 상속이나 JOIN을 통해
게시판 별로 세부적인 테이블을 만드는 것이다.
이번에는 ERD를 구상할 때 이런 방식을 생각해보지 못해서 택하지 못했지만
이 방식을 다음에 기회가 있다면 사용해볼 수 있을 것 같다.
게시판 말고도 결제 시스템(다양한 결제 수단), 상품 시스템(공통 속성-이름, 가격, 설명 등)에서도 사용할 수 있을 것 같다.
6. 쪽지
먼저 처음에 작성한 쪽지 테이블은 아래와 같다.
하나의 테이블을 이용 했는데,
이렇게 되면 수/발신과 관련한 문제(?)가 발생한다.
쪽지 읽음 여부는 사실 수신자에게만 필요한 컬럼이기 때문이다.
이거에 대한 해결으로는 '쪽지' 테이블 1개를
'수신 쪽지' 테이블과 '발신 쪽지' 테이블로 구분하고 1:1로 연결해줬다.
또 테이블을 나누면서 기존 쪽지 테이블을 구상할 때
삭제 여부를 빠뜨린 것도 확인해서 수신 쪽지와 발신 쪽지 모두에 삭제 상태도 넣어주었다.
기존의 '쪽지' 테이블에 있는 '차단 상태' 컬럼은
만약 사용자가 쪽지로 광고 등 이상한 쪽지를 보내는 등의 행위를 하면 그 사용자의 쪽지'만' 차단하는 거에 대한 것이어서
처음에는 쪽지 테이블에 넣어야겠다고 생각했다.
댓글 등 다른 도메인에서까지 그 회원을 차단하는 것이 아니니까.
그런데 차단 상태가 쪽지 테이블에 들어가는 게 맞냐고 하는 피드백을 받고 차단 테이블을 따로 빼주었다.
차단 테이블도 하나로 만들면 되겠지...
하고 생각했는데,
누가 누구를 차단했는지를 필요하다보니
테이블도 아래와 같이 나누어 주었다.
이렇게 해서 ERD 작업이 끝났다!
다음에는 아마 개발과 관련된 글을 가져올 것 같다!?