ai research
좋은 AI 데이터는 진짜 업무 source에서 나온다: Sean Cai
- AI 데이터 시장은 이제 인터넷에서 긁은 데이터나 인위적으로 만든 데이터만으로는 long-horizon training을 계속 개선하기 어렵다는 쪽으로 움직이고 있음
- 그래서 일부 데이터 buyer는 실패한 스타트업의 codebase, git commit, PR, 문서, 업무 기록을 대량으로 사려는 흐름이 생긴다는 주장
- 하지만 Sean Cai는 “진짜 회사에서 나온 데이터”라고 해서 자동으로 좋은 학습 신호가 되는 건 아니라고 봄
- 핵심은 real-world data가 아니라, 좋은 source에서 나온 실제 업무 데이터임. 망하기 직전 급하게 붙인 코드와 PR은 오히려 신호가 지저분할 수 있음
- Sean Cai가 X에서 AI 학습 데이터 시장의 다음 병목을 설명한 글
hillclimb가 왜 현실 데이터에 막히나?
- hillclimb는 모델 성능을 조금씩 끌어올리는 과정을 말함. 산을 오를 때 발을 한 걸음씩 더 높은 곳에 올리는 것과 비슷함
- 예전에는 인터넷 텍스트, 간단한 라벨링 데이터, synthetic data(모델이 만든 인공 데이터)만으로도 성능을 계속 올릴 수 있었음
- 하지만 모델이 실제 업무를 여러 단계로 처리해야 하는 long-horizon task에서는 단순 텍스트만으로 부족해짐
- 예를 들어 “고객 문의를 읽고, CRM에서 주문 내역을 찾고, 환불 정책을 확인하고, 답변을 보내라”는 작업은 한 줄 답변 문제가 아님
- 이 구간에서는 문제, 중간 판단, 도구 조작, 실패와 수정, 최종 완료가 이어진 trajectory(행동 흐름 데이터)가 필요함
왜 실패한 스타트업 데이터는 약할 수 있나?
- 데이터 시장이 실제 업무 데이터를 찾다 보니, 실패한 스타트업의 codebase나 git history를 사려는 시도가 생김
- 겉으로는 좋아 보임. 실제 회사에서 나온 코드, PR, issue, 문서이기 때문
- 하지만 실패한 스타트업의 마지막 데이터는 최고의 의사결정 기록이 아닐 수 있음
- 망하기 직전에는 급하게 붙인 코드, 끝까지 검증되지 않은 기능, 피봇하다 남은 흔적, 임시방편 PR이 섞이기 쉬움
- 그래서 real-world data가 곧 high-quality data는 아님. 좋은 데이터는 실제 업무에서 나왔고, 동시에 좋은 사람이 좋은 맥락에서 만든 데이터여야 함
| 데이터 source | 좋아 보이는 이유 | 위험한 점 |
|---|---|---|
| 인터넷 데이터 | 규모가 크고 싸게 모을 수 있음 | 이미 많이 긁었고 업무 과정이 없음 |
| synthetic data | 빠르게 만들 수 있음 | 모델이 만든 패턴을 다시 학습할 수 있음 |
| 실패한 스타트업 codebase | 실제 회사 데이터처럼 보임 | 급조된 결정과 낮은 품질이 섞일 수 있음 |
| 실제 업무 trajectory | 문제 해결 과정이 살아 있음 | 접근 권한, 보안, 동의, 품질 관리가 어려움 |
좋은 real-world data는 어떤 모습인가?
- 좋은 데이터는 단순 결과물이 아니라, 사람이 실제 문제를 해결하는 과정까지 담고 있어야 함
- 예를 들어 실제 회사의 GitHub commit, PR discussion, issue 해결 과정, 고객지원 티켓, CRM 기록, 업무 도구 조작 로그가 여기에 가까움
- CUA(computer-use agent) 관점에서는 사람이 브라우저에서 목표를 해결하는 screen trajectory가 중요해짐
- 좋은 형태는 before/after screenshot, DOM/action log, 실패 케이스, verifier(성공 여부를 확인하는 장치), reward signal(점수 기준)까지 붙은 데이터임
- 한국이라면 쇼핑몰 상품 등록, CS 처리, 홈택스 업무, 병원 예약, 학원 CRM, 공공기관 신청과 조회 같은 workflow가 실제 source가 될 수 있음
자연스러운 업무 데이터가 왜 더 강한 신호인가?
- Sean Cai는 가장 좋은 데이터가 “AI 학습에 쓰인다는 걸 모르는 사람들”에게서 나온다고 말함
- 이 문장은 윤리적, 법적 논쟁이 큰 표현임. 동의, 보안, 개인정보 문제는 반드시 별도로 해결해야 함
- 다만 데이터 품질 관점에서 말하려는 요지는 이해할 수 있음
- 사람이 “AI 학습용 데이터를 만들고 있다”고 의식하면 라벨러처럼 행동하거나, 보상 기준에 맞춰 부자연스럽게 행동할 수 있음
- 반대로 자기 일을 실제로 끝내는 사람의 행동에는 암묵지, 시행착오, 우선순위 판단, 예외 처리 방식이 자연스럽게 들어 있음
real-world data는 무조건 좋은 AI 학습 데이터인가요?
아님. 실제 세상에서 나온 데이터라도 source가 나쁘면 학습 신호가 약할 수 있음. 중요한 건 “실제 데이터인가”보다 “좋은 사람이 좋은 업무 맥락에서 만든 데이터인가”에 가까움.
failed startup 데이터가 왜 문제인가요?
실패한 스타트업의 codebase나 PR은 실제 회사 데이터처럼 보이지만, 마지막에는 급한 수정과 검증 안 된 의사결정이 많이 섞일 수 있음. 모델이 배우기 좋은 모범 사례라기보다 지저분한 흔적일 가능성이 있음.
CUA 데이터 회사는 무엇을 모아야 하나요?
단순 화면 녹화보다 목표, 행동 순서, 중간 실패, 수정, 최종 결과, 성공 여부를 확인하는 verifier까지 같이 모아야 함. 그래야 모델이 “무엇을 눌렀는지”뿐 아니라 “왜 그 순서로 문제를 풀었는지”를 배울 수 있음.