1부 4장. RAG, 워크플로, 에이전트는 무엇이 다른가

현장에서 가장 자주 듣는 말 가운데 하나가 이것이다. "이건 RAG로 되나요, 아니면 에이전트가 필요하나요?" 질문은 간단해 보이지만, 사실은 세 가지 다른 층위가 한 문장 안에 섞여 있다. RAG는 정보를 넣는 방식에 가깝고, 워크플로는 일을 흘려보내는 방식에 가깝고, 에이전트는 다음 행동을 고르는 방식에 가깝다. 이름은 비슷한 자리에 놓이지만, 실제로는 서로 다른 문제를 푼다.

이 차이를 흐리게 보면 설계가 금방 꼬인다. 문서 검색이 필요한데 괜히 에이전트를 붙여 시스템을 복잡하게 만들고, 반대로 동적 판단이 필요한데 단순 워크플로로 버티다가 예외 상황마다 멈춰 서게 된다. 그래서 이번 장의 목표는 하나다. RAG, 워크플로, 에이전트를 경쟁 관계로 보지 말고, 각각의 역할과 경계를 또렷하게 이해하는 것이다.

한마디로 먼저 정리하면 이렇다. RAG는 "무슨 정보를 넣을까"의 문제를 다루고, 워크플로는 "어떤 순서로 실행할까"의 문제를 다루며, 에이전트는 "지금 다음에 무엇을 해야 할까"의 문제를 다룬다. 이 한 줄이 머릿속에 자리 잡으면, 이후 설계의 절반은 이미 풀린 셈이다.

왜 이 셋이 자꾸 헷갈릴까

셋이 자주 헷갈리는 이유는 모두 LLM과 함께 등장하기 때문이다. 사용자는 질문을 하고, 시스템은 문서를 찾기도 하고, 어떤 경우에는 외부 도구도 부르고, 최종적으로 자연스러운 답을 돌려준다. 겉모습만 보면 다 비슷하다.

하지만 안쪽을 들여다보면 핵심 질문이 다르다. 어떤 시스템은 "정답에 가까운 정보를 어떻게 가져올까"에 초점이 있고, 어떤 시스템은 "정해진 절차를 얼마나 안정적으로 실행할까"에 초점이 있으며, 어떤 시스템은 "현재 상태를 보고 다음 행동을 어떻게 고를까"에 초점이 있다.

이 차이를 놓치면 아주 흔한 오해가 생긴다. 문서를 검색하면 다 RAG라고 부르고, 외부 API를 부르면 다 에이전트라고 부르고, 단계가 여러 개면 다 워크플로라고 부르는 식이다. 하지만 검색이 있다고 모두 RAG인 것도 아니고, 도구 호출이 있다고 모두 에이전트인 것도 아니며, 단계가 있다고 모두 워크플로인 것도 아니다. 무엇을 위해 그 구조를 쓰는지가 더 중요하다.

RAG는 읽기 전용 지식 주입에 가깝다

RAG는 Retrieval-Augmented Generation의 약자다. 어렵게 들리지만 감각은 단순하다. 모델이 답하기 전에 관련 문서를 찾아서, 그 내용을 컨텍스트로 넣고, 그 바탕 위에서 답을 생성하는 방식이다. 즉, 모델의 머릿속 기억만 믿지 않고 바깥의 자료를 함께 보게 만드는 장치다.

여기서 중요한 점은 RAG의 중심이 "읽기"라는 것이다. 보통 RAG는 문서를 조회하고, 필요한 부분을 골라 넣고, 그 근거를 바탕으로 답하게 만든다. 이 과정의 목적은 세계를 바꾸는 행동이 아니라, 더 정확하고 근거 있는 응답을 만드는 데 있다. 그래서 사용자가 사내 규정, 제품 매뉴얼, 계약 조항, 정책 문서를 묻는 상황에서 특히 강하다.

예를 들어 "우리 회사의 출장비 정산 기준이 어떻게 되나요?"라는 질문을 생각해 보자. 여기서 가장 좋은 시스템은 대개 화려한 자율성을 가진 에이전트가 아니다. 최신 규정 문서를 찾고, 관련 조항을 읽고, 그 내용을 바탕으로 깔끔하게 요약해 주는 RAG 시스템이면 충분할 가능성이 크다.

