AWS 기술 블로그

GS리테일의 Amazon Bedrock을 활용한 AI 와인 라벨 이미지 검색 서비스 구축

GS리테일은 전국 18,000여 개의 편의점 GS25와 슈퍼마켓 GS더프레시를 운영하는 대한민국 대표 유통 기업입니다. 특히 우리동네GS 앱을 통해 제공되는 와인25플러스 서비스는 1만여 종의 다양한 주류를 언제 어디서나 예약/픽업할 수 있는 주류 특화 서비스로 고객들에게 큰 호응을 얻고 있습니다.

복잡한 와인 라벨 해석의 어려움을 해결하기 위해 GS리테일은 Amazon Bedrock을 활용한 AI 와인 이미지 라벨 검색 서비스를 개발했습니다. 고객이 와인 병을 촬영하면 AI가 자동으로 유사한 상품을 검색해주는 혁신적인 서비스입니다.

본 블로그에서는 Anthropic Claude 모델의 멀티모달기반 OCR과 Amazon Titan Multimodal Embedding을 활용한 멀티모달 검색 기술을 실제 서비스에 적용한 과정과 검색 품질을 높이기 위한 기술적 해결 방안을 소개합니다.

우리동네GS – 와인25플러스란?

GS25 파르나스점을 비록한 많은 전국의 점포에서는 다양한 와인들을 전시하고 있다

전국 곳곳에 분포한 GS25(편의점)와 GS더프레시(슈퍼마켓)에서는 1만여 종의 다양한 주류들을 취급하여 집근처 어디서나 쉽게 접할 수 있습니다. 오프라인 지점의 매출 유도와 온라인으로도 편한 서비스 제공을 위해, 우리동네GS 앱에서는 “와인25플러스”를 통해 와인, 양주, 수제맥주 등 다양한 주류를 언제 어디서나 GS25 및 GS더프레시에서 예약/픽업으로 이용할 수 있는 주류 특화 서비스를 제공하고 있습니다.

와인25 플러스 내 상품 상세 정보 화면

특히 와인25플러스에서는 주류에 대한 전문지식이 없는 고객도 이애할 수 있도록 위의 앱 화면과 같이 품종, 당도, 산미, 수상 이력, 페어링 정보 등을 함께 제공하고 있습니다.

다양한 점포에서의 주류 진열대의 모습

오프라인 매장에서도 고객의 니즈를 잘 이해하고 직접 손으로 주류 라벨을 해석하여 추천 문구를 써 붙이는 등 다양한 따뜻한 방식으로 고객을 응대하고 있습니다. 익숙치 않은 와인과 주류에 깃든 이야기를 고객에게 더 쉽게 전하려고 노력하고 있습니다. 하지만 현실은 어려운 부분이 많습니다. 와인 라벨의 경우 프랑스어/라틴어로 쓰여져 있어 일반 고객은 물론 점포 직원도 해석하기 어려운 경우가 많으며, 온라인에 검색 가능한 정보가 제한적인 경우가 많습니다. 매장 직원 입장에서도 수천 개의 주류 상품 정보를 모두 기억하거나 일일이 설명해주는 건 물리적으로도 불가능합니다.

이러한 문제를 해결하기 위해 고객이 스스로 라벨 이미지를 기반으로 검색할 수 있는 AI 와인 이미지 라벨 검색 서비스를 기획하게 되었습니다.


AI 와인 이미지 라벨 검색 서비스 화면

이 서비스는 우리동네GS 앱의 와인25플러스 화면에서 고객이 와인의 병을 촬영하면 AI가 라벨의 텍스트와 색상, 병 모양을 인식하여 가장 유사한 상품들을 검색하여 찾아줍니다. 검색 결과에서 원하는 와인을 클릭하면 자세한 상품 정보로 바로 이동할 수 있어 고객은 손쉽게, 그리고 경영주님의 응대는 더 쉬워집니다.

