AI 에이전트를 만들지 말아야 할 때 (대신 이렇게 하세요)

목차

2026년 8월 게시.

TL;DR: 대부분의 AI 에이전트 아이디어는 그 일에 맞지 않는 도구입니다. 저는 에이전트 코드를 한 줄이라도 쓰기 전에 다섯 가지 실격 신호를 확인합니다 — 불안정한 프로세스, 낮은 빈도, 합격/불합격 테스트 부재, 이미 작동하는 더 단순한 도구, 시간 안에 게이트를 만들 수 없는 되돌릴 수 없는 실패 모드. 이 중 하나라도 해당하면 저는 만들지 않습니다. 대신 더 저렴한 대안들의 사다리를 내려가고, 그 사다리의 어떤 것도 버티지 못할 때만 커스텀 에이전트로 돌아옵니다.

[운영자의 시각] 저는 컨설팅 브랜드와 텍사스주 프플러그빌에 있는 피클볼 시설 Pickleland에서 30개 이상의 프로덕션 에이전트를 운영하고 있습니다. 저는 지금까지 만든 에이전트만큼이나 많은 에이전트 아이디어를 죽여왔고, 그중 아이디어 자체가 나빠서 죽은 것은 거의 없습니다 — 그 특정 작업에 에이전트가 맞지 않는 도구였기 때문에 죽었습니다. 이 글은 “이걸 만들어야 하는가”가 “어떻게 만들 것인가”로 넘어가기 전에 제가 돌리는 필터입니다.

기본 답은 “아니요”다

제가 쓰는 ROI 프레임워크는 어떤 자동화가 구축 및 유지보수 비용을 회수하는지 알려줍니다. 그것이 올바른 두 번째 질문입니다. 첫 번째 질문은 더 단순한데도 계속 건너뜁니다: 이게 애초에 에이전트여야 하는가?

15년 전 화면과 관련된 모든 것에 “앱”이 기본 명칭이 되었던 것처럼, “에이전트”는 이제 LLM과 관련된 모든 것에 기본 명칭이 되었습니다. 모델과 접촉하는 모든 것이 트리거를 지켜보고 스스로 행동하는 상시적, 자율적, 도구 호출형 시스템을 필요로 하는 것은 아닙니다. 사람들이 “에이전트를 만든다”고 부르는 것의 상당수는 사실 “정말 좋은 프롬프트를 작성해서 직접 손으로 돌리는 것”이며, 이는 실패 모드가 아니라 종종 올바른 최종 상태입니다.

저는 “커스텀 에이전트를 만든다”를 여러 선택지의 사다리 중 가장 비싼 옵션으로 취급하지, 첫 번째 단이 아닙니다. 거기에 손을 뻗기 전에, 저는 그 작업이 스스로를 실격시키는지부터 확인합니다.

에이전트가 잘못된 도구라는 다섯 가지 신호

이 중 어느 하나라도, 그 자체만으로 보통 저를 멈추기에 충분합니다.

1. 프로세스가 아직 안정되지 않았다. 비즈니스 자체가 아직 무엇을 원하는지 알아가는 중이라서 워크플로우가 지난 한 달 동안 두 번 바뀌었다면, 에이전트는 곧 다시 바뀔 오늘 버전의 프로세스를 고정시켜 버립니다. 프로세스가 바뀔 때마다 프롬프트, 도구 스키마, 평가(eval) 세트를 다시 써야 합니다 — 즉 비즈니스를 운영하는 대신 에이전트를 유지보수하게 됩니다. 프로세스가 분기 동안 안정될 때까지 수동으로 운영한 다음, 정착된 버전을 자동화하세요.

2. 너무 드물게 실행되어 비용을 회수하지 못한다. 1년에 두 번 발생하는 작업은, 완성되면 아무리 성능이 좋아도 구축 시간, 테스트 시간, 평가 세트를 정당화할 만큼 충분한 실행 횟수를 쌓지 못합니다. 낮은 빈도에 높은 구축 노력이 드는 것은 자동화에 있어 최악에 가까운 조합입니다 — 전체 구축 비용을 지불하고도 절감 효과는 거의 거두지 못합니다.

