에이전트란 무엇인가

이 장에서 배울 것

이 장의 목표는 '에이전트'라는 말을 정확히 구분하는 것이다. 많은 서비스가 AI 에이전트라는 이름을 쓰지만, 실제로는 단순 챗봇이거나 검색 기반 답변 시스템인 경우가 많다. 이름을 정확히 붙여야 하는 이유는 단순하다. 무엇을 만들고 있는지에 따라 기술 선택, 권한 설계, 평가 방식이 달라지기 때문이다.

이 장에서는 다음을 배운다.

• 일반 챗봇, RAG 앱, 워크플로, 에이전트의 차이

• 고객지원 사례에서 각 구조가 적합한 문제

• 에이전트 실행 루프의 기본 단계

• 자율성을 0 또는 1이 아니라 정도의 문제로 보는 관점

• 간단한 FAQ agent를 설계하는 방법

먼저 용어를 정리하자.

• LLM 단일 호출: 사용자의 입력을 한 번 모델에 보내고, 한 번 응답을 받는 구조다.

• 챗봇: 대화 인터페이스를 가진 프로그램이다. 반드시 에이전트는 아니다.

• 어시스턴트: 사용자를 돕는 AI 기능을 넓게 부르는 말이다. 제품명이나 역할명에 가깝다.

• RAG: Retrieval-Augmented Generation의 약자다. 외부 문서를 검색한 뒤, 그 내용을 근거로 답변하는 방식이다.

• 워크플로: 정해진 순서대로 작업을 처리하는 흐름이다. 조건문은 있을 수 있지만, 전체 경로는 사람이 미리 설계한다.

• 자동화: 반복 업무를 사람 대신 실행하는 시스템이다. 자동화가 모두 지능적인 것은 아니다.

• 에이전트: 목표를 달성하기 위해 상태를 확인하고, 필요한 도구를 선택해 사용하며, 결과를 관찰한 뒤 다음 행동을 정하는 시스템이다.

핵심은 이것이다. 에이전트는 '말을 잘하는 모델'이 아니다. 에이전트는 목표를 향해 도구를 쓰며 상태를 갱신하는 실행 시스템이다.

왜 이 주제가 중요한가

LLM 앱을 만들 때 가장 흔한 실패는 모든 문제를 에이전트로 풀려고 하는 것이다. 반대로 에이전트가 필요한 문제를 단순 챗봇으로 처리하려다 실패하기도 한다.

예를 들어 고객지원 서비스를 만든다고 하자. 사용자가 이렇게 묻는다.

지난주에 주문한 무선 이어폰을 반품하고 싶어요. 가능한가요?

이 질문에 답하려면 무엇이 필요할까?

단순 정책 설명만 필요하다면 LLM 단일 호출로도 충분할 수 있다. 반품 정책 문서에서 최신 규정을 찾아야 한다면 RAG가 필요하다. 주문일, 배송 상태, 상품 종류를 확인해야 한다면 내부 주문 시스템을 조회해야 한다. 반품 접수까지 진행하려면 권한이 있는 도구 호출이 필요하다. 환불 금액이 크거나 예외 상황이면 사람의 승인이 필요하다.

겉으로는 하나의 질문처럼 보이지만, 실제로는 여러 수준의 시스템 설계가 숨어 있다.

좋은 설계는 복잡한 기술을 많이 쓰는 것이 아니다. 문제에 맞는 최소 구조를 고르는 것이다.

핵심 개념 설명

LLM 단일 호출

LLM 단일 호출은 가장 단순한 구조다. 사용자의 질문을 모델에 전달하고 바로 답변을 받는다.

예를 들어 사용자가 '배송비는 얼마인가요?'라고 물으면 모델은 사전에 제공된 정책을 바탕으로 답할 수 있다. 장점은 구현이 쉽고 빠르다는 점이다. 단점은 최신 정보, 사용자별 데이터, 실제 업무 처리에는 약하다는 점이다.

이 구조는 다음 상황에 적합하다.

• 정적인 안내 문구 생성

• 간단한 문장 변환

• 짧은 요약

• 위험이 낮은 일반 질문 답변

