6부 27장. AI 에이전트란 무엇인가

이제는 답하는 AI보다 움직이는 AI를 이해해야 한다

앞부분에서 우리는 프롬프트, 컨텍스트, 멀티턴, 워크플로를 살펴봤다. 여기까지 오면 자연스럽게 이런 질문이 생긴다. "그래서 에이전트는 대체 뭐가 다른가?"

요즘은 무엇이든 에이전트라고 부르는 분위기가 있다. 조금 길게 답하면 에이전트, 파일 하나 읽으면 에이전트, 자동화 한 번 돌리면 또 에이전트라고 한다. 하지만 이름이 유행한다고 개념까지 흐려지면 곤란하다. 이 장의 목적은 바로 그것이다. 에이전트라는 말을 멋있게 느끼는 데서 멈추지 않고, 정확히 무엇을 뜻하는지 분명히 잡는 것.

간단히 말하면, AI 에이전트는 주어진 목표를 향해 여러 단계를 스스로 이어 가며, 필요한 도구를 사용하고, 중간 결과를 바탕으로 다음 행동을 결정하는 시스템이다.

중요한 것은 "한 번 답하는가"가 아니라 "목표를 향해 일을 진행하는가"이다. 챗봇이 주로 질문에 답한다면, 에이전트는 그 답을 바탕으로 다음 행동까지 이어 간다. 그래서 에이전트를 이해하려면 문장 생성기라는 관점에서 한 걸음 더 나아가야 한다. 에이전트는 말을 잘하는 AI가 아니라, 과업을 수행하는 AI 시스템에 가깝다.

에이전트의 핵심은 목표, 단계, 도구다

에이전트를 가장 짧게 설명하면 세 단어로 정리할 수 있다. 목표, 단계, 도구다.

먼저 목표가 있어야 한다. "이 문서를 요약해 줘"는 한 번의 요청일 수 있지만, "이 문서들을 비교해서 핵심 쟁점을 정리하고, 회의용 브리핑 초안을 만들어 줘"는 목표에 가깝다. 목표가 생기면 AI는 한 번의 답변으로 끝나기보다, 그 목표를 이루기 위해 무엇을 먼저 하고 무엇을 나중에 할지 생각해야 한다.

그다음은 단계다. 에이전트는 보통 일을 쪼갠다. 자료를 읽고, 필요한 정보를 찾고, 부족한 부분을 확인하고, 초안을 만들고, 다시 점검한다. 사람이 일할 때 "일단 조사부터 하자, 그다음 비교하자, 마지막에 보고서로 정리하자"라고 생각하는 것과 비슷하다.

마지막은 도구다. 도구가 없는 AI는 입으로만 일하는 조언가에 머물기 쉽다. 반면 도구를 쓸 수 있는 AI는 검색을 하고, 파일을 읽고, 코드를 실행하고, 캘린더를 확인하고, 데이터베이스를 조회할 수 있다. 이 순간부터 AI는 단순한 대화 상대가 아니라, 작업 환경 안에서 움직이는 존재가 된다.

즉, 에이전트는 "좋은 문장을 생성하는 모델" 위에 "일을 진행하는 구조"가 얹힌 형태라고 보면 된다.

에이전트는 어떻게 움직이는가

에이전트의 동작을 아주 단순하게 풀어 보면 이런 흐름이다.

사용자가 목표를 준다. 에이전트는 현재 상태를 파악한다. 무엇이 필요한지 생각한다. 적절한 도구를 고른다. 실행한다. 결과를 확인한다. 부족하면 다시 다음 행동을 정한다. 이 과정을 목표에 가까워질 때까지 반복한다.

겉으로 보면 그럴듯한 대화 한 번처럼 보일 수 있지만, 안에서는 작은 루프가 계속 돌아간다. 생각하고, 행동하고, 관찰하고, 다시 판단하는 식이다. 그래서 에이전트는 한 번의 프롬프트라기보다 반복 가능한 실행 구조로 이해하는 편이 맞다.

여기서 중요한 점이 하나 있다. 에이전트는 반드시 완전히 자율적일 필요는 없다. 어떤 에이전트는 중요한 단계마다 사람에게 확인을 받는다. 또 어떤 에이전트는 제한된 범위 안에서만 행동한다. 그러므로 에이전트를 "혼자 모든 걸 다 하는 AI"로만 생각하면 너무 좁게 보게 된다. 핵심은 완전 자율이 아니라, 목표 달성을 위해 여러 행동을 연결하는 능력이다.

