루프 엔지니어링을 활용하여 스스로 개선하는 AI 에이전트를 구축하는 방법

대부분의 AI 에이전트가 실패하는 이유는 모델이 약해서가 아닙니다.

모델을 둘러싼 시스템이 약하기 때문입니다.

프롬프트가 모호합니다.

도구 호출이 실패합니다.

에이전트가 잘못된 것을 재시도합니다.

두 단계 전에 배운 것을 잊어버립니다.

같은 잘못된 행동을 반복합니다.

너무 일찍 성공을 선언합니다.

그리고 그 실수를 잡아낼 피드백 루프를 아무도 만들지 않았습니다.

그것이 진짜 문제입니다.

시간이 지남에 따라 실제로 개선되는 AI 에이전트를 구축하려면 더 나은 프롬프트, 더 많은 도구 또는 더 많은 자율성 이상의 것이 필요합니다.

루프 엔지니어링이 필요합니다.

루프 엔지니어링은 에이전트가 다음을 수행하는 방식을 설계하는 학문입니다:

• 무슨 일이 일어났는지 관찰
• 효과가 있었는지 평가
• 다음 행동을 업데이트
• 유용한 피드백 저장
• 지능적으로 재시도 또는 에스컬레이션
• 더 바빠지는 대신 더 나아짐

이러한 전환이 중요합니다.

왜냐하면 유용한 AI 에이전트의 다음 세대는 한 번의 데모 실행에서 얼마나 인상적인지로 정의되지 않을 것이기 때문입니다.

그들은 다음을 할 수 있는지 여부로 정의될 것입니다:

• 실수로부터 회복
• 반복된 실패로부터 학습
• 모든 단계에서 사람이 감독하지 않고도 품질 향상
• 프로덕션에서 제한되고, 측정 가능하며, 신뢰할 수 있는 상태 유지

이것이 이 글의 주제입니다.

이와 같은 실용적인 AI 시스템을 더 원하시나요? ByteBuilders는 Claude, AI 워크플로우, 프롬프트, 자동화 및 실제 엔지니어링 시스템에 대한 짧고 유용한 분석을 공유합니다.

여기서 구독하세요:

https://bytebuilders.beehiiv.com/subscribe

루프 엔지니어링을 이해하면 모든 것이 완벽할 때만 작동하는 취약한 에이전트를 만드는 것을 중단합니다.

학습하도록 설계되었기 때문에 개선되는 시스템을 구축하기 시작합니다.

첫째, "자기 개선"이 실제로 의미하는 것

많은 사람들이 "자기 개선 에이전트"라는 말을 듣고 마법처럼 스스로 재훈련하거나 자율적이고 신비로운 무언가로 진화하는 시스템을 상상합니다.

그것은 유용한 정의가 아닙니다.

자기 개선 에이전트는 일반적으로 훨씬 더 간단합니다.

이전 시도의 신호를 사용하여 다음 시도에서 더 나은 결정을 내릴 수 있는 에이전트입니다.

이는 다음을 통해 발생할 수 있습니다:

• 더 나은 컨텍스트를 사용한 재시도
• 평가 기반 수정
• 이전 실패에 대한 기억
• 도구 사용 수정
• 출력 점수 매기기
• 인간 피드백 루프
• 규칙 업데이트
• 저장된 성공 패턴

즉:

자기 개선은 일반적으로 모델 진화가 아닙니다. 루프 진화입니다.

기본 모델은 동일하게 유지될 수 있습니다.

개선되는 것은 모델 주변 시스템의 동작입니다.

그것이 훨씬 더 실용적이고 엔지니어링 친화적인 프레임입니다.

대부분의 에이전트가 스스로 개선되지 않는 이유

놀랍게도 많은 에이전트가 실제로 개선되도록 설계되지 않았습니다.

그들은 계속하도록 설계되었습니다.

그것은 같은 것이 아닙니다.

오늘날 많은 에이전트 시스템은 기본적으로 다음과 같습니다:

1. 작업 읽기
2. 생각하기
3. 도구 호출
4. 중지될 때까지 계속

문제는 이 구조에 종종 다음이 부족하다는 것입니다:

• 명시적인 성공 기준
• 실패 분류
• 상태 인식 재시도
• 이미 실패한 것에 대한 기억
• 시도 간 비교
• 출력 평가
• 에스컬레이션 규칙

따라서 에이전트는 개선되지 않습니다.

그냥 반복할 뿐입니다.

이것이 단순 반복과 지능적 반복의 차이입니다.

루프 엔지니어링이 그 차이를 만드는 것입니다.

