Day22. G마켓에서 신규서비스 기획하기 - 꿀템피드 테이블 설계

안녕하세요, 기획자 팥씨입니다. 🥮

지난 5월, G마켓과 옥션이 진행한 '빅스마일데이'에서 '꿀템 피드' 기능이 실적을 이끌었다고 하는데요 O.O

 

'꿀템 피드' 설명과 함께, 기술블로그에서 다뤄주신 내용을 통해 그 뒷이야기도 알아보려 합니다.

 

0. 꿀템 피드?

• 고객이 직접 구매한 상품을 G마켓 전체 고객에게 소개하는 공간
• 꿀템 피드 추천글을 보고 다른 고객이 해당 제품을 구매할 경우 결제가의 1%를 스마일 캐시로 지급
  • -> 알뜰 쇼핑족들 사이 입소문
• 행사 기간 꿀템 피드에 올라온 추천 글은 총 7700건 (매일 500명 이상 추천 글)
• 실제 구매자가 작성한 후기를 확인하고 상품 추천 기능도 수행
• 실제 꿀템 피드를 읽고 추가 구매로 이어지는 비중 49%
• 빅스마일데이 행사 페이지는 시간당 PV 높아 '고단가 광고'영역
  • 과감하게 페이지 한 바닥을 고객이 직접 채우도록 함으로써, 도전적인 시도가 고객간 쌍방향 소통으로 이어져 큰 호응
• 앞으로도 꾸준히 선보이며 구매 과정 단축하고 정렬방법 개선할 것

@G마켓 꿀템 피드 프로모션 페이지

 

🥮 개인의 추천 상품을 구매하면 적립을 해주는 서비스 자체는 쿠팡 파트너스 등으로 낯선 개념은 아니지만,

이를 프로모션 기간동안 고객이 '즐길거리'로 제공해주었다는 점이 매우 흥미로웠습니다.

 

1. 꿀템 피드의 시작 - 챗 GBT

@ 지마켓 기술블로그

 

위 이미지는 챗 GBT (Gmarket Best iTem)으로, 지마켓 임직원분들이 직접 추천하는 상품을 모아둔 페이지였다고 합니다.

고객도 이처럼 자신의 꿀템 게시글을 작성할 수 있다면? 사이트에서 놀 수 있는 공간을 마련하자는 것이 꿀템 피드의 시작이었습니다.

 

2. 지속 가능한 개발을 위해 고려할 것

개발 비용이 너무 많이 소모되지 않으면서 꾸준히 디벨롭하고 개선할 수 있는, '지속 가능한 개발'을 목표로 했습니다.

이를 위해서는 확장성을 고려한 설계가 필요했는데요.

 

2024.05.22 - [[기획자 시선]] - Day12. 딜라이트룸에서 DB 기획하기 (삽질 덜 하기)

Day12. 딜라이트룸에서 DB 기획하기 (삽질 덜 하기)

🥮 지난 5월 작성한 글이 떠올랐습니다.

딜라이트룸에서 소개해주셨던 데이터베이스를 설계할 때 고려할 점입니다.

1. 제품의 [로드맵] 확인하기
2. [극단적]인 상황을 상상해보기
3. 제품이 사용되는 [플랫폼] 확인하기

지마켓 꿀템피드에서도, 추후 로드맵과 확장성을 고려하여 테이블을 설계한 것을 확인할 수 있었습니다.

 

2-1. 네이밍하기

저도 개발자가 가장 어려워하는 것은 코드 치는 것도 아닌 이름 붙이기라는 밈(?)을 몇차례 접했었는데요,

실제로 이름을 짓는 행위는 단순히 부르기 위한 목적보다 더 큰 의미가 있다고 합니다.

이를 위한 최소 요구사항은 아래와 같습니다.

 

1. 이름만 듣고도 직관적으로 만드는 의도를 이해하는 데 도움이 되어야 하며
2. 구현하고자 하는 개념을 포괄할 수 있어야 하며
3. 기존 개념과 헷갈리지 않도록 사내에서 사용되지 않는 단어를 선택해야 한다. 

이에, 고객이 지마켓 서비스에서 '즐긴다'는 것 착안해 '놀이기구' 개념을 사용했습니다.

(🥮 : 이 놀이기구 개념을 데려온 것이, 꿀템 추천 - 구매 로직과 정말 잘 들어맞는다고 생각했습니다👍)

 

