모든 게시물 특집 Manoj Yerrasani 2026년 1월 25일 저자 제공

업계의 컨센서스는 2026년이 "에이전트형 AI(agentic AI)"의 해가 될 것이라는 점입니다. 우리는 단순히 텍스트를 요약하는 챗봇 시대를 빠르게 지나고 있습니다. 우리는 작업을 실행하는 자율 에이전트(autonomous agents)의 시대로 진입하고 있습니다. 우리는 이들이 항공편을 예약하고, 시스템 중단을 진단하며, 클라우드 인프라를 관리하고, 실시간으로 미디어 스트림을 개인화할 것으로 기대합니다.

올림픽과 슈퍼볼 같은 대규모 글로벌 이벤트 동안 3천만 명의 동시 사용자를 서비스하는 플랫폼을 총괄하는 기술 임원으로서, 저는 과대광고 뒤에 숨겨진 매력 없는 현실을 목격했습니다. 에이전트는 믿을 수 없을 정도로 취약합니다. 경영진과 벤처 캐피탈리스트(VC)들은 모델 벤치마크에 집착합니다. 그들은 라마 3(Llama 3)와 GPT-4를 놓고 논쟁합니다. 그들은 컨텍스트 윈도우(context window) 크기를 최대화하는 데 집중합니다. 하지만 그들은 실제 실패 지점을 간과하고 있습니다. 자율 에이전트가 프로덕션 환경에서 실패하는 주된 이유는 종종 데이터 위생(data hygiene) 문제 때문입니다.

이전의 "휴먼 인 더 루프(human-in-the-loop)" 분석 시대에는 데이터 품질이 관리 가능한 골칫거리였습니다. ETL 파이프라인에 문제가 발생하면 대시보드에 잘못된 매출 수치가 표시될 수 있습니다. 인간 분석가는 이상 징후를 발견하고, 플래그를 지정하고, 수정했을 것입니다. 피해 범위는 제한적이었습니다. 자율 에이전트의 새로운 세상에서는 그 안전망이 사라졌습니다. 오늘날 데이터 파이프라인이 드리프트(drift)되면 에이전트는 단순히 잘못된 숫자를 보고하는 데 그치지 않습니다. 잘못된 조치를 취합니다. 잘못된 서버 유형을 프로비저닝합니다. 만화를 보는 사용자에게 공포 영화를 추천합니다. 손상된 벡터 임베딩(vector embeddings)을 기반으로 고객 서비스 답변을 환각(hallucinate)합니다.

NFL이나 올림픽 규모로 AI를 운영하기 위해서는 표준적인 데이터 클리닝으로는 불충분하다는 것을 깨달았습니다. 우리는 데이터를 단순히 "모니터링"할 수 없습니다. 우리는 데이터를 "입법화"해야 합니다. 이 특정 문제에 대한 해결책은 '데이터 품질 – 신조(creed)' 프레임워크의 형태일 수 있습니다. 이는 데이터 헌법(data constitution) 역할을 합니다. 단 한 바이트의 데이터라도 AI 모델에 도달하기 전에 수천 개의 자동화된 규칙을 강제합니다. 제가 이 방법을 NBCUniversal의 스트리밍 아키텍처에 구체적으로 적용했지만, 이 방법론은 AI 에이전트를 운영하려는 모든 기업에 보편적으로 적용될 수 있습니다. 여기에 "방어적 데이터 엔지니어링(defensive data engineering)"과 크리드(Creed) 철학이 에이전트 시대(Agentic era)를 살아남을 수 있는 유일한 방법인 이유가 있습니다.

The vector database trap

AI 에이전트의 핵심 문제는 그들에게 주어지는 컨텍스트(context)를 맹목적으로 신뢰한다는 것입니다. RAG(Retrieval Augmented Generation)를 사용한다면, 벡터 데이터베이스(vector database)는 에이전트의 장기 기억(long-term memory)입니다. 표준적인 데이터 품질 문제는 벡터 데이터베이스에 치명적입니다. 전통적인 SQL 데이터베이스에서는 널(null) 값은 그저 널 값일 뿐입니다. 벡터 데이터베이스에서는 널 값이나 스키마 불일치(schema mismatch)가 전체 임베딩(embedding)의 의미론적 의미(semantic meaning)를 왜곡할 수 있습니다.