기술적 구현방안

기존 방식의 한계점

상품 이미지에서 텍스트를 추출하거나 이미지 자체를 Embedding Model을 활용하여 검색하는 기술 등 많은 방법들과 사례가 존재합니다. 하지만 와인25 플러스에서 취급하는 상품들은 와인, 위스키, 맥주 등 다양한 종류와 국내를 비롯한 해외의 상품들이 대다수인 도메인 특성을 고려해야 합니다.

우선 여러 실험 과정을 진행하였는데, 텍스트를 추출하는 OCR 기술만 활용하였을 때에는 어떤 언어인지 파악하기 어려워 난해한 언어로 추출되기도 하였고, 단순히 이미지만 가지고 파악하였을 경우에는 병의 모양이 비슷하면 대부분 유사한 상품이라고 검색이 되거나 비슷한 에디션의 상품들이 많아 텍스트의 부가 정보를 필요로 함을 발견하였습니다.

OCR 기술은 정형화된 문자를 인식하는 기술은 ML기반의 전통적인 방식이 뛰어나지만, 와인라벨처럼 다자인이 가미되어 전체 컨텍스트를 이해하는 OCR은 Amazon Bedrock의 Anthropic Claude 3 Haiku을 활용하여 주류 라벨 내의 텍스트를 추출하는 것이 성능이 더 뛰어난 것을 실험을 통해 확인하였습니다. 예를 들어 아래의 이미지에 대해서 기존의 전통적인 OCR 모델은 “G7”과 같은 와인 상품명을 제대로 인식하지 못하는 경우가 많았지만, 컨텍스트를 이해하는 멀티모달 LLM은 주류 라벨 내의 텍스트를 더 정확하게 추출할 수 있음을 확인할 수 있었습니다.

🤖 LLM(Extract OCR) + Multi Modal Search(Embedding Image + Text)

이러한 한계점을 극복하기 위해 멀티모달 LLM을 활용한 정확한 텍스트 추출(OCR)과 이미지-텍스트 멀티모달 임베딩을 결합한 하이브리드 검색 방식을 도입했습니다. 이를 통해 주류 라벨의 컨텍스트를 정확히 이해하고 추출하면서, 동시에 이미지와 텍스트 정보를 모두 활용한 보다 정교한 상품 검색이 가능해졌습니다.

전체 아키텍처를 도식화하면 다음과 같습니다.

배치/추론 작업별 이미지 분석 흐름도

전체적으로 크게 상단에는 배치 작업을 통해 검색 대상 상품의 이미지를 분석하여 벡터 DB를 만드는 과정이며, 하단에는 사용자가 이미지를 촬영하여 유사한 상품을 찾는 검색 과정으로 나눕니다. 배치 작업과 추론 작업 모두 거의 같은 로직으로 AWS 클라우드의 리소스를 활용하고 Elasticsearch를 벡터 DB로 사용하여 이미지를 분석하고 벡터화의 과정을 거쳐서 진행됩니다.

우선 상단에 위치한 배치 작업을 위주로 설명드리겠습니다.

Batch Job Workflows

우리동네GS 데이터베이스에 온라인으로 등록된 주류들을 매 시간마다 수집하여 벡터 DB에 존재하지 않은 상품이 있을 경우, 이미지를 분석하여 벡터를 저장하는 파이프라인을 실행합니다. 검색추천팀 플랫폼 파트에서 운영하고 있는 KubernetesArgo Workflows기반으로 배치 작업이 실행되며 Metaflow를 통해 쉽게 실험, 관리하고 모니터링이 가능합니다.

Metaflow의 배치 작업 타임라인 조회 화면

이제는 좀 더 상세한 배치 작업 파이프라인의 컴포넌트에 대한 설명입니다.

1. Preprocessing: 전처리 구간

