[프로젝트/사이드] 0. 여행동행 서비스 개발 : ERD 1차 피드백 + 전체 회의

ERD 1차 피드백 

유저 & 프로필

✅ 유저 테이블 : 인증용 기본 정보 (간편 로그인에서 받아오는 이름, 이메일, 성별 등)

- 어떤 간편로그인인지, 소셜 타입 저장 필요

social_type ENUM('KAKAO', 'GOOGLE', 'NAVER') NOT NULL

 

📌 회원가입시, 소셜 타입은 달라도 이메일은 같을 수 있음

→ 이메일이 같다고 해서 같은 계정이라고 판단하면 안 됨

→ 이메일과 소셜 타입을 복합적으로 보고 계정 중복을 확인해야 함

 

 

- 소셜 타입별 기본 정보 제공 관련 내용 정리 필요

 

<네이버>

https://developers.naver.com/docs/login/profile/profile.md

네이버 회원 프로필 조회 API 명세 - LOGIN

 

https://developers.naver.com/docs/login/devguide/devguide.md

네이버 로그인 개발가이드 - LOGIN

 

 

 

<카카오>

https://developers.kakao.com/docs/latest/ko/kakaologin/rest-api#kakaologin

Kakao Developers

 

 

<구글>

https://cloud.google.com/identity-platform/docs/use-rest-api?hl=ko

REST API 사용  |  Identity Platform Documentation  |  Google Cloud

 

 

✅ 프로필 테이블 : 온보딩 과정에서 유저가 직접 작성하는 부가 정보 (MBTI, 여행 스타일, 자기소개 등)

** 유저 테이블과 프로필 테이블의 분리 관련 고민

 

유저테이블에 모든 데이터를 다 넣어버리면, 데이터를 조회할 때마다 매번 유저 테이블을 조회해야 하고 

 

 

---

유저 중심의 서비스와 프로필 중심의 서비스

유저 테이블과 다른 테이블 과의 연결이 너무 많아서 이와 관련해 생각을 해보다가 갑자기 공부하게 된 주제

 

흔히 사용자의 정보를 저장하는데 있어서 유저(멤버) 테이블과 프로필 테이블로 나눠 사용한다.

그렇다면 유저가 사용하는 기능을 위한 다른 테이블들과의 연관은 유저와 프로필 중에 어디와 시키는 것이 좋을까?

 

✅ 1. user 테이블과 연결

대부분의 기능이 사용자 계정 단위로 동작하는 경우
ex) 사진 업로드, 결제, 저장한 여행지, 분석 이력 등

 

✔️ 장점

외래키 관리가 간단하다 👉 모든 테이블의 userID 활용

대부분의 서비스에서 유저 단위로 로직이 구성됨

 

✔️ 단점

여러 프로필이 존재할 수 있는 구조일 때

EX) 다중(멀티) 프로필

 

 

✅ 2. profile 테이블과 연결

하나의 유저가 여러 프로필을 만들어 활동하고 이에 따른 설정, 콘텐츠가 구분되어야 하는 경우
ex) 페르소나 기반 AI 추천, 여러 개의 페르소나를 운영하는 SNS

 

프로필 중심의 서비스를 생각했을 때 바로 생각난 것이 넷플릭스.

하나의 계정에서 프로필을 선택할 수 있고 프로필별 시청 내역에 따라 추천 콘텐츠를 다르게 해서 보여준다.

 

출처 : 넷플릭스 페이스북

 

✔️ 장점

사용자 하나가 다양한 성향이나 목적을 가진 프로필을 만들고 쓸 수 있음

각 프로필에 맞는 데이터(추천, 분석 등)를 따로 저장할 수 있음

 

✔️ 단점

구현 난이도가 높다 👉 로그인 한 유저 중 어떤 프로필을 쓸지 선택해야 한다

모든 테이블이 profile_id 기준으로 바뀌기 때문에 로직 구조 변경이 크다

 

---

 

🔍 여행 동행 서비스의 경우

