한 팀이 들어오는 고객 지원 이메일을 분류하고 라우팅하기 위해 "에이전트 (agent)"의 범위를 설정합니다. 모델은 각 이메일을 읽고 카테고리를 라벨링하며, 몇 가지 결정론적 (deterministic) 분기(branches)가 이를 적절한 대기열로 보냅니다. 이것은 단 한 번의 모델 호출이 포함된 Power Automate 플로우 (flow)입니다. 이를 에이전트로 구축하면 비결정론 (non-determinism), 평가 부담, 실시간 비용 지출 위험을 떠안게 되지만, 그 대가로 얻는 것은 아무것도 없습니다. 왜냐하면 분기(branches)가 이미 수행하고 있는 일 외에 에이전트가 내려야 할 결정이 전혀 없었기 때문입니다.

대부분의 AI 에이전트 프레임워크 (AI agent frameworks)는 구조적으로 구축 가이드에 가깝습니다. 이들은 에이전트를 설계하는 방법을 보여주는 데 매우 능숙하지만, 이는 곧 그들이 당신을 대신해 내릴 수 없는 단 하나의 결정, 즉 에이전트를 구축할지 여부에 대해서는 결정할 수 없음을 의미합니다. 그 결정은 대개 "아니오" 또는 "아직은 아님"이며, 이 결정을 올바르게 내리는 것이야말로 시니어 아키텍트 (senior architect)가 실제로 보수를 받는 부분입니다. 에이전트는 업무를 수행하는 방법이라는 사다리에서 가장 유능하고, 가장 비싸며, 예측 불가능성이 가장 높은 단계입니다. 대부분의 문제는 한두 단계 낮은 단계에서 더 잘 해결됩니다. 이 글은 문제를 해결할 수 있는 가장 낮은 단계를 찾는 방법, 팀을 진정으로 곤경에 빠뜨리는 경계선, 그리고 에이전트가 그 비용을 정당화하는 사례에 대한 명확한 테스트에 대한 가이드입니다.

요약 (TL;DR)

• 작동하는 가장 낮은 단계부터 시도하세요: 프로세스를 수정하거나, 쿼리(Query)를 개선하거나, 결정론적 흐름 (Deterministic flow)을 구축하거나, 단일 모델 호출 (Single model call)을 적용한 뒤, 마지막에 에이전트 (Agent)를 고려하세요. 단계가 올라갈수록 비용과 예측 불가능성이 급격히 상승합니다.
• 팀을 혼란에 빠뜨리는 경계선은 '모델 호출을 포함한 흐름 (Flow-with-a-model-call)'과 '에이전트 (Agent)' 사이의 차이입니다. 만약 모델이 판단을 내리고 그 주변 단계들이 고정되어 있다면, 그것은 흐름 (Flow)입니다. 만약 다음 단계가 모델이 방금 찾아낸 결과에 따라 달라진다면, 그것은 에이전트 (Agent)입니다.
• 에이전트는 데모에서는 숨겨지는 '세금 (Tax)'을 수반합니다: 비결정론성 (Non-determinism), 지속적인 평가 (Evaluation) 관행, 실시간 비용 리스크, 그리고 그 밑바탕이 되는 데이터 작업이 그것입니다. 도입을 결정하기 전에 예산을 책정하세요.
• 아래의 5가지 질문 테스트를 통해 대부분의 의사결정을 몇 분 안에 내릴 수 있으며, 5가지 답변 중 보통 2가지는 "에이전트보다 저렴한 무언가를 구축하라"로 귀결됩니다.

사다리 (The ladder)

문제를 역량이 증가하고 예측 가능성이 감소하는 사다리 위에 배치하고, 문제를 해결할 수 있는 가장 낮은 단계의 발판을 선택하세요.

단계 (Rung)	사용 시점	비용 (대가)
없음 (프로세스 수정)	두 시스템 간의 불일치로 인해 작업이 발생하는 경우	상류 데이터 소유권 문제, 자동화가 아님
...

실수는 맨 위에서 시작하여 강요받을 때만 아래로 내려가는 것입니다. 맨 아래에서 시작하여, 바로 아래 단계가 진정으로 작업을 수행할 수 없을 때만 위로 올라가세요. 가장 흔한 과잉 범위 설정 (Over-scoping)은, 위에서 두 번째 단계인 '단일 모델 호출을 포함한 흐름 (Flow with a single model call)'이 정답이었음에도 불구하고 곧바로 맨 위 단계로 뛰어넘는 것입니다.

실제로 팀을 혼란에 빠뜨리는 경계선

쉬운 결정은 쉽습니다. 만약 작업이 규칙으로 표현 가능하다면, 그것은 플로우 (flow)입니다. 만약 정답이 데이터에 대한 조회 (lookup)라면, 그것은 쿼리 (query)이며, 어려운 부분은 추론 (reasoning)이 아니라 데이터를 해결하는 것입니다. 네 가지 철자로 저장된 고객을 대상으로 검색 파이프라인 (retrieval pipeline)을 실행하면, 모든 설정에서 확신에 찬 틀린 파이프라인 합계를 반환할 것입니다. 해결책은 데이터 내에 해결된 식별 키 (identity key)를 두는 것이며, 이는 데이터 준비 비용에 관한 동반 기사 (companion piece on the data-prep tax)에서 다루는 주제입니다. 이 중 그 어느 것도 에이전트 (agent)를 필요로 하지 않습니다.

