AI 가이드 · 11분 읽기

AI 에이전트란? 쉽게 설명

AI 에이전트의 뜻과 챗봇과의 차이, 잘하는 일과 아직 어려워하는 일을 살펴봅니다. 권한을 지나치게 넘기지 않고 안전하게 직접 사용해 보는 방법과 업무에서 마주할 수 있는 위험과 결과를 직접 확인하는 방법도 함께 알아봅니다.

계획, 행동, 관찰의 반복 과정 중심에 AI 모델이 있고 주변에 검색, 코드, 이메일 등의 도구가 있는 그림

챗봇은 질문에 답합니다. 에이전트는 나서서 무언가를 합니다.

이 한 가지 차이가 올해 AI 에이전트를 둘러싼 기대와 불안의 상당 부분을 설명합니다. 이제 에이전트는 코딩 도구, 브라우저, 고객 서비스 소프트웨어, 그리고 우리 중 많은 사람이 이미 돈을 내고 쓰는 비서 서비스에도 등장합니다. AI 모델이 들어간 거의 모든 것에 이 단어가 붙기 때문에, 잠시 멈춰 에이전트가 무엇인지, 실제로 무엇을 잘하는지, 아직 언제 믿어서는 안 되는지 정확히 짚어볼 필요가 있습니다.

실제로 쓸 수 있는 정의

AI 에이전트는 언어 모델을 사용해 목표를 향해 일하는 시스템입니다. 일이 끝났다고 판단할 때까지 다음 단계를 선택하고, 도구로 행동하고, 무슨 일이 일어났는지 확인하는 과정을 반복합니다.

세 가지가 있어야 합니다.

  • 목표가 있어야 합니다. 단순한 질문이 아닙니다. “40명이 참석하는 외부 행사를 위해 $5,000 미만의 장소 세 곳을 찾아줘”는 목표입니다. “Austin에서 좋은 장소가 어디야?”는 질문입니다.
  • 도구가 있어야 모델이 웹 검색, 파일 열기, 코드 실행, 양식 작성, 메시지 전송 등을 할 수 있습니다.
  • 반복 과정이 있어야 합니다. 모델은 한 단계를 계획하고 실행한 뒤 결과를 살펴보고, 확인한 내용에 따라 다음 단계를 선택합니다.

도구와 반복 과정을 빼면 다시 챗봇이 됩니다. 그것들을 더하면 모델은 단순히 글을 쓰는 데 그치지 않고 작업을 수행하는 사람처럼 행동하기 시작합니다. 이 변화가 핵심입니다.

챗봇, 워크플로, 에이전트는 다릅니다

제가 본 가장 명확한 구분은 에이전트 구축에 관한 Anthropic의 엔지니어링 가이드에 나옵니다. 이 가이드는 워크플로를 모델과 도구가 “미리 정의된 코드 경로를 통해 조율되는” 시스템으로, 에이전트를 모델이 “자체 프로세스와 도구 사용”을 동적으로 지휘하는 시스템으로 설명합니다.

실제로는 세 단계로 나뉩니다.

유형 다음 단계를 결정하는 주체 예시
챗봇 매 답변 뒤 사용자 비서에게 계약 조항을 설명해 달라고 요청하기
워크플로 개발자가 사전에 결정 새 지원 티켓을 모두 같은 방식으로 요약하고, 태그를 붙이고, 전달하기
에이전트 작업 중인 모델 “이 저장소에서 실패하는 테스트를 고쳐줘.” 코드를 읽고 파일을 수정하고 테스트를 다시 실행하며 반복합니다

에이전트로 판매되는 제품 중 상당수는 사실 워크플로입니다. 솔직히 그쪽이 더 나은 설계인 경우가 많습니다. 고정된 순서는 예측 가능하고 실행 비용이 낮으며 테스트하기 쉽습니다. 진정한 에이전트의 추가 비용과 위험은 아무도 목표에 이르는 경로를 미리 적어 둘 수 없을 때에만 정당화됩니다.

내부 구성

홍보 문구를 걷어내면 대부분의 에이전트는 같은 네 가지 요소로 구성됩니다.

생각하는 모델

거대 언어 모델이 목표를 읽고, 어떤 도구를 쓸지 결정하고, 반환된 결과를 해석합니다. 모델 품질은 채팅보다 에이전트에서 더 중요합니다. 채팅에서 부실한 답변의 대가는 답변 한 번입니다. 에이전트에서는 두 번째 단계의 잘못된 판단이 그 뒤의 모든 단계에 영향을 줍니다.

사용이 허용된 도구

도구는 에이전트가 호출할 수 있는 함수입니다. 코딩 에이전트에는 “파일 읽기”, “파일 수정”, “테스트 실행”이 있을 수 있습니다. 조사 에이전트에는 “검색”과 “페이지 열기”가 있을 수 있습니다. 각 도구는 쉬운 말로 모델에 설명되며, 모델은 구조화된 요청을 만들어 사용을 요청하고 주변 소프트웨어가 이를 실행합니다.

