TITLE : 추천 시스템의 원리와 구축 사례

YOUTUBE LINK : https://youtu.be/MTAc8-ygAaM PRESENTER : Amazon Web Services Korea DURATION : 00:57:49 PUBLISHED : 2021-11-22

Table of contents

1. TITLE : 추천 시스템의 원리와 구축 사례
2. FULL SCRIPT

FULL SCRIPT

안녕하세요 저는 AWS 솔로 센서 아키텍트 김성민이라고 합니다.

아마존 퍼스널라이드를 중심으로 해서 추천 시스템의 원리와 구축 사례에 대해서 설명을 드릴텐데요.

이번 시간에 드릴 내용은 전체적으로 첫번째로 추천의 정의에 대해서 좀 알아보고 그 다음에 왜 추천이 중요한지 그리고 그렇게 중요한 추천을 성과는 어떤 식으로 측정을 할 수가 있는지 추천 성과에 대한 지표에 대해서 설명을 드릴 거고요 그리고 이제 세번째로는 그렇다면 이런 추천 서비스를 어떻게 구축을 할 수 있는지 특히나 아마존에서 제공하고 있는 퍼스널라이즈라는 서비스를 이용해서 어떤 식으로 구축을 할 수 있는지 설명을 드리고 이제 적용된 아키텍처까지 보여드릴 생각입니다 저희가 이제 추천이란 무엇일까?

추천에 대해서 얘기를 드릴 건데요 제가 합술적으로 정확한 정의를 내리기보다는 추천이라는 것 자체가 이미 여러분들이 일상생활에서 너무나 자연스럽게 접하고 있는 것들이라서 직관적으로 설명을 약간 드린다면 추천하면 약간 떠오르는 단어들이 즐거움, 아니면 뭔가를 탐색한다는 느낌?

추천 같은 경우는 사실 이제 e-commerce에서 제일 중요한 지표라고 생각을 해보면 주로 고객들이 오랫동안 그 커머스 사이트에 체류해야 되니까 이제 리텐션 레이트 같은 고객 체류 시간 그 다음에는 그 사이트에 들어왔을 때 바로 이탈하지 않고 좀 오랫동안 있었으면 하는 그런 첫 레이트 세 번째로는 이렇게 고객들이 그 사이트에 오래 머물면서 최종적으로는 그 상품을 잘 구매하셨으면 그래서 e-commerce 사이트의 매출이 올라가는 것을 기대할 거예요 그래서 이제 구매 전환율 이런 것들이 상당히 중요한 지표인데 앞서 설명드렸던 추천이 갖추는 어떤 느낌들, 즉 탐험을 한다든가 탐색을 한다든가 즐거움을 주는 것들 이런 것들 때문에 기존의 e-commerce 사이트에서 중요한 서비스인 검색이나 결제 이런 거에 비해서 추천이 실제로 e-commerce의 중요한 지표에 상당히 많은 영향을 끼치고 있습니다 특히 이제 이러한 추천을 검색하고 약간 비교해서 설명을 해보자면 사실 추천이랑 검색이랑 상당히 유사한 점이 많거든요 둘 다 다 어떤 사용자가 원하는 아이템이라든가 아니면 그 뭔가 상품이라든가 아니면 어떤 컨텐츠나 이런 것들을 찾아주는 역할이긴 한데 검색 같은 경우는 사용자가 의도적으로 본인이 원하는 결과를 빨리 찾기를 원하기 때문에 약간 정확하고 신속하게 어떤 결과를 내주는 게 초점에 맞춰져 있다면 추천 같은 경우는 어떤 사용자가 의도로 드러내지 않더라도 저희가 그 사용자의 의도를 미리 파악을 해서 먼저 이런 상품은 어떤지 이런 컨텐츠는 어떤지 하고 이렇게 제안을 하는 그런 서비스로서 실제로는 그 사용자가 어떤 기대하지 않았는데 의외로 본인한테 되게 좋은 그런 상품이나 컨텐츠를 제공했을 때 기쁨을 느끼게 할 수 있도록 그런 거를 해주는 게 약간 추천이라고 생각이 들고 그렇기 때문에 이게 검색과 다르게 추천이라는 서비스가 또 필요한 이유이기도 하다고 생각이 듭니다 그래서 이제 이런 추천 같은 경우에 여러가지 알고리즘으로 추천 서비스를 저희가 만들어 볼 수 있는데요 대표적인 세 가지에 대해서 먼저 얘기를 드리면 대부분 콜라보레이션 필터링, 협업 필터링이 있고 그 다음에 컨텐츠 베이스드 필터링, 세 번째로는 협업 필터링과 컨텐츠 베이스드 필터링을 조합해서 사용하는 하이브리드 방식 이렇게 세 가지가 있고요.

