Stanford CS230 | 2025년 가을 | 강의 8: 에이전트, 프롬프트 및 RAG

2016년, Microsoft는 사용자로부터 학습하기 위해 Twitter에 봇을 출시했습니다. 단 하루도 채 되지 않아 이 봇은 너무 심각한 인종차별적 발언을 하기 시작하여 16시간 만에 운영을 중단해야 했습니다. 이는 임시로 구성된 팀이 아니라 Microsoft였습니다. 그러나 수십억 달러의 자금과 수백 명의 엔지니어가 투입되었음에도 불구하고 언어 모델을 실제로 제어하는 것은 여전히 해결되지 않은 문제입니다. 그리고 여기에서 일반적인 이야기의 첫 번째 결함이 드러납니다. 우리는 '강력한 모델'이 '유용한 모델'과 동일시된다고 생각합니다. 그러나 실제로는 LLM의 최근 역사가 신뢰할 수 있고, 최신이며, 무엇보다도 올바른 결과를 얻는 것이 얼마나 어려운지에 대한 거대한 교훈이 됩니다. 이 강의의 주제는 다음과 같습니다. 진정한 도약은 점점 더 큰 기본 모델을 구축하는 것이 아니라, 이미 보유하고 있는 모델을 조율하고, 수정하고, 강화하는 방법을 배우는 것입니다. 단순히 개선된 프로프트에서 실제 에이전트 및 다중 에이전트 워크플로에 이르기까지, 장난감과 제품의 차이는 모델 자체가 아니라 모델을 둘러싼 아키텍처에 있습니다. Andrew Ng는 이러한 방향을 '에이전트 워크플로(agentic workflows)'라고 명명했습니다. 즉, 모델, 외부 도구, 메모리 및 API가 자율적인 작업 체인으로 결합되는 시스템입니다. 고객 후기를 분류하려는 생명공학 회사의 경우를 살펴보겠습니다. 이론적으로는 모델에 “이 문장은 긍정적인가, 중립적인가, 아니면 부정적인가?”라고 묻기만 하면 됩니다. 그러나 결과는 수많은 미세한 차이에 달려 있습니다. 의료 스타트업의 경우, '모든 것이 잘 진행되었지만 더 많은 것을 기대했어요'라는 의견은 부정적일 수 있지만, 다른 분야에서는 중립적일 수 있습니다. 모델을 실제 니즈에 어떻게 맞춥니까? 더 많은 데이터나 더 큰 모델이 아니라, 엔지니어링된 프롬프트, 맞춤형 예제, 그리고 점점 더 자주 사용되는 생성, 평가, 수정, 맥락에 맞게 조정하는 다단계 파이프라인을 통해 가능합니다. 구체적인 예: 프롬프트 체인. 하나의 지침으로 모든 것을 요청하는 대신 작업을 여러 단계로 나눕니다. 먼저 핵심 사항을 추출하고, 다음으로 개요를 작성한 후, 마지막으로 최종 답변을 작성합니다. Workera와 같은 기업에서 사용하는 이 접근 방식은 시스템이 실제로 어디에서 잘못되었는지 파악할 수 있게 해줍니다. 예를 들어, 단계별 안내가 제대로 되어 있지 않나요? 최종 답변이 너무 냉정적인가요? 이렇게 하면 문제점을 정확히 파악하여 개입할 수 있습니다. 비즈니스에서 이러한 세분화는 데모와 신뢰할 수 있는 솔루션 간의 차이를 만들어 냅니다. 흥미로운 사실은 BCG 컨설턴트에 대한 연구에서 AI를 사용할 수 있고 프로프트에 대한 간단한 교육도 받은 사람들이 AI를 사용하지 않은 사람들과 AI를 ‘맹목적으로’ 사용한 사람들보다 훨씬 우수한 성과를 냈다는 것입니다. 뿐만 아니라, 이 연구는 LLM과의 두 가지 협업 스타일을 식별했습니다. '프레젠테이션을 하고 끝났을 때 알려줘'와 같이 전체 블록을 위임하는 '켄타우로스'와 각 단계에서 모델과 미세하게 상호 작용하며 공생하는 '사이보그'입니다. 두 방법 모두 효과가 있지만 서로 다른 워크플로가 필요하며, 기업 규모가 커질 때 그 차이는 결코 사소한 것이 아닙니다. RAG, 즉 Retrieval-Augmented Generation은 업데이트 및 정확성 문제에 대한 가장 구체적인 답변입니다. 모델이 '모든 것을 알고 있다'고 가정하는 대신, 외부 데이터베이스에 연결하여 관련 문서만 검색하여 답변에 포함시킵니다. 이는 임시방편처럼 보일 수 있지만, 생각해 보세요. 미래에 모델이 실시간으로 전체 웹을 읽을 수 있다고 해도 (스포iler: 지연 시간과 비용 문제로 절대 실현되지 않을 것입니다), 효율성과 출처 추적을 위해 검색 엔진과 같은 검색 시스템이 계속 필요할 것입니다. 트럼프 대통령의 유명한 “Covfefe” 실수 직후 생성된 콘텐츠의 예를 들어 보겠습니다. Twitter의 LLM은 이를 어떻게 처리해야 할지 몰랐고, 추천 시스템은 혼란에 빠졌습니다. 오늘날에도 슬랭, 신어, 트렌드와 관련하여 매일 똑같은 일이 발생하고 있습니다. RAG를 사용하면 모든 것을 처음부터 다시 훈련할 필요 없이 최신 정보를 유지할 수 있습니다. 이제 에이전트로 넘어가 보겠습니다. 고객 지원 에이전트를 생각해 보세요. 더 이상 단순히 응답하는 채팅 시스템이 아닙니다. 데이터 추출, 주문 데이터베이스 검색, 정책 확인, 정보 업데이트, 이메일 작성 등 모든 작업을 도구와 메모리를 조율하여 수행합니다. 하지만 이것이 '잘 작동하는지' 어떻게 알 수 있을까요? 여기에서 'evals', 즉 평가라는 개념이 중요해집니다. 객관적인 지표(해결된 요청의 비율, 응답 시간, 출력 정확도) 및 LLM 심사 위원 또는 사람의 피드백을 통한 주관적인 평가가 모두 사용됩니다. 그리고 가장 중요한 것은 모든 중간 단계를 추적한다는 것입니다. 만약 응답이 무례하다면, 어떤 프롬프트나 하위 시스템에서 문제가 발생했는지 추적할 수 있습니다. 이러한 모듈식으로 추적 가능한 아키텍처가 전통적인 결정론적 소프트웨어와 LLM 기반의 퍼지 시스템 간의 진정한 차이점입니다. 여기서 중요한 것은 한 번만 견고한 코드를 작성하는 것이 아니라, 실험하고, 일부분을 버리고, 반복하고, 인공 지능이 잘못되거나 궤도를 벗어난 부분을 수정하기 위해 인간 워크플로를 구현하는 방법을 배우는 것입니다. McKinsey는 엔터프라이즈 수준에서 에이전트 자동화가 신용 위험 평가와 같은 프로세스 시간을 20~60% 단축할 수 있다고 추정했습니다. 그러나 진정한 도전은 기술적인 것이 아닙니다. 수천 명의 사람들의 습관을 바꾸고, 직무 설명을 다시 작성하고, 인센티브를 재정의하는 것입니다. 그렇기 때문에 기술이 빠르게 발전하더라도 조직이 실제로 변화하는 데는 수년이 걸릴 것입니다. 마지막으로 한 가지 더 생각해 볼 점은, 오늘날 진정한 가치는 더 큰 모델을 구축하는 데 있지 않고, 실제적이고 측정 가능하며 시간이 지남에 따라 개선 가능한 문제를 해결하기 위해 모델, 도구, 워크플로 및 메모리를 함께 결합하는 데 있다는 것입니다. 데모와 제품의 차이점은 무엇일까요? 생성되는 모델뿐만 아니라 조율하는 시스템의 편에 서는 것입니다. 이 강의는 2025년 가을 스탠퍼드 대학교 CS230 강의에서 가져온 것입니다. 방금 거의 2시간 분량의 강의를 절약하셨습니다.