AI 에이전트: 코딩 없이 나만의 미니 팀 만들기
이 시리즈에서 지금까지 프롬프팅에 대해 이야기했다 — AI에게 작업을 주고 결과를 받는 것. 프롬프트 하나, 응답 하나. 묻고 답하는 것.
AI 에이전트: 코딩 없이 나만의 미니 팀 만들기
"AI로 만들기" 시리즈 7편
이 시리즈에서 지금까지 프롬프팅에 대해 이야기했다 — AI에게 작업을 주고 결과를 받는 것. 프롬프트 하나, 응답 하나. 묻고 답하는 것.
유용하다. 하지만 한계도 있다. 실제 업무의 대부분은 단일 교환으로 일어나지 않기 때문이다. 시퀀스로 일어난다. 단계 A가 단계 B를 트리거한다. 단계 B의 결과가 단계 C로 들어간다. 외부의 무언가 — 이메일, 폼 제출, 캘린더 이벤트 — 가 전체를 시작한다. 그리고 마지막에 결과가 어딘가로 간다: 받은편지함, 스프레드시트, Slack 채널.
바로 여기서 AI 에이전트가 등장한다.
에이전트는 질문에 답하는 AI가 아니다. 행동하는 AI다 — 일련의 단계를 계획하고, 도구를 사용하고, 결정을 내리고, 최소한의 인간 개입으로 목표를 완수할 수 있는. 지시를 기다리는 스마트 어시스턴트와 목표를 받고 단계를 스스로 파악하도록 신뢰할 수 있는 어시스턴트의 차이다.
그리고 2026년의 놀라운 것: 코드 한 줄 없이 에이전트를 만들 수 있다.
무엇이 "에이전트"를 만드는가
"에이전트"라는 단어가 많이 사용된다. 정밀하게 살펴보자.
기본 AI 상호작용은 이렇게 생겼다: 당신 → 프롬프트 → AI → 응답 → 당신
에이전트 상호작용은 이렇게 생겼다: 트리거 → 에이전트 → [계획 → 도구 → 결정 → 도구 → 결정...] → 출력 → 목적지
핵심 차이점:
에이전트는 트리거를 가진다. 채팅 창을 열 때까지 기다리지 않는다. 무언가가 일어날 때 활성화된다 — 새 이메일이 도착하거나, 폼이 제출되거나, 예약된 시간이 되거나, 스프레드시트에 새 행이 나타날 때.
에이전트는 도구를 사용한다. 웹을 검색하고, 파일을 읽고, 데이터베이스에 쓰고, 이메일을 보내고, API를 호출하고, 코드를 실행할 수 있다. 컨텍스트 윈도우를 넘어 실제 세계로 뻗을 수 있다.
에이전트는 결정을 내린다. 분기점에서 — 만약 이것이면, 그러면 저것 — 상황을 평가하고 경로를 선택한다. 텍스트만 생성하는 게 아니라 조건부 선택을 한다.
에이전트는 작업이 아닌 목표를 가진다. 작업은 "이 문서를 요약해줘"다. 목표는 "경쟁사 가격 페이지를 모니터링하고 변경될 때마다 무엇이 변했고 왜 중요할 수 있는지 요약과 함께 나에게 알려줘"다.
에이전트의 세 가지 레벨
모든 에이전트가 같지 않다. 세 가지 레벨로 생각하면 도움이 된다:
레벨 1 — 트리거된 자동화 무언가가 일어날 때 자동으로 실행되고, 고정된 일련의 단계를 실행하고, 결과를 전달하는 워크플로우. 진짜 의사결정 없음 — 정의된 프로세스의 신뢰할 수 있는 자동 실행만.
예시: 새로운 잠재 고객이 연락 폼을 작성할 때마다 LinkedIn에서 자동으로 찾아보고, 그들이 누구인지 개인화된 한 단락 요약을 생성하고, 팀이 리드를 보기 전에 CRM 노트에 추가한다.
도구: n8n 또는 Make.com, 생성 단계에 AI 포함.
레벨 2 — 의사결정 에이전트 AI가 무언가를 평가하고 발견한 것에 따라 다른 결과로 라우팅하는 조건부 논리가 포함된 워크플로우.
예시: 고객 지원 이메일이 도착하면 에이전트가 읽고, 분류하고(청구 문제 / 기술 문제 / 기능 요청 / 불만), 고객이 프리미엄 플랜에 있는지 확인하고, 그에 따라 라우팅한다 — 다양한 조합에 대해 다른 응답 템플릿으로.
도구: 여러 분기가 있는 n8n, 결정 지점에서 AI 분류.
레벨 3 — 목표 지향 에이전트 스크립트가 아닌 목표가 주어지는 에이전트 — 그리고 그것을 달성하기 위한 자체 단계를 파악한다. 계획하고, 순서대로 도구를 사용하고, 중간 결과를 평가하고, 접근 방식을 조정할 수 있다.
예시: "에너지 관리 분야 한국 스마트시티 스타트업 상위 5개를 조사하고, 제품 설명, 최근 펀딩, 핵심 차별점을 컴파일하고, 포맷된 비교 보고서를 만들어줘."
에이전트가 검색하고, 읽고, 추출하고, 구성하고, 작성한다 — 어떤 소스를 사용할지, 충분한 정보가 있을 때, 결과물을 어떻게 구성할지 결정하면서.
도구: 도구 접근이 있는 Claude Opus 4.6 또는 GPT-5.2, 또는 더 복잡한 오케스트레이션을 위한 Relevance AI나 Claude Code 같은 플랫폼.
첫 번째 에이전트 만들기: 실제 워크스루
실제 무언가를 만들어보자. 가장 강력한 무료/오픈소스 자동화 도구인 n8n을 사용해 레벨 1 에이전트를 만들겠다.
목표: 경쟁사 웹사이트 목록을 모니터링한다. 매주 월요일 아침, 가격 페이지가 업데이트됐는지 확인하고, 업데이트됐다면 변경된 내용 요약과 함께 Slack 메시지를 보낸다.
1단계: 트리거 n8n에서 Schedule 노드를 만든다. 매주 월요일 오전 8시에 실행하도록 설정한다. 이것이 트리거다 — 에이전트가 아무것도 하지 않아도 자동으로 깨어난다.
2단계: 데이터 소스 모니터링하려는 각 경쟁사 URL에 대해 HTTP Request 노드를 추가한다. 이것이 가격 페이지의 현재 콘텐츠를 가져온다.
3단계: 비교 오늘 콘텐츠를 지난 주 저장된 버전과 비교하는 Function 노드를 추가한다. 일치하면 — 중지. 일치하지 않으면 — 다음 단계로 계속.
4단계: AI 분석 AI 노드를 추가한다(n8n은 네이티브 Claude와 OpenAI 통합을 가지고 있다). 이 프롬프트와 함께 이전 및 새 콘텐츠를 전달한다:
"이 경쟁사 가격 페이지의 두 버전을 비교하라. 다음을 식별하라: (1) 무엇이 변했는지, (2) 가격이 올랐는지 내렸는지, (3) 추가되거나 제거된 새 플랜이나 기능, (4) 그들이 이 변경을 했을 수 있는 이유에 대한 평가. 구체적이고 간결하게."
5단계: 출력 Slack 노드를 추가한다. 경쟁사 이름, 날짜, 요약으로 포맷된 AI 분석을 #competitive-intel 채널에 보낸다.
6단계: 새 버전 저장 다음 주와 비교하기 위해 오늘 콘텐츠를 저장한다.
총 설정 시간: 45-60분. 코드 없음. 그 후 매주 월요일 자동으로 실행된다 — 실제로 무언가 변할 때만 보게 된다.
이게 에이전트다. 깨어나고, 확인하고, 행동할지 결정하고, 지능적으로 행동하고, 필요한 곳에 결과를 전달한다.
지금 일어나고 있는 것: 에이전트의 최전선
위의 기본 에이전트 프레임워크는 오늘 당장 만들 수 있는 것들이다. 하지만 최전선은 빠르게 움직이고 있다 — 2026년에 등장하고 있는 것들은 아직 그 수준에서 만들 준비가 안 됐더라도 이해할 가치가 있다.
에이전트 스웜: 병렬로 작동하는 여러 에이전트
단일 에이전트는 하나의 작업 흐름을 처리한다. 에이전트 스웜은 병렬로 작동하는 여러 전문화된 에이전트의 조율된 네트워크다 — 각각 다른 하위 작업을 처리하고 결과물을 결합한다.
프로젝트 팀처럼 생각하라. 한 명의 제너럴리스트 에이전트가 모든 것을 순차적으로 하는 대신:
- 리서치 에이전트 — 소스를 검색하고 읽는다
- 작성 에이전트 — 리서치를 기반으로 초안을 작성한다
- 비평 에이전트 — 검토하고 약점을 표시한다
- 편집 에이전트 — 최종 결과물을 다듬는다
각각 동시에 실행된다. 오케스트레이터가 결과를 결합한다. 전체 작업이 단일 순차적 에이전트보다 몇 배 빠르게 완료된다.
OpenClaw (에이전트 상호운용성을 위한 오픈 프로토콜), LangGraph, CrewAI가 스웜을 조율하는 데 사용하는 도구들이다. CrewAI는 특히 비개발자에게 인기를 얻고 있다 — 각 에이전트의 역할, 도구, 목표를 일상 언어로 정의하면 프레임워크가 조율을 처리한다. Claude Code도 네이티브로 멀티 에이전트 설정을 지원한다.
실제 스웜 사례:
- 투자자 리서치: 에이전트 1이 재무 데이터를 가져오고, 에이전트 2가 뉴스를 추적하고, 에이전트 3이 경쟁사 공시를 분석 — 모두 병렬로, 단일 브리핑으로 결합
- 콘텐츠 파이프라인: 에이전트 1이 주제를 리서치하고, 2가 작성하고, 3이 사실 확인하고, 4가 SEO 최적화 — 전체 파이프라인이 자율적으로 실행
- 대규모 고객 지원: 청구, 기술 문제, 계정 관리를 전문화된 에이전트들이 동시에 처리하고 라우팅 에이전트가 트래픽을 조율
AI 직원: 완전한 도구 접근
지금 가장 많은 대화를 만들어내고 있는 개념이다 — 그리고 가장 정당한 흥분을 자아내는. AI 직원은 단순한 데이터 접근이 아닌 실제 운영 능력을 부여받은 에이전트다:
- 결제 권한 — Stripe Agent Toolkit 같은 서비스를 통해 정의된 한도 내에서 승인된 거래를 실행할 수 있는 에이전트 (도구 구매, API 호출 결제, 구독 갱신)
- 전화와 음성 — 실제 전화를 걸고 받고, 음성 메일을 남기고, 전화 기반 시스템과 상호작용할 수 있는 전화번호를 가진 에이전트. Bland AI와 Vapi 같은 도구들이 실제 전화 통화를 처리하는 에이전트를 배포할 수 있게 한다 — 대부분의 사람에게 인간 상담원과 구별 불가능
- 이메일 아이덴티티 — 정의된 가드레일 내에서 당신을 대신해 서신을 수행할 수 있는 자체 이메일 주소를 가진 에이전트
- 브라우저와 컴퓨터 사용 — 웹사이트를 탐색하고, 양식을 작성하고, 버튼을 클릭하고, 소프트웨어를 조작할 수 있는 에이전트 — API만 호출하는 게 아니라 인간이 사용하는 것과 같은 인터페이스 실제 사용. Anthropic의 Computer Use (Cowork), OpenAI의 Operator, Google의 Project Mariner가 모두 이것을 개척 중
- 코드 실행과 배포 — 코드를 작성하고, 테스트를 실행하고, 프로덕션 저장소에 변경 사항을 푸시할 수 있는 에이전트. Cognition의 Devin (AI 소프트웨어 엔지니어)이 이 범주의 대표 사례
Artisan, Relevance AI, 11x 같은 회사들은 이미 "AI SDR"(영업 개발 담당자)을 판매하고 있다 — 잠재 고객을 발굴하고, 리서치하고, 개인화된 아웃리치를 작성하고, 팔로업하고, 이의를 처리하고, 미팅을 예약하는 에이전트. 24/7 완전 자동화.
실제 함의: 공급업체 온보딩 프로세스를 처리하는 에이전트는 이제 이메일을 초안 작성할 뿐만 아니라 보내고, 팔로업하고, 청구서를 처리하고, 회계 시스템을 업데이트할 수 있다 — 사람이 모든 단계가 아닌 예외만 검토하면서 처음부터 끝까지.
중요한 가드레일: AI 직원 역량의 모든 진지한 구현에는 지출 한도, 액션 로그, 고위험 액션에 대한 승인 워크플로우, 즉각적인 취소 메커니즘이 포함된다. 목표는 감독 없는 자율성이 아니다 — 인간이 경계를 설정하고 예외를 검토하는 대규모 감독 자율성이다.
MCP: 에이전트를 연결하는 결합 조직
위의 모든 것 — 기본 레벨 1 자동화부터 완전한 AI 직원 설정까지 — 의 기반에는 2편에서 처음 논의한 MCP(Model Context Protocol)가 있다.
MCP는 에이전트가 불안정한 맞춤 통합이 아닌 표준화된 인터페이스를 통해 외부 서비스에 연결할 수 있게 한다. 에이전트가 Google Drive, Gmail, Slack, GitHub, CRM, 회계 도구에 네이티브로 접근할 수 있다 — 어떤 에이전트 프레임워크도 사용할 수 있는 성장하는 표준화된 커넥터 라이브러리를 통해.
에이전트 스웜이 실용화되고 있는 이유가 이것이다: 모든 에이전트가 같은 연결 프로토콜을 사용하면 다양한 서비스에 걸쳐 에이전트를 조율하는 것이 극적으로 단순해진다. 그리고 AI 직원 개념이 가속화되는 이유다 — 에이전트가 MCP를 통해 결제 시스템, 전화 API, 브라우저 인터페이스에 연결할 수 있으면 운영 능력이 빠르게 확장된다.
에이전트 도구나 플랫폼을 평가할 때 MCP를 지원하는지 물어봐라. 지원하는 것들은 커넥터 라이브러리가 성장함에 따라 시간이 지나면서 능력이 복리로 쌓인다.
메모리와 커뮤니케이션: 에이전트가 시간을 넘어 생각하는 방법
에이전트를 이해하고 나면 자연스럽게 생기는 질문이 있다. 에이전트는 뭔가를 기억하는가? 여러 에이전트가 함께 작동할 때 어떻게 서로 소통하는가?
맞는 질문들이다 — 그리고 답은 대부분의 입문 자료가 다루는 것보다 훨씬 미묘하다.
에이전트 메모리의 네 가지 유형
인컨텍스트 메모리 (단기) 에이전트의 활성 작업 메모리다 — 현재 컨텍스트 윈도우에 있는 모든 것. 현재 세션에서 보고, 하고, 말한 것들. 빠르고, 즉시 접근 가능하고, 세션이 끝나면 완전히 사라진다. 컴퓨터의 RAM처럼 생각하라. 실행 중에는 강력하다. 끄면 지워진다.
100만 토큰 컨텍스트 윈도우도 긴 다단계 워크플로우 동안 채워진다. 채워지면 오래된 내용이 삭제되거나 요약된다. 이것을 잘 관리하지 않는 에이전트는 이전 단계를 "잊기" 시작한다.
외부 메모리 (장기) 에이전트는 외부 저장소 — 데이터베이스, 파일, 스프레드시트, 또는 특화된 메모리 저장소 — 에서 읽고 쓸 수 있다. 세션 간에 유지되는 영속적 메모리다. 에이전트가 실행 간에 무언가를 기억해야 할 때 — 고객의 이력, 이전 결정, 지난 주에 배운 사실 — 외부 저장소에 쓰고 다음에 검색한다.
Mem0과 Zep 같은 도구들이 이를 위해 특별히 만들어졌다. 메모리를 검색 가능한 임베딩으로 저장해 에이전트가 모든 것을 로드하는 대신 관련 맥락을 검색할 수 있다. 이것이 "개인 어시스턴트" 에이전트가 시간이 지나면서 실제로 당신을 아는 것처럼 느끼게 만드는 것이다.
절차적 메모리 (내장된 기술) 이것은 모델의 훈련이다 — 본질적으로 할 수 있는 것. 코드 쓰기, 텍스트 요약, 데이터 분석. 런타임에 추가할 수 없다; 모델 버전별로 고정되어 있다. 하지만 에이전트가 행동할 수 있는 것을 확장하는 도구와 지침을 줌으로써 확장할 수 있다.
에피소딕 메모리 (행동 이력) 에이전트가 한 것의 로그 — 과거 도구 호출, 과거 결과물, 과거 결정들. 외부에 저장되고 새 세션 시작 시 검색되어 에이전트가 "지난 번에 무슨 일이 있었는지" 이해할 수 있도록. 중복 행동과 무한 루프를 피하는 데 핵심이다.
에이전트들이 서로 소통하는 방법
스웜이나 멀티 에이전트 시스템에서 에이전트들은 조율이 필요하다. 세 가지 주요 패턴:
공유 메모리 (블랙보드 패턴) 모든 에이전트가 공유 데이터 저장소에서 읽고 쓴다. 에이전트 1이 조사 결과를 블랙보드에 쓴다. 에이전트 2가 그것을 읽고 초안을 쓴다. 에이전트 3이 초안을 읽고 편집한다. 에이전트 간 직접 메시징 없음 — 공유 상태를 통해 조율한다. 단순하고, 신뢰할 수 있고, 디버그하기 쉽다. 대부분의 프로덕션 시스템에서 선호되는 패턴이다.
직접 메시징 (메시지 패싱) 에이전트들이 구조화된 메시지를 서로에게 직접 보낸다 — 팀원 간의 Slack DM처럼. 에이전트 1이 그것으로 무엇을 할지 명시적 지침과 함께 결과물을 에이전트 2에게 보낸다. CrewAI와 AutoGen 같은 프레임워크가 이 모델을 사용한다. 에이전트들은 정의된 역할을 가지고 메시지 큐를 통해 작업을 넘긴다.
오케스트레이터 패턴 중앙 "관리자" 에이전트가 워크플로우를 제어한다. 워커 에이전트들에게 작업을 할당하고, 그들의 결과물을 수집하고, 품질을 평가하고, 다음 단계를 결정한다 — 기대에 미치지 못하면 수정을 위해 다시 보내는 것 포함. 이것은 훌륭한 인간 관리자가 팀을 운영하는 방식을 반영한다. 오케스트레이터는 전체 그림을 가진다; 워커들은 전문화된 하위 작업을 처리한다. 대부분의 엔터프라이즈급 에이전트 시스템이 이것의 어떤 형태를 사용한다.
실제로 문제가 되는 메모리 이슈
대부분의 사람들이 뭔가를 만들어보기 전까지 깨닫지 못하는 것: 에이전트는 자신이 이미 한 것을 자동으로 알지 못한다.
다단계 워크플로우에서, 에이전트가 진행 상황을 명시적으로 기록하지 않으면 중간에 실패하면 처음부터 다시 시작해야 한다. 다음 주에 다시 실행되면 이미 처리한 것을 전혀 모른다 — 다시 처리한다.
이것은 에이전트에 고유한 버그 카테고리를 만든다:
- 중복 행동 — 에이전트가 처음 보낸 것을 기록하지 않았기 때문에 같은 이메일을 두 번 보낸다
- 잃어버린 맥락 — 에이전트가 워크플로우 앞에서의 관련 이전 결정을 모르고 결정을 내린다
- 무한 루프 — 에이전트가 실패했다는 기록 없이 실패한 것을 계속 재시도한다
해결책은 명시적 상태 관리다 — 모든 의미 있는 단계에서 외부 저장소에 체크포인트를 쓰는 것. 에이전트가 항상 답할 수 있도록: 무엇을 했는가, 아직 무엇을 해야 하는가, 무엇이 실패했는가? 모든 진지한 에이전트 프레임워크에는 이를 위한 패턴이 있다. 화려하지 않다. 하지만 신뢰할 수 있는 프로덕션 에이전트와 실제 세계에서 망가지는 데모를 가르는 것이 바로 이것이다.
흔한 실수들
망가진 프로세스를 자동화하기 에이전트는 나쁜 프로세스를 열 배 속도로 충실히 실행한다. 자동화하기 전에 기본 프로세스가 실제로 맞는지 확인해라. 자동화는 증폭시킨다 — 좋은 것도 나쁜 것도.
중요한 출력에 인간 체크포인트 없음 고객, 파트너, 또는 외부 세계에 닿는 모든 것 — 항상 발송 전에 인간 검토 단계를 구축해라. 초안을 작성하는 에이전트는 강력하다. 검토 없이 발송하는 에이전트는 책임이다.
첫 번째 버전 과도하게 엔지니어링 레벨 1로 시작해라. 매주 두 시간을 절약하는 단순한 트리거된 자동화가 만드는 데 몇 주 걸리고 자주 망가지는 복잡한 레벨 3 에이전트보다 더 가치 있다. 단순한 버전이 작동하게 하고, 그것에서 배우고, 그 다음 복잡성을 추가해라.
실패 계획 없음 외부 서비스는 다운된다. API는 변한다. 페이지가 404를 낸다. 모든 에이전트에 오류 처리를 구축해라 — 단계가 실패하면 무슨 일이 일어나야 하는가? 최소한, 무언가 망가졌다는 것을 알 수 있도록 알림을 자신에게 보내라.
첫 번째 에이전트 도전
야심찬 것으로 시작하지 마라. 귀찮은 것으로 시작해라.
매번 같은 단계를 따르는 반복적으로 하는 무언가를 생각해보라. 15-30분이 걸리고, 최소 매주 일어나고, 사람이 필요하지 않아야 할 것 같은 것. 컴파일하는 보고서. 보내는 업데이트. 실행하는 점검. 작성하는 요약.
그게 첫 번째 에이전트 후보다.
먼저 종이에 단계를 매핑해라. 무엇이 트리거하는가? 순서대로 단계들은 무엇인가? 현재 인간 결정이 어디에서 일어나는가 — 그리고 규칙이 그 결정을 대체할 수 있는가? 결과물은 무엇이고 어디로 가는가?
그 지도가 생기면 n8n이나 Make.com을 열고 만들어라. 레벨 1로 시작해라. 실행되게 해라. 그 다음 한 달 동안 혼자 실행되는 것을 지켜봐라 — 그리고 추가하고 싶은 것을 주목해라.
더 깊이 배우고 싶다면
이 글은 에이전트의 기초를 다뤘다. 송재희의 AI Development Guide는 더 깊이 들어간다 — 멀티 에이전트 아키텍처, 특정 비즈니스 도메인을 위한 에이전트 워크플로우 설계 방법, 에이전트를 이전 포스트에서 다룬 프롬프팅 및 데이터 기반과 결합하는 방법 포함.
📱 Apple Books ▶️ Google Play Books 🌐 전 플랫폼 구매 (Books2Read)
다음 편: "바이브 코딩 — 일상 언어로 실제 앱 만들기" — 아이디어에서 코드 한 줄 없이 배포된 작동하는 애플리케이션으로 가는 방법.