beautifulsoups.dev
Published on

AutoGPT/BabyAGI 루프·헛발질 막는 프롬프트·메타규칙

Authors

사내 업무 자동화를 위해 AutoGPT/BabyAGI 같은 에이전트를 붙였는데, 결과가 나오기는커녕 같은 작업을 반복하거나(루프), 로그만 잔뜩 남기고 진전이 없는 경우(헛발질, thrashing)를 자주 봅니다. 문제는 모델이 “멍청해서”가 아니라, 목표·상태·종료조건·권한·검증 루프가 빈약한 상태에서 에이전트에게 과도한 자유도를 주기 때문입니다.

이 글에서는 AutoGPT/BabyAGI 스타일의 작업 분해형 에이전트가 사내 업무(리포트 생성, 데이터 정리, 티켓 triage, 배포 점검, 문서 갱신 등)를 수행할 때 생기는 루프/헛발질을 프롬프트와 메타규칙으로 막는 방법을 실전 관점에서 정리합니다.

또한 툴 실행을 로컬/사내 시스템에 연결할 때는 권한과 샌드박싱이 필수입니다. 관련해서는 AutoGPT에 MCP로 로컬툴 연결 - 권한·샌드박싱도 함께 참고하면 설계가 훨씬 안전해집니다.

1) 루프와 헛발질의 전형적인 패턴

1-1. 무한 계획 루프(Planning loop)

  • 증상: “계획을 세운다 → 더 좋은 계획을 세운다 → 리스크를 나열한다”를 반복
  • 원인: 목표가 추상적이고(예: “주간 보고서 자동화”), 완료 정의가 없음
  • 해결: 완료 정의(Definition of Done), 산출물 스키마, 최대 반복/시간 제한

1-2. 탐색 루프(Search loop)

  • 증상: 사내 위키/깃/티켓을 계속 뒤지는데 결론이 없음
  • 원인: 검색 범위·우선순위·증거 기준이 없음
  • 해결: 증거 기반 규칙(최소 2개 근거), “검색 예산” 도입

1-3. 실행 헛발질(Execution thrashing)

  • 증상: 파일을 조금 고치고 다시 되돌리고, 스크립트를 계속 재실행
  • 원인: 사전 체크리스트/드라이런/스냅샷 없이 바로 수정
  • 해결: 변경 전 스냅샷, 드라이런, diff 기반 검증, 롤백 플랜

예를 들어 텍스트 치환을 에이전트가 마음대로 하게 두면 sed 한 줄로 파일을 망칠 수 있습니다. 안전한 치환 관점은 bash에서 sed가 파일 망칠 때 안전 치환 7가지처럼 원자적 변경과 검증을 강제하는 쪽이 정답입니다.

1-4. 도구 호출 루프(Tool loop)

  • 증상: 같은 API/CLI를 반복 호출, 비용과 시간이 폭발
  • 원인: 캐시/메모리 요약이 없고, “같은 입력이면 같은 출력”이라는 전제가 깨짐
  • 해결: 호출 결과 캐시, 동일 명령 재호출 금지 규칙, idempotent 설계

2) 에이전트에게 반드시 넣어야 하는 “메타규칙” 10가지

아래는 AutoGPT/BabyAGI 공통으로 잘 먹히는 규칙입니다. 핵심은 자유도를 줄이는 게 아니라, 실패 모드의 자유도를 줄이는 것입니다.

  1. 완료 정의를 먼저 고정: 산출물 형식, 포함 항목, 금지 항목
  2. 상태를 외부화: 진행 상황을 STATE로 요약하고 매 스텝 업데이트
  3. 스텝 예산: 최대 스텝/시간/툴 호출 횟수 제한
  4. 동일 시도 반복 금지: 같은 입력으로 같은 도구를 2회 이상 호출 금지
  5. 증거 규칙: 결론에는 근거 2개 이상(로그/링크/커밋/쿼리 결과)
  6. 실행 전 체크리스트: 변경 작업은 드라이런, 백업, diff 확인
  7. 실패 시 축소 전략: 범위를 줄여 재시도(최소 재현, 최소 데이터)
  8. 중단/에스컬레이션: 권한 부족, 불확실성, 비용 초과 시 사람에게 질문
  9. 권한 최소화: 읽기/쓰기/배포 권한 분리, 샌드박스 우선
  10. 사후 보고: 무엇을 했고, 무엇을 안 했고, 남은 리스크는 무엇인지

이 규칙을 “시스템 프롬프트” 또는 “에이전트 헌장(Agent Charter)”로 고정해두면 루프 확률이 체감상 크게 떨어집니다.