네이밍	기본 개념	꿀템 피드에서의 개념
Attraction	- 놀이공원의 놀이기구 - 즐길거리, 명소 - 상업 시설 내 차별화를 두는 장소 (코엑스 별마당 도서관 등)	- 게시글을 포스팅할 수 있는 빈 보드
Ride	- 탈 것 - Attraction의 하위에 존재	- 등록, 수정이 가능한 컨텐츠** - Attraction의 하위에 존재 - Ride의 퀄리티에 따라 이 서비스의 흥행이 정해질것으로 예상
Passenger	- 탑승객	- Ride를 업로드할 수 있는 사람 - 지마켓, 옥션 회원, 셀러 고객, 임직원일 수도 있음

 

어트랙션이라는 개념 아래 하위 개념을 하나하나 정하다보니 자연스레 이 프로젝트의 이름은 지마켓의 놀이공원, 

G-world가 되었다고 합니다.👀

 

@지마켓 기술블로그 - 하위 속성 정의

 

2-2. 추가 요구조건 선정하기

 

해당 페이지를 어디에 노출할지, 어떤 속성이 필요한지 등 고민이 필요했습니다.

 

[Attraction의 추가 요구 조건]

• 임직원, 고객 모두 업로드 할 수 있음
• Linkrew와의 연동이 필요
  • Linkrew는 누구나 상품 링크를 공유해 수익을 셰어받는 지마켓의 신규 제휴 서비스

[Ride의 3가지 형태]

1. 구매 내역에서 불러오기
2. 구매 내역 없이 단순히 상품 추천하기
3. 임직원이 추천하기

[Ride의 리뷰 신뢰도를 높일 수 있는 방안]

• 리뷰 신뢰도 높이기 - 구매 기록에 기반한 태그 (첫 구매시기, 재구매 횟수 표시)
• 승객이 직접 해시태그 추가
• 해시태그 필터링
• 좋아요 표시 -> 인기 Ride에 대한 리스팅 기능
• Ride의 상품 카테고리 통해 특정 기획전 콘셉트에 맞는 / 유저가 원하는 상품의 Ride를 모아보는 필터링 기능
• 커뮤니티 기능 - 댓글

[Ride 콘텐츠 퀄리티를 높이고 활발하게 하기 위해]

• 이용약관 동의 위한 동선
• 동일 상품의 Ride가 올라올 시 취합하여 조회
• 콘텐츠 승인 대신 선 게시 후 모니터링 필요
• 신고 기능 개발

 

2-3. 목표설정 : PoC 개발

• PoC = Proof of Concpet = 개념 증명 = 기존 시장에 없던 신기술이나 개념을 도입하기 전 이를 검증하기 위한 과정
• 주요 목표 : 아이디어나 기술의 실행 가능성과 유효성 입증
• 실제 제품 / 서비스의 개발 전 단계로, 초기 투자를 최소화하고 잠재적인 위험을 줄이기 위해 사용

 

3. 테이블 설계

3-1. 어떤 DBMS를 선택해야 하는가?

요구조건

- 저장할 데이터 양이 많지 않으면서

- PoC 끝나고 데이터 사용성 고려했을 때 정합성이 가장 중요

- 성능과 안전성을 고려하면 Oracle 사용이 최선 !

 

참고) 데이터의 무결성과 정합성

*데이터 정합성 Consistency = 데이터의 올바른 유무와 상관없이 데이터들의 값이 서로 일치하는 상태

<무결성 훼손 예시>
주문정보 테이블에서 고객번호가 모두 -1으로 입력되어 있고,
고객정보 테이블에도 -1의 값을 갖는 고객이 존재한다. (데이터의 값이 일치한다.)
그러나 고객번호는 반드시 1 이상의 값을 가져야 한다. (데이터의 값이 정확하지 않다.)

이런 상황에는 데이터 정합성은 이상이 없으나, 데이터 무결성은 훼손되었다고 볼 수 있다.

<정합성 훼손 예시>
위 예시에서 주문정보 테이블의 고객번호를 -1에서 2로 변경했지만, 고객정보 테이블에는 고객번호가 변경되지 않았을 때, (데이터의 값이 서로 일치하지 않는다.)
데이터 정합성이 훼손되었다고 볼 수 있다.

 

