성공률 20퍼센트가 함정입니다: 제프 딘의 1퍼센트 규칙

7월 30일, 제프 딘이 YC 스타트업 스쿨 무대에서 창업자 6천 명을 앞에 두고 강연했습니다. 제목은 "AI에서 만들 때의 1퍼센트 규칙". 그리고 엿새 뒤 그는 27년 다닌 구글을 떠나 디스커버리 루프를 창업했습니다. 그러니 이 강연은 결과적으로 구글 최고과학자로서의 마지막 공개 조언이자, 자기가 곧 실행할 계획의 예고편이었던 셈입니다.

강연의 뼈대는 하나의 반직관적 규칙입니다. 모델이 이미 20퍼센트쯤 해내는 문제를 골랐다면, 그게 함정입니다.

1퍼센트 규칙: 20퍼센트는 능력이 아니라 예고입니다

딘의 조언은 명료합니다. 노리는 분야를 현재 최고 모델로 직접 시험해 보고, 성공률이 0에서 1퍼센트인 곳을 고르라는 것입니다. 20퍼센트가 나오는 곳은 피하라고 했습니다.

직관과 반대입니다. 보통은 모델이 어느 정도 되는 분야가 시장이 검증된 안전한 자리로 보입니다. 딘의 독해는 거꾸로입니다. 20퍼센트라는 숫자는 그 능력이 모델 안에서 이미 형성되기 시작했다는 신호이고, 데이터와 스케일이 조금 더 붙으면 다음 세대 모델이 그냥 덮어 버립니다. 창업자가 1~2년 걸려 만들 제품을 프런티어 랩의 다음 릴리스가 무료 기능으로 흡수하는 자리라는 뜻입니다.

중요한 것은 0~1퍼센트라는 숫자가 아니라 왜 0인가입니다. 아직 아무도 데이터를 안 부어서 0인 자리는 시간이 해결해 버립니다. 스케일을 부어도 안 뚫리는 구조적인 이유가 있어야 스타트업이 설 땅이 됩니다.

0퍼센트가 나오는 두 가지 구조

딘이 짚은 구조는 둘입니다.

모델이 데이터 자체를 볼 수 없는 자리. 개인의 사적 데이터, 기업 폐쇄망 안의 내부 데이터, 규제로 반출이 막힌 데이터. 구글도 프런티어 랩도 이 데이터로는 학습하지 못했으므로 기본 성공률이 0입니다. 여기서는 모델 성능이 아니라 접근 권한과 신뢰가 해자입니다. 다음 세대 모델이 아무리 똑똑해져도, 볼 수 없는 데이터에 대한 성공률은 오르지 않습니다.

자연어 밖의 법칙이 지배하는 자리. 단백질 접힘, 유체역학, 회로 설계처럼 엄격한 물리·수학 법칙이 정답을 정하는 분야입니다. 인터넷 텍스트를 아무리 섞어도 이 법칙은 유도되지 않고, 알파폴드처럼 도메인 데이터와 구조를 박은 특화 모델이 범용 모델을 이깁니다. 범용 모델의 다음 릴리스가 이 자리를 덮으려면 릴리스가 아니라 별도의 과학 프로젝트가 필요합니다.

파라미터는 수프이고, 컨텍스트는 편지입니다

강연에서 가장 인용할 만한 비유는 학습 데이터에 대한 것이었습니다. 모델이 학습한 수조 개의 토큰은 수천억 개의 파라미터 속에 수프처럼 뒤섞여 있습니다. 반면 추론 시점에 건네는 컨텍스트는 이 문제, 이 사례를 위해 골라 온 것이라 모델에게 훨씬 또렷하게 읽힙니다.

여기서 실무 지침이 나옵니다. 외부에서 하기 어려운 파라미터 수정(파인튜닝) 대신, 도구 사용법과 노하우를 스킬과 문서 형태로 주입하는 쪽이 성공률을 올리는 지렛대라는 것입니다. 학습이 아니라 컨텍스트 엔지니어링이고, 이것은 GPU 클러스터 없이 API 접근만으로 가능한 영역이라 작은 팀에게 열려 있습니다.

딘은 자기 사례를 둘 들었습니다.

퍼포먼스 힌트 문서. 딘과 사냐이 게마와트가 수십 년간 구글의 C++ 저수준 코드를 10배, 100배씩 가속하며 쌓은 노하우를 정리한 성능 최적화 가이드가 있습니다(현재 abseil.io에 공개돼 있습니다). 이 문서를 모델의 컨텍스트에 주입하면, 발언 기준으로 모델이 성능 병목을 추론하는 능력이 눈에 띄게 좋아진다고 합니다. 30년 차 엔지니어의 감각을 파인튜닝 없이 문서 한 편으로 이식하는 셈입니다.

최적화 스킬. 벤치마크를 돌리고, 코드를 고치고, 개선 폭을 측정하고, 다시 반복하는 자율 개선 루프를 스킬로 작성해 직접 쓰고 있다고 했습니다. 사람이 하던 최적화 절차 자체를 에이전트의 작업 단위로 포장한 것입니다.

같은 맥락에서 딘이 꼽은 희소해질 능력이 명세(specification)입니다. 에이전트 성공률을 가장 크게 좌우하는 것은 원하는 것을 명확하게 말하는 능력이라는 것. 그가 든 예가 파이썬 코드를 Go로 옮기는 작업입니다. 이런 변환이 놀랍도록 잘 되는 이유는 모델이 똑똑해서가 아니라 소스 코드 전체가 이미 완벽한 명세이기 때문입니다. 양쪽 결과가 같아질 때까지 테스트를 돌리면 채점도 자동입니다. 명세가 흐린 일감일수록 실패하는 것은 에이전트가 아니라 발주서 쪽이라는 이야기입니다.

