AI 업계는 모든 것을 “에이전트 (Agent)”라고 부르는 것을 좋아합니다.

언어 모델 (Language Model)에 몇 가지 도구에 대한 접근 권한을 주고, 데이터베이스에 연결하고, 루프 (Loop)를 추가하면, 갑자기 그 시스템은 자율적이라고 마케팅됩니다. 웹을 탐색하고, 이메일을 보내고, 코드를 작성하고, API를 호출하며, 결정을 내릴 수 있습니다.

하지만 이러한 시스템 대부분은 진정으로 자율적이지 않습니다.

그것들은 LLM이 중간에 배치된 취약한 워크플로우 (Workflow)입니다.

그 차이는 중요합니다. 워크플로우는 미리 정의된 단계를 따릅니다. 에이전트는 불확실한 환경에서 작동하며 다음에 무엇을 할지 결정해야 합니다. 문제는 소위 에이전트라고 불리는 많은 것들이 여전히 경직된 가정, 신뢰할 수 없는 도구 호출 (Tool calls), 불완전한 상태 관리 (State management), 그리고 취약한 복구 메커니즘 (Recovery mechanisms)에 의존하고 있다는 점입니다.

데모 중에는 지능적으로 보입니다. 하지만 프로덕션 (Production) 환경에서는 종종 비용이 많이 들고, 예측 불가능하며, 디버깅하기 어려워집니다.

LLM이 다음 단계를 선택하는 것은 자율성이 아닙니다

단순히 LLM이 다음에 무엇을 할지 결정한다고 해서 시스템이 자율적인 것은 아닙니다.

진정한 자율성에는 신뢰할 수 있는 실행, 명확한 경계, 관찰 가능성 (Observability), 그리고 상황이 잘못되었을 때의 복구 능력이 필요합니다.

전형적인 고객 지원 에이전트를 생각해 봅시다:

1. 사용자의 요청을 읽습니다.
2. 지식 베이스 (Knowledge base)를 검색합니다.
3. 고객 계정을 확인합니다.
4. 환불이 허용되는지 결정합니다.
5. 환불 요청을 제출합니다.
6. 확인 메시지를 보냅니다.

서류상으로는 이것이 자율적인 시스템처럼 보입니다. 하지만 현실에서는 여러 곳에서 실패할 수 있습니다:

• 모델이 사용자의 의도를 오해할 수 있습니다.
• 검색 도구가 관련 없는 정보를 반환할 수 있습니다.
• 계정 API가 타임아웃 (Time out)될 수 있습니다.
• 모델이 잘못된 함수를 호출할 수 있습니다.
• 환불 요청은 성공했지만, 응답이 유실될 수 있습니다.
• 에이전트가 동일한 작업을 재시도하여 두 번의 환불을 발생시킬 수 있습니다.
• 작업이 실패했음에도 불구하고 최종 메시지가 성공했다고 주장할 수 있습니다.

모델은 다음 행동을 선택할 수 있지만, 그 행동이 정확하거나, 안전하거나, 완료된다는 것을 자동으로 보장하지는 않습니다.

그것은 자율성이 아닙니다. 그것은 충분한 제어 없는 의사결정일 뿐입니다.

왜 에이전트 워크플로우 (Agent Workflows)가 운영 환경에서 무너지는가

1. 도구 호출 (Tool Calls)은 본질적으로 신뢰할 수 없습니다

언어 모델 (Language models)은 텍스트를 생성합니다. 이들은 API 호출이 유효한지, 파라미터 (parameter)가 안전한지, 혹은 부수 효과 (side effect)가 이미 발생했는지 여부를 본질적으로 이해하지 못합니다.

모델은 기술적으로는 유효하지만 비즈니스 의미상으로는 잘못된 함수 호출을 생성할 수 있습니다:

