AI는 학습한 것인가, 아니면 일시적으로 기억하는 것일 뿐인가

서론

AI에 대해 이야기하다 보면, '이 대화를 AI가 학습했다', '이 자료를 AI에게 기억시켰다'라는 표현을 자주 듣습니다.

물론 일상 대화로는 통합니다. 하지만 AI를 서비스나 업무에 통합할 때는, 학습한 것인지 아니면 입력으로 참조만 한 것인지를 구분해서 생각하는 것이 좋다고 생각합니다.

프롬프트에 자료를 붙이거나, RAG(Retrieval-Augmented Generation)로 검색 결과를 전달하거나, 에이전트에게 과거 대화를 참조하게 하거나, 파인튜닝을 실행하는 경우 등. 이 모든 것은 AI의 응답을 바꿀 수 있습니다. 하지만 이를 모두 같은 '지식이 늘었다'는 말로 묶으면, 저장 위치도 유효 기간도 삭제 방법도 알 수 없게 됩니다.

이 글에서는 AI와 관련된 '학습'과 '일시적인 기억'을 몇 가지 계층으로 나누어 정리합니다. 특정 서비스의 이용 약관을 해설하는 글이라기보다는, AI 기능을 설계하고 설명할 때의 사고방식을 정리하는 글입니다🧭

먼저 '학습'이라는 단어를 구분하기

엄밀히 말해 학습은 데이터 그 자체가 아닙니다. 데이터를 사용하여 모델의 파라미터를 업데이트하고, 다음에 입력되는 것에 대한 행동을 변화시키는 훈련 과정입니다.

따라서 '학습에 사용한 데이터'와 '학습 결과로 만들어진 모델'은 별개의 것입니다. 대화 로그를 저장만 한다고 해서 그것만으로 모델이 학습했다고 할 수는 없습니다.

여기서 구분하고 싶은 것은, 모델의 훈련과 그 외의 메커니즘입니다. 모델의 훈련에서는 데이터나 보상을 사용하여 파라미터를 업데이트합니다. 파인튜닝(Fine-tuning)에서는 이미 존재하는 모델에 추가 데이터를 주어 특정 작업이나 형식에 적합하도록 훈련합니다.

반면에, 프롬프트나 첨부 자료는 해당 요청의 컨텍스트로 전달됩니다. RAG에서는 검색한 정보를 추론 시의 컨텍스트에 추가합니다. 애플리케이션의 기억(memory)에서는 대화 요약이나 사용자 속성 등을 다른 곳에 저장하고 다음 프롬프트에 포함할 수 있습니다. 이들은 모델의 파라미터를 업데이트하지 않아도 구현할 수 있습니다.

응답이 바뀌었다고 해서 곧바로 '학습했다'고 말할 수는 없습니다. 먼저, 모델 자체가 변했는지, 아니면 모델에 전달된 입력이 변했는지를 확인할 필요가 있습니다.

모델을 만들 때의 학습

일반적인 LLM은 대량의 데이터를 사용한 사전 학습(pre-training)을 통해 언어 패턴이나 지식 표현을 모델의 파라미터에 통합합니다. 여기서 말하는 '통합'은 데이터베이스의 문장을 그대로 검색할 수 있는 형태로 저장한다는 의미가 아닙니다.

그 후, 바람직한 응답 예시를 사용한 지도 학습 기반 파인튜닝(Supervised Fine-tuning)이나, 인간/평가자로부터의 피드백을 보상으로 이용하는 강화학습(RL) 계열의 기법 등이 사용될 수 있습니다.

여기서, 강화학습 역시 '인간의 대화를 그대로 기억하는 메커니즘'으로 간주해서는 안 됩니다. 이는 보상이나 평가를 단서로 하여 더 바람직한 행동이 되도록 훈련하는 시스템입니다. 무엇을 보상으로 할지, 어떤 데이터를 사용할지, 어떤 방법을 사용할지는 서비스나 훈련 단계에 따라 다릅니다.

파인튜닝은 이미 존재하는 모델에 추가적인 훈련을 하는 것입니다. '나중에 지식을 더한다'는 설명이 편리할 때도 있지만, 실제로는 단순한 지식 기반의 추가와는 다릅니다. 특정 형식, 작업, 문체, 판단 경향을 습득시키는 용도로 설명하는 것이 오해를 줄일 수 있습니다.

프롬프트와 컨텍스트는 '그 자리에서 전달되는 정보'

