AI 에이전트 정확도가 안 나오는 진짜 이유: 모델보다 먼저 볼 6가지

AI 에이전트가 자꾸 틀리면 대부분 모델부터 바꿉니다. 더 비싼 모델을 붙이고, 검색 문서를 늘리고, 도구도 하나씩 추가하죠.

그런데 막상 운영해 보면 이상합니다. 비용은 올라갔는데 답은 여전히 흔들립니다. 어떤 날은 맞고, 같은 질문을 다시 하면 엉뚱한 테이블을 고릅니다.

OpenAI가 공개한 내부 데이터 에이전트 사례에서 제가 가장 눈여겨본 부분도 여기에 있습니다. 2026년 1월 공개 기준으로 600PB가 넘는 데이터와 7만 개 데이터셋을 다루면서도, 복잡한 멀티 에이전트를 앞세우지 않았습니다.

 

오히려 반대였습니다.

모델을 더 복잡하게 만들기 전에, 모델이 헷갈리지 않도록 데이터의 의미와 신뢰도, 권한, 검증 경로부터 정리했습니다.

2026년 6월 공개된 Emma Tang 인터뷰 기반 후속 사례에서는 규모가 1.5EB·9만 데이터셋으로 커지고 모델도 GPT-5.5로 바뀌었습니다. 숫자와 모델은 달라졌지만, 설계 방향은 같았습니다.

 

AI 에이전트 오답은 모델이 멍청해서가 아니라, 모델이 봐야 할 정보가 빠졌거나 서로 충돌해서 생기는 경우가 많습니다.

 

복잡한 모델과 도구를 늘린 AI 에이전트와 컨텍스트를 정리한 단순한 AI 에이전트 비교

 

 

 

 

SQL을 잘 짠다고 답까지 맞는 것은 아닙니다

예를 들어 “지난달 활성 사용자는 몇 명인가?”라고 물었다고 해보겠습니다.

질문은 간단합니다. 하지만 데이터를 조금만 들여다보면 바로 갈립니다.

• 로그인 사용자만 볼 것인가
• 로그아웃 사용자도 포함할 것인가
• 내부 테스트 계정은 뺄 것인가
• ‘지난달’을 달력 기준으로 볼 것인가, 최근 28일로 볼 것인가

 

두 테이블에 똑같이 user_id가 있어도 실제 의미는 다를 수 있습니다. 하나는 로그아웃 사용자를 포함하고, 다른 하나는 제외할 수 있습니다. 컬럼 이름만 봐서는 이 차이를 알 수 없습니다.

여기서 모델 성능을 올려도 해결되지 않습니다. 모델은 주어진 정보 안에서 추론할 뿐, 문서에도 코드에도 없는 업무 기준을 알아서 복원해 주지 않습니다.

오히려 더 좋은 모델일수록 그럴듯한 설명까지 붙여 틀릴 수 있습니다.

 

 

 

OpenAI 사례에서 봐야 할 6개 컨텍스트

이 사례를 단순히 “OpenAI는 이렇게 만들었다”로 보면 실무에 남는 게 많지 않습니다. 중요한 건 각각의 컨텍스트가 어떤 오답을 막았는지입니다.

 

컨텍스트	없으면 생기는 문제	작은 팀이 먼저 준비할 것
테이블 사용 정보	엉뚱한 테이블과 조인을 선택함	스키마, 데이터 계보, 검증된 대표 쿼리
사람 주석	지표의 업무 의미를 잘못 해석함	소유자, 정의, 제외 조건, 주의사항
코드 기반 설명	실제 변환 로직과 필터를 놓침	파이프라인 코드, 갱신 주기, 데이터 범위
조직 지식	장애·출시·내부 용어의 맥락을 놓침	공식 문서, 용어집, 장애 기록
메모리	이미 고친 실수를 계속 반복함	승인된 교정과 예외 규칙
런타임 확인	오래된 문서를 현재 정보로 착각함	실시간 스키마·샘플·최신성 검사

 

질문에서 6개 컨텍스트 검색과 도구 실행 평가 권한 검사를 거쳐 답을 만드는 AI 에이전트 흐름도

 

 

 

 

스키마보다 코드를 먼저 봐야 하는 이유

스키마는 데이터의 모양을 알려줍니다. 어떤 컬럼이 있고 타입이 무엇인지는 확인할 수 있죠.

하지만 정작 실무에서 중요한 내용은 빠져 있는 경우가 많습니다.

• 왜 특정 값이 제외됐는지
• 어떤 이벤트에서 데이터가 만들어졌는지
• 언제 갱신되는지
• 지금도 써야 하는 테이블인지

 

이 정보는 대개 파이프라인 코드와 변환 로직에 남아 있습니다.

