스마트폰을 바꾼 후 이전에 썼던 기기를 중고로 팔아보신 적 있으세요? ‘이 정도 상태의 기기면 어느 정도 가격대가 적당한 거지?’ 고민하며, 수많은 중고 매물 게시글을 일일이 확인하지는 않으셨나요? 이제는 LLM(대형 언어 모델) 덕분에 이렇게 번거롭고 어려웠던 작업이 훨씬 쉽고 빠르게 해결되고 있어요.이 글에서는 LLM을 활용해 중고거래 게시글에서 스마트폰 정보를 추출하고, 이를 통해 시세를 산출한 방법을 소개하려고 해요. 먼저 스마트폰 시세조회 서비스를 왜 만들게 됐는지 배경을 간단히 살펴본 후, LLM으로 게시글을 분류·정제하는 과정, BigQuery를 이용해 정보를 후처리하고 시세를 집계하는 과정, 마지막으로 벡터 DB 기반으로 유사 게시글을 추천하는 과정을 단계별로 소개해 드릴게요. LLM으로 사용자 경험을 효과적으로 개선할 방법을 고민 중인 분들에게 이 사례가 큰 도움이 되면 좋겠어요.스마트폰 시세조회 서비스의 모습스마트폰 시세조회는 왜 필요할까요?많은 중고거래 판매자들이 물품의 적절한 가격을 결정하는 걸 어려워해요. 개인 간 거래는 워낙 다양한 상품이 혼재되어 있기 때문인데요. 종류도 워낙 다양한데 상태도 가지각색이라, 물품의 정확한 시세를 한눈에 파악하기 어려운 거죠. 스마트폰을 예로 들면 단순히 같은 기종만 검색해서 끝날 일이 아니라, 사용 기간, 배터리 효율, 스크래치 여부 등 상태가 비슷한 기기가 얼마에 팔리는지 일일이 확인해야 하는 거예요.중고거래팀은 사용자가 물품의 시세를 한눈에 확인하고 더 쉽게 가격을 결정할 수 있도록, 아이폰, 갤럭시 기종을 대상으로 한 스마트폰 시세 조회 서비스를 테스트하기로 했어요. 다양한 물품 중 스마트폰을 베타 테스트 대상으로 선정한 이유는 다음과 같아요. 스마트폰은 제품 모델이 명확하고 게시글 수가 많아 데이터 기반 시세 계산에 유리해요. 또 판매 단가가 높아 가격 결정이 중요한 상품이기도 하고요.결과적으로 모델, 용량, 새 상품 여부, 스크래치 및 파손, 배터리 효율 등 구체적인 물품 상태에 따라 시세가 어느 정도인지 파악할 수 있는 서비스를 만들었어요. 예를 들어 사용자가 ‘아이폰 16 Pro 128GB’를 선택하고 필터에서 구체적인 ‘사용 상태’나 ‘배터리 성능’을 설정하면, 곧바로 그에 따른 시세 정보를 ‘OOO만원-OOO만원’과 같은 가격 범위의 형태로 확인할 수 있어요. 이번 프로젝트는 머신러닝을 활용해 당근 중고거래 데이터를 기반으로 정확한 시세를 제공한 첫 번째 시도로, 팀 내에서도 의미가 큰 프로젝트이기도 했는데요. 그럼 본격적으로 기능을 구현해 나간 과정을 단계별로 소개해 드릴게요.Step 1. 상품 정보 추출가장 큰 문제는 게시글에서 상품 정보를 추출하는 것이에요. 당근은 판매자의 글쓰기 허들을 낮추기 위해 중고거래 게시글에 구체적인 기종이나 물품 상태를 입력하도록 요구하지 않아요. 하지만 구체적인 물품 상태별로 스마트폰 시세를 제공하려면 모델, 용량, 새 상품 여부, 스크래치 및 파손 여부, 배터리 효율 등 여러 가지 다양한 조건을 알아내야 했어요.기존에는 이런