프롬프트에 자료를 붙이면 모델은 그 자료를 바탕으로 답변을 생성할 수 있습니다. 하지만 그것이 보통 모델 자체가 자료를 학습했다는 의미는 아닙니다.

자료는 요청의 입력, 즉 컨텍스트로 취급됩니다. 응답을 생성하는 데 도움이 되지만, 다른 요청에서 자동으로 같은 지식을 사용할 수 있는 것은 아닙니다. 컨텍스트 윈도우의 상한이나 대화 기록을 어디까지 보낼 것인지에 대한 구현상의 제약도 있습니다.

이 차이는 답변이 나올 때까지의 흐름을 떠올리면 이해하기 쉽습니다. 훈련 데이터는 훈련을 거쳐 모델의 파라미터에 영향을 미칩니다. 반면, 프롬프트, 대화 기록, RAG 검색 결과, 애플리케이션에 저장된 기억은 추론 직전에 컨텍스트로 모델에 전달됩니다. 모델은 이들 컨텍스트와 자신이 가진 파라미터를 사용해 답변을 생성합니다.

같은 답변 안에는, 모델이 원래 가지고 있던 패턴, 이번 프롬프트에서 얻은 정보, 검색 결과, 앱이 저장했던 기억이 혼재되어 있을 수 있습니다. 사용자 입장에서는 하나의 'AI 지식'처럼 보이지만, 시스템 내부에서는 출처가 다릅니다.

RAG는 '지식을 모델에 각인시키는' 것이 아니다

RAG는 질문과 관련된 문서를 검색하고, 그 결과를 생성 모델의 입력에 포함하는 구성입니다. 원 논문에서는 모델 내부의 파라메트릭한 기억(parametric memory)과 외부 인덱스 같은 비파라메트릭한 기억(non-parametric memory)을 결합하는 개념으로 설명되었습니다.

따라서 RAG 인덱스에 문서를 추가한 것을 'LLM이 그 문서를 학습했다'고 표현하면 약간 어긋납니다. 대부분의 경우 바뀐 것은 모델의 가중치(weight)가 아니라, 검색 대상 데이터와 검색 및 주입 처리 과정입니다.

이 차이는 문서 처리 메커니즘을 설계할 때 중요합니다. 문서를 교체하면 검색 결과를 업데이트할 수 있습니다. 접근 권한을 확인하여 사용자별로 검색 대상을 다르게 할 수도 있습니다. 반대로, 검색에 실패했거나 오래된 인덱스를 보고 있다면, 모델이 지식을 잊은 것이 아니라 참조 경로에 문제가 있을 수 있습니다🔎

에이전트의 '기억'도 여러 가지로 나뉜다

에이전트가 과거 대화를 기억하는 것처럼 보이는 경우에도 구현 방식은 몇 가지가 있을 수 있습니다. 직전 대화 기록을 다음 요청에도 보내고만 있을 수도 있습니다. 과거 대화를 요약하여 프로필이나 메모로 저장하고 있을 가능성도 있습니다. 벡터 검색으로 과거 발언을 찾아 관련 내용만 프롬프트에 전달하는 경우도 있습니다. 외부 시스템의 데이터를 툴(tool)을 통해 가져오고 있을 수도 있습니다. 또한, 그 대화나 데이터가 향후 모델 훈련에 이용되는 케이스도 있습니다.

이 모든 것은 사용자 입장에서는 '기억하고 있다'로 보입니다. 하지만 삭제 방법은 같지 않습니다. 대화 기록을 삭제해도 별도로 저장된 요약이나 검색 인덱스가 남아 있는 설계는 가능합니다. 반대로, 저장되지 않은 일시적인 컨텍스트(context)는 요청이 끝나면 다음 입력에 사용되지 않습니다.

따라서 AI 기능의 사양을 작성할 때는 'AI가 기억합니다'라고만 설명하는 것보다 친절하게 설명하는 것이 좋습니다. 예를 들어, '대화를 저장하고 다음 프롬프트에 요약을 포함합니다'라고 쓰면 애플리케이션의 기억이라는 것을 전달할 수 있습니다. '문서를 검색 인덱스에 등록하고 답변 시 관련 부분을 가져옵니다'라고 쓰면 자료를 RAG의 참조원으로 다룬다는 것을 알 수 있습니다.

'사용할수록 똑똑해집니다'라는 표현도 주의가 필요합니다. 실제로는 평가 데이터를 축적하여 나중 모델 개선에 이용하는 것일 수도 있고, 단순히 사용자의 선호도를 저장하여 다음 프롬프트에 포함하고 있을 수도 있습니다. '일시적으로 기억합니다'라는 경우도 현재 요청의 컨텍스트로 참조하는지, 일정 기간 동안만 기록으로 남는지에 따라 의미가 달라집니다.

