카파시 auto-research 실패사례: 따라 만들다 3일과 1,450줄을 버렸다

카파시 auto-research 실패사례 하나 남겨둔다. 그걸 따라 만든다고 3일을 쓰고, 결국 1,450줄을 통째로 버렸다.

블로그에 자동화 얘기를 여러 번 썼는데, 잘 된 것만 골라 쓴 셈이라 좀 찜찜했다. 이번엔 반대쪽. 3일 붙잡고 만든 걸 아카이브 폴더에 밀어넣고 슬래시 커맨드 하나를 지운 날의 기록이다. 코드가 안 돌아가서 버린 게 아니다. 잘 돌아갔다. 근데 잘 돌아가는 게 무슨 소용인가. 내가 만들라고 한 물건을 만들어줘야 써먹지, 딴 물건이면 아무리 멀쩡해도 쓸 데가 없다.

1. 이런 걸 만들었다니까 나도 시켜봤다

발단은 내 자료 창고였다. 텔레그램으로 흘려보낸 트윗들이 노트로 쌓이는데, 거기 "카파시가 자율 AI 연구자를 오픈소스로 풀었다"는 글이 몇 개 저장돼 있었다. 안드레 카파시(Andrej Karpathy)는 테슬라 AI 총괄과 오픈AI를 거친 사람이고, 이 바닥에서 그가 뭘 공개하면 대체로 화제가 된다.

읽어보니 물건 자체는 학습 코드 한 파일이었다. 카파시 본인 설명으로는 자기가 만든 소형 언어 모델 학습 코어를 GPU 한 장짜리 630줄 단일 파일로 깎아낸 것. 본론은 그 파일을 굴리는 방식이다.

에이전트가 그 학습 코드를 직접 고친다. 신경망 크기, 학습률, 구조, 뭐든 건드린다.
고친 걸로 작은 언어 모델을 딱 5분 학습시킨다.
처음 보는 글을 얼마나 잘 예측하는지 점수를 잰다. 점수가 낮아졌으면 남기고, 아니면 버린다.
남긴 설정만 git 브랜치에 커밋으로 쌓아가면서 다시 고친다. 이걸 밤새 반복한다. 시간당 12번, 하룻밤에 100번쯤.

핵심은 5분이라는 고정 시간이다. 뭘 바꾸든 조건이 같으니까 점수를 그냥 비교하면 된다. 끝이 안 보이는 연구를 점수판 있는 게임으로 바꿔놓은 셈이다. 그리고 사람은 그 학습 코드를 아예 안 건드린다. 대신 "연구를 어떻게 할지" 적어둔 마크다운 파일 하나를 손본다. 사람은 프롬프트를, 에이전트는 학습 코드를 각자 반복 개선하는 분업이고, 소개 글에서는 이걸 프로그래머를 프로그래밍하는 일이라고 표현했다.

한마디로 점수를 재면서 자기 자신을 계속 고쳐나가는 루프다. 이걸 보고 나도 내 리서치를 이런 식으로 돌려보고 싶었다. 그래서 시스템 로드맵에 다음 사이클로 적어뒀다. 이름만 적은 게 아니고 "자가개선 루프, 한 달에 한 번 돌려서 자료를 읽고 실험해서 스킬을 업그레이드한다"까지 써놨고, 근거로 삼을 수집 노트 4건 번호와 참조할 이전 설계 문서 위치도 같이 달아뒀다.

그리고 클로드코드를 켜서 그 항목을 던졌다. 설계 결론은 한 시간도 안 돼 나왔다. 내 노트 창고를 뒤져서 주제별 보고서를 자동으로 뽑아주는 생성기. 그럴듯했고, 세부 결정 8건 승인 요청이 올라와서 전부 OK를 눌렀다.

문제는 그 8건이 전부 "어떻게 만들까"였다는 거다. 무슨 색으로 칠할지만 여덟 번 물어보고 정작 "이게 로드맵에 적힌 그거 맞아?"는 한 번도 안 올라왔다. 정의도, 근거 노트 번호도, 참조 문서 위치도 내가 다 적어놨는데 클로드코드는 그중 한 건도 열지 않았다. 이름만 보고 뜻을 지어낸 설계가 그대로 결론이 돼서 올라온 거다.

2. 3일 동안 쌓인 것들

그다음은 익숙한 풍경이다. 밤새 돌려놓고, 아침에 보고 받고, 또 시켰다. 3일 치 산출물을 세보면 이렇다.

메인 스크립트 656줄
기존 지식 그래프 도구 확장 168줄
슬래시 커맨드 1개 신설
설계·단계별 보고서 5종
실제로 돌려본 주제 사이클 4건

코드와 문서를 다 합쳐 1,450줄쯤 된다. 실제로 돌아가는 코드는 이 중 824줄이고 나머지는 커맨드 정의와 보고서다. 게다가 중간중간 올라오는 자평이 아주 좋았다. 격리 테스트 통과, 신호 대 잡음비 8배 개선, 단계별 보강 4종 완료. 숫자가 다 예쁘게 나오니까 잘 가고 있다고 믿었다.

