AI 에이전트 만들기: ops 워크플로우 자동화 완전 가이드

들어가며: 프레임워크 없이 에이전트 만들기

AI 에이전트 만들기 ops 워크플로우 자동화는 더 이상 선택이 아닙니다. 이제 필수입니다. Python 프레임워크나 6주 스프린트도 필요 없습니다. 핵심은 4가지 단계입니다: 작업 정의, 명령어 체이닝, 컨텍스트 연결, 안전장치 추가. 실제로 Ops 리더들이 쓰는 Deal Review, 리드 분석, CS 인수인계 작업이라면 구축 시간은 4시간 수준입니다. CommanderGPT 워크플로우 빌더를 쓰면 더 빠릅니다.

이것이 실무 가이드입니다.

에이전트와 프롬프트의 차이점

프롬프트는 한 번 답하고 멈춥니다. 에이전트는 루프를 돕니다. 태스크를 받으면 도구를 선택하고, 결과를 읽고, 다음 도구를 고르고, 작업이 끝날 때까지 반복합니다.

영업 Ops 리더 입장에서 생각해봅시다. 프롬프트라면 URL을 붙여넣으면 회사 요약이 한 번 나옵니다. 에이전트라면 CRM 큐에서 회사명을 가져와 공개 데이터를 검색하고, 지난 통화 메모를 확인하고, 3줄 요약을 쓰고, 미팅 준비 문서에 넣습니다. 같은 모델인데 활용도가 완전히 다릅니다.

Ops 버전 에이전트는 반사 루프나 다중 에이전트 오케스트레이션이 필요 없습니다. 세 가지만 있으면 됩니다: 명확한 입력, 고정된 도구 순서, 명확한 종료 조건.

1단계: 에이전트가 맡을 단 하나의 작업 정의하기

30초 브리핑. 워크플로우 빌더를 열기 전에 작업을 한 문장으로 정의하세요. 한 문장에 못 담으면 아직 자동화 준비가 덜 됐습니다.

좋은 예: "계정명이 주어지면 LinkedIn + 최근 뉴스 + 지난 통화 노트를 모아 3줄 거래 요약을 작성하기"

준비 안 된 예: "파이프라인 관리 도와주기"

Ops 작업 중 자동화가 잘 되는 것들은 주 10회 이상 반복하고, 입력과 출력 형식이 일정한 것들입니다. 통화 전 거래 리서치. 리드 리스트로 진행도 평가. CRM에서 주간 메트릭 요약. 고객 이관 전 핸드오프 요약.

하나를 선택하고, 한 번에 모든 걸 자동화하려는 욕심을 버리세요. 하루 안에 에이전트를 배포하는 팀들은 가장 작은 쓸모 있는 루프부터 시작합니다. 3주를 프레임워크에 묻힌 팀들은 여전히 작업을 정의하고 있습니다.

실용적인 필터: 주니어 분석가에게 명확한 지시를 주고 이 작업을 시킬 수 있나요? 그럼 에이전트 준비 완료입니다. 계속 판단이 필요하면 아직 아닙니다.

2단계: 명령어를 워크플로우로 체이닝하기

CommanderGPT 워크플로우 빌더를 여세요. 인터페이스는 선형 캔버스입니다: 각 블록이 명령어, 각 화살표가 한 단계에서 다음으로 가는 데이터입니다.

거래 리서치 에이전트라면 체인은 이렇습니다:

1. /research + 계정명: 회사 규모, 최근 뉴스, 알려진 pain points를 구조화된 요약으로 반환

2. /summarize + 리서치 결과: 150자로 압축, 보일러플레이트 제거

3. /draft-email + 요약 + 담당자명: 가장 최근 뉴스 항목을 첫 줄에 언급하는 아웃리치 이메일 작성

3개 명령어, 1개 워크플로우, 0개 마찰. 전체 체인이 계정당 40초 이내에 끝납니다. BDR 팀이 주 30개 계정을 돌린다면 담당자당 주 90분을 준비 시간으로 돌려받습니다.

체인을 위한 두 가지 규칙:

한 명령어는 한 가지 일을 합니다. 리서치와 이메일 작성을 하나의 /mega-research 명령어로 묶지 마세요. 작은 명령어는 결과가 잘못됐을 때 디버깅하기 쉽고, 다른 워크플로우에서 재사용하기 편합니다.

데이터 흐름에 이름을 붙입니다. 워크플로우 빌더의 각 블록은 명명된 출력 변수를 가집니다. account_brief, compressed_summary, outreach_draft 같은 이름을 사용하세요. 밤 11시에 QBR 전 무언가 깨지면 정확히 어느 단계가 실패했는지 알 수 있습니다.

