Karpathy의 "Autoresearch"가 화제가 된 이유 — 소프트웨어 엔지니어가 업무에 이 패턴을 실제로 활용하는 방법

잠시 신경망 (neural networks)은 잊어버리세요. 이 저장소 (repo)의 핵심 아이디어는 AI 에이전트가 밤새도록 무인으로 작동하게 만드는 청사진이며, 이는 여러분의 팀이 이미 겪고 있는 문제들과 맞닿아 있습니다.

이번 주 테크 트위터 (tech Twitter)나 링크드인 (LinkedIn) 근처에 있었다면, 전 Tesla AI 디렉터이자 OpenAI 창립 멤버인 Andrej Karpathy가 공개한 autoresearch라는 작은 GitHub 저장소 (repo) 때문에 사람들이 열광하는 모습을 보았을 것입니다.

그 프레임워크는 극적입니다. 당신이 잠든 사이, AI 에이전트가 스스로 머신러닝 (machine learning) 실험을 수행한다는 것입니다. 코드를 수정하고, 5분 동안 학습시키고, 성능이 좋아졌는지 확인하고, 유지할지 버릴지 결정한 뒤, 이를 반복합니다. 아침에 일어나면 수백 개의 실험 로그와 조용히 스스로를 개선한 모델을 마주하게 됩니다.

만약 당신이 ML 연구원이 아니라면, 그냥 지나치고 싶을 수도 있습니다. "멋지긴 한데, 난 신경망 (neural networks)을 학습시키지 않아. 이게 나랑 무슨 상관이지?"

중요한 점은 — 신경망 (neural network) 부분은 거의 부수적인 것이라는 사실입니다. Karpathy가 실제로 오픈 소스 (open-source)로 공개한 것은 AI 에이전트 작업을 구조화하기 위한 하나의 **패턴 (pattern)**입니다. 즉, 인간과 AI 사이의 책임을 나누는 특정한 방식이며, 이는 매우 광범위한 엔지니어링 문제에 일반화될 수 있습니다. 일단 이 패턴을 이해하고 나면, 여러분의 업무 중 어디에 적용할 수 있는지 눈에 보이기 시작할 것입니다.

이 저장소 (repo)에 실제로 들어있는 것

저장소 (repo) 자체는 의도적으로 매우 작으며 — 그것이 핵심입니다. 실제로 중요한 파일은 단 세 개뿐입니다:

평가기 (evaluator, 수정 불가). 고정된 상수 (constants), 데이터 준비 (data preparation), 그리고 점수 산정 로직 (scoring logic)을 포함하는 파일입니다. 에이전트는 이 파일을 절대 수정할 수 없습니다. 이는 다른 모든 것을 측정하는 척도 역할을 합니다.

구현부 (implementation, 에이전트의 놀이터). 실제 모델, 학습 루프 (training loop), 그리고 하이퍼파라미터 (hyperparameters)를 포함하는 단일 파일입니다. 에이전트가 변경할 수 있는 유일한 파일입니다. 아키텍처 (architecture), 배치 크기 (batch size), 옵티마이저 (optimizer) — 이 모든 것이 대상입니다.

지침 (instructions) (인간의 유일한 작업). 에이전트가 무엇을 시도해야 하는지, 제약 조건(constraints)은 무엇인지, 결과를 어떻게 해석해야 하는지, 그리고 무언가 고장 났을 때 어떻게 해야 하는지를 설명하는 평범한 마크다운 (Markdown) 파일입니다. Karpathy는 이를 "마크다운으로 연구 조직을 프로그래밍하는 것"이라고 부릅니다.

루프 (loop) 자체는 당황스러울 정도로 단순합니다. 에이전트는 지침을 읽고, 가설 (hypothesis)을 세우고, 구현 파일 (implementation file)을 수정하고, 정해진 시간 제한이 있는 실험 (time-boxed experiment, 정확히 5분)을 실행하고, 단 하나의 수치를 확인한 뒤 — 변경 사항을 유지할지 아니면 git으로 되돌릴지(revert) 결정합니다. 그런 다음 이를 다시 반복합니다. 시간당 대략 12번, 밤새도록 약 100번 정도 수행합니다.