메타데이터(metadata)가 드리프트되는 시나리오를 고려해 봅시다. 파이프라인이 비디오 메타데이터를 수집하지만, 경쟁 조건(race condition)으로 인해 "장르(genre)" 태그가 누락된다고 가정해 봅시다. 메타데이터는 비디오를 "라이브 스포츠"로 태그할 수 있지만, 임베딩은 "뉴스 클립"에서 생성되었을 수 있습니다. 에이전트가 데이터베이스에서 "터치다운 하이라이트"를 쿼리할 때, 벡터 유사성 검색(vector similarity search)이 손상된 신호에서 작동하기 때문에 뉴스 클립을 검색합니다. 에이전트는 그 클립을 수백만 명의 사용자에게 제공합니다. 대규모 환경에서는 다운스트림 모니터링(downstream monitoring)에 의존하여 이를 감지할 수 없습니다. 이상 징후 경보가 울릴 때쯤이면 에이전트는 이미 수천 가지의 잘못된 결정을 내렸을 것입니다. 품질 관리는 파이프라인의 절대적인 "왼쪽(left)"으로 이동해야 합니다.

The "Creed" framework: 3 principles for survival

크리드(Creed) 프레임워크는 게이트키퍼(gatekeeper) 역할을 할 것으로 예상됩니다. 이는 수집 소스(ingestion sources)와 AI 모델 사이에 위치하는 다중 테넌트(multi-tenant) 품질 아키텍처입니다. 자신만의 "헌법"을 구축하려는 기술 리더들을 위해 제가 추천하는 세 가지 필수 원칙은 다음과 같습니다.

• 1. "격리(quarantine)" 패턴은 필수입니다: 많은 현대 데이터 조직에서 엔지니어들은 "ELT" 접근 방식을 선호합니다. 그들은 원시 데이터(raw data)를 데이터 레이크(data lake)에 덤프하고 나중에 정리합니다. AI 에이전트에게 이것은 용납될 수 없습니다. 오염된 호수에서 에이전트가 물을 마시게 할 수는 없습니다. 크리드 방법론은 엄격한 "데드 레터 큐(dead letter queue)"를 강제합니다. 데이터 패킷이 계약을 위반하면 즉시 격리됩니다. 벡터 데이터베이스에 도달하지 않습니다. 에이전트가 잘못된 데이터 때문에 자신 있게 거짓말하는 것보다 누락된 데이터 때문에 "모르겠다"고 말하는 것이 훨씬 낫습니다. 이 "서킷 브레이커(circuit breaker)" 패턴은 주목할 만한 환각(hallucinations)을 방지하는 데 필수적입니다.
• 2. 스키마(Schema)는 법입니다: 수년 동안 업계는 빠르게 움직이기 위해 "스키마리스(schemaless)" 유연성으로 나아갔습니다. 우리는 핵심 AI 파이프라인에 대해 그 추세를 뒤집어야 합니다. 우리는 엄격한 타이핑(typing)과 참조 무결성(referential integrity)을 강제해야 합니다. 제 경험상, 견고한 시스템은 규모를 필요로 합니다. 제가 감독하는 구현은 현재 실시간 스트림(real-time streams) 전반에 걸쳐 1,000개 이상의 활성 규칙을 강제하고 있습니다. 이들은 단순히 널 값을 확인하는 것이 아닙니다. 비즈니스 로직 일관성(business logic consistency)을 확인합니다.
  • • 예시: 이벤트 스트림(event stream)의 "user_segment"가 피처 스토어(feature store)의 활성 분류 체계(taxonomy)와 일치하는가? 일치하지 않으면 차단합니다.
  • • 예시: 타임스탬프(timestamp)가 실시간 추론(real-time inference)을 위한 허용 가능한 지연 시간(latency) 범위 내에 있는가? 그렇지 않으면 삭제합니다.
• 3. 벡터 일관성 검사(Vector consistency checks) 이것은 SRE(Site Reliability Engineer)의 새로운 개척지입니다. 우리는 벡터 데이터베이스에 저장된 텍스트 청크(text chunks)가 실제로 그들과 관련된 임베딩 벡터(embedding vectors)와 일치하는지 확인하기 위한 자동화된 검사를 구현해야 합니다. 임베딩 모델 API(embedding model API)의 "조용한" 실패는 종종 아무것도 가리키지 않는 벡터를 남깁니다. 이는 에이전트가 순수한 노이즈(noise)를 검색하게 만듭니다.

The culture war: Engineers vs. governance

크리드와 같은 프레임워크를 구현하는 것은 단순히 기술적인 도전이 아닙니다. 그것은 문화적인 도전입니다. 엔지니어들은 일반적으로 가드레일(guardrails)을 싫어합니다. 그들은 엄격한 스키마와 데이터 계약(data contracts)을 배포 속도(deployment velocity)를 늦추는 관료적인 장애물로 간주합니다. 데이터 헌법을 도입할 때, 리더들은 종종 반발에 직면합니다. 팀들은 엄격한 데이터베이스 관리의 "폭포수(waterfall)" 시대로 돌아가는 것처럼 느낍니다. 성공하려면 인센티브 구조(incentive structure)를 뒤집어야 합니다. 우리는 크리