상품 정보에 등록된 주류 이미지의 사이즈를 재조정하는 등 전처리하는 구간입니다. 하지만 상품 이미지를 보면 아래와 같이 주류만 찍힌 이미지가 아니라 박스와 포장버전 등의 노이즈가 많아 검색 기능에 방해가 될 수 있습니다. 이를 위해 YOLOv8 모델을 통해 병이라고 인식되는 위치만 탐지하여 이미지를 자르도록 설정 후 Amazon S3에 저장합니다. 이러한 객체 탐지 과정은 배치 작업에서만 수행되며 추론 작업에서는 진행하지 않습니다.

YOLO를 통해 병만 탐지하여 저장

2. Extract OCR: LLM을 통해 이미지 내 텍스트 추출하는 구간

위에서 병 모양만 자른 이미지를 불러왔다면, 이제는 Amazon Bedrock Claude-3-Haiku 모델 API를 활용하여 주류 라벨에서 상품명, 브랜드, 품종 등 텍스트 정보를 추출하라는 프롬프트와 이미지 정보를 송신합니다.

LLM 모델을 텍스트 추출할 대상을 이미지 내에서 분석하여 그 결과를 JSON 형식으로 반환하는 것이 필요합니다. 많은 실험을 통해 프롬프트 명령에는 단순히 텍스트 정보 추출 대상 뿐만 아니라 추론의 품질을 높이기 위해 할루시네이션을 방지하고 유효성을 검증하기 위한 내용과, 예시를 포함한 퓨샷 프롬프팅을 추가하였습니다.

  1. 구조화된 정보를 추출
    – itemName: 상품명 (완전히 보이는 경우만)
    – brand: 브랜드명 (완전히 보이는 경우만)
    – breedSpName: 포도 품종 (주류의 타입이 와인의 경우)
    – isProduct: 주류 제품 여부
  2. 엄격한 추출 규칙
    – 추측 금지: 완전히 보이는 텍스트만 추출
    – 부분 텍스트 무시: 잘린 단어나 부분적 정보는 무시
    – 정확성 우선: 확실하지 않으면 빈 문자열 반환
  3. 제품 유효성 검증
    – 음료 제품만: 와인, 위스키, 맥주 등 액체 음료 컨테이너
    – 의류/전자제품 제외: 바지, 신발, 전화기 등은 제외

3. Embedding Image + Text: Multi Modal 벡터 생성하는 구간

주류 제품이 맞다면 이제 상품명, 브랜드명, 포도 품종 등 텍스트 정보들을 알 수 있습니다. 이미지 정보를 벡터로 구성할 때 텍스트 정보들도 함께 포함하는 Multi Modal 방식으로 Embedding을 합니다. Amazon Titan Multimodal Embeddings G1 모델을 사용한다면 이미지와 텍스트 정보를 결합하여 Embedding 작업을 거쳐 총 1024개의 길이를 가진 벡터를 반환합니다.

4. Insert ES(Elasticsearch): 벡터 DB 저장

최종적으로 이미지와 텍스트 정보들이 담긴 벡터를 DB에 저장하여 코사인 유사도를 계산하여 스코어를 산출할 수 있도록 Elasticsearch 검색 엔진에 Bulk로 적재 및 인덱싱 처리를 합니다. 인덱싱이 완료 후 불과 몇 초 내에 검색이 가능한 상태로 변경됩니다.

Inference API Service

이미 앞서서도 언급하였지만 추론 작업도 배치 작업과 상당히 유사한 로직입니다. 약간의 차이가 있다면 데이터 출처, 데이터 전처리 방식과 마지막 최종 작업이 일부 차이가 있습니다. 우선 데이터는 우리동네GS 데이터베이스에서 수집하는 것이 아닌, 우리동네 GS 모바일 애플리케이션에서 사용자가 촬영한 이미지를 Amazon S3에 저장하고 이 위치에 접근하여 검색 API 서버가 데이터를 다운 받는 것 부터 추론 작업의 시작이 진행됩니다.