놓치기 쉽지만 매우 중요한 세부 사항이 하나 있습니다. 지침에 내재된 철학은 _성능을 유지하면서 코드를 삭제하는 것_을 승리로 명시적으로 간주하며, 복잡성을 더하는 아주 작은 개선 사항은 유지할 가치가 없는 것으로 취급한다는 점입니다. 이는 인간이 한 번 인코딩(encoded)한 가치 판단이며, 이제 에이전트는 실행되는 동안 매 사이클마다 이를 자율적으로 적용합니다.

패턴 뒤에 숨겨진 패턴

머신러닝 (machine learning) 맥락을 걷어내면, 남는 것은 다음과 같습니다:

평가자 (Evaluator) (고정됨, 자동화됨, 신뢰할 수 있음) + 구현 (Implementation) (개선 대상) + 방향 (Direction) (인간이 작성한 의도와 제약 조건) = AI 에이전트가 관리자 없이 실행할 수 있으며, 도움이 되지 않으면 되돌리는 내장된 안전 장치를 갖춘 루프

이것은 소프트웨어 팀에 이미 존재하는 수많은 문제의 정확한 형태입니다. 단지 우리가 보통 이런 방식으로 프레임화(frame)하지 않을 뿐입니다. 객관적으로 측정할 수 있는 무언가가 있고, 변경할 수 있는 무언가가 있으며, 무엇이 "더 나은지"에 대한 명확한 감각이 있는 곳이라면 어디든 이 패턴이 적용됩니다.

이것이 나타내는 가장 큰 변화는 기술적인 것이 아닙니다. 그것은 바로 당신의 노력이 어디에 투입되는가에 관한 것입니다. 기존 모델에서는 구현(implementation)을 수정하는 데 시간을 보냈습니다. 즉, 코드를 작성하고, 설정을 조정하고, 다음 아이디어를 직접 시도하는 방식입니다. 이 모델에서는 지침(instructions) — 즉, 평가기(evaluator)와 방향 파일(direction file) — 을 작성하고 다듬는 데 시간을 보냅니다. 에이전트(agent)가 구현 반복(implementation iterations)을 빠르게 수행합니다. 당신은 무엇이 "좋은지"를 정의하고, 양(volume)이 그 작업을 수행하도록 맡깁니다.

Karpathy는 이를 위해 "프로그래머를 프로그래밍하기 (programming the programmer)"라는 표현을 사용합니다. 당신은 더 이상 훈련 스크립트(training script)를 직접 작성하는 것이 아닙니다. 당신은 그것을 작성하는 무언가를 작성하고 있으며, 당신이 손으로 직접 하는 것보다 훨씬 더 빠르고 반복적으로 수행합니다.

실제 업무에서 이 패턴을 적용하는 6가지 방법

1. 성능 최적화 루프 (Performance Optimization Loops)

만약 당신에게 "아마 더 빨라질 수 있을 것 같은데" 아무도 파고들 시간이 없는 느린 함수, 쿼리, 또는 API 엔드포인트가 있다면 — 이것이 가장 깔끔하게 들어맞는 사례입니다.

평가기 (The evaluator): 현실적인 입력값으로 함수를 실행하고 지연 시간(latency), 처리량(throughput), 메모리 등의 수치를 보고하는 벤치마크 스크립트(benchmark script).

구현 (The implementation): 함수 또는 모듈 자체.

방향 파일 (The direction file)의 예시:

당신의 목표는 공개 인터페이스(public interface)를 변경하거나 기존 테스트를 깨뜨리지 않으면서 배치 처리(batch processing) 함수의 p95 지연 시간(p95 latency)을 줄이는 것입니다. 매 변경 사항 이후에 벤치마크를 실행하세요. 지연 시간이 개선되고 모든 테스트를 통과하면 변경 사항을 커밋(commit)하세요. 그렇지 않으면 되돌리세요(revert). 더 단순한 구현을 선호하세요. 만약 두 버전의 성능이 비슷하다면, 코드 양이 더 적은 것을 유지하세요. 15번의 시도 후 또는 3회 연속으로 개선율이 1% 미만인 경우 중단하세요.

