"성능은 모델 곱하기 하네스다" — 에이전트 루프 설계를 둘러싼 오후의 격론

오후 2시 56분, 채팅방에 짧은 질문 하나가 올라왔다.

"다들 루프 하네스 어떻게 하는지 궁금하네"

루프(loop)는 AI 에이전트가 계획을 세우고 실행한 뒤 결과를 다시 점검하는 과정을 스스로 반복하는 방식을 말하고, 하네스(harness)는 그 반복이 엉뚱한 곳으로 새지 않도록 감싸주는 실행 틀을 가리킨다. 질문이 올라오자마자 한 참여자가 뼈아픈 경험을 털어놨다.

"루프 걸었다가 다른길로 우수수 간적이 많아서"

반복 작업을 자동으로 돌리려 했다가 에이전트가 애초 목적과 무관한 방향으로 흘러가버린 적이 많다는 고백이었다. 대화는 곧 구체적인 인프라 설계 이야기로 옮겨갔다. 한 참여자는 머릿속으로 구조를 짜보는 과정을 그대로 채팅에 옮겼다.

"서비스가 다 이걸 본다고? 그럼 이거 관리가 흩어져있네? 합쳐야지? → pgbouncer랑 API 서빙 VM으로 가볼까 아니아니 워커랑 합치자 그리고 엔진은 격리로 두고.."

pgbouncer는 여러 프로그램이 데이터베이스에 접속할 때 연결을 효율적으로 나눠주는 중계 도구다. 이 참여자는 여러 서비스가 같은 자원을 들여다보는 구조에서 관리가 흩어지는 문제를 지적하며, 연결을 관리하는 부분과 실제 작업을 처리하는 부분(워커), 그리고 모델이 돌아가는 엔진을 어떻게 나누고 합칠지 실시간으로 고민을 풀어놓은 셈이다.

이 논의는 결국 한 문장으로 압축됐다.

"퍼포먼스 = model 성능 x 하네스 구조"

아무리 좋은 모델을 쓰더라도 그것을 감싸는 실행 구조가 부실하면 실제 성능은 곱셈으로 깎여나간다는 주장이었다. 이 공식에 곧바로 반박에 가까운 요구가 따라붙었다.

"로컬모델로 입증하라고 해봅니다"

크고 비싼 모델이 아니라 자체적으로 돌리는 작은 모델(로컬모델)로도 같은 결과가 나오는지 직접 실증해보라는 냉정한 되물음이었다. 이날 대화는 결국 하네스 자체가 성능을 좌우하는 핵심 변수인지, 아니면 결국 모델 자체의 힘이 전부인지를 놓고 참여자들의 시각이 크게 엇갈렸다는 인상을 남겼다.

실무에서 루프를 직접 걸어본 실패 경험, 인프라를 실시간으로 재설계하는 사고 과정, 그리고 주장을 증명해보라는 요구까지 한 자리에서 오간 것은 에이전트 하네스 설계가 여전히 정답 없는 실험의 영역에 머물러 있음을 보여준다. 모델 성능이 곱하기 대상일 뿐이라는 공식에 다들 동의한 것도 아니었고, 그 곱셈을 어떻게 증명할 것인지에 대한 결론도 나지 않은 채 대화는 마무리됐다.