프로젝트 회고

네이버 검색 API를 사용하다 보니 사용자가 입력한 키워드가 상품 제목에 강하게 반영되는 걸 알 수 있었다.예를 들어 사용자가 다음과 같은 키워드를 입력했다고 가정하자\[대상(남자친구), 예산(5~10만원), 상황(생일), 태그1(낚시), 태그2(장비)]\[대상(남자친

현재 내가 개발 중인 비회원 기반 선물 추천 서비스는 사용자가 프론트엔드에서 guest_id를 통해 고정 질문과 GPT 기반 질문에 답변하고 이 응답을 바탕으로 프론트에서 OpenAI API를 호출해 대표 키워드를 추출한 후 백엔드는 이 키워드들을 기준으로 DB에 캐시

오늘은 선물 추천 서비스의 품질을 심각하게 위협하고 있는 두 가지 이슈에 대해 정리해보았다. 바로 ‘중복 상품 제거’와 ‘추천 상품의 다양성 확보’다. 이는 단순히 추천이 "되냐 안 되냐"의 문제가 아니라 사용자가 이 추천을 실제로 신뢰하고 쓸 수 있느냐를 좌우하는 중

선물 추천 서비스를 운영하면서 사용자에게 제공되는 상품 리스트를 유심히 살펴보던 중 너무 유사한 상품들이 연속적으로 추천되는 현상을 발견했다. 겉보기에 상품 제목은 조금씩 다르지만 실제로는 같은 브랜드의 동일 라인업이거나 용량/옵션만 다른 거의 동일한 상품들이었고 이로

이번 추천 시스템 개발 과정에서 사용자 피드백을 수렴해 두 가지 큰 방향으로 개선을 진행했다. 추천 상품 수 확장 기존에는 추천 결과를 4개까지만 응답하도록 제한했는데 사용자 입장에서는 선택지가 너무 적다는 의견이 많았다. 선물이라는 특성상 비교/고민 후 선택하는 흐

최근 사용자 테스트(UT)가 끝난 이후, PM 분들과 UI/UX 디자이너 분들이 개선 백로그를 정리해주셨다. 이 중 가장 중요한 항목으로 꼽힌 것은 바로 "OpenAI 프롬프트 개선"이었다. 기존 구조에서는 다음과 같은 흐름으로 추천 시스템이 동작하고 있었다.고정 질문

추천 시스템에서 거의 동시에 여러 유저가 비슷한 시점에 추천 요청을 보냈을 때 발생하는 이슈를 해결했다. 기존 구조에서는 추천 요청이 들어오면 tag, receiver, reason 키워드를 조합하여 KeywordGroup 테이블에 저장하거나 조회하고 이후 이를 기반으

요즘 진행 중인 선물 추천 대화형 AI 어시스턴트 프로젝트에서, 사용자와의 대화 흐름을 자연스럽게 이어가기 위해 OpenAI 프롬프트 설계 방식을 고민하게 됐다. 기존에는 다음 질문을 생성할 때, "취향이 뭐야?", "관심사가 뭐야?" 같은 직접적인 질문을 던졌는데,

오늘은 이전에 팀원들과 진행했던 기능 개선 회의에서 도출된 안건들을 토대로 최종적으로 고정 질문 및 선택지 구성이 확정되었고 이에 따라 추천 시스템 전반을 정책 기반으로 정리하고 코드 리팩토링을 진행했다. 단순한 기능 추가가 아닌 전체 흐름의 개선 및 조건 처리 방식의

기존에는 question.type이 CHOICE, TEXT처럼 입력 형태(선택형/자유입력형)을 구분하는 필드로 사용되고 있었지만 실제로는 질문이 고정 질문인지(GPT가 생성한 AI 질문인지)를 구분하는 용도로 사용하는 것이 더 명확하다는 판단이 들었다. 입력 방식 자체

문제 상황 선착순 쿠폰 발급 시스템을 만들면서 가장 중요한 조건은 “한 유저가 하나의 쿠폰만 발급받을 수 있도록 보장”하는 것이었다. 즉, 중복 발급을 막고 동시에 만료 시간(유효기간)도 관리해야 했다. 전통적인 방식이라면 쿠폰 발급 내역을 DB에서 userid, co

현재 서비스는 사용자로부터 6개의 고정 질문(대상, 성별, 연령대, 가격, 상황, 카테고리)과 3개의 AI 질문을 통해 입력을 수집하고 이를 OpenAI API에 전달하여 키워드 5개를 생성한다. 이 키워드를 바탕으로 네이버 쇼핑 API에서 상품을 검색해 추천 결과를

우리는 왜 이 조사를 하게 됐을까? 무무의 선물상자에서는 사용자에게 더 나은 선물 추천을 제공하고자 고민하고 있다. 현재는 네이버 쇼핑 API를 활용해 실시간 상품 데이터를 가져와 추천에 사용하고 있으나 실제 서비스 운영 과정에서 추천 품질이 기대에 못 미친다는 피드백

문제 인식 현재 무무의 선물상자 서비스는 네이버 쇼핑 API를 기반으로 실시간 상품을 검색해 추천하고 있다. 하지만 실제 운영 과정에서 다음과 같은 한계에 부딪혔다. AAPI 응답 품질이 일정하지 않고, 태그나 키워드 조합에 따라 엉뚱한 결과가 나오기도 함 카테고리,

운영/관리자 화면에서 상품 우선순위와 노출명 가독성을 동시에 개선하고 싶었다.우선순위: 후기/평점을 기반으로 “믿고 볼 만한” 상품을 먼저 보여주기노출명: 플랫폼이 붙여놓은 판촉 문구(무료배송, 1+1 등)와 장식 기호를 제거해 핵심 이름만 보이게 하기이걸 위해 두 가

운영자가 크롤링된 상품을 검색 + 정렬 + 페이징으로 빠르게 훑고 확정(isConfirmed) 여부/성별/연령대/가격대/플랫폼/카테고리/판매자 기준으로 정밀 필터링할 수 있어야 한다. 초기 목표는 두 가지이다.설명 가능한 단순 구조: 복잡한 동적 쿼리 빌더보다 null

운영 화면에서는 특정 상품의 속성을 한 건만 가볍게 바꾸는 작업과 목록에서 여러 건을 체크해 한 번에 바꾸는 작업이 항상 공존한다. 한 가지 API로 억지로 처리하면 검증/에러/트랜잭션/성능/권한 가드가 서로 충돌한다. 그래서 단건 API와 벌크 API를 분리해 각각의

“무무의 선물상자”에 벡터 스토어(Qdrant)를 도입해 의미 유사도 기반 추천/중복 판별을 적용하려고 한다. 현재 인프라는 EC2 프리티어(t2.micro, 1 vCPU / 1GB RAM) + MySQL(EC2 내). 같은 인스턴스에 Spring Boot + Qdra

운영자가 한 번에 여러 상품을 등록할 때 기존에는 “성공/실패”만 알 수 있어 원인 파악과 재시도가 불편했습니다. 특히 product_url의 유니크 제약으로 중복이 자주 발생하는데 요청 리스트 중 어떤 항목이 중복이었고 어떤 항목이 다른 이유로 실패했는지를 한눈에 보

무무의 선물상자 서비스에서 상품 추천 품질을 높이기 위해 의미 유사도 기반 검색이 필요했다. 지금까지는 단순 문자열 매칭(Jaccard, LIKE 검색 등)으로만 상품명을 비교했는데 이 방식은 “단어가 다르면 다른 상품으로 처리”하는 한계가 있었다. 예를 들어, “무

EmbeddingService로 OpenAI 임베딩 생성(캐시 + 429 재시도 + dummy 모드 지원)ProductVectorService가 상품 텍스트를 벡터화 → Qdrant 컬렉션 보증 → 업서트저장 시점에 도메인 이벤트(ProductCreatedEvent)

목표1: 추천 품질 향상을 위해 Qdrant(벡터 DB) 를 EC2에 올리고 GitHub Actions 기반 CI/CD로 빌드/배포 자동화까지 한 번에 구성목표2: ./gradlew clean build 시 테스트가 로컬/CI 모두 실패하는 문제 해결최종 결론Qdran