자율 AI 에이전트: 몇 시간 동안 쓰레기를 만들지 않고 일하게 하는 방법

자율 AI 에이전트란 무엇이고 일반 요청과 어떻게 다른가

일반적인 에이전트 작업은 단계별로 진행됩니다. 프롬프트를 쓰면 에이전트가 한 단계를 수행하고, 결과를 보고 다음 단계를 정합니다. 자율 AI 에이전트는 루프 안에서 움직입니다. 최종 상태가 어떤 모습인지 한 번 설명하면, 에이전트가 목표에 도달하거나 예산이 소진될 때까지 "실행하고, 검증하고, 수정하는" 과정을 스스로 반복합니다. 작업을 시작한 뒤에는 자리를 비울 수 있습니다.

개념은 단순하지만 처음 시도하면 보통 이런 일이 생깁니다. 아침에 맡긴 작업을 저녁에 확인해 보니, 에이전트가 한 시간 전에 한 일을 잊고 이미 고친 버그를 몇 시간째 다시 고치고 있습니다. 아무도 언제 멈추고 언제 사람을 부를지 알려 주지 않았기 때문입니다. 아래에서는 이런 일이 생기지 않도록 루프를 설계하는 방법을 정리합니다.

한 가지 단서가 있습니다. 루프는 하네스를 대신하지 않습니다. 하네스는 한 번의 실행을 안정적으로 만들고, 루프는 실행을 끊임없이 이어 줍니다. 허술한 하네스 위에 루프를 얹으면 쓰레기가 더 빨리 만들어질 뿐입니다.

이 작업이 자율 에이전트에 맞는지 판단하기

먼저 작업에 기계로 확인할 수 있는 종착점이 있는지 봅니다. "tests/payments 아래의 모든 테스트가 통과한다", "목록의 모든 기능이 passing 상태다", "지표가 기준선보다 올랐다"는 맞는 목표입니다. "코드를 더 좋게 만들어라"나 "결제 기능을 계속 개선해라"는 맞지 않습니다. 이런 목표에는 끝이 없어서 루프가 예산을 다 쓸 때까지 돌아갑니다.

루프의 유형은 네 가지로 구분해 볼 수 있습니다.

• 단계형 — 프롬프트를 사람이 하나씩 입력합니다. 평범한 대화형 작업입니다.
• 목표형 — 목표를 정하고, 독립 검증이나 예산이 멈춤 조건을 맡습니다. 몇 시간짜리 자율 에이전트가 바로 이 유형입니다.
• 시간형 — 일정에 따라 실행하고 사람이 멈춥니다. 예를 들어 아침마다 실패한 CI 빌드를 살펴보는 작업입니다.
• 이벤트형 — 외부 이벤트(새 이슈, 실패한 배포)가 실행을 촉발하고, 이벤트 처리가 끝나거나 재시도 한도에 도달하면 멈춥니다.

자주 하는 실수는 시간형과 목표형을 혼동하는 것입니다. "10분마다 결제 작업을 계속해라"는 식의 지시가 여기에 해당합니다. 일정에 따라 도는 루프는 매번 지시를 처음부터 시작하며, 이전에 무엇을 했는지 알지 못합니다. 끝이 있는 작업이라면 진행 상황을 기억하는 목표형 루프가 필요합니다.

1단계. 샌드박스: 에이전트가 망가뜨려도 되는 곳

사람 없이 움직이는 에이전트는 조만간 잘못된 일을 합니다. 파일을 지우거나, 마이그레이션을 다시 쓰거나, 무거운 명령을 실행합니다. 그래서 질문은 "실수하지 않게 만들 수 있나"가 아니라 "실수해도 비용이 없게 만들 수 있나"입니다.

• 별도 작업 복사본. git worktree는 같은 저장소 위에 에이전트 전용 디렉터리와 브랜치를 만들어 줍니다. 메인 브랜치는 건드려지지 않고, 여러 에이전트가 서로 방해하지 않으며, 실패한 실행은 명령 하나로 지울 수 있습니다.
• 컨테이너나 가상 머신. 에이전트에 명령에 대한 전체 권한이 필요하다면, 홈 디렉터리, 키, 운영 데이터베이스에 접근할 수 없는 컨테이너에서 실행하세요.
• 테스트 데이터. 로컬 데이터베이스, 결제 시스템의 샌드박스, 가짜 키를 사용하세요. 에이전트 환경에는 운영 비밀 정보가 하나도 있으면 안 됩니다.

# 자율 실행 전용 브랜치와 디렉터리
git worktree add ../shop-agent -b agent/f03-refunds

# 실행 후: 결과를 보거나 버리기
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

2단계. 권한: 작업에 필요한 최소한만

