새로 찾은 상품은 6.5%, 오토태깅이 대신한 건 발견이 아니라 기억이었다

"유저에게 태그는 자기 물건의 목록이었습니다." 오늘의집 오토태깅 개발기의 끝자락, 출시 데이터를 해석하는 대목에 이 문장이 조용히 들어 있습니다. 글의 제목은 정답 없는 문제를 빠르게 푸는 법이고 분량 대부분이 웹 프로토타입과 UT, 앱과 서버를 넘나든 결정에 쓰였지만, AI 기능을 만드는 팀에게 더 오래 남을 교훈은 이 한 문장이라고 저는 봅니다. 사진 속 상품을 찾아 주겠다고 만든 AI가 실제로 한 일은 찾기가 아니라 기억해 내기였거든요.

55%와 6.5% 사이

출시 후 오토태깅으로 붙은 태그를 출처별로 나눈 차트부터 보죠.

예전에 태그한 적 있는 상품이 55%, 직접 검색해서 찾은 상품이 25%, 구매한 적 있는 상품이 10%. AI가 사진만 보고 새로 찾아낸 상품은 6.5%입니다. AI가 관여해 붙은 태그는 전체의 3분의 1이었는데 그중 대부분이 유저가 이미 샀거나 예전에 태그한 상품이었고, 이력에 없는 상품이 태그되는 비율은 오토태깅 전후로 거의 움직이지 않았어요.

이 숫자가 어디서 왔는지는 UT 회차표에 이미 적혀 있습니다.

2차 UT까지는 탐지된 객체를 전체 상품과 비교했습니다. 객체 탐지 모델로 위치를 찾고, OpenCLIP 계열 모델로 그 영역을 임베딩해서, 카탈로그를 미리 넣어 둔 ChromaDB에서 코사인 유사도가 높은 상품을 고르는 파이프라인이죠. 회차표에 남은 결과는 "탐지는 개선됐으나 검색된 상품의 정확도가 낮음". 3차에서 유저가 구매하거나 스크랩하거나 태그한 상품을 검색 대상에 함께 넣자 추천 적중률이 올라가고 삭제되는 태그 비율이 내려갔어요. 자기 공간에 있는 물건은 이미 한 번 본 물건일 가능성이 높다는 가정이 맞았던 겁니다. 회차표를 거꾸로 읽으면 대조군도 하나 있어요. 1차에서 탐지된 객체 수가 모자라자 팀은 다른 객체 탐지 모델로 바꿨고, 2차에서 탐지는 좋아졌지만 검색 정확도는 그대로 낮았습니다. 모델을 바꾼 효과는 물건을 찾는 데서 멈췄고, 무엇인지 맞히는 데까지는 오지 않은 거죠.

제가 보기에 이 프로젝트의 가장 큰 결정은 탐지 모델 교체도, 캐러셀도 아니고 이 검색 범위 변경이에요. 전체 카탈로그에서 비슷한 걸 찾는 문제를, 이 사람이 이미 아는 물건 가운데서 고르는 문제로 바꿔 버렸으니까요. 풀기 어려운 문제를 더 좋은 모델로 푼 게 아니라, 풀기 쉬운 문제로 바꿔서 푼 셈입니다.

공정하게 덧붙이면 모델이 놀고 있었던 건 아닙니다. 상품을 하나라도 찾아낸 사진이 92%였고, 유저가 사진의 한 곳을 눌렀을 때 그 좌표가 물건이 있는 자리인지 곧바로 판정할 수 있는 것도 진입할 때 캐시해 둔 탐지 결과 덕분이에요. 사진 속 어디에 물건이 있는지는 모델이 찾고, 그게 무엇인지는 대부분 유저의 기억이 맞혔다고 보는 게 정확합니다.

UT에서 한 말, 출시 후에 한 행동

기획 초기의 두 질문 중 하나는 유사한 상품까지 태그할지, 확실한 상품만 태그할지였습니다. UT 2차에서 정확도가 낮아 답답하다던 반응은 정확도를 개선한 뒤 결이 달라졌어요. "정확도가 떨어져도 비슷한 상품을 보여주는 거니까 괜찮아요. 오히려 상품 추천이 될 수도 있겠네요." "매치가 잘못됐다고 해서 크게 불쾌하진 않았어요." 개발기는 여기서 무엇을 정답으로 볼지, 유저가 결과를 어떻게 쓸지까지 함께 봐야 한다는 결론을 냅니다.