3. 합격/불합격 테스트를 작성할 수 없다. 사전에, 올바른 출력이 어떤 모습인지 프로그래밍적으로 확인할 수 있을 만큼 충분히 설명할 수 없다면, 그것을 위한 평가 하네스를 만들 수 없습니다 — 그리고 평가할 수 없는 에이전트는 여러분이 눈감고 날고 있는 에이전트입니다. 순전히 취향(“이게 내 말투 같은가”)이거나 일관된 기준 없는 순전한 판단인 작업은 수동으로 남거나, 매번 사람이 검토해야 하며, 이는 자동화하는 취지 자체를 무너뜨립니다.

4. 더 단순한 도구가 이미 그 일을 하고 있다. 에이전트의 범위를 정하기 전에, 스프레드시트 수식, LLM 단계 하나짜리 Zapier/Make/n8n 워크플로우, 저장된 프롬프트가 무엇을 해줄 수 있는지 물어보세요. 정직한 답이 “90%는 거기까지 간다”라면, 나머지 10%가 자체 인프라, 모니터링, 유지보수 세금을 가진 에이전트를 세울 만큼의 가치를 갖는 경우는 드뭅니다. 저는 필터 뷰 하나와 반복되는 캘린더 알림 하나로도 똑같이 해결됐을 작업에 대해 에이전트 범위를 산정한 적이 있습니다.

5. 실패 모드가 되돌릴 수 없고, 게이트를 제대로 만들 시간이 없다. 대량 이메일 발송, 환불, 공개 게시물 같은 일부 행동은 되돌릴 수 없습니다. 휴먼 인 더 루프 게이트는 정확히 이런 경우를 위해 존재하지만, 아무도 실제로 검토하지 않는 급조된 게이트는 자동화가 아예 없는 것보다 나쁩니다 — 감독의 실체 없이 감독하는 것처럼 보이는 외관만 만듭니다. 게이트를 제대로 만들고 운영할 시간이 없다면, 그것은 게이트를 건너뛸 이유가 아니라 속도를 늦춰야 한다는 신호입니다.

다섯 가지 중 어느 것도 해당하지 않는다면 — 프로세스가 안정적이고, 충분히 자주 실행되며, 정답을 정의할 수 있고, 더 단순한 도구가 커버하지 못하며, 실패 모드가 되돌릴 수 있거나 제대로 게이트가 되어 있다면 — 그때는 ROI 계산을 돌려볼 가치가 있습니다.

만들기 전에 내려가는 사다리

작업이 다섯 가지 확인 중 하나에서 실패했을 때 — 또는 거기까지 가기도 전에 — 저는 이 목록을 순서대로 내려가며, 실제로 문제를 해결하는 첫 번째 단에서 멈춥니다.

1. 그냥 모델에게 직접 물어본다. 래퍼도, 도구 호출도, 상시 인프라도 없습니다. Claude를 열고, 맥락을 붙여넣고, 질문하고, 답을 사용하세요. 이는 사람들이 예상하는 것보다 훨씬 많은 일회성 및 가끔 발생하는 작업을 처리합니다. 단 한 번만 일어날 일에도 “에이전트” 본능이 발동하기 때문입니다.

2. 저장된 프롬프트나 프로젝트 지침. 같은 종류의 요청이 반복적으로 발생하지만 매번 사람이 입력값을 모으고 출력을 검토해야 한다면, 트리거를 자동화하는 대신 프롬프트를 템플릿으로 저장하세요 — 프로젝트 지침, 커스텀 지침 세트, 스니펫 등. 인프라 없이도 에이전트의 일관성 이점을 얻을 수 있습니다.