3-2. ATTRACTION 테이블 설계

- ATTRACTION, RIDE, PASSENGER로 정해졌지만 축약형 필요 -> Attr 등

- 등록 전 사내 메타 데이터 관리 세트에서, 기존 개념과 헷갈리지 않는지 확인

- 확인 결과, Attr는 '속성'을 뜻하는 Attribute의 축약형과 동일 -> ATRC로 수정

- 그 외 Ride는 그대로, Passenger는 항공업계 공식 약어인 PAX 사용

 

@지마켓 기술블로그 - 완성된 어트랙션 테이블

 

• 논리적인 칼럼명은 한글 표기
• 물리적인 칼럼명은 영문 표기
• Data Type - 보편적인 타입 선언
• Length - 해당 칼럼의 길이를 러프하게 정하고
• Null 여부
• Default 초기값 설정
• Example 예시 추가

[추가로 고려한 것]

• 테이블에 콘텐츠의 생성, 조회 권한 칼럼
• 추후 유니버스 클럽 고객만을 위한 Attracion 만들 수 있도록
• Attraction Category 테이블 설계
  • 확장성 고려 - Attraction 테이블에 칼럼으로 넣지 않고 Category 테이블 별도 설계
  • 디지털, 신선식품 등 특정 카테고리 상품군 만을 Ride로 올릴 수 있도록
  • Attraction이 추후 기획전, 상품평, 코너 등에 사용될 수 있다고 판단
  • 정규화 - 데이터 구조화 작업
  • 중복 데이터를 없애고, 데이터베이스 구조 확장 시 재 디자인하는 것을 최소화하기 위한 목적으로 사용

 

3-3. RIDE 테이블 설계

@지마켓 기술블로그 Ride 테이블 설계

 

• Ride는 사이트 상품과 연동 가능해야 하므로, BSD (빅스마일데이) 기간에 태그가 붙은 상품을 구매한 경우에만 구매 내역에서 불러와 Ride Goods로 등록할 수 있게 설계
• Ride Recommend 좋아요 저장 테이블 설계
• Ride Report 신고 테이블 설계
• Ride Comment 댓글 저장 테이블 설계

 

3-4. PASSENGER 테이블 설계

 

 

Passenger는 사내에 없던 생소한 개념이었는데요, 아래의 문제상황이 있었습니다.

1. Gmarket의 id 중복 문제 -> 기본 id들이 있었기 때문에 Gmarket은 유니크한 id 식별자를 봐야 함
2. G/A 간 회원 식별자가 다른 것 -> Auction에는 회원 식별자가 없음
3. Admin도 참여할 수 있는 서비스 -> Admin id가 G/A와 중복될 수 있음.

• MyG, MyA 등의 내 정보와 연동하기 위해선 타 팀과의 논의가 필수 불가결
• 하지만 커뮤니케이션 비용 절감 / 확장 가능성 고려해 유저아이디, 회원 식별자, 사이트 종류 세가지 속성을 이용해
  기존 지마켓/옥션/Admin 계정 정보와 논리적인 Relation 맺는 것이 합리적이라는 판단
• 지마켓 / 옥션 / Admin 계정의 유저 id는 중복될 수 있으므로,
  pax의 id 칼럼을 만들어 유저 id로 넣어두되 사이트 종류 칼럼으로 구분 가능
• -> Passenger 테이블의 pk 만을 보고 유일한 탑승객임을 보장 가능
• 추후 해당 승객의 등급 / 뱃지 등 게이미피케이션 요소를 넣기 위한 칼럼 정의
• 해당 탑승객에 대한 정보는 Passenger 테이블에서만 저장됨

또한, 개인정보는 저장하지 않습니다.

• ※ 모든 속성은 G-World에서만 이용하기 때문에 개인정보를 저장하지 않음
• (개인정보 보호 테이블이 되면 Meta System 내에서 별도로 관리되어 관리 포인트가 많아짐)
• 기본적으로 모든 테이블에는 Insert Operator, Update Operator와 관련한 칼럼이 포함

 

따라서, 모든 테이블에 공통으로 들어가야 하는 정보는 아래와 같습니다.

@지마켓 기술블로그

 

설계는 항상 꼼꼼하게, BUT 칼럼 추가나 수정은 항상 발생할 수 있기에

과한 완벽함 추구는 오히려 장애가 될 수 있음을 짚어주셨습니다.

 

