AI 에이전트가 실패하는 이유는 모델이 아니라 데이터 레이어 때문입니다

제가 계속해서 목격하고 있는 패턴이 하나 있습니다. 한 팀이 AI 에이전트를 구축하고, 데모는 잘 작동하며, 제품을 출시합니다. 하지만 몇 주 지나지 않아 출력 결과가 신뢰할 수 없게 됩니다. 누군가는 환각 (Hallucinations)에 대해 티켓을 발행합니다. 다른 누군가는 더 나은 모델로 교체할 것을 제안합니다.

문제는 모델이 아닙니다. 모델에 공급되는 데이터가 문제입니다.

실제 실패의 해부학

OpenHands 및 MetaGPT와 같은 멀티 에이전트 프레임워크 (Multi-agent frameworks)는 실제 운영 환경과 유사한 조건에서 85% 이상의 실패율을 보입니다. 이러한 실패는 하나의 근본 원인으로 집중됩니다. 에이전트가 모호하거나, 일관성이 없거나, 의미론적으로 잘못된 컨텍스트 (Context)를 전달받았고, 이를 바탕으로 확신에 찬 답변을 생성했다는 점입니다.

제가 목격한 대부분의 사례는 다음 세 가지 패턴으로 설명됩니다:

1. 문서화되지 않은 스키마 (Undocumented schemas)

당신의 에이전트가 데이터베이스 도구를 호출하여 accounts라는 테이블의 행을 가져옵니다. 해당 테이블에서 status는 무엇을 의미할까요? 유효한 값은 무엇인가요? null은 비활성 상태를 의미하나요, 설정된 적이 없음을 의미하나요, 아니면 검토 대기 중임을 의미하나요?

모델은 알지 못합니다. 컨텍스트로부터 추론할 뿐입니다. 때로는 맞게 추측하기도 하지만, 그렇지 않은 경우가 훨씬 많습니다.

해결책은 스키마 레지스트리 (Schema registry)입니다. 에이전트가 쿼리할 모든 필드에 대해 자연어로 작성된 구조화된 설명을 시스템 컨텍스트 (System context)로 첨부하는 것입니다.

SCHEMA_REGISTRY = {
    "accounts": {
        "status": {
...

2. 추론 전 정규화 부재 (No normalization before inference)

만약 당신의 에이전트가 하나 이상의 데이터 소스에서 정보를 가져온다면 — 그리고 거의 확실히 그럴 것입니다 — 해당 소스들은 서로 다른 관례를 사용합니다. 한 벤더는 날짜를 MM/DD/YYYY 형식으로 보내고, 내부 시스템은 ISO 8601을 사용합니다. CRM은 통화를 $1,234.56로 내보내지만, 데이터 웨어하우스에는 센트 단위의 부동 소수점 (Float)으로 저장되어 있습니다.

def normalize_record(record: dict, source: str) -> dict:
    normalized = record.copy()

...

3. 최신성 추적 부재 (No freshness tracking)

당신의 에이전트는 확신에 차 있습니다. 고객의 질문에 답하기 위해 가격 데이터를 사용하고 있습니다. 하지만 그 가격 데이터는 72시간 전에 마지막으로 업데이트되었고, 어제 변경 사항이 있었습니다. 에이전트는 이를 알지 못합니다.

def get_data_with_freshness(table: str, db_conn) -> dict:
    rows = db_conn.query(f"SELECT * FROM {table}")
    last_updated = db_conn.query(f"SELECT MAX(updated_at) as ts FROM {table}")[0]["ts"]
...

신선도 메타데이터 (freshness metadata)를 모델에 전달하세요. 데이터가 오래되었을 경우(stale) 답변에 주의 사항을 포함하도록 지시하십시오.

실제로 작동하는 빌드 순서

Nu Terra Labs에서 AI 배포를 맡게 되면, 처음 2주는 거의 전적으로 데이터 인프라 (data infrastructure) 구축에 할애됩니다. 스키마 감사 (Schema audit), 정규화 파이프라인 (normalization pipeline), 신선도 모니터링 (freshness monitoring), 검증 세트 (validation sets) 등이 포함됩니다. 실제 에이전트 코드는 세 번째 단계에서 나옵니다.

대부분의 고객에게는 이 방식이 거꾸로 느껴질 것입니다. 그들은 데이터베이스 필드를 문서화하기 위해서가 아니라, AI를 구축하기 위해 우리를 고용했기 때문입니다. 하지만 이러한 순서 덕분에 우리가 구축한 것들이 6개월 차에도 1주 차와 마찬가지로 제대로 작동하는 것입니다.

데이터 레이어 (data layer)를 먼저 구축하십시오. 모델이 더 똑똑해질 필요는 없습니다. 더 나은 입력값 (inputs)이 필요할 뿐입니다.

만약 운영 환경 (production)에서 이 문제에 직면하여 전문가의 조언이 필요하다면, 언제든 DM을 보내주세요. 기꺼이 함께 파헤쳐 보겠습니다.