1부 1장. 챗봇을 넘어 에이전트로

우리는 너무 많은 것을 한 단어로 부르고 있다. 요즘은 질문에 답하면 챗봇이고, 조금 친절하면 어시스턴트이며, 도구를 한 번만 불러도 에이전트라고 말하곤 한다. 하지만 이름을 흐리게 붙이면 설계도 흐려진다. 무엇을 만들고 있는지 모르면 어디서 실패하는지도 알 수 없다.

이 장의 목표는 단순하다. 챗봇, 어시스턴트, 워크플로 시스템, 에이전트를 같은 바구니에 넣지 않고, 서로 다른 시스템으로 구분해 보는 것이다. 특히 목표, 자율성, 행동 가능성이라는 세 가지 관점으로 보면, 유행어처럼 보이던 "에이전트"가 꽤 또렷한 시스템 개념으로 바뀐다.

이름이 중요한 이유

개발 현장에서 가장 흔한 오해는 이것이다. "LLM이 들어갔으니 에이전트다." 하지만 모델이 문장을 잘 만든다는 사실과, 시스템이 스스로 일을 추진한다는 사실은 전혀 다르다. 답변을 잘하는 것과 일을 해내는 것은 한 끗 차이처럼 보이지만, 실제로는 설계 철학이 다르다.

예를 들어 고객센터용 질의응답 시스템을 만든다고 해 보자. 사용자의 질문에 적절한 답을 한 번 주면 끝나는 경우가 있다. 이때 필요한 것은 대개 좋은 검색과 좋은 답변 생성이다. 반면 출장 예약을 대신 처리하는 시스템이라면 이야기가 달라진다. 일정 확인, 항공편 탐색, 비용 정책 검토, 예약, 결과 보고까지 이어지는 여러 단계가 필요하다. 이 시스템은 단순히 말만 잘해서는 안 된다. 상태를 기억하고, 도구를 사용하고, 중간 결과를 검토하며, 필요하면 방향을 바꿔야 한다.

즉, "무엇을 말하느냐"만 중요한 시스템과 "무엇을 하느냐"가 중요한 시스템은 구분해야 한다. 바로 그 경계에서 에이전트라는 개념이 등장한다.

먼저, 네 가지를 한 장면에 세워 보자

헷갈리지 않게 네 가지를 나란히 놓아 보자. 모두 AI를 활용할 수 있지만, 작동 방식은 다르다.

이 표만 보면 간단해 보이지만, 실제 차이는 세 가지 질문에서 선명해진다.

첫째, 시스템은 무엇을 목표로 하는가. 둘째, 그 목표를 이루는 과정에서 스스로 얼마나 판단하는가. 셋째, 말만 하는가, 아니면 세상에 실제 변화를 일으키는 행동까지 하는가.

챗봇은 대화의 기계다

챗봇은 가장 익숙한 형태다. 사용자가 말을 걸면, 시스템이 그에 맞는 답을 돌려준다. 본질은 대화다. 챗봇의 중심은 "다음 응답을 얼마나 자연스럽고 유용하게 만들 것인가"에 있다.

좋은 챗봇은 친절하다. 맥락을 어느 정도 이어 가고, 질문 의도를 파악하고, 말투도 적절하다. 하지만 대체로 여기까지다. 챗봇은 보통 스스로 일을 시작하지 않는다. 사용자가 묻지 않으면 움직이지 않고, 목표를 장기적으로 추적하지도 않는다.

예를 들어 사내 정책을 안내하는 챗봇은 "재택근무 신청 절차가 뭐예요?"라는 질문에 답할 수 있다. 하지만 사용자의 팀, 직급, 최근 신청 이력, 부서 승인 규칙을 살펴서 실제 신청서를 작성하고 결재를 올리는 일까지 맡는다면, 그때부터는 단순한 챗봇을 넘어선다.

챗봇의 장점은 명확하다. 구조가 단순하고, 실패 범위가 비교적 좁다. 잘못 답하면 문제가 되지만, 잘못 행동하는 시스템보다는 통제하기 쉽다. 그래서 많은 서비스의 첫 단계는 챗봇으로 시작한다.

어시스턴트는 대화보다 한 걸음 더 나간다