개발 속도는 평가기의 속도입니다

며칠에서 몇 주짜리 에이전트 실행에 대한 그의 답도 낭만이 아니라 공학이었습니다. 긴 실행은 에이전트 하나를 오래 믿는 것이 아니라, 여러 갈래를 병렬로 돌리고 평가기가 유망한 가지를 골라내는 구조로 만듭니다. 스킬과 힌트는 에이전트를 학습 분포 안의 "불이 밝게 켜진 길" 위에 붙잡아 두는 장치입니다.

그래서 강연 전체를 관통하는 실무 문장은 이것입니다. 가설을 세우고, 실험하고, 평가하는 루프의 회전 속도가 곧 개발 속도다. 초고속 평가기를 먼저 만들어라. 그가 든 사례는 양자화학입니다. 비싼 시뮬레이터를 신경망으로 근사해 30만 배 빠른 평가기를 만들자 연구 속도 자체가 바뀌었다는 것(발언 기준). 이 논리는 제가 검증 루프 이야기에서 다룬 구조와 정확히 같고, 엿새 뒤 그가 세운 회사가 실험 루프 자동화를 사업 자체로 들고나온 것과도 이어집니다.

냅킨 수학: 실행 전에 자릿수를 계산합니다

강연에서 가장 구글다운 대목은 냅킨 수학(back-of-the-envelope calculation)이었습니다. 엄밀한 공식 대신 냅킨 한 장 분량의 대략 계산으로 문제의 자릿수를 먼저 파악하는 습관입니다. 딘의 경력에서 가장 큰 결정 두 개가 여기서 나왔습니다.

이 습관이 1퍼센트 규칙과 한 쌍이라는 점이 중요합니다. 규칙이 어디서 만들지를 정해 주고, 냅킨 수학은 그 자리에서 10배와 100배가 나올 길이 있는지를 실행 전에 가려 줍니다. 스쿨버스에 골프공이 몇 개 들어가느냐던 옛 구글 면접 문제가 측정하던 능력이 바로 이것입니다. 문제를 분해하고, 합리적으로 추정하고, 규모를 파악하는 힘.

마지막에 남는 것은 취향이고, 취향은 훈련됩니다

사회자가 물었습니다. 수백 개의 에이전트가 코드를 다 짜 주는 미래에 인간에게 남는 가장 희귀한 스킬은 무엇인가. 딘의 답은 취향(taste)이었습니다.

여기서 취향은 어떻게 만들지에 대한 심미안이 아니라 무엇에 시간을 쏟을지 고르는 안목입니다. 실행이 자동화될수록 승부는 문제 선택으로 옮겨 가고, 취향은 타고나는 것이 아니라 경험의 축적과 재조합에서 나온다는 것이 그의 주장입니다. 그리고 구체적인 훈련법을 하나 내놨습니다.

• 향후 12개월 동안 중요해질 것 같은 아이디어와 문제를 지금 전부 적습니다.
• 그중 하나를 골라 1년간 실제로 작업합니다.
• 12개월 뒤 노트를 다시 꺼내 대조합니다. 실제로 중요해진 것은 무엇이었나. 세상 누군가가 만들어 낸 것은 무엇인가. 여전히 아무도 손대지 않은 것은 무엇인가.

예측과 실제의 차이가 기록으로 남는 순간, 자기 안목의 버릇과 맹점이 데이터가 됩니다. 안목을 기르는 검증 루프를 자기 자신에게 거는 방법인 셈입니다. 12개월이 길면 분기 단위로 줄여도 구조는 같습니다.

엿새 뒤, 그는 자기 규칙을 자신에게 적용했습니다

이 강연을 다시 읽으면 흥미로운 사실이 하나 보입니다. 딘이 창업자들에게 준 지도(성공률 0~1퍼센트의 자리, 초고속 평가기, 실험 루프의 회전 속도, 노하우의 스킬화)는 정확히 엿새 뒤 그가 세운 회사의 설계도입니다. 머신러닝 연구의 완전 자동화는 지금 모델의 성공률이 0에 가깝고, 채점기는 이미 코드 안에 있으며, 루프의 회전 속도가 곧 제품인 자리입니다.

모델 회사들이 흔히 말하는 "목표만 주고 모델에 맡기라"와 결이 다르다는 점도 남겨 둘 만합니다. 딘의 강조점은 일관되게 사람이 앞단에서 하는 일에 있었습니다. 명세를 명확히 쓰는 능력, 노하우를 문서와 스킬로 바꾸는 작업, 냅킨 수학으로 자릿수를 가늠하는 습관, 그리고 무엇을 만들지 고르는 취향. 에이전트에게 더 많이 맡기라는 말과 사람의 근본 역량을 더 파고들라는 말이 그에게는 같은 문장이었습니다.

창업자 입장에서 이 강연을 한 문장으로 가져가면 이렇습니다. 지금 모델로 당신 문제를 직접 돌려 보고, 성공률이 낮게 나오면 기뻐하기 전에 그 이유가 구조적인지부터 확인하십시오. 데이터 격리나 물리 법칙이 이유라면 그 자리는 당신 것이고, 단지 아무도 데이터를 안 부었을 뿐이라면 그 자리는 다음 릴리스의 것입니다.