지금 보면 저 지표들이 전부 기계 쪽 숫자다. 코드가 안 터졌다, 처리량이 늘었다, 줄 수가 늘었다. 내가 그 결과물로 뭘 하는지는 저 목록 어디에도 없었다. AI 모델 비교하면서 채점 기준만 세 번 고쳐 쓴 얘기를 따로 쓴 적 있는데, 그때 배운 게 "무엇을 재느냐가 실력보다 중요하다"였다. 정작 이 사이클에선 재기 쉬운 것만 재고 있었네.

▲ 3일간 만든 1450줄 중 168줄만 인프라로 남았음을 보여주는 비교 카드 (자체 제작 이미지)

3. "그래서 이거 어디다 쓰지?"

다 만들었다니까 직접 돌려봤다. 주제 하나 넣으니 130줄짜리 보고서가 나왔다. 형식도 멀쩡하고 문장도 매끄러웠다.

근데 읽고 나서 할 게 없었다. 이걸 어디 붙이지? 예전에 몇 달 걸려 쓴 보고서들이랑 나란히 놓아보니 깊이가 아예 다른 물건이더라. 그 자리에서 딱 두 마디 했다. "이거 어디 갖다 쓸 수 있는데?" 그리고 "예전 그거 수준은 아니잖아."

그게 3일 만에 처음 나온 정직한 신호였다. 그전까지 신호가 없었던 게 아니라, 신호를 받을 자리가 없었던 거다. 만들고 나서 "이거 쓸 만한가"를 확인하는 절차가 내 작업 흐름에 아예 빠져 있었으니까.

4. 원문 읽고 한 거 맞냐고 물었다

결과물이 내가 기대한 것과 너무 다르니까 그때 물어봤다. 이거 원문 읽고 만든 거 맞냐고.

안 읽었다는 답이 나왔다. 저장해둔 트윗도, 로드맵이 가리킨 이전 설계 문서도, 근거로 달아둔 노트 4건도 하나도 안 열린 상태였다. 그러고 나서 다 읽고 올라온 보고를 원래 하려던 것과 나란히 놓아봤다.

내가 원한 건 점수를 재면서 자기를 고쳐나가는 루프였다. 3일 동안 나온 실제 결과물은 자료를 모아 글을 뽑아주는 단발 생성기였다. 점수가 없고, 반복이 없고, 자기를 고치는 부분이 없다. 이름만 같지 하는 일이 겹치는 데가 한 군데도 없었다.

답이 내 로드맵 안에 적혀 있었는데 그 문서를 3일 뒤에 열었다는 게 제일 뼈아팠다.

▲ 점수 기반 반복 루프와 단발 보고서 생성기의 구조 차이 비교 (자체 제작 이미지)

5. 왜 원문을 안 열고 3일을 갔나

3일 버린 건 결과고, 착수 시점에 원문이 왜 안 열렸는지가 원인이다. 따져보니 다섯 가지가 걸렸다.

(1) 원문 정독을 강제하는 자리가 없었다. 이게 제일 크다. 참조 문서 위치와 근거 노트 4건이 로드맵에 다 있었는데 클로드코드는 한 건도 열지 않고 설계 결론까지 갔다. 왜 안 열었을까 생각해보면, "auto-research"라는 이름 자체가 이미 뜻이 통하는 말처럼 보였기 때문인 것 같다. 자율 연구라는 뜻이 글자에 박혀 있으니 확인할 게 없어 보이고, 유명한 사람 이름이 붙어 있으면 더 그렇다. 그래서 확인 단계를 건너뛰고 곧바로 "이걸로 뭘 만들까"로 넘어간 거다. 열어보게 만드는 장치가 없으면 안 읽고도 그냥 진행이 된다.

(2) 물어온 게 전부 각론이었다. 승인 요청 8건이 죄다 구현 디테일이었다. "이 방향이 로드맵과 원본에 맞나" 같은 질문은 0건. 계획부터 세우게 하는 습관은 지시법 정리한 글에서 이미 썼는데, 계획을 세워도 전제가 틀리면 그 위로 정교하게 쌓일 뿐이더라.

(3) 중간에 올라오는 걸 내가 꼼꼼히 안 봤다. 여기는 내 몫이다. 승인 8건을 하나하나 따져보지 않고 쭉 눌렀고, 매일 아침 올라오는 보고도 결론만 훑고 넘겼다. "이게 그 항목 맞냐"고 되물을 자리가 승인창마다 있었는데 그 자리를 안 썼다. 방향을 확인할 마지막 관문이 나였는데 그냥 통과시킨 셈이다.

(4) 기계 지표로 만족했다. 격리 통과, 처리 효율, 줄 수. 사람 쪽 지표가 하나도 없는데 예쁜 숫자가 매일 나오니까 진도가 나간다고 착각했다.