우리팀이 개발 중인 여행 동행 서비스의 경우, 사용자가 멀티프로필을 가지고 있지 않다. (1인 1프로필)

그리고 하나의 계정으로 활용하는 기능은 아래와 같이 단순하기에 user 테이블과 바로 연결하는 것이 단순하고 좋다.

• 소셜 로그인으로 가입
• 사용자 분석(여행 성향, MBTI 등)
• 사용자별 사진 업로드 및 분석 결과 저장

→ 만약 "프로필을 추가로 여러 개 만들 수 있다"가 확장 계획에 있다면 profile 기준으로 설계하는 것도 고민해볼 만하다고 한다. (하지만 그럴 계획 없음^^)

 

프로필 중심 개발은 다음기회에~

 

 

 

---

관계 테이블(relation table) 추가

유저가 다른 유저(또는 프로필)와 가지는 다양한 관계들을 relation_type 으로 구분해서 하나의 테이블에서 관리
(ex. 좋아요(팔로우): FOLLOW, 차단: BLOCK, 신고: REPORT 등)

✅ 테이블 구조

 

✅ 프로필 테이블과의 관계 설정

당한 대상 유저는 프로필 테이블과 외래키 연결을 해서 relation 테이블에 id 저장

 

프로필 테이블에 컬럼 추가

→ followed_count(나를 팔로우 하는 사람 수), blocked_count(나를 차단한 사람 수), reported_count(나를 신고한 사람 수)

→ 이 개수에 따라 블랙리스트에 올리거나 나중에 팔로우 수에 따라 인기 순위를 정하는 등 확장 기능 고려 가능

 

수정되 ERD

 

✅ 유저 테이블과의 관계 설정

팔로우나 신고나 차단을 한 사람은 유저 테이블 외래키로 relation 테이블에 id 저장

 

따로 유저테이블에 추가되는 컬럼은 없음

 

 

❓ 프로필 & 유저 테이블과의 관계 설정 이유

 

왜 둘 다 연결시켰는가?

 

 

 

---

 

🌍 사용자 위치 기반 커뮤니티 기능

커뮤니티 기능?

여행 관련 글을 올리고 댓글을 달면서 서로의 이야기를 공유할 수 있는 기능

위치 기반?

사용자의 현재 위치 기반으로 여행 커뮤니티 게시글을 필터링하며, 위치 정보는 위도/경도가 아닌 사람이 읽기 쉬운 주소 정보(예: 일본 후쿠오카시 하카타)로 표시함. 사용자는 위치 기반 ON/OFF 토글을 통해 기능 사용 여부를 설정할 수 있음.

 

👉  여행 관련 글이기 때문에 사용자 위치 관련 기능 구현이 중요하다고 생각하였음

 

🏹 디자인 레퍼런스

당근마켓의 동네 생활

 

 

---

 

관련 논의 사항

사용자 위치 기반 커뮤니티 글 조회를 위해 "위치 ON/OFF" 기능 구현 필요
이때 유저 실시간 위치 정보를 프론트-백 에서 어떻게 주고 받고 관리를 할 것인지

 

🅰️ 경우 1 - 백엔드에서 주소 변환

 

1) 프론트에서 위도+경도 를 백엔드에 전달, 백엔드에서 그 주소를 받아 저장

2) 지역 변환을 지켜서 다시 프론트엔드에 반환

🧭 프론트에서 위도+경도를 전달 ➝ 백엔드에서 주소 변환 ➝ 저장 및 프론트에 반환

 

📌 로직

 

1. 프론트에서 사용자 위치정보 (위도, 경도)와 위치 사용 여부 (is_location_enabled)를 백엔드로 전송
2. 백엔드에서 Reverse Geocoding API (예: Kakao, Naver, Google API 등)를 통해 주소 변환
3. 변환된 주소 텍스트와 위경도를 DB에 저장 (user_location)
4. 변환된 주소를 프론트로 반환 (커뮤니티 탭에서 표시용)

 

 

✅ 장점

 