RAG의 장점은 분명하다. 모델이 아는 척하는 대신 실제 자료를 참고하게 만들 수 있고, 최신 정보를 반영하기도 쉬우며, 답의 근거를 추적하기도 좋다. 하지만 한계도 선명하다. RAG는 원래 계획을 세우는 구조가 아니고, 상태를 길게 운영하는 구조도 아니며, 여러 단계의 행동을 자율적으로 이어 가는 구조도 아니다. 말 그대로 잘 읽고 잘 답하게 만드는 장치에 가깝다.

그래서 RAG 자체를 하나의 완결된 제품 유형으로 보기보다, 지식을 주입하는 기술적 패턴으로 보는 편이 더 정확하다. 챗봇 안에도 들어갈 수 있고, 워크플로 안에도 들어갈 수 있고, 에이전트 안에도 들어갈 수 있다.

워크플로는 정해진 절차를 흔들림 없이 실행한다

워크플로의 중심은 순서다. 무엇을 먼저 하고, 그다음 무엇을 하며, 어떤 조건이면 어느 경로로 분기할지를 미리 정해 두고 그대로 실행한다. 즉, 시스템이 스스로 목표를 재정의하거나 새로운 전략을 짜는 것이 아니라, 설계자가 준비해 둔 길을 안정적으로 따라간다.

예를 들어 고객 환불 요청 처리 과정을 생각해 보자. 주문 내역 확인, 환불 가능 기간 확인, 결제 수단 확인, 승인 필요 여부 판정, 환불 실행, 고객 통지까지 이어지는 절차가 있을 수 있다. 이런 문제는 대개 규칙이 비교적 명확하다. 그렇다면 잘 설계된 워크플로가 가장 믿을 만하다.

워크플로는 자율성이 낮아 보일 수 있지만, 실무에서는 대단히 강하다. 이유는 반복 가능성과 예측 가능성 때문이다. 같은 입력이 들어오면 비슷한 방식으로 처리되고, 예외도 미리 정의한 범위 안에서 통제할 수 있다. 운영팀과 보안팀, 법무팀이 좋아하는 구조가 바로 이런 것이다. 이유 없는 창의성이 끼어들 틈이 적기 때문이다.

중요한 것은 워크플로도 충분히 강한 행동 시스템이 될 수 있다는 점이다. 데이터베이스를 갱신하고, 외부 API를 호출하고, 메일을 보내고, 승인 요청을 올리고, 티켓을 발행할 수 있다. 그런데도 에이전트와 다른 이유는, 다음 행동을 고르는 폭이 좁기 때문이다. 길은 이미 깔려 있고, 시스템은 그 길을 잘 따라간다.

한마디로 워크플로는 "무엇을 할지"보다 "정해진 것을 얼마나 잘 실행할지"에 강한 구조다.

에이전트는 경로를 동적으로 고른다

에이전트는 여기서 결이 달라진다. 에이전트의 핵심은 목표를 향해 현재 상태를 보고, 다음 행동을 선택하고, 필요하면 도구를 쓰고, 결과를 반영해 다시 판단하는 실행 루프에 있다. 같은 목표라도 상황에 따라 경로가 달라질 수 있다.

예를 들어 "경쟁사 세 곳의 최근 가격 정책을 조사해 비교표를 만들고, 우리 제품의 대응 전략 초안을 써 달라"는 요청을 보자. 이 과업은 중간에 무엇이 나올지 미리 다 알기 어렵다. 어떤 회사는 자료가 공개되어 있고, 어떤 회사는 제품 페이지를 여러 번 뒤져야 하며, 어떤 경우에는 정보가 부족해 사용자의 추가 확인이 필요할 수도 있다. 이런 문제에서는 단일한 고정 절차보다, 상태를 보며 다음 수를 고르는 구조가 더 잘 맞는다.

에이전트는 검색을 먼저 할 수도 있고, 사내 파일을 읽을 수도 있고, 정보가 부족하면 질문을 되물을 수도 있다. 어떤 자료를 찾은 뒤에는 계획을 조금 바꿀 수도 있다. 바로 이 동적 판단이 에이전트의 본질이다.

물론 여기서도 오해를 피해야 한다. 에이전트는 무조건 더 고급 시스템이 아니다. 자유도가 높은 대신 비용도 늘고, 디버깅도 어려워지고, 실패 양상도 복잡해진다. 즉, 에이전트는 더 똑똑한 만능 열쇠가 아니라, 필요한 순간에만 꺼내 써야 하는 더 복잡한 구조다.

