원문은 Anthropic Research에서, 코드는 GitHub에서 볼 수 있다. 더 많은 글은 radarlog.kr에서.
TL;DR
Anthropic이 공개한 "Long-running Claude" 연구는 에이전트한테 목표만 주고 며칠간 방치하는 워크플로우를 보여준다. 우주론 코드를 며칠 만에 짠 게 핵심이 아니다. 에이전트를 방치할 수 있게 만드는 구조 — CLAUDE.md, CHANGELOG.md, 테스트 오라클, Ralph loop — 가 핵심이다. 나는 이 중 CLAUDE.md만 쓰고 있었다. 나머지를 어떻게 내 작업에 붙일지 설계해봤다.
무슨 연구인지 30초 요약
Anthropic 연구원 Siddharth Mishra-Sharma가 자기 전공도 아닌 우주론 분야의 볼츠만 솔버를 Claude Opus 4.6에게 맡겼다. 볼츠만 솔버는 빅뱅의 잔광인 CMB(우주 마이크로파 배경복사)를 예측하는 수치 계산 코드다. 전문가들이 보통 몇 달에서 몇 년씩 걸리는 작업인데, 비전문가가 방향만 잡아주고 며칠 만에 서브 퍼센트 정확도를 달성했다.
대단한 건 Claude의 머리가 아니라, 에이전트를 혼자 돌려놓고 커피 마시러 갈 수 있게 만든 구조다. 연구에서 핵심으로 꼽은 구성 요소는 네 가지다. CLAUDE.md로 목표와 규칙을 잡고, CHANGELOG.md로 세션 간 기억을 유지하고, 테스트 오라클(참조 구현체)로 자가 검증하고, Ralph loop로 에이전트가 "다 했다"고 거짓말하는 걸 차단한다.
원문 디테일이 궁금하면 전체 글을 읽는 게 낫다. 여기서부터는 게임 개발자인 내가 이 패턴을 어떻게 보고, 어디에 쓸 수 있을지를 얘기한다.
CLAUDE.md — 이건 이미 쓰고 있다
CLAUDE.md는 프로젝트 루트에 두는 지시서다. Claude Code가 이 파일을 특별히 취급해서 항상 컨텍스트에 유지한다. Anthropic 연구에서는 여기에 "CLASS 참조 구현체 대비 0.1% 정확도 달성", "완전한 미분 가능" 같은 과학적 목표를 명시했다. 에이전트는 이 파일을 읽고 방향을 잡고, 작업하면서 스스로 이 파일을 수정하고 업데이트한다.
나는 이미 사이드프로젝트마다 CLAUDE.md를 쓰고 있다. LAMDiceBot에는 WebSocket 재연결 정책, 방 관리 규칙, 테스트 커맨드가 들어있고, radarlog.kr 블로그 프로젝트에는 빌드 규칙, 배포 파이프라인, Prisma 스키마 변경 절차가 적혀있다.
근데 이 연구를 읽고 느낀 게 있다. 나는 CLAUDE.md를 "규칙 모음"으로만 쓰고 있었다.
Anthropic 연구의 CLAUDE.md는 단순한 규칙 리스트가 아니다. 프로젝트의 최종 목표, 성공 기준, 현재 설계 결정의 근거까지 담고 있다. 게임 개발로 치면 "코딩 컨벤션 문서"와 "게임 디자인 문서"의 차이다. 나는 컨벤션만 적어두고, 왜 이 프로젝트를 하는지, 뭘 달성해야 하는지를 빠뜨리고 있었다.
# 내가 기존에 쓰던 CLAUDE.md (규칙 중심)
## 작업 규칙
- Railway 배포 시 환경변수 확인
- Prisma migrate 전에 반드시 백업
- 커밋 메시지는 한국어로
# 앞으로 바꿀 CLAUDE.md (목표 + 규칙)
## 프로젝트 목표
- AI Signal 피드: HuggingFace Papers 외 5개 소스 통합
- 소스 추가 시 기존 피드 품질 유지 (중복률 5% 이하)
- 최종 상태: 사람 개입 없이 1일 1회 자동 수집
## 성공 기준
- 5개 소스 모두 파싱 성공률 95% 이상
- 기존 테스트 스위트 전부 통과
## 작업 규칙
- 의미 있는 단위마다 커밋 & 푸시
- 커밋 전에 테스트 실행차이는 명확하다. 목표가 없는 CLAUDE.md는 "어떻게 일할지"만 알려주고, "왜 일하는지"를 모른다. 에이전트가 스스로 판단을 내려야 하는 순간에 방향을 잃는다. 목표가 있으면 에이전트가 "이 변경이 프로젝트 목표에 부합하는가"를 스스로 판단할 수 있다.
이건 UE5에서도 똑같다. 신입한테 "이 함수 고쳐"라고만 하면 코드 스타일은 맞추는데 왜 고치는지를 모르니까 엉뚱한 방향으로 갈 수 있다. "이 시스템의 목표는 X이고, 지금 문제는 Y다"까지 알려줘야 제대로 된 수정이 나온다. 에이전트도 마찬가지다.
CHANGELOG.md — 아직 안 쓰고 있다. 이게 빠졌다.
이 연구에서 가장 "아차" 했던 부분이 CHANGELOG.md다.
AI가 며칠 동안 작업하면 세션이 바뀔 때마다 컨텍스트가 날아간다. 이전 세션에서 "이 방법은 안 된다"고 결론 내린 걸, 다음 세션에서 또 시도한다. 똑같은 삽질을 반복하는 거다. Anthropic 연구에서는 이걸 막기 위해 CHANGELOG.md를 만들었다. 에이전트의 '휴대용 장기 기억'이자 실험 노트다.
현재 상태, 완료된 작업, 실패한 접근 방식과 그 이유, 핵심 체크포인트에서의 정확도 표 등이 기록된다. 새 세션이 시작되면 에이전트가 이 파일을 읽고 이전 작업을 이어간다. 특히 "실패한 접근 방식" 기록이 핵심이다. 이게 없으면 다음 세션의 에이전트는 같은 막다른 길을 또 시도한다.
나는 이걸 안 쓰고 있었다. Claude Code로 작업하다가 세션이 끊기면, 다음 세션에서 "이전에 뭐 했는지" 설명하느라 시간을 쓴다. 설명을 빼먹으면 에이전트가 같은 실수를 반복하기도 했다. 특히 LAMDiceBot에서 WebSocket 재연결 로직을 디버깅할 때 이게 심했다. Zscaler 프록시 때문에 소켓이 끊기는 문제를 3번은 다시 설명한 것 같다.
CHANGELOG.md를 도입하고 CLAUDE.md에 "세션 시작 시 CHANGELOG.md를 먼저 읽어라"고 규칙 한 줄만 넣으면 이 문제가 바로 해결된다.
# CHANGELOG.md 적용 예시
## 2026-03-25
- Reddit 소스 파서 구현 완료 (r/MachineLearning, r/LocalLLaMA)
- RSS 피드 파서는 feedparser 라이브러리로 구현
- 시도: BeautifulSoup으로 Reddit 직접 크롤링 → 429 에러 빈발, API로 전환
## 2026-03-24
- HuggingFace Papers 기존 파이프라인 리팩토링
- 중복 검사 로직 추가 (제목 유사도 85% 이상이면 중복 처리)
- 시도: 단순 URL 매칭으로 중복 검사 → 같은 논문이 다른 소스에서 다른 URL로 올라와서 실패"시도 → 실패 → 이유" 패턴이 핵심이다. 이게 없으면 다음 세션의 에이전트는 BeautifulSoup 크롤링을 또 시도하고, URL 매칭을 또 시도한다. 게임 개발에서 버그 트래커의 "Won't Fix" 코멘트랑 같은 역할이다. UE5에서 GC 댕글링 포인터 디버깅할 때 노션에 "이 패턴은 안 됨, 이유는 X"라고 적어두는 것처럼, 에이전트한테도 같은 형태의 기록을 남겨주면 된다.
영리한 부분은 에이전트 스스로 CHANGELOG.md를 업데이트하게 한 점이다. 사람이 매 세션마다 수동으로 적는 게 아니라, CLAUDE.md에 "작업 후 CHANGELOG.md를 업데이트하라"고 규칙을 넣으면 에이전트가 알아서 기록한다. 기억을 만드는 것까지 자동화한 거다.
Ralph Loop — 이건 꼭 써보고 싶다
연구에서 가장 재밌게 읽은 부분이다.
현재 모델들은 복잡하고 긴 작업을 맡기면 종종 핑계를 대며 중간에 멈추려 한다. Anthropic은 이걸 '에이전트의 게으름(Agentic laziness)'이라고 부른다. "여기까지 했으니 나머지는 다음에 이어서 하죠?" 같은 반응이다.
Ralph loop는 이걸 강제로 막는 패턴이다. 에이전트가 "다 했다"고 주장하면 다시 컨텍스트로 돌려보내서 "정말로 목표를 달성했는지" 되묻는 for 루프다.
/ralph-loop:ralph-loop "전체 매개변수 범위에서 0.1% 정확도를
달성할 때까지 계속 작업하라" --max-iterations 20
--completion-promise "DONE"최대 20번 반복한다. 에이전트가 기준 미달을 인정하면 스스로 작업을 이어가고, 진짜로 끝났을 때만 "DONE"을 외쳐서 루프가 종료된다.
이 패턴을 보면서 UE5의 자동화 테스트 파이프라인이 떠올랐다. 빌드 돌리고, 테스트 실패하면 고치고, 다시 돌리고. 차이점이라면 코드를 고치는 주체가 사람이 아니라 에이전트라는 것뿐이다. CI/CD에서 "빌드 실패하면 재시도"가 당연한 것처럼, 에이전트한테도 "기준 미달이면 반복"을 거는 건 자연스러운 확장이다.
아직 직접 써본 적은 없다. 근데 적용 시나리오는 바로 떠오른다.
radarlog.kr AI Signal 파이프라인에서 새 소스를 추가할 때, "5개 소스 전부 파싱 성공률 95% 이상이 될 때까지 반복하라"고 걸어둘 수 있다. 에이전트가 Reddit 파서를 짜다가 "일단 3개 소스까지 했으니 여기서 멈추겠습니다"라고 하는 걸 막는 거다. 혹은 UE5 프로젝트에서 대규모 리팩토링을 맡길 때, "기존 테스트 전부 통과할 때까지 계속 고쳐라"로 잡을 수 있다.
핵심은 명확한 성공 기준이 있어야 한다는 거다. "좋은 코드를 써라"는 Ralph loop에 넣을 수 없다. "이 테스트 10개를 전부 통과해라"는 넣을 수 있다. 수치로 떨어지는 기준이 있어야 에이전트도, 루프도 작동한다.
테스트 오라클 — 에이전트 자가 검증의 전제 조건
네 가지 구성 요소 중에서 가장 간과하기 쉬운 게 테스트 오라클이다. Anthropic 연구에서는 기존 C 언어 CLASS 소스 코드가 그 역할을 했다. Claude가 JAX로 코드를 짜면서 계속 CLASS의 출력과 비교해서 정확도를 측정했다.
이 패턴이 작동하는 이유는 "정답"이 존재하기 때문이다. CLASS가 내놓는 수치가 정답이고, Claude가 짠 코드의 수치가 거기에 수렴하면 성공이다.
내 프로젝트에 대입해보면 이렇다. AI Signal 파이프라인이라면 "기존 HuggingFace Papers 파이프라인의 출력"이 테스트 오라클이 된다. 새 소스를 추가해도 기존 소스의 파싱 결과가 깨지지 않는지 비교하는 거다. LAMDiceBot이라면 기존 통과 테스트 스위트가 오라클이다. 리팩토링 후에 기존 테스트가 전부 통과하면 성공.
여기서 원문이 솔직하게 인정한 부분이 있다. Claude가 한동안 단일 파라미터 포인트에서만 테스트를 돌리고 있었다. 테스트 커버리지에 구멍이 있었던 거다. 다양한 입력에서 테스트하지 않으면, 특정 조건에서만 작동하는 코드가 나온다.
게임 개발에서 이건 너무 익숙한 문제다. QA가 한 맵에서만 테스트하면 다른 맵에서 터지는 버그를 못 잡는다. 에이전트한테 테스트를 시킬 때도 "다양한 입력으로 돌려라"를 CLAUDE.md에 명시해야 한다. 오라클이 있어도 커버리지가 좁으면 반쪽짜리다.
정리 — 내가 가져갈 것
이 연구를 읽기 전과 후를 비교하면 이렇다.
CLAUDE.md는 이미 쓰고 있었는데, 규칙만 적고 목표를 빠뜨리고 있었다. 앞으로는 프로젝트 목표와 성공 기준을 먼저 쓰고, 규칙은 그 아래에 붙인다.
CHANGELOG.md는 안 쓰고 있었다. 세션이 바뀔 때마다 컨텍스트를 잃어버려서 같은 설명을 반복하는 문제가 있었는데, 이걸로 해결할 수 있다. "시도 → 실패 → 이유" 패턴으로 에이전트의 장기 기억을 만들어준다.
Ralph loop는 아직 써본 적 없지만, 명확한 수치 기준이 있는 작업에 바로 적용할 수 있다. "좋은 코드 써라"가 아니라 "이 테스트 통과해라"처럼 기준을 수치로 만드는 게 핵심이다.
테스트 오라클은 개념 자체는 익숙하지만, 에이전트 워크플로우 안에서 의식적으로 설계하는 건 다른 문제다. 커버리지까지 챙겨야 진짜 작동한다.
과학 연구 이야기지만, 결국 핵심은 범용적이다. 명확한 목표, 자가 검증, 장기 기억, 끝까지 반복. 이 네 가지가 갖춰지면 에이전트를 며칠째 방치할 수 있다. 안 갖춰지면 30분마다 들여다봐야 한다.
"CLAUDE.md에 규칙만 적고 있었다면, 목표를 빠뜨린 거다."