Photo Tag 개발기록 - 2

Photo Tag 데이터 베이스 구조 설계

우선 포토 태그의 동작 방식은 다음과 같습니다.

기존 모바일 기기의 사진이나 새로 촬영한 사진을 1장부터 최대 5장까지 고르고 메모를 작성합니다. 이때 메모에는 태그가 포함되는데 각각의 태그들은 하나의 카테고리처럼 작동합니다. 태그로 분류를 할 수 있고 태그와 메모 내용으로 검색도 가능합니다. 사진과 메모를 모두 합쳐 노트라는 개념으로 사용합니다.

이런 구성을 바탕으로 처음 설정한 ERD 구조는 다음과 같았습니다.

• user - note: 한 유저는 여러 개의 노트를 작성할 수 있습니다.
• note - photo: 하나의 노트는 여러 장의 사진을 가질 수 있습니다.
  • 사실 이때는 파일서버에 대한 이해가 명확하지 않아서 노트와 포토의 관계를 N:M으로 설정해 다음과 같은 ERD를 그려버렸습니다! 파일 서버에 올라간 포토를 다른 유저가 공유하거나 중복된 사진들은 하나만 사용할거라고 착각했던 것 같네요.😂
• note - tag: 하나의 노트는 여러 태그를 가질 수 있고 각각의 태그들은 여러 노트에서 쓰일 수 있습니다.
  • 태그는 다른 유저들끼리 공유가 되지 않는 쪽으로, 쉽게 말해 인스타그램에서 사용되는 것과는 달리 내 노트만 볼 수 있게끔 구성했으니 태그에도 유저의 정보를 담고 있어야 한다는 점 역시 나중에 깨달아서 위 구조에서는 놓쳐버렸습니다.

이대로는 안돼…!

위에 기술한 것처럼 초기 데이터 베이스 설계로 Mock api를 구현하다보니 이상한 점들을 포착하기 시작했습니다.

photo url을 관리하는 방법

사진 파일의 경우 S3로 파일 서버를 따로 두고 관리할 예정인데요. 처음엔 photo url을 별개의 테이블, 엔티티로 구분하는 것에도 고민이 많았습니다. 만약 사진을 한 장만 올릴 수 있는 구조였다면, 굳이 별개의 테이블로 나눌 필요 없지 않을까 싶었습니다. 그런데 현재 기획한 구조로는 사진을 1장부터 최대 5장까지 하나의 노트가 가질 수 있고 또 이렇게 장수가 변동적일거라면 따로 테이블을 두고 관리하는게 좋겠다는 생각이 들었습니다. 또 각각의 사진 파일들은 모두 개별적으로 노트와 관계를 맺게 될 것이기에 노트와 포토가 1:N으로, 그리고 사진을 통해서 노트의 작성자나 노트의 속성을 접근 할 이유가 없을 것으로 판단 되어 1:N 단방향 관계로 설정하기로 판단했습니다.

Photo Tag는 일기장 같은 곳

사실 포토 태그는 해시태그를 사용한다는 점에서, 또 사진들을 메인으로 기록한다는 점에서 인스타그램과 유사한 형태인데요. 그래서 자꾸만 여러 유저들의 노트가 한 화면에 공존한다고 착각을 하고 말았습니다. (물론 사실 추후에는 여러 유저들이 서로의 노트를 공유할 수 있는 공간을 만들고 싶다는 생각도 있었지만 그건 나중의 단계에서 고려할 내용이었어요.)

어쨌든 현재의 상황에서는 포토태그는 일기장처럼 작동합니다. 또 DB 구조 관점에서는 노트에서 유저를 조회하기 때문에 참조를 사용해서 연관관계를 조회하려고 합니다. 노트와 유저는 N:1 단방향 연관관계를 갖게되는 셈이죠.

가장 어려웠던 노트와…태그…

가장 오랜 시간 저를 괴롭혔던 고민 사항은 노트와 태그의 관계인데요. 이전에 클론코딩으로 구현했던 github의 issue tracker 프로젝트를 참고했습니다. 이슈와 라벨의 관계는, 한 이슈에는 여러 라벨들을 붙일 수 있고 각각의 라벨들은 여러 이슈에서 공용으로 붙여집니다. 이처럼 노트와 태그도 하나의 노트에 여러 태그가 붙고 각각의 태그들은 여러 노트에서 사용될 수 있어요. 다만 issue-tracker과 다른 점은 우선 태그는 홀로 생성되지 못합니다. 노트가 만들어질 때, 노트의 메모 속에서, 노트에 종속적으로 생성되죠. 그래서 처음에는 노트와 태그가 N:M, 풀어서 구현할 예정이니 노트와 중계테이블 1:N, 그리고 중계테이블과 태그가 N:1로 노트에서 태그로 이어지는 단방향 관계를 생각했습니다.

그런데 말입니다.

포토태그의 기능으로 태그의 카테고리화가 있었습니다. 태그로 노트를 조회해올 일들이 있더군요. 그렇다면 태그에서도 노트로 향하는 방향이 존재하지 않을까 하는 생각이 들었습니다. 물론 저의 DB설계, JPA에 대한 공부가 깊지 않기에, 이렇게 구현하는 과정이 DDD의 관점이나 JPA의 매핑전략과 상이한 해석을 낳은 것일지도 모릅니다.😂 그렇지만 기간은 정해져있고! 답은 모르겠으니 제 나름의 생각대로 구현하려고 합니다.

우여곡절 끝에 최종적으로 결정한 매핑 전략은 위와 같습니다.

홀로 고민들을 이어가면서…

사실 코드스쿼드 과정 중에서는 하나의 기획안을 가지고 여러 팀들이 각자만의 구현을 진행하곤 했습니다. 그렇다보니 모두가 프로젝트에 대한 이해도가 높았고 다같이 모여서 DB 구조에 대한 이야기를 한참이고 나눠보는 유익한 시간들이 많았어요. 또 모두가 묘한 상태로 오래 지속되면 마스터인 호눅스께 고민 요청도 하곤 했습니다. 그렇다보니 이렇게 홀로하는 고민은 시간적, 정신적 여유가 부족하게 느껴졌습니다. 그래도 다행인 것은 코드스쿼드 공간에 나가서 다른 멤버들에게 제 프로젝트를 설명할 수 있는 기회가 있었습니다. 동기사랑 나라사랑… 또 함께하는 팀원 레나도 저의 얘기에 귀기울여주며 본인의 의견을 전달하기도 했습니다! 아직 삐약이인 푸글은 이렇게 모두와 함께 한걸음 성장하는 걸까나요?🤓