루프 엔지니어링: AI 자동화를 위한 20단계 가이드

2026 년 6월, 일주일 만에 세 사람이 독립적으로 같은 아이디어에 도달했습니다.

OpenClaw 의 개발자 Peter Steinberger 는 코딩 에이전트에게 프롬프트를 입력하는 것을 멈추고, 그 에이전트에게 프롬프트를 입력하는 루프를 설계하라고 공개적으로 말했습니다. 거의 동시에, Anthropic 에서 Claude Code 를 이끄는 Boris Cherny 는 더 이상 Claude 에 직접 프롬프트를 입력하지 않고, Claude 에게 프롬프트를 입력하고 무엇을 해야 할지 파악하는 루프를 실행하고 있으며, 자신의 실제 업무는 루프를 작성하는 것이라고 말했습니다. 며칠 후, Google 의 엔지니어 Addy Osmani 가 이 용어를 정리하고 이름을 붙였습니다: 루프 엔지니어링.

그들 중 누구도 이 관행을 완전히 처음부터 발명한 것은 아닙니다. 그들은 이미 일어나고 있던 일에 이름을 붙였습니다. 그 기반이 되는 도구들이 조용히 임계점을 넘었기 때문입니다. 코딩 에이전트는 감독 없이 실제 작업을 완료할 수 있을 만큼 신뢰할 수 있게 되었습니다. 스케줄링은 작업을 타이머에 반복적으로 실행하는 것이 낭비처럼 보이지 않을 만큼 저렴해졌습니다. 단일 에이전트 실행 비용은 다섯 번 시도하는 것이 한 번 신중하게 생각하는 것보다 비용이 덜 들 정도로 충분히 낮아졌습니다.

그 임계점이 이 로드맵이 존재하는 이유입니다. 프롬프팅은 인간이 키보드에 앉아 에이전트에게 한 줄씩 지시해야 할 때 필요한 기술이었습니다. 루프 엔지니어링은 이제 에이전트에게 목표를 주고 실행하도록 맡길 수 있을 때 필요한 기술입니다. 이것은 하나에서 다른 것으로 가는 완전한 20단계 경로이며, 순서대로 나열되어 있습니다. 그 이유는 순서가 개별 단계보다 더 중요하기 때문입니다.

단계 자체를 설명하기 전에 순서가 특히 중요한 이유는 다음과 같습니다. 루프 엔지니어링은 있거나 없는 단일 기술이 아닙니다. 그것은 스택과 같아서, 각 계층은 그 아래 계층이 실제로 견고해야 합니다. 실제 중지 조건(10단계)을 갖추기 전에 스케줄링 트리거(14단계)를 구축하는 것은 단지 당신이 지켜보고 있을 때뿐만 아니라 당신이 없을 때도 돈을 낭비할 수 있는 시스템을 자동화했다는 것을 의미합니다. 실제 검증(6단계와 7단계)을 갖추기 전에 지속성(11단계)을 구축하는 것은, 잘못된 출력을 승인하는 심사관으로부터 얻은 교훈을 신중하게 기록하고 있다는 것을 의미하며, 이는 지속성 계층을 단순히 쓸모없게 만드는 것이 아니라 적극적으로 해롭게 만듭니다. 이 목록에서 앞서 나가는 것은 단지 기능을 놓치는 것을 의미하지 않습니다. 그것은 실제로 그것을 지탱할 수 없는 기반 위에 흥미로워 보이는 부분을 구축하고, 무언가가 이미 규모에 맞게 잘못된 후에야 그것을 발견하는 것을 의미합니다.

1 단계: 병목 현상이 모델이 아니라 당신임을 인정하십시오

첫 번째 실제 단계는 기술적인 것이 아닙니다. 현재 워크플로우의 제한 요소가 모델의 능력이 아니라 루프 안에 있는 당신 자신임을 인정하는 것입니다. 매번 응답을 기다리고, 읽고, 다음 지침을 입력할 때마다, 당신은 시스템에서 가장 느린 부분입니다. 모델은 당신이 감독할 수 있는 것보다 훨씬 빠르게 행동하고, 확인하고, 재시도할 수 있습니다.

