AI 에이전트 루프, 오래 돌리는 것보다 종료 조건이 먼저예요

AI 에이전트 루프, 오래 돌리는 것보다 종료 조건이 먼저예요

AI 뉴스 썸네일

AI 코딩 도구에 일을 반복해서 맡기려면 먼저 "언제 끝났다고 볼지"를 숫자와 규칙으로 정해야 해요. Addy Osmani가 소개한 실전 루프 엔지니어링은 `/goal`과 `/loop`의 차이, 독립적인 결과 확인, 사람이 직접 판단해야 할 영역을 구체적인 사례로 설명해요. 2

핵심 요약

구분	핵심	실제 적용 포인트
목표 기반 루프	`/goal`은 확인 가능한 완료 조건이 충족될 때까지 다음 작업을 이어가요	테스트 통과 수, Lighthouse 점수, LCP처럼 결과를 수치로 확인할 수 있어야 해요
시간 기반 루프	`/loop` 명령은 정해진 간격마다 같은 작업을 다시 실행해요	CI 상태, 새 이슈, 로그처럼 외부 상태가 달라지는 업무에 맞아요
중단 조건	최대 반복 횟수와 개선 정체 기준을 함께 정해요	같은 시도를 되풀이하거나 지표가 나빠지면 자동으로 멈추게 해야 해요
사람의 역할	구현과 반복은 맡길 수 있지만 제품 취향과 위험 판단은 사람이 맡아요	인증, 보안, 금융, 사용자 경험은 코드와 결과를 직접 확인해야 해요

1. 측정 가능한 완료 조건이 루프의 출발점이에요

루프 엔지니어링은 AI 에이전트가 변경하고 결과를 확인한 뒤 접근 방식을 조정하는 과정을 반복하는 방법이에요. 반복 횟수를 늘리는 기능만 켜서는 안정적인 결과를 얻기 어려워요. 작업 범위, 성공 기준, 금지할 변경, 최대 시도 횟수를 함께 적어야 해요. 1

Claude Code의 `/goal`은 사용자가 정한 조건을 별도 평가 모델이 매 작업 뒤 확인하는 방식이에요. 조건이 아직 충족되지 않았다면 다음 작업을 시작하고, 조건을 달성했거나 더는 달성할 수 없다고 판단하면 멈춰요. 공식 문서도 컴파일 성공, 테스트 통과, 파일 크기 제한, 이슈 대기열 소진처럼 결과를 확인할 수 있는 작업을 적합한 예로 들어요. 3

예를 들어 "페이지를 빠르게 만들어 줘"보다 "Lighthouse 성능 점수 92 이상, LCP 1.8초 미만, 공개 API 변경 금지, 최대 10회"가 훨씬 안전해요. 지표가 두 번 연속 나아지지 않으면 중단한다는 조건도 넣을 수 있어요. 이렇게 정하면 에이전트가 막연한 만족도를 추측하지 않고 남은 조건을 기준으로 다음 행동을 고를 수 있어요.

728x90

평가 모델이 코드 리뷰를 대신하지는 못해요

`/goal`의 평가 모델은 대화 기록에 나타난 조건 충족 여부를 확인해요. 파일을 독립적으로 읽거나 명령을 직접 실행해 구현 품질을 판정하는 코드 검토자는 아니에요. 테스트 결과가 기록에 남아 있으면 통과 여부를 확인할 수 있지만, 설계가 적절한지와 모바일 사용성이 좋은지까지 보장하지는 못해요. 3

작업을 만든 주체와 결과를 확인하는 주체를 분리하면 놓친 조건을 찾기 쉬워요. 첫 번째 에이전트가 데스크톱 성능만 확인했다면 두 번째 확인 과정에서 모바일 성능이나 콘솔 오류를 다시 볼 수 있어요. 그래도 제품 기준을 충족하는지에 대한 최종 판단은 담당자가 해야 해요.

`/loop` 명령은 외부 상태가 바뀌는 업무에 맞아요

`/loop` 명령은 일정한 간격으로 같은 작업을 다시 실행하는 기능이에요. 새 GitHub 이슈 확인, PR 리뷰 반영, 실패한 CI 재확인, 로그 감시처럼 입력이나 외부 상태가 시간에 따라 달라지는 업무에 잘 맞아요. 로컬에서 실행하는 루프는 컴퓨터나 세션이 종료되면 함께 멈출 수 있으므로, 더 오래 유지할 작업은 실행 위치와 수명도 따로 정해야 해요. 4

`/loop` 명령이 문제를 찾고 `/goal` 명령이 제한된 범위에서 해결을 반복하도록 연결할 수도 있어요. 다만 하나의 목표에 이슈 분류, 구현, 리뷰, 배포까지 모두 넣으면 실패 지점을 찾기 어려워져요. 발견, 수정, 확인을 작은 단계로 나누고 각 단계에 별도 종료 조건을 두는 편이 관리하기 쉬워요.

왜 중요한가요

AI 코딩 도구의 작업 시간이 길어질수록 잘못된 방향으로 반복할 비용도 함께 커져요. 테스트 개수와 성능 점수만 올리다가 유지보수성이 떨어지거나 사용자에게 불필요한 복잡성을 더할 수도 있어요. Addy Osmani도 경쟁 제품 조사와 구현을 맡긴 뒤 변경을 거의 반영할 뻔했지만, 직접 코드를 다시 보고 얻는 이익보다 복잡성이 크다고 판단해 중단했어요. 2

팀에서 첫 루프를 고를 때는 매일 손으로 확인하는 반복 업무부터 시작하는 편이 현실적이에요. 새 이슈 분류나 CI 상태 확인처럼 입력과 완료 기준이 분명한 업무가 좋은 후보예요. 반대로 "UI가 더 좋아질 때까지"처럼 취향에 따라 답이 달라지는 목표는 사람이 평가 기준을 먼저 만들지 못하면 반복 실행에 맡기기 어려워요.

운영 전에는 다섯 가지를 적어 두면 좋아요. 무엇을 바꿀 수 있는지, 어떤 수치로 완료를 확인할지, 몇 번까지 시도할지, 어느 상황에서 즉시 멈출지, 마지막 결정을 누가 내릴지예요. 이 항목이 비어 있다면 반복 실행 횟수를 늘리기보다 작업 범위를 다시 줄이는 편이 안전해요. 1

참고 자료

1. 실전 루프 엔지니어링 — GeekNews
2. Practical Loop Engineering — Addy Osmani, Elevate
3. Keep Claude working toward a goal — Claude Code Docs
4. Run prompts on a schedule — Claude Code Docs