대다수의 프로젝트는 간단한 스크립트, 반자동 워크플로, 챗봇, RAG, 완전 자율 에이전트 중 무엇을 고르느냐에 따라 좋은 해법이 될지, 과도하게 복잡한 유지보수 지옥이 될지 갈립니다. 이때 선택의 기준으로는 입력의 가변성, 필요한 추론 복잡도, 성능/컴플라이언스 제약, 유지보수 부담이라는 네 가지 핵심 요소를 고려해야 합니다.

선택 1. 간단한 스크립트

우선, 파운데이션 모델이나 머신러닝을 쓰지 않아도 되는 상황이 있습니다. 모든 입력이 완전히 예측 가능하고 모든 출력을 미리 기술할 수 있다면 몇 줄의 절차적 코드가 머신러닝 파이프라인보다 더 빠르고 저렴하며 테스트도 쉽습니다. 

예를 들어 ‘YYYY-MM-DD HH:MM:SS —[메시지]’ 형식을 따르는 로그를 파싱한다면 간단한 정규식 파서(파이썬/Go)로 충분합니다. 

지연시간이 매우 짧아야 할 경우(예: 센서 데이터에 실시간 반응하는 임베디드 시스템)라면 LLM API를 호출할 시간이 없습니다. 특히 의료 기기, 항공, 금융 시스템처럼 규제가 엄격한 도메인에서는 의사결정 과정이 완전히 확정적이고 감사 가능해야 합니다. 

하지만 신경망 모델은 내부 동작을 해석하기 어렵기 때문에 요구사항을 만족시키기 어렵습니다. 즉, 입력의 형태가 정해져 있거나 성능과 설명 가능성을 엄격하게 따져야 하거나 문제의 도메인이 고정되어 있다면 파운데이션 모델보다는 코드를 작성하는 편이 낫습니다.

선택 2. 워크플로

다음은 결정적 또는 반자동 워크플로입니다. 로직을 유한한 단계나 분기로 표현할 수 있고 어디서 인간 개입이나 추가 에러 처리가 필요한지 사전에 아는 경우라면 워크플로를 사용하는 편이 좋습니다. 

예를 들어 소규모 벤더 집단에서 송장을 수집하는데 각 송장이 세 가지 형식중 하나로 도착한다고 가정해봅시다. 형식에 따라 파서를 라우팅하고 불일치를 검사해 문제가 생기면 중지해 인간에게 전달하면 됩니다. 깊은 의미론적 이해는 필요하지 않습니다. 

실패 단계 재시도(지수 백오프)나 관리자 승인 대기 같은 요건도 워크플로 엔진(에어플로, AWS 스텝 펑션, 잘 구조화한 스크립트)이 에러 경로를 더 명확하게 통제할 수 있어 LLM보다 유리합니다. 

모든 결정 분기를 미리 나열할 수 있고 각 분기를 엄격하게 통제해야 한다면 워크플로가 적합합니다. 이런 시나리오에서는 워크플로가 대규모 임시 스크립트보다 자연스럽게 확장되면서도 에이전틱 파이프라인의 복잡성과 비용은 피할 수 있습니다.

선택 3. 챗봇과 RAG

그다음은 챗봇/RAG입니다. 자연어 이해와 문서 검색 기능을 추가하지만 자율적이고 다단계적인 계획 수립까지는 하지 않습니다. 

지식 베이스(knowledge base, 제품 매뉴얼, 법률 아카이브, 사내 위키)를 검색해야 한다면 RAG는 문서를 벡터스토어에 임베딩하고 관련 구절을 찾아 컨텍스트에 맞는 응답을 생성합니다. 

예컨대 IT 헬프데스크는 ‘VPN 자격 증명 초기화 방법’을 질문하면 최신 가이드에서 해당 내용을 찾아 요약해 답합니다. 하지만 자율 에이전트와 달리 RAG는 추가 행동(예: 티켓 발행, 콜백 일정 잡기)을 스스로 결정하지 않습니다. 