이 단계에는 첨부된 프롬프트가 없습니다. 그것은 결정입니다. 당신이 이것을 실제로 믿기 전까지는, 이후의 모든 단계가 실제 병목 현상을 제거하는 것처럼 느껴지지 않고 불필요한 오버헤드처럼 느껴질 것입니다.

2 단계: 더 긴 프롬프트를 더 나은 시스템과 혼동하지 마십시오

무언가 잘못되었을 때의 본능은 같은 프롬프트에 다른 지침을 추가하는 것입니다. 몇 달에 걸쳐 이것은 모델이 작업 기억에 한 번에 모두 담을 수 없는, 밀도 높고 모순된 규칙의 벽을 생성하며, 모델은 가장 최근에 느껴지는 것에 패턴 매칭하고 나머지는 조용히 삭제합니다.

루프 엔지니어링은 이 본능을 완전히 대체합니다. 프롬프트에 규칙을 추가하는 대신 시스템에 다른 구성 요소를 추가합니다. 검증 단계. 메모리 파일. 예약된 트리거. 프롬프트 자체는 주변 시스템이 더 강력해짐에 따라 시간이 지남에 따라 더 짧아져야 하며, 그 반대가 되어서는 안 됩니다.

3 단계: 모든 작업을 5가지 동작으로 보는 법을 배우십시오

특정 도메인에 관계없이 루프의 단일 턴은 5가지 동작으로 분해됩니다. 발견(Discovery), 실제로 무엇이 필요한지 파악하는 것. 핸드오프(Handoff), 실행할 작업을 전달하는 것. 검증(Verification), 실제 결과에 대해 결과를 확인하는 것. 지속성(Persistence), 손실되지 않도록 무슨 일이 일어났는지 기록하는 것. 스케줄링(Scheduling), 이것이 언제 다시 실행될지 결정하는 것.

대부분의 사람들의 현재 워크플로우에는 이 동작 중 두 가지만 명시적으로 있습니다. 발견과 핸드오프는 수동으로, 채팅 창에서 수행됩니다. 나머지 세 가지는 존재하지 않거나 사람의 머릿속에서 보이지 않게 발생합니다. 루프 엔지니어링은 다섯 가지 동작을 모두 명시적이고 자동으로 만드는 관행입니다.

4 단계: 첫 번째 실제 후보 작업을 식별하십시오

무언가를 구축하기 전에, 이미 반복적으로 수행하고 있고, 요청하면 적어 둘 수 있는 기준이 있는 작업 하나를 선택하십시오. 가장 어려운 문제가 아닙니다. 완전히 새로운 것이 아닙니다. 실제로 인식 가능한 완료 정의가 있는 작업, 동료가 보고 즉시 올바르게 완료되었는지 여부에 동의할 수 있는 작업입니다. 이 제약 조건은 보이는 것보다 더 중요합니다. 명확한 완료 정의가 없는 작업은 3단계인 검증을 위해 구축될 수 없으며, 실제 검증이 없는 루프는 루프가 아니라 감독되지 않은 추측에 불과합니다.

5 단계: 프롬프트를 작성하기 전에 완료 정의를 작성하십시오

이것은 대부분의 사람들이 건너뛰는 단계이며, 그 이후의 모든 것이 작동하는지 여부를 결정하는 단계입니다. 에이전트에 대한 단일 지침을 작성하기 전에, 올바른 결과가 어떻게 보이는지 일반 언어로 정확히 적어 두십시오. 모호한 품질 감각이 아닌, 구체적이고 확인 가능한 기준입니다.

<code-segment id="4" lang="text">

[작업 이름]에 대한 완료 정의:

[구체적이고 확인 가능한 기준 1]
[구체적이고 확인 가능한 기준 2]
[구체적이고 확인 가능한 기준 3] 출력이 완전해 보이거나 세련되어 보이더라도 위의 항목 중 하나라도 누락되면 이 작업은 완료된 것이 아닙니다. </code-segment>

선택한 작업에 대해 이것을 작성할 수 없다면 4단계로 돌아가 다른 작업을 선택하십시오.

6 단계: 빌더와 심사관을 분리하십시오

모든 루프에서 가장 중요한 단일 아키텍처 결정입니다. 작업을 생성하는 역할과 작업을 확인하는 역할은 분리되어야 합니다. 모델이 자신의 출력을 생성한 동일한 호흡으로 검토할 때는 진정으로 면밀히 조사하기보다는 해당 출력을 방어하는 경향이 있기 때문입니다.

