“에이전트는 이제 코드를 잘 짠다.”

문제는 그 다음입니다. 코드가 나온 뒤 누가 검토하고, 어떤 기준으로 배포를 결정하고, 그 결과가 다시 에이전트에게 어떻게 돌아가느냐. 이 흐름을 설계하지 않은 채 에이전트를 빠르게만 돌리면, 속도가 오히려 통제 불능으로 바뀝니다.

지난 주 Andrew Ng이 이 문제에 이름을 붙였습니다. “Loop engineering.”

세 개의 루프

Ng의 프레임은 세 층으로 구성됩니다.

Agentic coding loop — 에이전트가 반복 실행·수정하는 내부 루프입니다. 스펙을 받아 코드를 생성하고, 테스트를 실행하고, 실패하면 수정합니다. 이 루프는 이미 에이전트가 사람보다 빠릅니다.

Developer feedback loop — 개발자가 에이전트 산출물을 검증하는 중간 루프입니다. 코드가 맞는지, 테스트가 충분한지, 유지보수 가능한지를 판단합니다. 단순히 “돌아가느냐”가 아니라 “이해할 수 있느냐”를 보는 게이트입니다.

External feedback loop — 실제 운영 환경이 에이전트에게 피드백을 돌려보내는 외부 루프입니다. 사용자 반응, 시스템 에러, 비즈니스 지표가 이 루프를 통해 다음 개선 사이클에 입력됩니다.

7월 5일 LangChain이 공식 블로그에 “The Art of Loop Engineering”을 올렸을 때, 이 담론은 커뮤니티 의견에서 벤더 공식 입장으로 격상됐습니다. “에이전트를 한 번 똑똑하게 만드는 것”이 아니라 “반복해서 좋아지게 설계하는 것”이 에이전트 운영의 핵심이라는 점에서, 프레임 자체가 바뀐 것입니다.

루프에는 소유자가 있다

7월 13일, addyo의 글 “Own the outer loop”가 GeekNews에 올라왔습니다. 핵심 주장은 단순합니다. 에이전트가 내부 루프를 맡아도, 외부 루프의 판단과 책임은 인간이 소유해야 한다.

그가 제시한 외부 루프의 운영 기준 세 가지:

  • Quality — 에이전트 산출물이 기준에 부합하는가
  • Verdict — 배포 여부를 누가, 어떤 근거로 결정하는가
  • Answerability — 결과에 대해 누가 설명 책임을 지는가

에이전트가 판단을 내릴 수 있어도, 그 판단에 설명 책임이 없으면 프로덕션에선 위험합니다. 외부 루프 설계는 거버넌스의 문제이지 기술의 문제가 아닙니다.

같은 날 LangChain의 hwchase17은 다른 각도에서 같은 지점에 도달했습니다. “최고의 에이전트는 작업에 맞춘 커스텀 하네스에서 나온다.” 범용 프레임워크보다 작업별 middleware와 평가 구조가 성패를 가른다는 것입니다.

가장 느린 루프가 전체를 결정한다

7월 14일, Geoffrey Litt이 한 문장을 올렸습니다. “Understanding is the new bottleneck.” 같은 날 Chester Roh의 팟캐스트 EP103도 같은 주제였습니다. 에이전트 생성 속도가 빨라질수록 인간의 이해 속도가 병목이 된다는 것입니다.

세 루프 중 가장 느린 루프는 언제나 외부 루프입니다. 그 이유가 여기에 있습니다. 내부 루프는 자동화됩니다. 중간 루프는 반자동화됩니다. 외부 루프는 인간의 이해 속도에 묶여 있습니다.

에이전트가 빨라지면 내부 루프 처리량이 늘고, 개발자 검토 부하가 증가하고, 외부 피드백 사이클이 길어집니다. 루프 설계 없이 에이전트를 빠르게만 돌리면, 전체 시스템은 오히려 느려집니다.

이것이 “루프 엔지니어링”이 효율이 아니라 설계 개념인 이유입니다.

PM이 설계해야 할 것

루프 엔지니어링 프레임을 실무에 적용하면 PM의 역할이 재정의됩니다.

기존: 어떤 에이전트를 언제 투입할 것인가

지금: 각 루프의 소유권과 속도를 어떻게 맞출 것인가

구체적으로는 이렇습니다.

내부 루프는 에이전트에게 위임하되, 격리된 샌드박스와 체크포인트 자동 저장이 필요합니다. 루프가 망가졌을 때 어디서 멈추고 어떻게 복구할지를 미리 설계해야 합니다.

중간 루프에서는 “언제 검토하느냐”가 핵심 설계 변수입니다. 에이전트 산출물 100%를 개발자가 보는 구조는 확장되지 않습니다. 자동 검증 통과 기준을 정하고, 기준 미달일 때만 개발자에게 올라오는 구조가 필요합니다.

외부 루프에서는 addyo의 세 기준(Quality · Verdict · Answerability)을 운영 정책으로 만들어야 합니다. 에이전트가 무엇을 했는지 추적 가능하고, 배포 결정에 근거가 있어야 합니다.

실제 사례를 보면 이 차이가 수치로 나타납니다. 오픈클로(100 Agents)는 월 20억 토큰, 100개 에이전트를 3명이 운영합니다. 이 구조가 가능한 이유는 모델 성능이 아니라 빌드-검증-피드백 루프가 자동으로 닫히는 하네스 설계입니다. 바이트댄스의 Senior SWE-Bench도 같은 방향입니다. 에이전트 평가 기준을 단일 프롬프트 성능이 아니라 “환경 피드백 루프의 품질”로 삼고 있습니다.

루프 엔지니어링은 새 기술이 아닙니다. 에이전트 시대의 PM이 설계해야 할 시스템 구조입니다. 내부 루프는 에이전트에게, 중간 루프는 반자동화에게, 외부 루프는 사람이 소유합니다. 그리고 가장 느린 루프가 전체 속도를 결정합니다.

지금 당신이 운영하는 에이전트 시스템에서, 외부 루프의 소유자는 누구입니까?