OpenAI가 Codex로 테이블 생성 코드를 읽고 목적·데이터 단위·최신성·대체 테이블 설명을 보강한 이유도 같습니다.

사내 AI가 비슷한 테이블을 계속 혼동한다면 문서를 더 넣기 전에 먼저 확인해야 합니다. 이 결과물을 실제로 만든 코드와 규칙이 연결돼 있는가?

이 연결이 없으면 설명 문서가 많아도 실제 데이터와 조금씩 어긋나기 시작합니다.

 

 

 

도구가 많을수록 똑똑해진다는 착각

에이전트에 도구를 붙이는 일은 꽤 재미있습니다. 검색도 넣고, SQL 실행도 넣고, 문서 조회와 대시보드 호출까지 붙이면 금방 그럴듯해집니다.

문제는 비슷한 일을 하는 도구가 겹치는 순간부터입니다.

Emma Tang 인터뷰에 따르면 팀은 처음 약 40개 도구를 연결했습니다. 이후 모델이 엉뚱한 도구를 고르거나, 비슷한 도구에서 서로 다른 답을 가져오는 문제가 생겼고 호출당 약 13개 수준으로 정리했습니다.

여기서 “13개가 정답”이라고 받아들이면 곤란합니다. 숫자보다 중요한 건 역할이 겹치지 않는다는 점입니다.

제가 이 사례에서 실무적으로 가져갈 원칙은 네 가지입니다.

1. 같은 목적의 도구는 대표 도구 하나만 남깁니다.
2. 이름과 설명만 읽어도 언제 써야 하는지 구분돼야 합니다.
3. 실패 결과는 모델이 다시 판단할 수 있도록 구조화합니다.
4. 권한이 없는 데이터는 답변 단계가 아니라 도구 단계에서 막습니다.

 

반복 업무를 별도 워크플로로 묶는 방법은 AI Agent Skill과 재사용 워크플로 설계에서도 이어집니다. 긴 프롬프트 하나에 모든 지침을 몰아넣는 것보다, 필요한 규칙만 그때그때 불러오는 쪽이 관리하기도 쉽습니다.

 

중복된 AI 에이전트 도구와 역할이 분명한 최소 도구 세트의 선택 오류 비교

 

 

 

RAG는 문서를 많이 넣는다고 좋아지지 않습니다

RAG를 처음 만들 때 가장 흔한 접근은 “일단 전부 임베딩하자”입니다.

빠르게 시작하기에는 좋습니다. 다만 오래된 문서, 실험용 쿼리, 한 번 쓰고 버린 분석까지 같은 무게로 검색되기 시작하면 문제가 달라집니다. 에이전트는 근거를 많이 찾은 게 아니라, 오래된 오답 후보를 많이 찾은 상태가 됩니다.

OpenAI 팀도 과거 SQL 쿼리를 전부 예시로 넣는 방식을 시도했지만 잘 작동하지 않았다고 설명합니다. 실제 대시보드에서 반복 사용되는 검증된 쿼리는 높게, 일회성 탐색 쿼리는 낮게 두는 식으로 신뢰도를 나눈 뒤 품질이 나아졌습니다.

검색 대상에는 적어도 아래 정보가 붙어 있어야 합니다.

• 누가 관리하는가
• 마지막으로 언제 검증했는가
• 실제 운영에 쓰이는가
• 이미 대체되거나 폐기된 자료인가
• 누가 접근할 수 있는가

 

RAG의 기본 검색 구조를 이미 만들었는데도 답이 흔들린다면, 임베딩 모델부터 바꾸지 않아도 됩니다. 먼저 검색 결과 상위에 오래된 문서가 왜 올라오는지, 폐기된 자료가 아직 남아 있는지부터 보는 편이 빠릅니다.

 

 

 

데모와 운영의 차이는 평가·권한·검산에서 벌어집니다

데모에서는 한 번 잘 맞으면 꽤 그럴듯해 보입니다. 운영은 다릅니다.

데이터가 바뀌고, 프롬프트가 수정되고, 모델 버전이 올라가면 어제 맞던 질문이 오늘 틀릴 수 있습니다. 그래서 “지금 잘 되느냐”보다 “무엇이 바뀌었을 때 품질이 깨졌는지 잡을 수 있느냐”가 더 중요합니다.

OpenAI는 주요 자연어 질문과 사람이 작성한 정답 SQL을 짝지어 평가 세트를 만들었습니다. 생성된 SQL 문장만 비교한 게 아니라 실제 실행 결과까지 확인했습니다.

이 방식이 중요한 이유는 간단합니다. SQL 문장은 달라도 같은 결과가 나올 수 있고, 반대로 그럴듯한 SQL이 완전히 다른 결과를 만들 수도 있기 때문입니다.

 

권한도 빼놓을 수 없습니다.

