목차
- [ AI-DLC 사례 1: 검색 ] AI-DLC로 3일, 뷰티 자연어 검색을 만드는 여정
- [ AI-DLC 사례 2: 추천 ] AI로 코딩은 빨라졌는데, 왜 실험은 여전히 어려웠을까?
AI로 코딩은 빨라졌는데, 왜 실험은 여전히 어려웠을까?
AI-DLC에서 시작한 3일간의 추천 실험
앞선 글에서 검색 과제팀은 3일 만에 자연어 검색을 구현해봤습니다. 그 과정에서 크게 남은 것은, AI와 일할 때 사람이 무엇을 얼마나 또렷하게 정의해야 하는가에 대한 경험이었습니다.
같은 3일, 저희는 5명이 한 팀이 되어 AI-DLC를 통해 추천 문제를 풀기로 했습니다.
사실 AI와 함께 개발하는 일은 이미 꽤 익숙했습니다. 저희 검색추천파트도 평소 Claude, Cursor 같은 Coding Agent를 자주 사용하고 있었고, 아이디어를 구상하고나면 코드를 만들고, 오류를 고치고, 테스트를 붙이는 속도는 예전보다 확실히 빨라졌습니다.
이번에는 그 방식을 추천 모델 문제에도 적용해보고 싶었습니다.
2026년 7월 7일부터 9일까지, 저희는 실제 업무인 상품 상세 하단(단품하단) 추천의 후보군 개선을 주제로 잡았습니다. 여기서 추천 후보군이란 추천할 만한 상품을 넓게 모아둔 상품 집합을 말합니다.
워크숍은 앞선 검색 과제와 마찬가지로 AI-DLC의 흐름에서 시작했습니다. Inception에서 풀고 싶은 문제와 목표를 정리하고, 여러 아이디어를 구체화한 뒤 Construction으로 이어갔습니다.
처음에는 대상만 달라졌을 뿐, 비슷한 흐름으로 진행할 수 있을 거라고 생각했습니다. 여러 아이디어를 빠르게 구현하고 비교할 수 있다면, 좋은 추천 모델을 찾는 속도도 자연스럽게 빨라질 것 같았습니다.
그래서 저희가 확인해보고 싶었던 것은 하나였습니다.
AI로 구현이 빨라지면, 추천 실험도 그만큼 빨라질까?
실제로 여러 아이디어를 구현하고 실험 결과를 만드는 건 예상만큼 빨랐습니다.
하지만 결과가 쌓이자 병목은 구현이 아니라 판단으로 옮겨갔습니다.
어떤 결과가 더 좋은지, 그 숫자를 믿어도 되는지, 어디까지 더 볼지를 결정하는 일이었습니다.
그렇게 저희의 3일은 조금 다른 방향으로 흘러가기 시작했습니다.
모델이 많아질수록, 답은 오히려 흐려졌다
여러 후보를 빠르게 만들면 답도 빨리 찾을 수 있을 거라고 생각했습니다.
그런데 실제 결과가 쌓이자 이상한 일이 생겼습니다.
1등이 하나가 아니었습니다.
어떤 후보는 실제 주문 상품을 더 많이 찾아왔고, 어떤 후보는 주문 상품을 더 앞쪽에 배치했습니다. 또 어떤 후보는 기존 방식이 놓친 상품을 새롭게 찾아왔습니다.
모두 좋은 결과처럼 보였지만, 사실 서로 다른 질문에 답하고 있었습니다.
주문 상품을 얼마나 많이 찾아오는가
찾아온 주문 상품을 얼마나 앞쪽에 배치하는가
기존 방식이 놓친 주문 상품을 얼마나 새롭게 보완하는가
문제는 이 결과를 한 줄로 세워놓고 단순히 "이 모델이 더 좋다"고 말하기 어렵다는 것이었습니다.
처음 주요 판단 기준으로 정했던 지표에서도 문제가 발견됐습니다.
저희는 추천 상품이 노출된 이후 실제 주문으로 이어진 행동을 보는 내부 지표를 주요 기준으로 사용하고 있었습니다. 모델이 과거 데이터에서 얼마나 잘 맞는지만 보기보다, 실제 고객 행동에 가까운 기준으로 평가하고 싶었기 때문입니다.
그런데 데이터를 돌려보니 이 지표는 기존에 어떤 상품이 노출됐는지의 영향을 받고 있었습니다. 새로운 후보끼리 순수하게 비교하는 기준으로 쓰기에는 한계가 있었습니다.
그래서 실험 도중, 상위 16개 결과에서 주문 상품이 얼마나 앞쪽에 배치되는지를 보는 지표(order_NDCG@16)를 주요 판단 축에 추가했습니다. 기존 내부 지표는 후보를 직접 비교하는 기준이라기보다 결과를 해석하는 보조 지표로 역할을 조정했습니다.
흥미로운 점은 평가 기준 역시 실험의 결과물이었다는 것입니다.
모델을 구현하고 결과를 확인한 뒤, 무엇을 좋은 결과로 볼 것인지도 함께 조정해나가야 했습니다. 구현을 마치고 다음 단계로 넘어가기보다, 결과를 보고 다시 가설과 평가 기준으로 돌아가는 일이 반복됐습니다.
비교하려면, 시험대부터 같아야 했다
평가 기준만의 문제도 아니었습니다.
실험이 늘어나면서 각 결과가 만들어진 조건도 조금씩 달랐습니다. 어떤 후보는 로컬에서, 어떤 후보는 원격 환경에서 실행됐고 구현 방식도 서로 달랐습니다. 이 상태에서는 결과가 많아질수록 모델의 차이와 실험 조건의 차이를 구분하기 어려워졌습니다.
그래서 실행 환경 자체를 모두 통일하기보다, 적어도 같은 데이터를 사용하고 같은 기간을 평가하고 같은 형식으로 결과를 받도록 맞췄습니다.
한 줄로 정리하면 이렇습니다.
모델은 자유롭게, 평가는 엄격하게.
평가 시점 이후의 정보가 실험에 섞이지 않았는지도 함께 확인했습니다. 미래 정보를 사용한 결과는 실제 후보 판단에서 제외했습니다.
또, 전체 점수만 보지 않았습니다. 새로운 후보가 기존 방식이 놓친 주문 상품을 실제로 보완하는지도 함께 확인했습니다.
모델마다 구현 방식은 달라도, 결과를 바라보는 시험대만큼은 같아야 했습니다.
그래야 성능 차이가 모델에서 온 것인지, 실험 조건에서 온 것인지를 구분할 수 있었습니다.
가장 좋은 숫자를 바로 믿을 수는 없었다
이 구조가 왜 필요했는지를 가장 잘 보여준 결과가 하나 있었습니다.
상품 간 행동 유사도를 활용하는 실험 중 하나에서 order_NDCG@16이 0.097633이 나왔습니다.
같은 아이디어를 미래 정보가 섞이지 않도록 구현한 결과는 0.012374였습니다.
약 8배 차이였습니다.
숫자만 보면 고민할 이유가 없어 보였습니다.
하지만 높은 쪽을 확인해보니 평가 시점 이후의 정보가 포함된 결과였습니다. 실제 후보 판단에서 제외하고 참고 결과(LEAKY_REF)로만 남겼으며, 같은 아이디어를 미래 정보 누출이 없도록 다시 구현한 결과를 실제 비교에 사용했습니다.
이 경험은 꽤 상징적이었습니다.
높은 숫자를 빨리 얻는 것보다, 그 숫자를 믿어도 되는지 확인하는 일이 더 중요했습니다.
실험이 쌓이자, 판단에도 구조가 필요했다
같은 기준으로 결과를 비교할 수 있게 되자, 다음 문제는 그 결과를 어떻게 이어갈 것인지였습니다.
점수만 남겨두면 며칠 뒤 다시 이 모델들을 어떻게 할지 결정해야 합니다. 그래서 결과 옆에는 점수뿐 아니라 다음 행동도 함께 남기기 시작했습니다.
STOP — 지금 목적에서는 더 이상 보지 않는다
PARK — 가능성은 있지만 추가 검증이 필요하다
KEEP_SOURCE — 전체 1등은 아니지만 다른 역할로 남긴다
이 판단은 단순히 점수가 높은 순서대로 내리지는 않았습니다. 이번 실험의 목적에서 기존 후보보다 나아질 가능성을 찾기 어렵다면 STOP, 가능성은 보이지만 데이터나 기간을 넓혀 한 번 더 확인해야 한다면 PARK로 두었습니다. 전체 성능이 가장 높지 않더라도 기존 후보가 놓친 상품을 새롭게 찾아오는 등 후보군 안에서 다른 역할이 있다면 KEEP_SOURCE로 남겼습니다.
결국 이 라벨은 모델의 절대적인 우열을 정하기보다, 현재까지의 결과를 바탕으로 다음 행동을 정리하기 위한 기준에 가까웠습니다.
예를 들어 PARK가 붙어 있다면 다음 질문은 조금 더 명확해집니다.
“이 후보가 좋은가?”가 아니라 “어떤 조건에서 한 번 더 확인해야 하는가?”
실제로 후보의 순서를 다시 조정하는 모델 5종은 이번 목적에서 더 투자할 근거를 찾지 못해 STOP했습니다. 인기 상품을 활용한 후보는 전체 성능이 가장 높지는 않았지만, 기존 후보군이 놓친 주문 상품을 추가로 찾아오는 기여가 있어 단독 승부보다는 후보군을 보완하는 역할로 KEEP_SOURCE에 남겼습니다.
가장 가능성이 높아 보였던 후보도 바로 채택하지 않고, 더 큰 데이터와 여러 기간에서 안정성을 확인하기 위해 PARK했습니다.
실험 수가 늘어나면서 비교하는 비용이 커졌습니다. 주요 지표와 실행 조건, 미래 정보 누출 여부, 기존 방식 대비 변화, 그리고 각 실험에 내린 판단을 한눈에 볼 수 있도록 leaderboard 형태의 대시보드도 만들었습니다.
대시보드가 결과를 대신 판단해주는 것은 아니었습니다.
여러 실험을 같은 조건에서 보고 다음 행동을 결정하기 위한 화면에 가까웠습니다.
새로운 후보가 하나 추가될 때마다 이전 결과를 다시 찾고 별도의 표를 만드는 대신,
같은 입력 → 같은 평가 → 같은 비교 → 다음 행동
으로 이어지게 하고 싶었습니다.
이렇게 대시보드는 단순한 성능 순위표라기보다, 하나의 실험 결과를 다음 판단과 실험으로 이어주는 목록에 가까워졌습니다. 하지만 비교 방식을 정리한다고 해서 좋은 실험이 자동으로 만들어지는 것은 아니었습니다.
몇 차례 결과가 기대에 미치지 못하자 탐색이 기존 상용 추천 결과를 더 잘 재현하는 방향으로 움직인 적이 있었습니다. 숫자는 좋아질 수 있었지만, 원래 목적은 기존 추천을 따라가는 것이 아니라 새로운 추천 후보를 찾는 것이었습니다.
실험을 빠르게 반복하는 사이, 어느 순간 다른 문제를 더 잘 풀고 있었던 셈입니다.
필요 이상으로 큰 구조를 만들려는 경우도 있었습니다. 실험 실행 정보를 별도로 관리하는 구조가 제안됐지만 이미 Kubeflow가 제공하는 기능과 겹쳐, 기존 기능에 맡기고 필요한 부분만 남겼습니다.
이런 과정을 겪으며 한 가지가 분명해졌습니다.
실험을 빠르게 만드는 것과, 올바른 방향으로 빠르게 나아가는 것은 다른 문제였습니다.
AI와 실험 시스템은 구현과 실행, 결과 정리를 빠르게 해줬습니다. 하지만 어떤 가설을 볼지, 무엇을 성공으로 볼지, 언제 멈출지, 지금 풀고 있는 문제가 원래 목적과 맞는지는 여전히 사람이 판단해야 했습니다.
실험 속도가 빨라질수록 이런 판단 기준은 오히려 더 중요해졌습니다. 실험을 빠르게 만들 수 있다는 것은, 의미 없는 방향도 빠르게 많이 만들 수 있다는 뜻이기 때문입니다.
3일 뒤 남은 것
이번 3일의 결과는 하나의 모델 이름으로 정리되지는 않았습니다.
대신 더 보지 않아도 되는 방향을 정했고, 다른 역할로 남겨둘 후보와 추가 검증이 필요한 후보를 구분했습니다. 다음 후보가 들어와도 처음부터 평가 조건을 다시 맞추지 않아도 되는 공통 구조가 생겼습니다.
결국 저희가 얻은 것은 "무엇이 가장 좋은가"라는 답 하나보다, "무엇을 더 보고 무엇을 멈출 것인가"를 더 빠르게 판단할 수 있는 방식에 가까웠습니다. 다음에는 PARK한 후보를 더 큰 데이터와 여러 기간에서 검증하고, offline에서 가능성이 확인된 후보를 실제 서비스에 연결해 online 성과까지 확인할 예정입니다.
돌이켜보면 이번 3일은 AI-DLC에서 시작해 추천 문제를 풀어본 시도였지만, 실제로 오래 붙들게 된 것은 구현 이후의 실험 과정이었습니다.
모델을 구현하고 결과를 확인하면 새로운 가설이 생겼고, 때로는 feature나 label을 다시 봐야 했으며, 무엇을 좋은 결과로 볼 것인지 평가 기준 자체를 바꿔야 하기도 했습니다. 처음 그렸던 흐름을 한 번 따라가는 것으로 끝나기보다, 구현과 평가 사이를 여러 번 오가는 반복이 자연스럽게 이어졌습니다.
이번에 만든 공통 평가 조건과 leakage 검증, STOP / PARK / KEEP_SOURCE 같은 판단 기준, 대시보드도 구현과 평가 사이의 반복을 조금 더 빠르고 일관되게 이어가기 위해 하나씩 생겨난 장치들이었습니다.
앞선 검색 과제에서는 AI와 함께 개발할 때 무엇을 더 명확하게 정의해야 하는지가 중요하게 남았습니다. 이번 추천 실험에서는 구현 이후의 과정이 더 크게 보였습니다. 빠르게 만들어진 결과를 어떻게 평가하고, 무엇을 더 볼지 결정해 다음 실험으로 연결할 것인가였습니다.
저희에게 이번 3일은 AI-DLC에서 출발해, 실제 추천 문제를 풀며 구현 이후에도 이어지는 실험과 판단의 방식을 찾아간 시간이었습니다.
다른 개발 과제에서도 AI가 속도를 붙이는 지점과, 그 뒤 새롭게 드러나는 반복은 조금씩 다를 수 있습니다.
테스트나 리뷰, 배포가 될 수도 있고, 저희처럼 실험과 평가가 될 수도 있습니다.
하지만 어떤 문제를 마주하든,
AI가 잘할 수 있는 영역과 인간이 판단해야 하는 영역을 명확히 인지한다면 더 빠르고 정확하게 문제 해결에 다가설 수 있을 것입니다.
장효주 Ellie | AX본부 홈쇼핑AX부문 검색추천파트(H)
추천 시스템 개발을 담당하고 있습니다
사람의 행동을 데이터로 이해하고, 더 나은 선택으로 연결합니다
결과를 만드는 것뿐 아니라, 그 결과를 어떻게 해석하고 믿을지 함께 고민합니다