AI 에이전트를 잘 쓰려면, 먼저 그럴듯한 겉모습보다 안쪽의 흐름을 알아야 한다. 채팅창에서는 한 번에 대답이 튀어나오는 것처럼 보이지만, 내부에서는 보통 더 바쁜 일이 벌어진다. 에이전트는 목표를 받고, 주변 정보를 읽고, 다음 행동을 정하고, 도구를 써서 실제 일을 해본 뒤, 결과를 다시 확인한다. 그리고 필요하면 방향을 바꾼다.12
이 구조를 이해하면 두 가지가 달라진다. 하나는 에이전트를 훨씬 잘 시킬 수 있다는 점이다. 다른 하나는 결과를 맹신하지 않게 된다는 점이다. 말이 매끄럽다고 해서 과정까지 완벽한 것은 아니기 때문이다. 에이전트는 생각하는 기계이기도 하지만, 동시에 시도하고, 실패하고, 다시 맞추는 시스템이기도 하다.13
에이전트의 기본 동작은 하나의 루프다
가장 먼저 붙잡아야 할 그림은 복잡한 기술 용어가 아니라 아주 단순한 반복이다. 에이전트는 대체로 관찰하고, 판단하고, 행동하고, 확인하는 루프로 움직인다.13
예를 들어 사용자가 이렇게 말한다고 해보자.
"다음 주 경쟁사 동향 회의용 브리핑을 만들어줘."
겉으로는 한 문장이지만, 에이전트 입장에서는 바로 여러 단계로 바뀐다.
목표를 해석한다. 경쟁사 동향, 회의 일정, 원하는 산출물의 형태를 파악한다.
현재 상황을 관찰한다. 지난주 보고서, 관련 문서, 웹 검색 결과, 일정 정보 같은 재료를 모은다.
계획을 세운다. 어떤 회사를 먼저 볼지, 어떤 기간의 뉴스를 볼지, 요약만 할지 발표 초안까지 만들지 정한다.
행동한다. 검색 도구를 쓰고, 문서를 읽고, 정리하고, 초안을 만든다.
결과를 확인한다. 출처가 부족한지, 최신성이 떨어지는지, 빠진 항목이 있는지 점검한다.
부족하면 다시 돈다. 검색을 더 하거나, 다른 도구를 쓰거나, 사람에게 확인을 요청한다.
이 흐름이 중요한 이유는, 에이전트가 한 번의 "정답 생성"으로 끝나는 시스템이 아니라는 점을 보여주기 때문이다. 잘 만든 에이전트는 한 번 말하고 끝나는 것이 아니라, 중간 결과를 보고 다음 행동을 조정한다.13
모델은 두뇌지만, 에이전트 전체는 아니다
많은 사람이 에이전트를 거대한 언어 모델 하나로 생각한다. 반은 맞고 반은 틀리다. 모델은 분명 핵심이다. 사용자의 말을 이해하고, 정보를 엮고, 다음 행동을 추론하는 데 모델이 중심 역할을 한다. 하지만 모델 하나만으로는 에이전트가 되지 않는다.13
보통의 LLM은 본질적으로 입력을 바탕으로 다음 출력을 생성하는 엔진에 가깝다. 질문을 받으면 답을 만들고, 그 요청이 끝나면 사실상 작업도 끝난다. 스스로 캘린더를 열어보지도 못하고, 메일을 보내지도 못하고, 지난달 당신이 어떤 형식을 좋아했는지 저절로 기억하지도 못한다.14
에이전트는 이 모델 위에 여러 층을 덧씌운 구조다. 쉽게 비유하면 이렇다.
모델은 생각하는 두뇌다.
도구는 손과 발이다.
메모리는 노트와 기록장이다.
계획과 실행 루프는 일 처리 방식이다.
그래서 에이전트의 품질을 볼 때는 "모델이 얼마나 똑똑한가"만 보면 부족하다. 어떤 도구를 쓸 수 있는지, 무엇을 기억하는지, 실패했을 때 다시 시도하는지까지 함께 봐야 한다. 결과의 수준은 종종 모델보다 주변 설계에서 갈린다.34
도구는 에이전트를 말 잘하는 존재에서 일하는 존재로 바꾼다
에이전트가 실제로 일을 하려면 외부 세계와 연결되어야 한다. 이 연결 통로가 바로 도구다. 도구는 검색 API일 수도 있고, 사내 데이터베이스 조회 기능일 수도 있고, 메일 발송이나 캘린더 등록 기능일 수도 있다.13
여기서 핵심은 "도구를 안다"와 "도구를 쓴다"가 다르다는 점이다. 모델이 항공권 예약 절차를 설명할 수는 있어도, 실제 항공권 검색 API를 호출하지 못하면 예약을 진행할 수는 없다. 반대로 도구가 연결되면 이야기가 달라진다. 에이전트는 필요한 매개변수를 만들어 도구를 호출하고, 그 결과를 다시 읽은 뒤 다음 행동을 정할 수 있다.3
사용자 입장에서는 이 차이가 꽤 현실적이다. 같은 "출장 준비해줘"라는 요청이라도, 도구가 없는 시스템은 체크리스트를 줄 가능성이 크다. 도구가 있는 에이전트는 일정 확인, 비용 규정 조회, 교통편 비교, 메일 초안 작성까지 이어질 수 있다. 즉, 도구는 에이전트의 능력을 넓히는 장식이 아니라, 에이전트가 세상에 손을 뻗는 방식 그 자체다.1
하지만 도구가 많다고 무조건 좋은 것은 아니다. 에이전트가 할 수 있는 일의 폭이 넓어지는 만큼, 잘못할 수 있는 일의 폭도 넓어진다. 메일 발송 권한이 있다면 잘못된 사람에게 보낼 수도 있고, 데이터 수정 권한이 있다면 틀린 값을 저장할 수도 있다. 그래서 어떤 에이전트든 "무슨 도구를 쓰는가"만큼이나 "어디까지 허용되는가"가 중요하다.6
메모리는 단순한 채팅 기록보다 훨씬 넓다
에이전트 이야기를 들을 때 자주 등장하는 단어가 메모리다. 이 말을 너무 신비롭게 받아들일 필요는 없다. 메모리는 결국 지금 필요한 맥락을 붙잡아 두고, 나중에도 꺼내 쓸 수 있게 하는 장치다.45
가장 쉬운 구분은 두 가지다. 하나는 지금 대화에서만 쓰이는 짧은 기억이고, 다른 하나는 여러 번의 대화와 작업을 넘어 남는 긴 기억이다.45
짧은 기억은 현재 작업을 이어가기 위한 임시 메모에 가깝다. 방금 사용자가 "부산 말고 대전으로 바꿔줘"라고 했을 때, 에이전트가 그 변경 사항을 놓치지 않고 다음 단계에 반영하는 데 필요하다. 긴 기억은 더 오래 남는다. 예를 들어 사용자가 늘 표 형식을 선호한다거나, 회사가 출장 예약 전에 반드시 팀장 승인을 받아야 한다는 규칙 같은 것이 여기에 들어갈 수 있다.45
조금 더 세밀하게 보면 메모리에는 여러 얼굴이 있다.
작업 메모리는 지금 당장 계산과 판단에 필요한 핵심만 잡아둔다.
장기 메모리는 사용자 선호나 자주 쓰는 규칙처럼 다음 세션에도 도움이 되는 정보를 남긴다.
에피소드 메모리는 이전에 어떤 시도를 했고 무엇이 실패했는지를 기록해 다음 행동에 반영한다.4
중요한 점은, 메모리가 있다고 해서 언제나 정확한 것은 아니라는 사실이다. 오래된 정보가 남아 있을 수도 있고, 잘못 저장된 내용이 다음 판단을 흐릴 수도 있다. 그래서 실제 시스템에서는 메모리를 갱신하고, 통합하고, 필요하면 만료시키는 장치가 함께 들어간다. 사용자별로 기억을 분리하고, 관련성이 높은 기억만 꺼내 오며, 너무 오래된 정보는 정리하는 식의 관리가 필요하다.56
사용자 입장에서는 여기서 한 가지를 꼭 기억하면 좋다. "기억한다"는 말은 "항상 맞게 기억한다"는 뜻이 아니다. 에이전트의 기억도 관리 대상이다.
계획은 큰 일을 작은 일로 바꾸는 기술이다
에이전트가 일을 잘하는 순간은 대개 처음부터 모든 답을 알고 있어서가 아니다. 대신 큰 목표를 작은 단계로 쪼개기 때문에 움직일 수 있다. 이것이 계획이다.23
예를 들어 "3일짜리 제주 가족여행 계획 세워줘"라는 요청은 얼핏 간단해 보인다. 하지만 실제로는 교통, 숙소, 일정, 예산, 취향, 아이 동반 여부처럼 여러 하위 문제로 갈라진다. 계획이 있는 에이전트는 이 목표를 바로 받아 적는 대신, 먼저 어떤 하위 작업이 필요한지 정리한다. 비행편을 볼지, 숙소를 먼저 볼지, 예산 상한을 먼저 확인할지 순서를 세우는 식이다.2
모든 에이전트가 같은 방식으로 계획하지는 않는다. 어떤 에이전트는 한 걸음씩 가면서 그때그때 다음 행동을 정한다. 상황 변화에 민첩하지만, 멀리 내다보는 데는 약할 수 있다. 또 어떤 에이전트는 먼저 전체 설계를 대강 세운 뒤 실행에 들어간다. 긴 작업에는 유리하지만, 중간에 상황이 바뀌면 다시 계획을 고쳐야 한다.23
사용자에게 중요한 것은 이 차이를 체감하는 법이다. 간단한 작업에서 에이전트가 너무 오래 머뭇거리면 과한 계획일 수 있다. 반대로 복잡한 작업인데도 곧바로 행동부터 시작하면, 나중에 빠진 단계가 생길 수 있다. 좋은 에이전트는 목표의 크기와 위험도에 맞춰 계획의 깊이를 조절한다.
실행은 한 번의 점프가 아니라 여러 번의 발걸음이다
계획이 세워졌다고 해서 끝난 것은 아니다. 진짜 일은 실행에서 벌어진다. 에이전트는 계획을 따라 도구를 호출하고, 응답을 읽고, 필요한 데이터를 저장하고, 다시 다음 단계로 넘어간다.13
이 과정은 생각보다 자주 삐끗한다. 검색 결과가 비어 있을 수도 있고, API가 오류를 낼 수도 있고, 권한이 없어서 접근이 막힐 수도 있다. 에이전트가 "잘 작동한다"는 말은, 언제나 한 번에 성공한다는 뜻이 아니다. 오히려 실패를 관찰했을 때 다음 행동을 고를 수 있다는 뜻에 가깝다. 다른 검색어로 다시 찾거나, 대체 도구를 쓰거나, 사람에게 물어보는 식이다.3
그래서 실행 단계에서 꼭 필요한 것이 종료 조건이다. 언제 목표가 달성된 것으로 볼지, 몇 번까지 재시도할지, 어디서 사람에게 넘길지를 정해두지 않으면 에이전트는 열심히 빙글빙글 돌 수 있다. 실무에서 좋은 에이전트는 보통 "완료 기준", "중단 조건", "인간 검토 시점"을 함께 가진다.6
이 점은 사용자에게도 유용하다. 에이전트를 쓸 때 "초안까지만 만들어줘", "발송 전에는 꼭 나한테 보여줘", "출처가 3개 미만이면 멈춰줘"처럼 끝나는 조건을 말해주면 결과가 훨씬 안정적이다.
피드백은 에이전트를 덜 고집스럽게 만든다
에이전트의 마지막 핵심은 피드백이다. 피드백은 거창한 학습만 뜻하지 않는다. 더 넓게 보면, 방금 한 행동의 결과를 보고 다음 행동을 바꾸는 모든 과정이 피드백이다.13
가장 즉각적인 피드백은 실행 중에 일어난다. 예약 API가 실패를 돌려주면 다른 시간을 찾고, 검색 결과가 부족하면 다른 출처를 추가하고, 사용자가 "이 톤은 너무 딱딱해"라고 말하면 문체를 바꾸는 식이다. 이런 피드백 덕분에 에이전트는 정해진 스크립트처럼 움직이지 않고, 상황에 따라 방향을 틀 수 있다.3
조금 더 긴 시간의 피드백도 있다. 사용자가 자주 수정하는 표현, 자주 거절하는 제안, 성공률이 높은 작업 방식은 다음번 판단에 반영될 수 있다. 다만 여기서 중요한 현실 감각이 하나 있다. 많은 에이전트가 "배운다"고 말해도, 인간처럼 알아서 깊이 성장하는 것은 아니다. 실제로는 메모리를 갱신하거나, 선호를 저장하거나, 워크플로 규칙을 조정하는 수준인 경우가 많다. 즉, 피드백이 있다고 해서 모든 에이전트가 점점 현명해지는 것은 아니다.45
이 차이를 알아두면 과신을 줄일 수 있다. 어제 실수했다고 오늘 자동으로 완벽해지는 것은 아니다. 반대로 한 번 잘했다고 해서 영원히 잘하는 것도 아니다.
사용자는 에이전트의 결과보다 흐름을 읽어야 한다
에이전트가 내놓은 결과를 해석할 때는 최종 문장만 보지 말고, 그 결과가 어떤 흐름에서 나왔는지를 보는 습관이 필요하다. 아주 어렵게 볼 필요는 없다. 다음 세 가지만 물어봐도 상당히 많은 것이 드러난다.
이 에이전트는 무엇을 보고 판단했는가
이 에이전트는 어떤 도구를 써서 어디까지 행동했는가
이 에이전트는 언제 멈추고 사람에게 확인하도록 설계되어 있는가6
이 질문을 던지면 왜 어떤 결과는 믿을 만하고, 어떤 결과는 위험한지가 보이기 시작한다. 출처 없이 자신만만한 요약은 경계해야 하고, 도구 실패를 숨긴 채 만든 결과도 조심해야 한다. 반대로 사용한 자료, 수행한 단계, 불확실한 지점을 함께 보여주는 에이전트는 대체로 더 신뢰하기 쉽다.
결국, 에이전트는 이렇게 일한다
한 문장으로 줄이면 이렇다. AI 에이전트는 모델을 두뇌로 삼고, 도구로 세상과 연결되며, 메모리로 맥락을 이어가고, 계획으로 큰 일을 쪼개고, 실행과 피드백의 반복으로 목표를 향해 가는 시스템이다.124
이 그림을 이해하면 에이전트를 대하는 태도도 달라진다. 막연히 "똑똑한 AI"로 보는 대신, 어떤 재료를 읽었고, 어떤 손발을 썼고, 어디까지 자율적으로 움직였는지를 보게 된다. 그리고 바로 그 순간부터 사용자는 더 잘 맡기고, 더 잘 검토하고, 더 덜 속게 된다.
참고
1Google Cloud의 AI 에이전트 정의와 작동 방식
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.