3. LLM 단계가 하나뿐인 노코드 자동화 도구. 진짜로 트리거(새 폼 제출, 시트의 새 행)가 필요하지만 로직 자체는 단순한 작업이라면, 중간에 모델 호출이 하나 있는 워크플로우 도구가 커스텀 코드보다 훨씬 저렴하게 만들고 유지보수할 수 있습니다. 저는 트리거가 표준적이고 물량이 적당하거나 낮을 때는 커스텀 인프라보다 이걸 먼저 씁니다.

4. 수동으로 운영하는 템플릿. 어떤 프로세스는 자동화보다 체크리스트에서 더 큰 이득을 얻습니다. 가치가 속도가 아니라 사람이 각 단계를 생각하는 데 있기 때문입니다. 생각하는 것 자체가 핵심인 작업에서는 그 생각을 자동화로 없애지 마세요.

5. 아웃소싱. 평가 세트를 만들고 유지할 시간이 없는, 진짜 모호함이나 판단이 필요한 일이라면, 사람 — VA, 전문가, 제품화된 서비스 제공자 — 이 여전히 튜닝 중인 에이전트보다 더 빨리 가동시킬 수 있고 중간에 바로잡기도 더 쉬운 경우가 많습니다.

6. 그제야: 커스텀 에이전트. 사다리를 다 내려갔는데도 아무것도 버티지 못한다면 — 트리거에 부하 상태에서 진짜 판단이 필요하고, 물량이 수동이나 아웃소싱으로 처리하기엔 너무 많으며, ROI 계산도 통과한다면 — 그때가 바로 자체적인 신뢰성 스택을 갖춘 전용 에이전트가 그 구축 비용을 정당화하는 순간입니다.

2주짜리 섀도 테스트

경계에 걸쳐 있는 작업 — 다섯 가지 확인은 통과했지만 여전히 확신이 서지 않는 경우 — 에 대해서는, 구축을 결정하기 전에 2주짜리 섀도 테스트를 돌립니다. 저는 그 작업을 직접 수행하되, 모델을 자율 시스템이 아니라 코파일럿으로 씁니다: 결국 에이전트에게 줄 것과 같은 프롬프트, 같은 입력값을 쓰지만, 어디로 나가기 전에 모든 출력을 제가 직접 읽습니다.

이 테스트에서 두 가지가 나옵니다. 첫째, 모델이 제가 필요로 하는 품질 기준에서 실제로 그 작업을 잘 해내는지 — 만약 출력의 절반을 제가 직접 다시 써야 한다면, 다른 모든 것과 무관하게 그 작업은 자동화할 준비가 안 된 것입니다. 둘째, 진짜 평가 세트 — 2주 동안의 입력값과 제가 옳다고 판단한 출력값은 평가 하네스에 정확히 필요한 것이며, 만들기로 결정할 즈음에는 보통 그것을 공짜로 이미 확보한 상태입니다.

섀도 테스트는 또한 프로덕션에 들어가기 전에 엣지 케이스를 드러냅니다. 입력값의 15%가 특별한 처리가 필요하다는 것을 수동 테스트에서 발견하는 것이, 에이전트가 출시된 후 고객 불만으로 발견하는 것보다 훨씬 저렴합니다.

아이디어를 죽인 후 적용하는 규칙

에이전트 아이디어를 죽이는 것과 근본적인 문제를 죽이는 것은 다릅니다. 어떤 작업이 지금 스스로를 실격시켰다면 — 프로세스가 여전히 변하고 있거나, 물량이 너무 낮거나 — 저는 그 이유를 적어두고 대략적인 재검토 시점을 정해둡니다(보통 특정 날짜가 아니라 특정 트리거에 연결합니다: “예약이 주 50건을 넘으면 재검토”). 한 번 죽은 뒤 다시 검토되지 않는 에이전트 아이디어는 조용히 아무도 두 번 평가했는지 기억하지 못하는 영구적인 수작업으로 변합니다.