이 과정을 중요도가 낮은 서비스에 실행시켜 두고, 한 시간 뒤에 돌아와서 최종 코드뿐만 아니라 차이점(diff)과 실험 로그(experiment log)를 검토하십시오.

2. 불안정한 테스트(Flaky Tests) 추적하기

모든 팀에는 20번 중 1번꼴로 실패하지만 아무도 고칠 시간을 내지 못한 그런 테스트가 하나씩 있습니다. 이것은 "50번 실행해보고 확인해봐"라고 말할 수 있는 완벽한 문제입니다.

평가자 (The evaluator): 불안정한 (flaky) 테스트를 반복해서 실행하고 (예: 30회), 통과율 (pass rate)을 보고합니다.

구현체 (The implementation): 테스트 파일과 해당 테스트가 검증하는 코드.

지시 파일 (The direction file)의 내용 예시:

이 테스트는 간헐적으로 실패합니다. 왜 그런지에 대한 가설(경쟁 상태 (race condition), 타이밍 가정 (timing assumption), 공유 상태 (shared state) 또는 기타 원인)을 세우고, 타겟팅된 수정 (targeted fix)을 수행한 뒤, 테스트 스위트 (test suite)를 30회 실행하세요. 만약 통과율이 개선되고 다른 테스트의 퇴보 (regression)가 없다면 변경 사항을 유지하세요. 그렇지 않다면, 이전 상태로 되돌리고 (revert) 다른 가설을 시도하세요. 나중에 사람이 조사 내용을 검토할 수 있도록, 실패한 시도를 포함하여 각 시도에 대한 추론 과정을 기록하세요.

에이전트가 문제를 완전히 해결하지 못하더라도, 시도했다가 배제한 가설들의 기록은 당신이 처음부터 직접 시작하는 것보다 훨씬 더 가치 있는 경우가 많습니다.

3. 안전망 아래에서의 리팩터링 (Refactoring Under a Safety Net)

"이 모듈은 정리가 필요해"라는 문장은 모든 엔지니어가 말해왔지만, 거의 누구도 실행할 시간이 없는 문장입니다. Autoresearch 패턴은 기존의 테스트 스위트를 평가자로 변환합니다.

평가자 (The evaluator): 항상 통과 (green) 상태를 유지해야 하는 기존 테스트 스위트와 코드 라인 수 (lines of code) 또는 순환 복잡도 (cyclomatic complexity)와 같은 복잡도 지표 (complexity metric).

구현체 (The implementation): 리팩터링 대상이 되는 모듈.

지시 파일 (The direction file)의 내용 예시:

모든 테스트를 통과하는 상태를 유지하면서 이 모듈의 복잡도를 줄이세요. 코드를 추가하는 것보다 삭제하는 것을 선호하세요. 20줄을 삭제하면서 테스트를 통과 상태로 유지하는 변경이 새로운 추상화 (abstraction)를 추가하는 변경보다 더 가치 있습니다. 각 변경 후에는 전체 테스트 스위트를 실행하세요. 만약 무언가 깨진다면 즉시 되돌리세요 (revert). 10번의 시도 후 또는 테스트를 깨뜨리지 않으면서 더 이상의 단순화 (simplification)를 찾을 수 없을 때 중단하세요.

이는 Karpathy의 "삭제가 승리다 (deletion is a win)"라는 철학을 직접적으로 차용한 것입니다. 대부분의 엔지니어링 팀은 이 철학을 지지한다고 말하지만, 체계적으로 강제하는 경우는 드뭅니다.

4. 비용 또는 지연 시간 지표에 따른 설정 튜닝 (Tuning Configuration Against a Cost or Latency Metric)

스레드 풀 (thread pool) 크기, 캐시 TTL (cache TTLs), 재시도 및 백오프 (retry and backoff) 설정, 커넥션 풀 (connection pool) 제한, 백그라운드 작업의 배치 크기 (batch sizes) — 대부분의 팀은 이를 추측에 기반하여 한 번 설정한 뒤 다시 검토하지 않습니다.

