앞 장에서 우리는 에이전트를 어떻게 테스트하고 평가할지를 살펴봤다. 하지만 평가만으로는 제품이 좋아지지 않는다. 건강검진 결과표를 책상 위에 올려두는 것만으로 몸이 나아지지 않는 것과 같다. 수치를 보고, 원인을 찾고, 생활 습관을 바꾸고, 다시 확인해야 비로소 개선이 시작된다.
에이전트도 똑같다. 실패를 측정하는 시스템이 평가 하네스라면, 그 실패를 더 나은 행동으로 바꾸는 시스템은 피드백 루프다. 여기서 중요한 관점은 단순하다. 좋은 하네스는 한 번에 맞히는 시스템이 아니라, 틀려도 더 나아지게 만드는 시스템이다.
피드백 루프는 실행 루프와 다르다
10장에서 본 워크플로와 루프는 주로 한 작업 안에서 에이전트가 어떻게 관찰하고, 계획하고, 실행하고, 되짚는지를 다뤘다. 반면 이번 장의 피드백 루프는 한 번의 작업을 넘어선다. 실행의 결과를 다시 다음 실행의 입력으로 연결하고, 실패에서 교훈을 추출해 시스템 전체를 조금씩 개선하는 구조를 뜻한다.
쉽게 말해 워크플로 루프가 지금 이 일을 끝내는 리듬이라면, 피드백 루프는 다음번에는 더 잘하게 만드는 학습 구조다. 둘은 비슷해 보이지만 초점이 다르다. 하나는 진행을 위한 반복이고, 다른 하나는 개선을 위한 반복이다.
이 차이를 이해하면 중요한 사실이 보인다. 에이전트가 똑똑해 보이는 순간은 종종 첫 실행이 아니라, 한 번 실패한 뒤 두 번째 시도에서 방향을 제대로 바꿀 때 나온다. 그때 필요한 것은 "다시 해봐"라는 막연한 재시도가 아니라, 무엇이 왜 틀렸는지 구조화된 신호다.
좋은 피드백 루프는 인과관계가 보여야 한다
피드백이 진짜 피드백이 되려면, 어떤 행동이 어떤 결과를 낳았는지 연결이 보여야 한다. 사용자가 수정을 했는데 시스템이 왜 바뀌었는지 알 수 없고, 시스템이 추천을 바꿨는데 사용자는 무엇이 반영됐는지 체감할 수 없다면, 루프는 돌아가도 신뢰는 쌓이지 않는다. Google PAIR는 좋은 AI 피드백 루프에서 사용자 피드백은 시스템으로 흐르고, 시스템 피드백은 다시 사용자에게 돌아가며, 그 사이의 원인과 결과가 보이는 것이 중요하다고 설명한다.1
이 말은 제품 설계로 옮기면 더 구체적이 된다. 사용자가 "이 답은 틀렸어요"라고 눌렀다면, 시스템은 최소한 다음 중 하나를 해야 한다. 왜 틀렸는지 묻거나, 수정 요청을 남기거나, 다음 실행에서 다른 전략을 시도하거나, 인간 검토 대기열로 보내야 한다. 반대로 아무 일도 일어나지 않으면 그 버튼은 장식일 뿐이다.
좋은 피드백 루프는 그래서 단순히 입력창 하나를 더 만드는 일이 아니다. 행동 → 결과 → 해석 → 반영의 연결선을 보이게 만드는 일이다.
피드백의 종류를 먼저 나눠야 한다
현장에서 피드백 루프가 엉키는 가장 흔한 이유는, 서로 성격이 다른 신호를 한 바구니에 넣기 때문이다. 고객 만족도, 테스트 실패, API 타임아웃, 사람의 승인 거부, 클릭률 하락은 모두 "나쁜 신호"처럼 보이지만, 같은 방식으로 다루면 안 된다.
피드백은 보통 몇 가지 축으로 나눠 생각하면 편하다.
즉시 피드백과 지연 피드백
명시적 피드백과 암묵적 피드백
자동 판정과 인간 판정
실행 오류와 추론 오류와 정책 오류
즉시 피드백은 테스트 실패나 스키마 검증 실패처럼 바로 얻는 신호다. 지연 피드백은 사용자의 후속 행동, 실제 업무 성과, 며칠 뒤 드러난 데이터 품질 문제처럼 시간이 지난 뒤 나타난다. 명시적 피드백은 "틀렸어요", "승인 안 함"처럼 사람이 직접 준 신호이고, 암묵적 피드백은 사용자가 다시 수정했는지, 추천을 무시했는지, 사람이 결국 직접 일을 다시 했는지처럼 행동에서 추론하는 신호다.
이 구분이 중요한 이유는, 피드백의 무게와 용도가 다르기 때문이다. 테스트 실패는 즉시 재시도 규칙으로 연결할 수 있지만, 장기 만족도 하락은 프롬프트 한 줄보다 제품 정책이나 도구 순서를 손봐야 할 수도 있다.
결과를 다시 입력으로 넣는 가장 작은 구조
피드백 루프를 가장 단순하게 그리면 네 단계다. 실행한다. 평가한다. 진단한다. 그 진단을 다음 실행의 입력으로 넣는다. MindStudio의 실무 가이드도 자기 개선 루프의 최소 단위를 작업, 평가 하네스, 진단 피드백, 그리고 다음 실행에서 읽는 지속적 학습 저장소로 설명한다.2
이 구조가 좋은 이유는 화려하지 않아서다. 거대한 자율 학습 시스템이 없어도 된다. 에이전트가 이번 실행에서 실패한 이유를 짧고 구체적인 문장으로 남기고, 다음 실행 시작 전에 그것을 읽기만 해도 성능은 달라질 수 있다.
예를 들어 문서 요약 에이전트가 있다고 해 보자. 평가 결과는 이렇다.
단어 수 제한을 자주 초과함
근거 문장을 인용하지 않음
감정이 없는 리뷰를 긍정으로 과잉 해석함
이 정보를 그냥 로그로만 남기면 아무 일도 일어나지 않는다. 하지만 다음 실행의 시작 컨텍스트에 "50단어 제한 우선, 근거 문장 최소 1개 포함, 감정이 불분명하면 중립으로 처리"라는 식의 교훈으로 넣으면, 시스템은 적어도 같은 실수를 반복할 확률을 낮출 수 있다.2
핵심은 평가 점수 자체보다 행동 가능한 진단 문장이다. 62점보다 "출력 형식은 맞았지만 근거가 빠졌다"가 훨씬 더 쓸모 있다.
자기 수정은 반성문이 아니라 구조다
많은 사람이 자기 수정이라고 하면 모델에게 "다시 생각해봐"라고 한 번 더 말하는 장면을 떠올린다. 물론 그것도 도움이 될 때가 있다. 하지만 제품 수준의 자기 수정은 감상문이 아니라 구조다.
가장 기본적인 형태는 생성 → 비판 → 수정이다. 먼저 초안을 만들고, 그 초안을 기준표로 검사하고, 지적된 문제만 반영해 다시 쓴다. 코드 생성, 보고서 작성, 응답 초안 생성처럼 결과물이 분명한 작업에서 이 구조는 꽤 강력하다.
하지만 여기서 끝나면 아직 반쪽짜리다. 진짜 중요한 것은 비판 결과가 얼마나 구체적인가다. "더 명확하게 쓰세요"는 별 도움이 안 된다. 반면 "필수 필드 owner 누락", "정책상 금지된 표현 포함", "테스트 3개 중 1개 실패"는 다음 행동을 바꿀 수 있다.
즉, 자기 수정의 핵심은 스스로를 꾸짖는 데 있지 않다. 다음 시도에서 무엇을 바꿔야 하는지 명확히 아는 것에 있다.
자기 수정이 잘 작동하지 않는 이유
여기서 한 가지 환상을 버릴 필요가 있다. 모델에게 스스로 검토하고 고치라고 시킨다고 해서, 언제나 잘 고쳐지는 것은 아니다. 실제 연구에서도 단순한 자기 수정은 기대만큼 안정적이지 않으며, 오프라인 교정 흔적만 모아 학습시키는 방식은 분포 차이와 행동 붕괴 문제를 겪을 수 있다고 지적한다.3
쉽게 말하면 이런 일이다. 모델은 자기 답을 다시 읽고도 같은 오류를 고집할 수 있다. 틀린 답을 더 그럴듯하게 포장할 수도 있다. 또는 교정 자체에 과적응해서 사소한 문제도 과하게 수정하다가 원래 맞았던 부분까지 망가뜨릴 수 있다.
그래서 실무의 자기 수정은 "모델이 스스로 잘하겠지"에 기대면 안 된다. 대신 다음 세 가지가 필요하다.
무엇이 실패인지 외부에서 알려주는 검증기
몇 번까지 고칠 수 있는지 정하는 한도
수정 후 정말 나아졌는지 확인하는 재평가
자기 수정은 자율성의 기술이지만, 동시에 외부 검증을 전제로 한 자율성이어야 한다.
피드백은 어디에 꽂을 것인가
좋은 하네스는 피드백을 한 덩어리로 처리하지 않는다. 무엇이 잘못됐는지에 따라 고쳐야 할 위치가 다르기 때문이다. Datagrid의 가이드가 강조하듯, 실행 오류는 도구 계층으로, 추론 오류는 계획 계층으로, 환경 변화는 컨텍스트 계층으로 보내야 한다.4
이 원칙은 매우 실용적이다. 예를 들어 API 타임아웃이 발생했다고 하자. 이것은 보통 모델의 추론 문제라기보다 도구 인터페이스나 재시도 정책 문제다. 반대로 도구는 정상인데 엉뚱한 쿼리를 만들었다면, 계획 수립이나 질의 생성 규칙을 고쳐야 한다. 외부 문서가 오래돼서 잘못 답했다면, 메모리보다 검색 인덱스나 컨텍스트 신선도 관리가 먼저다.
피드백을 잘못 라우팅하면 팀은 자주 엉뚱한 곳을 고친다. 검색이 문제인데 프롬프트만 계속 바꾸거나, 권한 정책이 문제인데 모델 교체를 논의하는 식이다. 그래서 피드백 루프 설계의 핵심 질문 중 하나는 이것이다.
이 실패는 무엇의 실패인가?
대개 후보는 다섯 군데다.
프롬프트와 지시 규칙
컨텍스트와 검색 데이터
도구 인터페이스와 실행 환경
계획 로직과 워크플로
권한 정책과 승인 규칙
이 분해가 되어야 수정도 빨라진다.
작업 중 루프와 작업 간 루프를 분리하라
피드백 루프를 설계할 때 특히 유용한 구분이 있다. 하나는 작업 중 루프이고, 다른 하나는 작업 간 루프다.
작업 중 루프는 한 실행 안에서 일어난다. 테스트가 실패하면 에러 메시지를 읽고 다시 수정한다. 검색 결과가 부족하면 다른 검색어로 한 번 더 찾는다. 이때 피드백은 매우 짧은 시간 안에 들어오고, 같은 세션 안에서 바로 반영된다.
작업 간 루프는 실행이 끝난 뒤에 일어난다. 하루 동안 모인 실패 사례를 모아 새 규칙을 만들거나, 사람이 남긴 수정 이유를 학습 저장소에 정리하거나, 재현 가능한 회귀 세트에 추가하는 식이다. 이 루프는 느리지만 더 안정적이다. 한 번의 우연한 실패가 아니라 반복되는 패턴을 잡아낼 수 있기 때문이다.
이 둘을 섞으면 문제가 생긴다. 세션 중에 나온 임시 추론을 장기 메모리에 곧바로 써 버리면 오염이 퍼질 수 있다. 반대로 작업이 끝난 뒤 반영해야 할 교훈을 매번 실시간 수정으로 처리하면 시스템이 지나치게 들쑥날쑥해진다.
따라서 좋은 하네스는 이렇게 나눈다. 즉시 수정은 세션 안에서, 영구 교훈은 검증 후에만.
메모리를 고칠 때는 배포하듯이 다뤄라
에이전트의 장기 메모리나 정책 저장소를 피드백으로 갱신할 때는 특히 조심해야 한다. 잘못된 사실 하나가 들어가면 이후의 추론 전체가 그 영향을 받기 때문이다. Datagrid는 이런 이유로 메모리 진화를 버전 관리, 검증 게이트, 격리 환경, 자동 롤백이 있는 생산 데이터 파이프라인처럼 다뤄야 한다고 조언한다.4
이 원칙은 무척 중요하다. 많은 팀이 자기 개선을 흥미로운 기능으로 생각하지만, 사실 장기 메모리 갱신은 기능보다 배포에 가깝다. 한 번 잘못 쓰이면 다음 모든 실행을 오염시킬 수 있어서다.
그래서 장기 메모리 업데이트에는 최소한 이런 절차가 필요하다.
새 교훈을 바로 운영 메모리에 반영하지 않는다.
임시 저장소에서 먼저 테스트한다.
실제 대표 시나리오에 대해 성능이 좋아졌는지 본다.
나빠졌다면 이전 버전으로 되돌린다.
쉽게 말해, 메모리도 코드처럼 배포 전 검증과 롤백이 필요하다.
자동 수정은 좁게, 인간 승인은 넓게
자동 수정은 매우 매력적이다. 실패를 알아서 고치고 다시 시도한다니, 듣기만 해도 효율적이다. 하지만 모든 수정이 자동으로 돌아가면 곧 위험해진다. 특히 쓰기 권한, 외부 시스템 변경, 고객 노출 결과물, 비용이 큰 작업에서는 더 그렇다.
실무에서는 자동 수정과 인간 승인 사이에 계단을 두는 편이 좋다. Pedowitz의 실무 요약도 위험하거나 새로운 결정은 먼저 인간 검토에 보내고, 자동 정책 검증기와 오프라인 리플레이, 제한된 실험을 조합해 점진적으로 자율성을 높이라고 제안한다.5
이 계단식 접근은 에이전트 도입에서 매우 현실적이다. 예를 들어 다음처럼 나눌 수 있다.
초안 다시 쓰기, 형식 수정, 테스트 재실행은 자동 허용
고객 메일 발송, 데이터 갱신, 파일 덮어쓰기는 승인 후 실행
삭제, 결제, 권한 변경, 외부 공개는 기본 차단 또는 이중 승인
이렇게 보면 자동 수정의 범위가 명확해진다. 되돌릴 수 있고, 영향 범위가 좁고, 검증 가능한 수정만 자동화하는 것이다.
재시도와 자기 수정을 헷갈리지 말자
실패하면 다시 시도하는 것과, 실패 원인을 반영해 전략을 바꾸는 것은 전혀 다르다. 전자는 재시도이고, 후자는 자기 수정이다.
예를 들어 네트워크 오류 때문에 API 호출이 실패했다면 같은 요청을 다시 보내는 것이 합리적이다. 하지만 잘못된 쿼리를 생성해서 데이터가 비어 나왔다면, 같은 쿼리를 다시 보내는 것은 자기 수정이 아니라 낭비다. 이 경우에는 질의 전략 자체를 바꾸거나 필요한 필터를 조정해야 한다.
그래서 하네스는 실패 유형을 적어도 네 갈래로 나눠 다룰 필요가 있다.
일시적 실패: 제한된 횟수로 재시도
입력 부족 실패: 사용자 질문 또는 추가 검색
계획 실패: 다른 전략으로 재계획
위험 실패: 즉시 중단 후 승인 요청
이 구분이 없으면 시스템은 모든 문제를 "한 번 더"로 해결하려고 한다. 그러면 루프는 금방 비용 먹는 러닝머신이 된다.
사람의 수정 이유를 반드시 남겨라
사람이 에이전트 출력을 고쳤다면, 그 행위는 그냥 수작업이 아니라 아주 귀한 피드백이다. 그런데 많은 시스템은 수정된 최종 결과만 저장하고, 왜 고쳤는지는 남기지 않는다. 그러면 에이전트는 답만 잃는 게 아니라, 교훈을 잃는다.
좋은 피드백 루프는 사람의 개입을 단순한 승인/반려 버튼으로 끝내지 않는다. 최소한 짧은 이유 코드를 남기게 한다. 예를 들어 "사실 오류", "권한 과다", "근거 부족", "형식 위반", "톤 부적절", "실행 금지 작업"처럼 말이다. Pedowitz도 인간 오버라이드가 개선 자산이 되려면 reason code를 기계가 읽을 수 있는 형태로 남겨야 한다고 강조한다.5
이유 코드가 중요한 까닭은 두 가지다. 첫째, 반복 실패를 분류할 수 있다. 둘째, 어디를 고쳐야 할지 라우팅할 수 있다. 예를 들어 반려 이유의 40%가 "최신 정보 반영 실패"라면 검색과 컨텍스트 설계를 손봐야 하고, "승인 없이 발송 시도"가 늘어난다면 권한 정책을 조정해야 한다.
사람의 수정은 비싸다. 그러니 최소한 비싼 개입이 다음번 개선으로 남게 해야 한다.
코드 에이전트에서 배우는 자기 수정의 실전 감각
코딩 에이전트는 자기 수정 구조를 설명하기 좋은 분야다. 코드를 생성하고, 테스트를 돌리고, 실패를 읽고, 다시 고치는 흐름이 눈에 보이기 때문이다. Claude Code의 에이전트 루프 설명처럼, 도구 결과는 다음 판단의 입력으로 다시 들어가고, 모델은 그 피드백을 바탕으로 다음 행동을 정한다.6
예를 들어 인증 버그를 고치는 작업을 맡겼다고 하자. 좋은 하네스는 이렇게 움직인다. 먼저 테스트를 실행한다. 실패 로그를 읽는다. 관련 파일을 찾는다. 수정한다. 다시 테스트한다. 실패가 계속되면 에러 메시지를 바탕으로 다른 가설을 세운다. 반복 횟수나 예산 한도를 넘으면 멈춘다.
이 흐름에서 중요한 것은 "테스트를 다시 돌린다"가 아니다. 테스트 결과가 다음 행동을 바꾸는 근거가 된다는 점이다. 즉, 도구 결과가 곧 피드백이며, 그 피드백이 루프를 수정한다. 이 원리가 문서 작성이든 리서치든 업무 자동화든 똑같이 적용된다.
검토자 루프를 붙이면 무엇이 달라지는가
자기 수정이 약한 이유 중 하나는, 생성자와 검토자가 너무 쉽게 한 몸이 되기 때문이다. 방금 만든 초안을 바로 스스로 통과시켜 버리면 검토가 느슨해진다. 그래서 복잡하거나 위험한 작업에서는 생성자와 검토자를 역할상 분리하는 편이 좋다.
실무 예시도 많다. 구현 후 독립적인 리뷰 단계를 넣는 코드 리뷰 루프나, planner → actor → critic 구조로 실행 후 비평을 붙이는 오케스트레이터는 모두 같은 아이디어를 쓴다. critic은 결과를 pass/fail로 보고, 실패라면 구체적 피드백과 함께 제한된 범위 안에서 재시도하게 만든다.7
이 구조의 장점은 명확하다. 수정 이유가 남고, 재시도 횟수를 통제할 수 있으며, 위험 작업에서 인간 승인 지점을 끼워 넣기 쉽다. 즉, 자기 수정이 더 이상 "모델이 알아서 다시 생각"하는 흐릿한 행동이 아니라, 검토 가능한 운영 절차가 된다.
피드백 루프가 무한 루프가 되지 않게 하려면
피드백이 들어왔다고 해서 항상 계속 돌면 안 된다. 자기 수정 구조의 실패 모드는 크게 두 가지다. 하나는 아무것도 배우지 못한 채 같은 실수를 반복하는 것이고, 다른 하나는 사소한 차이에도 끝없이 다시 고치는 것이다.
이 문제를 막으려면 최소한 세 가지 브레이크가 필요하다.
반복 횟수 한도
무진전 감지
비용 또는 시간 예산
반복 횟수 한도는 단순하지만 효과적이다. 세 번 고쳤는데도 같은 검증기에서 떨어진다면, 네 번째는 대개 비슷한 실패다. 무진전 감지는 더 똑똑한 브레이크다. 점수가 오르지 않거나, 실패 이유 코드가 같거나, 수정 범위만 넓어지고 핵심 문제는 그대로라면 멈춰야 한다. 여기에 비용과 시간 예산까지 붙이면, 자기 수정은 비로소 제품 친화적인 구조가 된다.67
좋은 시스템은 집요하지만, 집착하지는 않는다.
CI/CD와 운영 루프에 연결해야 진짜 개선이 된다
피드백 루프는 세션 안에서만 돌고 끝나면 아깝다. 진짜 가치가 생기는 순간은 운영에서 나온 실패가 다음 배포와 다음 실행에 반영될 때다.
작은 팀이라면 시작은 단순해도 좋다. 한 주 동안 실패한 사례를 모은다. 같은 이유 코드끼리 묶는다. 반복되는 유형을 하나 고른다. 프롬프트, 도구 설명, 검색 규칙, 승인 정책 가운데 어디를 고칠지 정한다. 그다음 회귀 세트로 돌려 본다. 개선이 확인되면 운영에 반영한다.
좀 더 성숙한 팀이라면 여기에 단계가 추가된다. 오프라인 리플레이 세트, 시뮬레이션, 소규모 A/B 테스트, 점진적 롤아웃, 주간 리뷰 cadence를 운영한다.5 이렇게 되면 피드백 루프는 단순한 버그 수정이 아니라 제품 운영 리듬이 된다.
핵심은 한 번의 멋진 수정이 아니다. 실패를 수집하고, 분류하고, 반영하고, 검증하는 주기를 팀의 습관으로 만드는 것이다.
작은 팀이 바로 쓸 수 있는 피드백 루프 설계
처음부터 거대한 자기 개선 시스템을 만들 필요는 없다. 오히려 작은 팀일수록 다음 정도의 구조면 충분하다.
먼저, 중요한 작업 10개에서 실패 로그와 사람 수정 사례를 모은다. 다음으로, 실패 이유를 5~8개 코드로 정리한다. 그다음, 실행 후 자동으로 붙는 짧은 진단 문장을 만든다. 예를 들면 "출처 없음", "정책 위반 가능", "테스트 실패", "과도한 도구 사용" 같은 식이다. 그리고 다음 실행 시작 시 최근 교훈 3개만 읽게 한다. 마지막으로 주 1회, 정말 효과가 있었던 교훈만 장기 규칙으로 승격한다.
이 구조의 장점은 과하지 않다는 점이다. 모든 피드백을 곧바로 영구화하지도 않고, 그렇다고 매번 처음부터 시작하지도 않는다. 임시 교훈과 장기 규칙 사이에 완충 지대를 두는 셈이다.
작업장에 비유하면 이렇다. 자주 쓰는 메모는 책상 위에 올려두고, 정말 검증된 규칙만 작업장 벽에 붙이는 것이다.
피드백 루프가 자리 잡은 팀의 대화 방식
피드백 루프가 없는 팀은 흔히 이렇게 말한다. "가끔 이상하게 틀려요." "이번엔 운 좋게 잘 됐네요." "왜 나아졌는지 정확히는 모르겠어요." 이런 대화는 답답하지만 자연스럽다. 실패가 기록은 되어도, 교훈으로 구조화되지 않았기 때문이다.
반면 피드백 루프가 자리 잡은 팀은 다르게 말한다. "요약 실패의 대부분은 최신 문서 누락에서 시작됩니다." "사람 반려 사유 중 절반이 톤 문제가 아니라 근거 부족입니다." "재시도는 늘었지만 실제 수정 성공률은 오르지 않았습니다."
이 차이는 멋있어 보이기 위한 것이 아니다. 개선의 손잡이가 생겼다는 뜻이다. 어느 계층을 손볼지, 자동화를 어디까지 넓힐지, 사람 승인을 어디에 둘지에 대한 판단이 쉬워진다.
자기 수정의 목표는 완벽함이 아니라 회복력이다
피드백 루프와 자기 수정 구조를 이야기하면, 종종 "그럼 결국 스스로 계속 똑똑해지는 에이전트"를 상상하게 된다. 물론 장기적으로는 그런 방향이 중요하다. 하지만 제품 설계에서 더 먼저 봐야 할 목표는 완벽함이 아니다.
더 현실적인 목표는 이것이다. 실수해도 위험하게 망가지지 않고, 같은 실수를 반복할 가능성을 줄이며, 사람이 개입했을 때 그 개입이 다음 개선으로 남는 시스템. 이것이 회복력 있는 에이전트다.
좋은 하네스는 실패를 없애지 못한다. 대신 실패를 수집하고, 진단하고, 적절한 위치로 라우팅하고, 검증된 교훈만 남기고, 위험한 수정은 사람에게 넘긴다. 이 구조가 있으면 에이전트는 한 번의 영웅적 정답에 기대지 않아도 된다. 틀렸을 때도 다시 일어나는 법을 배우기 때문이다.
앞 장에서 평가 하네스가 진단이라면, 이번 장의 피드백 루프는 치료다. 그리고 다음 장의 관측 가능성은 그 치료가 실제로 잘 되고 있는지 계속 지켜보는 모니터에 가깝다.
참고
2How to Build a Self-Improving AI Agent That Learns From Its Own Mistakes
3Training Language Models to Self-Correct via Reinforcement Learning
4How to Build Self-Improving AI Agents through Feedback Loops
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.