Loop Engineering: AI 코딩에서 검증과 재시도를 시스템으로 설계하는 법

여러분, AI에게 코딩을 시키다 보면 사람이 계속 같은 말을 하게 되지 않나요.

• 테스트 돌려봐
• 에러 고쳐
• 로그 다시 확인해
• 아직 끝난 거 아니야
• 다른 방식으로 다시 해봐

처음에는 이 정도 반복이 자연스럽습니다. 사람이 방향을 주고, AI가 작업하고, 사람이 확인하고, 다시 지시하죠. 하지만 작업이 길어질수록 이 반복은 병목이 됩니다. 사람은 계속 확인해야 하고, AI는 매번 다음 행동을 기다립니다.

제가 말하고 싶은 건 이겁니다. Loop Engineering은 이 반복을 시스템 안으로 옮기는 관점입니다. 이름은 거창하지만 핵심은 단순합니다.

Goal -> Worker -> Verifier -> Feedback -> Retry -> Done

목표를 정하고, 작업자가 실행하고, 검증자가 확인하고, 피드백을 주고, 실패하면 다시 시도하고, 조건을 만족하면 멈춥니다.

결론부터 말하면, AI 코딩에서 중요한 건 이제 “AI가 코드를 잘 짜는가”만이 아닙니다. AI가 일하고, 검증하고, 실패를 반영하고, 적절한 시점에 멈추는 구조를 어떻게 설계할 것인가가 점점 중요해지고 있습니다.

사람이 하던 반복을 시스템으로 옮긴다

AI 코딩에서 사람이 자주 하는 일은 생각보다 정형화되어 있습니다.

코드를 작성하게 한 뒤 테스트를 돌리라고 합니다. 테스트가 실패하면 에러를 붙여주고 고치라고 하죠. 다시 로그를 확인하라고 하고, 문제가 해결되지 않으면 다른 접근을 시도하라고 합니다. 결과가 괜찮아 보이면 이제 완료라고 판단합니다.

이 흐름을 사람이 매번 직접 해도 됩니다. 하지만 반복 가능한 검증 기준이 있다면 시스템이 대신 돌릴 수 있죠.

예를 들어 프론트엔드 변경이라면 다음 루프가 가능합니다.

1. 화면 수정
2. 빌드 실행
3. Playwright로 주요 화면 확인
4. 스크린샷 비교
5. 깨진 레이아웃이 있으면 수정
6. 다시 확인
7. 기준을 만족하면 종료

백엔드 변경이라면 다른 루프가 됩니다.

1. 코드 수정
2. 타입 검사
3. 단위 테스트
4. 통합 테스트
5. 실패 로그 분석
6. 수정
7. 다시 테스트
8. 통과하면 종료

문서 작업도 루프가 될 수 있습니다.

1. 초안 작성
2. 톤과 독자 수준 검토
3. 중복 문장 제거
4. 제목과 메타 설명 점검
5. 링크 확인
6. 최종본 확정

핵심은 도메인마다 루프의 조건이 달라진다는 점입니다.

루프 자체보다 중요한 것은 루프의 조건이다

Loop Engineering에서 어려운 부분은 루프를 도는 것 자체가 아닙니다. 반복은 단순합니다. 어려운 건 어떤 조건으로 반복하고, 어떤 조건에서 멈출지를 정하는 일이죠.

제가 더 중요하게 보는 건 다음 질문들입니다.

• 무엇을 목표로 볼 것인가
• 누가 작업할 것인가
• 누가 검증할 것인가
• 실패하면 무엇을 바꿀 것인가
• 같은 실패가 반복되면 전략을 어떻게 바꿀 것인가
• 비용이 얼마나 커지면 멈출 것인가
• 어떤 상태가 되면 완료라고 볼 것인가

여기서 엔지니어링이 생깁니다.

단순히 “테스트가 통과할 때까지 고쳐”라고만 하면 위험합니다. 테스트가 잘못됐을 수도 있고, 에이전트가 같은 실수를 반복할 수도 있고, 비용이 끝없이 늘어날 수도 있거든요. 그래서 루프에는 종료 조건과 실패 처리 조건이 필요합니다.

좋은 루프는 무한 반복하지 않습니다. 실패를 보존하고, 실패 패턴을 관찰하고, 같은 실패가 반복되면 다른 전략을 선택하죠. 그래도 해결되지 않으면 사람에게 넘깁니다.

Worker와 Verifier를 분리한다

Loop Engineering에서 가장 중요한 분리는 Worker와 Verifier입니다.

Worker는 작업을 수행합니다. 코드를 작성하고, 문서를 고치고, 설정을 변경하죠. Verifier는 그 결과를 검증합니다. 테스트를 돌리고, 요구사항과 비교하고, 위험한 변경이 없는지 확인합니다.

