결론부터 말하면, 지금 시스템은 이미 거의 다 만들어져 있고 명령 6개만 새로 얹으면 됩니다. Loopy(루피)는 Claude Code에서 '스스로 고치는 자동 개선 루프'를 돌리는 명령 묶음입니다. 'V2' 문서는 사용자가 외워야 할 명령을 6개(/loopy:start, auto, resume, status, history, measure)로 줄이자고 제안합니다. 이 글은 그 6개 중, 실제 작업을 하는 내부 기계(loopy-era 엔진)가 이미 갖춘 것과 아직 없는 것을 나누고, 가장 적은 비용으로 채우는 단계별 계획을 정리합니다.
이 문서의 요구는 간단합니다. 엔진(속에서 실제로 일하는 기계)을 다시 만들자는 게 아니라, 사용자가 보는 명령만 다시 정리하자는 것입니다. init-project, team, qa-scenario-gen, qa-cycle, self-improve, eval 이 여섯 개 내부 단계는 전부 뒤로 숨깁니다. 사용자는 /loopy: 라는 공통 이름표가 붙은 표면 명령 6개만 외우면 됩니다.
| 표면 명령 | 내부 매핑 | 사용 시점 |
|---|---|---|
/loopy:start | init-project + team + qa-scenario-gen | 설치할 때 한 번 |
/loopy:auto | qa-cycle + self-improve + eval + keep/discard | 평소에 돌릴 때 |
/loopy:resume | 중단된 진행 상태를 다시 불러와 auto로 이어감 | 중단 복구 |
/loopy:status | metric parse + latest state | 수시 확인 |
/loopy:history | 그동안 쌓인 결과 기록과 발견 내용의 변화 | 끝난 뒤 검토 |
/loopy:measure | 측정만 함 (파일은 안 바꿈) | 진단 |
start → auto → resume, 즉 '시작하고 → 자동으로 돌리고 → 이어서 하기'처럼요. 속 단계가 바뀌어도 사용자가 쓰는 명령(표면)은 그대로라 안정적입니다.| 표면 명령 | 지금 상태 | 엔진 완성도 | 남은 일 |
|---|---|---|---|
/loopy:start |
없음 | 일부 (필요한 개별 명령은 이미 있음) | init-project → team → qa-scenario-gen을 순서대로 실행하는 여러 단계를 순서대로 실행하는 묶음 명령 필요 |
/loopy:auto |
없음 | 일부 (측정 명령 안에 이미 있음) | qa-cycle → self-improve → loopy-era-eval을 스스로 반복하는 순환(폐루프)으로 묶는 여러 단계를 순서대로 실행하는 묶음 명령 필요 |
/loopy:resume |
있음 | 완성됨 | /loopy-era-eval resume 별칭만 추가 |
/loopy:status |
있음 | 완성됨 | /loopy-era-eval status 별칭만 추가 |
/loopy:history |
있음 | 완성됨 | /loopy-era-eval history 별칭만 추가 |
/loopy:measure |
있음 | 완성됨 | /loopy-era-eval measure 별칭만 추가 |
init-project → team Phase 0~2 → qa-scenario-gen을 순서대로 실행하는 하나의 명령입니다. 이렇게 여러 단계를 순서대로 불러 묶는 것을 '오케스트레이션'이라고 합니다. 중간에 어느 단계든 실패하면 멈추고 자세한 기록을 남깁니다. 이미 team/SKILL.md가 맨 처음 단계에서 init-project를 불러오도록 연결돼 있어서, 그대로 하나로 묶기만 하면 됩니다.~/.claude/skills/loopy-start/SKILL.md (새 파일, 약 60줄)qa-cycle → self-improve → loopy-era-eval을 한 바퀴로 묶어 계속 반복하는 명령입니다. 한 바퀴 돌 때마다 '반드시 통과해야 하는 강제 검사'의 통과 비율(HARD 비율)을 기록하고, 더 이상 좋아지지 않으면(수렴) 멈춥니다. $ARGUMENTS로 최대 반복 횟수를 정합니다 (예:/loopy:auto 30은 30번까지). 속으로는 이미 /loopy-era-eval N이 있으므로, 이건 그 위에 씌우는 얇은 껍데기 명령일 뿐입니다.~/.claude/skills/loopy-auto/SKILL.md (새 파일, 약 80줄)/loopy:resume, /loopy:status, /loopy:history, /loopy:measure는 전부 /loopy-era-eval에 이미 들어 있는 기능입니다. Claude Code는 명령 앞에 공통 이름표(네임스페이스)를 붙이는 걸 지원합니다. 그래서 기존 기능을 가리키는 새 이름, 즉 별칭 파일 4개만 만들면 됩니다.~/.claude/commands/loopy-{resume,status,history,measure}.md (각 약 15줄)~/.claude/skills/loopy-era-eval/README.md (새 파일, 약 40줄)/init-project, /team 등은 내부용이지만, 문제를 뜯어볼 때를 위해 그대로 둡니다. 다만 안내 문서에는 '내부 전용'이라고 적어, 보통 사용자가 직접 부르지 않게 안내합니다. 지우지는 않습니다 — V2 문서도 둘을 함께 두는 것을 전제로 합니다.measure는 파일을 절대 고치지 않고 상태만 재야 합니다. 지금 /loopy-era-eval measure가 정말로 파일을 하나도 안 바꾸는지(코드 변경이 0인지) 확인하는 테스트를 추가합니다.~/.claude/logs/loopy-era-eval-results.tsv에 '측정만 하는지' 검증 항목 추가status 명령은 강제 검사 비율만 알려주므로, 나머지 세 가지(권고 검사 수·대기 항목·가장 최근 반복)를 더합니다.loopy-era-eval/SKILL.md 1단계 부분 확장 (약 20줄 추가)/loopy:resume, /loopy:status, /loopy:history, /loopy:measure 별칭 4개를 ~/.claude/commands/폴더에 만듭니다. 각 파일은 15줄이 안 됩니다. 기존 엔진을 그대로 부르기만 하므로, 멀쩡하던 게 깨질 위험(회귀)이 없습니다.
/loopy-era-eval resume 호출/loopy-era-eval status 호출/loopy-era-eval history 호출/loopy-era-eval measure 호출/loopy:start와 /loopy:auto 두 개의 묶음 명령을 만듭니다. 이 둘은 단순 별칭이 아니라 여러 명령을 순서대로 불러 실행하므로, 각 단계의 실패 처리와 진행 상황 기록이 필요합니다. V2 문서 4장의 '내부 매핑 규칙' 표를 그대로 구현합니다.
measure 가 파일을 안 바꾸는지 검증하고, status 출력 형식을 넓힙니다. V2 문서 5·6장의 이름 짓기·사용성 규칙을 마지막에 적용합니다.
| 위험 | 영향 | 대응 |
|---|---|---|
| 묶음이 실패하면 원인 찾기가 어려움 | 중 | /loopy:auto 가 실패하면 어느 내부 단계에서 멈췄는지 기록에 남깁니다. 필요하면 /qa-cycle 같은 개별 명령을 직접 부르는 길도 그대로 열어 둡니다. |
| 기존 사용자가 새 방식으로 옮길 때 혼란 | 낮음 | 지우지 않고 함께 둡니다. 기존 /loopy-era-eval도 그대로 작동합니다. 안내 문서에 어떤 새 명령이 어떤 기존 명령인지 대응표를 넣습니다. |
| 덧씌운 층을 관리하는 부담 | 낮음 | 별칭 4개는 각 15줄짜리 파일이고, 묶음 명령 2개는 각 약 70줄입니다. 전체 관리 부담은 약 200줄로 고정입니다. |
| V2 문서와 기존 측정 기준이 안 맞을 위험 | 중 | V2 문서 4장이 기존 측정 명령(loopy-era-eval)을 그대로 부르도록 정해 두었습니다. 그래서 지금의 강제 검사 비율(HARD 비율) 엔진과 완벽히 호환됩니다. 새로 만드는 묶음 명령도 속으로는 이 엔진을 부릅니다. |
이 문서의 핵심은 세 가지 사용성 원칙입니다 — 외우기 쉬울 것, 이름만 봐도 짐작될 것, 복잡한 내부 단계는 감출 것. 이 세 가지를 만족하는 표면 명령층을 지금 엔진 위에 얹으면, 문제를 뜯어보는 유연함은 그대로 두면서 자주 안 쓰는 사용자도 쉽게 다시 꺼내 쓸 수 있습니다. 제안한 3단계 계획은 이 전환을 멀쩡하던 것을 깨뜨릴 위험 없이 해내는 가장 빠른 길입니다.