{
  "user_id": "48291",
  "refund_amount": 499
...

JSON 형식은 완벽할 수 있습니다. 하지만 금액은 여전히 틀릴 수 있습니다.

스키마 검증 (Schema validation)을 통해 파라미터의 존재 여부는 확인할 수 있지만, 해당 동작이 타당한지까지 항상 확인할 수는 없습니다. 운영 환경의 에이전트 (Production agents)에게는 구조화된 출력 (structured output) 이상의 것이 필요합니다. 권한 확인 (permission checks), 비즈니스 규칙 (business rules), 멱등성 제어 (idempotency controls), 그리고 동작 후 검증 (post-action verification)이 필요합니다.

이러한 안전장치가 없다면, 모든 도구는 또 다른 실패 지점 (failure point)이 됩니다.

2. 에이전트가 상태 (State)를 잃을 수 있습니다

장시간 실행되는 에이전트 (Long-running agents)는 종종 여러 시스템과 상호작용합니다. 문서를 읽고, API를 호출하며, 비동기 응답 (asynchronous responses)을 받고, 외부 이벤트를 기다립니다.

시스템이 내구성이 있는 상태 (durable state)를 유지하지 못하면, 에이전트는 다음과 같은 사항을 잊어버릴 수 있습니다:

• 이미 무엇을 수행했는지
• 어떤 도구들이 이미 호출되었는지
• 어떤 동작이 현재 대기 중인지
• 이전 요청이 성공했는지 여부
• 왜 특정 결정을 내렸는지

상태가 불분명해지면, 에이전트는 동작을 반복하거나, 단계를 건너뛰거나, 오래된 정보에 기반하여 결정을 내릴 수 있습니다.

대화 기록 (conversation history)은 신뢰할 수 있는 시스템 상태 (reliable system state)와 동일한 것이 아닙니다. 채팅 로그 (Chat logs)는 문맥 (context) 파악에는 유용하지만, 운영 시스템에는 명시적인 상태 머신 (state machines), 이벤트 기록 (event records), 실행 ID (execution IDs), 그리고 트랜잭션 상태 (transaction status)가 필요합니다.

3. 루프 (Loops)는 만들기 쉽습니다

에이전트는 빈번하게 루프 내부에서 작동합니다:

1. 생각하기 (Think)
2. 도구 호출 (Call a tool)
3. 결과 읽기 (Read the result)
4. 다음 할 일 결정 (Decide what to do next)
5. 반복 (Repeat)

이 구조는 강력하지만 위험합니다.

도구 호출 (tool call) 실패는 모델이 무한히 재시도하게 만들 수 있습니다. 모호한 목표는 불필요한 조사를 유발할 수 있습니다. 상충하는 정보는 반복적인 검색을 트리거할 수 있습니다. 잘못 설계된 중단 조건 (stop condition)은 단순한 작업을 비용이 많이 드는 루프 (loop)로 변질시킬 수 있습니다.

문제는 단지 토큰 사용량만이 아닙니다. 모든 추가적인 반복은 지연 시간 (latency), 비용, 그리고 원치 않는 동작이 발생할 가능성을 증가시킵니다.

프로덕션급 에이전트 (production agent)에는 엄격한 제한 사항이 필요합니다:

• 최대 실행 단계 (Maximum execution steps)
• 타임아웃 (Timeouts)
• 예산 제한 (Budget limits)
• 재시도 정책 (Retry policies)
• 서킷 브레이커 (Circuit breakers)
• 민감한 작업에 대한 인간의 승인 (Human approval)

시스템이 안전하게 멈출 수 없다면, 그것은 자율적인 것이 아닙니다. 그것은 통제되지 않는 것입니다.

모든 문제에 에이전트가 필요한 것은 아니다

에이전트가 필요하지 않은 문제에 에이전트를 추가하려는 경향이 늘어나고 있습니다.

만약 프로세스가 예측 가능하다면, 워크플로우 (workflow)를 사용하십시오.

예를 들어, 송장 처리 (invoice processing)는 다음과 같이 안정적인 순서를 따를 수 있습니다:

1. 송장을 수신합니다.
2. 필드 (fields)를 추출합니다.
3. 공급업체를 검증합니다.
4. 금액을 구매 기록과 비교합니다.
5. 승인을 위해 전송합니다.

LLM은 지저분한 텍스트를 추출하거나 특이한 사례를 분류하는 데 도움을 줄 수 있습니다. 하지만 전체 프로세스에 개방형 의사결정을 내리는 에이전트가 필요하지는 않습니다.

여기서 에이전트를 사용하는 것은 불필요한 불확실성을 초래할 수 있습니다. 결정론적 워크플로우 (deterministic workflow)는 테스트, 모니터링 및 감사가 더 쉽습니다.

에이전트는 다음과 같은 경우에 더 적합합니다:

• 작업에 고정된 해결 경로가 없을 때.
• 시스템이 모호한 정보를 해석해야 할 때.
• 상황에 따라 서로 다른 도구가 필요할 수 있을 때.
• 실행 중에 환경이 변할 때.
• 시스템이 예상치 못한 결과에 적응해야 할 때.

올바른 질문은 "에이전트를 사용할 수 있는가?"가 아닙니다.

더 나은 질문은 "불확실성이 실제로 존재하는 곳은 어디인가?"입니다.

불확실성에는 에이전트를 사용하십시오. 통제에는 워크플로우를 사용하십시오.

프로덕션급 에이전트가 실제로 필요로 하는 것

신뢰할 수 있는 에이전트는 단순히 도구에 연결된 모델이 아닙니다. 그것은 내부에 LLM을 포함한 통제된 실행 시스템입니다.

명확한 경계 (Clear Boundaries)

에이전트는 자신이 무엇을 할 수 있고 무엇을 할 수 없는지 알아야 합니다.

액세스 권한은 역할(role), 사용자(user), 환경(environment), 그리고 작업 유형(action type)에 따라 제한되어야 합니다. 데이터를 읽는 것(Reading data)은 데이터를 수정하는 것(modifying data)과 같지 않습니다. 이메일 초안을 작성하는 것(Drafting an email)은 이메일을 발송하는 것(sending one)과 같지 않습니다.

민감한 작업(Sensitive operations)은 추가적인 검증이나 사람의 승인(human approval)을 필요로 해야 합니다.

구조화된 상태 (Structured State)

시스템은 실행 상태(execution state)를 모델의 대화 기록(conversation history)과 분리하여 저장해야 합니다.

여기에는 다음이 포함됩니다:

• 현재 작업 상태 (Current task status)
• 완료된 작업 (Completed actions)
• 대기 중인 작업 (Pending actions)
• 도구 응답 (Tool responses)
• 오류 (Errors)
• 재시도 횟수 (Retry counts)
• 승인 기록 (Approval records)

상태가 명시적(explicit)일 때, 실패는 미스터리한 현상이 아닌 복구 가능한(recoverable) 사건이 됩니다.

작업 전후의 검증 (Validation Before and After Actions)

도구(tool)를 호출하기 전에, 비즈니스 규칙(business rules)에 따라 요청을 검증하십시오.

도구가 응답한 후에는, 실제로 어떤 일이 일어났는지 확인하십시오.

에이전트가 성공적인 HTTP 응답이 곧 비즈니스 작업의 성공을 의미한다고 가정하게 두지 마십시오. 결제 API(payment API)는 트랜잭션(transaction)이 대기 상태로 남아 있는 동안에도 응답을 반환할 수 있습니다. 데이터베이스 쓰기(database write)는 성공했지만 다운스트림 알림(downstream notification)은 실패할 수 있습니다.

에이전트는 “요청이 전송되었다”, “작업이 성공했다”, 그리고 “사용자에게 알림이 전달되었다”를 반드시 구분해야 합니다.

관측 가능성 (Observability)

에이전트가 실패한다면, 개발자는 그 이유를 알아야 합니다.

이는 다음을 기록하는 것을 의미합니다:

• 모델 입력 및 출력 (Model inputs and outputs)
• 도구 호출 (Tool calls)
• 실행 타이밍 (Execution timing)
• 오류 (Errors)
• 재시도 동작 (Retry behavior)
• 토큰 사용량 (Token usage)
• 라우팅 결정 (Routing decisions)
• 최종 결과 (Final outcomes)

이러한 데이터가 없다면, 팀은 무작위적인 대화 로그를 조사하며 무엇이 잘못되었는지 추측해야만 합니다. 이는 확장 가능하지(scale) 않습니다.

맹목적인 재시도 대신 복구 (Recovery Instead of Blind Retries)

모든 실패에 대해 재시도하는 것은 회복탄력성(resilience)이 아닙니다.

일시적인 네트워크 타임아웃(network timeout)은 재시도를 정당화할 수 있습니다. 하지만 잘못된 파라미터(invalid parameter)는 그렇지 않습니다. 완료된 결제는 단지 확인 응답이 지연되었다는 이유만으로 절대 반복되어서는 안 됩니다.

시스템에는 실패 분류(failure classification), 멱등성 키(idempotency keys), 폴백 경로(fallback paths), 그리고 명확한 에스컬레이션 규칙(escalation rules)이 필요합니다.

신뢰할 수 있는 에이전트 뒤의 인프라 (The Infrastructure Behind Reliable Agents)

모델의 품질(Model quality)도 중요하지만, 이는 시스템의 일부분일 뿐입니다.

에이전트는 작업에 따라 서로 다른 모델이 필요할 수 있습니다. 분류 (classification)를 위한 빠른 모델, 복잡한 추론 (reasoning)을 위한 더 강력한 모델, 그리고 일상적인 응답을 위한 더 저렴한 모델이 필요할 수 있습니다. 또한 모델을 사용할 수 없거나 사용할 수 없는 출력을 생성할 때를 대비한 폴백 제공자 (fallback providers)가 필요할 수도 있습니다.

이 지점에서 인프라 (infrastructure)가 중요해집니다.

Tokenbay와 같은 플랫폼은 모델 액세스를 중앙 집중화하고, 라우팅 (routing)을 관리하며, 요청을 모니터링하고, 여러 제공자에 걸쳐 폴백 (fallback) 옵션을 제공하는 데 도움을 줄 수 있습니다. 더 중요한 것은, 이것이 에이전트 실행 주변의 신뢰성 계층 (reliability layer)의 일부가 될 수 있다는 점입니다.

Tokenbay 시도하기: https://www.tokenbay.com/?utm_source=devto&utm_medium=community_content&utm_campaign=week1_free_content

목표는 모든 실패를 숨기는 것이 아닙니다. 목표는 실패를 가시화하고, 제어 가능하며, 복구 가능하게 만드는 것입니다.

프로덕션 팀은 다음과 같은 간단한 질문에 빠르게 답할 수 있어야 합니다:

• 어떤 모델이 이 결정을 내렸는가?
• 비용이 얼마나 들었는가?
• 어떤 도구 호출 (tool call)이 실패했는가?
• 응답이 검증 (validated)되었는가?
• 시스템이 재시도 (retry)했는가?
• 폴백 (fallback) 모델이 더 나은 성능을 보였는가?
• 실행이 어디에서 중단되었는가?

만약 이러한 질문에 답할 수 없다면, 그 에이전트는 본격적인 프로덕션 사용을 위한 준비가 되지 않은 것입니다.

취약한 워크플로우를 자율적이라고 부르는 것을 멈추십시오

AI 에이전트의 미래는 모델이 얼마나 많은 도구를 호출할 수 있는지에 의해 정의되지 않을 것입니다.

모델이 틀렸을 때, API가 느릴 때, 데이터가 불완전할 때, 또는 환경이 변할 때 전체 시스템이 얼마나 신뢰성 있게 작동하는지에 의해 정의될 것입니다.

진정한 에이전트에는 지능 (intelligence)이 필요하지만, 지능만으로는 충분하지 않습니다. 경계 (boundaries), 상태 (state), 검증 (validation), 관찰 가능성 (observability), 그리고 복구 (recovery) 기능이 필요합니다.

그렇지 않다면, "에이전트"는 그저 가끔 즉흥적으로 행동하다가 자신 있게 망가져 버리는 워크플로우일 뿐입니다.

승리하는 시스템은 무제한의 자율성을 약속하는 시스템이 아닐 것입니다.

그들은 언제 행동해야 하는지, 언제 멈춰야 하는지, 그리고 언제 도움을 요청해야 하는지를 정확히 아는 시스템이 될 것입니다.