하지만 주문 조회, 환불 처리, 계약서 검토처럼 외부 정보와 행동이 필요한 문제에는 부족하다.

프롬프트 체인

프롬프트 체인은 여러 번의 LLM 호출을 정해진 순서로 연결하는 방식이다. 예를 들어 고객 문의를 다음처럼 처리할 수 있다.

1. 문의 유형을 분류한다.

2. 필요한 정보를 추출한다.

3. 답변 초안을 만든다.

4. 톤을 고객지원 문체로 다듬는다.

여기서 중요한 점은 순서가 미리 정해져 있다는 것이다. 모델이 다음 단계를 자유롭게 고르는 것이 아니라, 개발자가 설계한 흐름을 따른다.

프롬프트 체인은 반복적이고 비교적 안정적인 작업에 좋다. 그러나 상황에 따라 어떤 도구를 쓸지 바뀌거나, 중간 결과에 따라 계획을 수정해야 한다면 에이전트 구조가 더 적합해진다.

RAG 앱

RAG는 문서를 검색해 답변의 근거로 사용하는 구조다. 고객지원에서는 정책 문서, 제품 설명서, 자주 묻는 질문, 장애 공지 등을 검색할 수 있다.

RAG의 강점은 '모델이 기억하고 있는 것'에만 의존하지 않는다는 점이다. 최신 문서를 찾아 답변하고, 필요하면 출처를 함께 보여줄 수 있다.

하지만 RAG만으로는 업무를 실행하지 못한다. 문서를 찾아 '반품 가능 조건'을 알려줄 수는 있지만, 주문 시스템에 접속해 사용자의 실제 주문이 반품 가능한지 확인하거나 반품 접수를 완료하는 것은 별도의 도구가 필요하다.

따라서 RAG는 에이전트의 일부가 될 수 있지만, RAG 자체가 항상 에이전트인 것은 아니다.

워크플로

워크플로는 정해진 절차다. 예를 들어 반품 접수 워크플로는 다음처럼 설계할 수 있다.

1. 주문번호를 입력받는다.

2. 주문 상태를 조회한다.

3. 배송 완료 후 7일 이내인지 확인한다.

4. 미개봉 상품인지 확인한다.

5. 조건을 만족하면 반품 접수를 만든다.

6. 조건을 만족하지 않으면 상담원에게 연결한다.

이런 구조는 예측 가능하고 운영하기 쉽다. 특히 업무 규칙이 명확한 조직에서는 워크플로가 에이전트보다 더 안전할 때가 많다.

다만 사용자의 질문이 다양하고, 어떤 정보를 먼저 확인해야 할지 매번 달라진다면 고정 워크플로만으로는 답답해질 수 있다. 그때 에이전트성이 필요해진다.

도구 사용형 에이전트

도구 사용형 에이전트는 모델이 단순히 답변만 하는 것이 아니라, 필요한 도구를 선택해 호출한다.

고객지원 에이전트가 사용할 수 있는 도구는 다음과 같다.

• 문서 검색 도구

• 주문 조회 도구

• 배송 상태 조회 도구

• 반품 가능 여부 확인 도구

• 티켓 생성 도구

• 상담원 연결 도구

• 승인 요청 도구

에이전트는 사용자의 요청을 이해한 뒤, 현재 상황에 필요한 도구를 고른다. 도구 결과를 확인하고, 정보가 부족하면 후속 질문을 한다. 위험한 작업이면 사람의 승인을 기다린다.

이때 에이전트의 핵심은 '한 번에 정답을 말하는 능력'이 아니다. 핵심은 관찰하고, 판단하고, 다음 행동을 선택하는 반복 구조다.

에이전트 실행 루프

에이전트는 보통 다음 루프를 돈다.

1. 입력 수신

2. 의도 해석

3. 계획

4. 도구 호출

5. 관찰

6. 상태 갱신

7. 최종 응답

각 단계를 고객지원 예시로 살펴보자.

1. 입력 수신

사용자가 요청을 보낸다.

지난주에 산 이어폰 반품하고 싶어요.

