AI 에이전트를 다시 생각하게 만든 신뢰성 문제

고객 프로젝트를 위해 AI 에이전트를 구축한 지 몇 달이 지났을 때, 우리는 이 기술을 데모 단계를 넘어 실제로 출시하려는 사람이라면 누구나 익숙할 법한 패턴에 직면했습니다. 에이전트가 이해관계자들 앞에서는 아주 훌륭하게 작동하다가, 실제 사용자들이 손을 대는 순간 조용히 무너지는 현상이었습니다.

재앙적인 수준은 아니었습니다. 그랬다면 차라리 발견하기가 더 쉬웠을 것입니다.

도구 호출 (Tool call)이 약간 잘못된 인자 (Argument)와 함께 이루어져 재시도 루프 (Retry loop)에 빠지기도 했습니다. 다단계 작업 (Multi-step task)은 실행 중간에 원래의 목표에서 벗어나기도 했습니다. 에이전트는 아무런 유용한 성과도 내지 못하면서 자신 있게 성공했다고 보고하기도 했습니다.

시스템이 충돌한 것도 아니었고, 아무도 호출을 받지 않았습니다. 피해는 신뢰가 서서히 새어나가는 것이었습니다.

그 순간 우리는 신뢰성을 모델이 언젠가 충분히 갖게 될 속성으로 취급하는 것을 멈추고, 우리가 직접 설계 (Engineer)해야 하는 대상으로 취급하기 시작했습니다.

데모는 신뢰성에 대해 거짓말을 한다

데모는 시스템을 통과하는 큐레이션된 경로입니다.

당신은 모델이 잘 처리할 수 있다고 알고 있는 질문을, 모델이 이해할 수 있다고 알고 있는 방식으로 던지며, 모델이 경로를 이탈할 기회를 갖기 전에 멈춥니다.

실제 운영 환경 (Production)은 그런 친절을 베풀지 않습니다.

사용자들은 말을 바꾸기도 합니다. 대화 중간에 앞뒤가 맞지 않는 말을 하기도 합니다. 잘못된 형식의 데이터를 붙여넣기도 합니다. 당신의 평가 세트 (Evaluation set)에 있는 그 어떤 것과도 세 단계나 떨어진 것을 요구하기도 합니다.

우리가 깨달은 불편한 진실은, 실제 세상에서 에이전트의 신뢰성은 신중하게 선택된 15개의 사례에서 얼마나 인상적으로 보였는지와는 거의 관련이 없다는 점이었습니다.

그것은 아무도 예상하지 못한 상황들, 즉 롱테일 (Long tail) 상황에서 어떻게 행동하느냐와 모든 관련이 있습니다.

우리의 생각을 바꾼 사건

특히 한 가지 워크플로 (Workflow)가 우리의 가설을 다시 생각하게 만들었습니다.

우리는 여러 소스에서 정보를 수집하고 외부 시스템의 기록을 업데이트하는 역할을 담당하는 에이전트를 보유하고 있었습니다. 대부분의 경우 완벽하게 작동했습니다.

그러다 산발적으로 중복된 기록이 나타나는 것을 발견하기 시작했습니다.

로그를 조사한 끝에, 우리는 원인을 찾아냈습니다.

외부 시스템은 업데이트를 성공적으로 완료했지만, 응답이 에이전트(agent)에 도달하기 전에 타임아웃(timeout)을 반환했습니다. 에이전트는 이 타임아웃을 실패로 해석하고 작업을 재시도했습니다. 업데이트는 이미 성공했기 때문에, 재시도가 중복을 생성했습니다.

모델은 환각 (hallucination)을 일으키지 않았습니다.

추론 (reasoning)이 틀린 것도 아니었습니다.

실패는 주변 시스템이 불확실성 (uncertainty)을 처리하는 방식에서 발생했습니다.

그 깨달음은 우리가 신뢰성 (reliability)에 접근하는 방식을 바꾸어 놓았습니다.

신뢰성은 단일한 개념이 아니다

오랫동안 우리는 신뢰성을 하나의 모호한 목표로 취급했습니다.

그러한 접근 방식의 문제는 정의할 수 없는 것은 개선할 수 없다는 점입니다.

신뢰성을 별개의 관심사로 나누는 것은 추론을 훨씬 쉽게 만들어 주었습니다.

결정론 (Determinism)

동일한 입력이 매번 거의 동일한 동작을 생성합니까, 아니면 에이전트가 실행할 때마다 다르게 행동합니까?

실패 가시성 (Failure Visibility)