셋의 차이는 서로 다른 축에 있다

이제 핵심을 더 선명하게 보자. RAG, 워크플로, 에이전트는 사실 같은 축에서 겨루는 개념이 아니다.

이 표를 보면 중요한 사실이 드러난다. RAG는 지식 계층에 가깝고, 워크플로는 제어 계층에 가깝고, 에이전트는 의사결정 계층에 가깝다. 그래서 셋은 서로를 대체하기보다 겹쳐서 사용되는 경우가 많다.

에이전트가 문서를 읽어야 하면 내부에 RAG를 쓸 수 있다. 워크플로의 한 단계에서 관련 문서를 불러 답변 초안을 만들기 위해 RAG를 쓸 수 있다. 에이전트가 너무 위험한 쓰기 작업을 직접 하지 않게 하고, 승인된 순간에만 정해진 워크플로로 넘기게 할 수도 있다.

정리하면, RAG는 재료를 넣는 법이고, 워크플로는 레일을 까는 법이며, 에이전트는 상황을 보며 방향을 정하는 법이다.

같은 요청을 세 방식으로 처리해 보자

"신규 고객사와의 첫 미팅을 준비해 줘"라는 요청을 예로 들어 보자.

RAG 중심 시스템이라면, 회사 소개 문서, 기존 제안서, 산업 리포트, 고객사 관련 자료를 찾아 한 번에 읽히고 요약해 줄 것이다. 이 경우 시스템은 좋은 브리핑 문서를 만드는 데 강하다. 하지만 부족한 정보를 스스로 추가 조사할지, 일정 조율이 필요한지, 누가 참석해야 하는지까지 길게 판단하지는 않는다.

워크플로 중심 시스템이라면, 미리 정한 절차대로 CRM에서 고객 정보를 가져오고, 최근 접점 기록을 읽고, 표준 미팅 브리프 템플릿을 채우고, 관련 팀에 자료 요청 메일을 보낼 수 있다. 반복적이고 조직적인 준비에는 아주 강하다. 다만 고객사가 특이한 업종이거나 이전 기록이 빈약해서 추가 탐색이 필요하면, 준비된 분기 밖에서는 약해질 수 있다.

에이전트 중심 시스템이라면, 우선 어떤 정보가 필요한지 판단하고, 고객사 공개 자료를 찾고, 내부 CRM도 확인하고, 빠진 정보가 있으면 사용자에게 물어보고, 미팅 목표에 맞춰 발표 포인트를 구성하고, 경우에 따라 예상 질문과 리스크까지 정리할 수 있다. 목표는 같지만, 도달 경로는 매번 달라질 수 있다.

같은 "미팅 준비"라는 요청이라도, 시스템 구조에 따라 책임 범위가 완전히 달라진다. 이 차이를 모르고 하나의 이름으로 뭉뚱그리면 설계가 흐릿해진다.

RAG는 에이전트의 하위 호환도, 상위 개념도 아니다

실무에서 특히 많이 나오는 오해가 있다. "RAG보다 에이전트가 더 발전된 형태 아닌가요?" 얼핏 들으면 그럴듯하지만 정확한 표현은 아니다.

RAG와 에이전트는 계층이 다르다. 에이전트가 RAG를 사용할 수는 있다. 하지만 그렇다고 RAG가 에이전트의 초기 버전이라는 뜻은 아니다. 좋은 RAG 시스템은 에이전트가 전혀 없어도 실무에서 매우 큰 가치를 낼 수 있다. 반대로 에이전트도 꼭 RAG를 써야 하는 것은 아니다. 어떤 에이전트는 내부 상태와 도구 호출만으로도 충분히 작동할 수 있다.

예를 들어 사내 규정 질의응답 시스템은 정교한 RAG면 충분할 수 있다. 반면 "내일 있을 임원 보고를 위해 최근 수치를 모으고, 이상 징후를 찾고, 발표용 요약을 만들어 달라"는 요청은 에이전트성이 필요할 수 있다. 둘 중 어느 쪽이 더 고급이냐가 아니라, 어떤 문제를 푸느냐가 다를 뿐이다.

이 감각이 중요하다. RAG를 해야 할 문제를 억지로 에이전트화하면, 검색 한 번이면 끝날 일을 여러 단계 루프로 돌리며 비용과 불확실성만 늘린다. 반대로 에이전트가 필요한 문제를 단순 RAG로 밀어붙이면, 시스템은 문서를 잘 읽고도 실제로는 아무 일도 끝내지 못한다.