두 역할을 같은 에이전트가 할 수도 있습니다. 하지만 복잡한 작업에서는 분리하는 편이 낫다고 봅니다. 작업자는 자기 결과를 좋게 보고 싶어 하는 경향이 있으니까요. 검증자는 더 비판적으로 봐야 합니다.

AI 코딩에서 자주 생기는 문제는 “코드는 만들어졌지만 진짜 끝난 것은 아닌” 상태입니다. 빌드는 안 돌렸거나, 테스트는 빠졌거나, 엣지 케이스는 확인하지 않았거나, UI가 깨졌는데 코드만 그럴듯한 경우가 있습니다.

Verifier는 이 지점을 잡아야 합니다.

검증자는 다음을 확인할 수 있습니다.

• 요구사항을 실제로 만족했는가
• 타입 검사와 테스트가 통과했는가
• 변경 범위가 요청보다 커지지 않았는가
• 보안, 권한, DB, 결제 같은 고위험 영역을 건드렸는가
• UI 변경이라면 모바일과 데스크톱에서 깨지지 않는가
• 문서라면 독자가 이해할 수 있는 흐름인가

Verifier가 실패를 보고하면 Worker는 그 피드백을 받아 다시 작업합니다. 이때 루프가 시작됩니다.

하네스 다이어트와 Loop Engineering의 관계

최근 AI 코딩에서 하네스를 줄여야 한다는 이야기를 자주 합니다. AGENTS.md, CLAUDE.md, Cursor Rules, Skills, MCP, Hooks를 계속 붙이기만 하면 어느 순간 안전장치가 아니라 마찰이 되기 때문이죠.

그렇다고 통제를 포기하자는 뜻은 아닙니다. 덜어낸 통제는 사라지는 게 아니라 위치가 바뀌어야 합니다.

예전 방식은 Always-on Harness에 가까웠습니다.

• 항상 계획하기
• 항상 문서 읽기
• 항상 테스트하기
• 항상 리뷰하기
• 항상 서브에이전트 쓰기

이 방식은 한때 효과가 있었습니다. 하지만 모든 작업이 같은 무게를 갖고 있지는 않죠. 문서 오탈자 수정과 인증 구조 변경은 다릅니다. 버튼 색상 수정과 결제 로직 변경도 다르고, 한 줄 버그 수정과 대규모 리팩토링도 다릅니다.

전역 하네스는 이 차이를 잘 구분하지 못합니다. 모든 작업을 같은 방식으로 통제하려고 하죠.

Loop Engineering은 이 문제를 다르게 봅니다. 모든 규칙을 앞단에 박아두는 대신, 작업이 진행되는 과정에서 필요한 통제를 호출합니다.

간단한 작업이면 가볍게 처리합니다. 복잡한 작업이면 계획을 세웁니다. 위험한 변경이면 verifier를 붙입니다. 맥락이 부족하면 필요한 문서만 읽습니다. 테스트가 실패하면 다시 수정합니다. 같은 실패가 반복되면 다른 전략을 시도합니다. 완료 조건이 충족되면 멈춥니다.

즉, 하네스 리팩토링의 목적은 단순히 가벼워지는 것이 아닙니다. 루프가 더 잘 돌게 만드는 것입니다.

Dynamic Workflow는 루프를 제품 안으로 넣는 방향이다

Claude Code의 Dynamic Workflows도 이 흐름과 연결해서 볼 수 있습니다. 사람이 모든 작업에 적용될 규칙을 미리 고정해두는 게 아니라, 작업의 크기와 위험도에 따라 필요한 workflow를 구성하는 방향이죠.

작업이 작으면 단순하게 갑니다. 작업이 크면 나누고, 검증이 필요하면 verifier agent를 붙입니다. 반복이 필요하면 loop를 돌리고요.

이런 방향은 앞으로 더 중요해질 가능성이 크다고 봅니다. AI 코딩 에이전트가 단순히 한 번 응답하고 끝나는 도구가 아니라, 여러 단계의 작업을 장시간 수행하는 실행 시스템으로 바뀌고 있기 때문입니다.

다만 Dynamic Workflow 같은 기능이 있다고 해서 모든 것을 자동화해야 하는 것은 아닙니다. 오히려 더 중요한 것은 루프의 경계입니다.

• 어디까지 자동으로 반복할 것인가
• 어떤 실패는 사람이 봐야 하는가
• 어떤 변경은 승인 전에는 적용하지 말아야 하는가
• 비용이 커지면 어디서 멈출 것인가
• 검증 기준은 코드로 확인 가능한가, 사람 판단이 필요한가

기능이 강해질수록 조건 설계가 더 중요해집니다.

실무에서 바로 쓸 수 있는 루프 설계법

Loop Engineering을 실무에 적용할 때는 거창한 시스템부터 만들 필요가 없습니다. 작은 루프부터 시작하면 되죠.

