컨텍스트, RAG, 툴, 에이전트: 각각 어디서 틀리고 어떻게 확인하나

LLM의 한계를 보완하는 세 가지 방법 — 컨텍스트, RAG, 툴과 에이전트를 정리했어요. 확인 문제를 풀면서 놓친 지점을 같이 적었어요. 각 방법이 무엇이고 어디서 실패하는지를 다루고, 구현 코드나 특정 프레임워크 사용법은 다루지 않아요.

1. 모델은 보여준 것만 알아요

모델의 답은 학습된 지식과 지금 컨텍스트에 들어 있는 것으로 만들어져요. 사내 데이터, 오늘 로그, 내 요구사항은 학습에 없으니까 보여주지 않으면 모델에게는 없는 거예요.

좋은 지시에는 보통 이런 게 들어가요.

• 목표 — 무엇을 왜 하는지
• 입력 자료 — 데이터와 문서, 그 출처
• 제약 — 형식, 범위, 금지사항. "타임스탬프는 KST", "추정이면 추정이라고 표시" 같은 것
• 출력 형식 — 표, JSON 등. 형식을 정해 두면 나중에 검증하기도 쉬워요
• 예시(few-shot) — 원하는 입출력 예 1~3개가 긴 설명보다 정확해요
• 모를 때의 행동 — "자료에 없으면 확인 불가라고 답하라"

역할 부여("너는 공정 엔지니어다")는 말투와 관점을 맞추는 데는 도움이 돼요. 다만 모델이 모르는 지식이 생기지는 않아요.

컨텍스트는 많이 넣는다고 좋아지지 않아요. 관련 없는 자료가 섞이면 중요한 정보를 놓치고, 비용도 늘거든요. 필요한 걸 골라 넣는 일 자체가 기술이고, 요즘은 이걸 컨텍스트 엔지니어링이라고도 불러요.

2. RAG — 찾아서 보여주기

RAG(Retrieval-Augmented Generation)는 질문이 들어오면 관련 문서를 먼저 찾아 컨텍스트에 붙인 뒤 답하게 하는 구조예요.

1. 청킹 — 문서를 적당한 조각으로 잘라요
2. 임베딩 — 조각을 의미를 담은 벡터로 바꿔요. 의미가 비슷하면 벡터도 가까워요
3. 저장 — 벡터 DB에 넣어요
4. 검색 — 질문도 벡터로 바꿔서 가까운 조각 상위 k개를 가져와요. 키워드 검색과 섞기도 해요(하이브리드 검색)
5. 생성 — "아래 자료를 근거로 답하라"는 지시와 함께 모델에 넘겨요

매뉴얼 3,000쪽을 근거로 답하는 챗봇을 만드는데 그 매뉴얼이 분기마다 바뀐다면, 첫 접근은 파인튜닝보다 RAG예요. 둘은 해결하는 문제가 달라요.

RAG가 틀리는 경우

RAG 챗봇이 "PM 주기는 500시간"이라고 답하고 출처로 매뉴얼 4.2절을 달았는데 실제 최신 기준은 400시간인 상황이었어요. 저는 원인으로 문서가 최신화되지 않은 경우와, 청크를 잘못 잘라 엉뚱한 조각이 선택된 경우를 들었어요. 둘 다 맞았는데, 하나를 빠뜨렸어요 — 검색은 제대로 됐는데 모델이 근거를 무시하고 지어낸 경우요.

RAG가 실패하는 경우는 크게 넷이에요.

• 필요한 문서를 못 가져와요 — 청크 경계가 나쁘거나, 사내 약어·장비 코드처럼 임베딩이 의미를 못 잡는 용어 때문이에요
• 엉뚱한 문서를 가져와요 — 모델은 그걸 근거로 그럴듯하게 답해요
• 근거를 무시하고 자기 지식으로 답해요
• 문서 자체가 낡았거나 틀렸어요 — 실무에서는 옛 판과 새 판이 같이 색인돼서 옛 판이 검색되는 경우가 흔해요

그래서 첫 행동은 출처로 단 4.2절을 직접 열어 보는 거예요. 거기 정말 500이라고 써 있으면 문서 쪽 문제고, 없으면 모델이 지어낸 거예요. 이 확인 한 번으로 원인을 구분할 수 있어요. RAG를 써도 할루시네이션은 줄어들 뿐 없어지지 않아요.

이 실패 경우들은 RAG 평가 프레임워크의 축과 겹쳐요. RAGAS 논문은 세 가지를 봐요 — 답이 주어진 근거에 기대는지(faithfulness), 답이 질문에 맞는지(answer relevance), 가져온 근거가 질문에 맞고 군더더기가 없는지(context relevance)(Es et al. 2023). 지금 라이브러리 문서에는 필요한 근거를 빠짐없이 가져왔는지 보는 context recall, 가져온 것 중 쓸모 있는 비율을 보는 context precision 같은 지표가 더 붙어 있고요(Ragas 지표 목록).

3. 툴 사용 — 직접 실행하게 하기