좋은 프롬프트와 에이전트는 무엇이 다른가

좋은 프롬프트는 여전히 중요하다. 하지만 아무리 프롬프트를 잘 써도, 한 번의 응답만으로는 해결하기 어려운 일이 있다. 예를 들어 시장 조사를 하려면 자료를 찾고, 비교하고, 중복을 제거하고, 빠진 부분을 확인하고, 최종 형식으로 정리해야 한다. 이때 필요한 것은 예쁜 질문 한 줄이 아니라, 여러 단계를 관리하는 흐름이다.

바로 그 지점에서 에이전트가 등장한다. 프롬프트가 "이렇게 답해 달라"에 가깝다면, 에이전트는 "이 목표를 이루기 위해 다음엔 무엇을 해야 하는가"를 다룬다.

프롬프트가 대화의 단위라면, 에이전트는 작업의 단위다.

프롬프트가 출력의 품질을 좌우한다면, 에이전트는 진행 방식과 실행력을 좌우한다.

프롬프트가 한 번의 장면이라면, 에이전트는 여러 장면이 이어지는 이야기다.

그래서 에이전트 시대에 들어오면 질문을 잘 만드는 것만으로는 부족하다. 이제는 AI가 어떤 순서로 움직이고, 어떤 도구를 쓰며, 어떤 조건에서 멈추고, 언제 사람에게 넘겨야 하는지까지 설계해야 한다.

에이전트는 자동화와도 다르다

여기서 또 하나 헷갈리는 개념이 있다. 자동화와 에이전트의 차이다.

기존 자동화는 보통 규칙이 정해져 있다. 예를 들어 "이 메일이 오면 이 폴더에 저장하고, 슬랙으로 알림 보내기" 같은 흐름은 조건과 행동이 미리 고정되어 있다. 이런 자동화는 매우 유용하지만, 상황을 해석하거나 계획을 바꾸는 능력은 약하다.

에이전트는 좀 더 유연하다. 애매한 요청을 해석할 수 있고, 중간 결과를 보고 다음 행동을 조정할 수 있다. 필요한 정보를 먼저 찾고, 예상과 다른 결과가 나오면 다른 도구를 써 볼 수도 있다. 다시 말해 자동화가 "정해진 길을 빠르게 달리는 열차"라면, 에이전트는 "지도를 보며 경로를 조정하는 운전자"에 가깝다.

물론 현실에서는 이 둘이 섞여 있다. 에이전트 안에 자동화 규칙이 들어갈 수도 있고, 자동화 흐름 중간에 에이전트가 판단을 맡을 수도 있다. 중요한 것은 둘 중 무엇이 더 대단한가가 아니라, 규칙 기반 처리인지, 상황 판단과 도구 선택이 필요한지를 구분하는 일이다.

에이전트를 이루는 기본 부품들

에이전트를 이해할 때는 화려한 이름보다 구성 요소를 보는 편이 낫다. 보통 에이전트는 다음과 같은 부품으로 이루어진다.

첫째, 목표가 있다. 무엇을 끝내야 하는지가 분명해야 한다.

둘째, 상태가 있다. 지금까지 무엇을 했고, 어떤 결과를 얻었는지 기억해야 한다. 이것이 없으면 에이전트는 같은 자리를 빙빙 돌기 쉽다.

셋째, 추론이나 계획이 있다. 지금 무엇을 해야 할지 판단하는 부분이다.

넷째, 도구가 있다. 검색, 파일 읽기, 코드 실행, 메시지 전송처럼 실제 행동을 가능하게 한다.

다섯째, 검토가 있다. 결과가 목표에 맞는지, 오류는 없는지 확인해야 한다.

여섯째, 제한이 있다. 아무 일이나 하게 두면 위험하다. 권한, 범위, 예산, 시간, 승인 조건이 필요하다.

이 부품들을 보면 에이전트가 갑자기 신비한 존재가 아니라는 사실이 드러난다. 결국 에이전트는 "모델 + 컨텍스트 + 도구 + 실행 루프 + 제한 장치"의 조합이다. 이름은 새로워 보여도, 속을 들여다보면 꽤 합리적인 구조물이다.

실제로는 어떤 것이 에이전트인가

예를 들어 보자. "다음 주 고객 미팅 준비해 줘"라는 요청을 받았다고 하자. 단순한 챗봇이라면 준비해야 할 항목을 목록으로 제안해 줄 수 있다. 그것만으로도 도움이 된다.

