자기수정 에이전트 루프는 “AI가 코드를 고치고, 테스트를 돌리고, 실패 로그를 읽고, 다시 수정하는 흐름”으로 만들 수 있습니다. 다만 핵심은 더 똑똑한 프롬프트가 아니라 반복 횟수 제한, 테스트 게이트, 변경 diff 검토였습니다.
실패 테스트 1개를 골라 3회 제한 루프부터 만들어보세요. 거창한 에이전트 프레임워크보다 작게 검증되는 자동화가 먼저입니다.
이번 기록은 Claude Code, Cursor, pytest, Git worktree를 조합해 작은 기능 수정 자동화를 구성한 셋업입니다. 완전 자율 개발자가 아니라, 사람이 승인할 수 있는 범위 안에서 귀찮은 수정-검증 사이클을 줄이는 쪽에 가깝습니다.
기존 프로젝트에서 실패하는 테스트 1개를 고른 뒤, 아래 루프 구조만 복사해 3회 반복으로 먼저 실행해보세요.
실제로 만든 루프의 뼈대
처음에는 “에이전트에게 알아서 고치게 하자”에 가까웠습니다. 결과는 빠르게 지저분해졌습니다. 테스트와 무관한 파일을 건드리거나, 로그를 제대로 읽지 않고 추측성 수정을 반복했습니다.
그래서 루프를 네 단계로 쪼갰습니다. 입력은 이슈 설명이 아니라 실패한 테스트 로그로 제한했고, 출력은 코드 전체가 아니라 patch diff로 받았습니다.
1) 관찰: 로그와 목표를 작게 준다
Claude Code에 전체 저장소를 열어주되, 프롬프트는 짧게 고정했습니다. “이 테스트를 통과시키되 공개 API를 바꾸지 말 것, 변경 이유를 diff 아래에 적을 것” 정도입니다. Cursor는 사람이 빠르게 diff를 읽고 되돌릴 때 편했습니다.
2) 수정: 한 번에 한 가지만 바꾸게 한다
에이전트가 여러 파일을 동시에 크게 바꾸면 실패 원인을 추적하기 어렵습니다. 그래서 한 루프당 변경 파일 수를 3개 이하로 제한했습니다. 실제로 이 제한 하나만으로 검토 시간이 꽤 줄었습니다.
3) 검증: pytest와 타입 체크를 강제한다
수정 후에는 pytest tests/test_target.py -q처럼 좁은 테스트부터 돌리고, 통과하면 전체 테스트로 확장했습니다. Python 프로젝트라면 uv, Node.js라면 pnpm test처럼 프로젝트 표준 명령을 그대로 쓰는 편이 좋습니다.
4) 중단: 3~5회 안에 못 고치면 사람에게 넘긴다
가장 중요한 장치는 중단 조건이었습니다. 5회 이상 같은 실패가 반복되면 에이전트는 새로운 근거 없이 코드를 흔들 가능성이 커졌습니다. 이때는 “현재까지의 가설, 시도한 변경, 남은 의심 지점”만 요약하게 하고 사람이 이어받는 방식이 안전했습니다.
Claude Code, Cursor, GitHub Actions를 어떻게 나눠 썼나
한 도구로 끝내려고 하면 오히려 답답했습니다. 에이전트 루프는 역할을 나눴을 때 안정적입니다. 로컬에서는 Claude Code가 로그를 읽고 패치를 만들고, Cursor는 사람이 검토하는 편집기 역할을 했습니다. GitHub Actions는 최종 검증용으로만 두었습니다.
| 구성 요소 | 맡긴 일 | 좋았던 점 | 주의할 점 |
|---|---|---|---|
| Claude Code | 로그 분석, 코드 수정, 반복 실행 | 터미널 맥락을 이어가며 패치 제안이 빠름 | 권한을 넓게 주면 불필요한 파일까지 수정할 수 있음 |
| Cursor | diff 검토, 수동 리팩터링 | 변경 의도를 읽고 되돌리기 쉬움 | 자동완성 제안을 무심코 섞으면 원인 추적이 흐려짐 |
| pytest / Playwright | 정답 판정 | AI 판단보다 재현 가능한 기준이 됨 | 테스트가 부실하면 루프도 부실해짐 |
| Git worktree | 실험 브랜치 격리 | 망가져도 원본 브랜치 보호 | 환경 변수와 캐시 경로를 분리해야 함 |
| GitHub Actions | PR 단위 최종 확인 | 로컬에서 놓친 환경 차이를 잡음 | 매 반복마다 돌리면 비용과 시간이 커짐 |
가상의 예시: 깨진 API 응답 테스트 고치기
예를 들어 FastAPI 프로젝트에서 /api/tasks 응답 필드명이 바뀌어 테스트가 실패했다고 가정해보겠습니다. 사람이라면 로그를 보고 스키마, 라우터, 테스트 중 어디가 기준인지 확인합니다. 에이전트에게도 같은 순서를 강제해야 합니다.
프롬프트는 이렇게 줄 수 있습니다.
실패 로그를 읽고 원인을 한 문단으로 설명한 뒤, tests/test_tasks.py를 통과시키는 최소 변경만 제안해. 공개 응답 필드는 기존 문서를 기준으로 유지하고, 변경 파일은 3개 이하로 제한해.
첫 루프에서 스키마를 고치고 테스트가 통과하면 끝입니다. 실패하면 두 번째 루프에서는 직전 diff와 새 로그만 보여줍니다. 여기서 중요한 점은 “처음부터 전체 리팩터링을 허용하지 않는 것”입니다.
누구에게 추천하고, 누구에게는 아직 이른가
추천하는 경우
이미 테스트가 있고, 반복적으로 깨지는 작은 버그를 자주 고치는 개발자에게 잘 맞습니다. SaaS 사이드 프로젝트, 내부 자동화 도구, 크롤러 유지보수처럼 변경 범위가 좁은 작업에서 특히 체감이 큽니다.
조금 더 준비가 필요한 경우
테스트가 거의 없거나, 요구사항이 자주 바뀌는 신규 기능 설계 단계라면 먼저 테스트 기준을 세우는 편이 낫습니다. 자기수정 루프는 정답지가 있을 때 강해지고, 정답지가 없으면 그럴듯한 추측을 빠르게 쌓습니다.
직접 막혔던 지점: “성공 로그”를 너무 믿으면 안 된다
테스트가 통과해도 기능이 맞다는 뜻은 아닙니다. 한 번은 대상 테스트만 통과했지만 주변 케이스가 깨질 수 있는 형태의 수정이 나왔습니다. 그래서 좁은 테스트 통과 후에는 관련 테스트 묶음, 마지막에는 전체 테스트를 돌리는 3단계 검증이 필요했습니다.
또 하나는 비용입니다. 에이전트가 로그를 매번 길게 읽으면 토큰 사용량이 늘어납니다. 실패 로그를 파일로 저장하고, 마지막 100~200줄만 넘기는 방식이 실용적이었습니다.
바로 적용할 최소 체크리스트
- 실패하는 테스트 1개를 먼저 고른다.
- Git worktree나 새 브랜치에서만 실행한다.
- 루프 횟수는 3회로 시작하고 최대 5회를 넘기지 않는다.
- 변경 파일 수와 금지 영역을 프롬프트에 명시한다.
- 통과 후 사람이 diff를 읽고 PR로 올린다.
FAQ
Q. MCP까지 붙여야 제대로 된 에이전트 루프인가요?
필수는 아닙니다. MCP는 Jira, Notion, GitHub 이슈 같은 외부 맥락을 안정적으로 연결할 때 유용합니다. 처음에는 로컬 테스트와 Git diff만으로도 충분합니다.
Q. ChatGPT만으로도 가능한가요?
가능하지만 코드 실행과 파일 수정은 사람이 중간에서 더 많이 해야 합니다. Claude Code나 Codex CLI 계열 도구는 터미널과 저장소 맥락을 직접 다루기 쉬워 반복 루프 구성에 유리합니다.
Q. 운영 코드에 바로 적용해도 되나요?
권장하지 않습니다. 최소한 별도 브랜치, 테스트, 리뷰, CI를 거쳐야 합니다. 특히 결제, 인증, 개인정보 처리 코드는 자동 수정 범위를 더 좁게 잡아야 합니다.
결론은 단순합니다. 자기수정 에이전트는 “스스로 다 해주는 개발자”가 아니라, 실패 로그를 기준으로 짧게 시도하고 멈출 줄 아는 자동화 루프에 가깝습니다. 오늘은 새 도구를 더 붙이기보다, 실패 테스트 하나와 3회 제한 루프부터 만드는 것이 가장 빠른 시작입니다.
관련 링크
- AI 에이전트 하네스 엔지니어링 입문 결정적 오케스트레이션 직접 짜기: 에이전트를 ‘믿는’ 대신 묶어두는 법
- ai 코딩 구독 요금 비교: Claude Code·Cursor·Copilot, 빌드용으로 돈값 하는 조합
- ai 코딩 에이전트 테스트 자동화, 생성 코드 믿고 배포하려면 제가 두는 5개 게이트
- 관련 태그 더 보기
- 카테고리 더 보기
- 검색 결과 더 보기
- 참고 링크
