VLM을 쓰지 않은 이유: Geometric Prior로 25배 빠른 의류 디테일컷 자동화

무신사

2026년 5월 26일

원문에서 보기 ↗

무신사 유즈드에서 AI 기반 의류 디테일컷 자동 생성 시스템을 구축하며 겪은 기술적 의사결정과 구현 과정을 공유합니다.

들어가며

무신사 유즈드는 중고 의류를 거래하는 플랫폼입니다.

새 상품과 달리 중고 상품은 개별 상태가 모두 다릅니다.

목 라인이 얼마나 늘어났는지, 소매 끝이 마모되었는지, 주머니 안쪽은 깨끗한지, 이런 디테일이 구매 결정에 큰 영향을 미칩니다.

앞뒤 2장이 전부였던 상품 상세 페이지

Before

그런데 무신사 유즈드의 상품 상세 페이지에는 앞면과 뒷면, 단 2장의 사진만 제공되고 있었습니다.

구매자 입장에서는 "이 옷 상태가 진짜 괜찮은 건가?"라는 질문에 답할 수 없는 구조였던 거죠.

디테일컷이 필요하다는 건 모두가 알고 있었습니다.

다행히 검수 공정에서 촬영되는 원본 이미지는 충분히 고해상도였습니다.

즉, 의류의 디테일을 볼 수 있는 정보 자체는 이미 이미지 안에 다 들어 있었던 거죠.

문제는 구매자에게 그 디테일이 보이는 형태로 전달되지 못하고 있다는 점이었습니다.

그렇다면 해법은 분명했습니다. 고해상도 원본 이미지에서 문제가 되는 부위(주로 소매 끝, 밑단, 목 라인처럼 마모와 오염이 집중되는 의류의 끝단들)를 확대(zoom-in)해서 보여주는 것. 그 확대된 한 장 한 장이 "이 옷 상태가 괜찮은가?"라는 질문에 직접 답해주고, 결과적으로 구매 전환으로 이어질 수 있는 정보가 됩니다.

다만 그걸 실제로 만들어내는 게 현실적으로 쉽지 않았습니다.

가장 단순한 접근: 사람이 직접 크롭하기

가장 먼저 떠오르는 방법은 검수자가 직접 부위별로 크롭하는 것입니다.

상품 하나당 앞뒤 이미지에서 3~4개 부위를 잘라야 하는데, 이 과정에 약 70초가 걸립니다.

하루 수천 개 상품이 들어오는 검수 공정에서 상품마다 70초를 추가로 쓴다면, 그건 현실적으로 감당하기 어려운 병목입니다.

디테일컷을 "안 하는" 게 아니라, "할 수 없는" 상황이었습니다.

그래서 자동화를 고민하기 시작했습니다

자연스럽게 AI를 활용한 자동화를 떠올렸습니다.

2024년 들어 GPT-4V나 Claude Vision 같은 VLM(Vision-Language Model)이 빠르게 범용 도구로 자리 잡고 있었고,

실제로 팀 내에서도 여러 업무에 LLM을 활용하고 있었습니다.

"이미지에서 소매 부분을 찾아서 크롭해줘"라고 자연어로 지시하면 알아서 처리해주는, 개발자 입장에서는 상당히 매력적인 선택지였습니다.

그런데 PoC를 돌려보니 생각보다 녹록하지 않았습니다.

이미지 1장을 처리하는 데 약 5초, 상품 하나에 앞뒤 2장이고 각 이미지에서 3~4개 부위를 크롭하면 상품 하나를 처리하는 데 20초 이상이 걸렸습니다.

수기 70초에서 20초로 줄어든 건 분명 개선이지만, 하루 수천 개 상품을 처리해야 하는 상황에서 상품당 20초는 여전히 부담스러운 숫자였습니다.

여기서 근본적인 질문이 생겼습니다. VLM은 이 문제에 정말 적합한 도구인가?

그 고민의 결과로, 공정 시간 90% 절감(70초 → 7초)과 11만 개 기존 상품 일괄 적용이라는 성과를 얻었습니다.

이 글에서는 그 여정에서 마주한 세 가지 핵심 의사결정을 공유합니다.

1. VLM 대신 Object Detector를 선택한 이유

VLM을 처음 후보로 올린 배경