• 주소 변환 로직 일원화 (백엔드에서 관리)
• 주소 형식 통일, API Key 보안 유지

 

⚠️ 단점

 

• 백엔드 부하 증가 (API 호출 집중)
• 실시간성이 중요한 경우 약간의 응답 지연 가능

 

 

 

 

---

 

 

🅱️ 경우 2 - 프론트에서 주소 변환

1) 프론트엔드 쪽에서 위도+경도를 받아서 지역 변환까지 진행

2) 위치 관련 모든 정보를 백엔드에 전달

🧭 프론트에서 위도+경도 수신 → 주소로 변환 → 백엔드에 모든 위치 정보 전달

📌 로직

1. 프론트에서 사용자 위치정보 수집 후, 자체적으로 Reverse Geocoding 수행 (웹 클라이언트 또는 앱 내)
2. 위도, 경도, 변환된 주소 텍스트, 위치 사용 여부를 백엔드에 전달
3. 백엔드는 전달받은 데이터만 저장

 

✅ 장점

• 백엔드 부하 감소
• 빠른 응답성
• 사용자 위치를 변환하기 위한 API 호출 비용을 클라이언트 측으로 분산

 

⚠️ 단점

• 클라이언트마다 주소 형식이 다를 수 있음 (불일치 발생 가능)
• API Key가 노출될 수 있음 (프론트에서 직접 호출 시)

 

---

 

< 비교 >

구분	관리 편의성	응답 속도	데이터 일관성	보안성
백엔드 처리	✅ 높음	⚠️ 다소 낮음	✅ 높음	✅ 높음
프론트 처리	⚠️ 낮음	✅ 빠름	⚠️ 낮음	⚠️ 낮음

 

 

<GPT 의 추천(?)>

🔐 최종 추천: 경우 1 (백엔드 변환)

• 주소 포맷의 통일성과 보안성 확보를 위해 백엔드에서 변환 및 저장을 수행하는 방식이 더 안전하고 일관됨.
• 단, API 호출 비용이나 지연이 문제되면 위치 요청 수를 줄이거나 캐싱 전략 적용 가능.

 

<회의 결론>

프론트엔드측 : API 를 여러번 호출하는 것이 시간도 많이 걸리고 백엔드 쪽에 부담을 줄 것 같아서 프론트에서 한번에 위경도+지역 주소 를 넘겨주겠다. 

 

나중에 문제가 생기거나 더 좋은 방안이 나오면 그 때 다시 논의를 해보자.

 

 

---

 

그 외의,,,

추가사항

- 북마크 테이블 추가

- 여행 동행 테이블에 댓글 작성 시간 컬럼 추가, 이미지 추가

- 리뷰 수정 불가능 하도록 수정

기타

- DB 테이블/컬럼 네이밍 형식 통일 : snake_case

- 소문자로 정리

- 매너온도 계산 관련 기준

 

---

전체 회의 내용

파트별 진행 사항 확인

- 디자인 와이어프레임 제작 사항을 중점적으로 확인

- 궁금한 로직 질문

- 테마 색상 공유

- 팀명

- 로고, 캐릭터

 

백엔드, 프론트엔드 질문 사항 공유

- ERD 확정을 위한 질문 사항

- 사용자 위치 관련 프론트와의 논의

 

https://developer.mozilla.org/ko/docs/Web/API/Geolocation_API/Using_the_Geolocation_API

Geolocation API 사용하기 - Web API | MDN

 

---

2차 피드백을 위한 정리

파트별 진행 사항 확인

디자인

- 감사인사 로직 질문

- 캐릭터, 로고 확인

- 디자인 진행 사항 확인

 

백엔드

- ERD 확정 ( 사용자 위치 관련 수정 )

- 백엔드 개발 환경 세팅 확인

- 백엔드 배포 준비

 

프론트엔드

- 프론트엔드 개발 환경 세팅 확인

 

다음 회의 - 미정

👉 다른 분들 시험 기간 끝나고 진행 예정