빌더는 창의적인 재량권을 받고 첫 번째 시도를 생성합니다. 심사관은 빌더의 출력과 5단계의 완료 정의를 받으며, 그것을 설득할 필요가 없는 다른 것은 없습니다. 이상적으로 심사관은 빌더가 가지고 있지 않은 무언가(테스트 스위트, 원본 문서, 실시간 데이터)에 접근할 수 있어야 하며, 그 판결은 첫 번째 판결과 같은 방식으로 형성된 단순한 두 번째 의견이 아닌 실제 증거에서 비롯됩니다.

7 단계: 심사관에게 단순한 의견이 아닌 실제 사실을 제공하십시오

빌더의 출력만 보는 심사관은 그것이 일관되어 보이는지 여부를 알려줄 수 있습니다. 그것이 실제로 올바른지 여부는 알려줄 수 없습니다. 코딩 작업의 경우 실제 사실은 테스트 스위트와 실제 실행 출력입니다. 콘텐츠 작업의 경우 원본 자료와 브리프를 초안과 나란히 비교하는 것입니다. 연구 작업의 경우 사용되었어야 하는 실제 문서입니다.

심사관이 확인할 특정 실제 사실의 이름을 지정할 수 없다면, 심사관의 언어가 아무리 확신에 차 있어 보여도 루프에 아직 실제 검증이 없는 것입니다.

8 단계: 핸드오프 프롬프트를 작성하기 전에 핸드오프 형식을 작성하십시오

빌더의 출력과 심사관의 판결 모두 자유로운 흐름의 산문이 아닌 정의된 구조가 필요합니다. 그렇지 않으면 다음 단계의 관리자가 라우팅할 신뢰할 수 있는 것이 없습니다.

<code-segment id="6" lang="text">

빌더 출력: 결과물 + 신뢰도 + 알려진 불확실성

심사관 판결: 통과 / 실패 / 수정 필요 + 발견된 특정 문제 +

이것이 어떤 실제 사실과 비교하여 확인되었는지

</code-segment>

9 단계: 자동화하기 전에 수동으로 한 번, 처음부터 끝까지 실행하십시오

스케줄링이나 자동 재시도를 연결하기 전에, 전체 빌더-심사관 순서를 직접 수동으로 한 번 실행하십시오. 심사관의 판결을 비판적으로 읽으십시오. 당신도 그것에 동의했을까요? 심사관이 당신이 잘못 알고 있다고 알고 있는 것을 통과시켰거나, 실제로 괜찮았던 것을 실패했다면, 계속 진행하기 전에 실제 사실이나 기준을 수정하십시오. 깨진 검증 단계를 자동화하면 더 빠르게 잘못된 결과만 생성됩니다.

5단계부터 9단계까지의 실제 예시

마지막 다섯 단계를 구체적으로 만들기 위해, 실제 일반적인 작업(원본 문서를 완성된 콘텐츠로 바꾸는 것)에서 어떻게 작동하는지 보여드리겠습니다.

5단계의 완료 정의: 초안의 모든 사실적 주장은 원본 문서에 실제로 존재하는 것으로 거슬러 올라갑니다. 초안은 브리프의 모든 특정 요구 사항(길이, 어조, 필수 구조)을 충족합니다. 핵심 주장은 채워지는 내용으로 희석되지 않고 명확하게 살아 있습니다.

6단계의 빌더는 소스와 브리프를 받고 초안을 생성하며, 작성하는 동안 불확실했던 것(소스에 완전히 확신하지 못한 숫자, 명시적으로 명시된 것이 아니라 추론한 주장)에 대한 명시적인 진술을 함께 생성합니다.

7단계의 심사관은 초안만이 아닌 원본 소스와 나란히 초안을 받고, 세 가지 완료 정의 기준 각각을 개별적으로 확인하여, 혼합된 전체 점수 대신 각각에 대해 개별적으로 통과 또는 실패를 반환합니다. 세 가지 개별 확인을 단일 판결로 통합하면 실제로 어떤 차원이 실패했는지 정확히 숨겨지며, 이는 작동하는 루프가 조용히 유용한 피드백 제공을 중단하는 가장 일반적인 방법입니다.