무언가 잘못되었을 때, 시스템이 크고 명확하게 실패를 알립니까, 아니면 확신에 찬 듯하지만 틀린 답을 생성합니까?

복구 가능성 (Recoverability)

워크플로 (workflow)가 실행 도중 절반쯤 실패했을 때, 안전하게 재개할 수 있습니까, 아니면 처음부터 다시 시작해야 합니까?

유계성 (Boundedness)

에이전트가 언제 멈춰야 할지를 알고 있습니까, 아니면 만족스러운 결론에 도달하지 못해 도구 (tool) 호출을 무한히 계속할 수 있습니까?

우리가 이것들을 별개의 엔지니어링 문제로 다루기 시작하자, 신뢰성을 개선하는 것이 훨씬 쉬워졌습니다.

우리가 실제로 변경한 것들

영리한 도구 대신 더 작은 도구들

우리의 초기 도구 정의는 유연성을 확보하려 노력했습니다.

단일 도구가 수많은 선택적 매개변수 (optional parameters)를 수용하고 여러 가지 다른 워크플로를 지원할 수 있도록 했습니다.

이론적으로는 그것이 개발을 더 쉽게 만들었습니다.

실제로는 모호성을 증가시켰습니다.

모델은 동일한 도구를 호출하는 너무 많은 방법을 가지고 있었고, 우리는 검증해야 할 코드 경로 (code paths)가 너무 많았습니다.

우리는 이를 하나의 작업을 잘 수행하고 엄격한 스키마 (schema)를 강제하는, 범위가 좁고 작은 도구들로 교체했습니다.

잘못된 형식의 도구 호출이 감소하는 효과는 즉각적이었습니다.

신뢰할 수 없는 입력처럼 출력 검증하기

왜냐하면 그것들이 정확히 그런 존재들이기 때문입니다.

이제 모든 구조화된 응답 (structured response)은 실제 동작을 트리거하기 전에 스키마 검증 (schema validation)을 거칩니다.

검증 실패는 예외적인 상황이 아니라 워크플로 (workflow) 내에서 예상된 분기 (branch)로 취급됩니다.

이 단 한 번의 변화로 수많은 다운스트림 실패 (downstream failures)를 방지할 수 있었습니다.

멱등성 (Idempotency) 및 서킷 브레이커 (Circuit Breakers)

재시도 (Retries)은 유용하지만, 유용하지 않은 시점이 옵니다.

우리가 겪은 가장 기이한 버그 중 일부는 부분적으로 성공한 동작을 재시도하는 과정에서 발생했습니다.

우리는 가능한 모든 곳에 멱등적 동작 (idempotent operations)을 도입했으며, 무한 루프를 허용하는 대신 서킷 브레이커 (circuit breakers)를 통해 재시도 횟수를 제한했습니다.

이제 실패가 발생하면, 깔끔하고 명확하게 실패합니다.

에이전트 상태의 체크포인팅 (Checkpointing Agent State)

더 긴 워크플로의 경우, 각 완료된 단계 이후에 상태 (state)를 지속화 (persist)합니다.

7단계 프로세스가 4단계에서 실패하면, 에이전트는 처음 3개의 동작을 반복하는 대신 4단계부터 재개합니다.

이를 통해 중복된 부작용 (side effects)을 줄였고 복구를 훨씬 더 예측 가능하게 만들었습니다.

되돌릴 수 없는 동작에 대한 인간의 승인 (Human Approval)

이메일 발송.

카드 결제.

레코드 삭제.

콘텐츠 게시.

이러한 동작들은 이제 모델의 확신 (confidence)에만 의존하는 대신, 명시적인 승인 게이트 (approval gates)를 거칩니다.

확신 (Confidence)과 정확성 (correctness)은 동일한 신호가 아닙니다.

이 둘을 동일하게 취급하는 것은 불필요한 리스크를 초래합니다.

평가 (Evals)를 회귀 테스트 (Regression Tests)로 전환하기

대부분의 팀은 배포 전에 평가 (evaluations)를 실행합니다.

우리는 이를 영구적인 회귀 테스트 세트 (regression suite)로 취급하기 시작했습니다.

프로덕션 환경에서 에이전트가 실패할 때마다, 우리는 해당 사례를 캡처하여 테스트 세트에 추가했습니다.

이는 향후 모든 변경 사항이 과거의 실패를 다시 불러오지 않는다는 것을 증명해야 함을 의미했습니다.