에이전트가 혼자 오래 일할수록 권한은 더 좁아야 합니다. Claude Code에서 권한은 settings.json에서 설정합니다. 도구와 명령에 대한 allow와 deny 목록을 쓰면 됩니다. 작업에 필요한 것, 예를 들어 테스트 실행, 린터 실행, 작업 복사본의 파일 수정은 명시적으로 허용하고, 위험한 것, 예를 들어 메인 브랜치로의 push, 비밀 정보 다루기, 필요 없는 네트워크 명령은 막으세요.

모든 작업을 확인 없이 실행하는 모드는 격리된 샌드박스 안에서만 허용됩니다. 최악의 결과가 버려지는 컨테이너 하나인 경우에만 쓸 수 있습니다. 비밀 키와 저장소에 접근할 수 있는 개인 컴퓨터에서 이렇게 실행하면 안 됩니다.

절대 어기면 안 되는 금지 사항은 문장이 아니라 장치로 막으세요. "migrations/는 건드리지 마라"라는 지시문은 부탁에 불과합니다. 이 디렉터리 수정을 막는 훅이나 파일 시스템 권한이 있어야 보장이 됩니다.

3단계. 목표, 검증, 중단: 시작 전에 적는 세 줄

가장 단순한 작동 루프는 세 가지에 기대고, 이 세 가지는 실행 중이 아니라 실행 전에 적어 두어야 합니다.

1. 목표 — 최종 상태가 어떤 모습인지.
2. 검증 — 목표에 도달했는지 기계로 확인하는 방법. 성공이나 실패를 반환하는 명령이어야 합니다.
3. 중단 조건 — 목표에 도달하지 못해도 루프를 멈추게 하는 시도 횟수, 시간, 또는 비용의 한도.

이것을 방법론 파일로 따로 보관하면 편합니다. 이 파일은 사람만 수정합니다. 결제 백엔드를 위한 예시는 다음과 같습니다.

# program.md — 자율 실행 방법론

## 목표
.agent/feature_list.json의 모든 기능이 passing 상태다.

## 지표
passing 상태인 기능 수. 단조 증가해야 합니다. 후퇴하면 즉시 되돌립니다.

## 제약
- 동시에 진행하는 기능은 하나뿐입니다.
- migrations/와 infra/는 수정하지 않습니다.
- 기록 없이 의존성을 바꾸지 않습니다.

## 작업 순서
1. passing이 아닌 첫 번째 기능을 고릅니다.
2. 구현하고 pytest와 린터를 실행합니다.
3. 초록이면 커밋하고 .agent/progress.md에 기록합니다. 빨강이면 고칩니다.

## 중단과 에스컬레이션
- 한 기능에 3번 실패하면 blocked로 표시하고 다음 기능으로 넘어갑니다.
- 남은 기능이 모두 blocked면 멈추고 보고서를 씁니다.
- 고객 자금, 접근 권한, 데이터 삭제와 관련된 작업은 하지 않고 사람에게 넘깁니다.

4단계. 디스크에 기억을 둔 검증-수정 루프

컨텍스트 윈도우는 긴 작업을 버티지 못합니다. 가득 차고, 압축되고, 세션이 다시 시작됩니다. 그래서 진행 상황은 에이전트의 "머릿속"이 아니라 파일에 있어야 합니다. 상태가 붙은 작업 목록, 무엇을 했고 무엇이 실패했는지 적은 기록, git 히스토리가 여기에 해당합니다.

좋은 모델은 "앞으로만 움직이는 래칫"입니다. Andrej Karpathy의 autoresearch 프로젝트가 그런 예입니다. 에이전트가 밤새 수백 번의 ML 실험을 수행합니다. 각 반복은 방법론을 읽고, 가설을 세우고, 변경을 적용하고, 고정된 시간 예산으로 실험을 돌리고, 기준선과 비교하는 순서로 진행됩니다. 개선되었으면 커밋하고, 아니면 되돌립니다. 결과는 기록에 남고, 그다음 가설로 넘어갑니다.

이 방식에서 두 가지 결정을 가져올 만합니다.

• 시도마다 고정된 예산. 시도끼리 비교할 수 있게 되고, 실패한 가설 하나가 밤 전체를 잡아먹지 않습니다.
• 메인 브랜치에는 개선만. 효과가 없었던 것은 옆에 쌓아 두지 않고 되돌립니다. git log는 아침에 쉽게 읽을 수 있는 검증된 작업 기록이 됩니다.

이 구조에서는 파일별로 역할도 나뉩니다. 인프라와 평가 코드는 아무도 수정하지 않고, 실험 코드는 에이전트만 수정하며, 방법론은 사람만 수정합니다. 에이전트는 측정 방식을 바꿔서 결과를 "개선"할 수 없습니다.

5단계. 완료 여부를 판단하는 독립 평가자

사람이 루프 안에 없으면 에이전트의 자기 평가가 유일한 제동 장치가 되는데, 이 장치는 제대로 작동하지 않습니다. 방금 코드를 작성한 에이전트는 그 코드가 옳다고 여기기 쉽습니다. 자신의 추론을 그대로 보고 있고, 무엇을 하려고 했는지 "알고" 있기 때문입니다.