8단계의 핸드오프 형식은 심사관의 판결이 구조화된 객체(회피적인 산문 단락이 아닌, 세 가지 명시적인 통과 또는 실패 결과와 실패에 대한 특정 이유)로 도착함을 의미합니다.

9단계에 따라 자동화하기 전에 수동으로 한 번 실행하면, 심사관이 너무 관대해서(작문 스타일이 세련되었다는 이유로 조작된 통계가 포함된 초안을 통과시키는 경우) 또는 너무 엄격해서(실제로 브리프에 없었던 스타일 선호도 때문에 초안을 실패시키는 경우)인 경우를 잡아낼 수 있습니다. 두 가지 실패 모드는 첫 번째 시도에서 흔하며, 루프가 이미 감독 없이 50번 실행된 후에 발견하는 것보다 수동으로 한 번 잡는 것이 훨씬 저렴합니다.

10 단계: 관리자와 중지 조건 구축

관리자는 심사관의 판결을 읽고 다음에 무엇을 할지 결정합니다. 이것은 또한 루프의 중지 조건이 있는 곳이며, 모델이 설득할 수 있는 부드러운 지침이 아닌 하드 로직으로 작성되어야 합니다.

<code-segment id="7" lang="text">

중지 조건:

최대 수정 횟수: 3. 3번째 실패 판결 시, 전체 기록과 함께 사람에게 에스컬레이션하고,

4번째 주기를 시도하지 마십시오.

품질 임계값: 완료 정의의 모든 항목이 통과를 표시해야 합니다.

예산 상한: 이 작업이 [X] 비용 또는 [Y] 시간을 초과하면,

현재 상태에 관계없이 즉시 중지하십시오.

</code-segment>

실제 중지 조건이 없는 루프는 시스템이 아닙니다. 작업이 진정으로 해결 불가능한 것으로 판명될 날을 기다리는 책임입니다. 여기서 부드러운 지침이 실패하는 특정 이유를 이해하는 것이 가치 있습니다. "충분히 좋아지면 중지"라는 프롬프트 내의 지침은 제안이며, 충분한 압력(이미 여러 번 수정에 실패한)을 받은 모델은 종종 현재 시도가 충분히 가깝다고 스스로를 설득하여 통과시키려고 합니다. 정확히는 작업에 대한 만족스러운 해결책을 생성하려는 욕구 때문입니다. 코드에 의해 기계적으로 확인되거나 관리자가 논리적으로 우회할 수 없는 명시적 규칙에 의해 확인되는 하드 반복 카운터에는 그런 실패 모드가 없습니다.

11 단계: 지속성 추가, 루프가 실행 간에 기억하도록

실행할 때마다 매번 0부터 시작하는 루프는 지난번에 배운 것을 기억하지 못합니다. 간단한 지속성 계층(진정으로 새로운 교훈당 하나의 파일, 상단에 한 줄 요약 포함)을 추가하여 배우거나 수정한 내용과 그것이 중요한 이유를 기록하십시오. 중요하게도, 다른 곳에 이미 포착되지 않은 것만 기록하십시오. 중복된 메모리는 지식이 아닌 잡음입니다.

이 단계를 장기적으로 실제로 작동하게 만드는 규율은 쓰기 시점의 자제력입니다. 본능은 세션에서 발생한 모든 것을 기록하는 것이며, 이는 정확히 이 로드맵이 2단계에서 경고한 부풀려진 대본 문제를 프롬프트 대신 메모리 폴더로 옮긴 것에 불과합니다. 기록할 가치가 있는 교훈은 잊혀질 경우 다시 발견하는 데 실제 시간이 소요되는 것이며, 예상대로 성공한 일상적인 작업의 기록이 아닙니다.

12 단계: 정기적으로 통합 패스 추가

지속성만으로는 결국 부풀려진 프롬프트와 동일한 문제(수십 개의 파일, 대부분이 같은 내용의 약간 다른 버전을 말하는)를 생성합니다. 정기적인 일정(주간이 합리적)에 따라 메모리 파일을 검토하고, 중복을 단일하고 더 선명한 교훈으로 병합하고, 이후에 잘못된 것으로 판명된 것은 삭제하십시오. 목표는 지속적으로 증가하는 더미가 아니라, 각각 더 많은 밀도를 가진 더 적은 수의 파일입니다.

