저는 정해진 일정에 따라 백그라운드 AI 에이전트(AI agents)를 실행합니다. 몇 달 동안 저는 이 설정에 대해 조용히 자부심을 느꼈지만, 실제 루프(loop)가 진정으로 요구하는 사항과 비교해 본 결과, 신뢰성을 만드는 단 한 부분을 건너뛰었다는 사실을 발견했습니다. 만약 당신이 관리 없이 실행되는 에이전트를 운영하고 있다면, 이것은 제가 스스로에게 던져야 했던 질문이며, 당신 또한 던져야 할 질문입니다.

계단, 빠르게 살펴보기

프롬프트 엔지니어링 (Prompt engineering)은 단어를 조정했습니다. 컨텍스트 엔지니어링 (Context engineering)은 적절한 정보들을 윈도우(window) 안에 넣었습니다. 하네스 엔지니어링 (Harness engineering)은 모델 주변의 비계(scaffolding) 역할을 합니다: 도구(tools), 규칙(rules), 샌드박스(sandboxes) 등이 그것입니다. 루프 엔지니어링 (Loop engineering)은 그 위의 층으로, 타이머에 따라 실행되며, 도우미를 생성하고, 스스로에게 데이터를 공급하는 하네스입니다. 각 계층은 이전 계층을 감싸고 있습니다. 아무도 대체되지 않았으며, 단지 기술의 경계가 한 층 더 올라갔을 뿐입니다.

루프는 네 가지 부분으로 구성됩니다

행동하기 전에 읽고 행동한 후에 쓰는 메모리 (Memory). 어길 수 없는 규칙 (Rules). 출력이 유효한지 확인하기 전에 검증하는 검증기 (Verifier). 사이클을 트리거하는 일정 (Schedule). 메모리, 규칙, 검증, 일정.

제가 스스로의 실수를 고백하는 지점

프로젝트당 세 개의 인덱싱 계층, 큐레이션된 메모리 뱅크 (memory bank), 무엇이 무엇을 임포트(import)하는지에 대한 구조적 인덱스, 시간적 회상 계층 (temporal recall layer). 그리고 그 위에 일정에 따른 백그라운드 에이전트.

이것을 네 가지 부분과 대조해 보십시오. 메모리, 예. 규칙, 예. 일정, 예. 그것은 세 가지입니다. 네 번째는 검증 (verify)인데, 저에게는 그것이 없었습니다.

저는 별도의 검증기 (checker)를 만든 적이 없습니다. 루프는 작업을 생성한 다음, 그 작업 자체를 신뢰했습니다. 출력을 읽고 참(true) 또는 거짓(false)을 반환하는 것만이 유일한 임무인 두 번째 모델도, 서브 에이전트 (sub-agent)도 없었습니다. 작업을 수행하는 에이전트가 그 작업이 괜찮다고 결정하기도 합니다. 어떤 인간의 프로세스에서도 당신은 그러한 이해 상충 (conflict of interest)을 즉시 지적할 것입니다. 자동화된 프로세스에서는 그것이 왠지 모르게 기본값처럼 되어 있습니다.

그것이 바로 핵심입니다. 메모리 (memory)에 규칙 (rules), 일정 (schedule)을 더하면 아주 많이 실행되는 에이전트를 얻게 됩니다. 하지만 그것이 당신이 방치해도 믿을 수 있는 에이전트를 제공하지는 않습니다. 검증 (verification)은 자기 수정 (self-correcting)과 자기 확인 (self-confirming) 사이의 차이입니다.

검증이 실제로 의미하는 것

에이전트가 자신의 출력을 다시 읽고 "괜찮아 보이네"라고 말하는 것이 아닙니다. 별도의 검증기, 즉 목표의 수락 기준 (acceptance criteria)을 부여받은 서브 에이전트 (sub-agent)나 두 번째 모델로서, 정의된 최종 상태 (end-state)에 대해 오직 참(true) 또는 거짓(false)만을 출력하는 것을 의미합니다. 그것은 작업을 만들어낸 추론 (reasoning) 과정을 보지 않고, 작업물과 명세 (spec)만을 봅니다. 그 독립성이 전체 가치입니다. 이번 주에 한 가지를 만든다면 이것을 만드십시오. 왜냐하면 이것이 나머지 작업들을 방치해도 안전하게 만들어주는 요소이기 때문입니다.

대부분의 사람들이 놓치는 거버넌스 (governance) 관점

루프는 당신이 그것을 무엇에 사용하고 있는지 알지 못합니다. 두 팀이 동일한 루프를 구축하고 정반대의 결과를 얻습니다. 한 팀은 자신이 깊이 이해하고 있는 작업을 더 빠르게 처리하기 위해 루프를 사용합니다. 다른 팀은 작업을 전혀 이해하지 않기 위해 루프를 사용합니다. 동일한 파일, 동일한 cron 라인, 동일한 검증기를 사용하지만 결과는 정반대입니다. 역량이 향상됨에 따라 책임 또한 한 단계 위로 이동했습니다.

따라서, 단 하나의 질문: 누가 출력을 검증하는가? 만약 대답이 "그것을 작성한 것과 동일한 에이전트"라면, 당신은 루프를 가진 것이 아닙니다. 당신은 단지 초반의 속도 (head start)를 얻었을 뿐입니다.

당신의 에이전트 설정에서는 검증을 어떻게 처리하고 계신가요? 저는 아직 제 시스템에 연결하는 중이며, 더 앞서 나가는 분들의 조언을 듣고 싶습니다.