AI 학습법과 환각 줄이기: RAG·에이전트·평가(eval)에 대한 현장 엔지니어의 조언

핵심 메시지

• AI의 환각(hallucination)은 모델 내부만의 문제가 아니라, 사람이 문제를 얼마나 잘 정의하고 어떤 맥락을 주느냐에 크게 좌우된다.
• 거액을 투자하고도 95%의 조직이 성과를 못 내는 이유는 '평가(eval)'를 소홀히 하기 때문이다. 시스템 설계가 30%라면 평가가 70%다.
• 'RAG는 죽었다', '소프트웨어 공학은 끝났다' 같은 자극적 주장은 시스템을 제대로 만들 줄 모르는 사람들의 말이며, 학생은 기본기에 집중해야 한다.
• AI가 일자리를 빼앗기보다, 자신이 이미 가진 도메인 지식과 비즈니스 이해를 AI 솔루션으로 전환하는 사람이 시장에서 앞서간다.

쉽게 이해하기

이 영상은 가우라브 센과 IIT 마드라스 출신 엔지니어 타니시가 진행하는 즉석 팟캐스트로, 스탠퍼드·하버드·MIT 등의 설문 결과를 한 줄 질문으로 압축해 현직 엔지니어의 시각에서 해석한다. 첫 화두는 '개발자 10명 중 7명이 매일 쓰는 AI 도구의 결과를 신뢰하지 않는다'는 조사다. 타니시는 환각을 줄이는 출발점으로 '문제 정의'를 꼽으며, AI에게도 문제 진술·사용할 도구·성공 기준을 명확히 적어줘야 한다고 설명한다.

그는 RAG 시스템을 예로 든다. 막연히 시키면 AI가 벡터 DB나 청킹 기법을 임의로 고르지만, 문서 구조를 아는 도메인 전문가가 제약 조건을 잘 정의하면 훨씬 나은 결과가 나온다. 환각은 모델 문제이자 사람(맥락) 문제이기도 하다는 결론이다.

두 번째 주제는 'Gen AI에 수십억 달러를 투자하고도 95%의 조직이 수익을 못 낸다'는 MIT 조사다. 두 사람은 '소진한 토큰 수'나 '코드 줄 수'가 좋은 엔지니어의 척도가 아니듯 단순히 AI를 끼워 넣는다고 문제가 풀리지 않는다고 본다. 상위 5%의 비결로는 끝에서 끝까지의 이해, 문제와 해법의 범위(scope) 정의, 그리고 무엇보다 '평가'를 든다.

이때 평가는 출력만 보는 것이 아니다. 항공권 예약 에이전트라면 날짜·선호 같은 누락 정보를 먼저 되묻고 올바른 순서로 도구를 호출했는지를 봐야 한다. 출력만 보고 바로 예약했다면 그것이 곧 95%에 머무는 신호다. 이런 추적(trace) 점검은 QA가 아니라 파이프라인을 만든 엔지니어 본인의 몫이며, 도메인 전문가(예: 간호사)와 함께 프롬프트를 검증·작성해야 한다고 강조한다.

세 번째로 'LLM을 심판(LLM as a judge)으로 쓰는' 방식의 함정을 다룬다. 흔한 실수는 하나의 프롬프트로 답변 관련성·근거성·완결성 같은 여러 지표를 한꺼번에 평가하게 하는 것이다. 발표자들은 '지표 하나당 심판 하나'를 원칙으로 제시하고, 심판에게는 질의·모델에 전달된 맥락·출력을 모두 줘야 제대로 평가할 수 있다고 말한다.

마지막으로 자동화의 한계와 학습 경로를 다룬다. AI가 업무의 약 60%에 쓰이지만 완전 자동화가 가능한 일은 20%에 그친다는 앤트로픽 내부 연구를 인용하며, 그 이유를 고위험/저위험 구분으로 설명한다. 사람은 사라지는 게 아니라 '루프의 더 뒤쪽'으로 이동한다는 것이다. 또 'RAG·DSA가 죽었다'는 공포에 대해 기술은 죽는 게 아니라 추상화될 뿐이라며, 행렬 곱셈 수준의 기초 위에서 트랜스포머→RAG→에이전트→멀티 에이전트→평가 순으로 쌓아갈 것을 권한다.

주요 인사이트

• 환각을 줄이는 가장 현실적인 방법은 모델을 바꾸는 것이 아니라, 문제 진술·필요한 맥락·성공 기준을 좁고 명확하게 정의하는 것이다.
• '평가가 70%'라는 말처럼, 시스템을 먼저 만들고 나중에 평가하는 게 아니라 무엇을·왜 평가할지를 병행하며 만들어야 한다.
• 에이전트 평가의 핵심은 최종 출력이 아니라, 올바른 도구를 올바른 순서로 호출하고 누락 정보를 되물었는지를 보는 것이다.
• LLM 심판은 '지표 하나당 심판 하나'로 분리하고, 질의·맥락·출력을 함께 제공해야 의미 있는 평가가 된다.
• 도메인 지식과 비즈니스 문제를 AI 설계 결정으로 옮길 수 있는 사람이 향후 채용 시장에서 우위를 갖는다.

자주 묻는 질문

관련 AI 소식