이 단계는 대부분의 사람들이 완전히 건너뛰는 단계입니다. 자체적으로는 눈에 띄는 새로운 기능을 생성하지 않고 미래의 문제만 방지하기 때문입니다. 그 보이지 않음이 바로 명시적으로 일정을 잡아야 하는 이유이며, 누군가가 메모리 폴더가 다루기 힘들어졌다는 것을 알아차릴 때마다 발생하도록 두어서는 안 됩니다. 실제로는 루프의 성능이 모순되고 반쯤 관련된 교훈이 동일한 컨텍스트 창을 놓고 경쟁하면서 저하되기 시작할 때까지 절대 발생하지 않습니다.

13 단계: 회상 단계 추가

새로운 실행을 시작할 때마다 루프가 메모리의 한 줄 요약을 스캔하고, 현재 작업에 실제로 관련된 교훈을 식별하고, 해당 교훈만 로드하도록 하십시오. 메모리가 존재한다는 이유만으로 관련 없는 과거 교훈을 새로운 상황에 억지로 맞추기보다는, 메모리에 적용되는 것이 없을 때 명시적으로 말하도록 지시하십시오.

14 단계: 스케줄링 트리거 추가

이 루프가 수동으로 시작하지 않고도 실행되는 시점을 결정하십시오. 크론 작업. 파일 감시자. 반복되는 캘린더 기반 트리거. 이 단계는 요청 시 실행하는 시스템을 잠잘 때 실행되는 시스템으로 바꾸는 단계이며, 일반적으로 이 전체 목록에서 가장 쉬운 단계이고, 다른 모든 것을 구축한 후에도 대부분의 사람들이 구현하는 데 신경 쓰지 않는 단계입니다.

15 단계: 루프를 신뢰하기 전에 스트레스 테스트를 하십시오

이 루프를 실제로 신뢰하기 전에, 네 가지 실패 모드에 대해 의도적으로 테스트하십시오.

작업의 진정으로 해결 불가능한 버전을 제공하고 관리자가 영원히 루핑하는 대신 실제로 중지하는지 확인하십시오. 완료할 수 있는 작업에 대해서만 테스트된 루프는 우아하게 실패하는 방법을 실제로 보여준 적이 없기 때문입니다.

심사관에게 미묘하게 잘못된 출력(읽기에는 좋지만 당신이 의도적으로 심은 특정 사실적 또는 논리적 오류가 포함된)을 제공하고, 그럴듯해 보이는 것을 통과시키는 대신 실제로 결함을 잡아내는지 확인하십시오.

빌더와 심사관이 동일한 기본 모델을 공유하는 경우, 심사관에게 해당 모델이 특징적으로 저지르는 실수를 제공하고 그것이 실수를 통과시키는지 확인하십시오. 심사관이 빌더의 맹점을 공유하면 6단계의 분리 목적이 무효화되기 때문입니다.

가장 비싼 모델 호출과 가장 긴 합리적인 출력을 사용하여 루프가 최대 수정 한도까지 실행될 때의 최악의 비용을 계산하고, 실제 청구서에 나타날 경우 당신을 놀라게 할 숫자인지 정직하게 결정하십시오.

무언가 중요한 일에 루프를 신뢰하기 전에 이 네 가지 테스트를 실행하면, 그렇지 않으면 클라이언트, 상사 또는 자신의 은행 명세서 앞에서 처음으로 나타날 대다수의 실패를 잡아낼 수 있습니다.

16 단계: 매번 동일한 모델이 아닌 올바른 모델로 작업을 라우팅하십시오

루프가 작동하면, 모든 부분을 가장 좋아하는 단일 모델에서 실행하는 습관을 물리치십시오. 빌더 역할은 일반적으로 가장 강력한 모델의 이점을 얻습니다. 실제 어려운 추론을 수행하고 약한 모델은 더 나쁜 첫 번째 초안을 생성하여 처음에 잘 생성하는 데 드는 비용보다 더 많은 수정 주기를 필요로 하기 때문입니다.