문서 기반 Q&A가 주된 목적이고 외부 API 호출이나 의사결정 오케스트레이션이 크게 필요하지 않다면 RAG가 적절합니다. 유지비는 에이전트보다 낮고 구성에는 문서 임베딩 업데이트와 프롬프트 개선이 필요합니다. 그만큼 에이전트의 다단계 계획이나 피드백 루프 학습 능력은 포기해야 합니다.

선택 4. 자율 에이전트

마지막으로 자율 에이전트입니다. 입력이 변동성이 크고 상황에 따라 계획이 바뀌거나 지속적 학습이 필요해 코드나 워크플로, RAG로는 부족한 경우에는 자율 에이전트를 사용해야 합니다. 

예를 들어 고객지원 메일에 ‘노트북 배터리가 부풀어 터질 것 같아요’부터 ‘주문하지 않은 서비스 비용이 계속 청구돼요’까지 다양한 이메일을 받는다면 규칙 기반이나 RAG FAQ는 사용할 수 없습니다. 

반면 파운데이션 모델 기반 에이전트는 의도 파악, 엔티티 추출, 지식 베이스 조회, 적절한 답안 초안 작성, 필요 시 인간 인계까지 사전 정의 없이도 수행합니다. 

공급망에서도 재고나 리드타임, 수요 예측을 실시간으로 받아 동적으로 재계획할 수 있는데 결정적 워크플로는 예외를 처리하려면 수동 업데이트가 끊임없이 필요합니다.

또한 에이전트는 병렬 하위 작업이 많은 환경(예: 보안 운영 에이전트가 동시에 위협 인텔 API 질의, 네트워크 텔레메트리 스캔, 의심 바이너리 샌드박스 분석을 수행)에서 탁월합니다. 

비동기로 실시간 데이터에 맞춰 재우선순위화하므로 ‘한 번에 한 단계’만 수행하는 워크플로와 RAG의 취약성을 피할 수도 있습니다. 

다만 파운데이션 모델의 높은 연산, 운영 비용을 정당화하려면 컨텍스트 추론, 병렬 오케스트레이션, 자가 개선 수준이 필요합니다.

[표 1: 코드, 워크플로, 에이전트의 구분]

모든 선택에는 트레이드오프가 따릅니다. ‘코드’는 저렴하고 빠르지만 경직되어 있고 ‘워크플로’는 통제력이 있지만 입력이 다양하면 쉽게 깨집니다. 

‘챗봇과 RAG’는 문서 Q&A에 뛰어나지만 다단계 오케스트레이션은 못 합니다. ‘에이전트’는 강력하지만 클라우드 비용과 운영 부담(모니터링, 튜닝, 거버넌스)이 큽니다. 

결정 전에 스스로 물어보세요. 

입력이 예측 불가한가? 중간 결과에 적응하는 다단계 계획이 필요한가? 문서 검색으로 충분한가 아니면 스스로 결정하고 실행해야 하나? 최소한의 인간 개입으로 시간이 지날수록 스스로 개선하길 원하나? 지연, 유지보수 부담을 감수할 수 있나?

고정적이고 결정적인 작업은 간단한 코드를 쓰세요. 

분기가 정해져 있고 명시적 에러 처리가 필요하면 워크플로를 쓰세요. 

코퍼스(corpus) 기반 자연어 Q&A가 목적이면 챗봇/RAG를 쓰세요. 

그러나 입력의 변동성이 높거나 개방형 추론, 동적 계획, 지속적 학습이 필요하면 자율 에이전트를 쓰세요.

이런 기준으로 선택하면 단순성, 성능, 적응성의 균형을 잡아 요구가 변해도 효과적이고 유지 가능한 해법을 얻을 수 있습니다.

이 글은 <AI 에이전트 엔지니어링> 도서 내용 일부를 발췌 편집하여 작성되었습니다. AI 에이전트 선택과 설계, 구현까지 보다 깊이 있는 정보는 하기 책에서 만나볼 수 있습니다. 

 『AI 에이전트 엔지니어링』