서론

어느 날, 업무로 다루고 있는 Rails의 API 서버에서 테스트의 branch 커버리지(조건 분기가 얼마나 테스트를 통과하고 있는지)를 목표치까지 AI를 사용하여 대폭 끌어올리는 태스크를 맡게 되었습니다. 이런 종류의 작업은 본질적으로 반복 작업입니다. 현황을 측정하고, 가장 취약한 부분을 찾아내고, 테스트를 추가하고, 다시 측정한다. 이를 대상 파일의 수만큼, 때로는 수십 번 반복하게 됩니다.

이런 태스크를 AI 에이전트에게 맡기려고 하면, 방법은 크게 두 가지로 나뉩니다. 하나는 "전부 다 해줘"라고 일괄적으로 던지는 방법, 다른 하나는 "1건 해줘", "다음은 이거"라고 매번 지시하는 방법입니다. 전자는 반복 횟수가 늘어날수록 도중에 무너지기 쉽고, 후자는 인간이 계속 붙어 있어야 합니다.

Claude Code의 /loop 명령어는 이 중간을 메우는 하네스(Harness)로서 매우 잘 만들어져 있다고 느꼈습니다. 이 기사에서는 실제로 테스트 커버리지 개선에 사용해 본 예를 곁들여, /loop를 사용한 반복 작업의 설계 패턴을 소개합니다.

대상 독자

• Claude Code(또는 AI 코딩 에이전트 전반)로 개발하고 계신 분
• "비슷한 작업을 수십 건 반복하는" 태스크를 AI에게 맡기고 싶은 분
• 반복적인 자동화 태스크의 진척 관리 및 정지 조건 설계에 관심이 있는 분
• 거대한 일괄 프롬프트로 힘으로 밀어붙이다가 도중에 무너진 경험이 있는 분

다루지 않는 내용

• Claude Code 자체의 셋업 방법
• /loop 명령어의 내부 구현 그 자체
• RSpec/SimpleCov의 사용법 그 자체 (실례로 등장하지만 주된 주제는 아닙니다)

/loop 명령어를 사용하기에 적합한 태스크

"같은 형태의 태스크를 N회 수행한다"는 작업은, 일괄 프롬프트로 "전부 다 해줘"라고 던지면 반복 횟수가 늘어날수록 문맥(Context)이 파탄 나기 쉽고, 그렇다고 건마다 인간이 지시를 내리면 인력이 병목이 됩니다. /loop가 적합한 태스크에는 몇 가지 공통점이 있습니다.

• 같은 형태의 작업을 독립된 단위로 여러 번 반복한다
• 진척도를 객관적인 명령어 출력으로 판단할 수 있다 (감각적인 판단에 의존하지 않는다)
• 하나의 단위 작업이 다른 단위의 결과에 강하게 의존하지 않는다
• 종료 방식이 명확하다 (임계값, 건수, 상한 중 하나로 판정할 수 있다)

반대로, 전체를 조망한 단 한 번의 설계 판단이 필요한 태스크나, 완료 기준을 주관적으로만 정할 수 있는 태스크에는 적합하지 않습니다.

/loop라는 하네스

해결책: /loop가 뛰어난 점은 "전부 다 해줘"가 아니라 "1회 분량의 절차"를 전달하는 설계로 되어 있다는 점입니다. 1회는 다음과 같은 형태로 분해할 수 있습니다.

• 측정: 현황을 객관적으로 확인한다 (애매한 감각이 아니라, 명령어 출력으로 판단할 수 있는 형태)
• 대상 선정: 다음에 착수할 대상을 포함 조건 및 제외 조건에 따라 선택한다
• 실시: 해당 대상에만 집중하여 작업한다
• 재측정: 작업 결과를 동일한 방법으로 다시 측정한다
• 커밋: 해당 회차의 차분(Diff)을 기록한다
• 계속 판정: 미리 정해둔 정지 조건에 비추어 계속할지 끝낼지를 결정한다

이때 중요한 것은, 각 회차가 과거 대화의 기억이 아니라, 그때마다의 재측정으로부터 상태를 다시 구축한다는 점입니다. 이전 회차에서 무엇을 했는지 정확히 기억하지 못하더라도, 현황을 다시 측정하면 다음에 무엇을 해야 할지가 결정됩니다. 그렇기 때문에 대화의 요약이나 압축을 거쳐도 잘 무너지지 않으며, 수십 회에 걸친 장시간의 반복을 견딜 수 있습니다.

구체적인 예시: 테스트 커버리지 개선에 사용해 보았다

실제로 수행한 것은 Rails 프로젝트의 branch 커버리지를 80%까지 끌어올리는 작업입니다. 프롬프트의 골자는 커버리지 측정 명령어를 실행하고, 미커버 분기가 가장 많은 파일을 선택하여, 테스트를 추가하고, 재측정하는 것입니다. 상한 회수와 목표 도달 여부를 함께 정지 조건으로 설정했습니다.

처음에 특정 디렉토리 하나만을 대상으로 돌려본 결과, 예상했던 목표에 상당히 가까운 곳까지 그리 큰 수고를 들이지 않고(시간은 걸렸지만) 도달할 수 있었습니다. 반복 작업을 에이전트에게 맡기는 느낌으로서는 상당히 좋은 결과였습니다.

이 "측정 $\rightarrow$ 가장 취약한 곳에 집중하여 대응 $\rightarrow$ 재측정"이라는 루프의 형태는 loops.elorm.xyz라는 사이트에 있는 coverage-until-threshold...