도구를 다양한 에이전트에 연결할 수 있도록 표준이 만들어지기 시작했습니다. Anthropic은 AI 비서를 데이터와 서비스에 연결하는 개방형 방식으로 2024년 11월 Model Context Protocol을 도입했으며, 현재 널리 지원됩니다. 2026년 10월 6일 Sierra와 Meta는 Personal Agent Protocol을 발표했습니다. 이는 개인 에이전트가 기업에 자신의 신원을 어떻게 밝히고 연결 후 무엇을 할 수 있는지에 관한 OAuth 기반 제안입니다. 출범 당시 이름을 올린 파트너에는 Shopify, Stripe, Walmart가 포함됐으며, 명세의 첫 버전은 10월 후반에 나올 예정이었습니다.

기억

에이전트는 이미 시도한 일을 기억해야 합니다. 짧은 작업에서는 진행 중인 대화 기록이 그 역할을 합니다. 긴 작업에는 보통 파일이나 데이터베이스에 적은 메모가 필요합니다. 기록이 결국 너무 길고 잡다해져서 쓸모가 없어지기 때문입니다.

안전장치

좋은 에이전트는 제한 안에서 작동합니다. 접근할 수 있는 도구, 계정과 폴더, 지출할 수 있는 금액, 사람이 먼저 승인해야 하는 행동이 정해져 있습니다. 저는 안전장치가 모델보다 더 중요하다고 생각합니다. 안전하게 잠시 눈을 뗄 수 있게 해 주는 것이 바로 안전장치입니다.

오늘날 에이전트가 정말 잘하는 일

에이전트는 단계는 많지만 결과를 쉽게 확인할 수 있는 일에서 빛을 발합니다.

테스트가 있는 코딩이 가장 분명한 예입니다. 에이전트는 코드를 수정하고 테스트 모음을 실행하며 테스트를 통과할 때까지 계속합니다. 테스트는 지치지 않는 심판 역할을 합니다.

출처를 제시하는 조사도 잘 맞습니다. 에이전트는 검색하고, 출처 12개를 열고, 모든 주장에 근거 링크가 달린 요약을 만들 수 있습니다. 여전히 직접 읽어야 하지만, 빈 페이지가 아닌 초안에서 시작할 수 있습니다.

데이터 정리도 강점입니다. 어수선한 스프레드시트의 형식을 바꾸거나, 두 목록을 대조하거나, PDF 50개에서 같은 항목을 추출할 수 있습니다. 10개 행을 표본으로 확인하는 편이 모두 직접 처리하는 것보다 훨씬 빠릅니다.

패턴은 언제나 같습니다. 직접 결과물을 만드는 것보다 결과를 검증하는 편이 빠릅니다. 그렇다면 에이전트를 시험해 볼 만합니다. 그렇지 않다면 주의해야 합니다.

여전히 어려워하는 일

작은 실수가 쌓입니다

에이전트가 세 번째 단계에서 무언가를 잘못 읽으면 그 이후의 모든 일이 그 실수 위에 쌓입니다. 5분짜리 작업에서는 만회할 수 있습니다. 2시간짜리 작업에서는 보통 그렇지 않습니다. 시연에서 마법처럼 보이는 에이전트가 길고 복잡한 작업에서는 방향을 잃을 수 있는 이유입니다.

모호한 목표

“우리 온보딩을 개선해 줘”라고 하면 에이전트는 어디서 멈춰야 할지 알 수 없습니다. 완료의 명확한 정의가 없으면 에이전트는 너무 일찍 그만두거나 멈췄어야 할 때를 한참 지나서도 계속합니다.

되돌릴 수 없는 행동

읽기는 쉽게 되돌릴 수 있습니다. 이메일을 보내거나, 파일을 삭제하거나, 물건을 사는 일은 그렇지 않습니다. 에이전트가 현실 세계에서 더 많은 것을 바꿀수록 한 번의 오해가 치르는 대가도 커집니다.

보안

에이전트는 낯선 사람이 쓴 웹페이지, 이메일, 공유 문서를 읽습니다. 일부 콘텐츠에는 에이전트를 탈취하기 위한 숨겨진 지시가 들어 있을 수 있습니다. 이를 프롬프트 인젝션이라고 하며, OWASP Gen AI Security Project는 이를 언어 모델 기반 애플리케이션의 가장 큰 위험으로 꼽습니다. 아직 해결된 문제가 아닙니다.

열린 웹에 풀려난 에이전트

2026년 10월에는 생생한 사례가 있었습니다. Wikimedia 에이전트 사건에 관한 기사에서 자세히 다룹니다. 10월 초 Wikimedia Foundation은 OpenAI가 운영한 것으로 추정하는 에이전트들이 봇에 통상 필요한 커뮤니티 승인 없이 재단의 위키를 편집했다고 밝혔습니다. 거의 모두 샌드박스 영역의 테스트 편집이었지만, 일부는 인용 도구의 설정을 대상으로 했으며 Wikimedia는 이를 “악의적일 가능성이 있다”고 표현했습니다. 에이전트들은 Wikimedia의 공개 API에도 수백만 건의 자동 요청을 보냈고 Wikidata Query Service에는 수십만 건의 질의를 보냈습니다. Wikimedia는 이 트래픽이 5월 해당 서비스의 부분 장애에 영향을 줬을 수 있다고 말합니다. Wikimedia는 시스템이나 데이터가 침해됐다는 증거는 발견하지 못했습니다.

