research / market / 유사 사례

! 작업 노트입니다. 가설과 실험 계획이 섞여 있고, 사실이 아닐 수 있습니다.

유사 사례 리서치 — "중소 제조 데이터·환경 → OpenAI(Korea 경유) 공급"

최종 갱신 2026-10-26

목차
  1. 0. 한 줄 결론
  2. 1. 데이터 공급사: 한 버티컬 → 랩 공급
  3. 2. 벤치마크를 쐐기로 쓴 팀
  4. 3. 커뮤니티·해커톤을 파이프라인으로
  5. 4. 빅테크 현지법인과 공동사업
  6. 5. 종합: 구봉이 반드시 잘할 것 / 하지 말 것
  7. 6. 적용 시나리오 한 줄 (11/6 게이트와 연결)
  8. 7. 출처 확인 현황

0. 한 줄 결론

성공 사례의 공통 패턴은 (1) 고객이 실제로 돈을 쓰는 한 버티컬에서 품질로 표준이 된다 → (2) 그 버티컬 신뢰를 랩 공급으로 옮긴다 → (3) 벤치마크는 '판매 도구'가 아니라 '중립 신뢰 자산'으로 운영한다이다. 실패·논란 사례(FrontierMath 공개 지연, Scale의 AV 시장 한계, SWE-bench Verified 오염)는 모두 자금 출처·데이터 접근권 비공개, 단일 시장 과의존, 공개 데이터 오염에서 나왔다. 구봉의 사업에 적용하면 "OpenAI에 데이터를 판다"보다 "한국 제조 과제 환경 + 독립 평가 + 권리 정리된 공급망"을 OpenAI 1곳이 아닌 랩 여러 곳에 팔 수 있는 구조로 짜고, OpenAI Korea는 첫 레퍼런스이자 공동 프로그램 파트너로 두는 것이 사례들과 맞다.

1. 데이터 공급사: 한 버티컬 → 랩 공급

1-1. Scale AI (자율주행 집중 → 랩·정부 공급)

반드시 잘할 것: 고객이 이미 돈을 크게 쓰는 버티컬 하나에서 "가장 어려운 데이터(LiDAR 같은)"를 가장 정확하게 처리. 민감 데이터의 처리 위치·비공유 원칙을 처음부터 계약 문구로.
하지 말 것: 그 버티컬의 시장 크기를 회사의 상한으로 착각. 버티컬 데이터 자체를 상품으로 고정.
적용 HYPOTHESIS: 한국 제조(PLC 복구 에피소드)는 Scale의 LiDAR처럼 "어렵고 오류가 비싼" 데이터라 신용 자산이 될 수 있다. 다만 Scale은 고객(AV사)이 이미 큰 예산을 쓰는 상태였고, 우리는 OpenAI의 제조 예산이 확인되지 않았다(근거 0). 따라서 첫 고객은 "제조 데이터로 돈을 쓰는 게 증명된 곳"(국내 모델사·SI·대기업 계열)을 먼저 잡고, OpenAI는 "다음 단계의 큰 고객" 위치가 Scale 경로와 맞다. 제조만 고집하면 Scale의 AV 한계를 반복할 수 있으므로 법률·의료는 같은 파이프라인의 두 번째 버티컬로 남겨 둔다.

1-2. Surge AI (품질 집착, 부트스트랩)

반드시 잘할 것: 소수 고객(랩)에게 "품질 = 전문가 취향"을 증명. 사람 수가 아니라 검수 기준이 해자.
하지 말 것: 벤치마크 점수 올리기용 데이터 납품(창업자 본인이 비판). 고객 1~2곳 의존.
적용 HYPOTHESIS: 우리 쪽 '품질'의 정의는 "PLC 엔지니어 검수 + oracle/nop 통과 + 권리 분리". 12개 랩 중 OpenAI 1곳만 보면 Surge보다 훨씬 심한 집중이다. 제안 단계부터 "OpenAI 우선 공급, 비독점"과 "독점 시 가격 4~5배"(가설)를 분리해 두는 게 협상 여지를 남긴다.

1-3. Mercor (채용 마켓 → 전문가 데이터)

반드시 잘할 것: "기업이 데이터를 안 준다"는 공백을 전문가(퇴직·현직 엔지니어) 노동으로 우회하는 공급 경로.
하지 말 것: 총매출(gross)을 매출처럼 말하기. 랩이 내재화할 수 있는 단순 중개.
적용 HYPOTHESIS: 중소 제조사가 원본 데이터를 OpenAI에 넘길 가능성은 낮다(국가핵심기술·망분리). Mercor식으로 PLC·MES 엔지니어 네트워크가 가상 PLC 과제를 재현·검수하는 모델이 법적 리스크를 줄이면서 "중소기업 지식"을 공급하는 현실적 경로다. 해커톤(Team Attention)은 이 엔지니어 풀을 모으는 채널이 될 수 있다.