최근 몇 년 사이 VLM은 이미지 관련 태스크의 만능 도구처럼 여겨지고 있습니다.

실제로 잘 작동합니다. 이미지를 입력하고 자연어로 질문하면 스타일을 분류해주고, 상태를 판별해주고, 설명을 생성해줍니다.

별도의 모델 학습 없이 프롬프트 하나로 다양한 태스크를 처리할 수 있다는 점에서, PoC 단계에서 VLM을 가장 먼저 시도해본 건 자연스러운 선택이었습니다.

그런데 왜 맞지 않았나

단순히 "느리니까 안 쓴다"는 결론은 너무 피상적입니다.

더 중요한 건 VLM이 이 태스크에 구조적으로 맞지 않는다는 점이었습니다.

VLM은 크게 두 단계로 작동합니다.

먼저 Image Encoder가 이미지를 고차원 특징 벡터로 변환하고, 그다음 Language Model이 이 벡터를 바탕으로 자연어 응답을 생성합니다.

이 구조는 이미지를 이해하고 추론하는 데 최적화되어 있습니다.

"이 옷은 어떤 스타일인가?", "소재가 뭔가?", "상태가 좋은가 나쁜가?" 같은 분류, 추론, QA 태스크에서 강점을 발휘하죠.

그런데 우리가 필요한 건 전혀 다른 종류의 답이었습니다.

"소매가 이미지의 어느 픽셀 좌표에 있는가" 이건 추론이 필요한 문제가 아니라, 공간 위치를 정밀하게 찾아내는 문제입니다.

VLM에게 "소매를 찾아서 크롭해줘"라고 요청하면, 모델은 이미지를 토큰화하고, 어텐션을 통해 전체 이미지를 이해한 뒤, 자연어로 좌표를 생성합니다. 이 과정에서 Language Model이 수천 개의 토큰을 순차적으로 디코딩하면서 추론을 수행하는데, 사실 우리에게 필요한 건 그 추론 과정이 아니라 최종 좌표 네 개뿐입니다. VLM의 가장 강력한 능력인 "자연어 기반 reasoning"이 이 태스크에서는 불필요한 오버헤드가 되는 셈이죠.

정리하면 이렇습니다: VLM vs Object Detector

Object Detector라는 선택지

그렇다면 좌표를 찾는 데 특화된 도구는 뭘까요? Object Detector입니다.

Object Detector는 이미지에서 특정 객체가 어디에 있는지를 찾아내는 모델입니다.

출력은 바운딩 박스(Bounding Box) 즉 "이 객체가 이미지의 (x1, y1)부터 (x2, y2)까지의 사각형 영역에 있다"는 좌표 정보입니다.

VLM처럼 이미지를 이해하고 설명하는 게 아니라, 객체의 위치를 수치로 정확히 뽑아주는 데 집중하는 도구입니다.

우리는 의류/패션 도메인에서 이미 검증된 경량 Detection 모델을 선택했습니다. 이 모델은 이미지에서 가장 큰 객체(= 의류)의 바운딩 박스를 추출하며, GPU 없이 CPU 환경에서도 200ms 내외로 추론을 완료합니다.

속도와 비용 차이

VLM API 호출은 이미지 업로드, 토큰화, 순차 디코딩까지 포함해 평균 5초 이상이 걸립니다. 반면 경량 Detector는 CPU 환경에서 200ms면 충분합니다. 약 25배의 속도 차이입니다.

비용 차이는 대량 처리에서 더 두드러집니다. VLM vs Detector 비용 비교

VLM은 입력/출력 토큰 기반으로 과금되는데, 이미지는 토큰 수가 많습니다. 한두 장이면 무시할 수 있지만, 11만 상품을 처리해야 하는 상황에서는 약 10배의 비용 차이가 발생합니다.

2. Detector + Rule-based Crop: 의류의 공간적 규칙성을 활용하다

아키텍처의 핵심 아이디어

이 파이프라인의 구조는 두 단계로 나뉩니다.

Detection --- "옷이 이미지의 어디에 있는가?"를 찾는다
Rule-based Crop --- "찾은 영역 안에서 부위별로 어떻게 자를 것인가?"를 결정한다

핵심은 관심사의 분리입니다. Detector는 위치만 찾고, 크롭 로직은 규칙이 담당합니다.

Detector 없이 규칙만으로는 왜 부족한가

