루프 엔지니어링의 심장은 '검증'이다 — 그리고 검증자는 '다른' 모델이어야 한다

2026-06-22 · Ascendy Engineering

TL;DR

AI 에이전트를 다루는 기술은 프롬프트 → 컨텍스트 → 하네스 → 루프 엔지니어링으로 진화했다 — 적어도 아래 인용한 글들이 정리하는 계보가 그렇다. 2026년 6월 들어 빠르게 퍼진 루프 엔지니어링은 턴마다 직접 프롬프트하는 대신, 에이전트가 스스로 돌아가는 루프를 설계하는 것이다.
자율 루프의 구성요소는 트리거·목표·액션·검증·메모리지만, 자리를 비우고 맡길 수 있게 해주는 핵심은 검증 게이트다. 한 글(Cobus Greyling)이 짚듯 — “무인 루프에선 verifier가 있어야 어느 정도 안심하고 자리를 비울 수 있다.”
그런데 검증의 핵심 원칙이 “코드를 쓴 에이전트는 자기 일의 나쁜 심판이다”(maker/checker). 자기가 쓴 걸 자기가 검증하면 통과시킨다. 그래서 검증은 다른 지시·종종 다른 모델로 한다(캐논). → 그리고 이 글의 주장은, 거기서 한 걸음 더 가 검증자가 다른 프로바이더여야 한다는 것이다.
우리가 만든 적대적 에이전트-페어 하네스 redteam(Apache-2.0)이 정확히 그 지점을 끝까지 민 사례다 — 검증 게이트를 cross-provider 적대 + fail-closed로 박았다. (redteam이 최고의 루프라는 게 아니라, 루프의 심장을 가장 진지하게 만든 한 사례라는 얘기다.)

소스 노트. 루프 엔지니어링의 계보·정의는 공개 자료로 확인했다(Cobus Greyling, explainx). redteam의 동작은 public OSS(AscendyProject/redteam)라 README·CHANGELOG에서 직접 확인했다. 같은 적대적 검증 결의 두 번째 AI를 어떻게 부르고 언제 멈추나, 기능을 거부하는 법과 이어진다.

프롬프트에서 루프까지

AI를 부리는 기술의 계보를, 루프 엔지니어링 글들은 4단계로 정리한다.

프롬프트 엔지니어링 — 무슨 말을 입력하나. 한 줄의 지시를 잘 쓰는 기술.
컨텍스트 엔지니어링(2025) — 모델이 무엇을 보나. 과제를 풀 수 있을 만큼의 맥락을 모델 앞에 깔아주는 일.
하네스 엔지니어링(2026 초) — 모델이 어디서 도나. 모델 바깥의 환경 — 쓸 수 있는 툴, 걸린 제약, 피드백, 검증 게이트.
루프 엔지니어링(2026.6) — 무엇이 모델을 돌리나. 이제 내가 턴마다 프롬프트하지 않는다. 에이전트가 스스로 작업을 발견하고, 위임하고, 검증하고, 상태를 남기고, 다음 행동을 정하는 — 그 루프를 설계한다.

질문 자체가 “뭐라고 말하지?”에서 “어떤 시스템을 만들면 에이전트가 알아서 일하지?”로 옮겨갔다. 모델이 이미 몇 시간씩 자율로 도는 시대가 되자, 병목이 모델 능력에서 오케스트레이션 설계로 넘어온 것이다.

자율 루프의 전부는 ‘검증’이다

루프의 구성요소는 보통 이렇게 꼽힌다 — 트리거(스케줄/이벤트), 검증 가능한 목표, 액션(툴), 검증, 메모리(상태 보존). 그런데 이 중 진짜 어려운 하나가 있다.

검증 게이트. 루프 엔지니어링을 정리한 한 글(Cobus Greyling)이 짚는 한 줄이 이거다:

“무인 루프에서, verifier가 있어야 어느 정도 안심하고 자리를 비우고 맡길 수 있다.”

당연하다. 에이전트가 나 없이 몇 시간을 도는 루프라면, 그 결과를 믿을 수 있게 해주는 건 검증뿐이다. 검증이 약하면 — “검증이 없으면 루프는 영원히 돌거나 너무 일찍 멈춘다.” 자율성의 가치 전체가 verifier 하나에 달려 있다.

그런데 검증자가 자기 자신이면 무너진다

검증의 핵심 원칙은 더 날카롭다. 루프 엔지니어링 캐논이 그대로 적는다:

“코드를 쓴 에이전트는 자기 일의 나쁜 심판이다.” (maker/checker 분리)

자기가 쓴 코드를 자기가 검증하면, 자기 추론의 빈틈은 두 번째로 봐도 똑같이 안 보인다. 통과시킨다. 그래서 좋은 루프는 만드는 에이전트(maker)와 검증하는 에이전트(checker)를 분리하고, 다른 지시(때로 다른 모델)로 검증한다 — 여기까진 캐논이다.

여기서부터는 이 글의 주장이다. 검증자가 같은 프로바이더의 서브에이전트면, 그건 자기-리뷰의 한 변종에 가깝다고 본다 — 같은 계열은 같은 맹점을 공유할 위험이 크기 때문이다. 그래서 독립성을 프로바이더 경계까지 밀어야 한다는 게 redteam의 설계 선택이다(캐논이 요구하는 건 아니다).