'대화를 학습에 사용하는' 것은 어느 계층인가

이 표현은 특히 혼란을 야기합니다.

어떤 서비스가 '대화를 모델 개선에 사용한다'고 설명하는 경우, 일반적으로 대화 데이터가 향후 평가나 훈련의 데이터 후보가 된다는 의미입니다. 이는 지금 이 순간의 모델이 대화 내용을 파라미터에 반영했다는 의미도 아니며, 다음 응답에서 반드시 그 대화를 기억한다는 의미도 아닙니다.

반면, '이 대화를 다음에 참조합니다'라는 기능은 대화 기록이나 저장 메모리 등 애플리케이션 측의 기억일 가능성이 있습니다. 게다가 '이 자료를 사용해서 답변해 주세요'는 컨텍스트나 RAG에 관한 이야기입니다.

여기서는 먼저 어디에 저장되는지 확인해야 합니다. 그 후에 다음 응답에서 참조되는지, 모델 파라미터를 업데이트하는 훈련에 쓰이는지, 삭제나 이용 정지를 어떤 설정/절차로 할 수 있는지 확인합니다.

이 질문에 답할 수 없는 상태에서 '학습합니다'라고만 설명하면, 사용자는 저장, 참조, 훈련, 공개 범위를 혼동하게 됩니다. 반대로 이 네 가지를 순서대로 설명할 수 있다면, 같은 '기억한다'는 단어라도 어떤 메커니즘을 가리키는지 공유하기 쉬워집니다.

개발자가 설계 시 의식해야 할 점

AI를 통합하는 측에서는 '지식을 준다'고 생각하기 전에, 어느 계층에 무엇을 둘 것인지 결정하면 정리하기 쉽습니다. 최신 사내 문서를 답변에 사용하고 싶다면, 먼저 RAG나 외부 검색을 고려합니다. 이 경우 문서의 업데이트, 사용자별 권한, 답변 인용(citation), 삭제 시 처리가 중요합니다.

출력 형식을 안정시키고 싶다면, 프롬프트나 예시를 고안하여 필요에 따라 파인튜닝(fine-tuning)을 고려합니다. 여기서는 평가 방법, 재훈련 방법, 모델 업데이트 시의 호환성이 문제가 됩니다. 사용자의 선호도를 다음에도 반영하고 싶다면, 애플리케이션의 기억으로 저장하고, 저장 기간이나 수정/삭제 방법을 마련해야 합니다.

바람직한 행동을 모델 자체에 반영하고 싶다면, 평가 데이터나 추가 훈련에 대한 논의가 필요합니다. 이번에만 자료를 참조하고 싶다면, 컨텍스트로 전달하여 유지 범위, 입력 상한, 로그 기록 여부를 확인해야 합니다. 이렇게 목적부터 역산하면 '일단 학습시키자'라는 발상을 피하기 쉬워집니다.

민감도가 높은 정보를 다룰 경우에는 모델의 성능뿐만 아니라, 데이터 저장 위치, 접근 제어, 로그, 삭제 전파까지 확인할 필요가 있습니다. 특히 '학습에는 사용하지 않는다'는 설명만으로는, 기록이나 검색 인덱스에 저장되지 않음을 보장한다고 할 수 없습니다.

맺음말

AI가 새로운 정보를 바탕으로 답변했을 때, 우리는 무의식적으로 'AI가 학습했다'고 말하고 싶어집니다.

하지만 실제로는 모델의 훈련(training), 파인튜닝(fine-tuning), 프롬프트 컨텍스트(context), RAG 검색 결과, 에이전트의 저장 메모리 등 다양한 메커니즘이 비슷한 형태의 응답을 만들어내고 있습니다.

'학습'이라는 단어를 광범위하게 사용하는 것 자체가 나쁜 것은 아닙니다. 다만, 설계나 데이터 처리 방식을 고려할 때는 어떤 계층(layer)이 변경되었는지를 명확히 할 필요가 있습니다.

대화를 주고받았을 때 모델이 학습했는가? 자료를 제공했을 때 모델의 지식이 되었는가? 에이전트가 기억하는 것은 어디에 저장되며, 얼마나 오래 유지되고, 어떻게 삭제할 수 있는가?

이 질문에 답할 수 있도록 준비해 두는 것이 AI를 안심하고 사용하기 위한 첫 번째 설계라고 생각합니다🧠

참고 자료

논의