어시스턴트는 챗봇보다 적극적이다. 사용자의 일을 덜어 주는 쪽으로 설계된다. 여전히 주도권은 사용자에게 있지만, 시스템은 단순 답변을 넘어 정리, 추천, 요약, 초안 작성 같은 보조 작업을 수행한다.

여기서 중요한 점은 어시스턴트가 "행동"을 하더라도 그 범위가 제한적인 경우가 많다는 것이다. 예를 들어 이메일 초안을 써 주고, 회의 내용을 요약하고, 보고서 뼈대를 잡아 주는 일은 할 수 있다. 하지만 실제 발송, 승인, 결제처럼 되돌리기 어려운 행동은 보통 사용자의 확인을 거친다.

즉 어시스턴트는 사용자의 손을 덜어 주되, 운전대는 완전히 가져가지 않는다. 옆자리에서 지도를 봐 주는 조수석에 가깝다. 운전은 아직 사람이 한다.

그래서 많은 제품이 자신을 "AI 어시스턴트"라고 부른다. 이 이름에는 꽤 정직한 뜻이 있다. 사용자를 대신해 전 과정을 자율적으로 처리한다기보다, 사용자의 의사결정을 돕고 일부 단계를 가볍게 만든다는 뜻이다.

워크플로 시스템은 생각보다 똑똑하지 않아도 강하다

워크플로 시스템은 자주 과소평가된다. 하지만 실무에서는 가장 강력한 방식 중 하나다. 워크플로의 핵심은 "무엇을 할지 미리 정해 두고 그대로 실행하는 것"이다.

예를 들어 주문이 들어오면 결제를 확인하고, 재고를 차감하고, 송장 번호를 만들고, 고객에게 알림을 보내는 과정이 있다고 하자. 이 절차는 분기와 예외가 있을 수는 있어도, 전체 구조는 미리 설계되어 있다. 시스템은 스스로 목표를 새로 정의하지 않는다. 이미 주어진 절차를 안정적으로 수행한다.

흥미로운 점은, 워크플로 시스템은 행동 가능성이 높을 수 있다는 사실이다. 실제로 이메일을 보내고, 데이터베이스를 갱신하고, 외부 API를 호출할 수 있다. 그런데도 에이전트는 아닐 수 있다. 이유는 자율성이 거의 없기 때문이다. 잘 짜인 기차 선로를 따라 빠르게 달리지만, 어디로 가야 할지 스스로 결정하지는 않는다.

이 차이를 놓치면 모든 자동화를 에이전트라고 부르게 된다. 하지만 정해진 절차를 실행하는 시스템과, 상황을 보고 경로를 바꾸는 시스템은 설계도와 운영 방식이 크게 다르다.

에이전트는 목표를 향해 스스로 움직이는 시스템이다

이제 에이전트를 보자. 에이전트는 단순히 대답하는 시스템이 아니다. 주어진 목표를 이루기 위해 현재 상태를 파악하고, 다음 행동을 고르고, 필요하면 도구를 사용하며, 중간 결과를 보고 방향을 수정하는 시스템이다.

여기서 핵심은 "목표 지향성"과 "루프"다. 에이전트는 한 번 응답하고 끝나지 않을 수 있다. 계획하고, 실행하고, 관찰하고, 다시 계획하는 흐름을 가진다. 그래서 에이전트는 종종 조금 끈질기다. 목표를 끝낼 때까지 다음 수를 찾으려 한다.

예를 들어 "경쟁사 세 곳의 최근 가격 정책을 조사해서 비교표를 만들고, 우리 제품의 대응 전략 초안을 써 줘"라는 요청을 생각해 보자. 챗봇은 일반론을 답할 수 있고, 어시스턴트는 비교표 양식을 만들어 줄 수 있다. 워크플로 시스템은 미리 정한 소스만 모아 표를 채울 수 있다. 하지만 에이전트라면 자료를 찾고, 필요한 정보를 골라 정리하고, 빠진 부분을 추가로 확인하고, 최종 결과를 구성하는 식으로 여러 단계를 오가며 목표에 접근할 수 있다.