2. 벤치마크를 쐐기로 쓴 팀

2-1. SWE-bench → SWE-bench Verified (OpenAI 공동)

반드시 잘할 것: 학계 원저자 + 랩이 함께 "검수판"을 내는 구조(위상 상승의 실제 경로). 오염·불공정 과제 감사를 정기화.
하지 말 것: 공개 데이터에서 만든 벤치를 영구 자산으로 믿기. 포화된 벤치로 계속 마케팅.
적용 OBSERVED→HYPOTHESIS: 우리가 이미 한 PLCWorld 결함 감사(64개 후보→저자용 22건)는 OpenAI가 SWE-bench에 한 일과 같은 종류의 작업이다. 공동논문은 "원저자 + 한국 학계(KAIST) + 랩 연구자 + EF 감사팀"의 Verified형 구도로 제안하면 선례가 분명하다. 단 공개 데이터는 결국 오염되므로, 비공개 홀드아웃(실제 한국 공장 재현 과제)이 OpenAI에 파는 진짜 상품이 된다. OpenAI가 원하는 "긴 과제·루브릭 채점"이 제조 복구 에피소드와 맞물린다.

2-2. Epoch AI FrontierMath (랩 자금 + 비공개 문제)

반드시 잘할 것: 랩 자금·접근권을 첫날부터 공개하고, 독립 홀드아웃을 계약서에 명문화. 기여자(공장·엔지니어)에게 최종 수요처를 알린다.
하지 말 것: "OpenAI가 공개 허락할 때까지 비공개" 조항 수용. 구두 학습금지 합의.
적용 HYPOTHESIS: 이 사업은 FrontierMath와 구조가 거의 같다(랩이 비공개 과제를 사고, 같은 과제로 벤치 점수를 낸다). 공장·엔지니어가 "OpenAI에 들어간다"는 걸 나중에 알면 공급망이 무너진다. (a) 판매용 과제와 공개 리더보드용 홀드아웃 분리, (b) 공급자 동의서에 최종 수요처 범주 명시, (c) 공동논문에 OpenAI 저자가 들어가면 이해관계 공개를 원칙으로 둔다.

2-3. METR (자금 독립)

적용 HYPOTHESIS: 우리는 영리이고 OpenAI에 팔 생각이므로 METR식 독립은 불가능하다. 대신 "평가 사업부(공개 벤치)와 공급 사업부(비공개 과제)의 분리 + 공개"가 현실적 대안. 벤치 자체는 토큰 지원만 받는 구조가 위상 유지에 유리.

2-4. Artificial Analysis (독립 벤치 → 데이터 사업)

적용 HYPOTHESIS: 랩이 자기 점수를 퍼뜨려 주는 순간 벤치 인지도가 생긴다. 우리 PLCWorld에서 OpenAI 모델이 1위(83.3%)이면서 Motion Hard 11.1% 라는 결과는 "OpenAI가 공유하고 싶은 숫자 + 메워야 할 약점"을 동시에 준다. AA Index에 제조 트랙 편입 제안도 노출 경로 후보.

2-5. Harvey BigLaw Bench / Vals AI VLAIR (법률)

반드시 잘할 것: 수요 측 컨소시엄(로펌 6곳 ↔ 제조 대기업·SI)이 문제를 쓰게 하라. 그래야 벤치 결과가 구매 기준이 된다.
하지 말 것: 벤더가 빠질 수 있는 구조(선두 업체 불참 → 대표성 약화). 벤치를 자사 제품 홍보로만 쓰기(Harvey식은 신뢰 한계).
적용 HYPOTHESIS: "대기업 후원사가 가상 문제를 가져오는 산업 해커톤" + "대기업 담당자 밋업" 구상은 Vals 컨소시엄의 한국 제조판으로 설계할 수 있다. 국내 제조 대기업·SI가 "문제 작성 컨소시엄"이 되면 벤치는 구매 기준이 되고, OpenAI Korea엔 "한국 대기업이 직접 정의한 과제에서 OpenAI 모델 성적"이라는 서사가 된다. 법률은 "같은 방법론이 법률에서 이미 시장 표준(Vals·Harvey)"이라는 방법론 증거로만 한 줄 쓰는 게 맞다(우리에겐 법률 실물 자산 없음).

2-6. LMSYS Chatbot Arena → LMArena

적용 HYPOTHESIS: 커뮤니티(투표자) → 신뢰 → 랩·기업 유료 평가의 순서. TA 커뮤니티(랄프톤 참가자)가 제조 과제를 풀고 평가하는 구조라면 "사람이 푼 기준선(human baseline)"을 커뮤니티로 만들 수 있다. 다만 랩 우대 의혹이 가장 큰 리스크라는 점은 2-2와 같다.

2-7. OpenAI GDPval (OpenAI 자신의 수요 신호)