라는 루프 레시피를 참고하여 구현했습니다. 원래는 Node.js/npm 에코시스템(Ecosystem)을 위해 작성된 것이지만, 사고방식 자체는 언어나 툴체인(Toolchain)에 관계없이 유용하게 사용할 수 있습니다. 이번에는 이를 RSpec + Docker 환경에 맞춰 번역하는 형태로 사용했습니다. /loop를 사용하기 시작한다면, 이 사이트에 나열된 다른 레시피들도 살펴보는 것을 추천합니다.

중요한 설계 원칙

• 【 체크 커맨드는 "본방 상당"의 조건으로 측정한다 】 /loop는 일단 실행하면 매 회차마다 인간이 확인하는 것이 아니라, 수십 회차를 자율적으로 계속 회전합니다. 체크 커맨드 자체의 측정 방식이 어긋나 있더라도, 루프는 그것을 스스로 감지할 수 없습니다. 그렇기에 루프를 본격적으로 실행하기 전에, 체크 커맨드가 정말로 본방 상당의 조건을 재현하고 있는지 딱 한 번만 수동으로 검증해 두는 것이 가치가 높다고 느낍니다. 사전 검증에 드는 비용은 몇 분이지만, 이를 소홀히 하여 수십 회차를 실행해 버리면 쌓여온 "진척"을 모두 신뢰할 수 없게 되어 나중에 다시 작업해야 합니다.
• 【 정지 조건은 여러 개를 준비하고 우선순위를 정한다 】 단일 임계값(Threshold)에만 의존하면, 그 임계값을 측정하는 방식에 문제가 생겼을 때 알아차릴 수 없습니다. "목표 도달", "대상 재고 없음", "상한 횟수"와 같이 여러 조건을 조합해 두면, 어떤 이유로 멈췄는지가 항상 명확해집니다.
• 【 매 회차마다 커밋하여 체크포인트를 만든다 】 예를 들어 작게 검증된 단위로 커밋해 두면, 중간에 멈추더라도 성과가 남아서 어디서든 안전하게 재개 및 검증할 수 있습니다. 루프(Loop) 단위에 따라 이는 달라집니다. 예를 들어, 태스크를 수행하는 루프라면 구현부터 PR(Pull Request) 생성 및 머지(Merge)까지를 하나의 단위로 할 수도 있습니다.
• 【 체크 커맨드 자체의 개변을 금지한다 】 체크 방법이나 스킵(Skip)·무효화를 허용하게 되면, 달성하는 것 자체가 목적이 된 에이전트(Agent)에게 가장 손을 뻗기 쉬운 지름길이 됩니다. 이 부분을 명시적으로 금지해 두는 것이 자기 보고를 신뢰할 수 있는 최소한의 담보가 됩니다.
• 【 매 회차의 실제 작업은 저렴한 모델에 맡기고, 판단은 오케스트레이터 측의 고성능 모델에 남긴다 】 한 회차 분량의 구현 작업 자체는 동일한 패턴의 반복이며 난이도도 그리 높지 않습니다. 이 부분을 저렴한 모델에 맡기고, 대상 선정이나 정지 판정과 같은 "생각하는" 부분만 상위의 고성능 모델에 남기도록 지시해 두면, 정밀도를 떨어뜨리지 않으면서 실행 비용을 크게 억제할 수 있습니다.

응용: 커버리지 이외의 유스케이스

이 유형은 "같은 형태의 작업을 독립된 단위로 수십 건 수행하는" 태스크라면 기본적으로 유용하게 사용할 수 있습니다.

예를 들어 프로토타입 앱을 속도 중시로 개발하고 싶은 프로젝트에서, 개발 태스크를 하나의 문서로 일괄 관리하고 각각이 정해진 상태(미착수 → 준비 완료 → 대응 중 → 완료와 같은 전이)를 거쳐 완료되는 운용을 하고 있다고 가정해 봅시다. 이 태스크 목록을 /loop에 전달하여, "미착수 태스크를 1건 가져오기 → 구현하기 → 풀 리퀘스트(Pull Request) 만들기 → 다음 태스크로"라는 사이클을 돌리는 방식도 같은 사고방식의 연장선에 있습니다. 커버리지의 예와 마찬가지로, 측정(태스크 목록 확인) → 대상 선정(착수 가능한 것만으로 압축) → 실시 → 재측정 → 커밋이라는 구조가 그대로 적용됩니다.

그 외에도 대량의 번역 문구 채우기, 린트(Lint) 규칙을 파일 단위로 단계적 적용하는 작업, 유사한 구조의 파일군을 새로운 패턴으로 이행하는 작업 등, "동종의 작업을 독립된 단위로 수십~수백 건 수행하는" 장면 전반에서 응용할 수 있다고 느낍니다.

요약

• /loop는 "같은 작업을 수십 번 반복하는" 태스크에 적합한 하네스(Harness)이며, 매 회차를 재측정부터 다시 구성하는 설계로 함으로써 장시간의 반복을 견딜 수 있습니다.
• 체크 커맨드가 본방 상당의 조건을 재현하고 있는지가 루프의 신뢰성을 좌우하는 분수령이 됩니다.
• 테스트 커버리지에 국한되지 않고, 프로토타입 앱의 태스크 백로그(Backlog) 소화와 같이 "동종의 작업을 수십 건 수행하는" 장면 전반에 응용할 수 있습니다.

지루한 반복 작업이야말로 설계만 잘 갖춰 놓는다면 안심하고 AI에게 점점 위임해야 할 것이라고 생각하므로, 유효한 하나의 기술로서 활용해 나갑시다!

Discussion