우리의 가장 유망했던 '개선 사항' 중 일부는 한 가지 문제를 해결하는 동시에 세 가지 새로운 문제를 만드는 것으로 밝혀지기도 했습니다.

회귀 테스트 (regression testing)가 없었다면 우리는 결코 이를 알아차리지 못했을 것입니다.

모든 단계의 트레이싱 (Tracing Every Step)

이것은 가장 화려하지 않은 개선이었지만, 아마도 가장 가치 있는 개선이었을 것입니다.

우리는 모든 추론 단계 (reasoning step), 도구 호출 (tool call), 검증 체크 (validation check), 그리고 결정 지점 (decision point)을 트레이싱 (tracing)하기 시작했습니다.

디버깅 (Debugging)이 더 이상 고고학처럼 느껴지지 않게 되었습니다.

우리가 겪었던 수많은 미스터리한 실패들의 대부분은, 그 실패로 이어진 일련의 사건들을 직접 볼 수 있게 되자마자 명확해졌습니다.

이 중 그 어떤 것도 에이전트를 더 똑똑하게 만들지는 않았습니다

이 점은 강조할 가치가 있습니다.

이러한 변화 중 그 어떤 것도 모델의 추론 능력 (reasoning ability)을 향상시키지는 않았습니다.

이들이 한 일은 추론 오류가 운영 환경의 문제 (production problem)로 이어질 수 있는 경로의 수를 줄이는 것이었습니다.

그들은 실패를 가시화했습니다.

그들은 실패를 복구 가능하게 만들었습니다.

그들은 상황이 필연적으로 잘못되었을 때의 영향 범위 (blast radius)를 줄였습니다.

이러한 차이가 오늘날 우리가 프로젝트의 범위를 설정하는 방식을 바꾸어 놓았습니다.

우리는 더 이상 다음과 같은 질문으로 시작하지 않습니다:

모델이 이 작업을 수행할 수 있는가?

점점 더, 그 대답은 '예'가 되고 있습니다.

대신, 우리는 다음과 같이 질문합니다:

이 작업이 실패할 때—그리고 반드시 실패할 것입니다—그 실패는 어떤 모습이며, 누가 이를 인지하고, 어떻게 복구할 것인가?

이 질문이 훨씬 더 중요하다는 사실이 밝혀졌습니다.

만약 당신이 지금 AI 에이전트를 구축하고 있다면

여정의 초기에 있는 팀들과 공유하고 싶은 몇 가지 교훈입니다:

• 프롬프트 (prompts)를 작성하기 전에 실패 사례 (failure cases)를 먼저 기록하세요.
• 하나의 도구 (tool)가 다섯 가지 일을 하게 두지 마세요.
• 모든 구조화된 출력 (structured output)을 검증 (validate)하세요.
• 최종 답변뿐만 아니라 중간 추론 과정과 도구 호출 (tool calls)을 로그 (log)로 남기세요.
• 재시도 (retries)를 기본 반응이 아닌 신뢰성 전략 (reliability strategy)으로 취급하세요.
• 어떤 작업이 되돌릴 수 있는지(reversible)와 그렇지 않은지를 결정하세요.
• 실제 운영 환경에서의 실패 사례를 평가 세트 (evaluation suite)에 추가하세요.

해피 패스 (happy path)는 좀처럼 어려운 부분이 아닙니다.

신뢰성은 엣지 케이스 (edge cases)에서 승패가 갈립니다.

마치며

우리는 여전히 에이전트가 우리를 놀라게 할 새로운 방식들을 발견하고 있습니다.

그 부분은 아마 영원히 사라지지 않을 것입니다.

하지만 이제 실패의 모습은 달라졌습니다.

침묵하는 대신 가시화되었습니다.

끝이 없는 대신 경계가 생겼습니다.

재앙적인 대신 복구 가능해졌습니다.

운영 시스템 (production systems)에 있어서, 그것이 전투의 대부분입니다.

모델이 계속해서 개선됨에 따라, 신뢰성은 모델 품질의 문제라기보다 점점 더 엔지니어링의 과제가 될 것입니다.

이러한 변화를 조기에 인식하는 팀들이 사용자가 신뢰할 수 있는 시스템을 구축할 것입니다.

만약 여러분도 유사한 과제들을 해결하고 있다면, 특히 장기 실행 에이전트 워크플로우 (long-running agent workflows)에서 복구 가능성 (recoverability)과 상태 관리 (state management)에 어떻게 접근하고 계신지 매우 궁금합니다. 이 부분은 저희가 여전히 적극적으로 개선해 나가고 있는 영역 중 하나입니다.