생성자와 평가자를 분리하는 규칙은 다음과 같습니다.

• 작업을 한 세션이 평가하지 않습니다. Claude Code에서는 서브에이전트가 이때 유용합니다. 각 서브에이전트는 자기만의 컨텍스트를 가지기 때문입니다.
• 평가자는 깨끗한 컨텍스트를 받습니다. 요구사항, diff, 실행 결과만 받고, 실행자의 추론은 받지 않습니다.
• 가능하다면 평가자는 다른 모델이거나, 최소한 다른 역할의 다른 프롬프트여야 합니다.
• 판정은 루브릭에 따라 내리며, 각 항목은 증거를 가리켜야 합니다. 테스트의 한 줄, 명령의 출력, diff의 위치처럼 구체적인 증거여야 합니다.

그래도 기계적 검사가 1차 검증입니다. 평가자는 테스트가 잡아내지 못하는 것을 보기 위해 필요합니다. 요구사항을 잘못 이해했는지, 테스트가 코드에 맞춰 조정되었는지, 변경이 작업 범위를 벗어났는지 같은 것들입니다.

중단 조건: 에이전트가 언제 포기해야 하나

중단 조건이 없는 루프는 결국 무한히 돕니다. 최소한 다음 조건은 갖춰야 합니다.

진행 상황은 시도 횟수가 아니라 실질적인 결과로 확인하세요. "반복을 40번 했다"는 의미가 없습니다. "통과하는 기능 수가 5개에서 9개로 늘었다"는 의미가 있습니다. 작업이 계속 막힌다면 루프를 한 번 더 돌리지 말고 사람에게 넘기세요.

눈에 잘 띄지 않는 자율 에이전트의 위험

눈에 보이는 위험, 즉 지워진 파일이나 깨진 빌드는 샌드박스와 권한으로 막을 수 있습니다. 더 위험한 것은 몇 주에 걸쳐 조용히 쌓이는 비용입니다.

• 검증 부채. "괜찮아 보인다"가 "기계로 확인되었다"를 대신하는 상황입니다. 해결책은 예외 없이 기계로 검증 가능한 중단 조건을 쓰는 것뿐입니다.
• 이해도 저하. 자기 코드를 점점 덜 알게 됩니다. 해결책은 diff를 반드시 읽는 것입니다. 루프의 속도가 사람이 읽는 속도를 넘어서면 안 됩니다.
• 인지적 포기. 결과에 대해 더 이상 의견을 갖지 않고 무엇이든 받아들이게 됩니다. "나중에 보겠다"고 해 놓고 보지 않은 횟수를 솔직하게 세어 보는 것이 도움이 됩니다.
• 컨텍스트 비대화. 긴 실행은 히스토리를 쌓고, 다음 단계는 점점 비싸지고 나빠집니다. 컨텍스트 압축과 외부 메모리는 첫 번째 루프부터 필요하며, 모든 것이 흐트러진 뒤에 도입하면 늦습니다.

첫 자율 루프를 하루 저녁에 돌려 보기

"에이전트가 알아서 작업을 찾고 처리하게 하자"부터 시작하지 마세요. 자율성은 단계적으로 늘려야 합니다. 먼저 목표와 중단 조건이 있는 작업 하나를 맡기고, 다음으로 일정에 따라 도는 자동화 하나를 만들고, 그다음 격리된 작업 복사본에서 실행자와 검증자를 분리하고, 마지막에야 스스로 일을 찾아 병렬로 도는 루프를 시도하세요.

1. 일주일에 최소 두 번 손으로 하는 작업 중에서, 검증 가능한 종착점이 있는 것을 고르세요.
2. 목표, 검증, 중단 조건을 세 줄로 적으세요.
3. 별도의 worktree를 만들고 권한을 설정하세요. 테스트와 파일 수정은 허용하고, push와 비밀 정보는 허용하지 마세요.
4. 진행 파일을 만들고, 매 반복 후 에이전트가 그 파일을 갱신하게 하세요.
5. 실행자와 검증자를 나누세요. 실행자는 작성하고, 검증자는 별도 컨텍스트에서 diff를 평가합니다.
6. 전체 한도를 정하고, 첫 실행의 결과는 아침이 아니라 한 시간 뒤에 확인하세요.

요약

자율 AI 에이전트는 그 틀이 튼튼한 만큼만 믿을 수 있습니다. 틀이란 실수해도 비용이 없는 샌드박스, 최소 권한, 기계로 검증 가능한 목표, 디스크에 저장된 기억, 독립 평가자, 그리고 사람에게 넘기는 엄격한 중단 조건을 말합니다. 이런 틀이 없으면 긴 실행은 시간을 아끼는 것이 아니라, 나중에 치워야 할 쓰레기를 미루는 것입니다. 이 루프를 실제 프로젝트에서 program.md부터 독립 평가자까지 직접 구성하는 과정은 harness engineering 과정에서 다룹니다.