중요한 것은 에이전트가 "마법처럼 모든 것을 한다"는 뜻이 아니라는 점이다. 오히려 에이전트는 잘 설계된 제한 속에서 움직여야 한다. 목표는 분명해야 하고, 사용할 수 있는 도구도 정해져 있어야 하며, 실패했을 때 멈추는 조건도 있어야 한다. 자유가 많다고 좋은 에이전트가 되는 것은 아니다. 적절한 자유를 가진 시스템이 좋은 에이전트다.

세 가지 축으로 구분하면 훨씬 선명해진다

이제 목표, 자율성, 행동 가능성이라는 세 축으로 다시 정리해 보자.

목표: 무엇을 위해 존재하는가

챗봇의 목표는 주로 "좋은 응답"이다. 사용자가 묻는 말에 적절히 답하는 것이 끝이다.

어시스턴트의 목표는 "사용자의 과업을 보조하는 것"이다. 답변을 넘어 초안 작성, 정리, 추천까지 포함되지만, 여전히 사용자의 지시가 중심이다.

워크플로 시스템의 목표는 "정해진 절차를 정확히 실행하는 것"이다. 효율성과 일관성이 가장 중요하다.

에이전트의 목표는 "주어진 결과를 달성하는 것"이다. 그래서 결과에 도달하기 위한 중간 단계가 바뀔 수 있다. 목표는 같지만 경로는 유동적이다.

자율성: 누가 다음 행동을 결정하는가

챗봇은 거의 항상 사용자의 질문에 반응한다. 다음 차례를 먼저 꺼내기 어렵다.

어시스턴트는 약간 더 적극적일 수 있다. 예를 들어 "원하시면 이 내용을 메일 초안으로 바꿔 드릴까요?" 정도의 제안을 할 수 있다. 하지만 주도권은 아직 제한적이다.

워크플로 시스템은 자율성이 아니라 규칙성이 강하다. 다음 행동은 시스템이 정하지만, 그 결정은 미리 짜인 규칙에 따른 것이다. 상황 판단의 폭이 넓지 않다.

에이전트는 목표와 상태를 바탕으로 다음 행동을 선택한다. 검색을 먼저 할지, 파일을 읽을지, 사용자에게 추가 질문을 할지, 혹은 이미 충분하다고 판단하고 종료할지 스스로 결정할 수 있다.

행동 가능성: 말에서 끝나는가, 세상을 바꾸는가

챗봇은 대개 말에서 끝난다. 텍스트 응답이 주된 산출물이다.

어시스턴트는 제한된 행동을 한다. 문서를 작성하거나, 일정 제안을 만들거나, 버튼을 누르기 직전 상태까지 준비한다.

워크플로 시스템은 실제 행동을 매우 잘한다. 다만 그 행동은 설계자가 미리 허락한 경로 안에 있다.

에이전트는 행동 가능성이 높다. 다만 중요한 것은 "행동할 수 있다"가 아니라 "상황에 맞게 행동을 선택할 수 있다"는 점이다. 도구를 쓴다는 사실만으로는 부족하다. 도구 사용을 포함한 판단 구조가 있어야 에이전트다.

같은 요청을 네 시스템에 던져 보면 차이가 드러난다

다음 요청을 생각해 보자.

"다음 주 고객 미팅을 준비해 줘."

챗봇은 이렇게 반응할 가능성이 높다. 미팅 준비 체크리스트를 알려 주고, 발표 자료에 넣을 항목을 제안하고, 예상 질문 목록을 적어 준다. 유용하지만, 어디까지나 조언이다.

어시스턴트는 한 걸음 더 나아간다. 지난 미팅 메모를 요약하고, 발표 자료 초안을 만들고, 메일 문안을 작성해 줄 수 있다. 그래도 실제 일정 조정이나 자료 수집은 사용자의 승인이나 추가 지시를 기다릴 가능성이 크다.

워크플로 시스템은 미리 정한 절차가 있다면 강력하다. CRM에서 고객 정보를 읽고, 최근 이슈를 가져오고, 표준 템플릿에 맞춰 브리핑 문서를 자동 생성할 수 있다. 하지만 고객이 평소와 다르게 행동하거나 예외 상황이 생기면, 준비된 가지치기 안에서만 대응할 수 있다.