무엇을 에이전트로 만들지 말아야 하는가

이 장의 핵심 가운데 하나는 바로 이것이다. 모든 문제를 에이전트로 만들지 말아야 한다.

먼저, 답이 이미 신뢰할 수 있는 문서 안에 있고 사용자는 그 답을 읽기만 하면 되는 문제라면, RAG가 더 적합할 가능성이 크다. 규정 안내, 제품 문서 질의응답, 정책 검색, 계약 조항 확인 같은 문제들이 여기에 들어간다.

다음으로, 절차가 안정적이고 예외도 어느 정도 예측 가능하다면 워크플로가 더 낫다. 환불 처리, 주문 후속 조치, 승인 요청, 정형 보고서 생성, 데이터 정제 파이프라인 같은 일은 고정 절차가 주는 안정성이 훨씬 중요하다.

특히 되돌리기 어려운 쓰기 작업은 함부로 에이전트에게 자율성을 많이 주지 않는 편이 좋다. 결제 실행, 계정 삭제, 계약 발송, 운영 설정 변경 같은 일은 대개 워크플로와 권한 통제, 사람 승인 위에 올려야 한다. 에이전트가 관찰과 제안을 할 수는 있어도, 마지막 버튼을 자유롭게 누르게 두는 것은 전혀 다른 문제다.

즉, 불확실성이 낮고 절차가 분명할수록 에이전트는 과한 선택이 될 가능성이 높다.

언제 에이전트가 꼭 필요한가

반대로 에이전트가 빛나는 순간도 분명하다.

과업을 이루는 경로가 매번 달라질 때가 그렇다. 중간 결과를 보고 다음 행동을 정해야 하고, 정보가 부족하면 추가 탐색이나 질문이 필요하고, 어떤 도구를 써야 할지도 상황에 따라 달라진다면 에이전트 구조가 설득력을 가진다.

예를 들어 심층 리서치, 복합 고객 이슈 분석, 여러 시스템을 오가며 원인을 찾는 운영 진단, 목표 기반 문서 작성, 미정형 업무 보조처럼 "한 번에 정해진 레일"로 표현하기 어려운 일들이 여기에 속한다. 이때 중요한 것은 단순히 단계가 많다는 사실이 아니라, 단계의 순서와 필요성이 실행 중에 바뀐다는 점이다.

한마디로 말하면, 문제의 본질이 "정답을 말하라"에서 "상황을 보며 일을 진행하라"로 넘어가는 순간 에이전트가 등장한다.

좋은 설계는 셋을 섞어 쓴다

현실의 좋은 시스템은 셋 중 하나만 고집하지 않는다. 오히려 가장 실용적인 구조는 대개 조합형이다.

가장 흔한 패턴은 워크플로 안에 RAG를 넣는 방식이다. 예를 들어 고객 문의 분류 후 답변 초안을 만드는 단계에서 관련 정책 문서를 RAG로 읽어 오게 할 수 있다. 이렇게 하면 절차는 안정적으로 유지하면서도, 답변 품질은 문서 기반으로 끌어올릴 수 있다.

그다음으로 흔한 패턴은 에이전트가 RAG를 도구처럼 쓰는 방식이다. 에이전트는 목표를 향해 움직이되, 정보가 필요할 때마다 검색과 문서 조회를 수행한다. 이때 RAG는 에이전트의 눈처럼 동작한다. 에이전트가 혼자 상상하지 않고 실제 자료를 보게 만드는 것이다.

또 다른 중요한 패턴은 에이전트가 탐색하고, 실제 실행은 워크플로가 맡는 구조다. 예를 들어 에이전트가 고객 상황을 분석해 "환불, 교환, 쿠폰 보상" 중 최적 안을 제안할 수 있다. 하지만 실제 환불 실행은 권한과 감사 로그가 붙은 워크플로로 넘기는 식이다. 이 구조는 매우 실용적이다. 유연한 판단과 안정적 실행을 분리할 수 있기 때문이다.

이 조합을 문장으로 정리하면 이렇다. RAG는 정보를 보강하고, 워크플로는 실행을 고정하고, 에이전트는 판단을 유연하게 만든다. 셋을 적절히 나누면 시스템은 덜 똑똑해 보일지 몰라도 훨씬 더 잘 작동한다.

설계 회의에서 바로 쓰는 판단 순서