안녕하세요. 쏘카 데이터엔지니어링팀 삐약, 루디입니다.내용을 시작하기에 앞서, 저희 팀의 업무와 역할에 대해 간략히 소개해 드리겠습니다.데이터엔지니어링팀은 신뢰할 수 있는 데이터를 쏘카 구성원들이 안정적으로 활용할 수 있도록 기반을 마련하고, 이를 실제 비즈니스에 적용할 수 있는 서비스를 개발하며 환경을 구축하고 있습니다. 데이터 마트 관리, 데이터 인프라 구축, 그리고 데이터 제품(Data as a Product) 개발 등 폭넓은 업무를 수행하고 있습니다.특히 주요 업무로는 배치 및 실시간 스트리밍 파이프라인을 설계하고 개발하여, 쏘카의 모든 서비스에서 발생하는 데이터를 비즈니스 분석에 효과적으로 활용할 수 있도록 지원하는 역할을 하고 있습니다.이번 글에서는 저희 팀이 관리 및 운영하는 데이터 파이프라인 중, 비즈니스 의사 결정 시 지표로 사용되는 서버 로그를 데이터 웨어하우스로 사용하고 있는 BigQuery에 적재하는 로그 파이프라인 개선 과정을 소개드리고자 합니다개선을 하게 된 가장 주요 이유 중 하나는 데이터 스키마 변경으로 인해 겪는 어려움 이었습니다. 이를 해결하기 위해 데이터 컨트랙트를 도입하게 되었고, 이 과정에서 얻은 경험을 나누고자 합니다. 이번 시리즈는 비슷한 문제를 겪고 계신 분들께 도움이 되길 바랍니다.• 데이터 파이프라인을 구축하거나 개선하고자 하는 데이터 엔지니어• 데이터 컨트랙트를 도입하려는 개발자• 데이터 엔지니어의 업무에 대해 궁금한 분2. 기존 로그 파이프라인 현황기존 파이프라인을 설명하기에 앞서, 아키텍처의 문제를 더 명확히 이해하기 위해 원본 데이터의 구조와 요구사항을 먼저 살펴보겠습니다.원본 데이터에서 하나의 로그 파일은 다음과 같은 형식으로 제공됩니다.하나의 파일에는 여러 종류의 로그 데이터가 섞여 있으며, 모든 데이터에는 로그의 종류(type)와 생성 시간(timeMs) 같은 공통 필드가 포함되어 있습니다. 또한 각 로그 타입마다 고유한 필드도 존재합니다.파이프라인의 요구사항은 아래와 같습니다.• BigQuery 테이블화: 로그 데이터는 타입별로 구분된 BigQuery 테이블에 저장되어야 하며, 이를 통해 조회 및 분석이 가능해야 합니다.• 특정 타입 데이터 적재: 요청한 타입의 데이터만 BigQuery에 적재해야합니다.• 배치성 처리: 데이터 처리와 적재는 최소 2시간 이내에 이루어져야 하며, 가능하면 더 빠르게 처리되어야 합니다.이러한 데이터 구조와 요구사항을 바탕으로, 기존 파이프라인이 어떻게 구성되어 있는지 살펴보겠습니다.2-2. 기존 파이프라인 아키텍처우선 어떻게 데이터 파이프라인을 개선할 것인가에 대한 질문에 대한 답을 하기에 앞서 기존 아키텍처에 대하여 이해하고 어떤 부분에서의 문제가 발생하고 있는지의 파악이 필요합니다.기존 파이프라인 설계 당시의 상황과 고려 사항을 살펴보면, 이미 Amazon Kinesis Data Stream(KDS)과 Firehose를 통해 AWS S3에 데이터가 적재되고 있는 환경이었습니다. 더불어 로그 데이터는 주로 분석 용도로 활용될 예정이었기에 실시간성

WATCHA에서 서로 다른 클라우드 저장소 간의 데이터 마이그레이션 시스템을 구축한 경험을 소개합니다. #Kubernetes #ArgoWorkflows안녕하세요, WATCHA Server Platform 팀에서 플랫폼 엔지니어로 일하고 있는 루카입니다.WATCHA에서 모은 데이터를 효율적으로 분석하고 활용하기 위해 기존 데이터 마이그레이션 프로세스를 개선해 새로 구축한 경험, 그중에서도 AWS DynamoDB의 데이터 마이그레이션 사례를 중심으로 소개해 보려 합니다.WATCHA에서는 다양한 데이터가 매일 생성되고 업데이트됩니다. 이들은 용도에 따라 RDB나 NoSQL 등, 데이터 성질에 맞는 데이터베이스에 저장되지만, 다양한 의사결정을 지원하기 위해서는 서로 다른 성질의 데이터들을 통합하여 분석할 필요가 있습니다. WATCHA는 Google Cloud의 강력한 데이터 분석 도구인 BigQuery를 데이터 웨어하우스로 활용하고 있습니다.데이터 통합을 위해서는 매일 업데이트되는 데이터를 BigQuery에 동기화하는 과정이 필요합니다. 이 과정은 자동화되고 안정적이어야 하며, 새로운 데이터 형태가 추가될 때 쉽게 통합할 수 있어야 합니다. 또, WATCHA의 경우 대부분의 데이터가 Google Cloud 대신 AWS에 저장되고 있기 때문에, 멀티 클라우드 환경에 대한 고려도 필요합니다. 마지막으로, 위 조건들이 충족되는 한에서 비용 효율성을 최적화해야 합니다. 기존의 데이터 마이그레이션 프로세스는 이러한 요구사항들을 온전히 충족하지 못하고 있었습니다.데이터 마이그레이션 작업은 여러 팀의 리소스가 연계되는 작업입니다. 크게 보면 각 데이터를 소유한 담당 서버 팀, 데이터를 전달하는 인프라 팀, 그리고 데이터를 사용하는 분석 팀이 있겠습니다. 기존 파이프라인은 각 팀이 오너십을 가진 영역에서 각자 작업을 수행하는 협업의 형태로 설계되어 있었습니다. 이러한 오너십의 분산은 언뜻 보기엔 크게 문제가 없게 느껴졌지만, 운영 시스템의 미성숙과 겹치자 몇 가지 문제를 야기했습니다.기존 파이프라인. 각 팀마다 작업이 할당되어 각자 순차적으로 처리합니다.대표적인 문제는 Cascading failure였습니다. 기존 프로세스에서는 팀 간 작업 완료 이벤트를 제대로 체크하지 않고 있어, 한 작업이 실패할 경우 이후 단계 작업이 모두 실패하는 상황이 발생했습니다. 이로 인해 각 팀이 운영하는 모니터링 시스템에서 중복된 실패 알림이 발생해 혼란이 생겼고, 알림이 왔는데 막상 다른 팀의 실패에서 비롯된 경우가 발생하면서 알림의 신뢰도 역시 감소하였습니다.또 다른 문제는 지속적인 운영 부하였습니다. 데이터 마이그레이션 작업은 새로운 데이터가 통합에 추가되거나, 데이터의 스키마가 변할 때 지속적으로 관리가 필요한데요, 각 팀에서 각자 관리하는 데이터가 생기면서, 작은 스키마 변경에도 여러 팀에서 각자 설정 파일을 수정하고, 다른 팀 간에 타이밍을 맞춰 변경 사항을 적용하는 등의 번거로운 처리가 필요했습니다.문제점 2. 비용 비효율성마이그레이션에 활용되는 데이터 형태에도