입력은 항상 완전하지 않다. 주문번호가 없고, 상품 상태도 알 수 없다. 에이전트는 이 불완전함을 전제로 설계되어야 한다.

2. 의도 해석

에이전트는 사용자의 의도를 파악한다.

• 사용자는 반품을 원한다.

• 상품은 이어폰이다.

• 구매 시점은 지난주다.

• 주문번호는 아직 없다.

• 반품 가능 여부와 절차 안내가 필요하다.

의도 해석은 분류만이 아니다. 필요한 정보와 부족한 정보도 함께 파악해야 한다.

3. 계획

에이전트는 다음 행동을 정한다.

예를 들어 계획은 이렇다.

1. 주문번호 또는 계정 정보를 확인한다.

2. 반품 정책 문서를 검색한다.

3. 주문 상태를 조회한다.

4. 반품 가능 여부를 판단한다.

5. 접수 전 사용자 확인을 받는다.

계획은 길고 복잡할 필요가 없다. 오히려 운영 환경에서는 짧고 검증 가능한 계획이 좋다.

4. 도구 호출

에이전트는 필요한 도구를 호출한다. 예를 들어 문서 검색 도구로 반품 정책을 찾고, 주문 조회 도구로 사용자의 주문 정보를 확인한다.

도구 호출은 에이전트 설계의 핵심이다. 도구 이름, 입력값, 출력 형식이 모호하면 에이전트도 흔들린다. 좋은 도구는 이름만 봐도 역할을 알 수 있고, 실패했을 때 어떤 오류가 발생했는지도 명확해야 한다.

5. 관찰

도구가 결과를 반환하면 에이전트는 그것을 관찰한다.

예를 들어 주문 조회 결과가 다음과 같다고 하자.

• 주문일: 6일 전

• 배송 상태: 배송 완료

• 상품: 무선 이어폰

• 개봉 여부: 확인 필요

에이전트는 이 결과를 그대로 믿고 끝내지 않는다. 정책상 개봉 여부가 중요하다면 사용자에게 확인해야 한다.

6. 상태 갱신

상태는 현재 작업을 진행하는 데 필요한 기억이다. 여기서 말하는 상태는 장기 기억과 다르다. 지금 대화에서 확인한 사실, 아직 모르는 정보, 다음에 해야 할 일을 담는 작업 메모에 가깝다.

예를 들어 상태는 다음처럼 정리할 수 있다.

• 의도: 반품 요청

• 확인된 정보: 주문일 6일 전, 배송 완료, 상품은 무선 이어폰

• 미확인 정보: 개봉 여부, 구성품 보유 여부

• 다음 행동: 개봉 여부 질문

• 위험도: 낮음, 단 접수 전 사용자 확인 필요

상태를 갱신하지 않으면 에이전트는 같은 질문을 반복하거나, 이미 확인한 정보를 잊고 잘못된 결정을 내린다.

7. 최종 응답

마지막으로 에이전트는 사용자에게 답한다.

좋은 응답은 단순히 친절한 문장이 아니다. 확인한 사실, 판단 근거, 필요한 다음 행동을 분명히 말해야 한다.

예를 들어 다음과 같이 답할 수 있다.

주문일과 배송 상태를 확인했습니다. 현재 기준으로 반품 기한은 충족하는 것으로 보입니다. 다만 이어폰은 개봉 여부에 따라 반품 가능 조건이 달라질 수 있습니다. 상품을 개봉하셨나요? 구성품은 모두 보관 중인가요?

이 답변은 무리하게 결론을 내리지 않는다. 확인한 것과 확인하지 못한 것을 구분한다. 이것이 배포 가능한 에이전트의 기본 태도다.

자율성은 스위치가 아니라 조절값이다

에이전트를 설명할 때 '자율적으로 일한다'는 표현을 자주 쓴다. 하지만 자율성은 켜짐과 꺼짐의 문제가 아니다. 정도의 문제다.

같은 반품 요청이라도 여러 방식으로 설계할 수 있다.