이걸 하나씩 차례대로 설명을 드리자면 협업 필터링 같은 경우는 그 말 그대로 앞에 협업이라는 말이 이렇게 들어가 있는데 그게 뭐냐면 내가 누군가에 어떤 추천을 해줄 때 다른 사람의 성향이라든가 아니면 다른 상품의 특징이라든가 이런 것들을 가지고 서로 협업을 해서 결국에는 추천을 해준다 그런 의미에서 협업 필터링이라고 저희가 얘기를 하는데요 왼쪽에서 보이는 그림처럼 만약에 유저 1, 2, 3 이렇게 세 명의 유저가 있는데 만약에 제가 유저 3한테 딸기랑 수박 같은 걸 샀을 때 그 외에 다른 상품 어떤 걸 추천하면 좋을까 이걸 생각해 봤을 때 유저 3하고 가장 유사하게 상품을 구매했던 유저 1의 상품 구매 내역을 이용해서 추천을 하는 거죠 그래서 유저 1 같은 경우는 유저 3하고 동일하게 딸기랑 수박도 구매를 하고 또 그 외에 포도랑 오렌지도 구매를 했기 때문에 실제 유저 3에는 추천을 해줄 때 포도랑 오렌지를 추천을 해주는 거죠 반대로 첫 번째 얘기 드렸던 것은 어떤 사용자들을 묶어서 그 사용자들의 기호를 이용해서 추천을 해주는 건데 반대로 그렇다면 상품 추천을 하는데 그 사용자의 기호를 파악하는 게 아니라 그 상품이 어떤 상품하고 같이 잘 팔렸는지를 이용해서 또 추천할 수도 있거든요 똑같은 방식으로 만약에 포도를 산 사람한테 어떤 상품을 같이 추천해 주는 게 좋을까 이걸 살펴보면 실제 여러 유저들이 포도랑 딸기랑 같이 산 것보다 아니면 포도랑 오렌지랑 같이 산 것보다 포도랑 수박을 같이 산 게 지금 벌써 유저가 3명이 그렇게 샀거든요 유저 1도 그렇고 유저 2도 그렇고 유저 3도 그렇고요 그렇기 때문에 실제 만약에 어떤 사용자가 포도라는 과일을 사고 싶다 이렇게 관심을 보인다면 그때 수박을 이렇게 추천해 주는 방식으로 이렇게도 할 수 있는 거죠 이런 방식이 여러분의 협업 필터링이라고 얘기를 하고요 그 다음에 두 번째로 컨텐츠 베이스드 필터링으로 하는 것은 컨텐츠라는 게 일종의 저희가 텍스트 형태로 되어 있는 어떤 글이라든가 이런 블로그라든가 뉴스라든가 이런 걸 생각하시면 쉽거든요 그렇기 때문에 만약에 어떤 사용자가 자기가 어떤 뉴스라든가 블로그 포스팅이라든가 이런 걸 읽었다 그렇다면 그렇게 읽었던 내용하고 가장 유사한 어떤 뉴스나 블로그 포스팅을 찾아서 그 사람한테 추천을 해주면 좋지 않을까 이런 방식이 컨텐츠 베이스드 필터링이고 그래서 컨텐츠 베이스드 필터링하고 협업 필터링은 서로 장단점이 명확한데요 협업 필터링 같은 경우는 사실상 컨텐츠의 내용은 분석할 필요가 없이 추천이 가능합니다 아까 처음에 제가 예로 보여드렸던 것처럼 과일을 산다고 했을 때 그 사용자가 어떤 과일을 샀는지 어떤 아이템을 샀는지에 대한 행동 로그만 있다면 추천이 가능하고 그렇기 때문에 컨텐츠 분석 없이 로그만 있으면 추천이 가능하니까 실제로는 다양한 곳에 적용이 가능하거든요 반면에 컨텐츠 베이스드 필터링 같은 경우는 앞서 얘기 드렸듯이 어떤 뉴스라든가 블로그 같은 그런 컨텐츠를 분석을 해야지 추천이 가능하기 때문에 실제로는 적용 도움이 상당히 제한적이에요 상대적으로는 그래서 이제 어떤 음악이라든가 영화의 장면 같은 이런 거 같은 경우에는 이제 사실은 컨텐츠 분석이 어렵기 때문에 적용하기 좀 쉽지가 않죠 하지만 컨텐츠 베이스드 필터링 같은 경우는 사용자의 행동 로그가 없이도 추천이 가능하기 때문에 만약에 저희가 쇼핑몰을 처음에 하나 오픈을 했는데 그 오픈한 쇼핑몰이 처음 오픈한 거라서 사람들이 많이 방문 안 했겠죠 그렇다면 사실상 사용자들의 행동 로그가 없기 때문에 추천 계산을 하기가 어려운데 근데 그 쇼핑몰에 다양한 컨텐츠가 있다 어떤 상품에 대한 메타 정보라든가 이런 것들이 다양해서 컨텐츠 분석만으로도 추천이 가능할 것 같다 하면 컨텐츠 베이스드 필터링 방식으로 추천을 할 수가 있는 거죠 그래서 실제로는 이런 식으로 콜라보레이티브 필터링, 협업 필터링 같은 경우는 사용자의 행동 로그가 부족했을 때 추천하기가 어려운 그런 콜드 스타트 문제가 발생을 하는데 컨텐츠 베이스드 필터링 같은 경우는 콜드 스타트 문제를 약간 완화해 줄 수가 있다는 거죠 그래서 이러한 두 가지 협업 필터링과 컨텐츠 베이스드 필터링의 장점을 모두 활용해서 사용하는 방식이 하이브리드 방식이라고 저희가 보통 얘기를 합니다 그렇다면 이러한 추천을 어떤 방식으로 적용을 할까 이거에 대해서도 생각해 볼 수 있는데요 첫 번째 방식은 모든 추천 결과를 사용자마다 동일하게 내보내는 방식이에요 그래서 왼쪽 그림에 보시면 non-personalization이라고 하는 것들이 실제 모든 사용자마다 동일한 추천 결과를 보여주는 거고 오른쪽에 보이시는 것이 실제로 개인화된 추천 결과를 보여주는 거죠 즉 사용자마다 다른 추천 결과를 보여줌으로써 실제 그 사용자의 만족도를 훨씬 더 올려주는 그런 방식으로 적용할 수가 있거든요 그래서 지금까지 얘기했던 내용을 다시 한번 정리를 해보면 추천이라는 것을 크게 저희가 어떤 데이터를 사용하냐 그리고 어떤 식으로 적용하느냐에 따라서 분류를 해볼 수가 있는데 만약에 데이터 관점에서 본다면 사용자의 행동로그 즉 사용자가 어떤 아이템에 어떤 인터랙션을 했는지에 대해서 그런 데이터를 가지고 추천을 한다 그러면 협업 필터링이라는 알고리즘을 사용하게 되는 거고 그렇지 않고 그냥 컨텐츠 만으로도 추천하겠다

그러면 이건 컨텐츠 베이스드 추천이 되게 됩니다 그리고 협업 필터링 같은 경우는 콜드스탑 문제가 발생하기 때문에 이 두 가지를 섞어서 사용하는 방식이 하이브리드 방식 이렇게 이해하시면 될 것 같고요 그리고 이러한 추천을 어떤 방식으로 적용하냐에 따라서 개인별로 동일한 결과를 보여주느냐 아니면 다른 결과를 보여주냐에 따라서 non-personalization하고 personalization 이런 식으로 구분을 할 수 있다고 생각하시면 됩니다 여기까지 들어보면 사실은 추천을 적용을 하지 않을 필요가 없고 반드시 적용을 해야 될 것처럼 많이 생각이 드실 거예요 그래서 실제로 e-commerce 고객분들이 추천 서비스에 대한 도입에 대해서 상당히 적극적인데 근데 이제 사실은 이런 추천 서비스를 도입을 하려고 했을 때 실제 내부적으로 개발을 한다든가 적용하는 것 자체가 상당히 반복적이고 어려운 작업이거든요 그래서 이 과정들을 한번 쭉 살펴보면 처음에 추천에 대한 요구사항을 정리를 하고 거기에 맞는 데이터를 준비한 다음에 거기에 맞춰 추천에 효과를 가장 잘 낼 수 있는 모델을 개발하고 그걸 실제 배포하고 적용하는 이런 단계로 흘러갈 거예요 그렇지만 이게 한 번에 이루어지는 게 아니라 만약에 추천 모델을 개발하다가도 그 모델에 필요한 피처 값들 아니면 인풋 값들이 변경이 된다든가 아니면 모델 개선을 위해서 새로운 데이터가 필요하다면 데이터 준비부터 다시 시작을 해야 되고 또 이제 배포해서 운영을 하더라도 항상 그 추천 모델이 가장 좋은 성능을 낸다고 볼 수가 없기 때문에 항상 AB 테스트 같은 걸 통해서 개선을 하셔야 될 텐데 이런 것들이 상당히 반복적으로 일어나기 때문에 일어나고 또 한 가지 이렇게 한 단계, 각각의 단계마다 시간이 오래 걸릴 수가 있거든요 그렇기 때문에 이러한 부분들을 저희 AWS에서 약간 고객분들의 부담을 덜어주고자 저희가 이제 만든 서비스가 API 형태로 추천 서비스를 제공해주면 어떨까 그렇게 나온 서비스가 아마존 퍼스널라이즈라고 하는 서비스거든요 실제로 아마존 닷컴에서 사용하는 어떤 기기학습 기술을 사용해가지고 여러분들한테 실시간 개인학 라든가 그냥 비개인학 추천 서비스를 제공해드리고 아마존 닷컴에서 사용하는 머신러닝 기술을 사용했기 때문에 상당히 높은 품질의 추천을 제공합니다 그리고 여러분들이 앞서 제가 설명드렸던 것처럼 추천 서비스에 대한 개발과 적용이 실제로 상당히 오랜 기간 동안 걸리는데 만약에 데이터만 준비가 돼 있다면 실제 퍼스널라이즈를 이용을 하셔가지고 1, 2주 만에 추천 서비스를 개발을 하실 수가 있거든요 그리고 퍼스널라이즈 경우에는 어떤 사용자의 인터렉션 데이터를 가지고 추천을 하기 때문에 실제로 다양한 곳에 추천 서비스를 적용할 수가 있습니다 퍼스널라이즈에 대해서 조금 더 동작 방식이나 이런 부분에서 좀 더 구체적으로 살펴보면요 먼저 추천을 하려면 데이터가 필요한데 퍼스널라이즈에서 사용하는 데이터는 크게 3가지 데이터거든요 첫 번째로 가장 중요한 데이터는 그 사용자가 어떤 아이템, 상품이라든가 아니면 컨텐츠라든가 이런 것들에 대해서 어떠한 행동을 했는지, 그 사용자의 인터렉션 데이터가 필요하고 그리고 그 사용자가 인터렉션을 했던 아이템에 대한 메타 정보들 어떤 카탈로그라든가 아니면 가격 정보라든가 그런 것들, 그 다음에 세 번째는 그 사용자 자체의 어떤 정보들 즉 여성인지 남성인지 연령대는 어떤 건지 이러한 정보들이 필요하고요 이 중에 필수로 필요한 것은 실제로는 사용자의 인터렉션 정보만 필요하면 추천을 계산할 수가 있고 이러한 추천데이터를 일단은 S3에 저장을 하시면 그 데이터를 읽어가지고 저희가 데이터셋 그룹이라는 걸 만들어가지고 퍼스널라이저 관리를 합니다 그래서 그 데이터가 들어오면 그 데이터를 가지고 퍼스널라이저에서 제공하는 여러가지 알고리즘이 있는데 그 알고리즘 중에 하나를 선택하신 다음에 그걸 선택하셔가지고 실제 추천 모델을 개발하시는 거죠 그래서 추천 모델이 만들어지면 그 다음에 실제로 그 추천 모델을 이용을 해가지고 API 호출을 했을 때 추천 결과를 보내줄 수 있도록 저희가 추천 서비스 할 수 있는 엔드포인트 저희는 캠페인이라고 부르는데

