[Claude] 자율 연구와 개발 자동화 — AutoResearch·Goal·Autopilot
목차
📚 Claude Code 정리 노트 (2026-07) — 4부작
1. 제품 명세 문서 2. 멀티 에이전트와 Ralph 3. 자율 연구·개발 자동화 ← 지금 읽는 글 4. 브라우저 자동화
1. 2026년 3월, Andrej Karpathy의 AutoResearch란?
Ralph 루프의 “반복 + 검증” 아이디어가 코딩을 넘어 ML 연구 자동화로 확장된 대표 사례.
개념 한 줄
사람이 program.md(연구 방향)를 쓰면, 에이전트가 train.py를 직접 고쳐가며 밤새 실험을 반복하고, 개선된 결과만 git에 남기는 자율 연구 루프.
그림: 사람이 쓴
program.md(연구 방향) → 에이전트가train.py수정 → 5분 고정 학습 →val_bpb평가 → 개선되면 git 커밋으로 유지(keep-if-better), 나빠지면 폐기 → 반복. 사람은 방향·지표를 설계하고, 루프가 밤새 실험을 돌린다.
기본 정보
| 항목 | 내용 |
|---|---|
| 공개일 | 2026년 3월 7일 |
| 공개자 | Andrej Karpathy |
| 라이선스 | MIT(오픈소스), 약 630줄 파이썬 |
| 목적 | 단일 GPU에서 ML 연구 실험을 자율로 반복 |
| 대상 모델 | nanochat(간소화된 GPT 구현) |
동작 루프
| 단계 | 내용 |
|---|---|
| 1) 명세 | program.md에 연구 방향·맥락을 사람이 마크다운으로 작성 |
| 2) 수정 | AI 에이전트가 train.py를 직접 수정(아키텍처·하이퍼파라미터·옵티마이저·배치 크기 등) |
| 3) 학습 | 각 실험은 플랫폼 무관 비교를 위해 정확히 5분(wall-clock) 학습 |
| 4) 평가 | val_bpb(validation bits per byte, 낮을수록 개선)로 평가 |
| 5) 선택 | 개선되면 git 커밋으로 유지, 나빠지면 폐기(keep-if-better) |
| 6) 반복 | 계속 반복 — 시간당 약 12개 실험, 자는 동안 약 100개 |
결과 사례
| 사례 | 결과 |
|---|---|
| Karpathy 본인 | 이틀 연속 실행, 약 700개 실험. “Time to GPT-2” 벤치마크 2.02시간 → 1.80시간 |
| Shopify(Tobi Lütke) | 사내 query-expansion 모델에 응용, 37개 실험으로 검증 점수 약 19% 개선(공개된 수치, 하루 만에 보고) |
핵심 관점
“program.md(사람이 쓰는 명세) + train.py를 고치는 루프” 구조는 Ralph 루프를 ML 연구에 특화한 형태에 가깝다. 사람은 코드를 직접 치는 대신 연구 방향과 평가 지표(val_bpb)를 설계하고, 나머지는 루프가 밤새 실험을 돌리며 채운다. Karpathy는 이런 흐름 속에서 “코드를 직접 짜지 않게 됐다”는 취지의 발언을 한 것으로 보도됨.
🔗 이 구조는 파트 A(제품 명세 편)의 “명세가 먼저”라는 원칙, 루프 엔지니어링, Ralph와 직접 연결된다 — 도메인만 “코딩”에서 “ML 연구”로 바뀐 것.
한 줄 요약: AutoResearch =
program.md(명세) +train.py자동 수정 + keep-if-better 선택을 5분 단위로 반복하는 오픈소스 자율 연구 루프. Ralph의 “반복+검증” 아이디어를 ML 연구 실험에 특화한 사례.
출처: https://github.com/karpathy/autoresearch , https://www.datacamp.com/tutorial/guide-to-autoresearch
2. AlphaEvolve와 AutoResearch의 차이
둘 다 “AI가 알고리즘·모델을 자동으로 탐색·개선한다”는 같은 방향을 향하지만, 구현 방식은 상당히 다르다.
개념 한 줄
AlphaEvolve는 대규모·진화형·비공개, AutoResearch는 경량·탐욕적·오픈소스 — 같은 목표를 다른 규모·방식으로 푼 두 사례.
대비표
| 구분 | AlphaEvolve | AutoResearch |
|---|---|---|
| 공개 | Google DeepMind, 2025년 5월 | Andrej Karpathy, 2026년 3월 7일 |
| 탐색 방식 | 진화형(evolutionary) — 개체군(population)을 두고 수백만 코드 변형을 진화 탐색 | LLM이 train.py 코드를 직접 수정 + greedy keep-if-better(사실상 언덕오르기) |
| 사용 모델 | Gemini Flash(빠른 아이디어) + Gemini Pro(정교화) + 자동 평가기 앙상블 | 임의의 코딩 에이전트(LLM) 1개 |
| 공개성 | 비공개(closed-source), 기술 블로그·결과만 공개 | 오픈소스(MIT), 약 630줄 |
| 규모/컴퓨트 | 대규모, 수백만 코드 변형 탐색 | 단일 GPU, 실험당 5분, 밤새 약 100개 |
| 주 대상 | 범용 알고리즘 발견(행렬 곱셈, 데이터센터 스케줄링, 수학 난제 등) | ML 학습 연구(nanochat 기반) |
| 접근성 | 재현 어려움(코드 비공개) | 누구나 실행 가능 |
| 성과 | 공개 난제 50여 개 중 75%에서 기존 SOTA 재발견, 20%에서 최고 기록 경신 | ”Time to GPT-2” 2.02시간→1.80시간(Karpathy), 검증 점수 약 19% 개선(Shopify 사례) |
공통점 — 왜 둘 다 “루프”로 도는가
탐색 방식은 다르지만, 둘 다 성립하려면 반드시 **자동 평가기(evaluator)**가 있어야 한다 — AlphaEvolve는 자동 채점기, AutoResearch는 val_bpb 지표. 사람이 매 실험을 눈으로 확인하지 않아도 되게 만드는 이 장치가 없으면 루프 자체가 돌 수 없다.
🔗 이는 Ralph의 한계(“자동 검증 가능한 작업에만 통함”)와 같은 전제다 — 규모가 커지든 작아지든, 자율 반복 루프가 성립하려면 결국 명확하고 자동화된 성공 기준이 있어야 한다는 점은 동일하다.
한 줄 요약: AlphaEvolve(대규모·진화형·비공개)와 AutoResearch(경량·탐욕적·오픈소스)는 같은 “자율 알고리즘 발견”이라는 흐름 위에 있지만, AutoResearch는 접근성에서, AlphaEvolve는 탐색 규모에서 강점을 가진다. 둘 다 자동 평가기가 있어야 루프가 성립한다는 점은 동일.
출처: https://deepmind.google/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/ , https://en.wikipedia.org/wiki/AlphaEvolve
3. 연구 과정·결과 기록 — LLM Wiki
LLM Wiki는 OMC(oh-my-claudecode) 플러그인의 스킬(
/oh-my-claudecode:wiki)이다. Claude Code 자체의 native 기능이 아니라 그 위에 얹힌 확장 기능임에 유의.
그림: 세션은 끝나면 컨텍스트가 사라지지만, 매 세션이 **LLM Wiki(영속 마크다운 지식 베이스)**에 기록(write)하고 다음 세션이 재사용(read)하며 지식이 누적된다. 추가·질의·흡수·정리로 관리하는 “외부 기억” 층.
개념 한 줄
세션을 넘나들며 축적되는 영속적 마크다운 지식 베이스 — “Karpathy 모델”이라는 이름으로 소개됨(AutoResearch 절의 Karpathy의 “지식이 compounding된다”는 관점과 같은 맥락).
목적
연구 과정·결과·배운 점을 대화가 아니라 파일로 남겨, 컨텍스트가 초기화돼도 지식이 사라지지 않고 계속 쌓이게 하는 것.
주요 동작
| 동작 | 역할 |
|---|---|
| wiki_add | 새 지식·결과 추가 |
| wiki_query | 쌓인 지식 질의·검색 |
| wiki_ingest | 외부 문서를 흡수해 위키로 편입 |
| wiki_read | 특정 항목 읽기 |
| wiki_list | 목록 조회 |
| wiki_lint | 위키 내용 정리·정합성 점검 |
왜 필요한가
Ralph·AutoResearch 같은 루프는 매 반복이 새 컨텍스트라, 기억을 외부(파일·git)에 남겨야 이어진다고 이미 정리했다. LLM Wiki는 그 “외부 기억”을 연구 지식이라는 관점에서 체계화한 층이다 — 이전 노트의 파일 기반 메모리 시스템(2026-06-20 노트)과도 같은 계열.
🔗 Ralph(기억은 파일·git이 담당)·AutoResearch(program.md + git history로 상태 인계)·루프 엔지니어링과 연결.
한 줄 요약: LLM Wiki(OMC 스킬) = 세션이 끝나도 사라지지 않는 연구 지식 베이스. 추가·질의·흡수·정리 동작으로 Ralph·AutoResearch류 루프의 “외부 기억”을 지식 관리 관점으로 구체화한 것.
4. 자율 코딩 루프와 Goal (/goal)
그림:
/goal <조건>설정 → Claude 턴 실행 → 작은 모델(기본 Haiku)이 조건 평가 → 미충족이면 다음 턴을 자동 반복, 충족이면 정지. Prompt 기반 Stop hook으로 구현돼/compact후에도 유지되고--resume시 복원된다.
개념 한 줄
완료 조건(completion condition)을 정해두면, 그 조건이 충족될 때까지 여러 턴을 사용자 입력 없이 자동 반복 실행하는 Claude Code native 내장 기능. (Claude Code v2.1.139 이상 필요)
구현 원리
| 요소 | 내용 |
|---|---|
| 내부 구현 | ”Prompt 기반 Stop hook” |
| 평가 주체 | 각 턴 후 작은 빠른 모델(기본 Haiku)이 완료 조건 충족 여부를 평가 |
| 미충족 시 | 다음 턴을 자동으로 시작 |
| 컨텍스트 압축과의 관계 | hook은 컨텍스트가 아니라 코드로 실행되므로 /compact의 대상이 아님 → Goal 조건은 압축 후에도 유지 |
| 세션 재개 | 활성 Goal 상태로 종료 후 --resume/--continue로 재개하면 Goal이 복원됨. 단 턴 수·타이머·토큰 기준선은 리셋되고, 목표 조건 자체만 유지. 이미 달성했거나 /goal clear한 Goal은 복원되지 않음 |
사용법
| 명령 | 동작 |
|---|---|
/goal <조건문> | 조건 설정 + 자동 반복 시작 |
/goal | 상태 조회(경과 시간·턴 수·토큰·최근 평가 이유) |
/goal clear | 해제 (stop/off/reset/none/cancel도 동의어) |
claude -p "/goal ..." | 비대화형 실행 |
조건문 작성 제약
- 최대 4,000자
- 측정 가능한 단일 종료 상태여야 함(예: 테스트 통과, 빌드 종료 코드, 파일 개수 등)
- Claude가 이미 출력한 내용을 기준으로 평가됨
Auto mode와의 구분
| 구분 | 자동 반복 범위 |
|---|---|
| Auto mode | 한 턴 안에서 도구 호출을 자동 승인 |
| Goal | 턴 자체를 조건 충족까지 자동 반복 |
🔗 루프 엔지니어링의 native 구현이며, 외부 스크립트 방식인 Ralph와의 차이는 바로 다음 Ralph vs Goal 절에서 대비한다.
한 줄 요약: Goal = 루프 엔지니어링을 Claude Code가 native로 구현한 것. 완료 조건을 한 줄로 걸어두면, 작은 모델이 매 턴 평가해 조건 충족까지 자동으로 턴을 반복한다.
5. Ralph Loop와 Goal의 차이점
Ralph와 Goal은 둘 다 “될 때까지 반복”이라는 루프 엔지니어링의 구현체이지만, 출처와 작동 방식이 다르다.
그림: Goal(내장 native)과 Ralph Loop(외부 플러그인)의 구현·세션/컨텍스트·상태·평가·강점 대비. 간단한 반복이면 Goal, 복잡한 외부 검증·다중 에이전트 조율이면 Ralph.
대비표
| 측면 | Goal (/goal) | Ralph Loop |
|---|---|---|
| 출처 | Claude Code 공식 native 기능 | 외부 플러그인(OMC·ouroboros 등)의 기법 |
| 구현 | 내부 Prompt 기반 Stop hook | 외부 bash 반복(while true; do claude -p ...; done) |
| 세션/컨텍스트 | 단일 세션 내 턴 반복 → 컨텍스트가 계속 누적 | 매 반복 새 세션 → 깨끗한 컨텍스트, 상태는 파일·git으로 전달 |
| 평가 방식 | 작은 모델(Haiku)이 조건을 자동 평가 | 커스텀 검증(hook·프롬프트·외부 명령) |
| 중단 조건 | 조건 충족 시 자동 | 검증 통과 또는 최대 반복 횟수 |
| 강점 | 간편·빠른 내부 반복, 설정 한 줄(/goal ...) | 복잡한 외부 검증·다중 에이전트·빌드/배포 통합에 유연 |
핵심 트레이드오프
Goal은 누적 컨텍스트라 설정이 간편하지만, 반복이 길어질수록 컨텍스트가 쌓여 성능 저하 우려가 있다. Ralph는 매번 새 컨텍스트(Ralph·AutoResearch 절에서 이미 정리한 장점)라 편향·길이 문제를 피할 수 있지만, 그만큼 외부 스크립트·상태 관리(파일·git 인수인계)를 직접 챙겨야 한다.
선택 가이드
- 간단한 반복(같은 세션 안에서 조건 하나만 충족시키면 되는 작업) → Goal
- 복잡한 외부 검증·다중 에이전트 오케스트레이션이 필요한 작업 → Ralph
🔗 루프 엔지니어링·Ralph·AutoResearch와 연결.
한 줄 요약: Goal은 Claude Code native의 “턴 반복”, Ralph는 외부 플러그인·스크립트 기반의 “세션 반복” — 둘 다 자동 평가기가 있어야 성립한다는 점은 같지만, 컨텍스트를 누적할지(Goal) 매번 새로 시작할지(Ralph)가 근본적인 차이다.
6. OMC 코드 검증과 UltraQA
Ralph의 한계·AlphaEvolve와 AutoResearch의 공통점에서 이미 확인했듯, 자율 반복 루프가 성립하려면 자동 평가기가 반드시 있어야 한다. OMC는 이 검증 층을 여러 도구로 갖추고 있다.
그림: UltraQA는 테스트→검증→수정을 목표(품질 기준) 충족까지 반복하는 QA 사이클. 작성(writer)과 검수(reviewer)를 분리해 자기 승인을 막고, verifier·
/verify·code-reviewer로 검증 층을 갖춘다.
개념 한 줄
검증(테스트) → 확인 → 수정 → 반복을 목표 충족까지 도는 QA 워크플로가 UltraQA이며, 이는 OMC의 여러 검증 수단 중 하나다.
OMC의 검증 수단
| 수단 | 역할 |
|---|---|
| verifier 에이전트 | 완료 근거·검증 전략·테스트 적정성을 확인 |
/verify 스킬 | 완료를 주장하기 전에 변경이 실제로 동작하는지 확인 (Claude Code native built-in 스킬) |
| code-reviewer 에이전트 | 심각도 등급을 매기는 코드 리뷰 |
UltraQA(/oh-my-claudecode:ultraqa) | 테스트 → 검증 → 수정 → 반복의 QA 사이클 워크플로 |
주의 — 검증 수단은 native와 플러그인에 걸쳐 있다: /verify·/code-review는 Claude Code native built-in 스킬이고, verifier·code-reviewer 에이전트와 UltraQA는 OMC 플러그인이다.
원칙 — 작성과 검수는 분리
같은 컨텍스트에서 자기 승인을 하지 않고, 작성 패스와 검수 패스를 분리해 승인은 반드시 code-reviewer·verifier가 담당한다. 이번 편 앞부분(LLM Wiki부터 UltraQA까지)도 doc-writer(초안 작성) → doc-reviewer(검수)의 별도 패스로 만들어지는 것이 같은 원칙의 실제 적용 사례다.
관점 — 왜 이 층이 필요한가
UltraQA는 루프 엔지니어링을 QA에 적용한 것이며, 이런 검증 층이 있어야 Ralph·Goal 같은 자율 루프가 안전하게 돌아간다. 이는 Ralph의 한계에서 내린 결론(Ralph는 “자동 검증 가능한 작업”에서만 통함)과 AlphaEvolve와 AutoResearch 비교에서 내린 결론(AlphaEvolve·AutoResearch 모두 자동 평가기가 있어야 루프가 성립)으로 정확히 이어진다. 멀티 에이전트 구성 요소에서 정리한 것 중 **검증기(Verifier)**의 실제 구현 사례이기도 하다.
🔗 멀티 에이전트 구성 요소(검증기)·루프 엔지니어링·Ralph의 한계·AlphaEvolve·AutoResearch 비교(자동 평가기 필요)와 연결.
한 줄 요약: UltraQA = 루프 엔지니어링을 QA에 적용한 OMC 워크플로. verifier·
/verify·code-reviewer와 함께 “자동 검증 가능해야 루프가 통한다”(Ralph의 한계·AlphaEvolve 비교)는 전제를 실제로 채우는 검증 층이다.
이렇게 이 편 앞부분(LLM Wiki부터 UltraQA까지)을 지나면, 서두(“들어가며”)의 질문 — AI 에이전트 시대에 사람은 무엇을 할 것인가 — 에 대한 답이 한 바퀴 돌아 완성된다. 사람은 명세하고(파트 A, 제품 명세 편), 조율하고(파트 B, 멀티 에이전트 편), 검증 기준을 세운다(Ralph의 한계·AlphaEvolve 비교·UltraQA). 코드를 직접 치는 일은 줄어들지만, 그 세 가지 — 명세·조율·검증 — 는 여전히, 그리고 앞으로도 사람의 몫으로 남는다.
7. OMC 개발 루프 자동화 — Autopilot
OMC 플러그인 스킬(
/oh-my-claudecode:autopilot). 아이디어 2~3줄만 던지면, 동작하고 검증된 코드가 나올 때까지 전체 생애주기를 자율로 실행한다.
그림: Autopilot의 5+1단계 — Expansion→Planning→Execution→QA(UltraQA)→Validation(전원 승인)→Cleanup. 각 단계 순차·단계 내 병렬이며, deep-interview→ralplan→autopilot 파이프라인으로 앞 단계를 건너뛸 수 있다.
개념 한 줄
“아이디어 → 명세 → 계획 → 구현 → QA → 검증 → 정리”까지 6단계를 사람 개입 없이 끝까지 밀어붙이는 OMC의 종합 자동화 스킬.
5+1 단계
| Phase | 이름 | 내용 |
|---|---|---|
| Phase 0 | Expansion | analyst + architect(Opus)가 짧은 아이디어를 구체적 스펙으로 확장 |
| Phase 1 | Planning | architect가 계획을 수립하고, critic이 그 계획을 검증 |
| Phase 2 | Execution | Ralph + Ultrawork 루프, executor(haiku·sonnet·opus)가 병렬로 구현 |
| Phase 3 | QA | UltraQA — 빌드·린트·테스트·수정을 반복(최대 5회), 같은 에러가 3회 반복되면 중단 |
| Phase 4 | Validation | architect·security-reviewer·code-reviewer가 병렬로 검증, 전원 승인해야 통과(거부 시 수정 후 재검증) |
| Phase 5 | Cleanup | 작업 중 생성된 상태 파일 정리 |
실행 방식
각 Phase는 순차 진행되고, Phase 내부의 여러 에이전트는 병렬 실행된다. /oh-my-claudecode:cancel로 언제든 취소할 수 있고, 재실행하면 중단 지점부터 재개한다.
3단계 파이프라인 안에서의 위치
| 단계 | 스킬 | 산출물 |
|---|---|---|
| 1 | deep-interview | 요구사항 명세 |
| 2 | ralplan | 합의된 계획 |
| 3 | autopilot | 실제 구현·검증 |
→ ralplan에서 이미 합의된 계획이 있으면, autopilot은 Phase 0·1을 건너뛰고 Phase 2부터 시작한다.
🔗 이 노트 전체의 종합판이다. 파트 A(제품 명세 편)를 잇는 명세 단계(Phase 0), Ralph·Ultrawork(루프 엔지니어링·Ralph)를 잇는 실행 단계(Phase 2), UltraQA를 잇는 QA 단계(Phase 3), 멀티 에이전트 검증을 잇는 Validation 단계(Phase 4)를 한 스킬로 압축했다. “사람은 아이디어를 명세하고, 나머지 루프를 자동화한다”는 이 노트의 결론을 그대로 구현한 스킬.
한 줄 요약: Autopilot = 아이디어 2~3줄에서 검증된 코드까지, 명세·계획·구현·QA·검증·정리 6단계를 자율로 도는 OMC 스킬. 각 단계는 순차, 단계 내부는 병렬로 실행되며, 합의된 계획이 이미 있으면 실행 단계부터 바로 시작한다.
8. Claude Code의 Built-in 스킬
그림: 스킬 네 갈래(내장 bundled·사용자·프로젝트·플러그인)와 SKILL.md의 점진적 로딩 — description만 항상 컨텍스트에, 본문은 호출 시 로드. Goal=native 기능,
/loop·/verify=native 스킬, autopilot·visual-verdict 등=OMC 플러그인.
개념 한 줄
Built-in(bundled) 스킬 = Claude Code에 기본 내장되어 함께 배포되는 스킬. prompt 기반으로 Claude에게 지침을 주고 도구 사용을 조율한다. 예: /code-review, /verify, /loop, /review, /security-review, /run, /init 등.
명령(command)과 bundled 스킬의 구분
고정 로직을 즉시 실행하는 built-in “명령”(/help, /compact)과, prompt 기반으로 Claude를 조율하는 “bundled 스킬”은 성격이 다르다. 다만 호출 방식은 둘 다 /이름으로 같다.
스킬의 네 가지 종류
| 종류 | 위치 | 범위 |
|---|---|---|
| bundled(내장) | Claude Code 자체에 포함 | 모든 세션 |
| 사용자 스킬 | ~/.claude/skills/ | 모든 프로젝트 |
| 프로젝트 스킬 | .claude/skills/ | 현재 프로젝트 |
| 플러그인 스킬 | 플러그인의 skills/ 디렉토리 | 해당 플러그인 설치 환경(예: OMC) |
발견과 호출
각 스킬의 SKILL.md frontmatter에 있는 description을 Claude가 현재 문맥과 매칭해 자동으로 트리거하거나, 사용자가 /이름으로 수동 호출한다. disable-model-invocation 설정을 걸면 자동 트리거를 막고 수동 호출 전용으로 만들 수 있다.
Progressive disclosure(점진적 로딩)
description만 항상 컨텍스트에 상주하고, 스킬 본문은 실제로 호출될 때만 로드된다. 설치된 스킬이 많아도 평소 토큰 비용은 최소로 유지되는 구조.
🔗 이 노트에서 다룬 것들의 큰 그림 정리: Goal은 Claude Code의 native 기능, /loop·/verify는 native bundled 스킬, autopilot·ultraqa·visual-verdict·LLM Wiki는 OMC 플러그인 스킬이다.
한 줄 요약: bundled 스킬 = Claude Code에 기본 내장된 prompt 기반 스킬. 사용자 스킬·프로젝트 스킬·플러그인 스킬과 함께 네 종류를 이루며, description만 상주하고 본문은 호출 시에만 로드되는 progressive disclosure 구조로 토큰을 아낀다.
9. loop — 반복 실행 스킬 (/loop)
출처: https://code.claude.com/docs/en/scheduled-tasks.md · Claude Code native bundled 스킬
그림:
/loop의 세 사용법(고정 5분·간격 생략 시 동적·기본)과/schedule(클라우드·영구·최소 1시간)과의 대비. 현재 작업 중 빠른 반복은/loop, 야간/정기 자동은/schedule.
개념 한 줄
현재 세션 안에서 프롬프트나 슬래시 명령을 주기적으로 반복 실행하는 스킬. 폴링·상태 확인·반복 작업에 적합하며, 세션이 닫히면 함께 멈춘다.
사용법
| 명령 | 동작 |
|---|---|
/loop 5m <prompt> | 5분 간격 고정(내부적으로 cron으로 변환) |
/loop <prompt> | 간격 생략 시 Claude가 1분~1시간 범위에서 동적으로 선택 — 진행 중이면 짧게, 조용하면 길게 |
/loop | 인자 없이 호출하면 기본 유지보수 프롬프트로 반복 |
- Esc로 언제든 중단 가능.
- 생성 후 7일이 지나면 자동 만료.
/schedule(Routines)과의 차이
| 구분 | /loop | /schedule |
|---|---|---|
| 실행 위치 | 현재 머신의 현재 세션 | Anthropic 클라우드 |
| 지속성 | 7일 만료 | 계정에 영구 등록, 머신을 꺼도 유지 |
| 최소 간격 | 1분 | 1시간 |
| 컨텍스트 | 현재 세션 컨텍스트 상속 | 없음(독립 실행) |
| 로컬 파일 접근 | 가능 | 불가 |
| 트리거 방식 | 세션 내 반복 | Schedule/API/GitHub 트리거 |
선택 가이드
- 야간·정기 자동 실행 →
/schedule - 지금 하고 있는 작업의 빠른 반복 확인(PR 모니터링, 빌드 대기 등) →
/loop
🔗 루프 엔지니어링의 “시간 기반 반복” 형태다. 조건이 충족될 때까지 도는 Goal(조건 기반), 파일·git으로 상태를 이어가는 자기참조형 Ralph와 나란히 놓이는, 이 노트의 세 번째 루프 구현 방식.
한 줄 요약:
/loop= 세션 안에서 정해진(또는 동적으로 조절되는) 간격으로 프롬프트를 반복하는 native bundled 스킬. 세션 종속·7일 만료가 특징이며, 계정에 영구 등록되는/schedule과는 지속성·간격·로컬 접근성에서 갈린다.
10. QA 자동화 워크플로우 설계
지금까지 나온 검증 요소들(UltraQA, visual-verdict, verifier, 반복 엔진)을 하나의 QA 자동화 파이프라인으로 엮어보는 종합 설계 섹션.
그림: 코드 변경 → 기능 검증(UltraQA) → 시각 검증(visual-verdict·CDP) → 완료 근거(verify) → 종료 조건 미충족이면 반복(엔진:
/loop·Goal·Ralph), 충족 시 완료. 설계 4원칙(명확한 종료 조건·작성/검수 분리·기능+시각 이중 검증·반복 안전장치) 포함.
개념 한 줄
기능 검증 + 시각 검증 + 완료 근거 확인을 한 파이프라인에 묶고, 통과할 때까지 반복 엔진으로 돌리는 QA 워크플로.
파이프라인
코드 변경
│
▼
① 기능 검증: 빌드·린트·테스트 (UltraQA)
│
▼
② 시각 검증: 스크린샷 캡처 후 레퍼런스와 대조 (visual-verdict / 캡처 엔진: CDP)
│
▼
③ 완료 근거 확인 (verifier · `/verify`)
│
├─ 통과 못 하면 → 반복 엔진으로 되돌아감 (`/loop` · Goal · Ralph 중 선택)
│
▼
자동 평가기(테스트 결과 + 시각 verdict)가 종료 조건 판단설계 원칙
| 원칙 | 내용 |
|---|---|
| 측정 가능한 종료 조건 | ”잘 됐는지”가 아니라 테스트 통과·verdict 점수 같은 명확한 수치·상태로 판단 |
| 작성/검수 분리 | 같은 컨텍스트에서 자기 승인 금지(UltraQA 원칙과 동일) |
| 기능+시각 이중 검증 | 테스트는 로직을, visual-verdict는 눈에 보이는 결과를 각각 담당 — 한쪽만으로는 부족 |
| 반복 안전장치 | 최대 반복 횟수·비용 상한을 반드시 둠(Ralph 실행·Ralph의 한계에서 이미 강조된 원칙) |
완성형 구현
**Autopilot의 Phase 3(QA) + Phase 4(Validation)**가 이 설계를 실제로 구현한 사례에 해당한다 — 기능 검증(UltraQA)과 병렬 승인(다중 리뷰어)이 이미 파이프라인 안에 들어 있다.
🔗 UltraQA·verifier·visual-verdict·CDP·/loop·Goal·Ralph 종합.
한 줄 요약: QA 자동화 = 기능 검증(UltraQA) → 시각 검증(visual-verdict) → 완료 근거 확인(verifier) → 반복(loop/goal/ralph)을 하나로 묶은 파이프라인. 측정 가능한 종료 조건과 작성/검수 분리가 핵심 설계 원칙이며, Autopilot의 Phase 3·4가 이를 실제로 구현한 완성형이다.
11. OMC의 매서운 눈 — visual-verdict
OMC 플러그인 스킬(
/oh-my-claudecode:visual-verdict). 생성된 UI 스크린샷을 레퍼런스 이미지와 대조해 엄격한 JSON verdict를 반환한다.
그림: 레퍼런스 이미지 + 생성 스크린샷 → 대조 → JSON verdict(score·verdict·category_match·differences·suggestions·reasoning) → score≥90이면 pass, 미만이면 편집 후 재실행 반복. 픽셀 diff는 보조 디버그.
개념 한 줄
“이 화면이 레퍼런스와 얼마나 닮았는가”를 사람 대신 점수·판정으로 잘라 말해주는 시각 QA 스킬.
입력
| 입력 | 설명 |
|---|---|
reference_images[] | 비교 기준이 되는 레퍼런스 이미지 |
generated_screenshot | 현재 생성된 출력 스크린샷 |
category_hint(선택) | 화면 유형 힌트 |
출력(JSON only)
| 필드 | 내용 |
|---|---|
score | 0~100 정수 |
verdict | pass / revise / fail |
category_match | 레퍼런스와 같은 카테고리(화면 유형)인지 bool |
differences[] | 구체적인 시각 불일치 목록 |
suggestions[] | 다음 편집을 위한 제안 |
reasoning | 1~2문장 판정 근거 |
통과 기준과 반복
통과 임계는 90점 이상이다. 대략 90 이상이면 pass, 그 미만은 차이 정도에 따라 고칠 수 있으면 revise(편집 후 재판정), 방향 자체가 틀리면 fail로 갈린다. 90 미만이면 편집 후 /oh-my-claudecode:visual-verdict를 다시 실행하는 식으로 반복하며, 임계를 넘기 전까지는 시각 작업을 완료로 치지 않는다.
픽셀 diff는 보조일 뿐
pixelmatch 같은 픽셀 단위 diff 오버레이는 디버깅 보조 자료에 그치고, 최종 판단은 어디까지나 verdict가 내린다.
🔗 QA 자동화 파이프라인의 시각 검증 축이다. 텍스트·테스트로는 못 잡는 레이아웃·간격·타이포·색 차이를 정량적으로 판정한다. (참고: 이 노트에 들어간 SVG들도 브라우저로 렌더링해 육안으로 검증했는데, 그 판정 과정을 자동화·정량화한 것이 visual-verdict라고 볼 수 있다.)
한 줄 요약: visual-verdict = 스크린샷을 레퍼런스와 대조해 score·verdict·차이점·제안을 JSON으로 반환하는 OMC 스킬. 90점 미만이면 편집→재검증을 반복하며, 픽셀 diff는 보조일 뿐 최종 판정은 verdict가 담당한다.