3단계: 컨텍스트, 메모리, CRM 데이터 연결하기

컨텍스트 없는 명령어 체인은 여전히 빠른 프롬프트일 뿐입니다. 컨텍스트가 출력을 계정을 아는 사람처럼 만듭니다.

CommanderGPT의 30일 컨텍스트 메모리는 /research 명령어가 같은 계정과의 이전 통화, 담당자가 보낸 이전 이메일, HubSpot이나 Salesforce 통합으로 동기화된 CRM 노트를 끌어올 수 있다는 뜻입니다. 이건 수동으로 하는 게 아닙니다. 워크플로우 빌더 설정 패널에서 컨텍스트 소스를 정하면 명령어들이 자동으로 가져갑니다.

미팅 준비에서는 미팅 노트 입력을 워크플로우와 연결하세요. 팀이 AI 녹음 도구로 통화 노트를 캡처한다면, 최근 통화 녹음을 1단계 컨텍스트 블록으로 넣으세요. 에이전트가 다음 통화를 위해 만드는 요약은 지난 통화에서 뭐가 나왔는지 참조할 것입니다. 이게 일반 회사 요약과 실제 미팅 전 요약의 차이입니다.

뭘 끌어올지, 뭘 빼야 할지. 컨텍스트가 많다고 항상 좋은 건 아닙니다. 흔한 실수는 쓸 수 있는 모든 CRM 필드를 연결한 후 모델이 서로 무관한 데이터 사이에 환각으로 연결을 만드는 걸 보는 것입니다. 끌어올 것: 최근 상호작용 날짜, 최근 통화 노트, 공개 기회 단계, 알려진 이의. 뺄 것: 결제 내역, 3년 전 지원 티켓, 팀이 2024년부터 업데이트 안 한 필드.

측정하는 법: 잘 아는 계정 5개로 워크플로우를 돌려봅시다. 출력이 계정 이력을 읽은 사람이 쓴 것처럼 들리면 컨텍스트가 맞습니다. 모든 게 조심스럽게 들리면 입력에 잡음이 너무 많습니다.

4단계: 배포 전 안전장치 추가하기

이 단계가 대부분의 팀이 건너뛰는 부분입니다. 데모가 멋졌고 내일 QBR이 있거든요.

팀 전체가 워크플로우를 쓰기 전에 필수 불가결한 두 가지 안전장치가 있습니다.

루프에 캡을 씌웁니다. 워크플로우 빌더에서 모든 워크플로우는 max_steps 설정을 가집니다. 3단계 체인이면 10-15로 설정하세요. 캡이 없는 혼란스러운 에이전트는 예상치 못한 입력에 루프를 돌아 월간 토큰 예산을 다 써버립니다. 3단계 체인에서 8을 초과하면 경고를 설정하세요.

돌이킬 수 없는 동작 전에 확인 게이트를 추가합니다. 워크플로우의 마지막 단계가 이메일을 보내거나 Slack에 포스트한다면, 초안과 발송 사이에 사람이 확인하는 단계를 넣으세요. 명백해 보이지만 그렇지 않습니다. 몇 팀은 워크플로우 빌더의 자동완성이 /draft-email과 /send-email을 잘못 연결한 워크플로우를 배포했습니다. 200개 계정에 실수로 아웃리치를 보내는 비용이 확인 단계의 3분보다 훨씬 많이 듭니다.

20번 확인 게이트로 워크플로우를 돌려서 출력이 일정하게 좋아지면 게이트를 제거할 수 있습니다. 그 전에는 아닙니다.

Ops 에이전트가 첫 주에 실패하는 이유

실패 양식은 거의 항상 명령어 오류가 아니라 컨텍스트 부패입니다.

워크플로우가 월요일에는 잘 돕니다. 목요일이면 누구도 모르는 48시간 CRM 동기 지연 때문에 낡은 데이터를 끌어옵니다. 에이전트는 이걸 말해주지 않습니다. Q3 통화 노트 대신 화요일 통화를 참조하는 요약을 묵묵히 만들 뿐입니다.

핵심 규칙: 모든 워크플로우의 첫 블록에 컨텍스트 신선도 체크를 넣으세요. 간단한 /check-context-age 명령어가 최근 동기의 타임스탬프를 반환합니다. 데이터가 24시간보다 오래면 워크플로우는 낡은 입력에서 조용히 돌기 대신 경고를 띄웁니다.