제게 남은 Wikimedia의 Selena Deckelmann의 말은 이렇습니다. “Wikipedia는 사람을 위해 설계됐습니다.” 웹의 대부분도 마찬가지입니다. 에이전트를 운영하는 사람은 그곳에서 에이전트가 어떻게 행동하는지 책임져야 하며, 이를 제대로 관리할 도구는 아직 미성숙합니다.

직장에서의 기대와 현실

분석가들은 에이전트가 빠르게 확산할 것으로 예상합니다. 2025년 8월 Gartner는 2026년까지 기업 애플리케이션의 40%에 특정 작업용 AI 에이전트가 포함될 것으로 예측했습니다. 2025년의 5% 미만에서 증가한 수치입니다.

기업 설문조사는 더 조심스러운 모습을 보여 줍니다. 대부분의 기업은 에이전트를 시험하고 있다고 말합니다. 명확한 감독 아래 대규모로 운영 중이라고 답한 기업은 훨씬 적습니다. 이 격차는 AI 에이전트가 시범 단계에 머무는 이유에서 자세히 살펴봅니다. 제 생각에는 이 격차는 모델 품질보다 눈에 잘 띄지 않는 일과 더 관련이 있습니다. 에이전트를 올바른 시스템에 연결하고, 누가 무엇을 승인할지 정하고, 결과가 실제로 이전보다 나은지 측정하는 일입니다. AI가 반복 업무를 맡는 곳에서는 초급 일자리 채용에 첫 영향이 나타나고 있습니다.

후회 없이 에이전트를 시험하는 방법

실험하고 싶다면 다음 습관으로 위험 대부분을 줄일 수 있습니다.

  1. 읽기 전용으로 시작하세요. 무언가를 보내거나, 사거나, 삭제하도록 허용하기 전에 조사, 요약, 초안 작성을 시키세요.
  2. 확인할 수 있는 작은 작업을 주세요. “X에 관한 최근 기사 다섯 개를 찾아 각각의 핵심 주장을 링크와 함께 나열해 줘”는 “내 받은 편지함을 처리해 줘”보다 훨씬 나은 첫 작업입니다.
  3. 부수 효과가 있는 모든 일에 승인을 요구하세요. 대부분의 에이전트 도구는 메시지를 보내거나 파일을 바꾸기 전에 일시 중지할 수 있습니다. 이 기능을 켜고 에이전트의 행동을 알게 될 때까지 유지하세요.
  4. 가능한 한 적게 연결하세요. 작업에 필요한 폴더나 계정 하나만 제공하세요. 실험 중인 에이전트와 주 이메일 계정은 좋지 않은 조합입니다.
  5. 작업 기록을 읽으세요. 좋은 에이전트 도구는 수행한 모든 단계를 보여 줍니다. 적어도 처음 몇 번은 훑어보세요.
  6. 결과를 직접 확인하세요. 에이전트가 작업에 성공했다고 말하는 것은 성공했다는 증거가 아닙니다. AI 답변을 사실 확인하는 방법에서 소개한 습관이 여기에도 적용됩니다.

에이전트가 업무와 관련된 어떤 것에든 접근한다면 먼저 민감한 데이터를 유출하지 않고 직장에서 AI를 사용하는 방법을 읽어 보세요.

자주 마주칠 용어

  • 도구 사용 또는 함수 호출: 모델이 주변 소프트웨어에 특정 입력으로 특정 함수를 실행해 달라고 요청하는 것.
  • 컨텍스트 윈도: 지시, 지금까지의 대화, 도구 결과를 포함해 모델이 한 번에 고려할 수 있는 텍스트의 양.
  • 사람이 참여하는 과정: 사람이 핵심 단계를 승인하거나 수정하는 설계.
  • 오케스트레이션: 반복 과정을 실행하고 도구를 호출하며 제한을 적용하는 코드.
  • 멀티 에이전트 시스템: 계획 담당자와 여러 작업 담당자처럼 서로 다른 역할의 에이전트들이 하나의 작업을 조율하는 시스템.

이제 어떻게 해야 할까요

AI 에이전트는 목표와 도구 모음, 그리고 한 단계 이상을 수행할 권한을 가진 언어 모델입니다. 그래서 확인하기 쉬운 여러 단계의 작업에는 정말 유용하지만, 실제 결과가 따르는 열린 작업에는 정말 위험합니다. 작게 시작하고 중요한 결정에는 사람이 관여하게 하며, 에이전트가 신뢰를 얻은 후에만 허용 범위를 넓히세요.

기반 모델도 중요합니다. AI 모델을 선택하는 방법에서 고려할 장단점을 설명합니다.

출처

작성자

Chunyu Cai

Chunyu Cai는 Lotook, LLC의 CEO이자 기업가로, AI 모델과 에이전트, 그리고 이들이 일상 업무를 어떻게 바꾸는지에 관해 글을 씁니다. Chunyu Cai는 Imperial College London에서 석사 학위를 받았습니다.