왜 AI 에이전트는 프로덕션에서 실망스러울까
데모에서 완벽했던 AI 에이전트가 실제 운영 환경에서 무너지는 이유는 에이전트가 아니라 데이터 인프라에 있다.
프로덕션에서 에이전트에게 도로 위를 달리라고 요청하는데, 그 도로가 대시보드에 맞게 만들어진 도로라면 결과는 실망스러울 수밖에 없다. 신뢰할 수 있는 에이전트를 원한다면 하부 구조에 다음과 같은 네 가지 보장을 구현해야 한다.
AI 에이전트가 데모에서 뛰어난 이유는 데모가 에이전트에 친화적인 환경이기 때문이다. 데이터는 선별되고 툴은 제대로 작동한다. 에이전트가 생각하는 도중에 중요한 요소가 변경되는 일도 없다. 그러나 프로덕션은 그 반대다. 데이터는 늦게 도착하고 사실 관계는 충돌하고 권한이 돌발 변수가 되고 API는 타임아웃되고 기저 상태는 끊임없이 변한다.
이 간극은 초기 “프로덕션 에이전트”의 작동 범위가 읽기 전용 어시스턴트나 HIL(인간 개입) 워크플로우 또는 고도로 선별된 데이터가 사용되는 협소한 도메인과 같이 좀더 안전한 영역으로 축소되는 이유다. 주목을 받으며 배포됐지만 복잡다단한 현실 세계의 제약에 직면한 후 규모가 축소된 사례도 여럿 존재한다. 이런 헛발질은 자율성이 냉혹하다는 사실을 상기시켜 준다. 데이터 스택에 생긴 작은 균열은 에이전트 행동의 큰 균열로 이어진다.
이 패턴은 에이전트가 아주 간단한 워크플로우에서 본격적인 시스템으로 이동할 때마다 나타난다. 느슨한 보장은 범위가 확장되면서 고질적인 증상으로 이어진다. 즉, 오래된 데이터를 과도하게 확신하는 행동, 의미가 표류하는 상황에서의 불안정한 추론, 그리고 에이전트가 다시 쓸 때 복합적으로 발생하는 오류 등이다.
해결책은 에이전트를 있는 그대로, 라이브 운영 데이터를 대상으로 읽고 추론하고 쓰는 시스템으로 취급하는 것이다. 이를 위해서는 대다수 엔터프라이즈 스택이 암묵적으로만 제공하는 보장 조치를 마련해야 한다. 가장 중요한 네 가지 보장은 최신성, 의미론, 안전한 쓰기 경로, 계보다.
최신성 : 과거에 대한 추론은 그만
많은 기업이 일괄 처리 파이프라인, 복제 지연, 캐시, 지연된 CDC(변경 데이터 캡처), 구체화된 뷰와 같은 오래된 상태와 타협한다. 인간이 판단력으로 이를 보완한다면 에이전트는 근거 없는 자신감으로 보완한다.
프로덕션에서 일반적으로 발생하는 실패는 잘못된 시간에 대해 이뤄지는 올바른 추론이다. 에이전트가 몇 분 이전 상태의 재고를 읽고 재주문을 트리거하지만 이는 이미 진행 중인 재고 보충 작업과 충돌한다. 또는 에이전트 관점에서 한 시스템에서는 사고가 해결된 것으로 표시되지만 다른 시스템에서는 여전히 롤백이 대기 중인 것으로 나타나는 경우, 에이전트는 대기해야 할 변경 작업을 그대로 진행한다. 이런 착오는 말 그대로 최신성 버그다.
“최신성 보장”은 시간이 최우선임을 의미한다. 사실에는 타임스탬프가 있다. 쿼리는 명확한 “특정 시점 기준의 의미 체계를 지원하므로 에이전트는 시간 T에서 무엇이 진실이었고 지금은 무엇이 진실이며 마지막 행동 이후 무엇이 변했는지 물을 수 있다. 워크플로우는 의존하는 데이터에 대해 최신성 서비스 수준 목표(SLO)를 선언한다. 플랫폼이 이를 충족하지 못하면 에이전트는 작업을 일지 중단하고 확인을 요청하거나 읽기 전용 계획으로 전환한다.
최신성에는 배포라는 측면도 존재한다. 공장에서 소매점에 이르기까지, 많은 에이전트 사용례는 본질적으로 로컬이다. 저지연 컨텍스트가 필요한 경우 모든 것을 중앙 저장소로 밀어넣고 루프를 돌아 나오기를 기다린다면 그건 최적화 문제가 아니라 설계 결함이다.
의미론 : 의미를 추론하도록 하지 말고 명확히 할 것
데이터가 겉으로 보기에는 정확하지만 그 의미가 시스템마다 다르면 에이전트도 더 모호하게 실패한다. 고객 대 계정, 주문 대 거래, 팀 간의 표류하는 상태 코드, 중복된 식별자, 일관성 없는 명명. 각 시스템이 로컬에서 올바르더라도 전역에서 에이전트는 틀릴 수 있다.
사람들은 이 지점에서 벡터 검색을 가져온다(이를 메모리라고 함). 임베딩은 유사성에는 탁월하지만 복잡한 구조와 제약을 표현하는 데는 떨어진다. 실제 작업에서 유사성은 관련된 자료를 찾는 데 도움이 될 수 있지만 의미론적 계약을 제공하지는 않는다. “이 고객”이 CRM, 청구, 지원, ID 시스템 전반에 걸쳐 동일한 엔티티임을 강제할 수 없다. “디바이스는 한 번에 정확히 하나의 사이트에만 속한다” 또는 “환불에는 그에 상응하는 정산이 필요하다”는 식의 제약을 자연스럽게 인코딩할 수 없다. 에이전트는 흐릿한 기억에 의존해 결정론적 작업을 수행하면서 확신에 찬 듯이 행동한다.
의미론적 보장은 엔티티와 관계의 명시적인 모델, 많은 경우 운영 레코드와 이를 설명하는 문서 및 신호를 연결하는 “컨텍스트 그래프”를 의미한다. 분석 쿼리를 위해 데이터를 일괄 처리로 가져오던 과거의 지식 그래프 프로그램에서 바뀐 형태다. 새로운 에이전트 사용례는 지속적인 데이터 스트리밍이다. 데이터의 상당수는 문서와 파일이고, 동일한 운영 루프 내에서 실시간 읽기/쓰기와 결합된다.
안전한 쓰기 경로
읽기 전용 에이전트는 틀릴 때도 여전히 유용할 수 있지만 쓰기 권한을 가진 에이전트가 틀릴 경우 그 결과는 파괴적이다. 특히 복합적인 연쇄 효과가 위험하다. 잘못된 업데이트가 다음 단계의 기준 진실이 되고 재시도가 중복되고 불완전한 쓰기로 인해 일관성이 깨지게 된다.
안전한 쓰기 경로의 시작은 트랜잭션 보장이다. ACID 트랜잭션은 상태 전환의 일관성을 유지한다. 멱등성이 중요한 이유는 에이전트는 재시도하고 네트워크는 동요하기 때문이다. 동시성 제어가 중요한 이유는 상태를 변경하는 주체가 에이전트뿐인 경우는 거의 없기 때문이다. 그 다음으로 가드레일이 있다. 프롬프트에 매몰되는 가드레일이 아니라 플랫폼에서 강제하는 행 수준 보안, 역할 기반 액세스, 제약 조건 등이다.
실용적인 패턴은 계획-검증-커밋이다. 에이전트가 구조화된 변경 모음을 제안하고 이를 현재 상태 및 제약 조건을 기준으로 검증한 다음 행동과 근거를 연결하는 감사 레코드와 함께 커밋한다. 승인은 위험에 따라 자동화하거나 사람이 할 수 있지만 쓰기 경로는 엄격하게 통제된다.
계보 : 추적할 수 없는 의사결정은 개선도 불가능
에이전트가 잘못되면 단순한 질문, “에이전트가 본 것이 무엇인가?”에 대한 답을 찾아야 한다. 그 정보가 없으면 디버깅은 고고학이나 마찬가지다.
계보는 데이터와 행동을 연결한다. 여기에는 레코드와 문서의 출처뿐만 아니라 어떤 검색 결과가 사용됐는지, 어떤 툴이 호출됐는지, 어떤 정책이 적용됐고 그 결과 무엇이 변경됐는지와 같은 에이전트별 트레이스가 포함된다. AI 네이티브 플랫폼은 이를 실용적으로 캡처하고 쿼리할 수 있도록 해야 한다. 여기에는 고위험 행동에 대한 변경 불가능한 감사 트레일, 핵심 엔티티에 대한 버전 관리 또는 시점 이동, 그리고 의사결정 시점에 사용된 정확한 데이터 스냅샷으로의 링크가 포함돼야 한다. 재생 가능한 시나리오, 회귀 테스트, 표류 감지를 통해 평가가 엔지니어링이 되는 방식이기도 하다.
AI 네이티브 데이터 플랫폼이 제공하는 것
위에 설명한 네 가지 보장은 동일한 결론을 낸다. 에이전틱 워크로드에서 단편화에는 대가가 따른다는 점이다. 부가적인 데이터스토어, 인덱스, 파이프라인이 더해질 때마다 시맨틱이 표류하고 최신성이 실패할 여지도 늘어난다. 에이전트는 런타임에 5개의 시스템을 이리저리 이어 붙이게 된다. 이 런타임 결합에서 일관성이 파괴된다. 에이전트는 이런 시스템 전반에서 지속적으로 작동하므로 통합 결함을 더 증폭시킨다.
AI 네이티브 데이터 플랫폼은 운영의 진실, 의미론적 컨텍스트, 검색 신호를 한곳에 표현할 수 있는 기반이며, 트랜잭션의 정확성, 통제된 쓰기, 감사 가능한 이력을 제공한다. 이는 일반적으로 에이전트가 동일한 워크플로우에서 필요로 하는 모든 데이터 형태, 즉 관계형 레코드와 JSON 문서, 그래프 관계, 시계열 이벤트, 벡터 임베딩에 대한 네이티브 지원을 의미한다. 또한 여러 서비스에 걸쳐 데이터를 전송하지 않고도 구조화된 필터, 관계 추적, 유사성 검색을 혼합할 수 있는 구성 가능한 쿼리에 대한 지원을 의미하기도 한다.
또 다른 요구사항은 배포 유연성이다. 데이터 배관 작업은 대체로 프론트엔드 UX보다 느리게 움직인다. 보기 좋은 인터페이스는 대규모로 시스템 일관성을 유지하는 고된 작업에 비해 이해하기 쉽기 때문이다. 에이전트는 이 배관 문제를 표면으로 끄집어낸다. 클라우드, 자체 호스팅 환경, 메모리, 에지에서 동일한 엔진을 실행할 수 있는 플랫폼은 오케스트레이션 오버헤드를 줄이고 보장을 쉽게 유지할 수 있게 해준다.
시작 : 엔지니어를 위한 에이전트 준비 상태 체크리스트
처음부터 완전한 자율성이 필요한 경우는 거의 없다. 명확한 보장이 먼저다.
읽기 경로부터 시작한다. 에이전트가 자문 역할을 하는 동안 검색 품질, 최신성 경계, 의미론적 일관성을 검증한다. 신뢰할 수 있는 소스, 엔티티 통합 규칙, 중요한 관계, 그리고 각 워크플로우에서 “충분히 최신인 데이터”의 기준이 무엇인지에 대한 컨텍스트 계약을 정의한다. 기본적으로 계보를 구축해서 모든 추천의 근거를 추적할 수 있도록 한다.
쓰기는 점진적으로 도입한다. 초기 행동의 범위는 되돌릴 수 있는 작업으로 제한한다. 툴 호출은 멱등성을 갖추도록 하고 트랜잭션을 사용한다. 규칙 시행은 플랫폼 계층에서 이뤄지도록 한다. 승인은 조율 가능한 통제 수단으로 취급하되, 위험과 영향 범위가 큰 경우 사람이 승인하도록 한다.
프로덕션에서 에이전트를 향해 도로 위를 달리라고 요청하는데, 그 도로가 대시보드에 맞게 만들어진 도로라면 결과는 실망스러울 수밖에 없다. 하부 구조에 네 가지 보장을 구축하면 같은 모델이 훨씬 더 신뢰할 수 있는 시스템으로 작동하기 시작할 것이다. 이것이 “에이전트 메모리”와 “컨텍스트 그래프” 뒤에 숨겨진 화려하지 않은 진실이다. 이는 인프라 작업이지만 데모에서 배포로 가는 가장 빠른 길이기도 하다.