1. Preprocessing: 전처리 구간

Amzon S3로 부터 이미지 다운 후 이미지 전처리를 이전 배치 작업과 동일하게 작업하되, YOLO를 통한 객체 탐지는 진행되지 않습니다.

2~3. Extract OCR / Embedding Image + Text

배치 작업과 동일한 프롬프트, Embedding 방식은 동일하게 적용됩니다.

4. Search Similarity

API 서버에서 이전 단계로 부터 얻은 1024개의 벡터 값을 Elasticsearch에 코사인 유사도로 검색합니다. Elasticsearch 검색 엔진을 통해 가장 유사한 벡터를 가진 상품들이 무엇인지 빠른 시간 내에 결과값을 받을 수 있으며, 유사한 점수가 0.73 이상인 상품만 결과를 사용자의 화면에 노출할 수 있도록 응답을 보냅니다. 만약 아무런 상품도 0.73보다 높지 않다면 검색 신뢰도를 높이기 위해 아무런 상품을 찾지 못하였다고 화면이 노출됩니다.

🔧 검색 결과 개선을 위한 튜닝

서비스 출시 전, 다양한 실험과 테스트를 통해 검색 품질 향상을 위한 개선 작업을 진행했습니다. 검색 품질 향상은 단순히 정량적 지표를 개선하는 것이 아닌, 실제 사용자 경험을 중심으로 기술적 요소와 도메인 특성을 모두 고려한 정성적 개선에 중점을 두었습니다. 이를 위해 상품 데이터 품질 향상, 비영어권 상품 검색 최적화, 주류 도메인 특성 반영, 시스템 안정성 개선이라는 4가지 영역에서 개선을 진행했으며, 이를 통해 보다 정확하고 신뢰성 있는 검색 서비스를 구현할 수 있었습니다.

1. 상품 데이터 품질 높이기

우리동네GS 데이터베이스에 저장되어 있는 상품 정보 중 일부 이미지는 저화질로 저장되어 있어 텍스트 추출이 잘 되지 않아 벡터로 변환 후 실제 사용자의 스마트폰으로 촬영한 고화질의 데이터와 비교하면 유사도 결과가 잘 나오지 않는 문제가 있었습니다. 이를 개선하기 위해 현업으로 부터 고화질의 데이터를 받아 데이터의 품질을 높일 수 있었습니다.

전처리 방식도 고화질의 데이터인 경우 이미지를 재조정하지 않고 그대로 LLM을 통해 OCR 추출을 하여 더 정밀한 결과를 얻을 수 있었습니다. 또한 Inference Embedding 구간에서는 Multi Modal 방식으로 이미지와 텍스트를 함께 결합하는 방식이 아니라 텍스트만 Embedding하여 검색하는 방식이 더 유사한 상품을 찾아내는 성능을 보였습니다.

2. 비영어권의 상품 취급

Amazon Bedrock Haiku 모델을 통한 OCR 추론은 영어로 라벨링된 상품인 경우는 잘 추출되지만 아시아권 주류의 경우에는 텍스트가 추출이 잘 되지 않은 점이 발생하고 한자의 필체가 다양하다 못해 그림처럼 그려진 상품들이 많아서 인식률이 현저히 떨어졌기 때문에 분기 처리를 추가하여 전처리를 비롯한 Embedding 방식까지 다른 방법으로 고려해 보았습니다.

LLM을 통해 OCR을 추론할 때에 언어를 감지하여 만약 영어로 구성되어 있다면 기존 로직을 유지하고 그렇지 않은 다른 언어라면 텍스트 추출 결과는 무시하고, Amazon Bedrock Titan Image 모델이 아닌 Hugging Face에서 제공하는 SigLIP 모델을 활용해 이미지 정보만 Embedding하는 방식을 적용하는 것입니다. 인식이 잘 안되어 무의하게 추출된 더미 Text 데이터를 Multi Modal에 넣지 않는 것이 더 좋은 결과를 보였으며, Embedding 모델 또한 여러 실험을 통해 영어권이 아닌 경우에는 Amazon Bedrock Titan Image 모델보다 SigLIP 모델이 의미 있는 벡터를 생성한 결과를 보였습니다. 따라서 최종적인 흐름도는 다음과 같이 구성되어 현재 운영중입니다.