그 캠페인이라는 것을 자동으로 만들어지고 만들어지시면 그때는 이제 API 호출로써 추천을 바로 사용하실 수가 있는 거죠 그래서 실제 아마존 퍼스널라이저를 웹 콘솔에서 AWS 웹 콘솔에 들어가 보시면 지금 보시는 것 같은 그림 모양이 생길 텐데요 맨 먼저 하실 일은 데이터셋 그룹이라는 걸 지정을 해주시고 그 다음에는 실제 그 데이터들을 업로드를 해주는 작업을 하십니다 그 다음에는 앞서 얘기 드렸던 여러가지 알고리즘 중에 여러분들이 필요한 알고리즘을 선택하신 다음에 실제 학습을 시키는 거죠 그리고 그렇게 학습된 결과를 가지고 실제 API 호출로 추천 서비스를 할 수 있도록 엔드포인트를 만드는 작업 이렇게 크게 네 가지 단계를 거쳐서 이루어지고요 그러면 이제 좀 더 하나씩 살펴보면 먼저 제일 궁금하신 게 아마 데이터를 그러면 어떻게 준비를 해야 될까 그리고 또 어떤 데이터들이 좀 필요한가 여러 번 얘기를 드리긴 했지만 다시 한번 정리를 드리자면 크게 세 가지 데이터가 필요하고 첫 번째는 사용자에 대한 메타 정보들 연령이라든가 성별 또는 그 사용자가 어떤 멤버십이 있는지 아닌지 이런 부분들 그 다음에는 그 사용자들이 어떤 아이템에 대해서 행동을 했는지 그 사용자가 어떤 인터랙션을 했던 아이템에 대한 정보들 가격이라든가 아니면 상품에 대한 아이디라든가 지금 재고가 있는지 없는지 이런 메타 정보들 그 다음에 마지막으로 세 번째 가장 중요한 그 사용자가 그 아이템에 어떤 행동을 했는지 장바구니에 담았는지 단순히 보기만 했는지 아니면 실제 구매까지 했는지 이런 부분들에 대한 로그들이 시계 데이터로 이렇게 좀 있어야 되거든요 그리고 실제 이런 데이터들을 퍼설라이즈가 활용을 하기 위해서는 S3에 CSV 형태의 포맷으로 저장을 해야 됩니다 예를 보여드리자면 이제 지금 보시는 형태의 데이터 포맷이 될 텐데요 맨 위에 첫 번째 줄은 이 CSV 파일에 각각의 그 컬럼이 어떤 아이템, 컬럼에 대한 이름인 거죠 이름이 이렇게 쭉 있고 그 다음에 실제 아래로는 데이터들이 이렇게 들어가 있어요 근데 이제 이렇게 CSV 형태의 포맷으로 데이터를 저장하면 되는데 이제 여기서의 문제점은 뭐냐면 그러면 저 두 번째 줄에 있는 19624A 클릭 이런 것들이 있는데 이게 숫자인지 아니면 문자일인지 아니면 이게 어떤 시간인지 타임스탬프 값인지 이런 것들에 대해서는 그 데이터에 대한 데이터 타입을 좀 더 정확하게 알려줘야지 퍼설라이즈가 계산을 할 수가 있는데요 그렇기 위해서 저희가 아까 얘기 드렸던 처음에 얘기 드렸던 세 가지 데이터 타입에 대해서 그 데이터 종류별로 각각의 데이터가 어떠한 의미를 갖고 있는지 그 데이터에 대한 스케마를 정의할 수가 있거든요 그래서 지금 예로 보여드린 게 유저 아이템, 인터랙션 이렇게 세 가지를 보여드렸고 이제 자세히 보시면 공통적으로 보이는 포맷이 첫 번째 타입, 이 전체 레코드가 어떤 타입인지 그래서 레코드라고 얘기를 하시면 되고 그 다음에 실제 이게 유저 데이터인지 아이템 메타데이터인지 인터랙션인지 네임 부분에 적어주시고 네임 스페이스에는 저희가 퍼설라이즈에서 사용하는 스케마이기 때문에 고정된 값인 지금 보여드리는 이 값을 넣어주시면 되고요 그 다음에 필드 부분에 실제로 지금 CSV에 각각의 데이터, 즉 컬럼들이 어떠한 데이터 타입을 갖고 있는지 그게 인티지인지 스트링인지 아니면 타임스탬프인지 이런 것들을 이렇게 설명을 해주시면 돼요 그래서 그걸 필드라는 어트리뷰티에 정의해주시고 그 다음에 마지막으로 버전 이렇게 이런 식으로 스케마를 작성하신 다음에 앞서 만들었던 그런 cs 포맷 상태의 데이터와 이 스케마를 같이 퍼설라이즈에 넣으신 거죠 이렇게 넣으시면 실제 추천을 계산할 수 있습니다 그럼 이제 여기까지 하면 데이터는 어떻게 만들면 되겠다 이런 것까지는 감이 오실 텐데 그 다음에 이제 고민되시는 부분이 그렇다면 데이터를 진짜로 어느 정도나 준비를 해야지 우리가 추천을 제대로 할 수 있을까 그러니까 1년치의 데이터가 필요한지 아니면 한 달치의 데이터 아니면 일주일치의 데이터만 있어도 추천 계산이 가능한 건지 이런 부분에서 고민이 되실 거예요 근데 이제 저희가 이 부분은 일괄적으로 딱 이 이상은 하셔야 돼요 이렇게 얘기들이 어려운 게 고객사분들의 워크로드라든가 아니면 그 사이트의 특징에 따라서 조금씩 달라질 수가 있거든요 그렇지만 이제 약간 보편적으로 그냥 저희가 약간 제안드리고 싶은 사이즈라고 얘기 드리자면 대략 유저 데이터 같은 경우는 한 50명 이상의 유니크한 유저들이 좀 있었으면 되고 그 다음에 아이템 역시도 50개 이상의 아이템이 좀 필요하고요 그 다음에 인터랙션 같은 경우는 한 1500개 정도의 인터랙션 로브가 있는 게 최소라고 생각하시면 될 것 같습니다 그래서 이렇게 데이터까지 준비를 했다면 그렇다면 퍼스널라이즈를 가지고 어떤 추천을 할 수가 있을까 이런 부분에 대해서 궁금하실 건데 퍼스널라이즈가 제공하는 추천 방식은 크게 세 가지 방식을 제공하고 있거든요 첫 번째로는 사용자마다 다른 추천 결과를 보여주는 개인화 추천이 있고 두 번째는 비슷한 상품을 추천을 해주는 유사 상품에 관련된 추천 세 번째는 퍼스널라이즈랭킹이라고 해서 이렇게 생각해 보시면 쉬운데 저희가 검색을 했을 때 항상 사용자마다 동일한 검색 결과를 주로 보여줄 텐데 그런데 실제로는 사용자마다 원하는 결과가 조금씩 다를 거거든요 그리고 이렇게 특히나 지금 예에서 보이는 것처럼 어떤 클래식 음악을 검색을 해서 이렇게 노출을 시키는데 어떤 사람은 베토벤을 좋아할 수도 있고 어떤 사람은 바을을 좋아할 수가 있으니까 이런 사용자의 기호를 미리 알고 있다면 동일한 검색 결과라던가 이런 경우에서도 서로 순위를 바꿔서 보여주면 그렇다면 사용자의 만족도가 올라가는데 이럴 때 사용하는 게 퍼스널라이즈랭킹이라는 방식이 있습니다 그래서 개인화 추천부터 살펴보면 개인화 추천에서 사용할 수 있는 알고리즘 저희는 추천을 알고리즘을 퍼스널라이즈 레시피라고 얘기를 하는데 그 레시피 종류가 크게 4가지 정도가 있는데 한 5가지 정도가 있거든요 지금 중간에 보이시는 거는 레거시가 돼서 지금은 대부분 다 유저 퍼스널라이즈 제시어라고 하는 그 레시피에 다 통합이 되어 있는 거고 맨 마지막 아래에 있는 거 즉 popularity count라고 하는 거는 그냥 인기 상품이라고 생각하시면 돼요 그래서 저 popularity count 같은 경우는 실제로 전혀 사용자의 어떤 행동로그가 상당히 적었을 때 그리고 그 사용자에 대한 행동로그를 아직 추천에 반영을 못했을 때 추천 계산에 반영을 못했을 때 저희가 콜드스탑 문제를 해결하기 위해서 사용하는 그런 알고리즘을 생각하시면 되고 일단 개인화 추천을 하신다고 생각하신다면 유저 퍼스널라이즈 제시어를 사용하시면 됩니다 그 다음에 유사 상품을 추천하겠다 하신다면 sims라고 하는 그런 레시피가 있고 마지막으로 퍼스널라이즈 랭킹 같은 경우는 퍼스널라이즈 랭킹이라고 하는 그런 레시피 이렇게 있다고 생각하시면 되고요 지금까지 했던 내용을 마찬가지로 한 번 더 정리를 해보면 아마존 퍼스널라이즈라고 하는 것도 일종의 추천의 일종이고 그 다음에 그거를 마찬가지로 데이터 관점과 실제 어떤 식으로 적용하나에 따라서 분류를 다시 해보면 퍼스널라이즈 역시도 데이터를 주로 어떤 컨텐츠 자체를 쓰는 게 아니라 사용자가 아이템에 어떠한 인터랙션을 했는지 인터랙션에 대한 데이터를 중심으로 가지고 추천을 하는 거라서 대부분 유저 퍼스널라이즈션, 파퓰렛 카운트 sims 퍼스널라이즈 랭킹과 같은 레시피가 모두 다 콜라보레이터 방식처럼 사용자의 행동록으로 계산이 된다 이렇게 이해하시면 될 것 같고 그 다음에 적용하는 방식에 따라서는 비개인화, 즉 모든 사용자한테 동일한 결과를 보여주는 레시피는 sims, 파퓰렛 카운터 이렇게 두 가지가 있고 그 다음에 개인화를 하고 싶다고 한다면 유저 퍼스널라이즈 제시와 퍼스널라이즈 랭킹 두 가지 레시피를 사용하시면 됩니다 여기까지는 일반적인 추천에 대한 얘기였다고 그리고 특히나 퍼스널라이즈가 어떠한 기능들을 제공하는지 이런 거에 대해 설명을 드렸다면 궁금해하실 점이 그렇다면 정말 좋은 추천이라는 게 뭔지 이렇게 적용을 해봤는데 이게 추천이 정말 효과가 있는지 없는지 판단을 하고 싶어 하실 거예요 특히나 적용 전에 판단을 많이 하고 싶어 하시겠죠 그래서 이렇게 추천을 적용하기 전에 저희가 추천의 성능을 평가해볼 수 있는 방법으로는 그게 커버리지랑 렐러번스라고 하는 두 가지 지표를 가지고 평가를 할 수가 있거든요 커버리지라는 거는 우리가 추천 결과를 모든 사람한테 주면 좋은데 모든 사람한테 줄 수가 없기 때문에 만약에 지금 전체 고객들 중에 몇 %까지 추천 결과가 정상적으로 나가는지 이걸 측정하는 게 커버리지라고 생각하시면 되고 그 다음에 렐러번스 같은 경우는 제가 추천을 검색하고 상당히 유사하다고 설명을 드렸듯이 그러면 추천하는 그 상품이 정말로 그 사용자의 선호도라든가 아니면 그 상품하고 상당히 관련성이 높은지 이걸 측정하는 게 렐러번스라고 생각하시면 되고요 일종의 정확도라고 생각하셔도 됩니다 렐러번스를 측정하는 방법은 지금 보이시는 것처럼 세 가지 매트릭을 저희가 제공해드리고 있는데 이거에 대한 자세한 내용은 밑에 보이시는 링크가 있는데 거기를 참조하시면 될 것 같고요 여기서는 조금 더 디테일하게 설명을 드리는 것보다는 직접 한번 보시는 게 좀 나을 것 같고 제가 또 한 가지 얘기를 드리고 싶은 거는 앞서 얘기 드렸던 커버리지랑 렐러번스 같은 경우는 사실 추천을 적용하기 전에 이미 확인을 할 수가 있는 상황이긴 해요 하지만 추천에서 제가 앞서도 계속 얘기 드렸던 부분이 추천이라는 걸 저희가 쓰는 이유가 단순히 검색과 다르게 어떤 사용자가 자기가 뜻하지 않는 새로운 걸 발견할 수 있는 기쁨을 주기 위한 용도로 저희가 사용할 수 있다고 얘기 드렸는데 그런 걸 측정하는 게 세렌디픽트라고 하는 게 있거든요 일종의 서프라이즈 같은 그런 느낌이죠 근데 이제 사실상 커버리지랑 렐러번스 기준으로 추천을 평가한다면 이거는 기존의 검색에 대한 품질을 평가하는 거랑 거의 차이가 없거든요 그렇다면 굳이 추천을 도입할 필요가 없을 수도 있어요 근데 사실상 저희가 추천이 필요한 거는 결국에는 사용자들한테 어떤 발견의 기쁨 아니면 그런 즐거움을 계속 주므로써 사용자들이 오랫동안 쇼핑몰에 체류를 하게 되고 그래서 자연스럽게 구매를 할 수 있도록 이렇게 유도하는 게 결국에는 추천의 목적이기 때문에 이게 단순히 커버리지랑 렐러번스 위에도 저런 세렌디픽트라고 하는 것들을 측정이 되고 그런 것들을 높일 수 있도록 추천을 계산하는 게 상당히 중요하거든요 특히나 이런 세렌디픽트가 왜 중요한지를 제가 그 예를 들어서 설명을 드리자면 맨 왼쪽에 보이시는 것처럼 어떤 사용자가 시계를 봤을 때 저희가 위쪽에 상단에 보이는 것처럼 시계만 이렇게 쭉 추천을 해줄 수도 있어요 그렇지만 이렇게 하면 상당히 좀 단조롭죠 물론 되게 비슷한 시계랑 고급 시계도 있고 이렇게 하지만 그렇지만 밑에 추천된 상품을 봤을 때는 좀 약간 느낌이 다른 게 앞에 세 개는 시계에 관련된 것들이 추천이 됐지만 뒤에 두 개 같은 경우는 이게 약간 아웃도어형 시계이기 때문에 아 이 사람은 등산이라든가 이런 레포츠를 즐길 것 같다 그러니까 그런 레포츠용 자켓이라든가 등산화 같은 걸 같이 추천을 해줬을 때 좀 효과가 더 좋지 않을까?