두 번째 실패 양식은 프롬프트 드리프트입니다. 5월에 /research 명령어를 설정했습니다. 8월이면 ICP가 바뀌고, 아웃리치 형식이 바뀌고, 팀이 새로운 이의 처리 템플릿을 씁니다. 명령어는 여전히 돌지만 출력 형식이 아무도 안 쓰는 것이 됩니다. 6주마다 15분 워크플로우 검토를 정해놓으세요. 지난 10개 출력을 현재 플레이북과 비교합니다. 발산하면 명령어 프롬프트를 업데이트합니다.

세 번째 실패 양식은 팀 내부의 스코프 크리프입니다. 누군가 네 번째 명령어를 체인에 더합니다. 거의 맞았으니까요. 3주쯤 되면 워크플로우가 8개 명령어가 되고, 지연이 계정당 3분이 되고, 누구도 어느 명령어가 어느 출력 필드를 만드는지 모릅니다. 체인을 3-5개 명령어로 유지하세요. 더 필요하면 공유 출력 형식으로 두 개 워크플로우로 나눕니다.

지금 바로 포크할 수 있는 플레이북

CommanderGPT 템플릿 라이브러리에서 지금 당장 클론하고 쓸 수 있는 정확한 워크플로우입니다.

워크플로우: Deal Research + Outreach Draft

• 입력: 계정명 (CRM에서 붙여넣기 또는 직접 입력)

• 단계 1: /research + 계정명 + 컨텍스트 소스: 최근 통화 노트, 기회 단계

• 단계 2: /summarize 형식 제약: "3줄, 각 50자 이내, 가장 최근 뉴스를 먼저"

• 단계 3: /draft-email 톤: "직접적인, 첫 줄에서 특정 뉴스를 언급, 인사 없음"

• 출력: 요약 블록 + 이메일 초안, 클립보드로 복사

• 안전장치: 수동 발송 확인

• max_steps: 12

이 템플릿을 포크하고, CRM 통합을 연결하고, 잘 아는 3개 계정으로 돌려봅니다. 출력을 팀이 지금 수동으로 만드는 것과 비교합니다. 차이가 80% 품질보다 작으면 문제는 대부분 명령어가 아니라 컨텍스트 소스입니다.

워크플로우를 런칭하세요. 출력을 읽으세요. 배포하세요.

FAQ

Q: CommanderGPT 없이 이 워크플로우를 만들 수 있나요? A: 만들 수 있습니다. Zapier, n8n, Make 같은 일반 자동화 플랫폼을 쓰면 됩니다. 다만 LLM 컨텍스트 관리가 직접 손으로 해야 합니다. CommanderGPT는 CRM 메모리 동기와 토큰 추적을 자동으로 하므로 준비 시간을 줄입니다.

Q: 가장 흔한 에이전트 실패는 뭔가요? A: 컨텍스트 부패입니다. CRM 동기 지연이 24시간을 넘으면 에이전트 출력이 낡은 정보를 담습니다. 첫 번째 체크 블록으로 컨텍스트 신선도 확인을 항상 넣으세요.

Q: 한 번에 몇 개 명령어까지 체이닝할 수 있나요? A: 3-5개가 최적입니다. 8개 이상은 지연이 길어지고 디버깅이 어려워집니다. 더 필요하면 별도 워크플로우로 나누세요.

Q: 몇 시간마다 컨텍스트를 새로고침해야 하나요? A: CRM 동기 설정에 따라 다릅니다. 자동 동기가 6시간 주기면, 매 워크플로우 실행 전에 동기 체크를 하세요. 더 자주 새로고칠수록 더 신선한 데이터입니다.

Q: 여러 CRM을 연결할 수 있나요? A: 네, 있습니다. 하지만 필드 충돌을 조심하세요. 같은 이름의 필드가 두 CRM에 다른 형식이면 에이전트가 헷갈립니다. 명시적인 필드 매핑을 하거나 한 CRM을 주 소스로 정하세요.

Q: 컨텍스트 창이 가득 차면 어떻게 되나요? A: CommanderGPT는 가장 최근 메모와 상호작용부터 우선합니다. 낡은 항목은 자동 제거됩니다. 확인 gate로 어떤 컨텍스트가 쓰였는지 수동 검토를 할 수 있습니다.

Q: 프롬프트 드리프트를 방지하는 가장 좋은 방법은 뭔가요? A: 6주마다 워크플로우 리뷰를 정기적으로 하세요. 지난 10개 출력을 현재 팀 플레이북과 비교하고, 발산하는 부분이 있으면 명령어 프롬프트를 업데이트합니다.