평가자 (The evaluator): 고정되고 반복 가능한 부하(load) 하에서 목표 지표 — 요청당 비용 (cost per request), p99 지연 시간 (p99 latency), 에러율 (error rate) — 를 보고하는 부하 테스트 (load-testing) 스크립트.

구현체 (The implementation): 설정 파일 (configuration file).

지시 파일 (The direction file)의 내용은 다음과 같을 수 있습니다:

당신의 목표는 p99 지연 시간을 400ms 이상으로 높이거나 에러율을 0.1% 이상으로 높이지 않으면서 요청당 평균 비용을 최소화하는 것입니다. 한 번에 하나의 설정 값만 변경하세요. 각 변경 사항 이후에 부하 테스트를 실행하세요. 제약 조건을 위반하지 않으면서 비용을 개선하는 변경 사항은 유지하고, 그 외의 모든 것은 되돌리세요 (revert). 중단하기 전에 최소 20개의 설정을 시도하세요.

이것은 원본 리포지토리(repo)와 가장 유사한 형태입니다 — 고정된 시간 예산, 단일 지표, 수많은 작은 실험들, 그리고 git 기반의 유지(keep) 또는 되돌리기(revert) 방식입니다.

5. AI 기능을 위한 프롬프트 및 평가 반복 (Prompt and Eval Iteration)

만약 당신의 제품에 AI 기반 기능이 있다면 — 그리고 점점 더 많은 제품이 그러해지고 있다면 — 이것은 이 패턴 전체를 적용할 수 있는 아마도 가장 자연스러운 사례일 것입니다. 왜냐하면 거의 일대일로 매칭되기 때문입니다.

평가자 (The evaluator): 정확한 일치 (exact match), 유사도 점수 (similarity score), 또는 루브릭 기반의 판정사 (rubric-based judge)를 통해 자동으로 점수가 매겨지는, 검증된 기대 출력값이 포함된 고정된 입력 평가 세트 (evaluation set).

구현체 (The implementation): 당신의 프롬프트 템플릿 (prompt template), 시스템 지침 (system instructions), 또는 퓨샷 예시 (few-shot examples).

지시 파일 (The direction file)의 내용은 다음과 같을 수 있습니다:

당신의 목표는 평균 토큰 사용량을 10% 이상 늘리지 않으면서 평가 세트의 정확도 점수를 높이는 것입니다. 프롬프트 템플릿, 지침, 그리고 예시를 수정할 수 있지만, 평가 세트 자체는 수정할 수 없습니다. 매 변경 시마다 평가를 실행하세요. 개선 사항은 유지하고, 퇴보(regression)는 되돌리세요. 점수가 동일할 경우 더 짧은 프롬프트를 선호하세요.

이것은 말 그대로 동일한 세 가지 파일의 계약입니다 — 건드려서는 안 될 평가자로서의 평가 세트, 구현체로서의 프롬프트, 그리고 지시 파일로서의 지침입니다.

6. 빌드 및 CI 파이프라인 최적화

느린 CI 파이프라인은 모든 팀이 매일 지불하는 세금과 같으며, "누군가 빌드가 왜 18분이나 걸리는지 정말로 살펴봐야 한다"는 말은 우선순위가 결코 정해지지 않는 만성적인 백로그 (backlog) 항목입니다.

평가자 (The evaluator): 파이프라인에 의해 자동으로 보고되는 총 CI 실행 시간 (Total CI run time).

구현 (The implementation): 귀하의 CI 설정 (CI configuration), 캐싱 전략 (caching strategy), 그리고 병렬화 설정 (parallelization setup).

지시 파일 (The direction file)의 내용 예시:

귀하의 목표는 파이프라인을 정상(green) 상태로 유지하고 테스트 커버리지 (test coverage)를 제거하지 않으면서, 총 CI 실행 시간을 줄이는 것입니다. 캐싱 전략, 병렬화, 그리고 의존성 최적화 (dependency optimization)를 한 번에 하나씩 시도하십시오. 각 변경 사항 이후에는 전체 파이프라인을 실행하십시오. 개선 사항은 유지하고, 파이프라인이 실패하거나 커버리지가 떨어지면 되돌리십시오 (revert). 최소 10가지의 서로 다른 접근 방식을 시도하십시오.