redteam — 검증 게이트를 cross-provider 적대로 박는다

redteam(우리가 만든 적대적 에이전트-페어 하네스, Apache-2.0)은 정확히 그 검증 게이트를 끝까지 민 루프다. 핵심은 세 가지다.

검증자가 다른 프로바이더다. 한 모델이 pipeline(plan → implement → review)으로 코드를 쓰고, 다른 벤더의 모델이 그 diff를 적대적으로 리뷰한다. 기본 설정은 Claude가 쓰고 Codex가 리뷰한다(설정으로 반대도 가능). maker/checker를 cross-provider로 끌어올린 것이다.
자기-리뷰를 fail-closed로 거부한다. 같은 프로바이더의 모델이 자기 코드를 리뷰하려 하면, 하네스가 fail-closed로 막는다. “다른 서브에이전트인 척”으로 통과하는 길을 구조로 닫았다.
findings는 pass/fail이 아니라 tiered. 리뷰어가 심각도를 매긴 findings를 내고, common path는 사람 게이트 없이 draft PR 생성까지 자동으로 진행한다 — 적대적 페어 + 검증 자체가 신뢰이기 때문이다. (그 draft PR이 머지 전 사람 체크포인트이고, 하네스는 절대 자율 머지하지 않는다.)

그리고 이게 말이 아니라 기록으로 받쳐진다. redteam의 CHANGELOG는 한 줄로 적는다 — “cross-provider adversarial review가 머지 전 real HIGH 결함 4개를 잡았다.” CHANGELOG가 확증하는 건 다른 모델이 그 4개를 잡았다는 사실까지다 — 자기-리뷰라면 그냥 통과시켰을 법한 종류라는 건 이 글의 해석이다.

나머지 루프 구성요소도 다 있다

검증만 강한 게 아니라, 루프 엔지니어링이 꼽는 구성요소가 전부 들어 있다.

메모리/상태 보존 — 각 phase 후 state.json을 영속해서, 끊겨도 spin하지 않고 이어서 돈다. (“메모리가, 배우는 루프와 헛도는 루프를 가른다.”)
검증 가능한 목표 — TDD 모드는 write_test → verify_test를 앞에 깔아, 목표를 체크 가능하게 만든다.
fail-safe / 정지조건 — blocker가 리뷰 라운드를 넘겨 지속되면 human_gate_rescue로 사람에게 넘긴다. 1차 리뷰어가 인프라로 실패하면(CLI 없음·타임아웃) fallback ladder가 fail-closed로 degrade한다.
인지적 항복 방지 — 당신이 설정한 tier 프로파일이 어떤 변경(인증·저장·동시성·마이그레이션 등)을 production-critical로 분류하면, tier-aware routing이 그에 맞는 게이트(review/gates/models 토글)를 붙인다(기본 guarded 경로는 여전히 페어+검증, 사람 게이트 없음). production-critical엔 롤백 플랜을 요구하는 별도 운영 정책과 결합된다. 루프 캐논이 경계하는 ‘인지적 항복(cognitive surrender)‘을 구조로 막은 셈이다.

루프 설계엔 ‘안 만들기로’도 포함된다

흥미로운 디테일 하나. 루프 엔지니어링 글들은 “서브에이전트를 쓴다”고 말하는데, redteam은 한 사이클에서 세션 안에서 서브에이전트 리뷰어를 띄우는 어댑터를 거부했다. 이유는 한계 효용은 작은데(headless 리뷰어가 이미 cross-provider를 커버) 새 실행 표면과 까다로운 보안 선결조건(같은 세션 서브에이전트가 키우는 자기-리뷰 우회 위험 등)을 떠안아야 했기 때문이다 — 비용 대비 이득이 안 맞았다. 그래서 headless cross-provider 쪽을 택하고, 그 거부를 결정문으로 남겼다. (기능을 거부하는 법) 루프 설계는 무엇을 넣느냐만이 아니라 무엇을 안 넣느냐이기도 하다.

가져갈 것

루프가 자율적일수록, verifier가 핵심이다. 자리를 비우고 어느 정도 안심하고 맡길 수 있게 해주는 핵심 조건이 검증이다.
그 verifier가 자기 출력을 검증하는 같은 에이전트면 self-review로 조용히 무너진다 — 그리고 같은 모델·같은 프로바이더까지 가면 맹점을 공유할 위험이 있다는 게 이 글의 주장이다. 캐논이 막는 건 자기-리뷰고, 같은 모델/프로바이더면 위험하다는 건 한 걸음 더 민 주장이다. 같은 계열은 같은 맹점을 공유할 수 있고, “합의처럼 느껴지지만” 검증은 비어 있다.
그래서 내가 보는 루프 엔지니어링의 다음 프론티어는 cross-provider 적대 검증이다. maker/checker를 다른 벤더로, refute하도록 시키면 self-review가 통과시킬 법한 결함이 잡힌다.
redteam은 그걸 엔진 레벨로 박은 한 사례다. 최고라는 주장이 아니라 — 루프의 심장을 가장 진지하게 만들면 이렇게 된다는, 검증 가능한 예시다.

저장소: github.com/AscendyProject/redteam (Apache-2.0).

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: loop-engineering, agents, adversarial-review, redteam, oss