1
Andrej Karpathy는 자신의 AI를 3개의 역할로 나누었고, 각 역할이 자신의 작업을 평가하는 것을 금지했습니다. 한 역할이 스스로를 평가하면, 그 루프는 쓰레기 같은 결과로 수렴합니다.
이 내용은 LOOPS.md에서 나온 것입니다. 이는 인간의 입력 없이 며칠 동안 실행되는 AI 에이전트를 구축하는 그의 무료 필드 노트입니다. 여기에는 그가 자신의 에이전트를 구축하고 실행하는 방식에서 나온 9가지 원칙이 포함되어 있습니다.
기반은 프롬프트에서 루프로의 전환입니다. 왜냐하면 프롬프트는 한 번 입력하고 잊어버리는 것이기 때문입니다. 루프는 수집하고, 추론하고, 행동하고, 검증하고, 반복합니다. Karpathy는 새벽 3시에 단일 프롬프트를 반복적으로 수정하고 있다면, 여전히 프롬프팅 시대에 머물러 있다고 말합니다.
그는 AI를 3개의 역할로 나누며, 각 역할은 자신의 컨텍스트 창에서 작동합니다.
→ 플래너는 모호한 지시를 스프린트 사양으로 변환하고 코드를 절대 건드리지 않습니다.
→ 제너레이터는 모든 것을 작성하지만 자신의 출력을 평가할 수 없습니다.
→ 에밸류에이터는 diff를 읽고, 앱을 실행하며, 모든 코드베이스를 증명될 때까지 깨진 것으로 취급합니다.
제너레이터가 한 줄이라도 작성하기 전에, 에밸류에이터와 계약을 협상합니다. 둘은 마크다운 파일을 통해 논쟁하며, 테스트 가능한 기준의 체크리스트에 동의할 때까지 계속합니다. Karpathy는 작은 앱의 경우 27가지 기준이 적절한 크기라고 하며, 10가지는 너무 적어서 에밸류에이터가 단순히 승인만 찍는다고 합니다.
상태는 디스크에 저장됩니다. 왜냐하면 컨텍스트 창은 거짓말을 하기 때문입니다. Karpathy는 feature_list.json, progress.md, contract.md, 그리고 추가 전용 log.md를 유지합니다. 모델이 충돌하면 3개의 파일을 읽고 중단된 지점부터 재개합니다.
Karpathy의 핵심 메시지는 AI 에이전트를 단발성 프롬프트가 아니라 수집, 추론, 행동, 검증, 반복을 수행하는 루프로 설계해야 한다는 것이며, 이를 위해 플래너, 생성기, 평가기를 분리해 서로의 역할을 넘지 못하게 하는 구조가 중요하다는 점이다. 특히 생성 전에 평가 기준을 문서로 합의하고, 상태를 디스크에 저장해 재시작 가능하게 만들며, 모델이 실패하면 처음부터 다시 구성하는 재시작 자체를 루프의 정상 동작으로 받아들이라고 강조한다. 덧붙여 Claude 사례도 시스템 프롬프트를 최소화하고 실제 작업은 스킬로 분리할 때 성능과 운영성이 좋아진다는 같은 방향의 메시지를 뒷받침한다.
이 글의 핵심은 장시간 돌아가는 AI 에이전트는 단발성 프롬프트보다 반복 가능한 루프로 설계해야 한다는 점이다. 이를 위해 플래너, 생성기, 평가기를 분리해 한 역할이 자신의 작업을 직접 평가하지 못하게 해야 한다고 강조한다. 또한 생성 전에 테스트 가능한 기준을 문서로 합의해 계약처럼 맞춰 두어야 결과가 흔들리지 않는다. 상태는 컨텍스트 창이 아니라 파일에 저장해 충돌이나 재시작이 나도 쉽게 복구할 수 있어야 한다. 모델이 실패하면 억지로 이어 붙이기보다 처음부터 다시 구성하는 재시작을 정상적인 동작으로 받아들이는 것이 중요하다고 말한다. 마지막으로, 시스템 프롬프트는 최소화하고 실제 업무 로직은 스킬이나 분리된 구성요소로 옮길수록 운영성과 성능이 좋아진다는 메시지를 함께 전한다.