Vertex AI Search를 활용한 결과 없는 검색 개선하기AI SaaS 도입으로 검색 경험을 개선한 사례 소개• ‘결과 없는 검색’ 개선 프로젝트• Vertex AI Search• Vertex AI Search란? 왜 도입했는가?• 검색 데이터의 주기적인 업데이트• 데모 페이지로 검색 결과 쉽게 확인하기안녕하세요. 컬리 데이터서비스개발팀의 Product Manager 권수영, ML Engineer 한수진입니다. 저희 팀은 컬리에 적합한 AI 기술 리서치와 서비스 도입을 위한 다양한 프로젝트를 진행하고 있으며, 이번 글에서는 그 중 하나인 검색 기능 개선을 위한 Google Vertex AI Search 도입 사례와 그 성공적인 성과에 대해 소개하고자 합니다. 특히 이번 프로젝트는 Google의 SaaS를 사용하여 빠른 시일 내 개발을 완료하였고 성능 면에서도 우수한 성과를 거두어 2024 Google Cloud Summit 행사에서 소개되기도 했습니다.‘결과 없는 검색’ 개선 프로젝트컬리의 검색 기능에서 오타, 띄어쓰기 오류, 유의어 등으로 인해 검색 결과를 제공하지 못하는 케이스(이하 "NR"; No Result)는 전체 검색의 약 6%~7%를 차지하고 있습니다. 반복적으로 발생하거나 시즌 특성을 반영하는 중요한 검색어라면 시스템에 수동으로 등록하기도 하지만, 검색 결과가 없는 대부분의 경우에는 컬리의 베스트 상품을 대신 보여줍니다. 하지만 이러한 방식은 검색어 운영관리 측면의 번거로움이 있을 뿐만 아니라, 정확한 목적을 가지고 검색을 시도한 고객의 만족도 역시 저하되는 문제가 있었습니다.기존 검색 엔진에서 처리하지 못하는 이러한 NR 케이스에 유의미한 검색 결과를 제공하기 위해서는 검색어와 상품 간의 유사도를 맥락과 배경을 고려하는 컨텍스트 기반으로 좀 더 폭넓게 매칭시켜줄 수 있어야 합니다. 컬리의 GCP 분석 환경에서 이를 가장 빠르고 정확하게 실현시켜줄 수 있는 서비스가 Vertex AI Search였고, 이를 통해 검색 결과를 보완하고자 했습니다.기존 ‘결과 없는 검색’ 케이스를 AI 결과물로 대체한 모습 © 2024.Kurly.All right reservedVertex AI Search란? 왜 도입했는가?Vertex AI Search는 Google Cloud의 관리형 서비스로 웹사이트, 문서, 파일, 데이터베이스 등 대규모 데이터셋을 탐색하여 검색을 수행합니다. Vertex AI 모델을 활용하여 복잡한 검색 쿼리를 별도로 작성하지 않고도 사용자의 의도를 파악하여 보다 정확한 검색 결과를 제공할 수 있습니다. 이 모델은 검색어와의 텍스트 매칭뿐만 아니라 검색어 임베딩 간의 유사도 분석을 동시에 수행하여 하이브리드 검색(의미론적 검색)을 지원합니다. 또한, Google Cloud 내 다른 서비스인 BigQuery, GCS 등과 쉽게 통합할 수 있어 확장성이 뛰어나며, 비즈니스에 맞게 검색 모델을 튜닝하거나 사용자 정의 임베딩 작업을 간편하게 수행할 수 있는 점도 매력적입니다.검색 기능을 빠르게 테스트해보고 싶다면 웹사이