1. 목표를 명확히 쓴다

루프의 시작은 Goal입니다. 목표가 흐리면 Worker도 Verifier도 흔들립니다.

나쁜 목표는 이런 식입니다.

이 기능 개선해줘.

좋은 목표는 검증 가능한 상태를 포함합니다.

로그인 실패 시 사용자가 원인을 이해할 수 있도록 에러 메시지를 개선하고,
기존 로그인 성공/실패 테스트가 모두 통과해야 한다.

목표 안에 완료 조건이 들어가야 루프가 멈출 수 있습니다.

2. Worker에게 변경 범위를 제한한다

작업자가 무엇이든 마음대로 바꾸게 하면 루프가 커집니다. 변경 가능한 파일, 건드리면 안 되는 영역, 우선순위를 지정해야 합니다.

예를 들어 다음처럼 줄 수 있습니다.

로그인 폼 컴포넌트와 관련 테스트만 수정한다.
인증 API, DB schema, 세션 정책은 변경하지 않는다.

범위 제한은 루프 비용을 줄이는 가장 강력한 방법입니다.

3. Verifier 기준을 코드로 표현한다

가능하면 검증 기준은 명령으로 표현해야 합니다.

bun run build
bun test auth

UI라면 Playwright, screenshot, 접근성 검사 같은 기준을 붙일 수 있습니다. 문서라면 링크 검사, frontmatter 검사, 금지 문구 검사처럼 일부를 자동화할 수 있습니다.

중요한 건 Verifier가 단순히 “괜찮아 보입니다”라고 말하지 않게 만드는 겁니다. 가능한 한 관찰 가능한 근거를 줘야 하죠.

4. Retry 조건을 정한다

실패하면 무조건 다시 하게 만들면 안 됩니다. 어떤 실패는 같은 방식으로 다시 해도 해결되지 않습니다.

예를 들어 이렇게 정할 수 있습니다.

같은 테스트가 2번 연속 실패하면 구현 전략을 바꾼다.
3번 연속 실패하면 멈추고 원인과 선택지를 보고한다.

이 조건이 없으면 루프는 쉽게 무한 반복이 됩니다.

5. Done 조건을 명확히 한다

완료 조건은 “코드를 수정했다”가 아닙니다.

완료 조건은 보통 이런 형태가 되어야 합니다.

• 요청한 요구사항을 만족했다
• 변경 범위가 벗어나지 않았다
• 지정한 검증이 통과했다
• 실패하거나 생략한 검증을 명확히 보고했다
• 남은 리스크를 설명했다

Done은 작업자의 선언이 아니라 검증 가능한 상태입니다.

작은 작업에는 작은 루프가 필요하다

Loop Engineering을 말하면 대규모 자동화 시스템을 떠올리기 쉽지만, 실제로는 작은 작업일수록 루프 크기를 잘 조절해야 합니다.

문서 오탈자 수정에 대규모 verifier agent를 붙일 필요는 없죠. 간단한 CSS 수정에 복잡한 계획 문서를 만들 필요도 없고요. 반대로 결제 로직, 인증 구조, DB 마이그레이션, 운영 배포처럼 실패 비용이 큰 작업은 가벼운 루프로 처리하면 안 됩니다.

좋은 루프는 작업의 무게를 반영합니다.

작업 유형	적절한 루프
오탈자, 단순 문서 수정	수정 -> diff 확인 -> 완료
작은 UI 수정	수정 -> 빌드 -> 화면 확인 -> 완료
기능 구현	계획 -> 구현 -> 테스트 -> verifier -> 수정 -> 완료
보안/권한/DB 변경	계획 승인 -> 구현 -> 테스트 -> 독립 검증 -> 사람 승인 -> 완료
장기 리팩토링	작업 분할 -> 반복 구현 -> 검증 -> 기록 -> 다음 루프

모든 작업에 같은 루프를 적용하면 다시 Always-on Harness로 돌아갑니다. Loop Engineering의 핵심은 반복을 만드는 게 아니라, 반복의 크기와 조건을 설계하는 거죠.

마무리

앞으로 AI 코딩에서 중요한 질문은 “어떤 규칙을 더 추가할까?”가 아닐 수 있습니다.

오히려 이렇게 물어야 한다고 봅니다.

이 규칙은 항상 필요한가? 아니면 루프 안에서 필요할 때만 작동하면 되는가?

정적인 하네스를 줄이고, 필요한 통제를 루프 안으로 옮기고, 검증과 재시도와 종료 조건을 설계하는 것. 제가 말하고 싶은 Loop Engineering의 핵심이 바로 이겁니다.

AI에게 일을 시키는 시대에서, AI가 일하는 과정을 설계하는 시대로 넘어가고 있습니다. 그 과정의 중심에는 더 긴 프롬프트가 아니라 더 잘 설계된 루프가 있다고 생각합니다.