(5) 다 만든 뒤에 확인하는 자리가 없었다. 코드가 의도대로 도는지 점검하는 절차는 이미 있었다. 결과물이 나한테 쓸모 있는지 보는 절차는 없었다. 그게 있었으면 첫날에 걸렸을 일이다. 이틀 가까이 아꼈다는 뜻이고, 그 이틀에 얹힌 추가 작업도 안 생겼을 거다.

6. 그래서 만든 확인 절차 두 개

폐기하고 끝냈으면 다음에 똑같이 했을 거다. 그래서 커맨드 두 개를 새로 만들었다. 거창한 코드는 아니고 각각 백 줄 안팎짜리 체크리스트인데, 특정 상황에서 자동으로 불려나오게 걸어뒀다.

앞쪽 게이트는 새 설계 문서를 쓰기 직전에 돈다. 네 가지를 확인하고, 하나라도 못 채우면 문서 작성 자체를 막는다.

인용한 원본 자료를 실제로 읽었나 (읽은 흔적이 없으면 먼저 읽게 한다)
내 의도를 되물었나
이 결과물을 어디에 쓸지 내가 직접 답했나
예전에 제대로 나온 산출물이랑 형식과 깊이를 비교했나

첫 항목이 이번 일에 정면으로 대는 자리다. 읽은 흔적이 없으면 다음으로 못 넘어간다.

뒤쪽 게이트는 새 도구나 커맨드를 만든 직후에 돈다. 실제 시나리오로 몇 번 직접 돌려보고, 그 결과를 나한테 들이밀면서 "이거 쓸 만한가" 묻게 했다. 여기서 통과라는 건 완성이 아니라 "일단 써보자" 정도다. 아니라고 하면 어디가 부족한지 내가 짚고 다시 돌아간다.

효과는 아직 조심스럽게 본다. 이 두 개가 진짜 값을 하려면 앞으로도 계속 걸려야 하는데, 지금까지는 다행히 몇 번 잡아줬다. 만들어놓은 자동화를 점검하는 자동화가 따로 필요하더라는 얘기를 따로 쓴 것도 결국 이 일에서 시작된 흐름이다.

▲ 착수 전 게이트와 산출 후 게이트가 사이클의 앞뒤에 붙은 구조도 (자체 제작 이미지)

7. 정리, 1,450줄 중 살아남은 168줄

버린 걸 정확히 적어두는 게 이 글의 목적이라 마지막까지 세본다. 메인 스크립트 656줄은 아카이브로 갔고, 커맨드는 지웠고, 보고서 5종과 돌려본 사이클 4건도 같이 넣었다. 살아남은 건 지식 그래프 도구를 확장한 168줄뿐이다. 그건 auto-research랑 상관없이 원래 쓰던 인프라라서 남겼다. 남은 비율로 따지면 11퍼센트쯤 되나.

혹시 비슷한 자리에 있는 사람한테 도움이 될까 싶어 줄여두면, 결국 착수 전에 원문 한 번 열어보는 것과 만든 다음에 한 번 직접 써보는 것, 그 두 가지가 3일치 비용보다 훨씬 싸다는 얘기다. 유명한 사람이 공개한 걸 따라 만들 때 특히 그렇다. 이름이 그럴듯할수록 안 읽고 넘어가기 쉽더라. AI한테 시키면 착수 비용이 워낙 싸니까 확인 없이 그냥 출발하게 되는 것도 한몫하고. 싸게 시작한 만큼 싸게 끝나면 좋겠는데, 3일은 안 싸다.

돈 나가는 쪽으로도 손해였다. 3일 내내 굴렸으니.

3줄 요약 - 카파시 auto-research 같은 걸 나도 돌려보려다 3일, 코드와 문서 1,450줄을 버렸다. 내가 원한 건 점수를 재면서 자기를 고치는 반복 루프였는데, 실제 결과물은 보고서 생성기였다. - 로드맵에 정의와 근거 노트까지 적어놨는데 착수 시점에 원문이 한 건도 열리지 않았다. 내 몫은 중간 승인과 보고를 꼼꼼히 안 보고 쭉 통과시킨 것이다. - 착수 직전 4가지 확인과 산출 직후 직접 사용 확인, 이 두 게이트를 자동으로 걸어뒀다.

이 글은 개인 작업 기록이자 정보 제공이 목적이고, 작성 시점(2026년 8월) 기준이다. 인용한 카파시 auto-research 관련 수치와 설명은 공개된 소개 글에 근거했으며 원본 구현은 계속 바뀔 수 있다. 여기 적은 확인 절차는 내 작업 환경에 맞춰 만든 것이라 그대로 쓰면 안 맞을 수 있고, 특정 도구나 방식을 권유하거나 결과를 보장하지 않는다.

참고한 공식 자료 - 카파시 auto-research 공개 원문(X): x.com/karpathy/status/2030371219518931079 - 작동 방식 소개(X): x.com/i/status/2030376700337643742 - 클로드코드 개요·기본 사용: code.claude.com/docs - 클로드코드 설치·설정: code.claude.com/docs/setup