엔터프라이즈 AI 프로젝트에는 일정한 패턴이 있습니다. 팀이 프로토타입을 만듭니다. 데모는 인상적입니다. 그러다 3개월 후, 시스템이 무너지기 시작합니다. 답변이 어긋나고, 비용은 치솟습니다. 컴플라이언스 담당자가 특정 답변이 어디서 나왔는지 물으면, 회의실의 그 누구도 대답하지 못합니다.
이러한 붕괴는 나쁜 코드 때문에 발생하는 경우가 드뭅니다. 이는 인기 투표처럼 다뤄지는 단 하나의 아키텍처 선택에서 시작됩니다. 바로 검색 증강 생성(Retrieval-Augmented Generation, RAG)과 파인튜닝(fine-tuning) 사이의 선택입니다.
RAG와 파인튜닝은 같은 제품의 두 가지 버전이 아닙니다. 이들은 근본적으로 다른 도구입니다. 하나는 모델이 무엇을 볼 수 있는지를 제어하고, 다른 하나는 모델이 어떻게 행동하는지를 제어합니다. 작업에 맞지 않는 방식을 선택하는 문제는 프로토타입 단계에서는 나타나지 않습니다. 비즈니스가 그 시스템 위에서 실제로 운영될 때 비로소 문제가 드러납니다.
데모의 함정
생성형 AI 기능을 출시해야 한다는 압박은 매우 강렬합니다. 팀들은 잘 작성된 튜토리얼에서 봤다는 이유로, 혹은 벤더의 슬라이드 자료가 쉬워 보인다는 이유로 특정 방식을 선택하곤 합니다. 이는 인프라 의사결정을 내리는 매우 잘못된 방식입니다.
통제된 데모 환경에서 파인튜닝된 모델은 마법처럼 보일 수 있습니다. 회사의 톤앤매너로 말하고 제품 이름을 인식합니다. RAG 파이프라인 역시 마법처럼 보일 수 있습니다. 학습한 적 없는 문서에 대한 질문에도 답변하기 때문입니다. 하지만 데모는 운영상의 현실을 가립니다. 만약 가격 데이터가 매주 바뀌는데 지난 분기 수치로 파인튜닝을 했다면, 모델은 잘못된 수치를 자신 있게 인용할 것입니다. 지원 팀이 모든 답변에 대해 특정 정책 PDF를 추적할 수 있어야 한다면, 파인튜닝된 모델은 각주를 제공하지 않습니다. 그저 텍스트만 내뱉을 뿐입니다.
RAG의 실제 의미
RAG는 Retrieval-Augmented Generation의 약자이지만, 이름 때문에 실제보다 더 복잡하게 느껴질 수 있습니다. 핵심은 RAG가 단 하나의 질문에 답한다는 것입니다. "모델이 지금 당장 무엇을 찾아봐야 하는가?"
티켓에 답변하기 전에 회사 위키를 검색할 수 있는 고객 서비스 상담원을 상상해 보십시오. RAG는 정확히 그 역할을 자동으로 수행합니다. 사용자가 질문을 하면, 시스템은 벡터 데이터베이스나 문서 저장소에서 관련 있는 텍스트 조각(chunks)을 검색합니다. 그런 다음 그 조각들을 원래 질문과 함께 컨텍스트(context)로서 언어 모델에 전달합니다. 모델은 검색된 근거를 바탕으로 답변을 생성합니다.
이 방식은 지식 베이스가 모델 외부에 존재할 때 빛을 발합니다. 제품 문서, 법적 서류, 의료 연구, 재고 스프레드시트는 모두 계속 변합니다. RAG는 가중치를 단 하나도 다시 학습시키지 않고도 모델을 최신 상태로 유지합니다. 또한 자연스러운 감사 추적(audit trail)을 생성합니다. 어떤 문서가 검색되었는지 알 수 있기 때문에, 감사인이나 규제 기관에 답변이 정확히 어디에서 왔는지 보여줄 수 있습니다.
파인튜닝의 실제 의미
파인튜닝은 다른 질문에 답합니다. "모델이 어떻게 행동해야 하는가?"
모델에게 외부 읽기 자료를 주는 대신, 예시를 통해 가르칩니다. 원하는 출력값의 예시를 수백, 수천 개 수집하여 해당 데이터로 베이스 모델을 계속 학습시킵니다. 이 과정은 실제로 모델의 내부 파라미터를 조정하며, 가중치(weights)를 변경합니다.
그 결과, 패턴을 내재화한 모델이 탄생합니다.