역방향의 규율도 그만큼 중요합니다: 다섯 가지 확인과 ROI 계산을 통과한 아이디어가 오늘 자동으로 만들어지는 것은 아닙니다. 이미 비용 회수가 입증된 다른 자동화들과 함께, 그 아이디어도 같은 대기열에 들어가 우선순위가 매겨집니다. 필터를 통과하는 것은 대기열의 자리를 얻는 것이지, 우선순위 평가에서 면제되는 것이 아닙니다.

FAQ

이건 그냥 자동화 반대 주장 아닌가요?

아닙니다 — 이는 가장 비싼 형태의 자동화를 기본값으로 삼는 것에 반대하는 주장입니다. 위 사다리에 나온 대안들 대부분도 여전히 자동화입니다. 그저 더 가벼울 뿐입니다. 저는 수십 개의 프로덕션 에이전트를 운영합니다. 요점은 만들기를 피하는 것이 아니라, 저장된 프롬프트나 노코드 워크플로우가 구축 및 유지보수 비용의 일부만으로 같은 결과를 줄 때 곧바로 “커스텀 에이전트를 만든다”로 건너뛰는 것을 멈추는 것입니다.

그 작업의 물량이 나중에 확실히 늘어난다면요?

그건 현재 숫자보다 앞서서 만들 정당한 이유입니다 — 저는 이 예외를 ROI 프레임워크에서 다룹니다. 다만 위의 다섯 가지 신호를 무효화하지는 않습니다. 프로세스가 아직 불안정하거나 정답을 아직 정의할 수 없다면, 늘어나는 물량은 그저 더 큰 규모에서 고장 난 에이전트를 유지보수하게 된다는 뜻일 뿐입니다. 불안정성과 테스트 가능성을 먼저 해결하세요. 규모는 그것들이 해결된 뒤 더 빨리 만들 이유이지, 건너뛸 이유가 아닙니다.

노코드 도구 단계가 “충분히 좋은지” 커스텀 코드가 필요한지 어떻게 아나요?

일단 시도해보고, 비공식적인 것이라도 평가 세트와 비교해서 측정하세요. 노코드 LLM 단계는 단일 목적, 단일 입력 작업을 잘 처리합니다. 다단계 도구 사용, 실행 간 지속되는 상태, 도구 빌더가 깔끔하게 표현할 수 없는 조건부 로직이 필요해지면 한계에 부딪힙니다. 그 벽에 부딪히면, 그것이 커스텀 인프라로 옮겨갈 진짜 신호입니다 — 처음부터 거기서 시작할 이유는 아닙니다.

내부용 도구와 고객 대상 도구에 이게 다르게 적용되나요?

다섯 가지 신호는 똑같이 적용되지만, 위험 수위가 다릅니다. 프로세스가 불안정한 내부 도구는 고장 나면 여러분 팀의 시간만 낭비합니다. 프로세스가 불안정한 고객 대상 도구는 여러분의 평가 세트가 되는 데 동의한 적 없는 사람들과의 신뢰를 갉아먹습니다. 저는 특히 다섯 번째 신호를 고객 대상 자동화에서는 더 엄격한 버전으로 적용합니다 — 실수의 반대편에 동료가 아니라 낯선 사람이 있을 때, “제대로 게이트되었다”의 기준은 더 높아야 합니다.

에이전트 아이디어를 죽이는 가장 흔한 이유는 무엇인가요?

세 번째 신호입니다 — 깔끔한 합격/불합격 테스트가 없는 경우입니다. 범위를 정하는 동안 놓치기 가장 쉬운 신호인데, 사전에 올바른 출력이 실제로 어떤 모습인지 적어보려고 시도하기 전까지는 작업이 잘 정의된 것처럼 느껴지기 때문입니다. 그것을 한두 문장으로 적을 수 없다면, 그 에이전트는 평가 불가능해질 것이고, 그것은 곧 개선 불가능해진다는 뜻이며, 아직은 만들어지지 않는다는 뜻입니다.