사람들을 혼란에 빠뜨리는 결정은 중간 단계에 있는 것입니다: 모델 호출 (model call)이 포함된 플로우 (flow)와 진정한 에이전트 (agent) 사이의 선택입니다. 두 방식 모두 언어 모델 (language model)이 무언가 똑똑한 일을 수행하기 때문에 비슷해 보입니다. 차이점은 모델의 출력이 다음에 일어날 일을 바꾸느냐 아니냐에 있습니다.

• 고객 지원 이메일 분류 및 라우팅 (Classify-and-route). 모델이 이메일에 라벨을 붙입니다. 라우팅 분기 (routing branches)는 미리 정해져 있고 알려져 있습니다. 모델의 답변이 분기를 선택하지만, 새로운 단계를 만들어내지는 않습니다. 이것은 모델 호출이 포함된 플로우 (flow)입니다. Microsoft 스택에서는 Copilot Studio 에이전트가 아니라, AI Builder 또는 모델 액션이 포함된 Power Automate 플로우입니다.
• 불안정한 운영 환경의 장애 조사 (Investigate a flaky production incident). 시스템이 로그를 읽고, 가설을 세우고, 이를 테스트하기 위해 서비스를 쿼리하며, 해당 쿼리 결과에 따라 다음 조사 단계를 결정합니다. 단계가 미리 정해져 있지 않으며, 각 단계는 이전 결과에 의존합니다. 이것이 에이전트 (agent)이며, 이를 플로우 (flow)로 강제하는 것은 나열할 수 없는 분기들을 나열하려 하는 것과 같습니다.

한 줄 요약 테스트: 만약 분기를 미리 그릴 수 있다면, 그것은 플로우 (flow)입니다. 만약 모델이 다음 단계가 무엇인지조차 결정해야 한다면, 그것은 에이전트 (agent)입니다. 에이전트로 범위가 설정되는 작업 중 놀라울 정도로 많은 양이 사실은 두 번째 방식의 탈을 쓴 첫 번째 방식입니다.

에이전트 비용 (The agent tax)

작업이 진정으로 에이전트 형태라면, 정직하게 가격을 책정하십시오. 왜냐하면 에이전트는 단 한 번의 실행 데모에서는 절대 보여주지 않는 네 가지 측면에서 그 아래 단계보다 더 많은 비용이 들기 때문입니다.

• 비결정성 (Non-determinism). 동일한 입력이라도 다른 출력을 생성할 수 있습니다. 개방형 작업(open-ended work)이 목적이라면 괜찮지만, 정답이 있는 어떤 경우든 이는 평가(evaluation)와 가드레일(guardrails)로 관리해야 하는 위험 요소입니다.
• 지속적인 평가 관행 (A standing evaluation practice). 에이전트는 단위 테스트(unit-test)할 수 없습니다. 최소한의 기준선(baseline)은 레이블링된 사례들, 예를 들어 50개의 케이스와 통과율 임계값으로 구성되며, 프롬프트나 도구 변경 시마다 재실행해야 합니다. 이를 구축하는 데는 대략 일주일의 작업 시간과 지속적인 담당자가 필요하며, 대부분의 팀은 이 사실을 늦게 발견합니다.
• 실시간 비용 위험 (Real-time cost risk). 루프를 돌리는 에이전트는 아무도 감시하지 않는 상태에서 돈을 소모하며, 제공업체(provider) 예산은 주로 경고만 할 뿐 중단시키지는 못합니다. 실제로는 제한되지 않는 지출 상한선의 이유들로 볼 때, 장난감 수준을 넘어섰다면 실행당 지출(per-run spend) 보호 장치는 선택 사항이 아닙니다.
• 기반 데이터 (The data underneath). 에이전트는 사용자의 데이터를 상속받으며, 신원(identity)과 진실의 원천(source-of-truth)이 해결되지 않으면 잘못된 기록들로부터 자신감 있게 답변합니다.

일주일간 모델링 비용이 들지만 이후 수년간 예측 가능하게 실행되는 플로우(flow)가, 하루 만에 데모는 하지만 평가 시스템, 지출 보호 장치, 그리고 파트타임 담당자가 필요한 에이전트보다 더 나은 엔지니어링 결정인 경우가 많습니다.

AI 에이전트 대신 플로우를 구축해야 하는 경우

후보 사용 사례(candidate use case)를 다음 다섯 가지 질문을 순서대로 거쳐보세요. 첫 번째 '예'가 보통 당신의 답을 알려주며, 이 중 두 개가 당신을 에이전트 아래 단계로 안내합니다.

