단순히 ‘proprietary data’를 모으라고 말하는 것은 너무 추상적이다. 이 영상이 제시한 결정적인 통찰은 ‘어떤 데이터가 진짜 독점 가능한가’를 판별하는 기준: 알고리즘적으로 검증 가능한 reward function을 만들 수 없는 데이터만이 진정한 moat이 된다는 것이다. 그리고 그런 데이터를 얻으려면 반드시 환경(closed-loop system)을 먼저 설계해야 한다. 테슬라의 카메라-급제동 데이터, 메이크업 조합에 대한 사용자의 좋아요/싫어요, 로봇 시뮬레이터의 물리 법칙 — 이들은 모두 non-verifiable 데이터를 verifiable label로 바꾸는 ‘환경’의 예다.
노정석은 자신의 경험에서 “evaluation metric이 명확하게 상상 안 되는 프로젝트는 시작하면 안 된다”고 말한다. 이는 결국 어떤 환경이 0/1 라벨을 제공할 수 있는지 먼저 증명해야 한다는 뜻이다. 프런티어 모델 위에 단순한 래퍼를 만드는 대신, 사용자가 참여하는 피드백 루프를 제품 핵심에 내장해야 한다.
근거
“non-verifiable을 verifiable로 바꿔주는 이 시스템, 이 environment를 제가 정의하기로는 이런 거구나. … 그럼 그런 것들을 가능하게 하는 AI 서비스나 simulator를 뭐라고 정의하면 될까? ‘non-verifiable을 verifiable로 바꿔주는 이 closed-loop system이구나’.”
“저희 회사 같은 경우에는 메이크업의 조합들에 대한 데이터셋을 굉장히 많이 만들고 있는데, 그게 대표적으로 기계가 판단할 수 없는 영역이거든요. … 인간은 이 context가 주어지면 이건 명확히 좋고 이건 명확히 싫다는 것들을 계속 labeling을 하거든요.”
연결된 생각
- 20260607-non-verifiable-data-domain-closed-loop — 개념적 프레임워크와 평가 기준
- 20260607-verifiable-reward-function-test-time-compute — verifiable domain과의 대비
- 20260607-physical-simulator-omniverse-robotics — 시뮬레이터가 non-verifiable을 verifiable로 바꾸는 구체적 사례
- 20260607-startup-evaluation-metric-first — 내 생각: 프로젝트 시작 전 evaluation design의 중요성