마지막 단계가 '더 자율적'이라는 뜻은 아니다. 오히려 운영 환경에서는 자동화 수준이 높아질수록, 위험한 순간에 멈추는 능력도 함께 필요하다. 그래서 자율성을 설계할 때는 두 가지 질문을 함께 던져야 한다.

• 어디까지 자동 실행할 것인가?

• 어떤 조건에서 멈추고 사용자 확인, 사람 승인, 상담원 위임으로 전환할 것인가?

위험이 낮고 규칙이 명확한 작업은 자동 실행해도 된다. 반대로 금전, 법률, 개인정보, 계정 권한이 얽힌 작업은 승인 단계를 넣어야 한다.

좋은 에이전트 설계자는 모델을 얼마나 똑똑하게 만들지보다, 어디까지 자동화하고 어디서 멈출지를 먼저 정한다.

쉬운 비유: 신입 상담사와 업무 시스템

에이전트를 신입 상담사에 비유해 보자.

신입 상담사는 고객의 말을 듣는다. 무엇을 원하는지 파악한다. 모르는 정책은 매뉴얼에서 찾는다. 주문 정보는 내부 시스템에서 조회한다. 판단이 어려우면 선임에게 묻는다. 접수 버튼을 누르기 전에는 고객에게 확인한다.

이 모습은 에이전트와 비슷하다.

• 고객의 말 듣기: 입력 수신

• 요청 파악: 의도 해석

• 처리 순서 정하기: 계획

• 매뉴얼과 시스템 사용: 도구 호출

• 결과 확인: 관찰

• 상담 기록 작성: 상태 갱신

• 안내 또는 접수: 최종 응답과 실행

반대로 단순 챗봇은 매뉴얼 몇 문장을 외운 안내원에 가깝다. RAG 앱은 매뉴얼을 잘 찾아주는 검색 보조자에 가깝다. 워크플로는 정해진 신청서를 순서대로 처리하는 접수 시스템에 가깝다. 에이전트는 이 요소들을 묶어 상황에 맞게 움직이는 작업자에 가깝다.

다만 신입 상담사에게 회사 계좌 이체 권한을 바로 주지 않듯, 에이전트에게도 처음부터 큰 권한을 주면 안 된다. 권한은 작게 시작하고, 로그와 평가를 통해 점진적으로 늘려야 한다.

직접 해보는 실습: 간단한 FAQ agent 설계

이번 실습에서는 고객지원 FAQ agent를 두 가지 버전으로 설계한다. 실제 구현보다 구조를 이해하는 것이 목표다.

실습 목표

• 답변만 하는 FAQ 봇과 도구를 쓰는 FAQ agent의 차이를 비교한다.

• 문서 검색, 출처 확인, 후속 질문이 왜 필요한지 확인한다.

• 상태를 어떻게 기록할지 설계한다.

준비물

다음과 같은 FAQ 문서 5개를 만든다.

1. 배송 기간 안내

2. 반품 가능 조건

3. 환불 처리 기간

4. 제품 보증 기간

5. 고객센터 운영 시간

각 문서는 5~10문장 정도면 충분하다. 단, 일부 조건을 넣어야 한다. 예를 들어 반품 문서에는 '배송 완료 후 7일 이내', '개봉 여부', '구성품 보유' 같은 조건을 넣는다.

버전 A: 답변만 하는 FAQ 봇

구조는 단순하다.

1. 사용자가 질문한다.

2. 모델이 FAQ 내용을 참고해 답한다.

3. 모르면 일반적인 답을 한다.

예시 프롬프트는 다음과 같이 설계할 수 있다.

• 너는 고객지원 FAQ 봇이다.

• 제공된 FAQ에 근거해 답하라.

• 정보가 없으면 확정적으로 말하지 말고 고객센터 문의를 안내하라.

이 버전은 만들기 쉽다. 하지만 사용자의 상황을 확인하지 못한다. 출처가 없으면 어떤 문서에 근거했는지 알기 어렵다. 질문이 불완전할 때 후속 질문을 놓치기 쉽다.

버전 B: 문서 검색과 후속 질문을 수행하는 FAQ agent

이번에는 조금 더 에이전트답게 설계한다.

구성 요소는 다음과 같다.