회의에서 "이걸 에이전트로 만들까요?"라는 말이 나오면, 멋진 데모를 상상하기 전에 순서를 거꾸로 밟아 보는 것이 좋다.

첫째, 이 문제는 신뢰할 수 있는 자료를 읽어 답하는 것만으로 충분한가를 묻는다. 그렇다면 RAG부터 검토하면 된다. 많은 문제는 여기서 끝난다.

둘째, 답변을 넘어 실제 처리까지 필요하다면 그 절차가 대부분 고정되어 있는가를 본다. 그렇다면 워크플로가 우선이다. 규칙과 분기, 예외를 정리하는 편이 자율성보다 더 중요하다.

셋째, 그래도 여전히 경로가 자주 바뀌고 중간 판단이 중요하다면, 그때 에이전트를 고려한다. 이때도 처음부터 완전 자율 구조로 가지 말고, 읽기 권한 위주 도구와 짧은 실행 루프로 시작하는 편이 안전하다.

이 판단 순서를 기억하면, "무조건 에이전트"라는 유행을 피할 수 있다. 좋은 설계자는 가장 화려한 구조가 아니라, 가장 작은 구조로 문제를 푼다.

아주 실용적인 판별 질문

마지막으로, 무엇을 에이전트로 만들고 무엇은 만들지 말아야 하는지 빠르게 가르는 질문을 남겨 두자.

• 정답의 핵심이 이미 문서 안에 있는가?

• 절차를 대부분 미리 그려 놓을 수 있는가?

• 중간 결과에 따라 다음 행동이 자주 달라지는가?

• 시스템이 실제로 바깥세상에 변화를 일으켜야 하는가?

• 그 변화가 되돌리기 어렵거나 위험한가?

첫 번째 질문에 강하게 그렇다면 RAG 쪽에 가깝다. 두 번째에 강하게 그렇다면 워크플로 쪽이 낫다. 세 번째에 강하게 그렇다면 에이전트성이 필요해질 가능성이 크다. 네 번째와 다섯 번째는 권한과 안전 설계를 생각하게 만든다. 행동은 필요하지만 위험하다면, 에이전트가 직접 실행하지 말고 워크플로와 사람 승인을 사이에 두는 편이 맞다.

이 질문들은 정의 놀이가 아니다. 실제로 비용, 실패율, 운영 난이도를 크게 바꾸는 설계 질문이다.

결국 중요한 것은 경계가 아니라 책임이다

이 장에서 우리가 얻어야 할 가장 중요한 감각은, RAG와 워크플로와 에이전트가 서로의 이름을 빼앗는 관계가 아니라는 점이다. 셋은 각자 다른 책임을 진다.

RAG는 모델이 무엇을 근거로 말할지 책임진다. 워크플로는 시스템이 어떤 절차로 움직일지 책임진다. 에이전트는 상황 속에서 다음 행동을 어떻게 고를지 책임진다.

따라서 좋은 설계는 늘 이렇게 묻는다. 이 문제에서 필요한 것은 더 많은 지식인가, 더 단단한 절차인가, 더 유연한 판단인가. 답이 무엇이냐에 따라 구조가 달라진다.

현장에서는 종종 가장 똑똑해 보이는 구조를 고르고 싶어진다. 하지만 제품은 데모가 아니다. 설명만 잘하는 시스템보다, 정확한 문서를 읽는 시스템이 더 유용할 때가 많다. 자율적으로 돌아다니는 시스템보다, 정해진 절차를 착실히 밟는 시스템이 더 믿을 만할 때도 많다. 반대로 정말로 경로가 불확실한 과업에서는, 적당한 자율성을 가진 에이전트가 사람의 시간을 크게 줄여 주기도 한다.

그래서 결론은 의외로 소박하다. RAG는 읽게 하고, 워크플로는 흘려보내고, 에이전트는 판단하게 하라. 그리고 셋을 섞을 때는, 무엇이 지식의 문제이고 무엇이 절차의 문제이며 무엇이 판단의 문제인지 먼저 구분하라.

이 구분이 서면, 이제 다음 단계로 넘어갈 수 있다. 어떤 문제를 에이전트로 만들기로 했다면, 그다음 질문은 자연스럽게 이어진다. 그 에이전트는 하나면 충분한가, 아니면 단계를 쪼개야 하는가. 다음 부에서는 바로 그 설계 원리들을 하나씩 살펴볼 것이다.