이런 부분이 담당하는 게 일종의 세렌디피티라는 거죠 그래서 결국에는 이런 세렌디피티는 사용자들에게 계속 어떤 그 상품에 대한 관심을 계속 이어가도록 만들어주는 거기 때문에 추천에서는 상당히 중요한 지표이고 이것들을 결국에 측정을 하려면 단순히 그냥 추천을 계산한 다음에 측정할 수 있는 게 아니라 실제로 추천을 적용하신 다음에 ABT를 통해서 계산하는 게 가장 빠르고 정확한 방식이거든요 그래서 세렌디피티를 잊지 마시고 꼭 이렇게 측정할 수 있도록 생각하시면 될 것 같고요 그래서 여기까지 들으면 추천은 상당히 좋고 뭔가 적용할 만한 가치가 있을 것 같긴 한데 정말 그러면 아마존 퍼스널라이즈도 그러한 가치가 있는 건지 정말 효과가 있는지 이런 데에 대해서 또 이제 의문이 있으실 거예요 근데 이제 실제 저희 같은 경우에 퍼스널라이즈를 도입한 여러 고객들이 있는데 그 고객들 중에 브랜드라고 하는 아시는 분도 있을 텐데 브랜드라고 하는 이커머스 고객사 같은 경우에도 퍼스널라이즈를 적용하신 다음에 평균 클릭 수라든가 상품 클릭 자체가 상당히 많이 증가를 하셨어요 그래서 이러한 퍼스널라이즈 효과를 모두 맛보신 고객들이 지금 국내에서는 브랜드 외에도 다른 여러 고객들이 있고 해외에서도 지금 여기에서 이 슬라이드에는 몇 개밖에 담지는 않았지만 실제로 많은 고객들이 퍼스널라이즈를 사용하고 만족스럽게 효과를 보고 계시거든요 그래서 여기까지 퍼스널라이즈 얘기를 쭉 이론적인 부분만 설명을 드렸는데 그렇다면 실제 어떻게 적용을 할 수가 있고 동작을 하는지 그걸 제가 데모로 한번 잠깐 보여드리겠습니다 그래서 퍼스널라이즈 적용을 하실 때 맨 먼저 이러한 웹 콘서트에서 퍼스널라이즈 메뉴 들어가신 다음에 그 다음에 첫 번째로는 퍼스널라이즈가 사용할 데이터셋 그룹을 이렇게 만드십니다 그 다음에 데이터셋에는 크게 3가지의 데이터, 유저, 아이템, 그 다음에 인터랙션 데이터 3가지를 넣으셔야 되는데 인터랙션 데이터만 있어도 추천이 가능하기 때문에 지금 보시는 것처럼 인터랙션 데이터를 넣기 위해서 미리 그 데이터의 스키마를 정리하는 작업을 하는 거죠 그래서 이렇게 스키마를 정리를 하시고 여기서는 MovieLens라고 하는 사용자가 영화에 대한 평점을 매긴 데이터를 가지고 추천을 할 건데요 실제로 이렇게 스키마를 만드신 다음에 그러면 S3에 있는 데이터를 퍼스널라이즈 쪽으로 임포트할 수 있는 작업을 이렇게 만듭니다 그리고 인포드 데이터 위치를 지정해 준 작업을 할건데요 S3에 미리 올려놓은 import data width path를 적으시고 뒤에 폴더 부분까지 적어주시면 되거든요 이렇게 하시면 실제로 임포트 작업이 생성이 되고 그러면 데이터셋 부분에서 스키마를 만들어져 있고 임포트 작업이 진행이 되고 다 끝나면 active 상태가 변경이 되거든요 다시 데시보드에서 와보시면 다음 단계로 넘어가죠 이번에는 데이터를 가지고 실제 모델을 만드는 작업 그래서 모델 이름을 적어주시고 실제 어떤 알고리즘을 써서 하실 건지 여기서는 개인화 추천을 할 거기 때문에 user personalization하는 레시피를 사용할 거고요 그 다음에 실제로 모델을 학습시키기 위한 작업을 시작시키면 보통 데이터 양에 따라서 시간이 조금 오래 걸릴 텐데 지금 여기서는 데모라서 제가 짧게 줄여본 거고요 그래서 저런 모델이 다 만들어지면 그 다음 단계인 실제 그 모델을 api 서버로 호출할 수 있는 엔드포인트를 만드는 작업을 합니다 저희는 캠페인이라고 여기서 얘기를 하고 엔드포인트 이름을 입력을 하시고 그리고 저희가 처음 만들었던 모델에 대한 이름 나머지 설정들을 이렇게 해주시고 캠페인을 생성을 해주시면 출원할 수 있는 엔드포인트가 생성이 되는 거거든요 그래서 엔드포인트 생성까지 시간이 좀 걸리는데 상태가 액티브 상태로 되면 여기에 실제로 아이템 아이디나 아니면 유저 아이디를 넣어가지고 결과를 보실 수가 있거든요 그래서 지금 s3에 저장되어 있는 실제 인풋데이터를 가지고 저희가 테스트를 해볼 건데요 실제 데이터들이 저런 형태에 들어가 있고 저희는 개인화 추천이기 때문에 유저 아이디 298번에 대해서 결과를 한번 보면 이런 식으로 추천 결과가 나오고 만약에 다른 사용자라면 또 다른 식으로 결과가 나와야 되겠죠 만약에 196번 아이디로 한번 검색을 해보면 또 다른 식으로 결과가 나오죠 그래서 이렇게 추천 결과를 확인해 보실 수가 있고 그래서 다시 한번 쭉 정리를 해보면 저희가 맨 처음에 스키마를 정리를 해서 데이터셋을 임포트했고 그 다음에 솔루션을 만들고 캠페인을 만들고 해서 데이터셋은 유저 인터랙션 데이터를 저희가 사용했고요 그 다음에 솔루션을 만들 때는 퍼스널라이저로 하는 레시피를 사용했고 엔드포인트 이걸 사용해가지고 추천 서비스를 이렇게 한번 만들어봤습니다 그렇다면 여기까지는 AWS 퍼스널라이저를 어떤 식으로 쓸 수 있겠다 이렇게 이해를 하셨을 것 같은데