에이전트는 목표를 "미팅 준비 완료"로 놓고 접근한다. 필요한 자료가 무엇인지 판단하고, 부족한 정보를 찾고, 일정과 관련자를 확인하고, 누락된 점이 있으면 질문하고, 결과물을 종합한다. 필요하면 검색 후 요약하고, 고객 이력을 비교하고, 발표용 초안과 예상 질의응답까지 연쇄적으로 준비할 수 있다.

같은 요청인데도 시스템이 바라보는 방식이 다르다. 챗봇은 대화로 돕고, 어시스턴트는 작업을 보조하며, 워크플로는 정해진 절차를 실행하고, 에이전트는 목표 달성을 위해 경로를 구성한다.

"도구를 쓰면 에이전트다"라는 오해

많은 사람이 도구 호출 기능을 보면 곧바로 에이전트라고 생각한다. 하지만 도구 사용은 필요조건일 수 있어도 충분조건은 아니다.

예를 들어 사용자가 "오늘 환율 알려 줘"라고 묻자 시스템이 환율 API를 한 번 호출해서 값을 보여 준다고 하자. 이것은 도구를 쓰는 챗봇일 수 있다. 왜냐하면 목표가 단일 응답에 가깝고, 자율적 계획이나 반복적 실행 루프가 없기 때문이다.

반대로 도구를 거의 쓰지 않더라도 에이전트적 성격을 띨 수 있는 경우가 있다. 긴 문서를 분석해 논리적 허점을 찾고, 검토 기준에 따라 여러 차례 자기 점검을 하며 결과를 개선하는 시스템은 외부 행동은 적어도 내부적으로 목표 지향적 루프를 가질 수 있다.

즉, 에이전트를 판단할 때는 "도구를 쓰는가?"보다 "목표를 향해 스스로 다음 행동을 선택하는가?"를 먼저 물어야 한다.

에이전트가 아닌데 에이전트처럼 보이는 경우

실무에서는 특히 세 가지가 자주 헷갈린다.

첫째는 포장만 에이전트인 경우다. 사용자 인터페이스가 대화형이고 말투가 똑똑하면 사람들은 쉽게 에이전트라고 느낀다. 하지만 내부를 보면 단일 프롬프트와 단일 응답뿐일 수 있다.

둘째는 워크플로를 에이전트라고 부르는 경우다. 분기와 자동화가 많고 외부 시스템도 많이 연결되어 있으면 굉장히 자율적으로 보인다. 그러나 모든 경로가 사람이 미리 설계한 것이라면, 그것은 여전히 워크플로다.

셋째는 에이전트가 필요한데 챗봇으로 버티는 경우다. 여러 단계의 과업을 한 번의 답변으로 해결하려다 보니, 시스템이 장황하게 설명만 하고 실제 진척은 없는 상태가 된다. 사용자는 "똑똑한데 답답하다"는 느낌을 받는다.

이 세 가지 혼동은 제품 전략에도 영향을 준다. 챗봇이면 충분한데 복잡한 에이전트를 만들면 운영 비용과 실패 위험만 커진다. 반대로 에이전트가 필요한 문제를 단순 챗봇으로 풀려고 하면 사용자는 결국 사람에게 다시 돌아간다.

좋은 질문: 이 시스템은 어디까지 책임지는가

시스템 유형을 구분할 때 가장 실용적인 질문은 이것이다.

"이 시스템은 어디까지 책임지는가?"

챗봇은 대체로 정보 제공까지 책임진다. 그 다음 행동은 사람 몫이다.

어시스턴트는 준비 작업까지 책임질 수 있다. 그러나 결정과 최종 실행은 종종 사람에게 남겨 둔다.

워크플로 시스템은 정해진 절차의 완료까지 책임진다. 대신 절차 밖의 판단은 약하다.

에이전트는 목표의 달성 가능성까지 책임지려 한다. 물론 실제 서비스에서는 안전 때문에 책임 범위를 제한해야 하지만, 기본 태도 자체가 다르다. 에이전트는 "여기까지 답했습니다"보다 "이 목표를 끝내기 위해 다음에 무엇을 해야 하지?"라고 생각하는 시스템이다.

이 차이를 이해하면 제품 요구사항도 달라진다. 챗봇에는 주로 답변 품질과 검색 품질이 중요하다. 워크플로에는 분기 규칙과 예외 처리가 중요하다. 에이전트에는 상태 관리, 도구 사용, 실행 루프, 중간 검증, 실패 복구가 중요해진다. 설계 포인트가 달라지는 것이다.