"규칙 기반이면 그냥 이미지 전체에서 비율대로 잘라도 되지 않을까?"라는 생각이 들 수 있습니다.

실제로 시도해보면 금방 한계에 부딪힙니다. 상품 이미지마다 옷의 위치와 크기가 모두 다르기 때문입니다.

어떤 이미지에서는 옷이 화면 가운데에 크게 놓여 있고, 어떤 이미지에서는 약간 치우쳐 있거나 작게 찍혀 있습니다.

이미지 전체를 기준으로 "상단 30%가 목"이라고 규칙을 적용하면, 옷의 위치에 따라 허공을 크롭하거나 엉뚱한 부위를 잘라내는 경우가 빈번하게 발생합니다.

그래서 Detector가 선행 단계로 필요합니다.

먼저 의류의 바운딩 박스를 정확히 잡아내고, 그 좌표계 안에서 비율 규칙을 적용해야 크롭이 어긋나지 않습니다.

왜 규칙 기반이 작동하는가: 의류라는 도메인의 특수성

Rule-based Crop이 잘 작동하는 이유는 단순히 규칙을 잘 짜서가 아닙니다. 의류라는 도메인 자체가 강한 공간적 규칙성(Geometric Prior)을 가지고 있기 때문입니다.

생각해보면 당연합니다. 같은 카테고리의 의류라면, 부위의 위치는 거의 예측 가능합니다. 목은 항상 상단 중앙에 있고, 소매는 항상 좌우 측면에 있고, 밑단은 항상 하단에 있습니다. 아우터든 긴팔 상의든, 이 공간적 배치는 의류의 물리적 구조에서 비롯되기 때문에 거의 변하지 않습니다.

VLM이 "소매를 찾아서 크롭해줘"라는 자연어 지시를 받고 이미지를 이해하고 추론하는 동안, 우리는 이 사전 지식을 직접 좌표 규칙으로 인코딩합니다. 추론 과정 자체를 건너뛰는 것입니다.

이게 바로 이 파이프라인이 VLM 대비 25배 빠른 근본적인 이유입니다.

모델이 가벼워서가 아니라, 풀어야 할 문제의 복잡도 자체를 도메인 지식으로 낮춘 것입니다.

규칙은 어떻게 만들었나: 테스트셋 기반 귀납적 튜닝

"의류 부위의 위치가 예측 가능하다"는 건 직관적으로 맞는 말이지만, 실제로 비율값을 확정하는 과정은 그렇게 단순하지 않았습니다.

처음에는 카테고리별로 대략적인 비율을 짐작해서 넣었습니다.

"아우터의 목은 상단 30% 정도겠지?"라는 식으로요.

그런데 실제 상품 이미지를 돌려보면 생각보다 다양한 형태가 나옵니다.

같은 아우터라도 크롭 재킷과 롱 코트는 부위 비율이 꽤 다르고, 후드가 있는 경우와 없는 경우에 목 영역의 범위가 달라집니다.

바지도 와이드 팬츠와 스키니 팬츠에서 주머니 위치가 미묘하게 다르죠.

이 다양성을 단일 규칙으로 커버하려면, 충분한 샘플을 보고 여러 형태를 포괄하는 유효한 비율 범위를 찾아야 했습니다.

우리가 택한 방법은 카테고리별로 100장씩 테스트셋을 구축하고, 크롭 결과를 시각적으로 검증하는 반복적인 튜닝 과정이었습니다.

구체적으로는, 규칙을 적용한 크롭 결과를 HTML 리포트 형태로 생성해서 PM에게 전달했습니다.

리포트에는 원본 이미지와 부위별 크롭 결과가 나란히 표시되어,

어떤 이미지에서 크롭이 잘 됐는지, 어디서 실패했는지를 한눈에 확인할 수 있었습니다. HTML 리포트

PM이 리포트를 검토하고 피드백을 주면

("이 유형에서 소매가 잘리네요", "목 영역이 너무 좁아요"),

비율을 조정하고 다시 돌리는 사이클을 반복했습니다.

이 과정에서 PM과의 긴밀한 협업이 큰 역할을 했습니다.

엔지니어가 좌표 비율을 조정하고, PM이 실제 상품 관점에서 크롭 품질을 판단하는 각자의 전문성이 맞물리는 구조였습니다.