적용 HYPOTHESIS: OpenAI는 이미 제조를 "경제가치 평가" 축에 넣었지만, 디지털 업무 직업만 다루고 PLC·설비 제어 같은 물리 연동 업무는 비어 있다. 제안 프레이밍: "GDPval이 다루지 못하는 제조 현장 제어·복구 과제를, 한국 공장 기준으로 같은 방법(전문가 작성·루브릭)으로 공급". 이것이 OpenAI 내부 언어와 가장 잘 맞는 문장이다.

3. 커뮤니티·해커톤을 파이프라인으로

3-1. Hugging Face

3-2. Kaggle

3-3. Weights & Biases

반드시 잘할 것(3절 공통): 커뮤니티가 매번 쓰는 기본 도구·장소가 되는 것(HF Hub, W&B 대시보드, Kaggle 리더보드). 대회는 1회성 행사가 아니라 같은 리더보드·데이터셋에 결과가 쌓이게.
하지 말 것: 행사마다 새 주제·새 저장소(누적 0). 커뮤니티 성장 단계에서 과도한 유료화.
적용 HYPOTHESIS: 랄프톤을 "AutoFactory-Bench에 제출하는 시즌제 대회"로 만들면 Kaggle형 누적이 생긴다. 참가자 제출물 = human/agent 기준선 + 신규 과제 후보. Kaggle·W&B가 결국 플랫폼 사업자(Google Cloud·CoreWeave)에 팔린 점은, 이 경로의 출구가 "OpenAI 직판"보다 "랩·클라우드에 평가·커뮤니티 자산이 흡수되는 것"일 수 있음을 시사(VISION).

4. 빅테크 현지법인과 공동사업

4-1. SoftBank × OpenAI (일본, SB OAI Japan)

4-2. OpenAI Korea

4-3. OpenAI Data Partnerships (2023)

반드시 잘할 것(4절): 현지법인의 공식 정책 언어에 맞춰 제안(청사진의 "제조·중소기업·데이터 사일로·협업 허브"를 그대로 사용). 현지 파트너가 실행·통합(SI) 역할을 맡는 구조(SoftBank가 그 예).
하지 말 것: 현지법인을 "구매 결정권자"로 가정(조달·데이터 구매는 본사 post-training/human data 팀일 가능성 높음 — 미확인). Data Partnerships처럼 무상 기증 구도로 끌려가기(국가/공공은 무상, 기업은 유상 구분 필요).
적용 HYPOTHESIS/VISION: OpenAI Korea에게 줄 수 있는 것은 "데이터 판매"보다 청사진 권고의 실행 파트너다 — "한국 제조 중소기업 데이터 사일로를 권리 정리된 과제 환경으로 바꾸는 협업 허브(EF) + 대기업 문제 컨소시엄(해커톤·밋업) + 평가(AutoFactory-Bench)". 지사장 입장에서 이것은 본사에 보고할 '한국 성과'이고, 실제 구매(과제 환경 대금)는 본사 팀으로 이어지는 2단 구조가 SoftBank·Data Partnerships 사례와 맞다. 무상 기증 요청이 오면 공개 벤치(무상) / 비공개 과제(유상)로 선을 긋는다.

5. 종합: 구봉이 반드시 잘할 것 / 하지 말 것

#반드시 잘할 것근거 사례
1버티컬 1개(PLC 복구 에피소드)에서 "가장 어렵고 정확한" 공급자가 되기Scale, Surge
2수요 측 대기업이 문제를 쓰는 컨소시엄(랄프톤·밋업 = 컨소시엄 모집 채널)Vals VLAIR, Kaggle
3랩 자금·접근권·저자 이해관계 첫날 공개 + 독립 홀드아웃 계약 명문화FrontierMath, METR, Epoch 투명성
4공개 벤치는 정기 감사·버전업, 판매 가치는 비공개 과제에SWE-bench Verified→폐기
5OpenAI 내부 언어(GDPval·청사진)로 빈칸을 정확히 지목GDPval, Korea 청사진
6원본 대신 엔지니어 재현·검수 노동으로 공급(법적 리스크 회피)Mercor, Scale 처리 원칙
#하지 말 것근거 사례
1OpenAI 1곳 독점 의존·독점 계약을 싸게 주기Surge 집중 리스크, Scale AV 한계
2기여자(공장·엔지니어)에게 최종 수요처 숨기기FrontierMath
3원본 데이터 브로커리지(회사 non-goal, 산업기술보호법 리스크)회사 미션, Scale 비공유 원칙
4무상 데이터 기증 구도 수용OpenAI Data Partnerships
5"최초" 주장, gross 숫자 과장Mercor gross 논쟁, PLCBench 선행
6행사마다 새 주제로 누적 없는 해커톤Kaggle/HF 대비

6. 적용 시나리오 한 줄 (11/6 게이트와 연결)

7. 출처 확인 현황

← Research 목차