에이전트는 더 똑똑한 챗봇이 아니라, 다른 구조다

에이전트를 챗봇의 업그레이드 버전으로 생각하면 핵심을 놓친다. 에이전트의 본질은 더 긴 답변이나 더 자연스러운 말투가 아니다. 구조가 다르다.

챗봇의 중심은 응답 생성이다. 워크플로의 중심은 절차 실행이다. 에이전트의 중심은 관찰, 판단, 행동의 반복이다. 다시 말해, 에이전트는 문장 생성기 위에 얹힌 작은 운영체제에 가깝다.

그래서 에이전트를 설계할 때는 모델 성능만 볼 수 없다. 현재 상태를 어떻게 저장할지, 어떤 도구를 언제 허용할지, 중간 판단을 어떻게 검증할지, 실패하면 어디서 멈출지까지 함께 설계해야 한다. 다음 장들에서 계속 다룰 모델, 상태, 도구, 실행 루프가 바로 이 지점에서 중요해진다.

언제 챗봇이면 충분하고, 언제 에이전트가 필요한가

모든 문제에 에이전트가 필요한 것은 아니다. 오히려 많은 문제는 챗봇이나 워크플로로 더 잘 풀린다.

사용자가 한 번 묻고 한 번 답하면 되는 정보형 문제라면 챗봇이 적합하다. 규칙이 명확하고 절차가 안정적이라면 워크플로가 강하다. 사람의 생산성을 높이는 보조 기능이 목표라면 어시스턴트가 알맞다.

에이전트가 필요한 순간은 보통 이런 때다. 목표를 달성하려면 여러 단계를 거쳐야 하고, 중간에 어떤 행동이 필요한지 미리 완전히 정해 두기 어렵고, 외부 도구나 정보원을 상황에 따라 선택해야 하며, 결과가 나올 때까지 반복적인 판단이 필요할 때다.

간단히 말해, 문제의 본질이 "좋은 답변"이 아니라 "유연한 수행"으로 옮겨갈 때 에이전트가 등장한다.

현장에서 바로 써먹는 판별법

회의에서 누군가 "이걸 에이전트로 만들죠"라고 말하면, 다음 네 가지를 물어보면 된다.

• 이 시스템의 최종 목표는 무엇인가?

• 목표를 이루는 중간 단계가 매번 달라질 수 있는가?

• 시스템이 스스로 다음 행동을 고를 수 있는가?

• 말이 아니라 실제 행동이나 상태 변경까지 수행하는가?

네 질문 가운데 앞의 세 개가 강하게 그렇다고 답된다면, 에이전트일 가능성이 높다. 반대로 목표가 단일 응답이고, 경로가 고정되어 있고, 행동이 없거나 제한적이라면 챗봇·어시스턴트·워크플로 쪽에 더 가깝다.

이 판별법은 완벽한 정의는 아니지만 매우 실용적이다. 이름을 붙이기 위한 체크리스트가 아니라, 시스템 구조를 제대로 선택하기 위한 질문이기 때문이다.

이제 우리는 무엇을 배워야 하는가

이 장에서 가장 중요한 메시지는 하나다. 에이전트는 유행어가 아니라 시스템 개념이라는 점이다. 챗봇과 어시스턴트, 워크플로와 에이전트는 겉으로 비슷해 보여도, 목표와 자율성과 행동 방식이 다르다.

이 차이를 구분하는 순간 설계의 시야가 넓어진다. 왜 어떤 제품은 멋지게 말만 하고 끝나는지, 왜 어떤 시스템은 단순하지만 강력한지, 왜 어떤 경우에는 자율성이 오히려 독이 되는지도 이해하게 된다.

앞으로 우리는 에이전트를 더 작은 단위로 분해해 볼 것이다. 결국 에이전트란 갑자기 하늘에서 떨어진 마법 상자가 아니라, 모델이 있고, 상태가 있고, 도구가 있고, 그것들을 엮는 실행 루프가 있는 시스템이기 때문이다.

다음 장에서는 바로 그 최소 단위를 다룬다. 에이전트를 신비한 존재로 보지 않고, 설계 가능한 구조로 보기 시작하면 비로소 만들 수 있다.