Karpathy의 autoresearch는 밤새 100번 실험해 최적안을 찾습니다. PM의 영역도 같습니다. 리스크를 “피할 것”이 아니라 “점수로 관리하고 기회로 전환할 것”으로 보면, 에이전트가 42건의 리스크에서 패턴을 추출해 조직 표준 RBS를 하룻밤에 만들 수 있습니다.
- Autoresearch는 점수 기반 keep/revert 루프로 작동하는데, PM의 리스크 관리에 적용하려면 “어떤 7가지 지표”로 리스크 점수를 매겨야 할까? 그 점수가 “이 리스크를 취할 것인가”의 의사결정을 실제로 바꿀까?
- LG 워크숍에서 7개 전략 과제에 대해 위협 21건 + 기회 21건을 동시에 식별했는데, 대부분 조직은 왜 “리스크 = 피해야 할 부정적 것”으로만 인식하고 기회 리스크를 무시할까?
- 42건의 리스크에서 자동으로 5대 카테고리 50개 유형의 RBS를 만들었는데, 이 표준이 다음 프로젝트 3개에 실제로 적용되었을 때 리스크 사전 탐지율이 몇 %까지 올라갔을까?
- “준비 안 된 성공”이 실패만큼 위험하다는 통찰에서, PM들이 긍정 리스크(기회)를 구체적 contingency plan으로 대비하도록 하는 팀 기법은 무엇일까?
- PO: 기회 리스크를 제품 로드맵에 통합. “위협을 막는 것”보다 “기회를 자본화하는 것”이 PO 의사결정의 중심축.
- PM: 점수·루프·keep/revert 3요소로 리스크 관리를 과학화. 감에 의존하던 RBS를 “밤새 100번 실험”하는 에이전트 표준으로 전환.
- PL: 리스크 지표와 회귀 테스트의 결합. 기술 리스크는 측정 가능해야 관리 가능하고, 측정은 결정적(deterministic)이어야 재현 가능하다.
프롬프트 6줄 추가로 voice drift similarity를 0.22에서 0.79로 끌어올린 과정 — 그리고 PM/PL이 이 패턴에서 배워야 할 것
“아침에 일어나보니 실험이 100번 돌아 있었다”
솔직히 말하면, 처음엔 반신반의했습니다.
“AI한테 실험을 맡기고 자면, 아침에 결과가 나와 있다”는 말이 ML 엔지니어들 얘기처럼 들렸거든요. 저는 코드를 짜는 사람이 아니라, 15년간 삼성·LG·SK·KT 같은 대기업 PM 코칭을 해온 사람이니까요.
그런데 Andrej Karpathy가 2026년 3월 공개한 autoresearch를 보고 생각이 바뀌었습니다. 일주일 만에 GitHub 스타 3만 개. Shopify CEO Tobi Lütke가 이걸 써서 19% 성능 개선을 냈다는 소식. 하지만 제가 진짜 주목한 건 그 숫자가 아니었습니다.
주목한 건 패턴이었습니다.
“측정 가능한 단일 메트릭을 정의하고, 수정 범위를 한 파일로 격리하고, 자동화된 루프로 반복한다.”
이게 ML 학습 이야기처럼 들리시나요? 저는 달랐습니다. 이건 제가 15년간 PM 현장에서 반복해온 PDCA 사이클 그 자체였습니다.
Karpathy가 만든 것, 그리고 그 철학
Karpathy를 모르시는 분을 위해 간단히 소개하면, Stanford에서 박사를 받고 OpenAI 창립 멤버로 참여했으며, Tesla AI Director로 자율주행을 총괄한 사람입니다. 지금은 Eureka Labs를 창업해 AI 교육 민주화에 나서고 있고요.
그런데 그의 진짜 영향력은 직함이 아니라 철학에 있습니다.
2017년 그는 “Software 2.0” 에세이를 썼습니다. 요점은 이렇습니다. 기존 소프트웨어는 개발자가 한 줄씩 코드를 씁니다. Software 2.0에서는 데이터셋과 아키텍처가 소스 코드입니다. 그리고 이제 Software 3.0 — “가장 핫한 새 프로그래밍 언어는 영어다”라는 시대입니다.
autoresearch는 이 철학의 산물입니다. 630줄짜리 Python 스크립트 하나로, AI 에이전트에게 실험을 넘기고 아침에 결과를 확인합니다. 핵심 구조는 세 파일입니다.
prepare.py— 평가 하네스 (무엇을 측정할지)train.py— 에이전트가 수정하는 파일program.md— 전략 지시 (어떤 방향으로 개선할지)
“그래서 PM인 나랑 무슨 상관이지?” — 이 질문에 답하는 게 이 글의 목적입니다.
제 실험 무대: 15년 자산과 AI 출판 파이프라인
잠깐 배경을 설명할게요.
저는 2017년부터 125개 프로젝트(87개 고객사)를 거치며 1,650개 산출물, 739개 PM 지식 노트, 857개 블로그 아카이브를 쌓아왔습니다. 이 자산들을 Obsidian Vault로 이전하면서 ‘원소적 쪼갬(Atomic Decomposition)’을 적용했고, 8개 글로벌 표준 프레임워크(PMBOK, BABOK, SAFe 등) 114개 Knowledge Area에 매핑했습니다.
이 구조 위에서 운영하는 게 publishing-pipeline입니다. 소스 분석부터 PDF/ePub 퍼블리싱까지 10개 단계, 한국어·영어·일본어·중국어 4개 언어 동시 지원, 그리고 26종 품질 게이트. 1,608개 테스트 코드가 이 게이트들을 검증합니다.
이 파이프라인을 운영하면서 한 가지 질문이 생겼습니다.
“이 파이프라인의 프롬프트도 autoresearch로 최적화할 수 있지 않을까?”
autoresearch를 파이프라인에 매핑하기
19개 GitHub repo를 평가했습니다. autoresearch가 작동하려면 조건이 네 가지 필요합니다. 단일 메트릭, 고정 시간, 단일 수정 파일, 자동 평가. 이 네 가지를 모두 충족한 건 publishing-pipeline뿐이었습니다.
매핑은 이렇게 했습니다.
| autoresearch | publishing-pipeline |
|---|---|
prepare.py (평가 하네스) | quality_gate.py + token_reporter.py |
train.py (에이전트 수정) | prompts.toml (프롬프트 오버라이드) |
program.md (전략 지시) | 실험 전략 문서 |
| val_bpb (단일 메트릭) | pass_rate / cost (품질/비용 비율) |
베이스라인을 측정했습니다. Pass rate 100%(24/24 체크), 비용 $4.50, 메트릭 0.2306.
그리고 첫 번째 교훈을 바로 얻었습니다.
교훈 1: 최적화하기 전에 비용 구조부터 봐라
직관적으로 떠오른 첫 번째 가설은 “프롬프트를 짧게 만들면 비용이 줄고, 메트릭이 올라가겠지”였습니다.
분석해보니 현실은 달랐습니다.
Content tokens: 96,365 (96.3%) ← 고정값 (샘플 문서)
Prompt tokens: 3,663 (3.7%) ← 최적화 대상프롬프트를 50% 압축해도 절감액은 $0.08. 의미 없는 최적화였습니다.
PM 현장에서 자주 보는 패턴이죠. 효과 없는 곳에 에너지를 쏟는 것. 최적화할 곳이 아닌 곳을 최적화하는 건 시간 낭비입니다. 프로젝트 원가 관리의 기본 원칙과 정확히 같습니다. 전체 원가 구조를 먼저 파악하고, 임팩트 큰 항목부터 건드려야 합니다.
진짜 문제 발견: Voice Drift
LLM 체크 5종을 포함한 full mode를 돌리자 비로소 의미 있는 실패가 나타났습니다.
voice_drift_llm: similarity=0.22, verdict=SIGNIFICANT_DRIFT영어 학술 논문 28편을 소스로 한국어 백서를 생성했는데, 원문의 “학술적 목소리”가 원고에서 완전히 사라져 있었던 겁니다. Claude의 진단은 이랬습니다.
베이스라인은 정보 밀도 높은 영문 연구 초록체인 반면, 후보 원고는 수사적 질문·문학적 도입부·반복적 전환구로 채워진 한국어 교양서체로 전환되어, 레지스터·정보 밀도·문장 리듬 세 축 모두에서 뚜렷한 이탈이 관찰된다.
이게 진짜 최적화 대상이었습니다.
교훈 2: 평가 기준을 다듬어도 품질은 안 오른다
voice drift를 평가하는 시스템 프롬프트를 4번 바꿔봤습니다.
| 실험 | 주요 변경 | Similarity |
|---|---|---|
| Original | “Korean developmental editor” | 0.22 |
| Exp 1 | + 크로스 언어 transcreation 컨텍스트 | 0.38 |
| Exp 2 | + 5차원 가중 평가 프레임워크 | 0.18 (역효과!) |
| Exp 3 | + 크로스 언어 캘리브레이션 스케일 | 0.31 |
| Exp 4 | + “register-mapping에 관대하게 점수” | 0.38 |
흥미로운 패턴이 보입니다. 더 상세한 기준(Exp 2)은 오히려 역효과였습니다. Claude가 더 엄격하게 평가하게 된 것입니다.
0.38에서 막혔습니다. 결론은 명확했습니다. 평가 프롬프트가 아니라 콘텐츠 생성 로직 자체가 문제였습니다.
PM 현장과 정확히 같은 패턴입니다. QA 체크리스트를 아무리 정교하게 만들어도, 설계 단계의 문제는 QA로 고칠 수 없습니다. “무엇을 측정할지”와 “어디를 수정할지”를 구분하는 게 먼저입니다.
돌파구: chapter_writer에 제약 6종 추가
방향을 바꿔서 콘텐츠를 생성하는 chapter_writer.py의 프롬프트를 손댔습니다. 추가한 제약은 여섯 가지입니다.
- 수사적 질문 금지 (소스에 없는 경우)
- AI filler 전환구 금지 (“살펴보겠습니다”, “함께 알아보겠습니다” 등)
- 정보 밀도 유지 (기술 콘텐츠를 교양서 수준으로 희석하지 않기)
- 장면 묘사 방식 지정 (학술 장르에서는 직접 분석 도입 우선)
- Register 일관성 (해라체/합니다체 혼용 금지)
- Perspective 일치 (비인칭 객관 서술 유지)
결과는 이랬습니다.
| Round | Similarity | 핵심 변경 |
|---|---|---|
| R1 | 0.71 | 제약 1~3 추가 |
| R2 | 0.74 | 제약 4~6 추가 (target 0.72 돌파) |
| R3 | 0.61 | LLM 평가 편차 발생 |
| R4 | 0.79 | 상충 지시 해결 |
0.22 → 0.79. +259% 개선입니다.
교훈 3: 프로세스가 쌓이면 지시가 충돌한다
R2에서 0.74를 찍었는데 R3에서 0.61로 떨어졌습니다. 왜일까요?
chapter_writer 프롬프트 안에 서로 충돌하는 지시가 있었습니다.
기존: "Sensory description (required): 각 섹션 도입부에 감각 묘사 필수"
기존: "Scene description: 추상적 설명 대신 구체적 장면으로 시작"
신규: "문학적 장면 묘사로 섹션을 시작하지 마세요"
신규: "학술/기술 글에서 감각적 비유를 사용하지 마세요"자기계발서용으로 만든 “장면 묘사 필수” 지시가 학술 백서에서도 그대로 적용되고 있었던 겁니다. Claude는 양쪽 지시를 모두 따르려다 불안정한 출력을 만들었습니다.
해결은 장르 조건부 분리였습니다.
학술/기술 장르 → 직접 분석 도입
자기계발/에세이 장르 → 장면 묘사 유지이 한 줄의 변경이 R4의 0.79를 만들었습니다.
PM 현장에서도 똑같은 일이 일어납니다. “모든 산출물에 이해관계자 서명 필수”와 “3일 내 신속 승인”이 동시에 존재하는 상황. 프로세스가 쌓이면 충돌이 생깁니다. 자동화된 실험 루프가 아니었으면 이 충돌을 발견하기 어려웠을 겁니다.
PM/PL이 autoresearch에서 가져갈 수 있는 것
이 실험을 통해 확인한 건, autoresearch가 ML 전용 도구가 아니라는 점입니다. 패턴 세 가지를 정리하면 이렇습니다.
단일 메트릭을 정의하라. PM 현장의 고질적 문제는 “잘 되고 있는지 어떻게 알지?”입니다. “고객 만족도 향상”이 아니라 “NPS 40 → 55″로 정의하는 순간 PDCA가 작동하기 시작합니다. voice drift similarity라는 숫자 하나가 있었기에 8회 실험의 방향이 일관되었습니다.
AI가 생성하고 AI가 평가하고 사람이 방향을 잡는다. 가장 인상적인 건 Claude가 매 라운드마다 정확한 진단을 내렸다는 점입니다. “수사적 질문이 소스에 없는데 삽입되어 있다”, “해라체와 합니다체가 혼용되어 register 일관성이 깨졌다” — 이 진단이 없었으면 다음 방향을 잡을 수 없었습니다. PM/PL의 역할은 코드를 쓰는 게 아니라 “다음에 무엇을 시도할지” 판단하는 것입니다. autoresearch의 program.md가 바로 그 역할입니다.
Keep/Discard — 가장 정직한 의사결정. 개선되면 keep(git commit), 안 되면 discard(git revert). 감정도, 정치도, 매몰 비용도 없습니다. “이미 3개월 투자했으니 계속 가자”는 오류를 수없이 봤습니다. autoresearch의 keep/discard 프로토콜은 이 함정을 구조적으로 차단합니다.
다음 단계, 그리고 여러분의 파이프라인
남은 drift 네 가지(일부 절의 장면 묘사 잔존, 서문 register 혼용, 1인칭 주관 서술, 감각적 비유)는 추가 라운드로 해결 가능합니다.
하지만 더 큰 가능성은 이 패턴의 확장입니다. 다국어 품질 균등화, Lighthouse 성능 최적화, 커리큘럼 자동 생성 — 단일 메트릭과 자동화된 루프가 있다면 적용할 수 있습니다.
Karpathy가 보여준 건 630줄짜리 스크립트가 아닙니다. 측정하고, 격리하고, 반복하라는 원칙입니다. 그리고 이 원칙은 ML 학습에도, 콘텐츠 파이프라인에도, PM 현장의 지속적 개선에도 동일하게 적용됩니다.
여러분의 워크플로에 “단일 메트릭”과 “격리된 수정 파일” 하나씩 꺼낼 수 있다면, 오늘 밤 AI에게 실험을 맡겨보세요. 아침에 결과가 기다리고 있을 겁니다.
이 글의 모든 실험은 Claude Code + publishing-pipeline으로 수행되었습니다. 소스 코드와 실험 로그는 GitHub에서 확인하실 수 있습니다.
#autoresearch #ClaudeCode #AgenticPM #PublishingPipeline #VoiceDrift #AIPM #PM코칭시리즈 네트워크에서 이 편과 연결된 글
- K-1 · 사고 체계
Agentic 시대, PM의 온톨로지맵 — Obsidian을 통해 나만의 RAG를 만드는 법 - K-2 · 사고 체계
Karpathy의 LLM과 Obsidian 지식 결합 - K-4 · 사고 체계
Karpathy: AI의 사고 체계를 PM에 어떻게 적용할까? - K-5 · 사고 체계
Karpathy LLM OS 시각으로 본 AX PM/PL 역량 — Claude Code 소스의 교차 분석 - P-1 · AI 인물 탐구
PM 코치가 바라보는 AI 전문가 탐구 1편: Andrej Karpathy - A-4 · 실전 실험
AI 멀티 에이전트 개발 효과성 분석
- P-0 7인의 사고 체계 종합 프레임워크
- P-1 Karpathy: 제약 설계 + 닫힌 루프
- P-2 Sutskever: 압축이 곧 지능이다
- P-3 Hassabis: 제1원리 분해
- P-4 LeCun: 세계 모델 + 예측
- P-5 Hinton: 거버넌스 + 자기부정
- P-6 Ng: AI 전환 플레이북
- P-7 Fei-Fei Li: 인간중심 설계
- P-8 Builders 종합: Boris·Cat·Truell·Masad·Murati·Brockman
- P-9 Operators 종합: Altman·Amodei·Nadella·Pichai·Zuckerberg·Suleyman
- P-10 Hardware 양강: Jensen Huang · Lisa Su
- P-11 PO·PM·PL 역량 통합: 5-Domain × 3-Level