카파시 루프

1무슨 일이 있었나

Andrej Karpathy 가 autoresearch 라는 저장소를 공개했다. AI 에이전트에게 모델 학습 코드를 주고, 혼자 수정하고 혼자 돌려보고 혼자 채점하게 둔 것이다. 사람은 중간에 끼어들지 않는다.

숫자 자체보다 중요한 건 어디에서 나온 11%인가이다. nanochat 은 Karpathy 가 이미 상당히 다듬어 둔 코드였다. 세계적인 ML 연구자가 최적화해 둔 코드에서 에이전트가 20개를 더 찾아냈다. 그중 하나는 QK-Norm 에 스칼라 곱이 빠져 있던 것 — 본인이 몇 달간 못 보고 지나친 버그였다.

핵심은 이것이다. 연구자가 하루에 돌릴 수 있는 실험은 많아야 8~10회다. 그 시간의 대부분은 GPU 를 기다리는 데 쓰인다. 생각하는 시간이 아니라 기다리는 시간이 병목이다. 루프는 그 기다림을 사람에게서 떼어낸다.

2루프의 해부도 — 파일 세 개가 전부다

autoresearch 의 구조가 놀라운 건 단순해서다. 복잡한 프레임워크가 아니라 파일 세 개의 역할 분담이 전부다.

3가장 중요한 규칙: 채점표를 못 만지게 한다

이 설계에서 하나만 가져가야 한다면 이것이다. 에이전트는 자기를 채점하는 파일을 수정할 수 없다.

이유는 단순하다. 고칠 수 있게 두면, 모델을 개선하는 대신 점수를 따기 쉽게 만드는 쪽이 훨씬 빠른 길이기 때문이다. 에이전트는 악의가 없다. 주어진 목표를 가장 효율적으로 달성하는 것이고, 채점표를 고치는 게 실제로 더 효율적이다.

4언제 쓰면 안 되는가 — 네 가지 조건

여기가 실무에서 가장 중요한 대목이다. 루프는 공짜가 아니다. 맞지 않는 작업에 루프를 세우면 토큰만 태우고 결과도 못 얻는다. 네 가지가 모두 충족될 때만 만들 가치가 있다.

• 자주 반복하는 작업인가 루프를 만드는 데도 시간이 든다. 한 번만 할 일이면 좋은 프롬프트 하나가 낫다. 아니면 작업보다 설정에 시간을 더 쓰게 된다.
• 토큰 예산을 감당할 수 있는가 루프는 매 회차마다 프로젝트를 다시 읽고 새로 수정한다. 실패한 회차도 토큰을 쓴다. 월 20달러 요금제로 긴 루프를 돌리면 끝나기 전에 사용량 한도에 걸린다.
• 명확한 점수로 검증할 수 있는가 "잘 만들어졌나"를 사람이 눈으로 봐야 하는 작업은 루프가 돌 수 없다. 앱이라면 기능이 되는지 확인하는 작은 테스트 코드가 그 점수다.
• 에이전트가 직접 실행해서 깨지는 걸 볼 수 있는가 만든 것을 돌려보고 무엇이 실패했는지 알아야 다음 회차에서 고친다. 실행할 수 없으면 반복할 이유가 없다.

5앱 개발로 옮기기 — 스킬 다섯 개

ML 학습용 루프를 일반 앱 개발로 옮기면 구조가 이렇게 된다. 각 조각을 스킬로 쪼갠 이유가 중요하니 하나씩 본다.

왜 파일이 아니라 "스킬"로 만드는가

프로젝트 정보를 그냥 context.md 같은 파일에 두는 것과 스킬로 만드는 것의 차이가 영상에서 가장 실용적인 대목이었다.

6실제로 돌려보니 — 점수에 안 잡힌 문제

영상 제작자가 이 구조를 레스토랑 웹사이트에 적용했다. "손님이 음식 픽업을 주문할 수 있게 해달라"는 요청이었다.

1. 기능 목록에 없던 기능이라 먼저 등록

   Claude 가 features.md 에 온라인 주문 규칙을 추가했다.

2. 검사 항목 10개를 제시

   사람이 보니 게스트 이메일 확인이 빠져 있었다. 추가 요청 → 11개가 되었고, 새 검사는 이메일이 실제 주소 형식인지 확인했다.

3. 승인 → 커밋 → 잠금

   이 시점부터 에이전트는 검사를 수정할 수 없다.

4. 약 6분 만에 기능 완성, 첫 라운드에 11개 전부 통과

   반복이 필요 없었다. 여기까지는 성공이다.