루프 엔지니어링이 진정한 아키텍처 계층입니다

루프 엔지니어링을 이해하는 가장 쉬운 방법은 다음과 같습니다:

프롬프팅은 모델에게 무엇을 할지 알려줍니다.

루프 엔지니어링은 시스템에게 시도 후 어떻게 행동할지 알려줍니다.

여기에는 다음과 같은 질문이 포함됩니다:

• 실패한 도구 호출 후 에이전트는 무엇을 해야 합니까?
• 언제 재시도하고 언제 전략을 전환해야 합니까?
• 허용되는 시도 횟수는 몇 번입니까?
• 메모리에 무엇을 저장해야 합니까?
• 자동으로 평가해야 하는 것은 무엇입니까?
• 언제 사람이 개입해야 합니까?
• 무엇이 개선으로 간주됩니까?

이것이 루프 엔지니어링이 단순한 프롬프트 대화가 아닌 아키텍처 대화에 속하는 이유입니다.

자기 개선 에이전트 뒤의 핵심 루프

대부분의 유용한 자기 개선 에이전트는 다음과 같은 반복 구조를 따릅니다

1목표
2  ↓
3계획
4  ↓
5행동
6  ↓
7결과 관찰
8  ↓
9품질 평가
10  ↓
11신호 저장
12  ↓
13재시도 / 수정 / 에스컬레이션 / 최종화

그것이 기초입니다.

루프를 통과할 때마다 다음 결정이 유용한 방식으로 변경될 때 시스템이 개선됩니다.

모든 에이전트가 복잡한 버전을 필요로 하는 것은 아닙니다.

하지만 모든 신뢰할 수 있는 에이전트는 이와 같은 어떤 버전이 필요합니다.

단순한 에이전트와 루프 엔지니어링된 에이전트의 차이

차원

단순한 에이전트

루프 엔지니어링된 에이전트

작업 처리

작업을 한 번 시도하거나 맹목적으로 계속

제한된 주기로 작업

오류 대응

무작위로 재시도하거나 심하게 실패

분류된 실패를 기반으로 재시도

메모리

거의 또는 전혀 유용한 상태 없음

실행 가능한 컨텍스트 저장

평가

완료가 성공을 의미한다고 가정

기준에 대한 출력 확인

개선

우연적

설계됨

인간 역할

비상시에만 사용

의도적인 에스컬레이션 지점

신뢰성

일관성 없음

시간이 지남에 따라 점진적으로 강화됨

이것이 전환입니다.

루프 엔지니어링된 에이전트가 반드시 모델 수준에서 "더 똑똑한" 것은 아닙니다.

단지 더 나은 시스템 내에서 작동하고 있을 뿐입니다.

자기 개선 에이전트의 다섯 가지 구성 요소

에이전트가 개선되도록 하려면 구조가 있는 루프가 필요합니다.

이 다섯 가지 구성 요소가 가장 중요합니다.

1. 명확한 성공 기준

시스템이 "좋은" 것이 무엇인지 모르면 그것을 향해 개선할 수 없습니다.

성공 기준은 다음과 같을 수 있습니다:

• 정확한 출력 형식
• 정확성 임계값
• 근거 있는 답변 요구 사항
• 도구 완료 신호
• 테스트 통과 결과
• 인간 승인
• 작업별 점수

이것이 없으면 에이전트는 최적화할 안정적인 대상을 갖지 못합니다.

1. 평가 계층

평가 계층은 에이전트에게 시도가 효과가 있었는지 알려줍니다.

이는 다음과 같을 수 있습니다:

• 규칙 기반 검사
• 스키마 검증
• 단위 테스트
• LLM-as-judge 점수 매기기
• 검색 근거 확인
• 비즈니스 로직 검증
• 인간 검토

이것이 "답변을 생성했다"와 "유용한 답변을 생성했다"의 차이입니다.

1. 피드백 메모리

자기 개선에는 메모리가 필요하지만 단순한 원시 기록만으로는 충분하지 않습니다.

에이전트는 사용 가능한 메모리가 필요합니다.

좋은 피드백 메모리에는 다음과 같은 것들이 포함됩니다:

• 마지막 실패 이유
• 이전 도구 오류
• 알려진 최고 성공 경로
• 피해야 할 알려진 나쁜 전략
• 사용자 선호도 또는 수정
• 이전 시도의 압축된 요약

모든 컨텍스트가 지속되어야 하는 것은 아닙니다.

다음 결정에 도움이 되는 컨텍스트만 지속되어야 합니다.

1. 전략 수정