특정 서면 표준에 대해 확인하는 심사관 역할은 종종 더 작고 저렴하며 빠른 모델에서도 동등하게 안정적으로 수행됩니다. 창의적이어야 하는 것이 아니라 일관성만 요구되며, 매우 잘 지정된 체크리스트에 대해 확인하는 작은 모델은 종종 더 큰 모델과 비용 및 지연 시간의 일부만으로 일치하기 때문입니다.

이미 작성한 규칙을 기반으로 라우팅하는 관리자 역할은 거의 가장 비싼 모델이 전혀 필요하지 않습니다. 작업은 개방형 추론이 아닌 이미 지정한 로직을 실행하는 것이며, 빌더와 심사관의 성능에 관계없이 반복당 최소 한 번 실행되므로 호출당 비용이 원시 기능보다 더 중요합니다.

이 계층적 접근 방식(구축에는 비싼 모델, 일상적인 확인에는 저렴하고 일관된 모델, 라우팅에는 저렴한 모델)은 일반적으로 루프에서 실제 비용 절감이 발생하는 곳입니다. 대부분의 사람들은 비용 통제가 더 적은 루프나 더 적은 수정을 의미한다고 가정합니다. 그러나 실제로는 이미 구축한 루프 내에서 각 특정 역할의 실제 난이도에 모델 비용을 일치시키는 데서 비롯됩니다.

17 단계: 한 번에 다섯 개가 아닌 두 번째 루프로 확장하십시오

첫 번째 루프가 작동하면 유혹은 즉시 몇 개를 더 구축하여 아키텍처가 기술적으로 지원하기 때문에 다섯 가지 다른 작업을 병렬로 처리하는 것입니다. 편안하게 느껴지는 것보다 더 오래 저항하십시오. 하나의 루프가 출력을 더 이상 면밀히 확인하지 않을 만큼 안정적으로 실행되도록 하십시오. 즉, 실제 시간 동안 자체 수동 스팟 점검을 일관되게 통과한다는 의미입니다. (모든 사람이 주의 깊게 지켜본 단일 성공적인 데모 실행만이 아닙니다.) 그런 다음에만 두 번째 루프를 다른 작업(이상적으로는 첫 번째 작업과 완전히 다른 작업)에서 시작하여 기본 구조가 일반화되는지 테스트하고 같은 작업을 더 조정하는 것이 아닌지 확인하십시오.

18 단계: 실행 중인 모든 루프에 대한 공유 보기를 스스로에게 제공하십시오

둘 이상의 루프가 실행되면, 모든 루프에 걸쳐 비용 및 중지 조건 트리거에 대한 공유 보기를 개별 루프가 아닌 전체적으로 추적하십시오. 작업당 합리적인 예산이 있는 단일 루프는 자체적으로는 완전히 괜찮아 보입니다. 각각 개별적으로 예산 내에 있는 10개의 루프는 여전히 놀라운 총계로 합산될 수 있으며, 각 개별 루프의 추적이 개별적으로는 괜찮아 보였기 때문에 총계 청구서가 도착할 때까지 아무도 알아차리지 못합니다.

성공적인 완료뿐만 아니라 특히 모든 중지 조건 트리거를 기록하십시오. 다른 루프는 거의 하지 않는 동안 루프가 지속적으로 수정 상한에 도달하는 것은 심사관의 기준이 잘못 조정되었거나(통과하기에는 너무 엄격함) 완전히 잘못된 실제 사실을 확인하고 있음을 알려줍니다. 기본 작업이 단순히 어렵다는 것이 아닙니다. 성공만 추적하고 모든 에스컬레이션을 해당 특정 루프 설계에 대한 데이터 포인트가 아닌 고립되고 주목할 만한 이벤트로 취급하면 그 패턴은 보이지 않습니다.

19 단계: 작성한 프롬프트 수로 자신을 측정하지 마십시오

전환이 실제로 일어났다는 가장 분명한 신호는 당신이 일상적으로 주의를 기울이는 것이 바뀌는 것입니다. 프롬프터는 얼마나 많은 좋은 프롬프트를 작성했는지 추적합니다. 시스템 설계자는 얼마나 많은 루프가 실행 중인지, 각각이 얼마나 신뢰할 수 있는지, 그리고 더 이상 감독이 필요하지 않은 시스템에 의해 얼마나 많은 자신의 시간이 반환되었는지 추적합니다. 여전히 입력한 프롬프트 수로 자신의 생산성을 측정하고 있다면, 기술적으로 얼마나 많은 루프를 구축했는지에 관계없이 1단계의 정신적 전환이 아직 완전히 자리 잡지 않은 것입니다.

