운영중인 시스템은 누가 더 나아졌다고 판단할 수 있을까요? 담당자가 바뀌면 같은 에러도 다른 분석이 나오는 문제는 어떻게 해결할까요?
최근 안드레 카파시가 공개한 Auto Research를 보면서, 최근 업무에서 비슷한 질문을 풀었던 경험이 떠올랐습니다.
Auto Research가 하는 일
Auto Research는 안드레 카파시가 공개한 오픈소스 프로젝트입니다. AI 에이전트가 사람 없이도 스스로 모델을 개선하도록 만든 자동 실험 루프입니다.
동작 방식은 이렇습니다.
- 개발자가 퇴근 전에 에이전트에게 지시를 내려둡니다
- 에이전트는 `train.py` 파일 하나만 수정할 수 있습니다
- 수정한 코드로 정확히 5분 동안 모델을 학습시킵니다
- 학습이 끝나면 `val_bpb`(validation bits per byte)라는 지표로 결과를 판정합니다
- 이전보다 수치가 낮아졌으면 변경 사항을 남기고, 아니면 그대로 버립니다
- 이 사이클이 밤새 반복됩니다. 시간당 12번, 하룻밤이면 100번 가까이 돌아갑니다
규칙은 세 가지입니다. 수정 가능한 파일을 하나로 제한한다. 실험 시간은 5분으로 고정한다. PyTorch 외에 의존성을 거의 두지 않는다. 이 제약이 루프를 밤새 흔들림 없이 반복시키는 힘입니다.
이 프로젝트에서 배울 점
Auto Research에서 중요한 건 "AI가 코드를 알아서 짠다"가 아닙니다. 진짜 핵심은 두 가지입니다.
1. val_bpb라는 정량적 기준점을 하나 정했다는 것. 원래 연구자가 "이번 실험이 저번보다 나은가"를 머릿속으로 판단하던 걸, 어휘 사전 크기와 무관하게 공정 비교가 가능한 숫자 하나로 바꿨습니다.
2. 정량적 기준점을 축으로, 후퇴하지 않는 루프를 만들었다는 것. 좋아지면 남기고 나빠지면 버린다. 이 단순한 규칙 하나로, 사람이 매번 붙어서 판단하지 않아도 시스템이 계속 나은 방향으로만 굴러갑니다.
업무에서 만든 것: 에러 발생률과 에스컬레이션 루프
최근 구축된 지 얼마 안 된 시스템을 맡아 안정화하는 업무를 했습니다. 초반에는 에러가 날 때마다 로그를 보고 원인을 파악하고 고칠지 말지를 판단하는 일이 전부 사람의 감과 경험에 달려 있었습니다. 판단 기준이 사람마다 달라서, 누가 대응하느냐에 따라 속도도 품질도 매번 달랐습니다.
그래서 이 판단 과정을 명시적인 기준점과 루프로 옮겼습니다.
- 정량적 기준점: 시스템의 에러 발생률. 같은 에러가 더는 반복되지 않고 줄어드는지를 이 숫자 하나로 판단합니다
- 1차 자동 분석: 에러 로그가 발생하면 AI가 자동으로 감지하고 1차 분석을 수행합니다
- 2차 인간 판단: 사람이 로컬에서 클로드 코드로 이 분석 결과를 재검토하고, 상세 분석과 수정으로 에스컬레이션할지를 판단합니다
- 분석 절차 자체의 표준화: 이 2차 분석을 사람마다 다르게 하지 않도록, 클로드 코드 Skill을 만들어 분석 절차와 판단 기준을 고정했습니다. 누가 실행하든 같은 방식, 같은 톤으로 분석 결과가 나옵니다 (여기서 스킬이 하는 역할은 Auto Research에서 "수정 가능한 파일을 하나로 제한한다"는 규칙과 같습니다.)
- 개입점 최소화: 사람이 하는 일은 두 가지뿐입니다. 표준화된 스킬로 나온 분석을 보고 더 파고들지 말지 고르는 것. 상세 분석이 필요하면 같은 스킬로 AI에게 맡기고 그 결과를 수정사항으로 올릴지 고르는 것
즉, 에러 감지부터 초기 분석, 상세 분석 및 실제 이슈화까지 흐르는 과정을 자동화하고, 시스템으로 정의하고, 실제 표준 절차 안에 가둬서 시스템의 개선 및 분석이 업무를 담당한 사람에 따라 흔들리지 않게 만드는 시스템을 설계했습니다.
이 작업은 Auto Research처럼 완전히 새로운 파이프라인을 만든 건 아니고, 원래 있던 "에러 대응" 업무 흐름 안에, 에러가 날 때마다 이 루프가 돌아가도록 기존 업무를 시스템으로 재정의한 것입니다.
마치며
- 에러가 발생하면 레포팅되고, 확인해서 분석하고, 이슈로 판단되면 이슈화하고, 수정한다. 이 과정을 반복하여 오류를 최소화하고 운영중인 시스템을 개선한다.
- 연구의 기준점을 잡고, 연구 결과가 이전보다 좋지 않으면, 새로운 연구를 진행하며 더 나아지면 기준점을 향상한다.
두 사례 다 원래 사람이 하고 있던 일입니다. 다만 그 판단이 각자의 머릿속에 흩어져 있어서, 사람이 바뀌면 결과도 같이 흔들리는 문제가 있었습니다. 그 판단을 정량적 기준점인 숫자 하나로 정의하고, 그 숫자를 기준으로 누가 오더라도 후퇴하지 않게 루프를 짜두면 시스템은 알아서 나은 방향으로 굴러갑니다.
지금 하는 일에서 "이게 좋아진 건지 나빠진 건지"를 여전히 감으로 판단하고 있다면, 그 기준을 숫자 하나로 꺼내는 것부터 시작하면 됩니다.
Auto Research: AI 에이전트가 사람을 대신해 스스로 모델 연구와 학습을 수행하는 'Vibe Training' 프로
Auto Research 소개 OpenAI의 전 핵심 연구원이자 저명한 AI 개발자인 안드레이 갓카파시(Andrej Karpathy)가 2026년 3월에 새롭게 공개한 Auto Research는 AI 에이전트가 스스로 모델 연구와 학습을 진행하도록
discuss.pytorch.kr
'Develop(개발)' 카테고리의 다른 글
| Java 멀티스레딩의 진화: Runnable부터 Virtual Threads까지 (0) | 2026.01.02 |
|---|---|
| [AWS] 프리티어 VPC 과금 문제 해결법 (RDS Public IP 없이 MySQL 워크벤치 연결) (0) | 2024.07.18 |
| 스프링 동시성 문제 해결법의 종류와 장단점 (5) | 2024.03.17 |
| 스프링이 어떻게 여러 요청을 동시에 처리할 수 있을까? (0) | 2024.03.10 |
| Github Action에서 간단한 테스트 자동화 하기! (4) | 2024.02.25 |