URL: https://www.youtube.com/watch?v=lCBf9slCanI 날짜: 2026-08-01 채널: AI Engineer (aiDotEngineer)
📌 핵심 질문 / 이 영상이 다루는 핵심 논점
==AI slop(AI가 만든 저품질 콘텐츠)이 발생하는 근본 원인은 "주관적 도메인은 검증(verify)이 불가능하다"는 것이며, 이를 해결하려면 주관적 문제를 분해(decompose)해 검증 가능한 형태로 바꾸는 작업이 선행되어야 한다==. Taste Labs 창업자 Tais는 디자인·글쓰기·창의성 같은 주관적 영역에서 모델이 왜 뒤처지는지를 두 가지 근본 원인(측정 가능성 부족, 평균으로의 붕괴)으로 짚고, 이를 극복하는 실무적 방법론(분해·라우팅·선호 벡터·데이터 QA)을 제시한다.
- 코드와 수학이 모델을 잘 훈련시키기 쉬운 이유는 모델의 속성이 아니라 "코드 자체가 분해되고, 검증되고, 실행된다"는 코드의 속성 때문이다
- 주관적 도메인이 어려운 이유는 두 가지다: (1) 능력은 측정 가능성을 따라간다(capability follows measurability), (2) 평균으로의 붕괴(collapse to the mean)가 주관적 도메인에서는 최적이 아니다
- 브랜드(brand)처럼 이미 잘 정의된 하위 도메인을 예시로 들며, "훌륭한 것을 만들어라"는 막연한 지시를 "브랜드에 맞는 것을 만들어라"는 검증 가능한 문제로 바꾸는 구체적 방법을 제시한다
Taste Labs는 파운데이션 모델 레이어(프론티어 랩과의 벤치마킹·RL 환경 설계)부터 에이전트/애플리케이션 레이어(컨텍스트·유저 인텐트 기반 해결)까지 전 스택에 걸쳐 "데이터와 인프라 레이어"가 되는 것을 목표로 한다.
1. 주관적 도메인이 어려운 두 가지 근본 이유
이 영상 전체를 관통하는 프레임워크로, 코드/수학과 디자인/글쓰기의 차이를 근본적으로 설명한다.
1.1. 능력은 측정 가능성을 따라간다 (Capability follows measurability)
- 코드가 쉬운 이유는 모델의 속성이 아니라 코드의 속성
- 분해·검증·실행 가능성: 코드는 decompose(분해)되고, verify(검증)되고, execute(실행)된다는 성질을 갖고 있어 훈련이 쉽다
- 오해: "모델이 코딩을 잘한다"는 사실을 모델의 속성으로 착각하기 쉽지만, 실제로는 우리가 코드를 그렇게 훈련시키기 쉬운 도메인으로 만들었기 때문이다
- 디자인·글쓰기는 분해·검증·판단이 모두 어렵다
- 정의 불가능성: "훌륭한 디자인이란 무엇인가"라는 질문 자체에 명확한 정답이 없다
- 다중 정답 구조: 세일즈·마케팅 같은 회사 내부 워크플로우도 정답이 하나가 아니라 여러 개인 경우가 대부분이다
1.2. 평균으로의 붕괴(Collapse to the mean)가 문제인 이유
- 모델은 "가장 가능성 높은 다음 결과"를 예측하고 이를 이상적인 답으로 가정한다
- 수학/코딩에서는 유효함: "2+2가 뭐야?"라는 질문에서 가장 가능성 높은 답(4)이 곧 정답이자 최적의 답이다
- 디자인/글쓰기에서는 무효함: 평균적인 답, 즉 가장 가능성 높은 답이 최적의 답과 일치하지 않는다
- 위대함과 창의성은 분포의 끝(ends of the distribution)에서 나온다
- 규칙 파괴: 능동적으로 규칙과 패턴에서 벗어날 때 주관적이면서도 위대한 것이 만들어진다
- AI slop의 정체: 이 평균으로의 붕괴와 반복이 바로 우리가 "슬롭에 둘러싸여 있다"고 느끼는 이유다
2. 주관적 문제를 검증 가능하게 만드는 방법: 분해(Decomposition)
2.1. 브랜드(Brand) 사례 — Redoct 웹사이트 예시
- 왜 브랜드가 좋은 예시인가
- 막연한 질문 vs 구체적 질문: "훌륭한 것을 만들어라"는 어렵지만, "브랜드에 맞는 것을 만들어라"는 훨씬 쉬운 문제로 정의된다
- 기존 자산 활용: 회사 디자이너들이 이미 색상·타이포그래피·간격·텍스처의 조합을 왜 선택했는지에 많은 노력을 들여 브랜드를 정의해 놓았다는 "비밀 무기"가 있다
- 분해 프로세스
- 구성요소 코드화: 브랜드를 색상, 타이포그래피, 모션, 애니메이션, 텍스처로 분해하면 검증 가능한 코드화된 요소가 된다
- LLM-as-judge의 한계: "이게 브랜드에 맞나?"를 LLM에게 통째로 판단시키는 것은 어렵지만, 정확한 구성요소를 하나씩 뜯어보면 검증 가능한 형태로 바뀐다
2.2. RL 환경 설계와 그라운드 트루스(Ground Truth)
- 분해가 곧 그라운드 트루스가 된다
- 태스크 설계가 가장 어려운 부분: 애매해 보이는 태스크를 실제로 RL할 수 있는 형태로 바꾸는 것이 문제의 핵심 난이도다
- 원본 복제가 아닌 새로운 창작 평가: 에이전트에게 "레독트 브랜드를 따르되 완전히 새로운 페이지를 만들라"는 태스크를 줄 경우, 원본과의 유사도가 아니라 분해된 그라운드 트루스 기준으로 평가해야 한다 (구성요소를 새로운 방식으로 유효하게 조합할 수 있기 때문)
- LLM-as-judge의 위험성
- 리워드 해킹: LLM을 심사자로 쓸 경우 리워드 해킹(reward hacking) 패턴이 자주 발생한다
- 환각 패턴: 흥미로운 형태의 환각(hallucination) 패턴도 함께 나타난다
2.3. 객관-주관 스펙트럼과 라우팅 문제
- 모든 문제는 스펙트럼 위에 있다
- 객관에 가까운 요소: 디자인 안에서도 비전(vision)·정렬(alignment)·타이포그래피 같은 요소는 상대적으로 객관적 축에 가깝다
- 주관에 가까운 요소: 스타일 적합성(style fit)·창의성(creativity) 같은 요소로 올라갈수록 판단과 측정이 훨씬 어려워진다
- 핵심 메시지: 라우팅 로직
- 문제 분해 후 최적 해법 매칭: 이 거대하고 애매한 문제를 어떻게 쪼개서 각 하위 요소마다 최선의 해결 방법(RL 환경화 vs 포스트 트레이닝 데이터 vs 인간 판단)을 찾을지가 이 영상의 유일한 한 가지 핵심 교훈(one takeaway)이다
3. 인간 판단과 다중 선호(Multi-preference) 데이터
3.1. 인간 판단이 여전히 필요한 이유
- 인간 취향의 우월성: 인간의 판단은 여전히 어떤 LLM-as-judge보다 훨씬 높은 수준이며, 이 "인간의 취향"을 고품질 데이터로 정제하는 것이 관건이다
- 디자이너 커뮤니티 활용: Taste Labs는 다양한 매체·스타일에 정통한 1,000명 이상의 전문가 커뮤니티와 협업하며, 문제를 쪼갤 때 의도적으로 분포를 강제로 다양화(force the distribution)해 mode collapse를 방지한다
3.2. 선호 데이터가 평균으로 붕괴하는 문제
- 과거 선호 데이터 수집의 함정
- 무맥락 수집의 문제: 누구인지, 무엇을 좋아하는지, 왜 좋아하는지, 언제 좋아하는지를 이해하지 않고 여러 사람으로부터 선호 데이터를 모으면 다시 평균으로 붕괴한다
- 의견 불일치는 자연스러운 현상: 어떤 사람이 A 스타일을 더 좋아하고 다른 사람이 B 스타일을 더 좋아하는 것은 둘 다 틀린 게 아니며, 정답이 둘의 평균도 아니다
- 선호 벡터(Preference vector) 개념
- 다원주의를 데이터에 내재화: 세상은 다중 선호(multi-preference)로 구성되어 있다는 것을 근본적으로 이해하고, 개인별 선호 벡터를 만들어 선호 데이터에 부착하면 노이즈가 아닌 의도적 다원성으로 훈련할 수 있다
4. 데이터 품질 확보 전략
4.1. 문제 분해와 전문가 선정 — 완전히 통제 가능한 영역
- 문제 분해의 강제: 세상에서 관찰되는 진짜 분포(true distribution)를 얼마나 강제로 재현하는지가 통제 가능한 변수다
- 전문가 선정의 엄격성: 어떤 전문가인지 알 수 있고, 매우 엄격한 선정 패턴을 적용할 수 있다는 점에서 이 부분은 실험 결과 품질에 완전히 통제 가능한 기여를 한다
4.2. 데이터 QA — 신호가 풍부한 데이터의 특성
- 구체성(Specificity)
- 전문가 언어의 정밀도: 전문가에게 "이게 좋다/나쁘다"를 판단하게 하거나 근거를 대게 할 때, 그 언어의 구체성과 정밀도가 데이터 품질을 결정한다
- 관찰 시스템 구축: 전문가가 자산(asset)을 어떻게 판단하는지에 대한 전체 관찰 시스템을 만드는 것이 중요하다
- 코드-코멘터리 연결(Code-tied commentary)
- 모델의 약점 보완: 모델은 코드 조각과 시각적 결과물을 실제로 연결하는 데 어려움을 겪는다는 것이 알려져 있다
- 정확한 연결의 효과: 전문가의 코멘터리를 정확한 코드 컴포넌트에 연결시키는 방법을 찾으면 훨씬 노이즈가 적고 명확한 데이터가 만들어진다 (예: 랜딩 페이지를 심사하는 전문가의 문단 설명보다, 코드 특정 부분과 연결된 코멘트가 훨씬 유용하다)
4.3. Human QA와 컨센서스 불일치 분석
- 두 종류의 Human QA
- 스펙 준수 체크: 대부분이 동의할 만한 규격(spec)을 따르는지 확인하는 기본적인 QA
- 전문가 컨센서스 체크: 다른 전문가가 초기 심사자의 판단에 동의하는지 확인하는 QA
- 불일치(disagreement)를 해석하는 방법이 핵심
- 결함으로서의 불일치: 정렬(alignment)처럼 객관적 성격이 강한 요소에서 전문가들이 불일치한다면 이는 데이터의 결함(flaw)일 가능성이 높다
- 좋은 데이터로서의 불일치: 스타일이나 미학(aesthetics)처럼 주관적 요소에서 전문가들이 불일치한다면, 이는 나쁜 데이터가 아니라 사람들의 취향 차이를 보여주는 좋은 데이터다
주요 발언 모음
"Our whole mission is basically how do we end AI slop? And we believe that to really solve this problem, we have to first decompose and understand subjective domains."
"Code is something that decomposes, it verifies, it executes and so it makes it a lot easier for us to be able to train on these domains... but realistically it's actually a fact about code [not the model]."
"A lot of like what I describe it is a lot of greatness and creativity happens actually at the ends of the distribution. It's not the most likely outcome."
"The closer you are to something that it becomes verifiable, especially programmatically, the better for something like RL... but the more that it does shift to things that are contextual... the more this shifts towards something that requires human judgment."
"We need to fundamentally understand that the world is multi-preference and how do we do that matching accordingly."
"I would advocate for a quality over quantity approach. I think creating high quality data is expensive. It's difficult... [but it] yield[s] far better results than getting a bunch of noisy data."
핵심 데이터 & 수치
- 1,000명 이상의 전문가 커뮤니티: Taste Labs가 다양한 매체·스타일 전문가와 협업해 데이터 수집 시 의도적으로 분포를 강제 다양화하는 데 사용하는 커뮤니티 규모
- 2가지 근본 원인: 주관적 도메인이 어려운 이유 — (1) capability follows measurability, (2) collapse to the mean이 최적이 아님
- Taste Labs의 2가지 사업 축: (1) 프론티어 랩과의 모델 벤치마킹/RL 환경·포스트트레이닝 데이터 설계, (2) 에이전트/애플리케이션 레이어 기업과의 컨텍스트·유저 인텐트 기반 솔루션
결론 및 시사점
- AI slop을 해결하려면 먼저 분해하라: "훌륭한 것을 만들어라" 같은 막연한 문제를, 브랜드처럼 이미 정의된 하위 요소(색상·타이포그래피·모션 등)로 분해해 검증 가능한 형태로 바꿔야 RL이나 벤치마킹이 가능해진다.
- 평균은 답이 아니다: 모델이 학습하는 "가장 가능성 높은 답"은 수학/코딩에서는 정답이지만, 창의성·디자인에서는 오히려 slop의 원인이다. 분포의 끝단을 의도적으로 강제해야 진짜 창의성이 나온다.
- 문제를 라우팅하라: 모든 주관적 문제를 하나의 방법으로 풀려 하지 말고, 객관에 가까운 요소는 검증/RL로, 주관에 가까운 요소는 인간 판단과 선호 데이터로 라우팅하는 것이 핵심 전략이다.
- 선호는 다원적이다: 선호 데이터를 무맥락하게 수집하면 다시 평균으로 붕괴한다. 개인별 선호 벡터를 만들어 다원성을 의도적으로 데이터에 반영해야 한다.
- 데이터는 양보다 질: 특히 주관적 도메인에서는 고품질·고정밀 데이터(전문가의 구체적 언어, 코드-코멘터리 연결, 컨센서스 불일치의 올바른 해석)를 소량이라도 확보하는 것이, 노이즈 많은 대량 데이터보다 훨씬 나은 결과를 낸다.