루프는 하나의 결정을 블랙박스 안에 숨깁니다: 다음에 무엇이 실행될지.
에이전트 루프가 재시도, 에스컬레이션 또는 진행 여부를 결정할 때마다 그 결정은 모델 자체의 추론 내에서 이루어지며, 여러분에게는 보이지 않고, 사후 감사가 불가능하며, 모델의 원시 출력을 다시 읽고 정직하게 설명했기를 바라는 것 외에는 검사할 방법이 없습니다. 그래프는 동일한 결정을 명시적으로 만듭니다. 기록됩니다. 실행이 시작되기 전에도 검사할 수 있습니다.
이것은 사소한 차이가 아닙니다. 2026년 4월에 발표된 실제 arXiv 논문 뒤에 숨은 실제 논증이며, 에이전틱 시스템을 구축하는 방식을 재정의했습니다. 이 과정을 더 진행하기 전에 한 가지를 솔직하게 밝히는 것이 중요합니다. 해당 논문의 저자조차도 이는 구현되지 않은 설계이며, 약속된 이점을 실제로 제공하는지 여부는 여전히 열린 실증적 질문이라고 명시하는 공정성 고지 사항을 포함하고 있습니다. 이 과정은 그 프레임워크를 솔직하게 가르치며, 그 주의사항도 포함합니다. 아직 대규모로 입증되지 않은, 실제로 엄격하게 논증된 제안을 이해하는 것이 그것을 확정된 사실인 척하는 것보다 더 유용하기 때문입니다.
이 과정을 마치면 여러분은 그래프 엔지니어링이 실제로 무엇인지, 왜 루프 위의 계층으로 존재하는지, 이 프레임워크의 모든 그래프가 기반하는 세 가지 약속, 그리고 첫 번째 그래프를 구축하는 방법을 이해하게 될 것입니다. 또한 현재 증거가 어디에 있고 어디에 없는지에 대한 솔직한 설명도 함께 제공됩니다.
루프가 한계를 가지는 이유
그래프가 왜 존재하는지 이해하려면 루프가 충분하지 않은 지점을 정확히 이해해야 합니다.
여기서 중요한 에이전틱 의미에서 루프는 에이전트가 작업을 시도하고, 결과를 관찰하고, 다음에 무엇을 할지 결정하는 주기이며, 어떤 조건이 충족될 때까지 반복됩니다. 이는 매우 다양한 작업에서 놀랍도록 잘 작동합니다. 그러나 구조적으로 가장 중요한 순간, 즉 다음에 무엇이 일어날지 결정하는 순간에 블랙박스가 됩니다.
루프의 에이전트가 실패한 단계를 재시도하기로 결정할 때, 그 결정은 모델이 자신의 컨텍스트를 추론하고 선택을 생성한 결과입니다. 결정이 발생하기 전에 검사할 수 없습니다. 결과를 관찰할 수만 있습니다. 에이전트가 동일한 실패 접근 방식을 다섯 번 연속으로 재시도하여 매번 비용을 소모한다면, 루프 구조는 이를 방지하지 않습니다. 재시도 결정이 전적으로 모델 자체의 판단 내에 존재했지, 외부의 확인 가능한 규칙에 있지 않았기 때문입니다.
이는 가끔 낭비되는 재시도가 별 의미가 없는 낮은 위험, 저렴한 작업에서는 괜찮습니다. 그러나 장기적이고 비용이 많이 들거나 위험도가 높은 작업에서는 실제 부담이 됩니다. 바로 에이전틱 시스템이 점점 더 신뢰받고 있는 작업 범주입니다. 논문의 핵심 주장은 에이전틱 시스템이 더 중요한 작업을 맡게 됨에 따라 "다음에 무엇이 실행될지"의 불투명성이 더 이상 수용 가능한 블랙박스가 아니라, 직접 엔지니어링해야 할 실제 실패 지점이 된다는 것입니다.
그래프가 실제로 무엇인가
이 프레임워크에서 그래프는 모델의 암시적 다음 단계 결정을 실행 시작 전에 정의된 명시적 구조로 대체합니다.
에이전트가 불투명한 컨텍스트 창 내에서 "재시도해야 한다" 또는 "에스컬레이션해야 한다"로 추론하는 대신, 그래프는 미리 정확히 어떤 상태가 존재하는지, 상태 간 어떤 전환이 유효한지, 각 전환을 트리거하는 특정 조건이 무엇인지 정의합니다. 에이전트는 여전히 각 상태 내에서 실제 작업을 수행합니다. 더 이상 전체 프로세스의 모양을 눈에 띄지 않게 결정하지 않습니다.
이와 같은 그래프를 통한 단일 회전을 설명하는 5가지 이동 구조는 다음과 같습니다: 계획, 실행, 복구, 에스컬레이션, 반복. 계획은 작업이 정의된 시퀀스로 분해되는 곳입니다. 실행은 에이전트가 현재 단계에 대한 실제 작업을 수행하는 곳입니다. 복구는 실행이 실패할 때 발생하며, 즉흥적인 재시도가 아닌 정의된 프로토콜을 따릅니다. 에스컬레이션은 그래프가 자동 복구를 계속 시도하는 대신 인간에게 제어권을 넘기는 명시적이고 정의된 지점입니다. 반복은 주기를 닫고 계획의 다음 단계로 이동합니다.
루프에서 무엇이 변경되었는지 주목하세요. 이 다섯 가지 이동 각각은 이제 그래프에서 명명되고 검사 가능한 상태가 되었으며, 정의된 전환을 갖추고 있습니다. 단일 모델 호출 내에서 조용히 발생하는 결정이 아닙니다.
세 가지 약속
이 프레임워크의 모든 그래프는 세 가지 특정 약속에 기반합니다. 이 세 가지를 깊이 이해하는 것이 실제 그래프 엔지니어링 학문의 핵심이며, 특정 구현 세부 사항보다 더 중요합니다.
약속 1: 불변 계획
실행 계획은 실행 중에 변경될 수 없습니다. 계획이 생성되고 잠기면 해당 실행 기간 동안 하나의 고정된 버전으로 존재합니다. 에이전트는 실행 중간에 발견한 내용을 기반으로 자신의 계획을 조용히 수정할 수 없습니다. 이는 루프 내 에이전트가 수정이 발생했다는 외부 기록 없이 자주 수행하는 작업입니다.
이는 제한적으로 들리며, 의도된 바입니다. 제한이 바로 핵심입니다. 실행 중간에 자유롭게 계획을 수정할 수 있는 에이전트는 사후 감사가 불가능한 행동을 보이는 에이전트입니다. 이후에 검토할 계획은 실제로 따랐던 계획이 아니라, 결국 계획이 표류한 최종 버전이기 때문입니다. 계획을 잠그면 실제 유연성과 실제 검사 가능성을 교환합니다. 이 트레이드오프는 무료가 아니며, 모든 경우에 엄격한 개선으로 취급하기보다는 솔직하게 직시할 가치가 있습니다. 원래 계획이 예상하지 못한 진정한 새로운 상황은 자유롭게 적응할 수 있는 루프보다 불변 계획으로 더 나쁘게 처리됩니다. 이 약속은 이 프레임워크가 대상으로 하는 작업 범주에서 예측 가능하고 감사 가능한 것이 최대 적응성보다 낫다는 의도적인 베팅입니다.
약속 2: 분리된 계층
계획, 실행 및 복구는 세 가지 독립적인 계층에 존재하며, 세 가지 모두가 동일한 연속 추론 프로세스 내에서 발생하는 하나의 얽힌 루프가 아닙니다.
계획 계층은 약속 1의 불변 계획을 생성하고 다른 작업은 수행하지 않습니다. 단계를 실행하지 않으며 실패를 처리하지 않습니다. 실행 계층은 정의된 단계를 실행하고 결과를 보고합니다. 실패 시 무엇을 할지 결정하지 않고, 무엇이 발생했는지만 보고합니다. 복구 계층은 실패 보고서를 수신하고 정의된 프로토콜을 적용합니다. 새로운 작업을 직접 실행하지 않고, 이미 발생한 일에 대응하는 방법만 결정합니다.
이 분리는 의도적으로 검증 루프에서 Builder와 Judge를 분리하는 것과 동일한 원칙을 반영합니다. 작업을 생성하는 역할은 해당 작업을 평가하거나 결정하는 역할과 동일해서는 안 됩니다. 둘을 합치면 검증을 의미 있게 만드는 독립성이 무너지기 때문입니다. 여기서는 분리가 두 배가 아닌 세 배이지만, 기본 추론은 동일합니다. 계획, 실행 및 복구를 모두 하나의 미분화된 프로세스 내에서 수행하는 시스템은 이러한 기능 중 어느 하나를 독립적으로 의미 있게 감사할 수 없습니다. 이후 검토할 추적에서 실제로 구별되지 않기 때문입니다.
약속 3: 엄격한 에스컬레이션
복구는 무기한 재시도하고 언젠가는 작동하기를 바라는 대신 고정된 프로토콜을 따릅니다.
이 약속은 실제 중지 조건이 없는 루프를 괴롭히는 토큰 폭발 실패 모드를 가장 직접적으로 해결합니다. 엄격한 에스컬레이션 프로토콜은 미리 정확히 허용되는 복구 시도 횟수, 복구 시도 성공 또는 실패로 간주되는 기준, 정의된 한도에 도달하는 순간 발생하는 작업(인간에게 제어권을 넘기고, 동일한 실패 접근 방식에 대한 창의적인 변형을 한 번 더 시도하지 않음)을 정의합니다.
이 논문의 70개 실제 시스템 분석에 따르면, 에이전트 루프 구현의 상당 부분이 복구 시도에 대한 공식적인 제한이 전혀 없었습니다. 즉, 문제가 발생했을 때의 실제 행동은 모델이 그 순간에 결정한 것에 의해 결정되었으며, 인간이 사전에 검토하고 승인한 규칙에 의한 것이 아닙니다. 엄격한 에스컬레이션은 이 특정 격차를 직접적으로 해소합니다.
첫 번째 그래프 구축하기
다음은 실제로 하나를 구축하는 실용적인 경로이며, 세 가지 약속을 개념적으로 이해하는 것뿐만 아니라 구현할 수 있는 것으로 변환합니다.
코드나 프롬프트를 작성하기 전에 종이에 상태를 명시적으로 정의하는 것으로 시작하세요. 일반적인 작업의 경우 최소한 다음과 같습니다: 계획 중, N단계 실행 중, 실패 복구 중, 에스컬레이션됨, 완료. 각 상태에 대해 시스템이 해당 상태에 있는 동안 정확히 무엇이 발생하는지, 그리고 어떤 조건이 상태 전환을 유발하는지 적어보세요.
계획 생성 단계를 작성하여 출력이 고정되고 버전이 지정된 아티팩트가 되도록 하세요. 나머지 시스템이 조용히 편집할 수 있는 살아있는 문서가 아닙니다. 간단하고 실용적인 버전은 계획을 명시적 성공 기준이 있는 개별 단계의 번호가 매겨진 목록으로 생성하고, 해당 목록을 실행의 나머지 기간 동안 읽기 전용으로 취급하는 것입니다. 이 계획에서 벗어나야 할 진정한 필요가 있는 경우, 조용한 내부 수정이 아닌 인간에 대한 명시적 에스컬레이션을 트리거해야 합니다.
실행 계층을 구축하여 결과만 보고하도록 하세요. 통과 또는 실패, 특정 세부 정보와 함께. 다음에 무엇을 할지 스스로 결정하지 않습니다. 이는 검증 루프의 Builder 역할을 정확히 반영하며, 작업을 생성하고 정직하게 보고하지만, 재시도 여부를 결정하는 역할은 아닙니다.
복구 계층을 명시적이고 번호가 매겨진 프로토콜로 구축하세요. 첫 번째 특정 대체 접근 방식을 시도합니다. 실패하면 두 번째, 다른 특정 접근 방식을 시도합니다. 실패하면 에스컬레이션합니다. 프로토콜은 사전에 읽는 인간이 각 단계에서 시스템이 정확히 무엇을 할지 예측할 수 있을 정도로 구체적이어야 합니다. "적절한 횟수로 고치려고 시도하세요"와 같은 모호한 지시가 아닙니다.
에스컬레이션 상태를 연결하여 도달하는 것이 실제로 보이는 이벤트가 되도록 하세요. 조용히 기록되고 잊혀지는 것이 아닙니다. 인간에게 시도된 전체 기록과 각 시도가 실패한 이유와 함께 알림이 전송되어야 합니다. 이는 일반적으로 검증 루프의 중지 조건에 권장되는 규율과 동일합니다.
이 프레임워크가 실제로 도움이 되는 경우와 그렇지 않은 경우
그래프 엔지니어링의 한계에 대해 솔직하게 설명하는 것이 모든 상황에서 루프에 대한 보편적인 업그레이드로 취급하는 것보다 더 유용하며, 논문 자체도 이 더 측정된 프레임을 지지합니다.
그래프는 잘못될 수 있는 것의 공간이 사전에 합리적으로 잘 이해된 작업, 감사 가능성이 최대 적응성보다 중요한 작업, 그리고 통제 불능의 무제한 재시도 주기의 비용(컴퓨팅 비용 또는 실제 사용자나 실제 시스템에 도달하는 나쁜 결과의 결과)이 실제로 비싼 작업에서 진정으로 도움이 됩니다.
그래프는 실패의 형태를 사전에 의미 있게 예측할 수 없고 시스템의 가치가 정확히 아무도 예상하지 못한 것에 대한 즉흥적인 대응 능력에서 비롯되는 진정으로 개방적이고 탐색적인 작업에는 덜 적합합니다. 새로운 정보가 등장함에 따라 적응형 재계획이 근본적으로 필요한 작업에 대해 계획을 불변으로 잠그는 것은 처음에 에이전트로 작업을 자동화할 가치가 있게 만든 정확한 능력을 포기하는 것입니다.
솔직하고 방어 가능한 입장은(논문 저자도 취하는 입장입니다) 이것이 모든 경우에 루프에 대한 엄격히 우월한 대체물이 아니라 깊이 이해할 가치가 있는 실제 트레이드오프라는 것입니다. 적응성이 감사 가능성보다 더 중요한 곳에서는 루프를 사용하세요. 그 반대라면 그래프를 사용하세요. 대부분의 실제 시스템은 두 패턴을 모두 사용할 수 있고 작업별로 의도적으로 선택할 수 있는 것이, 둘 중 하나를 영구 기본값으로 채택하는 것보다 이점이 있습니다.
실제 예: 그래프 구조화된 코드 마이그레이션
다섯 가지 이동 구조와 세 가지 약속을 구체적으로 만들기 위해, 여기서는 실제 공통 작업인 코드베이스 전반에 걸친 레거시 모듈의 새 프레임워크 버전 마이그레이션에 어떻게 적용되는지 설명합니다.
계획 상태는 시작 시 한 번 실행됩니다. 모듈을 분석하고, 변경해야 하는 모든 파일을 식별하고, 각각 명시적 성공 기준이 있는 고정된 번호가 매겨진 마이그레이션 단계 목록을 생성합니다. 예를 들어, 4단계는 업데이트된 파일이 컴파일되고 해당 파일의 기존 테스트 스위트가 수정 없이 통과할 때 성공합니다. 이 계획은 잠깁니다. 약속 1, 불변, 실제로 적용됩니다.
실행 상태는 계획의 단계를 순서대로 진행합니다. 각 단계에 대해 계획에 정의된 특정 변경을 적용하고 결과(통과 또는 실패)를 실제 컴파일러 출력 또는 테스트 결과를 증거로 첨부하여 보고합니다. 자체 평가된 "올바른 것 같음"이 아닙니다. 이는 약속 2의 실행 계층이며, 실패할 경우 어떻게 할지 결정하는 것과 엄격히 분리됩니다.
단계가 실패하면 그래프는 복구로 전환되며, 즉흥적인 재시도가 아닌 정의된 프로토콜을 따릅니다. 시도 1: 더 좁은 범위로 동일한 변경을 다시 적용하여 파일의 어느 부분이 컴파일 실패를 일으켰는지 정확히 격리합니다. 시도 2(첫 번째가 실패할 경우): 이 특정 종류의 실패에 대해 문서화된 대체 마이그레이션 패턴으로 대체합니다. 매번 새로 발명하는 대신 알려진 수정 사항의 작은 라이브러리에서 가져옵니다. 두 정의된 시도가 모두 실패하면 그래프는 에스컬레이션됨으로 전환됩니다. 이것이 약속 3, 엄격한 에스컬레이션이며, 세 번째 즉흥적인 시도가 아닙니다.
에스컬레이션됨 상태는 전체 기록(어느 단계가 실패했는지, 두 복구 시도가 무엇을 시도했는지, 각각의 특정 오류 출력)을 첨부하여 인간에게 직접 알립니다. 인간은 전체 컨텍스트를 가지고 이 특정 실패를 검토합니다. 며칠 후에 에이전트가 동일한 깨진 접근 방식을 루프에서 조용히 재시도하고 있었고, 왜 실패했는지에 대한 기록도 없이 비용을 소모하고 있었다는 것을 발견하는 것과는 다릅니다.
반복은 성공적인 단계에 대해 주기를 닫고, 그래프를 잠긴 계획의 다음 항목으로 이동시킵니다. 목록이 소진될 때까지, 그 시점에서 실행은 완료에 도달합니다.
이것이 구조화되지 않은 루프로 실행된 동등한 작업보다 제공하는 이점을 주목하세요. 모든 결정(재시도 여부, 방법, 포기 시점)은 실행이 시작되기 전에 그래프의 정의된 구조에서 볼 수 있습니다. 사후에 대본을 읽고 모델이 무엇을 생각하고 있었는지 추론해야만 발견할 수 있는 것이 아닙니다. 코드 리뷰어나 규정 준수 감사자는 그래프 정의만 보고도 시스템이 모든 실패 시나리오에서 정확히 무엇을 할 수 있는지 알 수 있으며, 실행을 본 적이 없어도 가능합니다.
그래프 엔지니어링 대 루프 엔지니어링: 언제 무엇을 사용할지
두 패턴 모두 실제로 문서화되어 있고 각각 진정한 강점이 있으므로, 특정 작업에 대해 둘 중 하나를 선택하기 위한 실용적인 결정 프레임워크를 제공합니다. 어느 하나를 영구 기본값으로 취급하지 마세요.
작업이 진정으로 탐색적일 때, 잘못될 수 있는 것의 형태를 사전에 예측할 수 없을 때, 그리고 예상치 못한 것에 대한 모델의 즉흥적 대응 능력이 정확히 당신이 의존하는 능력일 때 루프를 사용하세요. 연구 작업, 근본 원인이 시작 시 진정으로 알려지지 않은 개방형 디버깅, 그리고 엄격한 구조가 출력을 적극적으로 해칠 창의적인 작업은 모두 그래프의 감사 가능성보다 루프의 적응성을 선호합니다.
작업이 사전에 충분히 이해되어 있어서 가능한 실패 모드를 실제로 열거할 수 있을 때, 무제한이고 감사되지 않은 재시도 주기의 비용이 실제로 비쌀 때, 그리고 인간 검토자(규정 준수 팀, 보안 감사자, 또는 생산 사고를 디버깅하는 미래의 자신)가 전체 실행 대본을 다시 읽지 않고 시스템이 무엇을 할 수 있는지 정확히 검사해야 할 때 그래프를 사용하세요. 마이그레이션, 금융 거래, 규제 데이터와 관련된 모든 것, 그리고 조용한 실패가 아무도 알아차리기 전에 몇 시간 동안 축적될 수 있는 장기 실행 무인 에이전트 작업은 모두 루프의 유연성보다 그래프의 구조를 선호합니다.
두 패턴은 더 큰 시스템 내에서 상호 배타적이지 않습니다. 일반적인 실용적인 설계는 외부 수준에서 그래프를 사용하여 전체 작업 구조와 중지 조건을 처리하고, 단일 실행 상태 내에서 루프가 실행되도록 허용하여 하나의 특정 단계를 구현하는 방법을 알아내는 진정한 탐색적 하위 작업을 처리합니다. 이렇게 하면 그래프의 감사 가능성을 가장 중요한 수준(시스템이 할 수 있는 전체적인 모양)에서 얻을 수 있는 동시에, 루프의 적응성을 실제 즉흥성이 실제로 가치 있는 수준(하나의 제한된 작업의 세부 사항)에서 유지할 수 있습니다.
그래프를 신뢰하기 전에 테스트하기
그래프 구조화된 시스템을 실제로 사용하기 전에 세 가지 약속을 중심으로 특별히 설계된 스트레스 테스트를 실행하세요. 각 약속은 느슨하게 구현되면 조용히 실패하는 고유한 방식이 있기 때문입니다.
불변 계획 약속을 테스트하려면 실행 중간에 시스템이 자유롭게 추론한다면 잠긴 계획에서 벗어나는 "명백히 올바른" 다음 단계가 있는 시나리오를 의도적으로 구성하세요. 시스템이 계획을 조용히 적응시키는 대신 실제로 인간에게 에스컬레이션하는지 확인하세요. 조용히 적응한다면 코드가 어떻게 구조화되어 있든 계획은 실제로 불변한 적이 없습니다.
분리된 계층 약속을 테스트하려면 실행 계층의 실패 보고서에 다음에 무엇이 일어나야 하는지에 대한 결정의 흔적이 있는지 확인하세요. 중립적인 통과 또는 실패 보고서에 포함된 "이것은 아마 다른 접근 방식이 필요할 것 같다"와 같은 문구. 실행 계층이 이미 복구에 대한 의견을 형성하고 있다면 복구 계층과의 분리는 실제가 아니며, 단지 이름만 바꾼 것입니다.
엄격한 에스컬레이션을 테스트하려면 정의된 복구 시도 중 어느 것도 고칠 수 없는 실패를 시스템에 의도적으로 제공하고, 정의되지 않은 세 번째 접근 방식을 시도하는 대신 정의된 한도에서 깔끔하게 에스컬레이션하는지 확인하세요. 이는 진정으로 해결할 수 없는 작업에 대해 루프의 중지 조건을 테스트하는 것과 동등한 그래프 엔지니어링이며, 동일한 종류의 조용히 비용이 많이 드는 실패를 잡아냅니다.
이 세 가지 목표 테스트 외에도, 실제 사용에서 루프 기반 대안이 일반적으로 깔끔하게 제공할 수 없는 하나의 특정 지표를 추적하세요. 실행이 에스컬레이션됨 상태에 도달하는 비율을 각 복구 시도가 실패한 특정 지점별로 세분화합니다. 동일한 특정 복구 단계에서 지속적으로 에스컬레이션하는 그래프는 해당 단계의 정의된 프로토콜이 잘못 보정되었음을 알려줍니다. 기본 작업이 균일하게 어렵다는 것이 아닙니다. 이는 루프에 대해 중지 조건 트리거를 추적하는 것과 동일한 진단 가치를 제공하지만, 여기서는 실패 지점이 불투명한 대본 내의 추론된 순간이 아닌 명명되고 검사 가능한 상태이기 때문에 더 세분화되어 있습니다.
첫 번째 그래프를 구축할 때 흔히 하는 실수
첫 번째 그래프 구조화된 시스템을 구축하는 사람들에게 반복적으로 나타나는 몇 가지 특정 실수가 있으며, 이를 미리 알면 나중에 실제 디버깅 시간을 절약할 수 있습니다.
계획을 이름만 불변으로 취급하기. 종이에 계획을 잠그면서 실행 계층이 실제로 조용히 벗어나도록 허용하면 최악의 두 가지 상황을 모두 초래합니다. 실제 적응성도 없고 실제 감사 가능성도 없습니다. 추적이 더 이상 검토할 잠긴 계획과 일치하지 않기 때문입니다.
세 계층을 다시 하나로 합치기. 구축하는 것이 더 빠르게 느껴지기 때문입니다. 실행 계층이 복구도 결정하도록 허용하여 약속 2의 분리를 건너뛰는 것은 프레임워크의 실제 목적을 무효화합니다. 계획, 실행 및 복구가 진정으로 독립적이지 않다면, 그래프의 어휘를 입은 루프를 구축한 것이지 실제 그래프가 아닙니다.
복구 프로토콜을 실제 프로토콜이 아닐 정도로 모호하게 작성하기. "적절한 수의 대체 접근 방식을 시도하세요"는 엄격한 에스컬레이션 프로토콜이 아닙니다. 그래프 엔지니어링 언어로 설명된 무제한 루프와 동일한 실패 모드를 가진 부드러운 지시입니다. 실제 프로토콜은 특정 시도 횟수와 각각의 특정 조건을 명명합니다.
적합성에 대한 솔직한 평가 건너뛰기. 그래프 엔지니어링이 더 새롭고 더 엄격해 보이는 프레임워크이기 때문에 진정으로 개방적이고 탐색적인 작업을 위해 그래프를 구축하는 것은(작업이 실제로 트레이드오프의 이점을 얻기 때문이 아니라) 루프보다 구축하기 어렵고 실제 작업에서 루프보다 더 나쁜 시스템을 만듭니다.
증거의 솔직한 상태
이 과정이 시작될 때 언급한 주의사항으로 마무리합니다. 대부분의 기술 문서보다 여기서 더 중요하기 때문입니다. 위에서 설명한 세 가지 약속은 실제로 신중하게 논증된 제안이며, 70개의 실제 시스템을 분석하여 루프가 조용히 실패하는 지점을 정확히 식별합니다. 이는 저자의 명시적 진술에 따르면 아직 생산에서 대규모로 약속된 이점을 제공하는 것으로 검증되지 않았습니다.
이것이 프레임워크를 가치 없게 만들지는 않습니다. 이는 진정으로 유망한 설계이며, 의도적으로 이해하고 실험할 가치가 있으며, 이론적 논증이 자동적으로 실제로 전환된다고 가정하지 않고 자신의 결과를 솔직하게 추적합니다. 이 과정을 사용하여 그래프 구조화된 시스템을 구축한다면, 할 수 있는 가장 가치 있는 일은 그것이 목표로 하는 특정 실패 모드(무제한 재시도, 감지되지 않은 중간 실행 계획 표류, 감사되지 않은 복구 결정)를 실제 사용에서 실제로 줄이는지 측정하는 것입니다. 종이에 설득력 있는 논증이 있기 때문에 개선이 있다고 가정하지 마세요.
잘 추론된 프레임워크를 무비판적으로 채택할 확정된 사실이 아닌 테스트할 가설로 취급하는 그 규율 자체가 이 과정의 모든 것 아래에 있는 실제 메타 기술입니다. 그래프 엔지니어링, 루프 엔지니어링, 이 빠르게 변화하는 분야의 명명된 모든 관행은 이름과 논문이 있다는 이유만으로 채택하기보다는 제대로 배우고 자신의 결과에 대해 정직하게 테스트할 가치가 있습니다.
@cyrilXBT를 팔로우하여 이 프레임워크에 대한 실제 구현과 결과가 나타나기 시작할 때 업데이트를 받아보세요.