1. 상류 프로세스(upstream process)가 고장 났기 때문에 이 작업이 필요한 것인가? 만약 작업 내용이 서로 일치하지 않아야 할 두 시스템을 조정하는 것이라면, 상류의 소유권(ownership) 문제를 먼저 해결하세요. 아무것도 구축하지 마십시오.
2. 답변이 데이터에 대한 조회(lookup) 또는 집계(aggregation)인가? 쿼리(query)를 구축하고, 먼저 데이터를 해결하십시오.
3. 작업이 규칙으로 표현 가능하고 반복 가능한가? 결정론적 흐름(deterministic flow)을 구축하십시오.
4. 고정된 단계들 사이에서 단 하나의 판단만 수행하는가? 오케스트레이션(orchestration)이 아닌, 단 한 번의 모델 호출(model call)이 포함된 흐름을 구축하십시오.
5. 다음 단계가 모델이 방금 찾아낸 것에 의존하며, 그 가치가 비용(tax)을 지불할 만큼 충분한가? 첫날부터 평가(evaluation)와 비용 가드레일(spend guard)을 갖춘 에이전트(agent)를 구축하십시오.

두 가지 짧은 사례를 통해 이 테스트가 실제로 어떻게 작동하는지 보여드리겠습니다.

질문 2에서 멈추는 후보 사례. "이 계정의 모든 자회사에 걸친 전체 오픈 파이프라인(open pipeline)을 알려줘." 이는 운영 데이터에 대한 조회(lookup) 및 집계(aggregation)입니다. 정직한 답변은 쿼리(query)이며, 유일하게 어려운 부분은 네 가지의 서로 다른 계정 철자를 하나의 ID로 해결하는 것입니다. 즉, 모델이 추측하는 이름 매칭이 아니라, Dataverse의 대체 키(alternate key)나 해결된 계정 테이블(resolved-account table)을 사용하는 것입니다. 에이전트 없이도 정확하고 반복 가능한 수치를 얻을 수 있습니다.

질문 5에 도달하는 후보 사례. "이메일, 채팅, 통화 기록을 통해 들어오는 모호한 고객 불만을 분류(triage)하고, 조사가 필요한 항목을 결정하며, 조사가 필요한 항목에 대한 컨텍스트(context)를 수집하라." 이는 고정된 프로세스가 아니며(질문 3, 아니오), 고정된 단계 내에서의 단일 판단도 아닙니다(질문 4, 아니오, 조사 경로는 각 불만이 무엇으로 밝혀지는지에 따라 달라집니다). 그리고 그 가치는 높습니다. 이것은 에이전트(agent)이며, 첫날부터 라벨링된 평가 세트(eval set)와 비용 가드레일(spend guard)을 갖추어 출시해야 합니다.

규율(discipline)이 곧 결과물이다

AI 실무 역량을 얼마나 많은 에이전트를 출시했느냐로 측정하고 싶은 유혹이 생길 수 있습니다. 하지만 더 나은 측정 기준은 얼마나 많은 에이전트를 구축하지 않기로 올바르게 결정했느냐입니다. 왜냐하면 그 결정 하나하나가 더 저렴하고 신뢰할 수 있는 방식으로 문제를 해결한 것이며, 아무런 이득도 주지 못하는 비결정론(non-determinism)을 관리하기 위해 예산을 낭비하지 않았음을 의미하기 때문입니다.

그러므로 테스트를 습관화하십시오. 누군가가 아키텍처(architecture)에 매료되기 전, 프로젝트 시작 단계에서 다섯 가지 질문을 소리 내어 던져보십시오. 네 가지 철자 오류를 하나의 핵심 키워드로 해결한 팀은 에이전트(agent)를 구축하지 않았고, 정확한 결과값을 얻어냈습니다. 이것이 바로 AI를 수익성이 있는 곳에 배치하는 것이 실제로 어떻게 구현되는지를 보여주는 사례입니다. 프레임워크(frameworks)는 여러분에게 이 작업을 하라고 권고하지 않을 것입니다. 왜냐하면 프레임워크의 목적 자체가 여러분에게 무언가를 구축하도록 유도하는 것이기 때문입니다.

다음 글 읽기

• The Data-Prep Tax: Why Your AI Agent Project Is Really a Data Project - 왜 수많은 에이전트 프로젝트가 사실상 데이터 프로젝트인지, 그리고 어떻게 데이터 작업을 먼저 범위화(scope)해야 하는지에 대하여.
• Microsoft's Agents Hub Decoded - 공식적인 에이전트 가이드라인이 공식화하는 내용과, 그것이 여러분에게 남겨둔 절제와 비용에 대한 과제.
• AI Cost Governance: The Spend Caps That Don't Actually Cap - 에이전트가 데모 단계를 벗어난 후 필요하게 되는 실시간 지출 가드레일.

이 기사는 원래 az365.ai에 게시되었습니다. 저는 Alex Pechenizkiy이며, Microsoft AI 스택에 대해 정직하고 특정 벤더에 치우치지 않은 분석을 작성하는 Azure 및 Power Platform 솔루션 아키텍트입니다. 더 많은 내용은 az365.ai에서 확인하실 수 있습니다.