결과적으로 10개 카테고리 각각에 대해 이 귀납적 튜닝 과정을 거쳐 최종 비율이 확정되었습니다.

카테고리별 규칙 설계

아우터 카테고리를 예시로 들면 이렇습니다: 아우터 카테고리 부위별 X/Y 비율 규칙

Detector가 잡아낸 의류 바운딩 박스를 기준 좌표계로 삼고, 그 안에서 비율을 적용해 부위별 절대 좌표를 계산합니다.

이 규칙을 카테고리별로 정의해두면, 어떤 이미지가 들어와도 일관된 크롭 결과를 얻을 수 있습니다. After

10개 카테고리 적용 결과

10개 카테고리별 크롭 부위

스커트나 세트 아이템의 경우 의류 형태의 다양성이 커서 단일 규칙으로 커버하기 까다로운 부분이 있습니다.

특히 세트 아이템은 상하의가 함께 있어 구조가 복잡한데, 이 카테고리들은 추후 규칙 세분화를 통해 개선할 예정입니다.

3. AWS Lambda를 서빙 인프라로 선택한 이유

AutoCrop 요청이 발생하는 시점

인프라를 선택하기 전에, 먼저 이 서비스의 트래픽 특성을 이해할 필요가 있습니다.

AutoCrop API는 언제 호출될까요?

검수 공정에서 재고가 등록될 때입니다.

무신사 유즈드에서는 중고 상품이 입고되면 검수자가 상태를 확인하고 재고로 등록하는 과정을 거칩니다.

이 재고 등록 시점에 상품 이미지가 확정되고, 그때 AutoCrop API가 호출되어 디테일컷을 생성합니다.

이 과정은 검수자가 근무하는 시간에만 일어납니다.

즉 평일 09:00~18:00 업무시간에 요청이 집중되고, 야간과 주말에는 거의 호출이 없는 명확한 패턴을 보입니다.

유휴 시간에 서버를 띄워둘 이유가 없었다

이 트래픽 패턴에서 핵심 질문은 하나였습니다.

"아무도 쓰지 않는 시간에도 서버를 띄워둬야 하는가?"

Kubernetes 기반으로 운영한다면 KEDA 같은 오토스케일러를 붙이더라도 최소 인스턴스는 유지해야 합니다.

하루 24시간 중 약 15시간 이상이 유휴 상태인데, 그 시간에도 비용이 계속 발생합니다.

반면 AWS Lambda는 요청이 있을 때만 실행되고, 실행된 시간만큼만 과금됩니다. 유휴 시간 비용이 0원인 거죠.

업무시간에만 트래픽이 발생한다는 사실 자체가 Lambda를 선택하는 가장 강력한 근거였습니다.

여기에 팀 상황도 고려했습니다.

리커머스팀은 Kotlin/Spring 기반으로 운영되고 있고,

Python 기반 ML 서버를 직접 운영해본 경험이 많지 않았습니다.

K8s 위에 Python 서빙 서버를 올리고 모니터링, 배포, 롤백을 관리하는 운영 부담까지 감안하면, Lambda의 관리형 인프라가 현실적으로 더 나은 선택이었습니다. K8s + KEDA vs AWS Lambda

Lambda 구성과 비용 최적화

Docker 컨테이너 기반으로 배포했으며, CPU 전용 PyTorch를 사용해 이미지 크기를 약 700MB로 최소화했습니다.

Lambda는 실행 시간 × 메모리로 과금됩니다. 여기서 중요한 점은, Lambda에서는 할당 메모리에 비례해 vCPU가 함께 증가한다는 것입니다.

Detection 추론은 CPU-bound 작업이기 때문에, 메모리를 높이면 vCPU가 늘어나 실행 시간이 단축됩니다.

처음에는 4GB(약 2.5 vCPU)로 시작했는데, 추론에 약 400ms가 걸렸습니다. 메모리를 8GB(약 4.5 vCPU)로 올리자 약 200ms로 절반 가까이 줄었습니다. 메모리 비용은 2배가 되었지만 실행 시간이 절반으로 줄었으니,

최종 과금액은 거의 동일하면서 응답 속도는 2배 빨라진 셈입니다.

"빨리 돌려 짧게 과금" 전략이 이 워크로드에서는 확실히 유리했습니다. Lambda 메모리 구성별 성능 (4GB vs 8GB)