에이전트가 관리자 권한으로 모든 자료를 검색한 뒤 마지막 답변에서만 걸러내는 구조라면 이미 늦습니다. 검색과 도구 호출 단계부터 기존 사용자의 권한을 그대로 따라야 합니다.

공식 사례에서도 사용자가 원래 볼 수 없는 테이블은 에이전트 역시 조회하지 못하게 했습니다. 답변에는 가정, 실행 과정, 원본 결과를 함께 보여줘 사람이 다시 확인할 수 있게 했고요.

평가 세트를 어디서부터 만들지 막힌다면 AI Evals 실전 평가 설계법의 task → eval data → grader 구조부터 적용해 보면 됩니다. 처음부터 수백 개를 만들 필요는 없습니다.

 

 

 

답이 이상할 때 모델부터 바꾸지 마세요

아래 표는 운영 중 자주 보이는 증상과 먼저 확인할 지점을 정리한 것입니다.

 

증상	가능성이 큰 원인	먼저 할 일
같은 질문인데 선택하는 테이블이 자주 바뀜	의미 설명·소유자 부재	기준 테이블과 제외 조건 문서화
도구 호출 순서가 매번 달라짐	기능이 겹치는 도구가 너무 많음	목적별 대표 도구 하나로 통합
오래된 내용을 자신 있게 답함	최신성 정보·런타임 확인 부재	갱신일과 실시간 검증 단계 추가
한번 고친 오류를 다시 반복함	승인된 메모리 없음	교정 저장·편집·폐기 절차 마련
배포 후 갑자기 품질이 떨어짐	회귀 평가 부재	골든 질문·정답 결과 세트 운영
권한 밖 정보가 답에 섞임	검색과 도구 권한 분리 실패	기존 사용자 권한 그대로 상속

 

이 표에서 중요한 건 한 가지입니다. 같은 오답처럼 보여도 원인은 전혀 다를 수 있다는 점입니다.

모델을 바꾸면 잠깐 좋아 보일 수는 있습니다. 하지만 원인이 데이터 정의나 권한 구조라면 다시 같은 문제가 생깁니다.

 

 

 

이런 상태라면 에이전트부터 만들지 않는 편이 낫습니다

아래 세 가지 중 두 개 이상에 해당한다면, 모델 연결보다 기반 정리가 먼저입니다.

• 같은 지표를 팀마다 다르게 계산합니다.
• 데이터와 문서의 소유자가 정해져 있지 않습니다.
• 누가 어떤 자료를 볼 수 있는지 정리돼 있지 않습니다.

이 상태에서 에이전트를 붙이면 혼란이 해결되지 않습니다. 잘못된 답이 더 빠르고 더 자연스러운 문장으로 퍼질 뿐입니다.

AI가 조직의 데이터 문제를 해결해 주는 게 아니라, 이미 있는 데이터 문제를 확대해 보여주는 셈입니다.

 

 

 

작은 팀이라면 질문 20~50개로 시작해도 충분합니다

OpenAI처럼 수만 개 데이터셋을 갖고 있지 않아도 원칙은 그대로 적용할 수 있습니다. 다만 처음부터 전사 데이터를 연결할 이유는 없습니다.

작게 시작하는 편이 훨씬 낫습니다.

1. 실제로 자주 반복되는 질문 20~50개를 고릅니다.
2. 질문마다 기준 데이터와 정답 계산법을 정합니다.
3. 소유자·최신성·제외 조건을 붙입니다.
4. 역할이 겹치는 도구는 하나로 합칩니다.
5. 검증된 문서와 쿼리만 검색 우선순위에 올립니다.
6. 정답 결과를 기준으로 반복 평가합니다.
7. 기존 사용자 권한을 그대로 적용하고, 답의 근거를 함께 보여줍니다.

 

이 정도만 해도 “모델이 왜 틀렸는지 모르겠다”는 상태에서는 상당히 벗어날 수 있습니다.

 

 

 

결국 모델 밖에서 품질이 갈립니다

OpenAI 사례에서 정말 볼 것은 GPT 버전도, 도구가 13개라는 숫자도 아닙니다.

시간이 지나면서 모델과 데이터 규모는 바뀌었습니다. 그런데 품질을 만드는 순서는 크게 달라지지 않았습니다.

정리된 데이터 기반 → 신뢰할 수 있는 컨텍스트 → 역할이 겹치지 않는 도구 → 반복 평가 → 권한과 검산 가능성

AI 에이전트가 틀릴 때 바로 모델부터 바꾸고 있다면, 한 번은 순서를 뒤집어 볼 필요가 있습니다.

모델이 무엇을 봤는지, 그 정보는 최신이었는지, 서로 충돌하지 않았는지, 어떤 도구를 왜 골랐는지부터 확인해 보세요.

생각보다 많은 문제는 모델 안이 아니라 모델 밖에 있습니다.