'에이전트'는 지금 소프트웨어에서 가장 의미가 과도하게 실린 단어다. 벤더들은 이 말을 챗봇에도, 예약 실행 스크립트에도, API 키가 하나 붙어 있는 것이라면 무엇에든 갖다 쓴다. 하지만 그 소음 아래에는 배울 가치가 있는 진짜 패턴이 있다. 올해 AI 에이전트를 만들고 싶다면, 첫 번째 할 일은 그 패턴을 마케팅에서 떼어내는 것이다. 사람들이 스케치하는 '에이전트' 프로젝트 중 상당수는 그냥 단순한 자동화로 만드는 편이 더 낫기 때문이기도 하다 — 하루 오후에, 비용도 아주 일부만 들여서.
이 가이드는 세 가지를 한다. 에이전트가 실제로 무엇인지를, 기획 회의에서 재사용할 수 있는 한 문장으로 정의한다. 여러분의 역량에 맞춘 세 가지 구축 경로를 제시한다: 노코드 플랫폼, 개발자용 프레임워크, 그리고 아예 에이전트를 만들지 않는다는 정직한 세 번째 선택지. 그리고 하나의 구체적인 예시인 받은편지함 분류 에이전트를, 목표에서 가드레일까지 통째로 짚어 간다.
이 중 어느 것도 머신러닝 배경을 요구하지 않는다. 하지만 이 모두는 그 물건이 무엇을 하기를 원하는지에 대해 명확해질 것을 요구한다.
AI 에이전트가 실제로 무엇인지
브랜딩을 걷어내면 에이전트는 루프 안에서 돌아가는 세 부분이다:
- 다음에 무엇을 할지 결정하는 모델
- 호출이 허용된 도구의 집합: 데이터베이스 검색, 이메일 읽기, 라벨 붙이기, 메시지 초안 작성
- 정지 조건이 딸린 목표. 이것이 있어야 루프가 언제 끝났는지 안다
에이전트는 루프다: 결정하는 모델, 행동하는 도구, 그리고 언제 멈출지 말해 주는 목표.
중요한 것은 루프라는 부분이다. 챗봇은 메시지에 답하고 기다린다. 워크플로는 매번 똑같은 고정된 단계를 실행한다. 에이전트는 상황을 읽고, 도구를 고르고, 결과를 보고, 다시 결정하기를 목표가 충족되거나 예산이 바닥날 때까지 되풀이한다. 루프 한가운데의 그 결정 지점이야말로, 에이전트와 에이전트라며 팔리는 그 밖의 모든 것 사이의 차이 전부다.
이것은 또한 여러분 자신의 프로젝트를 가리는 깔끔한 테스트를 안겨 준다. 무엇이든 실행되기 전에 모든 단계를 순서도로 그릴 수 있다면, 여러분에게는 에이전트가 필요하지 않다 — 워크플로가 필요하며, 그것이 아래의 세 번째 경로이고, 부끄러워할 것은 전혀 없다. 에이전트는 다음 단계가 앞 단계에서 나온 것에 진짜로 좌우될 때에만 그 복잡성을 정당화한다.
AI 에이전트를 만드는 세 가지 방법
어떤 경로를 택할지는 야심보다는 누가 만드는지, 그리고 문제가 어떤 형태인지에 달려 있다. ToolPotion의 디렉터리에는 AI 에이전트를 만들기 위한 도구 700개가 실려 있다. 이 세 경로의 요점은, 여러분이 그중 한 줌보다 많이 평가할 필요가 결코 없어야 한다는 것이다.
경로 1: 노코드 에이전트 플랫폼
이것은 코드를 쓰는 사람이 아니라 그 프로세스를 소유한 사람(지원 리드, 운영 매니저, PM)을 위한 길이다.
Microsoft Copilot Studio는 여러분의 비즈니스 데이터에 연결되고, 자연어 프롬프트에 응답하며, Microsoft 365 앱이나 웹사이트로 배포되는 에이전트를 만들게 해 준다. 회사가 이미 Microsoft 위에서 돌아가고 있다면, 이것은 아이디어에서 배포된 에이전트까지의 가장 짧은 거리다: 모델 접근, 데이터 연결, 채널이 모두 이미 동료들이 일하는 곳에 있다. 여러분의 스택이 Microsoft의 것에서 멀어질수록, 그만큼 값어치는 떨어진다.
Voiceflow는 대화의 측면에서 문제에 접근한다: 채팅과 음성 에이전트 흐름을 시각적으로 설계하고, 여러 채널에 걸쳐 출시하며, 실제 대화록을 바탕으로 반복 개선한다. 고객을 마주하는 지원 에이전트에는 강하게 들어맞는다. 여러분의 에이전트가 사람과 결코 대화하지 않는다면 형태가 맞지 않는다.
이 경로의 공통된 트레이드오프: 여러분은 루프를 빌리고 있다. 에이전트가 오작동할 때 디버깅은 자신의 로그를 읽는 대신 벤더의 인터페이스를 클릭해 헤매는 일을 뜻하고, 나중에 다른 플랫폼으로 옮기는 것은 다시 짓는 것을 뜻한다. 그리고 여러분이 애초에 에이전트를 만들고 있기는 한지도 정직하게 보라: 이 수준의 프로젝트 다수는 사실 챗봇이며, 여러분의 것이 거기 해당한다면 챗봇을 만들기 위한 도구 디렉터리가 더 딱 맞는 쇼핑 장소다.
경로 2: 프레임워크와 코드, 개발자용
개발자는 더 많은 제어권과 더 많은 숙제를 얻는다. 루프는 여러분이 직접 쓴다: 모델을 고르고, 각 도구를 함수로 정의하고, 목표를 시스템 프롬프트로 표현하고, 반복 횟수와 지출에 강한 상한을 건다.
모델 선택은 여기서 다른 어디에서보다 더 중요하다. Claude Opus는 바로 이 작업을 위해 만들어졌다: 코딩과 에이전트를 위해 설계된 추론 모델로, 100만 토큰 컨텍스트 윈도를 갖춰 오래 이어지는 작업 내내 메일함 하나 또는 코드베이스 하나 분량의 컨텍스트를 통째로 담을 수 있다. 다만 유의할 점은 비용 규율이다: 루프의 매 턴마다 프런티어 모델을 쓰면 쌓여 가므로, 값싼 단계(분류, 서식)는 더 작은 모델로 보내고 큰 모델은 결정을 위해 아껴 두라.
첫 구축에는 범용 프레임워크보다 좁은 프레임워크가 낫다. Vanna 2.0이 좋은 예다: 회사 데이터베이스를 평이한 언어로 질의하는 에이전트를 위한 오픈소스 프레임워크로, 여러 LLM 제공자와 데이터베이스를 지원하고, 프로덕션용 접근 제어와 에이전트 메모리까지 갖췄다. 여러분의 첫 에이전트가 '우리 데이터에서 질문에 답하기'라면, 뼈대의 대부분은 이미 쓰여 있는 셈이다. 어떤 오픈소스 프레임워크와도 마찬가지로, 배포와 유지 관리는 여러분의 몫이다.
오케스트레이션 라이브러리부터 평가 하네스까지, 더 많은 선택지는 AI 프레임워크 디렉터리에 있다.
경로 3: 여러분에게 필요한 건 에이전트가 아니다 — 워크플로다
이것이 순서도 테스트의 가장 흔한 정직한 결말이며, 위로상이 아니라 진짜 경로로 대접받아 마땅하다.
단계가 알려져 있다면, 애매한 부분을 위한 모델 단계 하나를 갖춘 워크플로 도구가 루프의 예측 불가능성은 하나도 없이 가치의 대부분을 안겨 준다. Zapier는 9,000개가 넘는 앱에 걸쳐 AI 워크플로와 에이전트를 구축하며, 팀을 위한 가드레일과 접근 제어를 갖췄지만, 작업당 과금 모델은 물량이 늘면 따끔하다. Make는 드래그 앤드 드롭 방식의 시각적 캔버스와 3,000개 이상의 연동, 그리고 시제품을 만들어 볼 무료 요금제를 준다. 큰 시나리오는 그 캔버스 위에서 스파게티로 변하곤 한다. n8n은 기술 팀에 가장 잘 맞지만(필요한 곳엔 코드, 필요 없는 곳엔 노코드, 게다가 자체 호스팅도 가능), 팀에 JSON을 편히 읽을 수 있는 사람이 있다고 기대한다.
잘 다듬은 프롬프트의 LLM 단계 하나를 갖춘 워크플로는 급 낮은 에이전트가 아니다. 그것은 올바른 도구이고, 더 일찍 끝나며, 여러분이 예측할 수 있는 방식으로 실패한다.
| 경로 | 가장 적합한 대상 | 가동까지 | 함정 |
|---|---|---|---|
| 노코드 에이전트 플랫폼 | 엔지니어가 없는 프로세스 소유자 | 며칠 | 빌린 루프: 불투명한 디버깅, 벤더 종속 |
| 프레임워크와 코드 | 개발자 | 일이 주 | 평가·모니터링·유지 관리는 여러분의 몫 |
| 워크플로 더하기 LLM 단계 하나 | 정의된 프로세스를 가진 누구나 | 몇 시간 | 개방형 과제는 감당 못 함 |
실제로 풀어 본 예시: 받은편지함 분류 에이전트
여러분이 공유 지원 받은편지함을 운영한다고 하자. 목표는 이렇다: 들어오는 모든 메시지를 유형과 긴급도로 라벨링하고, 알맞은 담당자에게 라우팅하고, 안전한 경우에는 초안으로 답장한다. 이것을 에이전트로 놓으면 어떻게 보이는지, 어느 경로로 만들든 아래와 같다.
- 적어 둔 목표. "새 메시지마다 분류하라; 라벨이 붙고, 배정되고, 초안이 작성되었거나 에스컬레이션되면 멈춰라." 정지 조건은 장식이 아니다: 그것이 루프가 헤매지 않게 붙드는 것이다.
- 도구. 메시지를 읽는다. 이 발신자에 대해 지난 스레드와 CRM을 검색한다. 라벨을 붙인다. 담당자를 배정한다. 답장 초안을 쓴다. 무엇이 빠졌는지 눈여겨보라: 보내기다. 이것은 의도된 것이다.
- 한 메시지에서 도는 루프. 환불 요청이 도착한다. 모델은 그것을 읽고, 고객 이력을 검색해, 연간 구독과 3월의 불만을 찾아내고, 청구/높음으로 라벨링하고, 청구 담당자에게 배정하고, 앞선 불만을 참조하는 답장을 초안으로 쓰고, 멈춘다.
- 가드레일. 루프 반복 횟수의 상한, 메시지당 지출 상한, 그리고 에이전트가 확신이 서지 않을 때마다 반드시 써야 하는 '사람에게 에스컬레이션' 라벨.
이제 정직한 부분이다. 이 파이프라인의 대부분은 에이전트가 아니다. 라벨링과 라우팅은 분류기 더하기 규칙으로, Make나 n8n에게 편안한 영역이다. 루프가 값어치를 하는 것은 오직 세 번째 단계, 즉 검색 결과가 초안이 무슨 말을 해야 할지를 정하는 대목뿐이다. 만약 그 맥락을 아는 초안 작성이 여러분에게 값어치가 없다면, 워크플로 버전을 만들어 금요일까지 끝내라.
그리고 애초에 만들기 전에 사는 쪽을 살펴보라. 개인 받은편지함이라면 Shortwave가 이미 평이한 프롬프트로 이메일을 정리하고, 초안을 쓰고, 검색하고, 일정을 잡아 준다. 직접 만드는 것이 말이 되는 경우는, 어떤 기성 제품도 알 수 없는 라우팅 규칙을 가진 공유 메일함일 때뿐이다. 바로 쓸 수 있는 AI 에이전트 553개 디렉터리에서 20분을 쓰는 것은, 여러분의 에이전트가 이미 존재하는지를 알아내는 값싼 방법이다.
언제 망가지는지, 그리고 어떻게 알아차릴지
에이전트는 공손하게 실패한다. 모델이 잘못된 라벨을 붙이거나 자신만만하게 헛소리를 초안으로 쓸 때 스택 트레이스는 없다: 루프는 완료되고, 성공을 보고하며, 피해는 며칠 뒤 어리둥절해진 고객 스레드에서 수면 위로 떠오른다.
그래서 관측 가능성은 구축의 일부이지, 나중에 붙이는 부가물이 아니다. LangSmith는 에이전트가 밟는 모든 단계의 추적을 기록하고, 실패를 표시하며, 비용과 지연 시간을 추적한다. Python, TypeScript, Go, Java용 SDK를 갖췄다. 자매 프레임워크를 쓰든 안 쓰든 작동한다. Langfuse는 그 오픈소스 대응물로, 추적·프롬프트 관리·평가를 한데 묶었고, 자체 호스팅할 수 있다. 둘 중 어느 것이든 운영하거나 비용을 내야 하는 또 하나의 인프라다. 에이전트를 눈 감고 돌리는 편이 어김없이 더 비싸다.
그렇다면 여러분의 첫 한 주는 이런 모습이다: 정지 조건이 딸린 목표 문장을 쓰고, 에이전트가 손댈 수 있는 도구를 나열하고, 순서도 테스트를 돌리고, 테스트가 가리키는 경로를 고른다. 구축은 쉬운 절반이다. 사람을 루프에서 빼낼 만큼의 신뢰를 얻는 것, 그것이 진짜 프로젝트다.
자주 묻는 질문
코딩 없이 AI 에이전트를 만들 수 있나요?
가능합니다. Microsoft Copilot Studio나 Voiceflow 같은 플랫폼은 에이전트의 목표, 데이터 연결, 채널을 시각적 인터페이스로 정의하게 해 줍니다. 다만 노코드가 '일 없음'을 뜻하지는 않습니다: 여전히 목표를 명시하고, 도구를 고르고, 가드레일을 설정하고, 대화록을 검토해야 하므로, 구성과 테스트는 일 단위로 잡아 두세요.
AI 에이전트와 챗봇의 차이는 무엇인가요?
챗봇은 메시지에 응답하고 다음 메시지를 기다립니다. 에이전트는 루프 안에서 도구를 호출하며 목표를 향해 나아가고, 직전 단계가 돌려준 것을 바탕으로 다음 단계를 스스로 결정합니다. 에이전트로 마케팅되는 제품 상당수는 API 호출 하나가 붙은 챗봇입니다. 판별 기준은 시스템이 다음 행동을 스스로 고르는가입니다.
AI 에이전트를 만들려면 머신러닝 기술이 필요한가요?
아니요. 여러분은 모델을 훈련하는 것이 아니라 API나 플랫폼을 통해 호출합니다. 첫 에이전트에는 머신러닝 이론보다 명확한 프로세스 정의, 괜찮은 프롬프트, 그리고 자신의 데이터와 도구에 대한 지식이 훨씬 더 중요합니다.
첫 AI 에이전트를 만드는 데 얼마나 걸리나요?
LLM 단계 하나를 갖춘 워크플로는 당일에 돌릴 수 있습니다. 노코드 플랫폼 에이전트는 대개 구성과 테스트에 며칠이 걸립니다. 프레임워크 위에 코드로 만든 시제품은 일이 주가 걸립니다. 어느 경우든 길게 꼬리를 무는 것은 신뢰입니다: 사람 검토를 걷어내기 전에 출력을 평가하고 가드레일을 조이는 일은 대개 구축 그 자체보다 더 오래 걸립니다.