AI를 그저 똑똑한 검색창으로 취급하는 것을 멈춘 날, 무언가 저에게 '꽂혔습니다'.
저는 AI 분야에서 충분히 오래 활동하여 이 분야의 회사를 설립하고 매각해 본 경험이 있습니다. 제가 운영했던 이전 회사에서는 어린 아이들에게 언어와 STEM을 가르치는 AI 로봇인 ROYBI Robot을 만들었습니다. 이는 실제 언론의 주목을 받았고, 제가 예상치 못했던 자리들에 저를 데려다주었죠. 이 점을 분명히 말씀드리는 이유는 제 조급함을 설명하기 위해서입니다. 저는 내부에서 AI가 하이프 사이클(hype cycles)을 거치는 것을 지켜봤으며, 저의 관계 대부분은 여전히 '질문하면, 답변하고, 다음으로 넘어가는' 형태였습니다. 단어들을 위한 자판기 같은 것이었죠. 물론 유용했지만, 실제 작업은 제가 직접 해야 했습니다. 추적하는 것, 컴파일하는 것, 후속 조치를 취하는 것까지요. AI가 말했고, 저는 행동했습니다.
그러다가 저는 '비서(assistant)'와 '에이전트(agent)'의 차이를 알게 되었고, 이는 제가 일을 처리하는 방식에 대한 사고방식을 재정립하게 했습니다.
비서는 사용자의 지시를 기다렸다가 실행합니다. 단계별 방향을 직접 전달해야 합니다. 반면 에이전트는 목표를 받으면 스스로 단계를 파악합니다. 사용자에게 목적(objective)과 몇 가지 가드레일(guardrails)만 주면, 사용자가 다른 일을 하는 동안에도 에이전트가 작업을 수행해 나갑니다.
교과서적인 정의에 따르면, 에이전트는 환경을 인지하고(perceives), 결정을 내리고(makes decisions), 행동하며(takes actions), 어느 정도의 자율성으로 목표를 추구하는(pursues goals with some degree of autonomy) AI 시스템입니다. 실용적인 정의는 더 짧습니다. 즉, 에이전트는 단순히 말만 하는 것이 아니라 실제로 '행동'하는 AI라는 것입니다.
저에게 결정적이었던 비유가 있습니다. 식당 추천을 위해 AI에 질문하는 것은 챗봇(chatbot)입니다. 반면, 옵션을 조사하고, 이용 가능 여부를 확인하며, 리뷰를 읽고, 가격을 비교하고, 테이블을 예약한 다음, 달력에 기록해 줄 사람을 고용하는 것은 에이전트입니다. 대화적인 표면은 같지만, 그 아래의 본질은 완전히 다릅니다.
에이전트를 에이전트로 만드는 다섯 가지 요소들.
'에이전트'라는 라벨이 붙었다고 해서 모든 것이 진정한 에이전트는 아닙니다. 요즘에는 채팅창만 있으면 무엇이든 그 이름표가 붙는 경향이 있습니다. 제가 실제로 사용하는 체크리스트는 다음과 같습니다:
- 인식(Perception). 환경에서 정보를 수집할 수 있습니다: 문서를 읽거나, 데이터베이스에 질의하거나, 피드를 관찰하는 것.
- 추론(Reasoning). 다단계 문제를 처리하고 다음에 무엇을 할지 결정할 수 있습니다.
- 행동(Action). 단순히 제안하는 것을 넘어 실제로 무언가를 수행할 수 있습니다: API를 호출하거나, 파일을 작성하거나, 메시지를 보내는 것.
- 지속성(Persistence). 매번 처음부터 시작하는 대신 단계와 세션 전반에 걸쳐 컨텍스트(context)를 유지합니다.
- 목표 지향성(Goal orientation). 단순히 프롬프트에 답변하는 것이 아니라 결과(outcome)를 목표로 합니다.
이러한 몇 가지 익숙한 도구들을 이 필터를 통해 실행해 보면 그림이 빠르게 선명해집니다.
지식 기반에서 질문에 답하는 고객 서비스 챗봇? 진정한 에이전트라고 보기 어렵습니다. 그와 같은 챗봇에게 데이터베이스에서 주문을 확인하고, 환불 처리를 하고, CRM 티켓을 업데이트하며, 내일 후속 이메일을 보낼 수 있는 능력을 부여해 보세요. 이제야 비로소 '에이전트'가 됩니다.
그리고 저는 이것을 옆에서 관찰하며 설명하는 것이 아닙니다. 제가 오늘 업무를 처리하는 방식 자체가 그렇습니다. 에이전트들이 끝까지 작동하도록 하고, 제가 인간의 개입이 실제로 필요한 부분만 지시하고 호출합니다.
코딩 도구도 마찬가지입니다. GitHub Copilot이 타이핑할 때 줄을 완성해 주는 것은 편리하지만, 그것은 '에이전트적(agentic)'이지 않습니다. 전체 코드베이스를 읽고, 아키텍처에 대해 추론하며, 여러 파일에 걸쳐 변경 사항을 만들고, 테스트를 실행하고, 실패한 부분에서 반복하는 Cursor와 같은 도구는 행동하고, 기억하며, 목표를 추구합니다. 이것이 에이전시(agency)에 훨씬 가깝습니다.
참고로 다섯 가지 특성을 모두 최고 수준으로 갖출 필요는 없습니다. 이 중 세 가지 또는 네 가지가 강력한 에이전트도 단순 챗봇을 압도적으로 능가할 것입니다. 핵심은 최대의 자율성을 추구하기보다는 실제 업무에 맞춰 에이전시의 수준을 조절하는 것입니다.
아무도 경고해주지 않는 사고방식의 변화
에이전트의 어려운 부분은 기술적인 것이 아닙니다. 정신적인 것입니다.
여러분은 질문하고 답변을 받는 것에 익숙합니다. 에이전트를 사용할 때는 목표를 정의하고 AI를 풀어놓아 그것을 추구하게 합니다. 여러분은 스스로 작업을 수행하는 데 익숙했습니다. 이제는 '완료'가 어떤 모습인지 설명하고, 에이전트에게 실행을 맡기는 것입니다.
수행하는 것에서 지시하는 것으로의 전환은 미묘하며, 솔직히 처음에는 약간 불편할 수 있습니다. 절차(procedures) 대신 결과(outcomes)를 지정하고, 단계(steps) 대신 제약 조건(constraints)을 지정하는 방법을 배워야 합니다. 하지만 일단 감이 오기 시작하면, 어디서든 에이전트가 해결할 수 있는 문제들을 발견하게 됩니다. 매주 월요일 여섯 개의 소스에서 취합하는 보고서, 손으로 확인하던 경쟁사 블로그, 커피를 마시며 처리하던 받은 편지함 분류 작업 등이 그것입니다.
오늘 바로 첫 번째 에이전트를 만들어 보세요: 20분 만에, 코딩 없이
에이전트에 대해 배우는 가장 좋은 방법은 직접 하나를 구축해 보는 것입니다. 여기 정말 유용한 스타터가 있습니다. 특정 주제를 감시하고 매일 요약본을 이메일로 보내주는 리서치 에이전트입니다. 20분 만에 설정을 마치면, 매일 아침 꾸준히 보상을 받게 될 것입니다.
무료 Make.com 계정이 필요합니다. 이곳의 시각적 빌더(visual builder)는 에이전트의 논리를 플로우차트(flowchart)로 보여주기 때문에 개념을 추상적인 것이 아닌 구체적으로 이해할 수 있습니다.
[Trigger]. 새 시나리오를 만들고, 스케줄 모듈(Schedule module)을 추가하여 원하는 시간에 하루에 한 번 실행되도록 설정합니다. 이것이 에이전트가 시간을 인식하는 방식이며, 작업 주기를 시작시키는 역할을 합니다.
[Perceive]. HTTP 모듈을 추가하고, 주제와 관련된 Google News RSS 피드를 GET 방식으로 가져옵니다: https://news.google.com/rss/search?q=your+search+terms. API 키는 필요하지 않습니다. 그런 다음 Parse XML 모듈을 추가하여 에이전트가 제목, 설명, 링크, 발행 날짜 등의 구조를 읽을 수 있게 합니다.
[Reason]. 파서와 다음 단계 사이에 필터(Filter)를 배치하고, 지난 24시간 이내에 발행된 항목만 통과하도록 구성합니다. 이것이 바로 에이전트가 무엇이 관련성이 있는지 판단하고 나머지는 무시하는 과정입니다.
[Think]. AI 모듈(OpenAI 또는 Claude API)을 추가하여 각 기사의 제목과 설명을 받아 간결한 두 문장 요약본을 작성하게 합니다. 원본 피드 데이터가 실제로 훑어볼 수 있는 정보로 변환됩니다.
[Act]. 이메일 모듈을 추가하여 컴파일된 요약본(각 항목의 제목, 요약, 링크)을 사용자에게 전송합니다.
저장하고, 활성화하고, 완료했습니다. 에이전트가 매일 깨어나 사용자의 주제를 스캔하고, 노이즈를 필터링하며, 새로운 내용을 요약하여 받은 편지함에 전달합니다. 예약된 인식(Scheduled perception), 관련성 추론(Relevance reasoning), 도구로서의 AI, 가치를 제공하는 행동입니다. 모든 핵심 에이전트 개념을 점심 식사 전에 배포할 수 있는 작은 패키지로 담았습니다.
피해야 할 두 가지 초보자 실수가 있습니다. 첫째, 너무 공격적으로 필터링하여 아무것도 통과하지 못하게 해서는 안 됩니다. 실행 기록(execution history)을 확인하여 무엇이 걸러졌는지 보고 기준을 완화하세요. 둘째, 과도하게 엔지니어링하려는 충동에 저항해야 합니다. 첫날부터 복잡한 계획 알고리즘(complex planning algorithms)이나 프로덕션 등급의 오류 처리(production-grade error handling)가 필요하지 않습니다. 복잡한 에이전트 하나를 만들기 전에 간단한 에이전트 다섯 개를 만드세요. 각각의 작은 구축은 패턴을 가르쳐주며, 이 패턴들이 결합하여 시너지를 냅니다.
이것이 열어주는 것들 (What this unlocks)
에이전트를 생각하기 시작하면 가능성의 한계가 높아집니다.
고객 서비스 팀은 일상적인 문의를 해결하고 진정으로 어려운 사례만 인간에게 에스컬레이션하는 에이전트를 운영합니다. 개발팀은 사양(specifications)으로부터 기능을 구현하고, 테스트 코드를 작성하며, 풀 리퀘스트(pull requests)를 여는 코딩 에이전트를 보유합니다. 마케팅 팀은 모두가 잠든 사이에 수십 가지의 메시지 변형을 테스트합니다.
흥미로운 부분은 노동력 절감 자체가 아닙니다. 아예 가능하게 되는 '일'입니다. 한 번에 수천 개의 소스를 모니터링하고, 모든 사용자에게 맞춤형 콘텐츠를 제공하며, 동시에 백 가지 변형을 테스트하는 것입니다. 그 어떤 비용으로도 사람이 직접 할 수는 없습니다. 에이전트는 단순히 오래된 작업을 가속화하지 않습니다. 새로운 일을 존재하게 만듭니다.
여기서 나아갈 방향 (Where to go from here)
작게, 그리고 현실적으로 시작하세요. 짜증 나는 반복적인 업무 하나를 고르세요. 주간 수치 요약, 가격 추적, '이 페이지에 변화가 있었는지' 확인하는 것 등 무엇이든 좋습니다. 그것을 에이전트화(agent-ify) 하세요. 하나의 목표, 몇 단계의 과정, 그리고 마지막 한 가지 행동으로 끝냅니다. 작동하도록 만들고, 돌아가는 것을 지켜본 다음, 더 똑똑하게 만드세요.
전체 지도를 원한다면, 친구가 이번 가을에 읽고 있는 책 한 권을 추천해 주었습니다. 바로 『AI Agents for Beginners』입니다. 이 책에는 에이전트 아키텍처 패턴(agent architecture patterns), 에이전트를 위한 프롬프트 엔지니어링(prompt engineering for agents), 메모리 및 컨텍스트 관리(memory and context management), 실제 시스템에 에이전트를 연결하는 방법, 그리고 50개 이상의 바로 사용할 수 있는 프롬프트가 모두 담겨 있으며, 제가 찾아본 것 중 가장 실용적인 내용입니다. Apple Books에서 이번 12월 Great Books, Amazing Deals 이벤트로 이 책을 소개하고 있다는 점에서, 지금이야말로 이러한 지식을 배울 적기임을 알게 되었습니다.
AI의 자판기 시대는 끝났습니다. 이제 에이전트를 고용할 시간입니다.
계속 소통해요. 저는 AI에 대해 이야기하는 것을 좋아합니다. 링크드인(LinkedIn)에서 저를 찾아주세요.