RAG와 Agent Workflow의 차이

AX 설계를 하다 보면 “이건 RAG로 할 일인가 에이전트로 할 일인가”를 정해야 하는 순간이 온다. 둘 다 모델 혼자서는 부족한 걸 메워주는 방법이라 헷갈리기 쉬운데, 메우는 방식이 꽤 다르다. 이 구분을 분명히 해두면 어떤 루프를 고를지 정한 뒤 그걸 무엇으로 구현할지가 한결 명확해진다.

RAG와 Agent Workflow는 대립하는 선택지가 아니다. RAG는 답하기 전에 맥락을 미리 채워 넣는 방식이고, Agent는 스스로 여러 단계를 밟아 가며 풀어가는 방식이다. 층위가 다르다.

두 방식의 모양

가장 빠른 이해는 흐름을 나란히 놓고 보는 것이다.

RAG(Retrieval-Augmented Generation)는 질문이 들어오면 관련 자료를 검색해 모델의 컨텍스트에 넣어주고, 그 맥락 위에서 한 번 답을 생성한다. 흐름이 직선이라 예측 가능하고, 비용도 대체로 한 번의 검색과 한 번의 생성으로 끝난다. 모델이 모르는 외부 지식·최신 정보를 채우는 데 강하다.

Agent Workflow는 목표를 주면 모델이 스스로 계획을 세우고, 도구를 호출하고, 결과를 관찰해 다음 행동을 정하는 과정을 목표에 닿을 때까지 반복한다. 에이전트를 모는 법에서 다룬 그 루프다. 여러 단계와 결정이 필요한 일을 해낼 수 있지만, 반복마다 모델이 비결정적으로 움직여서 흐름을 예측하기 어렵고 비용도 단계 수만큼 늘어난다.

무엇을 언제 쓰나

선택의 기준은 단순하다. 한 번의 조회로 채울 수 있는 일이면 RAG로 충분하다. 외부 지식을 끌어와 답하면 끝나는 일에 에이전트를 붙이면, 얻는 것 없이 비용과 불확실성만 늘어난다. 반대로 중간 결과에 따라 다음에 무엇을 할지가 달라지는 일, 여러 도구를 순서대로 써야 하는 일이라면 그건 에이전트의 자리다.

흔한 실수는 멋져 보인다는 이유로 단순 조회 작업에 에이전트를 얹는 것이다. 무엇을 안 만들지 정하는 감각이 여기서도 작동한다 — 더 강력한 도구가 늘 더 맞는 도구는 아니다.

대개는 섞인다

마지막으로, 이 둘은 양자택일이 아니다. 실제로는 에이전트가 밟는 한 단계가 RAG인 경우가 흔하다. 에이전트가 “이건 문서를 찾아봐야겠다”고 판단해 검색 도구를 호출하는 그 순간이 RAG다. 그래서 둘을 경쟁 관계로 보기보다, 맥락을 채우는 기본 동작(RAG)과 그걸 포함해 여러 단계를 엮는 구조(Agent)라는 층위 차이로 보는 게 맞다. “RAG냐 Agent냐”가 아니라 “이 일에 단계가 필요한가, 한 번 채우면 되는가”를 먼저 묻는다.