3) 루프를 끊는 프롬프트 템플릿(바로 복붙용)

아래 템플릿은 AutoGPT/BabyAGI뿐 아니라 LangGraph/커스텀 오케스트레이션에도 그대로 적용됩니다. 중요한 점은 본문에 부등호 기호가 들어가면 MDX에서 JSX로 오인될 수 있으니, 예시는 코드 블록 안에만 넣었습니다.

[ROLE]
너는 사내 업무 자동화 에이전트다. 목표 달성을 위해 계획-실행-검증을 수행하되, 아래 메타규칙을 최우선으로 따른다.

[GOAL]
- 최종 목표: (예: 주간 장애 리포트를 생성하여 슬랙에 게시)

[DEFINITION OF DONE]
- 산출물: (예: Markdown 리포트 1개, 섹션 6개 고정)
- 포함: (예: 기간, 상위 5개 이슈, RCA 링크, 재발 방지 항목)
- 제외/금지: (예: 추측으로 원인 단정 금지)

[CONSTRAINTS]
- 최대 스텝: 12
- 최대 툴 호출: 20
- 동일 명령/쿼리 재호출 금지(입력 동일 기준)
- 불확실하면 질문 1회로 에스컬레이션

[STATE FORMAT]
매 스텝마다 아래를 갱신해라.
STATE:
- progress: (0~100)
- done: [완료한 작업]
- todo: [남은 작업]
- evidence: [근거 링크/로그/커밋]
- risks: [남은 리스크]

[WORKFLOW]
1) 3줄 이내로 계획을 세운다(과도한 계획 금지)
2) 실행한다
3) 검증한다(산출물 스키마/근거/테스트)
4) 실패하면 범위를 줄여 재시도한다

[STOP CONDITIONS]
- Definition of Done 충족 시 즉시 종료
- 예산 초과/권한 부족/근거 부족 시 즉시 중단하고 질문

[OUTPUT]
- 최종 산출물
- 수행 로그 요약
- 남은 리스크 및 다음 액션

이 템플릿의 효과는 “생각을 잘해라”가 아니라, 되풀이를 금지하고 종료 조건을 기계적으로 만들기에 있습니다.

4) BabyAGI식 태스크 큐에서 헛발질을 줄이는 운영 규칙

BabyAGI류는 “태스크 생성기-우선순위-실행기”가 분리되어 있어, 태스크 생성기가 쓸데없는 일을 끝없이 만들기 쉽습니다. 그래서 아래 3가지를 강제하면 좋습니다.

4-1. 태스크 스키마 고정

  • 태스크는 반드시 objective, input, expected_output, validation, cost_budget를 포함
  • validation이 없는 태스크는 큐에 넣지 않기
{
  "objective": "주간 장애 리포트 초안 생성",
  "input": "incident_db_query_result.json",
  "expected_output": "weekly-report.md",
  "validation": "섹션 6개 존재 + 각 이슈에 링크 1개 이상",
  "cost_budget": {"tool_calls": 5, "minutes": 10}
}

4-2. 태스크 생성 상한

  • 한 번에 생성 가능한 신규 태스크 수를 제한(예: 최대 3개)
  • 생성된 태스크는 반드시 기존 태스크를 “완료”시키는 방향이어야 함

4-3. 우선순위에 “증거 접근성”을 반영

  • 사내 시스템에서 접근 권한이 없는 리소스가 필요한 태스크는 우선순위를 낮추거나 즉시 에스컬레이션

5) “검증 루프”를 넣으면 자동화 품질이 급상승한다

에이전트가 헛발질하는 이유는 대부분 검증이 없기 때문입니다. 검증을 넣으면 에이전트는 최소한 “틀렸음을 아는 상태”가 되고, 그 다음부터는 범위를 줄이거나 질문할 수 있습니다.

검증은 크게 3종류가 있습니다.

  1. 형식 검증: 산출물이 스키마를 만족하는지(섹션, JSON 필드 등)
  2. 근거 검증: 주장마다 링크/로그/쿼리 결과가 있는지
  3. 실행 검증: 실제로 동작하는지(테스트, 드라이런, 린트)

예를 들어 Docker 기반 업무(빌드/배포 점검)를 자동화한다면, 에이전트가 “캐시가 안 먹네요” 같은 말만 반복할 수 있습니다. 이때는 캐시 무효화 원인을 체크리스트로 검증하게 만들어야 합니다. 관련 원인 정리는 Docker 빌드 캐시가 무효화되는 원인 7가지처럼 항목화된 지식이 특히 유용합니다.

6) 툴 권한·샌드박싱 없이는 루프가 “사고”로 변한다