• 입력 수신기: 사용자 질문을 받는다.

• 의도 분류기: 배송, 반품, 환불, 보증, 운영 시간 중 무엇인지 분류한다.

• 문서 검색 도구: 관련 FAQ 문서를 찾는다.

• 출처 확인 단계: 답변에 사용한 문서명을 기록한다.

• 후속 질문 판단기: 필요한 정보가 부족한지 확인한다.

• 상태 저장소: 확인된 정보와 미확인 정보를 기록한다.

• 응답 생성기: 근거와 다음 행동을 포함해 답한다.

상태는 다음 항목으로 시작하면 충분하다.

• user_intent: 사용자의 의도

• known_facts: 확인된 사실

• missing_info: 부족한 정보

• used_sources: 사용한 문서

• next_action: 다음 행동

• risk_level: 낮음, 중간, 높음

예를 들어 사용자가 '이어폰 반품하고 싶어요'라고 말하면 상태는 다음처럼 정리된다.

• user_intent: 반품 요청

• known_facts: 상품은 이어폰

• missing_info: 주문일, 배송 완료일, 개봉 여부, 구성품 보유 여부

• used_sources: 반품 가능 조건 FAQ

• next_action: 필요한 정보를 질문

• risk_level: 중간

이 agent의 응답은 다음처럼 나와야 한다.

반품 가능 여부는 배송 완료일, 개봉 여부, 구성품 보유 여부에 따라 달라집니다. 반품 조건 문서를 확인한 결과, 배송 완료 후 7일 이내인지와 상품 상태 확인이 필요합니다. 주문일 또는 배송 완료일을 알려주시겠어요? 상품은 개봉하셨나요?

이 답변은 '될 것 같습니다'라고 섣불리 말하지 않는다. 문서에 근거하고, 부족한 정보를 질문한다.

비교 평가

두 버전을 다음 기준으로 비교한다.

실습 결과물로는 다음 세 가지를 제출한다.

1. FAQ 문서 5개

2. 버전 A와 버전 B의 처리 흐름도

3. 같은 질문 3개에 대한 두 버전의 응답 비교표

질문 예시는 다음을 사용한다.

• 배송은 보통 얼마나 걸리나요?

• 지난주에 받은 이어폰을 반품하고 싶어요.

• 환불은 언제 들어오나요?

흔한 실수와 오류 분석

실수 1. 챗봇을 에이전트라고 부른다

대화할 수 있다고 해서 에이전트는 아니다. 도구를 쓰지 않고, 상태를 갱신하지 않고, 다음 행동을 선택하지 않는다면 일반 챗봇에 가깝다.

이름을 과장하면 설계도 흐려진다. 먼저 시스템이 실제로 무엇을 하는지 정의해야 한다.

실수 2. RAG를 붙이면 에이전트라고 생각한다

RAG는 강력하지만 검색 구조다. 문서를 찾아 답변하는 기능과, 목표를 달성하기 위해 여러 도구를 선택하고 실행하는 기능은 다르다.

RAG는 에이전트의 도구가 될 수 있다. 그러나 RAG만으로 반품 접수, 승인 요청, 상태 갱신까지 자동으로 해결되지는 않는다.

실수 3. 처음부터 너무 많은 권한을 준다

초기 에이전트에게 결제 취소, 계정 변경, 대량 발송 같은 권한을 바로 주면 위험하다. 모델이 항상 잘 판단한다고 가정하면 안 된다.

처음에는 조회 권한부터 시작한다. 그다음 초안 생성, 승인 요청, 제한된 실행 순서로 확장한다.

실수 4. 상태를 설계하지 않는다

상태가 없으면 에이전트는 대화의 흐름을 잃는다. 이미 확인한 정보를 다시 묻거나, 부족한 정보를 채우지 않은 채 실행할 수 있다.

상태에는 최소한 의도, 확인된 사실, 부족한 정보, 다음 행동, 위험도를 담아야 한다.

실수 5. 실패 경로를 만들지 않는다

도구 호출은 실패할 수 있다. 문서 검색 결과가 없을 수 있고, 주문 시스템이 응답하지 않을 수 있다. 사용자가 필요한 정보를 주지 않을 수도 있다.

