2023~2024년, 많은 개발자들이 RAG(검색 증강 생성)에 기대를 걸었습니다. LLM에 방대한 인덱스를 연결해두면, 필요한 정보가 자동으로 맥락에 떠오를 거라고요. 하지만 결과는 반대였습니다. 정교한 임베딩과 유사도 검색 대신, 에이전트가 사람처럼 직접 검색하도록 두는 방식이 오히려 더 잘 작동했습니다.
소프트웨어 엔지니어 Sean Goedecke가 LLM을 활용한 프로그램 설계의 두 가지 접근 방식, 파이프라인과 에이전트를 비교 분석한 글을 발표했습니다. 그는 2023년부터 에이전트 방식을 일관되게 주장해온 개발자로, 이 글에서 각 방식의 트레이드오프와 판단 기준을 구체적으로 정리합니다.
출처: Build agents, not pipelines – seangoedecke.com
파이프라인과 에이전트, 무엇이 다른가
LLM을 프로그램에 쓰는 방법은 크게 두 가지입니다. 파이프라인은 코드가 제어 흐름을 쥡니다. 맥락을 수집하고, LLM을 호출하고, 결과를 파싱하고, 다음 단계로 넘기는 순서가 모두 코드에 명시되어 있죠. 에이전트는 반대입니다. LLM에게 도구(tool)를 주고, 어떤 순서로 무엇을 할지는 LLM 스스로 결정하게 합니다.
저자는 이를 라이브러리와 프레임워크의 차이에 빗댑니다. 라이브러리는 개발자가 구조를 짜고 필요할 때 호출합니다. 프레임워크는 구조 자체가 프레임워크 안에 있고, 개발자의 코드를 필요한 시점에 불러씁니다. 파이프라인은 라이브러리 방식, 에이전트는 프레임워크 방식에 가깝습니다.
단순한 작업에서는 둘의 차이가 거의 없습니다. 하지만 맥락이 프롬프트 한 번에 담기지 않을 만큼 크거나, 어떤 행동을 취한 뒤 그 결과에 따라 다음 단계를 결정해야 하는 복잡한 작업에서는 선택이 크게 달라집니다.
파이프라인의 진짜 어려움, 맥락 수집
파이프라인에서 가장 손이 많이 가는 부분은 맥락 수집입니다. LLM이 딱 한 번만 실행되기 때문에, 필요한 정보가 처음부터 모두 프롬프트 안에 들어있어야 합니다. 코딩 보조 도구를 예로 들면, 현재 파일과 관련된 코드 조각이 무엇인지 개발자가 직접 파악해서 컨텍스트로 넣어야 합니다. AST를 분석하거나, 전체 코드베이스를 임베딩으로 인덱싱해서 유사도 검색으로 찾아오는 방식(RAG)이 대표적입니다.
문제는 “어떤 정보가 지금 이 문제와 관련 있는가”를 판단하는 일 자체가 문제를 푸는 것만큼이나 어렵다는 겁니다. 시맨틱 임베딩과 코사인 유사도는 그 판단을 하기엔 충분히 강력한 도구가 아니었습니다. RAG가 기대만큼 작동하지 않은 이유가 여기 있습니다.
에이전트는 이 부분에서 훨씬 유리합니다. “grep”과 “파일 읽기” 도구만 줘도 에이전트가 필요한 맥락을 스스로 찾아갑니다. 개발자가 미리 무엇이 필요할지 예측할 필요가 없습니다.
파이프라인을 선택해야 할 때
에이전트가 유리하다고 해서 항상 답은 아닙니다. 저자는 다음 상황에서는 파이프라인을 권장합니다.
- 비용과 처리 시간을 엄격하게 예측하거나 제한해야 할 때
- 컨텍스트 크기를 작게 유지해야 할 때 (특히 로컬 모델 사용 시)
- 대규모로 반복 실행해야 할 때 (비용이 수백 달러까지 늘어날 수 있는 에이전트는 부적합)
에이전트는 문제의 난이도에 따라 LLM 호출 횟수가 수 회에서 수백 회까지 달라집니다. 규모가 커질수록 비용과 처리 시간의 예측 불가능성이 심각한 문제가 됩니다.
안전성과 미래 대응력
흔히 파이프라인이 에이전트보다 안전하다고 여겨집니다. 하지만 저자는 이 통념에 반박합니다. 프롬프트 인젝션(악의적인 지시가 데이터에 숨어 LLM을 오작동시키는 공격) 같은 보안 위협은 두 방식 모두 동일하게 노출되어 있습니다. 파이프라인이든 에이전트든 외부 데이터를 LLM에 넣는 이상, 입력을 sanitize하고 LLM이 유발하는 행동을 이중 확인하는 작업은 어느 쪽에서도 필수입니다.
미래 대응력에서는 에이전트가 유리합니다. 모델이 발전할수록 에이전트는 더 큰 수혜를 받습니다. 파이프라인 기반 시스템은 새 모델로 교체했을 때 성능이 조금 나아지는 수준이지만, 에이전트 기반 시스템은 훨씬 더 큰 도약이 가능합니다. 지금 당장은 너무 어려운 과제라도, 모델이 충분히 발전하면 해결될 것이라는 가정 하에 에이전트 시스템을 먼저 구축해두는 전략도 유효합니다.
저자는 지난 1년간 파이프라인에서 에이전트로 전환한 프로젝트는 여럿 봤지만, 반대 방향으로 간 경우는 한 건도 보지 못했다고 말합니다.
원문에는 NSA의 이메일 감시 시나리오를 사례로 파이프라인과 에이전트를 병행 운영하는 설계 패턴도 다루고 있으니, 실제 설계 판단이 필요한 분이라면 원문을 직접 확인해보시길 권합니다.
답글 남기기