그러면 아키텍처 관점에서 어떤 형태로 퍼스널라이저를 도입할 수 있는지 차근차근 제가 설명을 드릴 텐데요 맨 먼저 저희가 가장 쉽게 생각해 볼 수 있는 게 일반적인 e-commerce 쇼핑몰을 하면 대략 이런 형태의 3티어나 2티어 형태의 웹서비스라고 생각하실 수 있을 거예요 웹서버가 하나 있고 그 다음에 데이터베이스 안에 사용자 아카운트에 대한 정보, 프로덕트 아이템들에 대한 정보 그 다음에 그것들에 대한 트랜저스의 정보들이 각각의 테이블에 저장이 되어 있고 사용자들은 쇼핑몰을 방문했다든가 상품을 봤다든가 아니면 장바구니에 담았다든가 구매를 했다든가 이러한 행동들이 실제 웹서버를 통해서 DB 앱 저장되는 이러한 구조가 될 텐데 이런 상태에서 저희가 추천 서비스를 도입을 하고 싶다 그렇다면 추천 서버 같은 걸 만들어가지고 추천 요청을 하면 그 결과를 돌려주는 이렇게 구조를 만들어갈 건데 그때 저희가 저 추천 서버로 아마존 퍼스널라이저를 활용하실 수 있다는 거죠 퍼스널라이저는 앞서 퍼스널라이저 동작 방식을 설명드렸듯이 유저라든가 아이템이라든가 인터랙션에 대한 데이터들을 퍼스널라이저 내부로 임포트를 시켜야 되는 거고 그 다음에 알고리즘을 통해서 레시피를 통해가지고 솔루션을 만들고 그 다음에 그렇게 만들어진 솔루션을 활용할 수 있는 엔드포인트를 만드는 이런 작업들을 해야 되는데요 그렇다면 그런 작업들이 지금 제가 데모에서도 보여드렸던 것처럼 중간중간에 사람이 개입을 해가지고 작동을 시켜줘야 돼요 실제로 웹 콘솔에서 하실 때는 근데 사실 그렇게 하면 만약에 저런 추천 서비스를 여러 개를 쓰겠다고 하시면 상당히 번거로우실 거고 그 다음에 작업이 끝날 때마다 기다렸다가 사람들이 그걸 또 해야 되기 때문에 아 이걸 어떻게 자동화를 할 수 있을까 이런 데 고민이 되실 거예요 그때 이제 저희가 사용할 수 있는 방법이 AWS Step Function이라고 하는 워크플로우 엔진이 있는데 이걸 사용하시면 퍼스널라이즈에서 필요한 데이터셋 그룹을 만들고 그 다음에 데이터셋을 임포트하고 그 다음에 레시피로 솔루션을 만들고 캠페인을 만드는 이 작업들을 한 번에 클릭으로 처리를 할 수 있다는 거죠 그래서 Step Function을 이용해가지고 어떤 데이터셋에 대한 정보를 S3 버킷에 넣어주면 S3 버킷에서 트리거가 돼서 그 다음에 실제 퍼스널라이즈 작업들이 쭉 돌고 그 작업들이 다 끝나면, 즉 캠페인까지 다 만들어지면 그게 사용자한테 SNS 서비스를 통해서 전달이 되고 이런 형태로 저희가 Step Function을 구성해 볼 수 있고요 Step Function에 대해서 조금만 더 설명을 드리자면 Step Function은 일종의 워크플로우 엔진인데 왼쪽에 보이시는 이 그래프처럼 저희가 어떤 작업을 그래프 형태로 표현을 할 수가 있잖아요 그래서 맨 먼저 시작을 하고 그 다음에 어떤 배치 작업을 서밋을 한 다음에 그게 성공을 하면 성공했다는 노트를 보내고 실패했다면 실패했다는 노트를 보내고 작업이 종료되는 이런 형태로 저희가 보통 이렇게 방향이 있고 그 다음에 사이클이 없는 이런 그래프 형태, 즉 DAG라고 하는 이런 그래프 형태로 작업을 표현할 수가 있는데 근데 이런 작업들을 그래프 형태로 표현을 할 수도 있는데 각각의 그래프의 노드들을 이런 JSON 파일에 attribute로 이렇게 정의를 해가지고 이 작업에 대해서 명세를 할 수가 있거든요 그래서 보시면 start 같은 거, 그 다음에 각 스테이트가 그 다음에 notify, success 이런 부분들이 JSON의 하나의 attribute로 들어가는 거죠 그래서 이런 형태로 작업에 대해서 명세를 하고 이렇게 명세한 작업들을 실제 Step Function한테 요청을 주면 Step Function이 그대로 실행을 한다는 거죠 그래서 실제로 Step Function이 할 수 있는 일들을 좀 더 설명을 드리면 기본적으로는 순차적인 작업들, 어떤 작업이 끝나면 다음 작업을 하고 또 다음 작업을 하고 이런 것들을 할 수 있고 두 번째로는 이 작업의 결과에 따라서 A라는 작업을 하다든가 B라는 작업을 하든가 이렇게 이 부분처럼 브린칭을 할 수도 있고요 세 번째는 만약에 이 작업이 실행을 하다가 실패를 했는데 이때 리트라일을 하면 다시 성공할 수가 있어서 이런 경우에 어느 정도까지 리트라일을 해라 이렇게 반복을 시킬 수 있는 거죠 그 다음에 네 번째로는 어떤 작업 같은 경우는 실제 사람이 그 결과를 한번 보고 승인을 해줘야지 그 다음 단계 넘어가야 되는 그런 식의 작업도 있을 거예요 이렇게 사람이 개입해서 승인을 할 수 있는 이런 형태로도 구성을 할 수가 있고 그 다음에 다섯 번째로는 동시에 여러 개의 작업을 돌리고 싶다 이런 것도 Step Function에도 가능하고요 그 다음에 그런데 그 동시에 여러 개의 작업을 돌리는데 이거를 약간 조건에 따라서 좀 더 어떤 때는 10개로 돌리고 싶고 어떤 때는 5개로 돌리고 싶고 이렇게 약간 동적으로 동시성을 제어를 하고 싶다 이런 부분도 Step Function에서 충분히 가능하고요 그래서 실제로 제가 예제로 보여드린 Step Function을 활용해서 Personalize를 자동화시키는 그 전체 그래프를 한번 보여드리면 이렇게 상당히 복잡해 보이는데