20 단계: 다른 사람에게 5가지 동작을 가르치십시오

마지막 단계는 더 이상 자신의 시스템에 관한 것이 아닙니다. 전문 용어를 사용하지 않고 다른 사람에게 설명함으로써 전환을 실제로 내면화했는지 확인하는 것입니다. 발견, 핸드오프, 검증, 지속성, 스케줄링. 이 5가지 동작과 위의 단계만 사용하여 다른 사람이 자신의 첫 번째 루프를 구축하도록 안내할 수 있다면, 이 로드맵이 설명하는 실제 전환을 이룬 것입니다. 더 이상 루프 안에서 다음 지침을 입력하는 사람이 아닙니다. 루프를 설계하고, 밖에 서서 실행되는 것을 지켜보는 사람입니다.

이 로드맵의 단계를 건너뛰는 것은 큰 소리로 실패하지 않고 조용히 실패하며, 훨씬 나중에야 나타나는 방식으로 실패하므로 경고와 함께 마무리할 가치가 있습니다.

검증 부채는 6단계와 7단계를 건너뛰고 실제 심사관이나 실제 사실이 없는 루프를 구축할 때 누적됩니다. 출력이 괜찮아 보이기 때문에 루프가 작동하는 것처럼 보이다가, 누군가 알아차리기 전에 수십 번의 실행에 걸쳐 실수가 조용히 증폭됩니다.

이해 부패는 20단계를 건너뛰고, 한 번 구축했지만 고장났을 때 더 이상 설명하거나 디버깅할 수 없는 루프를 실행할 때 발생합니다. 각 부분이 왜 존재하는지 내면화할 필요가 없었기 때문입니다.

인지 항복은 1단계가 실제로 정착되지 않을 때 발생합니다. 검증 시스템이 이미 스스로를 입증한 후에도 오랜 습관으로 모든 출력을 수동으로 다시 확인하여 시스템을 구축하는 전체 목적을 무효화합니다.

토큰 폭발은 10단계를 건너뛰고 실제 중지 조건 없이 루프를 실행하여 청구서가 도착했을 때만 실제 비용을 발견할 때 발생합니다.

이러한 모든 비용은 피할 수 있으며, 각각은 동일한 규율로 피할 수 있습니다. 단계를 순서대로 구축하십시오. 화려해 보이지 않는 단계를 건너뛰지 마십시오. 지루한 단계(완료 정의, 중지 조건, 실제 사실)가 실제로 작업을 수행하는 단계입니다. 흥미로워 보이는 부분(영리한 프롬프트, 정교한 아키텍처 다이어그램)은 구축한 시스템이 언제 옳은지, 언제 틀렸는지, 그리고 언제 중지해야 하는지를 실제로 아는지 여부보다 훨씬 덜 중요합니다.

그것이 프롬프터와 시스템 설계자의 전체적인 차이입니다. 뛰어난 지능이 아닙니다. 구축하기에는 지루하고 건너뛰기 쉬운 부분에 대한 규율입니다.

<a href="https://x.com/@cyrilXBT">@cyrilXBT</a> 를 팔로우하여 이 로드맵의 모든 단계 뒤에 있는 정확한 루프 템플릿과 빌더-심사관-관리자 설정을 확인하십시오.

루프 엔지니어링: 프롬프터에서 시스템 설계자로 나아가는 20단계 경로

Turn one viral article into a full content workflow

최근 바이럴 아티클

에이전트 마켓플레이스는 해결되었지만, 트레이딩 에이전트를 위한 시장은 아직 없습니다.

평가 엔지니어링 자동화를 향하여

우리가 Buzz에 열광하는 이유

커뮤니티 맥싱 (Communitymaxxing)

Kimi K3 Swarm Max: 단일 프롬프트로 300개의 리서치 에이전트를 실행하는 방법

AI는 왜 실업률을 높이지 않았을까?