모델이 직접 하지 못하는 일은 도구를 불러서 하게 해요.

1. 개발자가 쓸 수 있는 도구 목록을 줘요 — 이름, 설명, 입력 형식. 예: query_sensor_log(equipment_id, start, end)
2. 모델이 "이 도구를 이 인자로 부르겠다"는 요청을 출력해요
3. 실행은 모델이 아니라 바깥 프로그램이 해요
4. 결과를 다시 모델에게 줘요
5. 모델이 답하거나 다음 도구를 불러요

계산을 모델이 직접 하게 하면 틀릴 수 있지만, 코드로 돌리면 정확하고 실행 기록이 검증 흔적으로 남아요. 최신 데이터를 실제로 조회하니까 지식 컷오프도 피할 수 있고요.

도구와 데이터 소스를 AI 앱에 연결하는 방식을 통일하려는 표준으로 MCP(Model Context Protocol)가 있어요. Anthropic이 2024년 11월 25일 오픈소스로 공개했어요(Introducing the Model Context Protocol).

4. 에이전트 — 스스로 반복하게 하기

에이전트는 목표를 받고 "생각 → 도구 실행 → 결과 관찰 → 다음 행동"을 스스로 반복하는 구조예요. 이 패턴을 ReAct(Reason + Act)라고 불러요(Yao et al. 2022).

"어제 수율이 떨어진 원인 찾아줘"를 맡기면 대략 이렇게 움직여요. 수율 데이터를 조회해 하락 시점을 찾고, 같은 시점 장비 로그에서 특정 챔버의 온도 이상을 찾고, 그 챔버를 거친 웨이퍼만 따로 비교해서 보고서를 써요.

위험도 이 구조에서 나와요.

• 오류가 누적돼요. 단계마다 90%로 맞아도 10단계면 전체가 맞을 확률은 약 35%(0.9¹⁰)예요. Anthropic도 에이전트의 자율성이 비용 증가와 누적 오류 가능성을 함께 가져온다고 적고 있어요(Building effective agents).
• 잘못된 가정을 바탕으로 계속 진행해요. 첫 단계에서 날짜를 잘못 잡으면 이후 분석이 전부 틀어지는데, 결론은 아주 그럴듯하게 나와요.
• 권한. 삭제나 설정 변경처럼 되돌릴 수 없는 행동은 사람이 승인하게 하고, 권한은 최소로 줘요.
• 끝나지 않고 반복해요. 반복 횟수와 비용 상한을 둬요.

결론이 그럴듯한 보고서를 받았을 때

에이전트가 10단계 분석 끝에 "온도 센서 이상이 원인"이라는 보고서를 냈을 때 무엇을 확인하겠냐는 질문에, 저는 "검증 에이전트 돌리기"라고만 답했어요. 틀린 건 아닌데 약했어요. AI가 AI를 검증하면 같은 오류를 똑같이 놓칠 수 있어서, 검증 에이전트도 같은 보고서를 읽고 "그럴듯하다"고 할 수 있거든요.

더 확실한 검증은 독립적인 근거로 하는 검증이에요.

1. 중간 단계 확인 — 조회한 날짜 범위와 시간대, 대상 라인과 장비가 맞는지
2. 핵심 숫자 재현 — 하락폭, 온도 같은 숫자를 코드로 다시 계산
3. 상관과 인과 구분 — 같은 시점에 이상이 있었다는 것만으로는 원인이라고 할 수 없어요. 그 챔버를 거친 웨이퍼만 떨어졌는지, 안 거친 웨이퍼는 정상인지, 그 시간대에 다른 변화(레시피 변경, 자재 로트 교체)는 없었는지 봐요
4. 센서 자체 의심 — 이상값이 실제 공정 이상인지 센서 고장인지

다시 물었을 때는 "중간 단계를 탐색하고, 숫자는 코드로 검증하고, 상관과 인과를 구분하도록 검증해"라고 시키겠다고 답했어요. 여기에 두 가지를 더할 수 있어요.

• 보고서만 주지 말고 원본 데이터와 실행 기록을 같이 줘요. 보고서만 보면 보고서 안의 논리만 확인할 수 있거든요.
• 반박하는 역할을 줘요. "이 결론이 틀렸다는 증거를 찾아라. 다른 원인 후보를 최소 둘 제시하고 각각을 데이터로 배제하라." 출력은 항목별 통과/실패와 근거로 받아요.

다시 정리하면

• 모델은 컨텍스트에 넣어 준 것만 근거로 쓸 수 있어요. 필요한 것만 골라 넣는 게 좋아요.
• RAG는 문서를 찾아 붙여 주지만, 검색 실패·엉뚱한 문서·근거 무시·낡은 문서로 틀릴 수 있어서 출처를 직접 확인해요.
• 툴을 쓰면 계산과 조회를 코드가 하고, 실행 기록이 남아요.
• 에이전트는 단계가 길수록 오류가 쌓이니까, 중간 단계와 핵심 숫자를 독립적으로 확인해요.