평가 후 에이전트는 무엇을 변경할지 결정해야 합니다.

여기에는 다음이 포함될 수 있습니다:

• 새 도구 시도
• 작업 범위 좁히기
• 명확한 질문하기
• 더 많은 정보 검색
• 행동에서 설명으로 전환
• 인간에게 에스컬레이션

이것이 시스템이 실제로 적응하는 부분입니다.

1. 경계 및 중지 조건

자기 개선 에이전트에도 여전히 제어가 필요합니다.

그렇지 않으면 개선되지 않습니다.

혼란만 생깁니다.

다음에 대한 한도를 설정하세요:

• 재시도
• 비용
• 지연 시간
• 파괴적인 행동
• 인간 승인 임계값
• 작업 포기 규칙

제한된 루프가 제약 없는 루프보다 더 가치 있습니다.

실제 루프 엔지니어링의 모습

다음은 많은 에이전트에 잘 작동하는 간단한 패턴입니다.

루프 1: 시도

에이전트가 현재 컨텍스트로 작업을 시도합니다.

루프 2: 평가

검사가 실행됩니다.

예:

• 스키마가 검증되었습니까?
• 코드가 테스트를 통과했습니까?
• 답변이 필요한 출처를 인용했습니까?
• 도구가 올바른 필드를 반환했습니까?

루프 3: 진단

실패한 경우 이유를 분류합니다.

예:

• 컨텍스트 부족
• 잘못된 도구 인수
• 검색 실패
• 환상적인 가정
• 불완전한 출력
• 정책 충돌

루프 4: 적응

다음 시도를 변경합니다.

예:

• 더 많은 컨텍스트 검색
• 작업을 더 좁게 다시 작성
• 다른 도구 시도
• 검증 규칙 추가
• 누락된 세부 정보에 대해 사용자에게 질문

루프 5: 유용한 신호 저장

향후 실행에 도움이 되는 것만 저장합니다.

그런 다음 반복합니다.

이것이 운영 측면에서의 루프 엔지니어링입니다.

루프 엔지니어링된 에이전트를 위한 실용적인 다이어그램

1사용자 목표
2   ↓
3작업 해석기
4   ↓
5계획자
6   ↓
7도구 / 행동 계층
8   ↓
9결과
10   ↓
11평가자
12   ├── 통과 → 최종화
13   ├── 실패: 컨텍스트 부족 → 더 검색
14   ├── 실패: 잘못된 도구 사용 → 행동 수정
15   ├── 실패: 낮은 신뢰도 → 에스컬레이션
16   └── 실패: 복구 가능 → 메모리로 재시도

이것이 에이전트 품질이 우연이 아닌 체계적으로 되는 지점입니다.

자기 개선 신호는 어디서 와야 하는가

이것은 가장 중요한 설계 질문 중 하나입니다.

잘못된 신호를 루프에 공급하면 에이전트가 잘못된 방향으로 최적화할 수 있습니다.

개선 신호의 강력한 소스는 다음과 같습니다:

결정적 신호

• 테스트 통과 또는 실패
• 스키마 검증 성공 또는 실패
• API 상태 성공 또는 오류
• 출력에 필수 필드 포함 여부
• 정책 규칙 충족 또는 위반

워크플로우 신호

• 재시도 횟수
• 도구 지연 시간
• 실패가 발생한 단계
• 신뢰도 임계값 초과
• 에스컬레이션 빈도

인간 신호

• 좋아요 / 싫어요
• 수정된 출력
• 수락된 초안 대 거부된 초안
• 수동 재정의 패턴
• 검토자 메모

비교 신호

• 버전 A 대 버전 B 출력 품질
• 검색 변형 비교
• 도구 경로 비교
• 반복 실행에 따른 점수 개선

최고의 자기 개선 에이전트는 일반적으로 이러한 범주 중 적어도 두 가지를 결합합니다.

최고의 루프는 응답뿐만 아니라 워크플로우를 개선합니다

이것이 설계가 더 성숙해지는 지점입니다.

약한 구현은 루프를 사용하여 텍스트만 재생성합니다.

더 강력한 구현은 루프를 사용하여 전체 워크플로우를 개선합니다.

즉, 에이전트가 다음을 변경하여 개선할 수 있음을 의미합니다:

• 검색하는 내용
• 사용하는 도구
• 단계 순서
• 기억하는 내용
• 무시하는 내용
• 더 일찍 명확한 설명을 요청하는지 여부
• 더 일찍 중지하는지 여부

이것은 "답변을 다시 작성하는 것"보다 훨씬 강력합니다.