최종 개선 아키텍처

3. 주류 도메인을 좀 더 고려하기

위스키나 와인의 경우 년도가 다르면 차이가 매우 많이 난다는 빈티지의 특성이 존재하기 때문에 다른 상품으로 취급합니다.

이를 반영하기 위해 LLM에 OCR을 추출할 때 프롬프트에다가 라벨에 년도가 포함되어 있다면 추출하도록 수정, 그리고 해당 정보도 또한 Multi Modal을 통해 Embedding 할 때 텍스트 정보에 추가하도록 하였습니다. 이를 통해 동일한 주류이더라도 좀 더 정확한 년도 정보까지 고려하여 검색을 진행할 수 있습니다.

4. Cross-Region Inference 설정하기

서비스의 급격한 성장에 대비하기 위해 대규모 요청 처리를 위해 API 서버에 HPA(Horizontal Pod Autoscaling)를 적용했습니다. 하지만 처리 지연의 병목점이 Amazon Bedrock API 서비스에서 발생할 수 있다는 점을 확인했습니다.

초기에는 us-east-1 리전의 Haiku 모델 부하 증가 시 us-east-2 리전으로 Fallback하는 방어 로직을 직접 구현했습니다. 그러나 AWS에서 제공하는 더 간단하고 안정적인 해결책을 발견하여 적용했습니다.

Amazon Bedrock API 호출 시 모델명만 수정하면 AWS가 자동으로 Cross-Region Inference를 처리합니다:

  • 기존: “anthropic.claude-3-haiku-20240307-v1:0”
  • 변경: “us.anthropic.claude-3-haiku-20240307-v1:0”

이러한 간단한 설정만으로 별도의 방어 로직 없이도 안정적인 서비스 운영이 가능해졌습니다.

✅ 현장 검색 성능 테스트 진행

서비스 출시 전, 개발팀은 실제 현장에서의 검색 성능을 검증하기 위한 테스트를 진행했습니다. 편의점과 마트에서 이루어지는 실제 사용 환경을 고려하여 두 가지 촬영 방식으로 테스트를 설계했습니다:

  1. 상품 직접 촬영 방식
    • 와인을 진열대에서 꺼내어 촬영
    • 라벨을 가장 선명하게 촬영 가능
  2. 진열 상태 촬영 방식
    • 무게가 무겁거나 파손 위험이 있는 경우
    • 상단 진열대처럼 접근이 어려운 경우
    • 진열된 상태 그대로 촬영

이러한 실제 사용 환경을 반영한 테스트를 통해 서비스의 실용성과 성능을 검증했습니다.

테스트 진행 방식

테스트 대상은 165개의 주류 상품을 테스트하였으며, 진행 결과 70%의 검색 성공률을 보였습니다. 예상보다 낮은 성공률을 기록하였는데, 실제 검색 실패의 유형을 분석한 결과 대부분은 온라인에서 취급하지 않고 오프라인에서만 판매하는 상품이다 보니 벡터 DB에 존재하지 않은 케이스가 대부분이었습니다. 이를 고려한다면 온라인 취급 상품에서는 상당히 높은 검색의 성능 결과를 보입니다.