따라서 에이전트는 실패했을 때의 문장을 가져야 한다.

• 지금은 주문 정보를 확인할 수 없습니다.

• 이 경우는 자동 판단이 어렵습니다.

• 상담원에게 연결하겠습니다.

• 추가 정보가 필요합니다.

실패를 숨기지 않는 것이 안전한 에이전트의 기본이다.

실수 6. 평가 없이 느낌으로 배포한다

에이전트가 몇 번 잘 답했다고 바로 배포하면 안 된다. 최소한 대표 질문 세트, 실패 케이스, 위험 케이스를 만들어 테스트해야 한다.

예를 들어 FAQ agent라면 다음을 확인한다.

• 문서에 없는 질문에 모른다고 답하는가?

• 반품 조건이 부족할 때 후속 질문을 하는가?

• 출처 없이 확정 답변을 하지 않는가?

• 승인 필요한 작업을 자동 실행하지 않는가?

이 평가는 뒤에서 tracing과 evals를 다룰 때 더 자세히 살펴본다.

요약

에이전트는 단순히 대화를 잘하는 AI가 아니다. 목표를 이해하고, 필요한 도구를 사용하고, 결과를 관찰하며, 상태를 갱신해 다음 행동을 정하는 시스템이다.

LLM 단일 호출은 간단한 답변에 적합하다. 프롬프트 체인은 정해진 단계가 있는 작업에 적합하다. RAG는 문서 근거가 필요한 답변에 적합하다. 워크플로는 절차가 명확한 업무에 적합하다. 에이전트는 상황에 따라 도구를 선택하고 실행해야 하는 문제에 적합하다.

또한 에이전트의 자율성은 조절해야 한다. 모든 것을 자동으로 실행하는 것이 목표가 아니다. 어떤 일은 자동화하고, 어떤 일은 승인받고, 어떤 일은 사람에게 넘겨야 한다.

배포 가능한 에이전트는 똑똑한 문장보다 안전한 구조에서 나온다.

퀴즈

1. LLM 단일 호출과 에이전트의 가장 큰 차이는 무엇인가?

2. RAG 앱이 에이전트의 일부가 될 수는 있지만, 항상 에이전트는 아닌 이유는 무엇인가?

3. 에이전트 실행 루프의 7단계를 순서대로 적어보라.

4. 반품 접수 업무에서 사람 승인이 필요한 상황을 두 가지 이상 적어보라.

5. FAQ agent의 상태에 들어가야 할 최소 항목은 무엇인가?

정답을 외우기보다, 각 답을 고객지원 사례로 설명할 수 있어야 한다.

체크리스트

이 장을 마쳤다면 다음을 확인하자.

• 일반 챗봇과 에이전트의 차이를 설명할 수 있다.

• LLM 단일 호출, 프롬프트 체인, RAG, 워크플로의 용도를 구분할 수 있다.

• 에이전트 실행 루프를 입력 수신부터 최종 응답까지 설명할 수 있다.

• 상태가 왜 필요한지 예시로 말할 수 있다.

• 자율성을 단계적으로 설계해야 하는 이유를 이해했다.

• FAQ 봇과 FAQ agent의 차이를 실습 흐름으로 정리했다.

• 에이전트가 실패했을 때의 처리 경로가 필요하다는 점을 이해했다.

다음 장 연결

이번 장에서는 에이전트가 무엇인지, 그리고 어떤 문제에 필요한지 살펴보았다. 다음 장에서는 에이전트를 만드는 대표적인 구조를 더 구체적으로 다룬다.

특히 Agent pattern과 workflow pattern을 비교한다. 어떤 문제는 자유도가 있는 에이전트 루프가 필요하고, 어떤 문제는 정해진 워크플로가 더 안전하다. 다음 장의 핵심 질문은 이것이다.

이 업무는 에이전트가 스스로 판단해야 하는가, 아니면 정해진 흐름을 안정적으로 따라야 하는가?

이 질문에 답할 수 있어야 실제 배포 가능한 AI 시스템을 설계할 수 있다.