5. 그런데 루프가 점수에 안 나타난 문제를 잡아냈다

   검사는 주문 규칙만 테스트했다. 규칙은 만들어졌지만 손님이 쓸 주문 양식이 없었다. 루프는 기능을 완료로 표시하기 전에 양식을 만들고 규칙과 연결했다.

7치명적 결함: 에이전트는 어제를 기억하지 못한다

여기가 영상의 핵심이고, 루프를 실제로 운영해 보지 않으면 모르는 문제다.

루프 안에서 어떤 방식이 안 먹히면 에이전트는 그 루프 안에서는 개선한다. 하지만 다음번에 같은 루프가 돌 때는 그걸 기억하지 못한다.

모든 기능이 항상 새 에이전트 + 똑같은 지시 파일로 시작하기 때문이다. 그래서 한 라운드에서 저지른 실수가 다음 라운드에서 똑같이 반복된다. 영상에서는 이것을 에이전트의 "습관"이라고 불렀다.

8해법 — 루프 안의 루프(오토 루프)

해결 방식이 우아하다. 첫 번째 루프의 실행 기록을 읽고 지시 파일을 고쳐 쓰는 두 번째 루프를 만든다. 영상에서는 이것을 오토 루프(auto loop) 스킬이라 불렀다.

원래 방식에서는 사람이 program.md 를 쓴다. 이 설정에서는 오토 루프가 그 파일을 고쳐 쓴다.

실제로 잡아낸 습관 두 개

프로젝트 관리 앱(여러 사람이 집중 세션을 공유하는 기능)에 적용한 결과다.

검사가 실제로 작동하는 모습

루프가 늘 한 번에 성공하지는 않는다. 공유 프로젝트 기능에서 빌더가 두 라운드를 틀렸고, 검사가 그걸 잡았다.

33+33+33=99 같은 오차는 사람이 코드 리뷰로 잡기 어렵다. 실행해서 채점했기 때문에 잡힌 것이다. 이게 "명확한 점수로 검증 가능해야 한다"는 조건이 왜 필수인지 보여준다.

9내 환경에 세울 때의 순서

영상 제작자는 "각 부분이 무슨 역할인지 알려줄 테니 Claude 에게 직접 만들어 달라고 요청하라"고 했다. 그 요청을 할 때 빠뜨리면 안 되는 것들을 순서로 정리한다.

1. 이 작업이 루프에 맞는지 먼저 판정

   4장의 네 조건을 통과하지 못하면 여기서 멈춘다. 프롬프트 하나로 끝낼 일에 루프를 세우면 설정에 더 많은 시간을 쓴다.

2. 프로젝트 컨텍스트 스킬부터 만든다

   기능·화면·규칙·금지사항을 담는 기억 저장소. 앱이 자라면 같이 갱신한다. 파일이 아니라 스킬로 만드는 이유는 5장 참조.

3. 검사 작성 스킬 — 구현보다 먼저

   에이전트가 자기 코드를 자기가 판단하지 않게 기준을 먼저 못박는다. 평이한 말로 "이 검사가 무엇을 확인하는지" 나열시켜 사람이 읽을 수 있게 한다.

4. 🔒 검사 잠금 장치를 반드시 넣는다

   승인된 검사를 잠긴 폴더로 옮기고, 에이전트 설정 규칙으로 그 폴더 수정을 차단한다. 커밋까지 해두면 보호 계층이 하나 더 생긴다. 이 단계를 빼면 루프 전체가 무의미해진다.

5. 기능 빌더를 별도 컨텍스트로 분리

   빌드 스킬이 직접 만들지 않고 넘긴다. 기능마다 새 컨텍스트로 시작해야 앞 기능의 잡음이 섞이지 않는다. 라운드 결과는 파일로 남긴다 — 다음 단계의 재료다.

6. 오토 루프를 얹어 지시서가 스스로 개선되게

   라운드 기록에서 반복되는 실수(습관)를 찾아 program.md 를 다시 쓰게 한다. 단, 오토 루프에게도 검사 편집 권한은 주지 않는다.

7. 샌드박스를 고려한다

   에이전트를 여러 개 동시에 돌리면 노트북에서 서로 충돌하고 느려진다. 각 에이전트에 격리된 실행 환경을 주면 밤새 병렬로 돌릴 수 있다. (영상에서는 10개를 동시에 돌렸다 — 하나는 기능 빌드, 하나는 버그 추적 등)

한 장으로 요약