출시 데이터는 그 질문에 꽤 분명하게 답했다고 봐요. 참가자들은 비슷한 상품도 괜찮다고 말했지만, 실제 크리에이터들이 남긴 건 대부분 자기가 샀거나 예전에 태그한 바로 그 물건이었고, 사진만 보고 찾아낸 비슷한 상품은 6.5%에 머물렀습니다. 추천으로 받아들일 수 있다는 말과 내 사진에 붙여 두겠다는 행동은 다른 문제였던 거죠. 태그가 자기 물건의 목록이라면, 비슷한 물건은 목록에 오를 자격이 없습니다. UT에서 나온 관대한 반응을 그대로 정답의 기준으로 삼았다면 제안의 폭을 넓히는 쪽으로 갔을 텐데, 데이터는 반대 방향을 가리켰어요.

기다림은 줄였는데 발행은 28% 늦어졌다

개발기의 중반은 대기 시간과의 싸움이었습니다. 1차 UT 참가자들은 한 번에 세 장에서 열 장까지 올렸고, 마지막 사진의 감지가 끝날 때까지 기다려야 했어요. 한 참가자는 이렇게 말했죠. "수동으로 태그하는 게 나을 수도 있어요. 자동 검색은 감지 시간이 걸리니까, 빠르게 올리고 싶을 때는 오히려 불편할 수 있어요." 올린 사진을 한꺼번에 감지하던 처음 설계가 사진을 많이 올리는 유저를 충분히 고려하지 않았다는 게 1차 세션에서 바로 드러난 거예요. 그래서 지금 보고 있는 사진 한 장만 감지하도록 바꿨고, 탐지 목록을 서버가 아니라 앱이 들고 있게 해서 누를 때마다 서버를 다녀오지 않게 했습니다.

상품을 못 찾았을 때 에러 대신 빈 목록을 돌려주기로 한 결정은 따로 짚고 싶어요. 에러를 받으면 앱은 실패 화면을 띄우는데, 사진이 그대로인 이상 다시 시도해도 결과는 같습니다. 그래서 "사진에서 추천할 상품을 찾지 못했어요"라고 결과를 그대로 알리고 다시 불러오기 버튼을 꺼 뒀죠. 요청은 성공했고 결과가 없을 뿐이라는 구분은, 추천을 내려주는 API라면 어디든 가져가도 되는 원칙입니다.

그런데 출시 후 숫자를 보면 태그 화면에 들어가서 발행하기까지 걸린 시간이 28% 늘었습니다. 기계의 대기는 줄였는데 사람의 시간은 늘어난 거예요. 그 시간이 어디로 갔는지는 삭제율이 알려 줍니다. 오토태그를 본 유저 세 명 중 두 명은 제안을 적어도 하나 남겼지만, 붙은 태그 가운데 44%는 지워졌어요. 팀이 세운 목표는 붙은 태그의 절반 이상이 살아남는 것이었고 56%로 넘겼습니다. 플랫폼 쪽에서 보면 합격선인데, 크리에이터 쪽에서 보면 태그 하나를 남기려고 두 개 가까이를 확인해야 한다는 뜻이기도 해요. 생존율은 제안의 품질을 재는 숫자고, 검수의 수고를 재는 숫자는 따로 있어야 합니다.

캔들·방향제는 27%, 소파는 29%만 지워진 반면 커튼·블라인드는 61%, 거울과 침구는 58%가 지워졌습니다. 크리에이터의 일은 줄지 않았어요. 상품을 찾아 입력하던 일이 AI가 내민 후보를 훑고 지우는 일로 바뀌었을 뿐입니다. 개발기도 오토태깅이 입력 시간을 줄이지는 못했다는 걸 숨기지 않았고, 잘 지워지는 물건군에서는 확신이 더 있을 때만 제안하도록 기준을 달리 두는 걸 다음 방향으로 적었어요. 저도 그 방향에 동의하고, 한 걸음 더 가도 된다고 봅니다. 커튼이나 침구처럼 무늬와 색으로만 구분되는 물건은 전체 카탈로그와의 유사도로는 확신이 잘 생기지 않으니, 그 물건군에서는 아예 유저의 구매·태그 이력 안에서만 후보를 내는 식으로요. 앞의 차트대로라면 맞는 태그는 어차피 대부분 거기서 나왔습니다.

차트에서 덜 눈에 띄는 숫자도 하나 있어요. 직접 검색해서 찾은 상품이 여전히 25%입니다. 오토태깅이 붙은 뒤에도 태그 넷 중 하나는 크리에이터가 예전 방식대로 검색해서 붙였다는 뜻이고, 이 부분의 수고는 그대로 남아 있어요. 사진의 한 곳을 누르면 그 자리의 추천을 띄우는 두 번째 흐름이 이 빈틈을 겨냥한 장치일 텐데, 그 흐름이 25% 중 얼마를 가져왔는지는 개발기에 나오지 않습니다.

태그 2.7배, 클릭 2.3배는 누구의 몫인가

오토태깅이 적용된 유저와 적용되지 않은 유저를 비교한 표를 보면 이 거래의 모양이 더 분명해집니다.

