19% 느려졌는데, 20% 빨라졌다고 믿었다
AI를 써서 얼마나 나아졌는지에 대한 우리의 감각은 생각보다 훨씬 부정확합니다.
2025년 연구기관 METR이 실험을 하나 했습니다. 숙련된 오픈소스 개발자 16명에게 실제 업무 246건을 주고, 과제마다 AI 사용을 무작위로 허용하거나 금지한 뒤 소요 시간을 쟀습니다. 무작위 대조 실험(RCT)입니다. 결과는 예상 밖이었습니다. AI를 쓴 쪽이 오히려 19% 느렸습니다. 더 놀라운 것은 참가자들의 인식입니다. 실험 전에는 AI로 24% 빨라질 것이라 예측했고, 실험이 끝난 뒤에도 자신이 20% 빨라졌다고 믿었습니다. 실제 성과와 체감 사이에 약 40%p의 인식 격차(perception gap)가 있었던 셈입니다.
이 연구는 2025년 초 시점의 도구를 대상으로 한 스냅샷이고 이후 도구가 빠르게 발전했다는 점은 감안해야 합니다. 저자들 스스로도 이것이 초기 시점의 관찰임을 뒤에 명시했습니다. 그럼에도 필자가 이 결과를 오래 붙들고 있는 이유는 하나입니다. 숙련자조차 자기 AI 경험을 감으로는 정확히 평가하지 못한다는 것입니다. "요즘 AI 덕분에 일이 빨라진 것 같아"도, "AI가 요즘 멍청해진 것 같아"도, 측정 없이는 둘 다 믿을 수 없는 문장입니다.
그래서 이 글은 감이 아니라 진단에 관한 글입니다. AI가 실무에서 말썽을 부릴 때, tool을 갈아치우거나 prompt를 백 번 고치기 전에 고장이 어디에서 났는지부터 찾는 방법을 정리합니다.
실패율 80%의 시대, 그런데 범인은 모델이 아니다
2024–2025년에 나온 굵직한 조사들은 방향이 일치합니다.
※ 95%라는 수치는 방법론을 둘러싼 공개 논쟁이 있습니다. 정밀한 상수보다는 패턴의 증거로 읽는 편이 안전합니다. RAND의 80%에도 "일부 추정에 따르면"이라는 단서가 붙어 있습니다.
눈여겨볼 것은 실패의 원인 분석입니다. RAND가 경험 많은 데이터 과학자·엔지니어 65명을 인터뷰해 도출한 5대 근본 원인은 리더십의 문제 정의 실패, 데이터 품질, 기술 우선주의, 인프라 투자 부족, 그리고 기술 자체의 미성숙 순이었습니다. 인터뷰이의 84%가 이 다섯 가지 가운데 하나 이상을 실패의 주원인으로 꼽았고, 그중에서도 리더십과 데이터 두 가지가 압도적이었습니다. 한 실무자의 표현이 인상적입니다. "AI의 80%는 데이터 엔지니어링이라는 궂은일이다."
MIT 연구의 결론도 같은 곳을 가리킵니다. 파일럿이 멈추는 이유는 모델 성능이 아니라 AI가 업무 흐름(workflow)에 통합되지 못하고 그로부터 학습하지도 못하기 때문이라는 것입니다. 정리하면 이렇습니다. 모델의 지능은 대부분의 실패에서 병목이 아닙니다. 병목은 모델을 둘러싼 시스템, 즉 데이터·맥락·검색·실행·사람의 층위에 있습니다.
그렇다면 실무자에게 필요한 것은 "더 좋은 모델"이 아니라 고장 위치를 특정하는 지도입니다. 아래는 필자가 실무에서 겪은 증상들을 바탕으로 정리한 5구역 진단 지도입니다. 각 구역은 증상으로 들어가 근본 원인과 실무자가 할 수 있는 진단 행동으로 나옵니다.
1입력 구역 — 재료가 오염됐다
필자가 처음 밟은 지뢰가 정확히 이것이었습니다. 음성 회의를 STT(speech-to-text)로 받아 적은 회의록을 요약시키면 고유명사가 계속 엉뚱하게 나왔습니다. prompt에 "이름을 정확히 쓸 것"을 아무리 강조해도 나아지지 않았습니다. 당연한 결과였습니다. STT 단계에서 이미 이름이 깨진 채로 입력됐기 때문입니다. 모델은 자기가 받은 재료 안에서만 일합니다. 오염된 재료를 복원하라는 지시는 존재하지 않는 정보를 만들어내라는 지시와 같습니다.
2026년 ACL TrustNLP 연구는 RAG 시스템의 실패 지점을 체계화해 파이프라인 7단계에 걸친 33개 실패 유형을 분류했습니다. 그 첫 단계는 생성(generation)이 아니라 수집·변환 단계입니다. 문서 layout parsing 오류, 음성·이미지 등 멀티모달 변환 손실, 오래된 데이터가 각각 별도의 실패 유형으로 등재돼 있습니다. RAND의 "AI의 80%는 데이터 엔지니어링"이라는 증언과 정확히 같은 층위입니다.
출력이 이상하면 출력을 다듬기 전에 입력을 열어봅니다. 원본 transcript, 원본 문서, 원본 데이터를 직접 눈으로 확인하는 것이 첫 진단입니다. 필자의 경우 자주 깨지는 고유명사의 정정 사전(glossary)을 만들어 입력과 함께 넣어주는 것만으로 문제가 사라졌습니다. 화려한 해법은 없었습니다. 재료를 손질했을 뿐입니다.
2맥락 구역 — 기억이 무너졌다
긴 작업에서 가장 흔한 고장입니다. 모델이 멍청해진 것이 아니라 구조적으로 예측 가능한 현상이라는 것이 최근 연구들의 결론입니다.
중간에 묻힌 정보, 정확도 30%+ 하락
Stanford의 "Lost in the Middle" 연구(TACL 2024)는 핵심 정보가 입력의 처음이나 끝에 있을 때 정확도가 가장 높고 가운데에 묻히면 30% 이상 떨어지는 U자 곡선을 6개 모델 계열에서 재현했습니다. 원인은 attention 구조와 위치 인코딩, 곧 아키텍처 자체입니다. 버그가 아닙니다.
2025년 Chroma의 "Context Rot" 보고서는 18개 최신 모델을 테스트해, 입력이 길어질수록 단순 검색·복사 과제에서조차 신뢰도가 떨어지고 그 저하가 context window가 가득 차기 훨씬 전부터 시작된다는 것을 보였습니다. 스펙상 200K token 모델도 실제로는 그보다 훨씬 좁은 구간에서만 안정적이라는 것이 실무 보고들의 공통된 관찰입니다.
"context window가 크니까 다 넣어도 된다"는 착각이 이 구역의 주범입니다. 실무에서는 네 가지 오염 패턴이 정리돼 있습니다. 잘못된 정보가 맥락에 들어와 계속 참조되는 context poisoning, 맥락이 너무 길어져 모델이 이력에만 매달리는 context distraction, 무관한 내용이나 과다한 tool이 판단을 흐리는 context confusion, 새 정보가 기존 맥락과 충돌하는 context clash입니다.
여기에 세션을 넘나드는 기억(memory) 기능이 2025년 주요 AI 제품에 일제히 탑재되면서 변수가 하나 더 생겼습니다. 편리하지만 기억이 쌓일수록 무관한 맥락이 새어 들어오거나 과거 대화에 영합하는 부작용도 함께 보고되고 있습니다. 기억은 저장의 문제가 아니라 구조화의 문제입니다.
긴 대화에서 품질이 떨어지면 prompt를 고치지 말고 맥락을 리셋합니다. 새 대화를 열고 살아남아야 할 규칙과 상태만 요약해 맨 앞에 다시 놓습니다. 중요한 지시는 입력의 처음이나 끝에 배치합니다. 앞의 U자 곡선을 실전에 그대로 옮긴 배치입니다. 매번 반복하는 지시는 대화에 두지 말고 memory나 사용자 설정으로 넘깁니다. 필자는 문서 양식과 표기 규칙 같은 반복 지시를 이관한 뒤로 대화의 시작점 자체가 달라졌습니다.
3검색 구역 — 못 찾았다
사내 문서나 knowledge base를 연결해 쓰는 경우(RAG, Retrieval-Augmented Generation)의 대표적인 고장입니다. 이때 대부분은 "모델이 이해를 못 하네"라고 결론을 내리지만, 데이터가 가리키는 방향은 반대입니다.
RAG 실패의 약 73%는 생성이 아니라 검색 단계에서 발생
기업 RAG 프로젝트를 분석한 업계 조사에 따르면, 심각한 실패의 다수는 LLM의 답변 생성이 아니라 retrieval 단계에서 비롯되고 그 뿌리는 대개 문서를 어떻게 잘랐는지(chunking)라는 수집 단계의 설계 결정에 있습니다. 같은 조사에서 정비된 데이터를 쓴 검색 정확도는 85–92%, 방치된 데이터에서는 45–60% 수준으로 갈렸습니다. 다만 벤더 쪽에서 낸 업계 조사이므로 정밀한 수치보다는 방향성 지표로 읽는 편이 안전합니다. 기초 연구인 Barnett 외(2024)의 "RAG의 7가지 실패 지점"도 missing content, 상위 랭킹 누락, 맥락 통합 실패처럼 검색·수집 쪽 문제를 앞세웁니다.
비유하면 이렇습니다. 사서(retriever)가 엉뚱한 책을 뽑아다 줬는데, 우리는 그 책을 읽고 답한 연구원(model)을 탓합니다.
"자료에 있는데 못 찾는다"는 증상이 나오면 모델을 탓하기 전에 두 가지를 봅니다. 첫째, 그 정보가 실제로 검색 대상 문서에, 검색 가능한 형태로 존재하는지 봅니다. 스캔 이미지 속의 표, 깨진 인코딩, 오래된 버전은 존재로 치지 않습니다. 둘째, 문서 정리 상태를 봅니다. 중복·구버전·초안이 뒤섞인 폴더를 통째로 연결하면 검색 품질은 딱 그 수준을 따라갑니다. 데이터 정비는 검색 품질을 움직이는 지렛대입니다. IT 부서만의 일이 아닙니다.
4추론 구역 — 모델의 본성이다
앞의 세 구역을 다 통과하고도 남는 고장이 있습니다. 바로 hallucination입니다. 2025년 OpenAI의 연구("Why Language Models Hallucinate")는 이것이 왜 사라지지 않는지에 대해 불편할 만큼 명쾌한 설명을 내놨습니다. 지금의 학습·평가 방식이 "모른다"고 말하는 것보다 그럴듯하게 추측하는 쪽에 보상을 주기 때문입니다. 대부분의 벤치마크에서 공란보다 오답이 점수상 유리합니다. 모델은 좋은 수험생이 되도록 최적화됐고, 좋은 수험생은 모르는 문제도 찍습니다.
이 설명은 실무의 대응을 바꿉니다. hallucination은 다음 모델이 나오면 해결될 버그가 아니라 설계상의 성질에 가깝습니다. 따라서 대응도 모델 교체가 아니라 검증 체계의 문제가 됩니다.
경계 안 품질 +40%, 경계 밖 오답률 +19%p
Dell'Acqua 외의 Harvard 공동 실험은 BCG 컨설턴트 758명을 대상으로 삼아 "jagged frontier(들쭉날쭉한 경계)"라는 개념을 남겼습니다. AI 능력 범위 안쪽의 과제에서 AI 사용 그룹은 25.1% 빠르게, 약 40% 높은 품질로 일했고 특히 하위 성과자의 향상 폭(+43%)이 컸습니다. 그러나 겉보기에는 비슷해 보이는 능력 범위 바깥의 과제에서는 AI 사용 그룹의 오답률이 오히려 19%p 높았습니다. 문제는 그 경계가 직선이 아니라 들쭉날쭉해서 지금 맡으려는 과제가 경계 안인지 밖인지 미리 알기 어렵다는 데 있습니다.
이 구역의 진단 질문은 "모델이 왜 틀렸지?"가 아니라 "이 과제는 경계 안인가 밖인가, 그리고 검증 비용은 얼마인가"입니다. 검증이 싼 과제(초안 작성, 형식 변환)는 과감하게 맡기고, 검증이 비싸거나 경계 밖으로 의심되는 과제(수치 계산, 최신 사실, 법적 판단)에는 사람이 확인하는 지점을 반드시 박아 둡니다. 필자는 보고용 문서에서 "숫자에는 반드시 출처를 함께 표기"를 규칙으로 못 박았는데, 이것은 모델을 믿지 않아서가 아니라 검증을 싸게 만들기 위해서입니다.
5실행 구역 — 실행이 무너졌다
2025–2026년의 화두인 agent, 즉 스스로 판단하고 여러 단계를 실행하는 AI는 새로운 종류의 고장을 데려왔습니다. 단계가 이어질수록 오류가 복리로 불어난다는 것입니다.
조율 없는 multi-agent, 오류 최대 17.2배 증폭
UC Berkeley의 MAST 연구(NeurIPS 2025)는 7개 framework에서 1,600건 이상의 실행 기록을 분석해 agent 실패를 14개 유형으로 분류했습니다. 핵심 발견은 두 가지입니다. 첫째, 조율 장치가 없는 multi-agent 시스템은 단일 agent 대비 오류를 최대 17.2배까지 증폭시켰고 검증 관문을 둔 중앙집중형 구조는 이를 약 4.4배로 억제했습니다. 둘째, 연구진의 결론입니다. "기반 모델의 성능 향상만으로는 이 실패 유형들을 해결할 수 없다." 문제는 지능이 아니라 구조라는 뜻입니다.
비용도 같은 구역의 문제입니다. Anthropic의 공개 자료에 따르면 agent는 일반 채팅 대비 약 4배, multi-agent 시스템은 약 15배의 token을 씁니다. token 단가는 1년 새 크게 떨어졌지만(업계 추산 약 -67%), FinOps Foundation의 2026년 조사에서는 조직의 73%가 AI 비용이 당초 예상을 넘었다고 답했습니다. token은 싸졌는데 청구서는 커졌습니다. 사용량이 그만큼 폭증했기 때문입니다.
실무자 입장에서는 반가운 소식인데, 이 구역의 해법은 코딩 기술이 아니라 프로세스 설계 감각입니다. 단계를 어떻게 쪼갤지, 어디에 검증 관문을 둘지, 사람이 어느 시점에 승인할지(human in the loop). 이것은 우리가 결재선과 리뷰 프로세스를 설계할 때 매일 쓰는 근육입니다.
필자는 주간 리포트 자동화를 "한 번에 끝까지"로 시켰다가 실패한 뒤, 데이터 검증 → 초안 → 검토 → 최종안으로 쪼개고 단계 사이에 필자의 확인을 끼워 넣는 방식으로 바꿨습니다. 실패율이 눈에 띄게 줄었습니다. 하나 더 덧붙이면, agent 작업의 비용 상한과 사용량 관측이 불가능하다면 아직 확장할 때가 아닙니다. Gartner의 40% 취소 전망은 대부분 이 지점에서 현실이 됩니다.
Prompt를 고치는 사람에서, 맥락을 설계하는 사람으로
다섯 구역을 관통하는 2025년의 흐름 전환이 하나 있습니다. 업계의 관심이 prompt engineering에서 context engineering으로 옮겨갔습니다. 후자는 "추론 시점에 모델에게 주어지는 token 집합 전체를 최적으로 선별·유지하는 일"로 정의됩니다. 문장을 다듬는 일이 아니라 어떤 데이터가, 어떤 순서로, 어떤 형태로 모델 앞에 놓이는지를 설계하는 일입니다.
둘을 가르는 기준이 마음에 들어 옮겨 둡니다. 명사와 형용사를 바꾸고 있다면 아직 prompt engineering이고, 모델이 무엇을 참조할지와 어떤 순서로 볼지를 바꾸고 있다면 context engineering입니다. 이 글의 1~3구역이 사실상 전부 context engineering의 영역이라는 점을 눈치채셨을 것입니다. 그리고 이 일에는 코딩보다 정보 설계와 우선순위 판단이 필요합니다. 코드를 쓰지 않는 실무자도 충분히 잘할 수 있는 일입니다.
마지막 조각은 측정입니다. 서두의 METR 실험이 보여줬듯 감으로는 AI 성과를 평가할 수 없습니다. 그래서 AI 제품 업계에서는 출력의 합격·불합격 기준을 명시적으로 정의하고 실제 실패 사례를 분석하는 문화, 즉 evals가 실무자의 핵심 기술로 떠올랐고 "evals는 새로운 요구사항 정의서"라는 말까지 나왔습니다. 거창한 도구가 없어도 시작할 수 있습니다. 필자가 쓰는 최소 버전은 이것입니다. AI에게 일을 맡길 때, 결과물의 합격 기준 세 가지를 먼저 적습니다. 기준을 적을 수 없다면 그 일은 아직 맡길 준비가 안 됐습니다.
증상별 진단표 — tool을 바꾸기 전에
지금까지의 내용을 한 장으로 접어 두겠습니다. 다음에 "AI가 또 이상해"라는 말이 나오면 이 표부터 열어 보시기 바랍니다.
| 증상 | 구역 | 첫 번째 진단 행동 |
|---|---|---|
| 고유명사·수치가 반복적으로 틀림 | 1 · 입력 | 원본 데이터를 직접 확인, 정정 glossary 제공 |
| 긴 작업에서 초반 규칙을 무시함 | 2 · 맥락 | 대화 리셋 + 핵심 규칙 재요약, 중요 지시는 처음/끝에 배치 |
| 같은 지시를 매번 반복하고 있음 | 2 · 맥락 | Memory·사용자 설정으로 규칙 이관 |
| 자료에 있는 내용을 "없다"고 함 | 3 · 검색 | 정보가 검색 가능한 형태로 존재하는지 확인, 문서 정비 |
| 그럴듯한 거짓을 자신 있게 말함 | 4 · 추론 | 출처 표기 의무화 등 검증 비용을 낮추는 규칙 도입 |
| 비슷해 보이는 과제인데 품질이 널뜀 | 4 · 추론 | Jagged frontier 의심 — 과제별로 검증 강도 차등화 |
| 다단계 작업이 중간에 무너짐 | 5 · 실행 | 단계 분해 + human in the loop 관문 설계 |
| 사용량·비용이 예측을 초과함 | 5 · 실행 | 비용 상한·관측 체계 확보 전 확장 중단 |
| 열심히 쓰는데 성과를 모르겠음 | 공통 | 합격 기준 3가지를 먼저 적기 — 감이 아니라 evals |
이 지도를 쓰면서 필자에게 생긴 가장 큰 변화는 "AI가 이상해"라는 문장을 더 이상 결론으로 쓰지 않게 됐다는 것입니다. 그 말은 이제 질문의 시작입니다. 어느 구역이지?