시스템이 프로세스 수준에서 자체 수정이 가능해집니다.

자기 개선을 지원하는 프롬프트 패턴

프롬프팅은 여전히 중요합니다.

단지 루프를 지원해야 합니다.

다음은 유용한 프롬프트 패턴입니다.

프롬프트 1: 평가 인식 행동 프롬프트

1당신은 제한된 워크플로우 내에서 작업을 실행하고 있습니다.
2당신의 목표는 단순히 답변을 생성하는 것이 아니라 평가를 통과할 답변을 생성하는 것입니다.
3정보가 누락된 경우 요청하거나 검색하십시오.
4결과가 불확실한 경우 확신을 가지고 최종화하지 마십시오.
5이전 시도가 실패한 경우 컨텍스트가 변경되지 않는 한 동일한 전략을 반복하지 마십시오.

프롬프트 2: 실패 진단 프롬프트

1이전 시도가 실패했습니다.
2가능한 실패 이유를 다음 범주 중 하나로 분류하십시오:
3- 컨텍스트 부족
4- 도구 오용
5- 잘못된 가정
6- 불완전한 출력
7- 형식 또는 스키마 실패
8- 정책 충돌
9그런 다음 성공 확률을 개선하는 가장 작은 다음 변경 사항을 제안하십시오.

프롬프트 3: 수정 프롬프트

1아래 평가자 피드백을 사용하여 다음 시도를 수정하십시오.
2이미 실패한 경우 동일한 추론 경로를 반복하지 마십시오.
3더 좁고 근거 있는 솔루션을 선호하십시오.
4필요한 경우 답변하기 전에 더 많은 컨텍스트를 검색하십시오.

프롬프트 4: 메모리 요약 프롬프트

1마지막 시도를 다음 실행을 위한 짧은 메모리 블록으로 요약하십시오.
2다음만 포함하십시오:
3- 실패한 것
4- 효과가 있었던 것
5- 피해야 할 것
6- 다음에 시도해야 할 것
7120 단어 미만으로 유지하십시오.

이것들은 마법의 프롬프트가 아닙니다.

루프 동작을 강화하도록 설계된 프롬프트입니다.

간단한 Python 스타일 루프 아키텍처

다음은 루프 엔지니어링이 코드에서 어떻게 보일 수 있는지에 대한 간단한 예입니다

1MAX_ATTEMPTS = 4
2
3memory = []
4
5for attempt in range(MAX_ATTEMPTS):
6    context = build_context(task=task, memory=memory)
7    plan = agent.plan(context)
8    result = agent.act(plan)
9
10    evaluation = evaluator.check(task=task, result=result)
11
12    if evaluation.passed:
13        return {
14            "status": "success",
15            "result": result,
16            "attempt": attempt + 1,
17        }
18
19    failure_summary = agent.summarize_failure(
20        result=result,
21        evaluation=evaluation,
22    )
23
24    memory.append({
25        "attempt": attempt + 1,
26        "failure": failure_summary,
27        "suggested_fix": evaluation.next_step,
28    })
29
30    if evaluation.requires_human:
31        return {
32            "status": "escalated",
33            "reason": evaluation.reason,
34            "attempt": attempt + 1,
35            "memory": memory,
36        }
37
38return {
39    "status": "failed",
40    "reason": "max_attempts_reached",
41    "memory": memory,
42}

이것은 의도적으로 간단합니다.

중요한 점은 코드 자체가 아닙니다.

구조입니다:

• 시도
• 평가
• 신호 저장
• 적응
• 재시도 또는 에스컬레이션

그것이 내면화해야 할 패턴입니다.

루프 엔지니어링이 가장 중요한 곳

이 접근 방식은 첫 번째 시도에서 성공이 보장되지 않는 워크플로우에서 특히 가치 있습니다.

코딩 에이전트

시스템이 다음을 할 수 있기 때문에 루프에 완벽합니다:

• 테스트 실행
• 실패 검사
• 코드 수정
• 출력 비교
• 검증이 통과될 때만 중지

지원 에이전트

시스템이 다음을 할 수 있기 때문에 유용합니다:

• 정책 컨텍스트 검색
• 응답 초안 작성
• 근거 확인
• 위험이 높은 경우 승인 요청

연구 에이전트

시스템이 다음을 할 수 있기 때문에 도움이 됩니다:

• 여러 출처 수집
• 격차 식별
• 다시 검색
• 증거가 충분할 때만 종합

문서 추출 에이전트

시스템이 다음을 할 수 있기 때문에 유용합니다:

• 파일 구문 분석
• 스키마 검증
• 모호한 필드 재시도
• 낮은 신뢰도 사례 에스컬레이션

운영 워크플로우 에이전트

시스템이 다음을 할 수 있기 때문에 가치 있습니다:

• API 호출
• 결과 확인
• 부분 실패로부터 복구
• 예외를 인간에게 라우팅

이 모든 경우에서 루프 품질이 한 번 생성 품질보다 더 중요합니다.

루프 엔지니어링의 일반적인 실수

실수 1: 재시도를 개선으로 간주

더 많은 시도가 자동으로 더 나은 학습을 의미하지는 않습니다.

시스템이 동일한 행동을 반복한다면 개선되는 것이 아닙니다.

그냥 반복할 뿐입니다.

실수 2: 너무 많은 메모리 저장

모든 과거 컨텍스트가 도움이 되는 것은 아닙니다.

너무 많은 메모리는 다음 시도를 오염시킬 수 있습니다.

압축되고 실행 가능한 교훈을 저장하십시오. 원시 기록 더미가 아닙니다.

실수 3: 평가 건너뛰기

확인 없이 에이전트는 더 나아졌는지 알 수 없습니다.

이것이 가장 흔한 구조적 실패입니다.

실수 4: 중지 조건 없음

제약 없는 에이전트는 고급이 아닙니다.

비용만 많이 듭니다.

실수 5: 인간 피드백 무시

인간이 계속해서 같은 것을 수정하고 루프가 그 신호를 사용하지 않는다면 시스템은 실제로 개선되지 않는 것입니다.

실수 6: 모든 작업에 하나의 거대한 루프 사용

다른 작업에는 다른 루프가 필요합니다.

지원 에이전트와 코딩 에이전트는 동일한 재시도 로직이나 평가 규칙을 공유해서는 안 됩니다.

제가 추천하는 실용적인 구축 순서

처음부터 구축하는 경우 이 순서를 사용하십시오.

1단계: 성공을 명확하게 정의

좋은 결과는 어떻게 생겼습니까?

2단계: 실패 범주 정의

이 에이전트는 일반적으로 왜 실패합니까?

3단계: 먼저 평가자 구축

시스템이 성공 또는 실패를 어떻게 알 수 있습니까?

4단계: 메모리 규칙 설계

시도 사이에 무엇이 지속되어야 합니까?

5단계: 재시도 전략 정의

첫 번째 시도와 두 번째 시도 사이에 무엇이 변경됩니까?

6단계: 에스컬레이션 로직 추가

인간은 언제 개입해야 합니까?

7단계: 중요한 모든 것을 기록

관찰하지 않으면 개선할 수 없습니다.

8단계: 루프가 작동한 후에만 최적화

핵심 주기가 안정되기 전에 시스템을 너무 복잡하게 만들지 마십시오.

이 순서는 팀이 과대광고 대신 행동에 집중하도록 유지합니다.

에이전트를 "자기 개선"이라고 부르기 전의 간단한 체크리스트

이것을 현실 점검으로 사용하십시오.

• 에이전트가 성공이 어떻게 생겼는지 알고 있습니까?
• 각 시도를 평가합니까?
• 실패로부터 유용한 교훈을 저장합니까?
• 피드백을 기반으로 전략을 변경합니까?
• 동일한 실패 경로를 맹목적으로 반복하지 않습니까?
• 언제 중지해야 하는지 알고 있습니까?
• 언제 인간에게 에스컬레이션해야 하는지 알고 있습니까?
• 실제로 더 나아지고 있는지 측정할 수 있습니까?

이 중 대부분이 누락된 경우 시스템은 아마도 자기 개선이 아닐 것입니다.

그냥 반복적일 뿐입니다.

마지막 생각

AI 에이전트의 미래는 더 나은 프롬프트, 더 많은 도구 또는 더 긴 체인이 아닙니다.

더 나은 루프입니다.

그것이 루프 엔지니어링이 가능하게 하는 것입니다.

에이전트를 일회성 생성기에서 다음을 할 수 있는 시스템으로 전환합니다:

• 관찰
• 평가
• 적응
• 기억
• 지능적으로 재시도
• 실제 조건에서 개선

그것이 프로덕션 AI에서 자기 개선이 실제로 보이는 모습입니다.

신비가 아닙니다.

마법이 아닙니다.

더 나은 시스템 설계일 뿐입니다.

더 강력한 에이전트를 원한다면 어떻게 행동하게 할지 묻지 마십시오.

다음에 일어난 일로부터 학습하게 하는 방법을 물어보십시오.

거기에 진정한 레버리지가 있습니다.