그리고, 예상외로 높은 검색 성능이 보인 경우도 있었습니다. 바로 진열대에 그대로 촬영하였을 때 진열대 안전 바 때문에 라벨이 일부 가려져서 잘 안보이는 문제가 있는데에도 검색이 잘 된다는 점입니다. 아무래도 이미지를 얼마나 유사한지 판단하겠지만 일부 텍스트 정보들을 함께 모아 유사한 상품을 찾기 때문에 더 풍부한 검색의 힌트를 모델이 얻어서 그런 것으로 판단됩니다. 이는 타사 기술과 비교하였을 때 안전 바에 가려진 주류를 촬영하였을 때 보다 뛰어난 검색 결과를 보였습니다.

마무리

GS리테일의 AI 와인 이미지 라벨 검색 서비스는 LLM 멀티모달 기능을 활용하여 복잡한 주류 검색 문제를 해결한 대표적인 사례입니다. 단순한 이미지 검색을 넘어 LLM을 통한 텍스트 추출과 Multi Modal Embedding을 결합함으로써 높은 이미지 검색품질을 달성하고 서비스를 성공적으로 출시 할 수 있었습니다.

주요 성과 및 시사점

  • 기술적 혁신: 전통적인 OCR 기술 대신 LLM을 활용한 텍스트 추출로 다국어 라벨 인식 성능을 크게 향상시켰습니다. 특히 영어권과 비영어권 상품을 구분하여 각각 최적화된 Embedding 모델(Amazon Bedrock Titan Image, Hugging Face SigLIP)을 적용하여 높은 검색 품질을 달성하였습니다.
  • 비용 효율성: Amazon Bedrock의 종량제 과금 모델과 Cross-Region Inference 기능을 활용하여 안정적이면서도 경제적인 서비스 운영이 가능했습니다.
  • 도메인 특화 최적화: 와인의 빈티지(년도) 정보까지 고려한 세밀한 검색 로직을 통해 검색 신뢰도를 높였습니다.

향후 발전 방향

GS리테일은 현재 서비스의 지속적인 개선을 계획하고 있습니다. 검색 실패율 30%의 주요 원인인 온라인 미취급 상품 문제를 해결하기 위한 온/오프라인 상품 동기화 작업을 진행하고 있으며, 고객이 찾는 상품 데이터를 분석하여 경영주 대상 발주 상품 추천 서비스로 확장하는 방안도 검토 중입니다. 또한 유사도 임계값 조정과 추가적인 프롬프트 엔지니어링을 통해 검색 정확도를 향상을 통해 고객 경험을 한층 더 개선할 수 있을 것으로 기대합니다.

앞으로도 GS Retail에서는 생성형 AI를 활용한 지속적인 서비스 개선과 확장을 통해 혁신적인 고객 중심 서비스를 제공할 계획입니다.

안호빈

안호빈 매니저는 GS리테일 O4O DX팀 검색추천파트 소속으로, 우리동네GS 검색 개발 및 설계와 운영을 맡고 있습니다. 끊임없이 변화하는 트렌드와 기술에 도전하며, AI 기반의 검색 기술을 적극 활용해 더 나은 검색 경험을 만들어가고 있습니다.

박동우

박동우 매니저는 GS리테일 O4O DX팀 검색추천파트 소속으로, 우리동네GS 어플리케이션의 추천 서비스 개발과 시스템을 최적화하는 업무를 담당하고 있습니다.

박성화

박성화 매니저는 GS리테일 O4O DX팀 소속으로, Flutter와 React 기반의 우리동네GS 앱 개발 및 운영을 담당하고 있습니다.또한 프론트엔드 분야의 새로운 기술과 트렌드에 대한 관심이 많아, 이를 실제 서비스에 적용할 수 있도록 연구하고 활용하는 역할을 하고 있습니다.

DongHoon Han

DongHoon Han

한동훈 솔루션즈 아키텍트는 소프트웨어 개발 / 데이터 아키텍트 / IT 거버넌스의 경험을 바탕으로, Enterprise팀에서 Retail 고객을 대상으로 AWS 클라우드 서비스를 활용하고 적용하시는데 어려움이 없도록 도움을 드리는 역할을 하고 있습니다.