미국 최대 배달 앱인 도어대시가 음식 메타데이터를 어떻게 만드는지 엔지니어링 블로그에 공개했어요. '메뉴 데이터가 뭐 그리 어렵나' 싶을 수 있는데요, 수십만 개 가게가 제각각의 방식으로 올린 메뉴에서 쓸 만한 정보를 뽑는 건 생각보다 훨씬 까다로운 문제거든요. '할머니 특제 매운 볶음'이라는 메뉴명만 보고 이게 채식인지, 얼마나 매운지, 어떤 요리 분류인지, 알레르기 유발 재료가 들었는지를 구조화된 데이터로 만들어야 검색, 필터, 추천이 제대로 돌아가요. 이 태깅 품질이 곧 서비스 품질인 셈이죠.
LLM 배심원단, 이게 뭐냐면
요즘 이런 판단 작업을 LLM에게 맡기는 건 업계 표준이 됐어요. 흔히 'LLM-as-judge(심판으로서의 LLM)'라고 부르는 패턴인데요. 문제는 모델 하나의 판단에는 구멍이 많다는 거예요. 특정 방향으로 치우친 편향이 있고, 같은 질문을 두 번 던지면 답이 흔들리기도 하고, 애매한 케이스에서 아주 자신 있게 틀리기도 하거든요. 그래서 나온 게 배심원단(jury) 방식이에요. 판사 한 명 대신 배심원 여러 명이 평결을 내리듯, 여러 모델(또는 여러 프롬프트 설정)에게 같은 판단을 시키고 다수결로 결론을 내는 거죠. 흥미로운 건 비용 면에서도 이게 이길 수 있다는 점이에요. 비싼 대형 모델 하나보다 저렴한 모델 여러 개의 합의가 더 정확하면서도 더 싸다는 연구 결과들이 나와 있거든요. 사실 이건 전통 머신러닝의 앙상블 기법, 그러니까 약한 모델 여러 개를 묶어 강한 모델을 만드는 오래된 지혜가 LLM 시대에 부활한 거예요.
컨텍스트 최적화 — 뭘 보여줄지가 절반이에요
또 하나의 축은 모델에게 어떤 정보를 얼마나 보여줄 것이냐예요. 메뉴명만 줄지, 설명과 가격을 붙일지, 고객 리뷰까지 넣을지, 사진도 보여줄지에 따라 정확도와 비용이 크게 달라지거든요. 정보를 다 넣으면 좋을 것 같지만 실제로는 토큰 비용이 폭발하는 데다, 관련 없는 정보가 오히려 판단을 흐리는 경우도 많아요. 그래서 항목 특성에 따라 필요한 정보만 골라 넣는 컨텍스트 최적화가 중요해지는데, 이건 요즘 얘기되는 컨텍스트 엔지니어링의 실전 사례라고 볼 수 있죠. 수백만 건을 처리하는 파이프라인에서는 항목당 토큰 몇백 개 차이가 곧바로 큰돈이 되니까요.
텍스트가 부실하면 사진을 봐요
멀티모달 활용도 실용적인 포인트예요. 메뉴 설명이 아예 없거나 부실한 가게가 많은데, 이럴 때 음식 사진을 비전 모델에 넣어서 요리 종류나 구성 재료 같은 정보를 뽑아내는 거죠. 텍스트와 이미지 신호를 합치면 어느 한쪽만 볼 때보다 훨씬 안정적인 태깅이 가능해져요.
실무에 바로 가져갈 수 있는 패턴
이 사례에서 한국 개발자가 가져갈 수 있는 핵심 패턴은 '합의도를 신뢰도로 쓴다'는 거예요. 배심원들이 만장일치면 자동 승인하고, 의견이 갈리는 항목만 사람이 검수하는 human-in-the-loop 구조를 만들면, 전수 검수 대비 라벨링 비용을 극적으로 줄이면서 품질은 지킬 수 있거든요. 이건 음식 데이터에만 해당하는 얘기가 아니에요. 커머스 상품 속성 태깅, 게시글 분류, 고객 문의 라우팅, 심지어 자체 LLM 기능의 품질 평가 파이프라인까지, 대량의 판단 작업이 있는 곳이라면 어디든 적용할 수 있는 구조예요. 국내 배달·커머스 서비스들도 똑같은 문제를 안고 있을 테니, 오늘 다룬 구조를 그대로 벤치마킹해볼 만하죠.
정리하면, 핵심은 'LLM 하나의 출력을 믿지 말고, 여러 판단의 합의와 불일치를 시스템 신호로 활용하라'는 거예요. 여러분 서비스에서 지금 사람이 일일이 하고 있는 반복 판단 작업 중에, 배심원단 구조로 넘길 만한 건 뭐가 있을까요?
🔗 출처: Hacker News