4. 데이터 스키마와 현업에서 FK 사용 여부

 

앞선 요구사항들을 고려해 완성된, G-World Attraction의 데이터 스키마는 아래와 같습니다.

 

 

@지마켓 기술블로그

• Entity 선언
• Entity 끼리의 Relation 맺기
• 물리적, 논리적 ERD 각각 구성

 

추가로, 사내에서는 실제 테이블이 생성될 때 외래키 FK를 반영하지 않는다고 합니다. 

• 외래키 = 두 테이블을 연결시켜주는 다리
• ex. Ride 테이블에 상위 테이블인 Attraction 키 값이 있거나 Ride Goods 테이블에 Ride 키 값이 들어있는 것 등
• 관계형 데이터베이스에 대해 배울때는 PK, FK 설정을 통한 데이터 무결성/정합성 보장한다고 하지만,
• 성능, 개발, 유지보수에 있어서 trade off 관계이기 때문에 현업에서는 물리적 FK를 정의하지 않는 편 -> Meta 시스템 통해 정합성 보장

이와 관련해 추가 설명이 필요해 GPT에게 질문했습니다.

!GPT 에게 물어본 PK FK와 트레이드 오프 관계

PK와 FK의 트레이드오프:

성능: FK를 설정하면 데이터베이스가 참조 무결성을 유지하기 위해 추가 작업을 해야 하므로 성능에 영향을 줄 수 있습니다.
개발: FK를 정의하면 개발 중에 데이터 삽입/수정 시 제약 조건을 신경 써야 하므로 복잡성이 증가할 수 있습니다.
유지보수: FK로 인해 데이터베이스 구조가 복잡해질 수 있고, 구조 변경 시 제약 조건을 고려해야 하므로 유지보수가 어려워질 수 있습니다.
현업에서의 FK 사용:

이러한 이유로 실제 현업에서는 성능과 유지보수의 이유로 물리적으로 FK를 정의하지 않는 경우가 많습니다.
대신, Meta 시스템을 사용하여 데이터의 정합성을 보장합니다. Meta 시스템이란 데이터베이스 외부에서 데이터의 관계와 규칙을 관리하는 시스템을 의미합니다. 예를 들어, 애플리케이션 레벨에서 데이터의 무결성을 검증하는 로직을 구현하는 것입니다.

 

🥮 챗 GBT 시스템 자체가 꿀템, 구현을 위한 테이블 설계의 여정

빅스마일데이 기간동안 꿀템피드에는 7700개의 추천글이 올라왔다고 하는데요,

이러한 반응을 이끌어낼 수 있었던 데는 이 아이디어의 시작점이 중요했다고 생각합니다.

 

사내에서 '챗 GBT'를 사용하고 직접 구매에 도움을 받았던 임직원분들께서

'우리 고객도 이런 것을 좋아하지 않을까?'하고 프로모션에 녹여냈다고 하는데요,

'챗 GBT'라는 추천시스템 자체가 '꿀템'이었던 거죠.

사내 시스템에서 충분한 가치를 느꼈기에, 이를 고객에게 추천하고 고객 역시 기대 이상의 가치를 제공받을 수 있었다고 생각합니다.

 

그리고 이를 성공적으로 구현하기 위한 과정을 상세하게 작성해주신 기술블로그를 보면서,

간단해보이는 서비스를 만들기 위해 얼마나 많은 테이블이 논리적으로 구성되어야 하며

설계에 있어서 확장성과 중복 배제 등을 고려해야 함을 알 수 있었습니다.

또한 기획자로서 개발자에게 요청하기 전, 미리 고려하면 좋을 테이블 속성에 대해서도 알 수 있었습니다. 

 

긴 글이었지만, Attraction이라는 놀이공원의 개념을 데려와 추천 서비스에 적용,

테이블을 설계하는 과정들을 어렵지 않게 설명해주셔서 재미있게 읽었습니다👍

 

좋은 글 써주셔서 감사합니다!

 

 

신규 서비스 "꿀템"을 만들기 위한 여정(네? 다음달까지요?) -1편

G마켓 삼인방이 만든 '꿀템 피드'…빅스마일데이서 빛났다 | 아주경제

"꿀템 추천하고, 용돈버세요"쇼핑고수의 '빅스마일데이' 재테크 - 뉴스웨이