11만 상품 마이그레이션

AutoCrop 시스템을 구축한 후, 신규 상품뿐 아니라 기존 11만 개 상품에도 디테일컷을 적용해야 했습니다.

대량 처리 시에는 Lambda를 순차적으로 호출하는 방식을 사용했는데,

연속 요청이 들어오면 Lambda 컨테이너가 Warm 상태로 유지되어 모델을 매번 다시 로드하지 않아도 됩니다.

이 특성 덕분에 별도의 배치 인프라 없이 기존 상품 마이그레이션을 완료할 수 있었습니다.

성과

비즈니스 성과

디테일컷이 상품 상세 페이지에 추가되면서, 구매자가 상품의 세부 상태를 직접 확인할 수 있게 되었습니다.

검수 공정에서도 디테일컷 생성이 자동화되어, 상품당 약 63초의 공정 시간이 절감되었습니다.

기술적 성과

25배 빠른 추론: VLM 5초 → Detector 200ms (CPU 환경 기준)
90% 공정 시간 절감: 상품당 70초 → 7초
10배 낮은 비용: VLM 대비 대량 처리 비용 약 1/10 수준
10개 의류 카테고리 지원: 아우터, 긴팔/반팔 상의, 긴/반바지, 원피스, 스커트, 민소매, 세트

마치며

돌이켜보면, 이 프로젝트의 핵심은 "AI를 어떻게 쓸 것인가"보다 "이 문제에 AI가 정말 필요한가 "를 먼저 물었던 데 있었습니다.

의류의 공간적 규칙성이라는 도메인 지식이 이미 답을 가지고 있었고,

우리는 그걸 좌표 규칙으로 옮기기만 하면 됐습니다.

물론 Rule-based Crop이 모든 걸 해결해주는 건 아닙니다.

지금은 "부위가 어디에 있는가"만 다루고 있지만, 앞으로는 "그 부위의 상태가 어떤가", 마모도, 오염, 변색 같은 상태 판별이 필요한 시점이 올 겁니다.

그때는 이미지를 이해하고 추론하는 능력이 진짜로 필요해지고, 그게 바로 VLM이 제 역할을 할 수 있는 영역이라고 생각합니다.

적합한 도구는 문제에 따라 달라집니다.

이번에는 Detector와 규칙이 정답이었고, 다음 문제에서는 VLM이 정답일 수 있습니다.

중요한 건 도구를 먼저 정하는 게 아니라, 문제의 구조를 먼저 파악하는 것 입니다.

가장 빠른 추론은, 추론하지 않아도 되는 문제를 알아보는 것에서 시작합니다.

TEAM MUSINSA CAREER

무신사는 2001년 온라인 커뮤니티로 시작해 2005년 무신사 매거진, 2009년 무신사 스토어를 오픈하며 빠르게 성장하고 있는 국내 대표 온라인 패션 스토어입니다. '입점 브랜드와 동반성장'이라는 경영 철학을 바탕으로 브랜드가 안정적으로 사업을 전개할 수 있도록 무신사가 보유한 노하우와 인프라를 지원합니다. 고객에게는 풍성한 패션 콘텐츠와 패션에 특화된 차별화된 서비스로 최상의 온라인 쇼핑 경험을 제공하고 있습니다. 글로벌 №1 패션 기업으로 성장할 무신사와 함께 새로운 도전과 혁신을 만들 인재를 기다립니다. 29CM는 '고객의 더 나은 선택을 돕는다'라는 미션으로 출발했습니다. 우리는 우리만의 방식으로 콘텐츠를 제공하며, 브랜드와 고객 모두에게 대체 불가능한 커머스 플랫폼을 만들어가고 있습니다. 이 미션을 이루기 위해 우리는 흥미로우면서도 복잡한 문제들을 해결하고 있습니다. 만약 우리와 함께 이 문제들을 해결해 보고 싶다면, 주저하지 말고 29CM에 합류하세요! 🚀 팀 무신사 채용 페이지(무신사/29CM 전체 포지션 확인이 가능해요) 🚀 팀 무신사 테크 소식을 받아보는 링크드인 🚀 팀 무신사 뉴스룸

VLM을 쓰지 않은 이유: Geometric Prior로 25배 빠른 의류 디테일컷 자동화 was originally published in MUSINSA techblog --- 무신사 테크 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.