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