사내 자동화에서 가장 위험한 루프는 “반복 실행” 그 자체가 아니라, 반복 실행이 실환경에 누적 영향을 주는 것입니다.

  • 같은 티켓에 코멘트를 30번 달기
  • 같은 배포를 재시도하다 rate limit/장애 유발
  • 파일을 여러 번 덮어써서 원본 손실

따라서 에이전트 툴링은 다음처럼 설계하는 게 안전합니다.

6-1. 읽기/쓰기/배포 권한 분리

  • 읽기 전용 툴(검색, 조회)과 쓰기 툴(수정, 코멘트), 배포 툴(릴리즈)을 분리
  • 기본값은 읽기 전용

6-2. 샌드박스 우선, 실환경은 승격 승인

  • 로컬/스테이징에서 검증 후에만 실환경 실행
  • “승격”은 사람이 승인하거나, 최소한 명시적 토큰이 있어야 가능

6-3. 모든 쓰기 작업은 “트랜잭션”처럼

  • 변경 전 백업
  • 변경 후 diff 출력
  • 검증 통과 시 커밋/반영
  • 실패 시 롤백

MCP나 로컬 툴 연결을 고려 중이라면, 권한·샌드박싱 설계를 먼저 잡아야 합니다. 이 주제는 AutoGPT에 MCP로 로컬툴 연결 - 권한·샌드박싱에 더 자세히 정리되어 있습니다.

7) 실전 예시: “리포트 자동 생성” 에이전트 프롬프트

아래는 사내에서 흔한 “주간 운영 리포트” 자동화를 예로 든 프롬프트입니다. 루프 방지 장치(예산, 동일 호출 금지, 검증, 에스컬레이션)를 모두 포함합니다.

너는 SRE 주간 리포트 작성 에이전트다.

목표: 지난 7일간 장애/성능 이슈를 요약한 주간 리포트를 작성해 슬랙에 게시할 초안을 만든다.

완료 정의:
- weekly-report.md 생성
- 섹션은 정확히 6개: 요약, 주요 장애 5건, 성능 이슈, 고객 영향, 조치 사항, 다음 주 계획
- 각 항목은 반드시 근거 링크(티켓 URL 또는 로그 쿼리 ID) 1개 이상 포함
- 근거 없는 추측 금지

제약:
- 최대 스텝 10, 최대 툴 호출 15
- 동일 쿼리/명령 재호출 금지
- 접근 권한이 없는 데이터가 필요하면 즉시 질문

작업 방식:
1) 필요한 데이터 소스를 3개 이내로 선택하고, 각 소스에서 무엇을 뽑을지 한 줄로 말한다.
2) 조회 툴로 데이터 수집
3) 초안 작성
4) 검증: 섹션 6개, 각 항목 링크 포함, 수치/기간 일관성
5) 부족하면 범위를 줄여 1회만 보완

출력:
- weekly-report.md 본문
- 사용한 근거 목록
- 남은 리스크(데이터 누락 등)

8) 체크리스트: “루프가 시작됐다”를 감지하는 신호

운영 중에는 아래 신호를 로그/메트릭으로 잡아두면 좋습니다.

  • 같은 툴 호출이 N회 이상 반복(입력 해시 기준)
  • progress가 2스텝 연속 증가하지 않음
  • 새로운 evidence가 3스텝 연속 추가되지 않음
  • 출력이 계속 “계획/주의사항” 위주이고 산출물이 없음

이런 조건을 만족하면 강제로 “질문 모드”로 전환시키거나, 작업 범위를 축소하는 리커버리 플로우를 태우는 것이 비용을 크게 줄입니다.

9) 정리: 에이전트 자동화는 프롬프트보다 “운영 규칙”이 절반이다

AutoGPT/BabyAGI로 사내 업무를 자동화할 때 루프·헛발질을 막는 핵심은 다음 4가지입니다.

  • 완료 정의를 구체화하고, 산출물 스키마를 고정한다
  • 상태를 외부화하고, 스텝/툴 호출 예산을 둔다
  • 동일 시도 반복 금지와 검증 루프를 강제한다
  • 권한 최소화와 샌드박싱으로 반복 실행이 사고로 커지지 않게 한다

이 조합을 갖추면 “에이전트가 똑똑해졌다”기보다, 실패해도 안전하게 멈추고, 성공할 때만 앞으로 나아가게 됩니다. 결국 사내 자동화의 성패는 모델 성능보다도, 이런 메타규칙과 가드레일을 얼마나 체계적으로 설계했는지에 달려 있습니다.

Discuss on Twitter • View on GitHub