실제로 이런 복잡한 것을 Step Function으로 쉽게 구현을 해가지고 여러분들이 관리를 할 수가 있는 거죠 그래서 제가 Step Function을 도입을 해가지고 이렇게 Personalize의 전체 작업을 이런 식으로 자동화를 시키고 그러면 그 다음에 고민되는 부분은 그런데 이렇게 하면 실제로 지금 DB에 쌓여있는 어떤 사용자라든가 아이템이라든가 트랜잭션한 데이터를 일단 S3로 한번 덤프를 한 다음에 그 다음에 Step Function을 돌려가지고 Personalize를 돌리는 이런 형태가 될텐데 그게 아니라 지금 사용자들이 계속 우리 사이트를 방문하고 그런 사용자들에 대해서도 우리는 추천을 해주고 싶다 그렇다면 그리고 또 기존에 방문했던 사용자들이 또 방문해가지고 새로운 로그를 보내준다면 그것까지 반영을 해서 추천을 해주고 싶다 이런 니즈가 있을 거예요 그래서 결국에는 실시간 어떻게 사용자의 인터랙션 데이터를 업데이트 할 거냐 이런 문제를 풀고자 하실 거예요 그래서 이런 부분을 어떻게 풀 수가 있냐면 저희가 Personalize에서 처음에 보여드렸던 이런 그림은 실제로 배치 방식으로 데이터를 한 번에 덤프를 뜬 다음에 이렇게 쭉 계산하는 건데 이거 외에도 Personalize에서는 이벤트 트리거라고 하는 컴포넌트가 있어서 이 이벤트 트리거에 사용자들의 행동 로그를 실시간으로 계속 업데이트를 할 수가 있습니다 그래서 이벤트 트리거를 통해서 사용자의 행동 로그를 받고 그 이벤트 트리거가 다시 이벤트를 Personalize 쪽으로 보내가지고 추천 계산을 할 때 사용자들 실시간으로 보내는 데이터도 반영이 되도록 이렇게 구성을 하실 수가 있는 거죠 그래서 실제 지금 배치 형태로 돌아가는 이런 형태에서 저희가 이벤트 트리거를 도입을 하고 Personalize 이벤트 트리거를 도입을 한 다음에 그렇다면 웹서버 쪽에서 어떻게 실시간으로 이벤트 트리거 트레이커 쪽으로 데이터를 보낼 수가 있느냐 이 부분을 고민하시면 될 텐데 이때 저희가 사용할 수 있는 방법이 만약에 웹서버에서 Kinesis 데이터 트리거 같은 그러한 분상 퓨 같은 거에 데이터를 사용자의 액션 로그들을 이렇게 쭉 넣어주고 그 다음에 Lambda를 이용해서 Kinesis 데이터 스트림에서 들어온 레코드들을 Lambda에서 이벤트 트레이커 쪽으로 이렇게 푸트해주면 자연스럽게 실시간으로 이벤트 트레이커 쪽으로 사용자의 Interaction 로그를 계속 보내줄 수가 있고 그렇다면 이벤트 트리거가 데이터를 모아가지고 Personalize한테 주고 그 데이터도 역시 실제 추천 계산에 반영이 되는 거죠 그리고 이런 형태로 Kinesis 데이터 스트림을 이용해서 실시간으로 데이터를 수집을 함으로써 기존의 패치 방식으로 사용하실 때는 데이터베이스에서 한 번씩 데이터를 덤프 뜨는 방식으로 다시 S3로 옮겨가지고 추천을 계산했을 텐데 그러실 필요가 없이 웹서버를 통해서 들어온 데이터를 Kinesis 데이터 스트림과 파이얼스를 이용해서 S3로 바로 적재를 하신 다음에 그것들을 모아서 Personalize 배치도 똑같이 돌리실 수 있는 거죠 이런 식으로 해서 실제 데이터베이스에 대한 부하도 좀 더 줄일 수 있고요 이런 형태로 최종적으로는 구성을 해보실 수가 있습니다 여기까지 들으면 Personalize를 이렇게 쓸 수 있고 이런 형태로 구성할 수 있겠다 이렇게 느낌을 좀 받을 수 있을 텐데 여기서 또 한 가지 고민되는 부분이 그런데 우리는 추천 결과에서 특정 결과를 제외를 하고 싶다 만약에 그 사용자가 이미 구매한 상품이라든가 아니면 품절된 상품 같은 경우는 추천 결과에서 뺐으면 좋겠다 이런 니즈가 있을 거예요 그래서 이렇게 추천 결과를 어떤 식으로 필터링 할 수 있느냐 이런 거에 대해서 궁금해하실 텐데 그런 방법이 저희가 크게 두 가지 방식이 있습니다 그 두 가지 방식은 실제로 필터링하는 시점이 어느 시점에 따라서 나눠질 수가 있는데요 맨 아래 그림에서 보이듯이 Personalize는 데이터셋을 만들고 그 다음에 데이터셋을 임포트하고 그 다음에 실제 레시피를 가지고 솔루션을 만드는 이 작업이 할 텐데요 즉 솔루션을 만드는 과정, 모델을 만드는 과정에서 필터링을 하는 방식이 하나가 있고 그 다음에 모델이 다 만들어진 다음에 실제 엔드포인트인 캠페인이 만들어지고 그 엔드포인트에서 엔드포인트로 실제 호출을 하실 때 그 호출한 시점에 동적으로 필터링을 하실 수 있고 이렇게 두 가지 방식으로 필터링을 하실 수가 있고요 그래서 실제로 레시피를 이용해서 추천 모델을 만드실 때는 저희가 유저 인터랙션 데이터셋에 이벤트 타입이랑 이벤트 밸류라고 하는 이러한 필수 컬럼이 있는데 이 두 가지 컬럼을 이용을 해가지고 실제 사용할 데이터셋에서 추천 계산에 필요한 것들만 넣고 필요하지 않는 것들 뺄 수가 있습니다 그래서 이벤트 타입 같은 경우는 이벤트 타입에 상품을 받냐 아니면 구매를 했냐 이런 식으로 이벤트 타입을 정해놓으면 그 중에 내가 구매 데이터만 쓰겠다고 한다면 바이라고 하는 구매 이벤트 데이터 레코드만 사용하겠다고 지정해 주시면 되고 또 반대로 이벤트 밸류 같은 경우는 상품에 대한 상품 평가 같은 걸 하는데 그게 일점에서부터 오전까지 있는데 우리는 최소 2점 이상 받은 상품에 대해서만 추천하고 싶다 아니면 영화를 봤는데 그 영화를 본 사람이 최소 5명 이상이 된 영화에 대해서만 추천하고 싶다 이런 것들을 이벤트 밸류에다가 넣어주시고 그 다음에 이벤트 밸류에 스레쉬 홀드 값을 넣어가지고 그 레코드만 사용할 수 있도록 이렇게 하시는 거죠 다이나믹 필터링 같은 경우는 화면에 보이시는 것처럼 파란색 Exclude 라든가 Include 그 다음에 Where, In 이런 식의 보통 SQL 같은 걸 써보신 분들은 아시겠지만 이런 형태로 저희가 필터링을 할 수 있는 그런 필터링 표현식을 이렇게 작성을 합니다 이렇게 표현식을 작성을 하고 그 표현식을 가져다가 실제로 API를 호출할 때 이쪽에 보이시는 것처럼 제가 실제 API 호출하는 라이브러리의 파라미터를 제가 이렇게 캡쳐를 해왔는데요 여기 보시면 이 표현식에 대한 스트링을 주고 그 다음에 실제 그 표현식에 들어가는 여기 보시면 이제 코미디, 클릭, 스트림 이런 값들을 이렇게 대체를 시키는 거죠 여기 필터 밸류에다가 이렇게 넣어주시면 실제 추천이 나갈 때 그 표현식에서 필터링되는 값을 이용해서 결과를 필터링하는 식으로 보내줄 수가 있어요 그래서 이렇게 다이나믹 필터링을 사용하실 때 필터링할 수 있는 방식은 아이템 메타 정보를 이용해서 필터링하는 방식이 하나가 있고 두 번째는 인터랙션 데이터 즉 사용자가 어떤 행동을 했느냐에 행동 로그 같은 것에 이벤트 타입 같은 걸 이용해서 필터링하는 방법이 있고 또 한 가지는 아이템하고 유저 정보가 동시에 있다 그렇다면 그 두 가지를 조합을 해서 필터링하는 이렇게 세 가지 방식으로 필터링이 가능하고 밑에 제가 저희 블로그 링크를 하나 적어놨는데요 여기 블로그에 들어가 보시면 좀 더 구체적인 사례랑 어떻게 활용하는지에 대한 내용이 나오기 때문에 오늘 설명을 한번 들으시고 이걸 적용하실 때는 이 블로그도 꼭 한번 참조하시길 바랍니다 필터링은 이런 형태로 필터링하는 시점에 따라서 모델을 생성할 때 뺄 거냐 아니면 실제 생성된 모델을 가지고 추천 결과를 읽어올 때 뺄 거냐 이렇게 적용할 수가 있는데 이런 방식은 사실상 퍼스널라이즈의 필터링 기능을 그대로 활용을 하시는 방법이에요 그런데 실제로 퍼스널라이즈 제공하는 필터링 기능보다 실제 고객분들의 비즈니스 로직에 따라서 필터링 방식을 바꾸고 싶어 하실 때가 있을 거예요 그런 방식을 하실 때는 실제로 퍼스널라이즈 필터링하고 고객분들이 필터링할 수 있는 로직이 들어간 서버를 프록시 서버 같은 거 하나 두셔서 실제 퍼스널라이즈의 결과를 다시 한번 필터링하는 이런 형태로 구현을 하실 수가 있거든요 두 개의 장단점을 약간 비교를 해드리자면 만약에 어떤 퍼스널라이즈에서 나온 추천 결과를 보여줄 때 최소 5개 이상을 보여주고 싶으신 거예요 한 웹페이지에서 그렇다면 슬롯이 5개가 있을 텐데 그런데 퍼스널라이즈의 필터링을 사용을 하시게 되면 처음에 퍼스널라이즈는 5개 정도의 결과를 내보내줄 수가 있는데 퍼스널라이즈 필터링을 적용함으로써 실제로는 3개만 나가는 거죠 지금 왼쪽에 보이는 그림처럼 X표시라고 된 것들은 필터링에서 빠지는 결과들이고 그래서 최종적으로는 3개가 나가고 그리고 화면에는 원래 5개가 보여줘야 되는데 2개가 비고 3개만 나가는 이런 형태가 될 수가 있거든요 그렇지만 이런 부분에서 만약에 퍼스널라이즈 쪽의 필터링 결과에 의존하지 않고 여러분들이 직접 람다와 API 게이트 같은 걸 활용하시던가 아니면 이식초 라든가 이런 것들을 이용하셔가지고 중간에 비즈니스 로직을 처리하는 어떤 서버를 하나 줬다 그렇다면 실제 퍼스널라이즈 쪽에서는 필터링을 하지 않고 그대로 결과를 주고 그 결과가 중간에 있는 이 서버에 가면 그 서버에서 실제 필터링을 하는 게 아니라 랭킹을 낮춰가지고 뒤쪽으로 빼는 거죠 그렇게 되면 실제로 사용자한테 보여줄 때는 이가 빠진 것처럼 술라 두 개가 빈 게 아니라 다섯 개가 다 채워지되 필터링이 돼야 할 아이템이라든가 이런 것들은 뒤쪽으로 가고 앞쪽에는 필터링이 안 된 것들만 오기 때문에 실제로 퍼스널라이즈에서 필터링하는 효과랑 비슷하게 쓰면서도 UX 상으로서 이상한 그런 웹페이지가 그려지지 않도록 만들 수 있는 거죠 이런 거 외에도 여러분들이 좀 더 자유롭게 비즈니스 로직을 적용할 수 있기 때문에 이런 부분에서 퍼스널라이즈 필터링 말고도 비즈니스적으로 어떻게 적용할 수 있는지 이런 것들 함께 고민하시면 좋습니다 그리고 마지막으로 설명드릴 부분은 지금까지는 제가 실시간으로 어떻게 추천을 활용할 수 있는지에 대해 설명을 드렸는데 그런데 저희가 사이트마다 성격이 다른 게 어떤 추천을 하느냐에 따라서 성격이 다른 게 만약에 우리는 추천을 한번 계산을 하고 그거를 여러 번 재활용할 수가 있다 특히나 유사 상품 같은 걸 추천한다고 친다면 신규 상품이 들어오거나 아니면 없어지거나 하는 것들이 그렇게 빈번하지 않다 아니면 그게 몇 개월에 한 번씩 된다 한다면 상품에 대한 추천 결과를 한 번만 계산을 하고 그것들을 계속 재활용하는 게 추천을 한 번 계산했기 때문에 비용이 훨씬 더 경제적일 거거든요 특히나 추천 결과 자체를 사용자들한테 동일하게 내보내줘도 크게 무리가 없다 그렇다면 오히려 실시간으로 매번 추천을 계산하고 그 결과를 내보내주는 것보다는 어딘가에 한번 계산한 결과를 저장했다가 그거를 재활용하는 게 훨씬 더 효과적일 텐데 그런 부분들을 저희가 제공해드리는 게 배치 레코멘데이션을 하는 방식이거든요 그래서 실시간으로도 계산할 수가 있긴 하지만 여러분들이 데이터셋을 하나 만들어 놓고 그 데이터셋을 이용해서 한 번에 계산을 하면 그 결과가 S3로 저장이 되고 S3로 저장된 결과를 재활용할 수 있는 형태로 구성하실 수가 있습니다 그래서 아키텍처 관점에서 다시 한 번 본다면 기존에 실시간 추천이랑 배치 추천이 크게 다르진 않아요 그래서 일단 데이터를 수집하는 부분은 웹서버에서 Kinesis Data Stream하고 파이어스 같은 걸 이용하셔서 S3에 한 번 저장이 됐다고 친다면 그때 저희가 원래 실시간에서는 이벤트 트래커를 이용해서 실시간 데이터를 이렇게 계속 받아왔는데 지금 배치로 활용하실 거라면 S3에 데이터가 일정하게 쌓이면 일정하게 쌓인 데이터를 가지고 배치 레코멘데이션을 수행하시는 거죠 그렇게 되면 그 결과가 S3에 저장이 될 거고 그러면 S3에 저장된 결과를 글로우라든가 아니면 EMR이나 이런 것들을 이용을 하셔서 다이나모 딥이나 아니면 데이터베이스 오로라 같은 데서 저장을 하신 다음에 실제로 추천 엔드포인트를 직접 만드시는 거죠 그래서 API Gateway랑 Lambda 같은 걸 이용을 하셔서 서버리스 형태로 이렇게 쉽게 구현을 하실 수가 있고요 이렇게 되면 추천을 한 번 계산해서 계속 재활용하실 수 있는 이런 장점이 있고 앞서 설명드렸던 그런 비즈니스 로직을 적용해서 필터링 하실 때도 지금 이렇게 한 번 저장된 다이나모 딥에 저장된 결과를 가지고 재활용하실 때 이런 Lambda 같은 부분에서 비즈니스 로직을 적용을 해서 필터링을 또 하실 수가 있는 거죠 그래서 지금까지 쭉 설명을 드린 게 실시간 추천, 배치 추천 이런 것들을 다 설명을 드렸고 그러면 배치 추천이 딱 들어보면 정말 싸고 괜찮을 것 같다 또 이렇게 생각하셔서 그러면 우리는 무조건 배치 추천을 써야지 이렇게 판단을 하실 수도 있는데요 이렇게 생각을 하시는 것보다는 좀 더 합리적인 결정을 하실 필요가 있어요 왜 그러냐면 저희가 AWS 아마존 퍼스널라이즈를 활용하실 때 퍼스널라이즈의 과금 정책이 퍼스널라이즈에서 사용하는 데이터 양하고 그 다음에 그 데이터를 가지고 모델을 학습시키는 시간 그리고 그 데이터로 만들어진 출원 API를 얼마나 호출하느냐 호출하는 시간에 따라서 저희가 비용이 발생을 하거든요 그렇기 때문에 실제로는 데이터 양에 따라서 사실상 비용이 비례해서 발생을 한다고 보시는 게 맞거든요 그러면 실제 배치 추천 같은 경우는 만약에 내가 한 달짜리 데이터로 추천했던 거랑 그 다음에 1년짜리 데이터로 추천했던 거랑 아무리 비용이 싸다고 하더라도 계속 데이터 양이 늘어가면 선형적으로 증가할 거예요 하지만 실시간 추천 같은 경우는 실제 계산을 해보면 이게 배치보다 어느 시점이 넘어가면 오히려 싸지는 경우가 있거든요 그래서 만약에 내가 실시간 추천을 적용하고 싶은지 배치 추천을 적용하고 싶은지는 첫 번째로는 물론 어떤 형태의 추천을 쓰고 싶느냐에 따라서 달라지겠지만 비용 관점에서 본다면 두 가지를 한 번 다 시뮬레이션 해보고 가장 합리적인 가격이 나오는 방식으로 추천을 적용하시기를 권장드립니다 지금까지 했던 내용을 다시 한번 빠르게 정리를 해보면 결국에는 저희가 추천이 필요한 이유는 e-commerce에서 가장 중요한 지표인 리텐션이라든가 첫레이트, 그 다음에 컨버전 레이트 같은 경우에 추천이 상당히 중요한 영향을 준다 그리고 저희가 추천을 평가할 때는 단순히 커버리지나 렐러번스 외에도 세렌디피트라고 하는 이러한 지표에 대해서도 성과가 잘 나오도록 추천을 해야 되고 세렌디피트를 추천하시려면 A,B 테스트를 항상 하셔야 된다고 생각하시면 됩니다 그 다음에 추천을 적용하실 때 아마존의 퍼스널라이저를 사용하셔서 추천 서비스를 만드실 수 있는데 이때 필요한 데이터는 유저 데이터, 아이템 데이터 그 다음에 유저가 그 아이템에 어떠한 인터랙션을 했는지 인터랙션 데이터가 필요하고 이 중에 인터랙션 데이터가 가장 중요한 데이터다 이렇게 생각하시면 됩니다

