AI를 시스템으로 운영하는 사람과 그냥 사용하는 사람을 가르는 결정적 순간
실수 잡아내는 사람이 더 이상 '나'가 아닌 순간이 바로 그 순간입니다.
지금 대부분의 사람들에게 이 과정은 이렇게 이루어집니다. Claude에게 무언가를 요청합니다. 결과를 읽습니다. 뭔가 잘못된 점을 발견합니다. 지적합니다. 수정된 버전을 받습니다. 다시 읽습니다. 또 다른 문제를 발견합니다. 다시 지적합니다. 여러분은 매번, 모든 작업마다 수동으로 검증 계층 역할을 하는 셈입니다.
자기 수정 루프는 여러분을 그 자리에서 완전히 빼냅니다. 시스템이 결과물을 생성하고, 실제 기준에 따라 스스로 검토한 뒤, 잘못된 부분을 찾아 수정하고, 그다음에야 여러분에게 결과를 보여줍니다. 여러분이 결과물을 볼 때쯤이면 명백한 실수는 이미 발견되어 처리된 상태입니다. 여러분에게 남은 것은 기계의 초안을 교정하는 것이 아니라, 진정으로 사람의 판단이 필요한 부분에 대한 결정입니다.
이것이 완전한 구축입니다. 이 글을 다 읽고 나면 여러분은 정확한 아키텍처, 정확한 프롬프트, 그리고 중요한 작업에 이 시스템을 신뢰하기 전에 반드시 테스트해야 할 정확한 실패 유형을 알게 될 것입니다.
단순히 두 번 물어보는 것과 다른 이유
가장 먼저 떠오르는 본능적인 방법은 같은 대화에서 모델에게 스스로 작업을 검토하라고 요청하는 것입니다. "방금 작성한 내용을 검토하고 실수를 수정해줘." 이 방법은 약간 도움이 됩니다. 하지만 진정한 자기 수정 루프를 구축하지는 못하며, 그 이유를 이해하는 것이 앞으로 설명할 내용의 전체 기초입니다.
모델이 실수를 처음에 발생시킨 동일한 맥락과 동일한 추론 과정으로 자신의 결과물을 검토할 때, 모델은 결과물을 진지하게 분석하기보다는 변호하는 경향을 보입니다. 이는 특정 모델의 결함이 아닌 구조적인 문제입니다. 그럴듯해 보이지만 틀린 답변을 생성한 동일한 과정은 그 답변이 틀렸다는 것을 인지하기에 적합하지 않습니다. 내부적으로 볼 때 그 답변은 여전히 그럴듯하게 들리기 때문입니다. "확실해?"라고 묻는 것은 진정한 재검토보다는 확신에 찬 대답을 더 자주 이끌어냅니다.
해결책은 더 나은 질문이 아닌 아키텍처입니다. 진정한 자기 수정 루프는 답변을 생성하는 작업과 이를 판단하는 작업을 분리합니다. 즉, 다른 과정, 다른 프롬프트, 그리고 이상적으로는 완전히 다른 관점을 사용하여, 실수를 만든 동일한 맹점에 의해 판단이 오염되지 않도록 하는 것입니다.
모든 자기 수정 루프에 필요한 세 가지 역할
작동하는 모든 자기 수정 시스템은, 특정 작업과 관계없이, 세 가지 뚜렷한 역할로 축소됩니다. 이 역할들을 명확히 이해하는 것이 아래의 어떤 특정 프롬프트보다 중요합니다. 왜냐하면 이를 이해하면, 세부 사항을 채워 넣음으로써 거의 모든 작업에 대한 루프를 구축할 수 있기 때문입니다.
빌더 (Builder). 실제 결과물을 생성합니다. 코드를 작성하고, 콘텐츠를 초안 작성하고, 연구를 수행하고, 작업을 실행합니다. 이 역할은 가장 창의적인 재량권과 가장 적은 제약을 받아야 합니다. 그 임무는 완벽한 결과물이 아니라 첫 번째 시도를 생산하는 것이기 때문입니다.
판사 (Judge). 아무것도 구축하지 않습니다. 유일한 임무는 모호한 품질 감각이 아닌, 특정하고 명시된 기준에 따라 빌더의 결과물을 평가하는 것입니다. 코드가 테스트를 통과했는지, 초안이 브리프와 일치하는지, 연구가 실제로 요청된 질문에 답변했는지 등을 확인합니다. 판사는 이상적으로 빌더가 가지고 있지 않은 무언가, 즉 원본 소스 자료, 테스트 스위트, 실제 요구 사항 문서에 접근할 수 있어야 합니다. 이를 통해 동일한 결과물을 다시 읽고 새로운 의견을 형성하는 것보다는 독립적인 근거 진실을 기준으로 확인할 수 있습니다.
관리자 (Manager). 판사의 판결을 읽고 다음에 어떤 일이 일어날지 결정합니다. 구체적인 피드백과 함께 빌더에게 다시 보냅니다. 사람에게 에스컬레이션합니다. 작업을 완료로 표시합니다. 또한 중지 조건이 있는 곳이기도 합니다. 즉, 문제를 자동으로 수정할 수 없을 때 루프가 영원히 실행되는 것을 방지하는 규칙입니다.
세 가지 역할 모두에 걸친 중요한 설계 원칙은 검증이 빌더 자신의 추론 외부에 있는 무언가를 참조해야 한다는 것입니다. 테스트 스위트, 원본 소스 문서, 명시된 체크리스트, 진정으로 다른 프레이밍을 가진 두 번째 AI 호출 등 빌더의 추론 외부에 있는 무언가를 말합니다. "같은 모델에게 같은 맥락에서 다시 묻는 것"이 아닌 어떤 것이든 상관없습니다.
핸드오프 구축하기
자기 수정 루프에서 실제 엔지니어링 작업은 각 역할에 대한 영리한 프롬프트가 아닙니다. 그것은 역할 간에 전달되는 내용의 구조이며, 이것이 대부분의 사람들이 첫 번째 루프를 구축할 때 완전히 건너뛰고서 시스템이 예측 불가능하게 동작하는 이유에 대해 궁금해하는 부분입니다.
핸드오프가 안정적으로 작동하려면 세 가지 속성이 필요합니다. 정의된 형식: 수신 역할이 느슨한 산문을 파싱하고 중요한 것이 무엇인지 추측할 필요가 없도록 합니다. 정의된 트리거: 빌더가 언제 완료되었는지 스스로 결정하지 않도록 합니다. 그리고 정의된 실패 경로: 문제가 깔끔하게 해결되지 않을 때 시스템이 조용히 중단되거나 영원히 루프를 도는 대신 지정된 다음 단계가 있도록 합니다.
실제로 이는 빌더가 대화 형식의 텍스트가 아닌 구조화된 무언가를 출력해야 함을 의미합니다. 명확한 결과물과 함께 자신이 확신하지 못하는 부분에 대한 명시적인 진술을 포함해야 합니다. 그런 다음 판사는 해당 구조화된 출력물을 명시된 기준에 따라 평가하고, 모호한 문장이 아닌 명확한 통과, 실패 또는 수정 필요와 함께 구체적인 이유가 첨부된 구조화된 판결을 반환합니다. 관리자는 해당 구조화된 판결을 읽고, 원시 콘텐츠가 아닌 이를 기반으로 즉흥적인 판단이 아닌 사전에 설정된 규칙에 따라 다음 조치를 결정합니다.
다음은 대부분의 작업(글쓰기, 코드, 연구 등)에 적용되는 템플릿 구조입니다.
1BUILDER OUTPUT FORMAT2Deliverable: [the actual output]3Confidence: [high / medium / low]4Known uncertainties: [anything you are unsure about, stated explicitly]5Assumptions made: [anything you assumed without being told]67JUDGE VERDICT FORMAT8Verdict: [PASS / FAIL / NEEDS REVISION]9Checked against: [the specific standard used, e.g. the original brief,10the test suite, the source document]11Specific issues found: [exact problems, not a general impression]12Confidence in this verdict: [high / medium / low]1314MANAGER ACTION15If PASS: mark complete, deliver to user.16If FAIL or NEEDS REVISION: send back to Builder with the Judge's17specific issues attached. Increment the revision counter.18If revision counter exceeds [N]: stop looping, escalate to human19with full history of what was tried and why it failed.
이는 캐주얼한 대화보다 더 많은 구조처럼 보이며, 실제로 그렇습니다. 이 선행 비용은 여러분에게 첫 번째 실행에서와 같은 방식으로 백 번째 실행에서도 동일하게 동작하여, 맥락이 축적됨에 따라 예측 불가능하게 표류하지 않는 시스템을 제공합니다.
판사에게는 단순한 의견이 아닌 근거 진실이 필요합니다
이것은 전체 시스템에서 가장 중요한 원칙이며, 이를 잘못 이해하면 다른 모든 것을 조용히 무너뜨리기 때문에 별도 섹션으로 다룰 가치가 있습니다.
빌더의 결과물만 보고 독립적인 참조 자료가 없는 판사는 내적 일관성, 즉 결과물이 일관되고 잘 포맷되었는지만 평가할 수 있습니다. 결과물이 실제로 요청된 것과 일치하는지 또는 실제 문제를 해결하는지와 같은 정확성은 평가할 수 없습니다. 자신 있게 틀린 답변이 잘 포맷되고 내적으로 일관성이 있다면, 근거 진실이 없는 판사를 매번 통과할 것입니다.
코딩 작업의 경우, 근거 진실은 테스트 스위트, 코드 실행의 실제 출력, 린트 결과, 빌드 상태입니다. "이 코드가看起来 괜찮아 보이나?"가 아니라 "실제로 실행했을 때 통과했는가?"입니다.
콘텐츠 작업의 경우, 근거 진실은 초안과 나란히 놓인 원본 소스 자료와 원본 브리프입니다. "이 글이 잘 읽히나?"가 아니라 "이 초안의 모든 특정 주장이 소스에 실제로 있는 내용으로 추적 가능하며, 해당 글이 브리프의 모든 요구 사항을 실제로 충족하는가?"입니다.
연구 작업의 경우, 근거 진실은 연구가 기반해야 했던 실제 검색 결과와 소스 문서입니다. "이 요약이 권위적으로 들리나?"가 아니라 "모든 주장이 특정 소스로 추적 가능하며, 검색된 소스가 실제로 관련된 소스였는가?"입니다.
특정 작업에 대한 판사의 근거 진실이 무엇인지 명확히 설명할 수 없다면, 아직 자기 수정 루프를 갖춘 것이 아닙니다. 여러분은 재구성 루프를 가지고 있는 것입니다. 빌더의 자신 있는 실수가 판사에 의해 실제로 발견되지 않고 자신 있게 재구성되는 것입니다.
중지 조건은 선택 사항이 아닙니다
자기 수정 루프가 비용이 많이 들고 통제 불능 상태가 되는 가장 흔한 방법은 명시적이고 강력한 중지 조건이 없는 것입니다. 그것 없이는 빌더와 판사가 무한정 순환할 수 있습니다. 각 수정이 다른 평가를 촉발하고, 각 평가가 다른 수정을 촉발하여 비용이 계속 증가하고 아무도 청구서가 도착할 때까지 알아차리지 못합니다.
실제 중지 조건은 세 가지 구성 요소가 필요하며, 세 가지 모두 모델의 즉흥적인 판단에 맡기지 않고 명시적 로직으로 적용되어야 합니다.
최대 반복 횟수. 수정 주기의 상한선입니다. 이를 초과하면 판사가 만족하는지 여부와 관계없이 관리자가 사람에게 강제로 에스컬레이션해야 합니다.
실제로 측정 가능한 품질 임계값(야망적인 것이 아닌). 프롬프트 내의 "충분히 좋음"이라는 명령은 중지 조건이 아닙니다. 이는 모델이 적절한 압력 하에서 결국 무시할 수 있는 제안에 불과하기 때문입니다. "11개 모든 테스트 케이스 통과" 또는 "초안이 명시된 5가지 브리프 요구 사항을 모두 충족"과 같은 특정하고 확인 가능한 기준은 중지 조건입니다. 이는 매번 주관적으로 판단하는 것이 아니라 기계적으로 검증할 수 있기 때문입니다.
비용 또는 시간 상한선. 해당 상한선에 도달했을 때 작업이 어떤 상태에 있든 관계없이 초과할 수 없는 절대 예산입니다. 이것은 최악의 시나리오, 즉 진정으로 해결 불가능한 작업이 누군가가 인보이스를 알아차릴 때까지 루프를 도는 상황으로부터 여러분을 보호하는 보호 장치입니다.
STOP CONDITIONS
Maximum revisions: 3. On the 3rd failed verdict, stop and escalate
to a human with the full revision history attached, do not attempt
a 4th cycle automatically.
Quality threshold: all items on the Judge's checklist must show PASS,
not "mostly passing" or "close enough."
Budget ceiling: if this task has consumed more than [X] tokens or
[Y] minutes, stop immediately regardless of current state and report
what was completed versus what remains.
이것들을 관리자의 실제 로직에 작성하세요. 모델이 압력에 스스로를 설득할 수 있는 긴 프롬프트 내의 소프트 명령이 아닌, 하드 로직으로 작성하세요.
실제 예시: 자기 수정 콘텐츠 제작
구체적으로 설명하기 위해, 세 가지 역할과 중지 조건이 실제 일반적인 작업(소스 문서를 완성된 콘텐츠로 변환하는 작업, 사람이 모든 초안을 수동으로 교정하지 않고)에 어떻게 함께 적용되는지 정확히 보여드리겠습니다.
빌더는 소스 자료와 브리프를 받아 초안을 생성합니다. 출력물에는 초안 자체와 함께 명시적인 확신 수준 진술 및 작성 중 확신이 없었던 사항(소스에 확실히 있는지 완전히 확신하지 못한 특정 수치, 직접 명시된 것이 아니라 추론한 주장 등) 목록이 포함됩니다.
판사는 초안과 원본 소스를 나란히 받습니다. 초안만 단독으로 받는 경우는 절대 없습니다. 판사는 각각 통과 또는 실패가 있는 세 가지 특정 사항을 확인합니다. 초안의 모든 사실적 주장이 소스에 실제로 있는 내용으로 추적 가능한가? 초안이 브리프의 모든 특정 요구 사항(분량, 톤, 필수 섹션)을 충족하는가? 핵심 논점 또는 훅이 실제로 존재하며 군더더기로 희석되지 않았는가? 판사는 세 가지 각각에 대해 통과 또는 실패가 포함된 구조화된 판결을 반환합니다. 이를 하나의 전체 점수로 통합하면 정확히 어떤 차원이 실패했는지 숨겨지기 때문입니다.
관리자는 해당 구조화된 판결을 읽습니다. 세 가지 모두 깨끗하게 통과하면 초안은 최종 출력 큐로 전송됩니다. 사실 확인 차원에서 실패하면 검증되지 않은 특정 주장이 직접 플래그 지정된 상태로 빌더에게 다시 전송됩니다. 브리프 준수 차원에서 실패하면 누락된 특정 요구 사항이 명명된 상태로 다시 전송됩니다. 동일한 특정 확인에서 세 번의 실패 주기 후에 관리자는 루프를 완전히 중단하고 시도된 내용의 전체 기록과 함께 사람에게 에스컬레이션합니다. 시스템이 이미 스스로 해결할 수 없음을 입증한 문제를 계속 재시도하지 않습니다.
이것은 작은 시스템입니다. 세 가지 역할, 하나의 구조화된 핸드오프 형식, 하나의 명시적 중지 조건입니다. 또한 여러분이 실제로 무인으로 실행하고 그 결과물을 신뢰할 수 있는 시스템입니다. 모든 실패 유형에 대해 정의되지 않은 경로 대신 정의된 경로가 있기 때문입니다.
신뢰하기 전에 루프 테스트하기
실제로 중요한 무언가에 자기 수정 시스템을 의존하기 전에, 의도적으로 다음 특정 스트레스 테스트를 통해 시스템을 실행하세요. 실제 사용에서 실패하는 대부분의 루프는 누군가가 먼저 확인하려고 했더라면 이 테스트 중 하나에서 즉시 실패했을 것입니다.
해결 불가능 작업 테스트. 의도적으로 빌더에게 판사의 기준을 충족할 수 없는 작업을 주세요. 관리자가 올바르게 반복 상한선에 도달하여 사람에게 에스컬레이션합니까, 아니면 성공할 수 없었던 작업에 비용을 소모하며 무한정 회전합니까?
자신 있게 틀린 테스트. 이미 미묘하게 틀렸다고 알고 있는 결과물(읽기에는 좋지만 특정 사실적 또는 논리적 오류가 포함된)을 판사에게 제공하세요. 판사가 근거 진실 참조를 통해 올바르게 잡아냅니까? 판사가 여러분이 알고 있기에 잘못된 것을 통과시킨다면, 여러분의 근거 진실 참조가 실제로 확인되고 있지 않거나 확인이 너무 얕은 것입니다.
동일 모델 맹점 테스트. 빌더와 판사가 동일한 기본 모델에서 실행되는 경우, 이는 직접 확인할 가치가 있습니다. 판사에게 해당 모델이 특징적으로 저지르기 쉬운 종류의 실수가 포함된 결과물을 제공하세요. 판사가 그것을 통과시킨다면, 여러분은 역할 간에 맹점을 공유하는 루프를 구축한 것이며, 이는 역할을 분리하는 전체 목적을 무효화합니다. 판사 역할에 대해 진정으로 다른 모델을 사용하거나, 최소한 의미 있게 다른 프롬프트 프레이밍을 사용하는 것을 고려하세요.
비용 폭주 테스트. 시스템을 통한 최악의 경로(최대 수정, 관련된 가장 비싼 모델 호출, 가장 긴 합리적 콘텐츠 길이)를 계산하고 실제 비용과 실제 시간으로 얼마인지 산출하세요. 그 숫자가 실제 청구서에 나타나는 것을 보고 놀라게 될 것이라면, 중지 조건이 충분히 엄격하지 않은 것입니다.
실제 무언가에 자기 수정 루프를 신뢰하기 전에 이 네 가지 테스트를 실행하면, 그렇지 않으면 클라이언트, 상사 또는 은행 명세서 앞에서 처음으로 나타날 대다수의 실패를 잡아낼 수 있습니다.
잘 설계된 시스템을 조용히 망가뜨리는 일반적인 실수
올바른 세 가지 역할 아키텍처를 갖추고 있더라도, 완전히 다른 도메인에서 반복적으로 나타나는 몇 가지 특정 구현 실수가 있습니다. 이것들을 미리 알면 각각을 어렵게 다시 발견하는 수고를 덜 수 있습니다.
판사가 빌더의 결과물만 보고 독립적인 참조 자료를 보지 못하게 하는 것. 이것은 가장 흔한 실수이며, 시스템을 정확성 검사에서 일관성 검사로 조용히 바꿔버립니다. 비교할 대상이 없는 판사는 결과물이 내적으로 일관되어 보인다고만 말할 수 있을 뿐, 실제로 올바른지는 결코 알려줄 수 없습니다.
모든 역할에 얇은 명령 차이만 덧붙인 동일한 모델을 제공하는 것. 판사가 빌더와 정확히 동일한 기본 모델을 실행하고, 단지 "비판적으로 검토하라"는 다른 프롬프트만 있다면, 빌더와 정확히 동일한 맹점을 종종 상속받습니다. 왜냐하면 근본적으로 같은 추론 과정이 다른 모자를 쓰고 있기 때문입니다. 예산이 허락하는 곳에서는 판사 역할에 진정으로 다른 모델을 사용하면 연극적인 독립성이 아닌 실제 독립성을 만들어냅니다.
관리자를 단순한 통과 채널로 취급하고 이전 시도에 대한 실제 기억을 주지 않는 것. 이 특정 작업에서 이미 무엇이 시도되었는지에 대한 가시성이 없는 관리자는 기꺼이 동일한 실패한 피드백을 빌더에게 두세 번째 보낼 것이며, 매번 동일한 실패한 결과를 생성할 것입니다. 시스템이 이 정확한 접근 방식이 이미 한 번 실패했다는 것을 기억하지 못하기 때문입니다.
모두가 면밀히 주시한 단일 데모 실행에서 시스템이 잘 작동했다는 이유로 네 가지 스트레스 테스트를 건너뛰는 것. 여러분이 면밀히 지켜볼 때 올바르게 동작하는 시스템과 무인으로 실행될 때 올바르게 동작하는 시스템은 다른 주장입니다. 두 번째 것만이 자기 수정 루프를 구축하는 실제 요점입니다. 실패 모드를 의도적으로 테스트하지 않았다면, 여러분의 시스템에 대해 어떤 주장이 사실인지 실제로 알지 못하는 것입니다.
중지 조건을 하드 로직이 아닌 소프트 명령으로 작성하는 것. 프롬프트 내의 "충분히 좋아지면 멈춰"는 중지 조건이 아닙니다. 이는 모델이 적절한 압력 하에서 결국 스스로를 설득하여 넘어갈 수 있는 제안입니다. 관리자가 다른 주기를 허용하기 전에 기계적으로 확인하는 하드 반복 카운터는 중지 조건입니다. 이 둘의 차이는 작업이 진정으로 해결 불가능한 것으로 판명되는 첫 번째 순간에 엄청나게 중요합니다.
두 번째 실제 예시: 자기 수정 코드
동일한 뼈대는 작업이 콘텐츠 대신 코드일 때 다르게 보이지만 동일한 로직을 따릅니다. 두 가지를 나란히 살펴보면 도메인 간에 실제로 얼마나 변경되는지 명확해집니다.
여기서 빌더는 정의된 작업(버그 수정, 기능, 리팩터링)을 수행하는 코딩 에이전트입니다. 구조화된 출력물은 코드 diff뿐만 아니라 실행을 시도한 실제 명령 출력, 테스트 결과, 린트 출력, 빌드 상태를 핸드오프에 번들로 포함합니다. 코드를 생성하지만 실제로 실행하지 않는 빌더는 빌더 역할을 올바르게 수행하는 것이 아닙니다. 구문적으로 그럴듯해 보이지만 자체 테스트 스위트를 통과하지 못하는 코드는 코드가 없는 것보다 더 나쁩니다. 완성된 것처럼 보이지만 실제로는 완성되지 않았기 때문입니다.
판사는 세 가지 특정하고 검증 가능한 사항을 확인합니다. 변경 사항이 테스트 자체를 수정하지 않고 기존 테스트 스위트를 통과했는가? (빌더가 조용히 테스트를 편집하여 통과시키는 것은 특정하고 놀랍게도 흔한 실패이므로 직접 확인할 가치가 있습니다.) 정적 분석과 린팅이 깨끗하게 나왔는가? diff가 실제로 할당된 작업을 해결하는가, 아니면 빌더가 가는 길에 해결하는 것이 더 흥미롭다고 판단한 관련이 있지만 다른 문제를 해결하는가? 각각은 구조화된 판결에서 자체 명시적 통과 또는 실패를 받습니다.
관리자는 실패한 특정 확인에 따라 라우팅합니다. 실패한 테스트 스위트는 정확한 실패한 테스트 출력이 직접 첨부된 상태로 빌더에게 다시 전송됩니다. 할당된 것과 다른 문제를 해결한 범위 불일치는 루프를 도는 대신 즉시 사람에게 에스컬레이션됩니다. 이는 작업이 실제로 무엇인지에 대한 판단 실패이기 때문이며, 빌더가 스스로 반복을 통해 해결할 수 있는 기계적 결함이 아닙니다.
여기서 기본 뼈대가 콘텐츠 제작 예제와 동일하다는 점에 주목하세요. 빌더는 증거와 함께 결과물을 생성 및 제출하고, 판사는 확인별 판결과 함께 지정된 특정 기준에 대해 확인하며, 관리자는 정확히 어떤 확인이 실패했는지에 따라 라우팅합니다. 이것이 두 가지 다른 도메인을 나란히 보는 것에서 얻을 수 있는 실제 교훈입니다. 뼈대가 올바르게 되면, 새로운 종류의 작업에 적용하는 것은 주로 판사를 위한 새로운 특정 체크리스트를 작성하는 문제이지, 매번 처음부터 전체 아키텍처를 재설계하는 것이 아닙니다.
여러 개의 동시 루프로 확장하기
단일 자기 수정 루프가 진정으로 신뢰할 수 있게 되면, 다음 실제 질문은 시스템이 관리 불가능해지지 않으면서 여러 개를 동시에 실행하는 방법입니다. 이것이 바로 대부분의 사람들이 확장을 시도할 때 잘못되는 지점입니다.
첫 번째 루프가 작동하자마자 여러 루프를 동시에 시작하고, 아키텍처가 기술적으로 이를 지원하기 때문에 다섯 가지 다른 작업을 병렬로 처리하려는 유혹이 있습니다. 필요 이상으로 오래 저항하세요. 각 추가 동시 루프는 중지 조건이 조용히 실패할 수 있는 또 다른 장소이고, 비용이 감지되지 않고 폭주할 수 있는 또 다른 장소이며, 판사의 근거 진실 참조가 단일 테스트 실행보다는 실제 볼륨에서만 나타나는 방식으로 미묘하게 잘못될 수 있는 또 다른 장소입니다.
더 안전한 확장 경로는 각 단계에서 진정한 신뢰 임계값을 사용한 순차적 확장입니다. 하나의 루프가 여러분이 출력을 면밀히 확인하는 것을 중단할 정도로 충분히 안정적으로 실행될 때까지, 즉 단일 성공적인 데모 실행이 아닌 실제 시간 동안 여러분의 수동 스팟 점검을 일관되게 통과할 때까지 기다리세요. 그런 다음에만 다른 작업을 위한 두 번째 루프를 추가하세요. 각 루프의 실제 실패율을 시간 경과에 따라 추적하세요. 우연히 관찰한 실행에서 작동하는 것처럼 보였는지 여부만이 아닙니다.
여러 루프를 동시에 실행할 때는 개별 루프 추적을 고립적으로 수행하는 대신 모든 루프에 걸친 공유 비용 대시보드를 진지하게 고려하세요. 작업당 합리적인 예산을 가진 단일 루프는 고립적으로 볼 때 완전히 괜찮아 보입니다. 각각 개별적으로 예산 내에 있는 10개의 루프는 여전히 진정으로 놀라운 총계를 합산할 수 있으며, 각 개별 루프의 추적이 자체적으로는 괜찮아 보였기 때문에 총계 청구서가 도착할 때까지 아무도 알아차리지 못합니다.
확장 문제가 시작되기 전에 방지하는 단일 습관: 성공적인 완료뿐만 아니라 모든 루프의 모든 중지 조건 트리거를 기록하세요. 최대 반복 상한선에 도달하여 사람에게 에스컬레이션하는 루프는 정확히 해야 할 일을 하는 것입니다. 하지만 하나의 특정 루프가 다른 루프가 거의 그렇지 않은 동안 지속적으로 해당 상한선에 도달한다면, 이는 해당 특정 작업에 대한 판사의 기준이 잘못 조정되었거나, 실제로 통과하기에는 너무 엄격하거나, 완전히 잘못된 근거 진실에 대해 확인하고 있다는 신호입니다. 성공만 추적하고 모든 에스컬레이션을 고립되고 평범하지 않은 사건이 아닌 해당 특정 루프 설계에 대한 데이터 포인트로 취급한다면 이 패턴은 보이지 않습니다.
이번 주에 시작할 곳
첫 번째 시도에서 완전히 일반적인 자기 수정 시스템을 구축하려고 하지 마세요. 이미 정기적으로 수행하는 하나의 특정하고, 좁고, 잘 정의된 작업을 선택하세요. 요청 시 적어둘 수 있는 명확한 기준이 있는 작업을 선택하고, 먼저 해당 단일 작업 주위에 세 가지 역할 루프를 구축하세요.
빌더 프롬프트의 한 줄을 작성하기 전에 판사의 체크리스트를 명시적으로 적어두세요. 확인하는 기준이 빌더에게 무엇을 생성하도록 요청할지 결정해야 하며, 그 반대가 되어서는 안 됩니다. 아직 체크리스트를 작성할 수 없다면, 이 작업에 대해 "올바른" 것이 무엇인지 아직 자동화 검사를 할 만큼 충분히 알지 못하는 것이며, 이는 무엇이든 구축하기 전에 발견할 가치가 있습니다.
실제로 중요한 것에 루프를 신뢰하기 전에 위의 네 가지 스트레스 테스트를 실행하세요. 누군가 앞에서 이미 문제가 발생한 후가 아니라요. 첫 번째 버전부터 중지 조건을 실제 하드 로직으로 추가하세요. 한 번 폭주 루프에 당한 후의 사후 고려가 아니라요.
일단 하나의 루프가 진정으로 신뢰할 수 있게 되면(무인으로 실행되고, 실제 실수를 잡아내고, 필요한 경우 깔끔하게 중지됨), 두 번째 루프는 훨씬 더 빨라집니다. 프롬프트가 직접 전송되기 때문이 아니라(보통 새 작업을 위해 다시 작성해야 함), 문제의 실제 형태를 이미 이해했기 때문입니다. 구축과 판단을 분리하세요. 판단에 실제로 확인할 수 있는 무언가를 제공하세요. 중지 조건을 희망이 아닌 로직으로 작성하세요.
그 형태가 전체 훈련입니다. 다른 모든 것은 단지 여러분 앞에 있는 작업에 그것을 적용하는 것일 뿐입니다.
이 글의 모든 내용 뒤에 있는 정확한 루프 템플릿과 빌더-판사-관리자 설정을 보려면 @cyrilXBT를 팔로우하세요.
