Kalibr: 에이전트를 수동으로 디버깅하고 있다면, 당신은 뒤처지고 있다

Source: Dev.to

프로덕션에서 AI 에이전트를 죽이고 있는 병목 현상이 있습니다.
문제는 모델 품질, 프롬프트, 혹은 툴링이 아닙니다.
병목 현상은 바로 여러분—좀 더 정확히 말하면, 인간이 항상 존재해 시스템을 유지할 것이라고 가정하는 아키텍처입니다.

무언가가 악화됩니다. 인간이 이를 감지하고, 진단하고, 무엇을 바꿀지 결정한 뒤, 수정 사항을 배포해야 합니다.
그 루프가 제약 조건입니다. 느리고, 간헐적이며, 야간에는 작동하지 않고, 시간당 수천 건의 결정을 내리는 시스템에 확장되지 않습니다.

에이전트 신뢰성 실제 모습

이것이 오늘날 기본 설정입니다.

에이전트가 성공률이 약간씩 감소하기 시작합니다. 오류는 없고, JSON은 여전히 유효합니다. 로그도 정상으로 보입니다. 하지만 시간이 지나면서 지연 시간이 늘어나고, 성공률이 감소하며, 비용이 증가하고, 엣지 케이스가 쌓입니다.

결국 누군가가 이를 눈치채거나, 알림이 울리거나, 고객이 불만을 제기합니다. 그러면 절차가 시작됩니다: 대시보드를 확인하고, 트레이스를 파고들며, 모델인지, 프롬프트인지, 도구인지에 대해 논쟁하고, 변경 사항을 배포하고, 잘 작동했기를 바랍니다.

• 최선의 경우: 복구에 몇 시간이 걸립니다.
• 보통의 경우: 며칠이 걸립니다.
• 최악의 경우: 아무도 눈치채지 못해 절대 일어나지 않습니다.

이것이 2026년 프로덕션 환경에서 “자율 에이전트”가 보이는 모습입니다.

왜 이것은 설계상의 실패인가

다른 모든 성숙한 시스템에서는 인간이 실시간 라우팅 결정을 담당하지 않는다.

• 인간은 패킷을 라우팅하지 않는다.
• 인간은 데이터베이스를 재조정하지 않는다.
• 인간은 컨테이너가 어디서 실행될지 결정하지 않는다.

백엔드가 “우리는 엔지니어가 대시보드를 보면서 문제가 발생했을 때 스위치를 전환한다”라고 설명된다면, 농담처럼 들리거나 2008년 스타트업처럼 들릴 것이다. 이러한 결정들은 인간이 빠르고 반복적인 다수의 결정을 신뢰성 있게 내리는 데 서투르기 때문에 시스템으로 옮겨졌다. 에이전트도 마찬가지이며, 아직 그 추상화를 구축하지 않았을 뿐이다. 대시보드를 보고 설정을 조정하는 것이 허용된다고 가장하는 것은 임시방편일 뿐, 해결책이 아니다.

인간 루프를 제거하면 무엇이 바뀔까

각 모델‑툴 조합을 하나의 경로로 취급하는 시스템을 상상해 보세요. 실행이 끝날 때마다 결과가 보고되고, 확률은 실시간으로 업데이트되며, 성능이 변하면 트래픽이 자동으로 전환됩니다. 무언가가 악화되면 시스템이 그 경로를 우회하도록 라우팅합니다—알림도, 대시보드도, 사고도 없습니다. 사용자 입장에서는 아무 일도 일어나지 않은 것처럼 보입니다.

이것은 최적화가 아니라 전혀 다른 신뢰성 모델입니다. 바로 Kalibr 이 하는 일입니다: 목표에 가장 적합한 실행 경로를 학습하고, 복구 루프에 인간이 개입하지 않은 상태에서 그에 맞게 라우팅합니다. 신뢰성은 언제나 최우선 목표이며, 성공이 보장된 뒤에야 다른 고려사항이 의미를 갖게 됩니다.

왜 시간이 지남에 따라 복합적으로 작용하는가

• 계속 실행되는 시스템은 깨끗한 결과 데이터를 수집하고, 더 빠르게 학습하며, 지속적으로 개선됩니다.
• 중단되는 시스템은 잡음이 섞인 데이터를 생성하고, 정상 작동을 위해 사후 분석이 필요하며, 고장될 때마다 학습 속도가 느려집니다.

시간이 지남에 따라, 한 시스템은 지능을 누적하고 다른 시스템은 운영 부채를 누적하여 격차가 확대됩니다.

인간이 아직도 하는 일

이는 “인간을 대체한다”는 이야기가 아닙니다. 인간은 여전히:

• 목표를 정의합니다.
• 실행 경로를 설계합니다.
• 성공이 무엇인지 결정합니다.
• 전략을 개선합니다.

인간은 확률적 시스템에 대한 사고 대응을 중단하고, 실제로 영향력이 존재하는 상류 단계로 이동합니다. 일상적으로 인간이 시스템을 유지해야 하는 에이전트 시스템은, 인간이 단지 개선만 하면 되는 시스템에 비해 열세에 놓입니다.

결과

• 가시성은 필요하지만 충분하지 않습니다.
• 오프라인 평가가 유용하지만 완전하지 않습니다.
• 인간이 개입하는 디버깅은 규모를 확장할 수 없습니다.

이 원칙을 내면화한 팀은 실제로 작동하는 에이전트를 출시할 것이며, 나머지는 같은 화재와 계속 싸우게 될 것입니다.

이것은 결정 경계 이동이다

• 관측 도구: 데이터를 인간에게 전달하고, 인간이 결정한다.
• 라우팅 시스템: 결정을 시스템으로 옮기고, 인간은 감독한다.

그 구분은 중요합니다. 인프라는 결정 경계가 이동할 때 발전한다: TCP는 패킷 라우팅을 네트워크로 옮겼고, 컴파일러는 하드웨어 번역을 소프트웨어로 옮겼으며, Kubernetes는 스케줄링을 제어 평면으로 옮겼다. 현재 에이전트가 어떤 모델을 사용해야 할지를 결정하는 것도 같은 범주에 속한다.

여기서 실패하는 이유

• Cold start는 여전히 판단이 필요합니다; 라우팅이 확신을 갖게 되기 위해서는 경로당 대략 20–50개의 결과가 필요합니다.
• Bad success metrics는 나쁜 최적화를 초래합니다.
• 일부 작업은 본질적으로 모호합니다.

내가 하는 내기

Agents는 이미 인간이 합리적으로 감독할 수 있는 것보다 더 많은 결정을 내리고 있습니다. 인간을 신뢰성 루프에서 제거하는 추상화가 승리할 것이며, 이는 주의력이 확장되지 않기 때문입니다. 그 추상화는 존재할 것입니다.

This is the company I’ve built: Kalibr.
만약 당신의 agents가 하루에 수백 번 혹은 수천 번 같은 결정을 내린다면, 이 문제는 이미 비용을 초래하고 있습니다. 아직도 하나의 agent를 손수 연결하고 있다면, 지금은 이를 무시할 수 있지만—오래는 못 갈 것입니다.