그리고 추천에 대한 알고리즘은 가장 크게 개인화 추천을 제공해주는 유저 퍼스널라이저 그 다음에 관련 상품이라던가 유사 상품을 추천해줄 수 있는 SIMS라는 알고리즘 그 다음에 인기 상품을 그대로 계산해주는 Popularity Count 그리고 사용자마다 다른 순서로 결과를 보여줄 수 있는 퍼스널라이저 랭킹 이렇게 한 네 가지 정도의 알고리즘이 있다고 생각하시면 되고 퍼스널라이저를 가지고 추천 서비스를 적용하실 때는 데이터 세트를 생성하시고 데이터 세트를 임포트하신 다음에 실제 레시피를 선택하셔서 솔루션을 만들고 최종적으로 엔드포인트 캠페인을 생성하신 후에 API 호출을 통해서 사용하실 수가 있고 이러한 작업들을 저희가 아마존 스탭 펑셀을 활용하셔서 자동화 하실 수가 있다 그리고 추천 결과를 필터링 하실 때는 퍼스널라이저의 고유 기능을 사용하실 수도 있고 실제 비즈니스 로직을 적용하셔서 직접 만드실 수 있다 이렇게 이해를 하시면 될 것 같습니다.

지금까지 추천에 대해서 쭉 설명을 드렸는데 하실 사장님, 제가 마지막으로 드리고 싶은 말씀은 실제로 항상 이런 문제를 풀 때 고객분들이 알고리즘이 중요할까 데이터가 중요할까 또 고민에 빠지세요.

일단 알고리즘보다는 데이터를 먼저 생각하시는 게 훨씬 더 유리하십니다.

그래서 좋은 데이터, 그 다음에 실제 잘 정제된 데이터가 풍부할수록 알고리즘과 상관없이 항상 일정 이상의 성능을 낼 수가 있거든요.

그렇기 때문에 항상 데이터를 잘 관리하고 그 데이터를 어떻게 잘 활용하실지 고민하시고 그 다음에 거기에 맞는 알고리즘을 선택하신다 이렇게 생각하시면 될 것 같습니다.

여기까지 아마존 퍼스널라이즈에 대한 설명을 드렸고요.

저는 AWS 솔루센트 아키텍트 김성민이었습니다.

감사합니다.