사진 한 장에 최종적으로 남은 태그는 2.7배, 콘텐츠 하나당 태그 클릭은 2.3배가 됐고, 조회당 태그 CTR은 17%, 태그를 한 번이라도 누른 유저 비율은 19% 늘었습니다. 커머스를 하는 플랫폼에는 반가운 숫자죠. 그런데 두 배수를 나눠 보면 태그 하나당 클릭은 대략 0.85배로 줄었어요. 태그가 늘어난 만큼 클릭이 비례해서 따라오지는 않았고, 늘어난 태그 중 일부는 아무도 누르지 않는 태그라는 뜻이기도 합니다. 이건 3차 UT에서 이미 한 번 들었던 경고와 이어져요. "태그가 사진에 너무 많으니까, 사진도 잘 안 보이고 태그도 잘 안 보여요." 그때는 툴팁을 사진 아래 캐러셀로 옮겨 가림 문제를 풀었지만, 사진 한 장의 태그가 2.7배가 된 지금은 캐러셀 안에서 태그끼리 주의를 나눠 갖게 됩니다. 태그당 클릭이 줄어든 건 그 분산의 흔적으로 읽혀요.

그래도 출발점의 문제는 확실히 풀렸습니다. 원래 크리에이터가 상품 하나를 태그하려면 사진에서 위치를 찍고, 상품을 검색하고, 결과에서 골라야 했고, 번거로워서 태그를 건너뛰는 일이 흔했어요. 남은 태그 2.7배는 건너뛰던 태그가 돌아왔다는 뜻입니다.

셈을 따져 보면 태그와 클릭이 늘어 이득을 보는 쪽은 플랫폼이고, 발행 시간 28%를 내는 쪽은 크리에이터입니다. 크리에이터에게 태그가 정말 자기 물건의 목록이라면 이 거래는 공정할 수 있어요. 같은 소파와 조명을 매번 다시 찾아 입력하던 수고를 후보 확인으로 바꿔 준 셈이니까요. 하지만 발행 시간이 계속 늘어난다면 어느 시점에는 태그가 아니라 업로드 자체를 미루게 될 수 있고, 개발기에는 발행 빈도가 어떻게 변했는지가 나오지 않습니다. 제가 이 팀이라면 다음으로 확인할 숫자는 그거예요.

웹 프로토타입이 벌어 준 것, 그리고 조건

프로세스 쪽 교훈에는 대체로 동의합니다. 안드로이드 개발자로 시작해 지금은 Product Engineer로 일하는 Liz가 사내 Build Anything Program(BAP) 과제로 AI 코딩 에이전트를 써서 만든 첫 프로토타입은 HTML 파일 하나에 FastAPI 추론 서버를 붙인 웹이었어요. 빌드 없이 새로고침으로 반영하고, 아이폰의 HEIC 사진은 JPEG로 바꾸고, 사진과 태그 상태는 IndexedDB에 남겼습니다. 참가자가 올린 실제 사진에 실제 추론이 돌았기 때문에 이력을 검색 범위에 넣는 결정도, 캐러셀도 네 번의 UT 안에서 나왔고요. 정지된 시안으로는 어느 쪽도 얻지 못했을 답입니다.

앱과 서버를 한 사람이 넘나든 것도 이 크기의 기능에서는 맞는 선택이었습니다. 탐지 목록 보관이나 빈 목록 응답처럼 규약을 바꿔야 끝나는 문제를 발견한 자리에서 바로 고칠 수 있었으니까요. 비용은 iOS 빌드 실패의 진짜 원인이 메모리 부족이었다는 식의 일회성 학습이었고요. 에러 메시지는 전혀 다른 곳을 가리켰는데, 한 컴퓨터에서 iOS와 서버, Android를 모두 빌드하다 생긴 일이었습니다. 다만 이건 한 사람이 규약 양쪽을 다 책임질 수 있을 때 성립합니다. 같은 API를 여러 클라이언트가 쓰기 시작하면, 발견한 자리에서 바로 바꾸는 속도가 다른 팀의 장애로 번질 수 있어요.

개발기의 마지막 숙제는 개수가 아니라 정확도로 적혀 있습니다. 중요한 건 그 정확도가 무엇을 향하느냐예요. 6.5%의 발견을 키우는 정확도라면 우선순위가 틀렸고, 44%의 삭제를 줄여 크리에이터에게 검수 시간을 돌려주는 정확도라면 맞습니다. AI 제안 기능의 성패는 모델의 눈이 얼마나 좋은지보다 사용자의 기억에 얼마나 빨리 닿느냐에서 갈린다는 게 이 데이터의 요지고, 그래서 모델을 키우기 전에 이력부터 연결하고, 생존율 56% 같은 제안 품질 숫자 옆에 남은 제안 하나에 드는 검수 시간을 나란히 재는 것이 이 개발기에서 가져갈 순서라고 봅니다.