이를 안전하게 만드는 가드레일 (Guardrails) — 그리고 실패하는 지점

원래의 설정이 작동하는 이유는 범위 (scope)가 매우 좁기 때문입니다. 하나의 파일만 변경될 수 있고, 하나의 머신에만 영향을 미치며, 하나의 지표가 성공 여부를 결정하고, 모든 변경 사항은 git을 통해 커밋되거나 즉시 되돌려집니다. 에이전트가 수행하는 그 어떤 것도 되돌릴 수 없는 것이 없으며, 샌드박스 (sandboxed) 환경 외부의 어떤 것에도 영향을 미치지 않습니다.

범위를 넓히는 순간, 계산 방식이 달라집니다. 따라서 업무에 이 패턴을 적용할 때는 다음과 같은 타협할 수 없는 원칙들을 준수하십시오:

• 항상 브랜치 (branch)에서 실행하고, 절대 메인 (main) 브랜치에서 실행하지 마십시오. Git revert는 귀하의 유일한 안전망입니다.
• 항상 격리된 환경 (isolated environment)에서 실행하십시오. 로컬 머신, 샌드박스, 또는 일회용 컨테이너 (disposable container)를 사용해야 하며, 절대 공유 인프라를 사용해서는 안 됩니다.
• 평가자 (evaluator)를 진정으로 건드릴 수 없게 만드십시오. 만약 에이전트가 자신의 작업 점수를 매기는 요소를 직접 수정할 수 있다면, 루프 (loop)는 무의미해집니다.
• 시도 횟수에 엄격한 상한선을 두십시오. "수익 체감 (diminishing returns)이 발생할 때까지 실행하라"는 말에는 명시적인 숫자가 붙어야 합니다.
• 최종 디프 (diff)뿐만 아니라 로그 (log)를 검토하십시오. 실패한 가설을 포함하여 시도된 가설의 순서는 종종 가장 유용한 결과물 (artifact)이 됩니다.

이러한 경계 내에서 사용된다면, 이것은 무모한 자동화가 아닙니다. 이는 명확한 평가 기준 (rubric)을 가진 매우 철저하고 인내심 있는 주니어 엔지니어를 세팅해 두고 몇 시간 동안 자리를 비우는 것에 더 가깝습니다.

이번 주에 이를 시도하는 방법

이 패턴을 테스트하기 위해 GPU나 연구 예산이 필요하지는 않습니다. 위 아이디어 중 가장 규모가 작고 리스크가 낮은 버전을 선택하세요. 브랜치(branch) 상에 있거나, 샌드박스(sandbox) 환경에 있거나, 이미 신뢰할 수 있는 테스트 스위트(test suite) 또는 벤치마크(benchmark)가 있는 것이라면 무엇이든 좋습니다.

좋은 시작점은 다음과 같습니다: 기존 유닛 테스트(unit test)가 있는 함수를 하나 가져와서, 목표와 제약 조건을 설명하는 짧은 지시 파일(direction file)을 작성합니다. 그리고 코딩 에이전트(coding agent)를 해당 함수로 지정한 뒤, 몇 차례의 반복(iterations)을 수행하도록 요청하세요. 에이전트는 진행 과정에서 개선 사항을 커밋(commit)하고 퇴보(regression)가 발생하면 되돌려야(revert) 합니다.

그다음 실제로 중요한 부분을 수행하세요: 에이전트가 시도한 로그를 읽는 것입니다. 최종 코드가 아니라, 추론의 흔적(reasoning trail)을 읽으세요. 이 패턴이 당신의 워크플로(workflow)에 영구적으로 자리 잡을 가치가 있는지 여부는 바로 그곳에서 확인할 수 있습니다.

원문으로 바로 가고 싶으신가요? 오리지널 리포지토리(repo)는 여기 있습니다: github.com/karpathy/autoresearch

AI for Everyone 시리즈의 일부 — 엔지니어와 전문가를 위한 실용적인 AI 가이드입니다. 더 많은 정보를 원하시면 팔로우하세요.