같은 주에 두 팀이 에이전트를 프로덕션에 올렸습니다.

빅밸류는 부동산 가격 산정 에이전트를 출시하면서 핵심 원칙 하나를 내세웠습니다. 근거 데이터가 충분하지 않으면 추정값을 내놓는 대신, 프로세스를 멈추고 사람에게 넘깁니다.

AWS 컨티뉴엄은 보안 취약점 탐지 → 검증 → 패치를 자동으로 도는 에이전트 파이프라인을 공개했습니다. 이 에이전트의 구조도 마찬가지입니다. 발견 단계와 패치 단계 사이에 검증 게이트가 있고, 에이전트는 그 게이트를 혼자 넘지 못합니다.

두 팀 모두 새로운 실행 능력을 내세운 게 아닙니다. 멈추는 조건을 설계한 겁니다.

왜 실행보다 멈춤이 먼저인가

에이전트를 처음 설계할 때 팀들이 가장 많은 에너지를 쏟는 곳은 ‘이 에이전트가 무엇을 할 수 있는가’입니다. 어떤 도구를 연결할지, 어떤 API를 붙일지, 어떤 데이터에 접근할지. 실행 능력을 극대화하는 방향입니다.

그런데 프로덕션에서 에이전트가 문제를 일으키는 방식은 대부분 그 반대입니다. 실행 능력이 부족해서가 아니라, 멈춰야 하는 순간에도 계속 진행하기 때문입니다.

CIS 2026 컨퍼런스에서 600명의 기업·학계 관계자가 같은 진단을 내렸습니다. AI에 큰 비용을 투입하고도 체감 변화가 작은 가장 큰 이유가 ‘시스템과 에이전트 간 연결 부족’이라는 겁니다. 여기서 연결 부족은 기술 스택의 문제가 아닙니다. 에이전트가 어떤 맥락에서 자율적으로 움직이고, 어떤 맥락에서 사람에게 승인을 구해야 하는지 — 이 경계가 설계되지 않았다는 뜻입니다.

에이전트의 실행 능력은 이미 상당 부분 범용화됐습니다. 멀티스텝 추론, 도구 호출, 병렬 처리는 대부분의 프레임워크에서 기본값입니다. 2026년 지금 남은 차별화 축은 멈춤 설계입니다.

멈춤 설계의 세 가지 원칙

1. 근거 없으면 추정하지 않는다

빅밸류 사례가 보여주는 핵심입니다. 에이전트가 충분한 데이터 없이 그럴듯한 답을 만들어내는 것, 이른바 ‘합리적 추정’은 사람이 검토하기 가장 어려운 오류 유형입니다. 결과만 보면 틀렸다는 걸 알기 어렵기 때문입니다.

실무에서 이를 구현하는 방식은 단순합니다. 에이전트의 응답 전에 근거 신뢰도 점수를 함께 산출하게 하고, 임계값 이하이면 결론을 내지 않고 에스컬레이션합니다.

# 판단 게이트 예시
if confidence_score < CONFIDENCE_THRESHOLD:
    return escalate_to_human(
        context=context,
        reason="근거 데이터 불충분",
        confidence=confidence_score
    )
return agent_decision(context)

이 게이트가 없으면 에이전트는 항상 무언가를 출력합니다. 그 출력이 맞는지 틀린지를 판단하는 부담이 사람에게 전가됩니다.

2. 발견과 실행 사이에 검증 게이트를 넣는다

AWS 컨티뉴엄의 구조입니다. 탐지(발견) → 위험도 평가(검증, 사람 확인) → 패치(실행)의 3단계에서, 중간 검증은 에이전트가 자율적으로 건너뛸 수 없습니다.

이 패턴은 보안 도메인에 국한되지 않습니다. 고객 데이터에 쓰기 작업을 하거나, 금전 거래를 발생시키거나, 외부 시스템에 영향을 미치는 모든 에이전트에 동일하게 적용됩니다. 읽기와 쓰기 사이의 인간 검토 게이트입니다.

많은 팀이 이 게이트를 처음에는 ‘나중에 자동화할 임시 조치’로 설계합니다. 실제로 자동화하면 사고가 납니다. 게이트는 에이전트의 책임 범위를 정의하는 구조이지, 자동화가 부족해서 남겨둔 공백이 아닙니다.

3. 멈춤 이유를 트레이스에 남긴다

에이전트가 멈추는 것만으로는 충분하지 않습니다. 왜 멈췄는지를 추적 가능한 형태로 기록해야 합니다. 이것이 다음 이터레이션에서 임계값을 조정하거나 에이전트 설계를 개선하는 데이터가 됩니다.

이 트레이스가 없으면 두 가지 문제가 생깁니다. 에이전트가 너무 자주 멈추는지(과도한 보수성), 아니면 너무 가끔 멈추는지(과도한 자율성)를 판단할 근거가 없습니다. 멈춤의 패턴이 쌓여야 게이트를 튜닝할 수 있습니다.

실제 운영에서 이 트레이스는 단순한 로그가 아닙니다. 에이전트가 어떤 종류의 판단을 사람에게 넘기고 있는지를 보여주는 신호입니다. 그 신호를 읽는 사람이 PM입니다.

PM이 먼저 정해야 하는 질문

에이전트 설계를 시작할 때 엔지니어링 팀은 대부분 기능 목록부터 만듭니다. PM이 먼저 정해야 하는 것은 기능이 아닙니다.

“이 에이전트는 어떤 상황에서 사람을 부르는가?”

이 질문에 답하기 전에 기능 목록을 만들면, 나중에 이 질문에 답하기 위해 아키텍처를 뒤집어야 합니다.

멈춤 조건은 완성된 에이전트에 나중에 붙이는 안전장치가 아닙니다. 에이전트의 역할 경계를 정의하는 첫 번째 설계 결정입니다. 빅밸류가 ‘근거 없으면 멈춤’을, AWS 컨티뉴엄이 ‘발견과 패치 사이의 검증 게이트’를 핵심으로 내세운 이유가 여기에 있습니다.

실행을 얼마나 잘 하는가는 모델과 도구가 결정합니다. 언제 멈추는가는 PM이 설계합니다.

당신의 에이전트는 지금 어떤 조건에서 멈추도록 되어 있습니까?