19% 느려졌는데, 20% 빨라졌다고 믿었다
AI 활용 성과에 대한 우리의 감각은 생각보다 훨씬 부정확하다.
2025년 연구기관 METR이 흥미로운 실험을 했다. 숙련된 오픈소스 개발자 16명에게 실제 업무 246건을 주고, AI 사용을 무작위로 허용·금지한 뒤 소요 시간을 측정한 것이다(RCT). 결과는 예상 밖이었다. AI를 쓴 쪽이 오히려 19% 느렸다. 더 놀라운 것은 참가자들의 인식이다. 실험 전에는 AI로 24% 빨라질 것이라 예측했고, 실험이 끝난 뒤에도 자신이 20% 빨라졌다고 믿었다. 실제 성과와 체감 사이에 약 40%p의 인식 격차(perception gap)가 있었던 셈이다.
이 연구는 2025년 초 시점의 도구를 대상으로 한 스냅샷이고, 이후 도구들이 빠르게 발전했다는 점은 감안해야 한다. 그럼에도 내가 이 결과를 오래 붙들고 있는 이유는 하나다. 숙련자조차 자기 AI 경험을 감(vibe)으로는 정확히 평가하지 못한다는 것. "요즘 AI 덕분에 일이 빨라진 것 같아"도, "AI가 요즘 멍청해진 것 같아"도, 측정 없이는 둘 다 믿을 수 없는 문장이다.
그래서 이 글은 감이 아니라 진단에 대한 글이다. AI가 실무에서 말썽을 부릴 때, tool을 갈아치우거나 prompt를 백 번 고치기 전에 — 고장이 어디에서 났는지부터 찾는 방법.
실패율 80%의 시대, 그런데 범인은 모델이 아니다
먼저 현실 파악. 2024–2025년에 나온 굵직한 조사들은 방향이 일치한다.
※ 95%라는 수치는 방법론에 대한 공개 논쟁이 있어 "정밀한 상수"가 아니라 "패턴의 증거"로 읽는 것이 안전하다. RAND의 80%도 "일부 추정에 따르면"이라는 단서가 붙어 있다.
흥미로운 것은 실패의 원인 분석이다. RAND가 경험 많은 데이터 과학자·엔지니어 65명을 인터뷰해 도출한 5대 근본 원인은 리더십의 문제 정의 실패, 데이터 품질, 기술 우선주의, 인프라 투자 부족, 그리고 기술 자체의 미성숙 — 이 순서다. 인터뷰이의 84%가 이 다섯 가지 중 하나 이상을 실패의 주원인으로 꼽았고, 그중에서도 리더십과 데이터 두 가지가 압도적이었다. 한 실무자의 표현이 인상적이다. "AI의 80%는 데이터 엔지니어링이라는 궂은일이다."
MIT 연구의 결론도 같은 곳을 가리킨다. 파일럿이 멈추는 이유는 모델 성능이 아니라, AI가 업무 흐름(workflow)에 통합되지 못하고 그로부터 학습하지 못하기 때문이라는 것. 정리하면 이렇다 — 모델의 지능은 대부분의 실패에서 병목이 아니다. 병목은 모델을 둘러싼 시스템, 즉 데이터·맥락·검색·실행·사람의 층위에 있다.
그렇다면 실무자에게 필요한 것은 "더 좋은 모델"이 아니라 고장 위치를 특정하는 지도다. 아래는 내가 실무에서 겪은 증상들을 바탕으로 정리한 5구역 진단 지도다. 각 구역은 증상(symptom)으로 들어가서, 근본 원인(root cause)과 실무자가 할 수 있는 진단 행동으로 나온다.
1입력 구역 — 재료가 오염됐다
내가 처음 밟은 지뢰가 정확히 이것이었다. 음성 회의를 STT(speech-to-text)로 받아 적은 회의록을 요약시키면 고유명사가 계속 엉뚱하게 나왔다. prompt에 "이름을 정확히 쓸 것"을 아무리 강조해도 개선되지 않았다. 당연했다. STT 단계에서 이미 이름이 깨진 채로 입력됐기 때문이다. 모델은 자기가 받은 재료 안에서만 일한다. 오염된 재료를 복원하라는 지시는, 존재하지 않는 정보를 만들어내라는 지시와 같다.
RAG 시스템의 실패 지점을 체계화한 2026년 ACL TrustNLP 연구는 파이프라인 7단계에 걸친 33개 실패 유형을 분류했는데, 그 첫 단계가 생성(generation)이 아니라 수집·변환 단계다 — 문서 layout parsing 오류, 음성·이미지 등 멀티모달 변환 손실, 오래된(stale) 데이터가 별도의 실패 유형으로 등재되어 있다. 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)라는 수집 단계의 설계 결정에 있다. 같은 조사에서 정비된(governed) 데이터 기반 검색 정확도는 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
BCG 컨설턴트 758명을 대상으로 한 Harvard 공동 실험(Dell'Acqua 외)은 "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에게 일을 맡길 때, 결과물의 합격 기준 3가지를 먼저 적는다. 기준을 적을 수 없다면, 그 일은 아직 맡길 준비가 안 된 것이다.
증상별 진단표 — tool을 바꾸기 전에
지금까지의 내용을 한 장으로 접는다. 다음에 "AI가 또 이상해"라는 말이 나오면, 이 표부터 연다.
| 증상 | 구역 | 첫 번째 진단 행동 |
|---|---|---|
| 고유명사·수치가 반복적으로 틀림 | 1 · 입력 | 원본 데이터를 직접 확인, 정정 glossary 제공 |
| 긴 작업에서 초반 규칙을 무시함 | 2 · 맥락 | 대화 리셋 + 핵심 규칙 재요약, 중요 지시는 처음/끝에 배치 |
| 같은 지시를 매번 반복하고 있음 | 2 · 맥락 | Memory·사용자 설정으로 규칙 이관 |
| 자료에 있는 내용을 "없다"고 함 | 3 · 검색 | 정보가 검색 가능한 형태로 존재하는지 확인, 문서 정비 |
| 그럴듯한 거짓을 자신 있게 말함 | 4 · 추론 | 출처 표기 의무화 등 검증 비용을 낮추는 규칙 도입 |
| 비슷해 보이는 과제인데 품질이 널뜀 | 4 · 추론 | Jagged frontier 의심 — 과제별로 검증 강도 차등화 |
| 다단계 작업이 중간에 무너짐 | 5 · 실행 | 단계 분해 + human in the loop 관문 설계 |
| 사용량·비용이 예측을 초과함 | 5 · 실행 | 비용 상한·관측 체계 확보 전 확장 중단 |
| 열심히 쓰는데 성과를 모르겠음 | 공통 | 합격 기준 3가지를 먼저 적기 — 감이 아니라 evals |
이 지도를 쓰면서 내게 생긴 가장 큰 변화는, "AI가 이상해"라는 문장을 더 이상 결론으로 쓰지 않게 됐다는 것이다. 그것은 이제 질문의 시작이다 — 어느 구역이지?