하지만 에이전트는 그다음으로 나아간다. 관련 문서를 찾고, 지난 회의록을 읽고, 고객사의 최근 이슈를 정리하고, 필요한 브리핑 초안을 만들고, 일정 후보를 캘린더에서 확인하고, 빠진 정보를 다시 묻는다. 즉, 답을 주는 데서 끝나지 않고 준비 과정을 실제로 진행한다.

또 다른 예를 들어 보자. 개발자가 "이 오류를 고쳐 줘"라고 말하면, 일반 챗봇은 원인 후보를 설명할 수 있다. 반면 코딩 에이전트는 로그를 읽고, 관련 파일을 찾고, 테스트를 실행하고, 수정안을 만들고, 다시 테스트를 돌려 결과를 확인할 수 있다. 이것이 바로 행동이 연결된다는 뜻이다.

이처럼 에이전트는 대개 눈에 띄는 한 번의 대답보다, 보이지 않는 중간 단계에서 진가를 드러낸다.

에이전트는 이분법이 아니라 스펙트럼이다

사람들은 종종 이렇게 묻는다. "이건 에이전트예요, 아니에요?" 하지만 현실에서는 딱 잘라 나누기 어렵다. 에이전트성은 정도의 차이가 있기 때문이다.

어떤 시스템은 답변만 한다. 어떤 시스템은 도구를 한 번 쓴다. 어떤 시스템은 여러 단계의 계획을 세운다. 어떤 시스템은 실패를 감지하고 다른 방법을 시도한다. 어떤 시스템은 며칠에 걸친 작업을 이어 간다.

즉, 에이전트는 켜짐과 꺼짐의 문제가 아니라, 얼마나 스스로 과업을 이어 가는가의 문제다. 이 관점이 중요하다. 그래야 제품 소개 문구에 휘둘리지 않고, 실제 기능을 냉정하게 볼 수 있다.

"스스로 목표를 분해하는가?"

"도구를 쓸 수 있는가?"

"중간 결과를 보고 다음 행동을 바꾸는가?"

"검토와 수정 루프가 있는가?"

이 질문에 많이 "예"라고 답할수록 에이전트에 가까워진다.

에이전트를 잘 이해하면 무엇이 달라지는가

에이전트를 이해하면 AI에 대한 기대도 더 현실적이 된다. 괜히 "알아서 다 해 주는 만능 비서"를 기대하지 않게 되고, 반대로 "결국 말만 하는 챗봇 아니냐"라고 과소평가하지도 않게 된다.

무엇보다 사용 방식이 달라진다. 프롬프트 한 문장을 다듬는 데만 매달리기보다, 목표를 어떻게 정의할지, 어떤 도구를 연결할지, 중간 검토를 어디에 넣을지, 실패했을 때 어떻게 복구할지를 생각하게 된다. 이것이 바로 AI 활용이 프롬프트 중심에서 시스템 중심으로 이동했다는 뜻이다.

에이전트는 마법이 아니다. 하지만 단순 대화보다 한 단계 높은 실행 구조인 것은 분명하다. 그리고 앞으로 AI를 잘 쓴다는 말은, 좋은 답변을 얻는 능력만이 아니라 좋은 에이전트 흐름을 설계하고 다루는 능력을 포함하게 될 가능성이 크다.

이 장의 정리

이제 에이전트라는 말이 조금 덜 흐릿해졌을 것이다. 에이전트는 그럴듯한 마케팅 단어가 아니라, 목표를 향해 여러 단계를 수행하고 도구를 사용하며 중간 결과에 따라 다음 행동을 정하는 시스템이다.

핵심은 세 가지다. 첫째, 에이전트는 목표를 가진다. 둘째, 에이전트는 단계를 이어 간다. 셋째, 에이전트는 도구를 사용해 실제로 일을 진행한다.

그래서 에이전트를 이해하는 일은 단지 새 용어 하나를 배우는 일이 아니다. AI를 "대답하는 기계"로 볼 것인지, 아니면 "일을 수행하는 시스템"으로 볼 것인지 관점을 바꾸는 일이다.

다음 장에서는 이 관점을 조금 더 선명하게 만들기 위해, 많은 사람이 가장 헷갈려 하는 질문으로 들어가 보자. 챗봇과 에이전트는 무엇이 다른가?