AI 자동화 (AI automation)는 미리 정의된 트리거와 단계를 따릅니다. 반면 AI 에이전트 (AI agent)는 목표를 전달받으면 문맥을 검토하고, 도구와 다음 단계를 선택하며, 결과에 따라 적응합니다. 안정적이고 반복적이며 대량의 작업에는 자동화를 사용하세요. 해석이 필요한 가변적이고 다단계인 작업에는 에이전트를 사용하세요. 실제 운영 환경에서 가장 강력한 설계는 종종 하이브리드(hybrid) 방식입니다. 에이전트는 이해, 계획 및 예외 처리를 담당하고, 결정론적 시스템 (deterministic systems)은 민감한 작업을 수행하며, 사람은 고위험 변경 사항을 승인합니다.

이것은 단순한 제품 정의가 아닙니다. 우리는 xAgent에서 통제된 프로젝트 보고 작업을 실행했으며, 지속적인 계획, 작업 진행, 삭제 승인, 생성된 결과물, 독립적 검사 및 복구 계획을 유지했습니다. 핵심적인 발견은 간단했습니다. 에이전트는 워크플로 (workflow)로 미리 정의하기 어려운 작업을 해결할 수 있지만, "작업 완료"가 "결과 검증"과 동일한 것은 아니라는 점입니다.

A persistent execution plan in an xAgent Session, with completed, current, and not-started tasks

AI 에이전트 vs. AI 자동화 한눈에 보기

AWS의 공식 비교에서도 유사하게 자동화는 미리 정의되고 빠르며 일관되고 예측 가능하다고 설명하는 반면, 에이전트는 추론, 적응 및 의사결정 능력을 추가한다고 설명합니다. 운영상의 질문은 어떤 명칭이 더 진보적으로 들리는가가 아닙니다. 작업이 그 경로와 결과의 불확실성을 허용할 수 있는지 여부입니다.

AI 자동화란 무엇인가?

AI 자동화 (AI automation)는 알려진 프로세스 내에 모델의 역량을 내장합니다. 지원 워크플로 (support workflow)의 경우, 들어온 티켓을 분류하고, 고정된 필드를 추출하며, 라우팅 규칙 (routing rules)을 적용하고, 선택된 큐 (queue)에 레코드를 기록할 수 있습니다. 모델이 한 단계를 수행할 수는 있지만, 트리거 (trigger), 순서, 쓰기 대상 및 오류 처리 (failure handling)는 여전히 사람이 사전에 정의합니다.

다음과 같은 경우에는 자동화가 일반적으로 더 나은 선택입니다:

• 입력 구조와 비즈니스 규칙 (business rules)이 안정적일 때.
• 동일한 작업이 대량으로 실행될 때.
• 모든 분기 (branch)를 사전에 설명하고 테스트할 수 있을 때.
• 출력이 정확한 필드, 순서 또는 타이밍을 준수해야 할 때.
• 시스템이 모델에 의해 실행 경로 (execution path)가 변경되는 것을 허용해서는 안 될 때.

그 한계 또한 명확합니다. 두 소스가 충돌하거나, 정보가 누락되었거나, 사용자의 목표를 재해석해야 할 때, 워크플로는 누군가가 이미 설계해 놓은 예외 분기 (exception branch)만을 실행할 수 있습니다. 해당 분기가 없다면, 워크플로는 신뢰할 수 있는 응답을 스스로 만들어내지 못합니다.

AI 에이전트(AI Agent)란 무엇인가?

AI 에이전트는 채팅 인터페이스가 아닌 목표 중심의 실행 루프 (goal-driven execution loop)로 정의됩니다. 즉, 목표와 컨텍스트 (context)를 조사하고, 계획을 세우며, 사용 가능한 역량 (capabilities)을 발견하고, 도구 (tools)를 호출하며, 결과를 검토하고, 다음에 무엇을 할지 선택하는 과정입니다. xAgent는 에이전트 (Agents), 기술 (Skills), 도구 (Tools), MCP, 커넥터 (Connectors), 워크스페이스 (workspaces) 및 승인 (approvals)을 하나의 서버 측 작업 환경에 배치합니다. 역량은 필요에 따라 로드될 수 있지만, 특정 도구가 존재한다는 것을 아는 것이 사용자가 이를 승인했거나 승인을 우회할 수 있음을 의미하지는 않습니다. 이러한 경계에 대해서는 동적 역량 발견 (dynamic capability discovery) 및 승인 및 안전 제어 (approval and safety controls)를 참조하십시오.

에이전트는 다음과 같은 작업에 적합합니다:

• 입력이 문서, 테이블 및 자연어 요구 사항에 걸쳐 있을 때.
• 이후 단계가 이전 단계에서 발견한 내용에 의존할 때.
• 작업이 사실, 충돌, 위험 및 누락된 정보를 구분해야 할 때.
• 목표는 명확하지만 전체 경로를 사전에 열거할 수 없을 때.
• 사람이나 프로그램이 결과를 검토할 수 있을 때.

적응성을 만들어내는 것과 동일한 모델의 판단(model judgment)이 새로운 실패 모드(failure modes)를 만들어내기도 합니다. 에이전트는 증거를 과장하면서 구조적으로는 그럴듯한 보고서를 생성할 수 있습니다. 실제로 파일을 파싱(parsing)하지 않고도 파일을 검증했다고 말할 수도 있습니다. 이것이 바로 에이전트가 검증자(validators), 액세스 제어(access control) 또는 승인 정책(approval policies)을 대체할 수 없는 이유입니다.

언제 각 접근 방식을 사용해야 할까요?

제품을 선택하기 전에 다섯 가지 질문을 던져보세요:

1. 경로를 사전에 열거할 수 있는가? 그렇다면 자동화(automation)로 시작하세요. 그렇지 않다면 에이전트(agent)를 고려하세요.
2. 결과를 확인할 수 있는가? 신뢰할 수 있는 수락 테스트(acceptance test)가 없는 고위험 작업은 자율 에이전트(autonomous agent)에게 위임해서는 안 됩니다.
3. 실패 시 복구가 가능한가? 사람이 개입할 수 있는 경로가 있고 재시도 및 되돌리기가 가능한 작업이 에이전트의 더 나은 후보입니다.
4. 변화가 어디에서 발생하는가? 파서(parser)나 규칙(rule)은 형식의 변화를 처리할 수 있습니다. 의미와 다음 행동의 변화가 에이전트가 더 많은 가치를 더하는 지점입니다.
5. 작업이 외부 세계에 영향을 미치는가? 삭제, 전달, 결제, 게시 및 비즈니스 데이터 변경은 프롬프트 텍스트(prompt text)만으로 처리하는 것이 아니라, 결정론적 도구(deterministic tools)와 승인을 거쳐야 합니다.

가장 부적합한 에이전트 후보는 규칙이 안정적이고, 처리량이 높으며, 기대 결과가 동일하거나, 실패 시 되돌릴 수 없는 작업들입니다. 이러한 작업에 모델의 판단(model judgment)을 추가하는 것은 유용한 적응성을 더하지 못한 채 비용과 불확실성만 증가시킵니다.

프로덕션 시스템이 종종 하이브리드(Hybrid)인 이유

"에이전트냐 자동화냐"는 너무 단순한 선택입니다. 더 강력한 프로덕션 아키텍처(production architecture)는 보통 세 가지 계층을 가집니다:

이는 NIST AI 리스크 관리 프레임워크 (NIST AI Risk Management Framework)와 일치합니다. 신뢰할 수 있는 사용은 AI 시스템의 설계, 사용 및 평가 전반에 걸친 리스크 관리 관행에 달려 있습니다. 거버넌스(Governance)는 프롬프트의 한 문장이 아닙니다. 그것은 검사 가능한 통제 수단(inspectable controls)의 집합입니다.

통제된 xAgent 워크플로 (A Controlled xAgent Workflow)

우리는 허구적이지만 내부적으로 일관된 두 가지 프로젝트 소스를 준비했습니다: 주간 회의록과 프로젝트 상태 CSV 파일입니다. 에이전트는 다음 세 가지 제약 조건을 준수하면서 마크다운(Markdown) 형식의 주간 브리핑과 7개 열로 구성된 실행 항목(action-items) CSV를 생성해야 했습니다:

• 담당자, 날짜, 진행 상황, 원인 또는 결정을 임의로 만들어내지 말 것.
• 소스 간에 내용이 불일치할 경우, 두 주장을 모두 표시하고 해당 항목을 확인 필요(needing confirmation)로 표시할 것.
• 출력물을 검증한 후, 기존 승인 정책(approval policy)을 통해 일회성 초안을 삭제할 것.

이 테스트는 모델의 순위를 매기거나 모든 에이전트를 대표한다고 주장하는 것이 아닙니다. 이는 하나의 구체적인 경계선을 관찰합니다: 작업에 여러 소스, 지속적인 계획(persistent plan), 파일 아티팩트(file artifacts) 및 중대한 결과가 따르는 작업이 포함될 때, 에이전트의 판단(agent judgment)과 결정론적 통제(deterministic controls)가 어떻게 상호작용하는지를 보여줍니다.

1. 에이전트가 지속적인 계획을 생성하고 진행함

에이전트는 plan_create를 호출하여 6단계 계획을 수립했습니다. 인터페이스는 완료된 작업, 현재 진행 중인 작업, 시작되지 않은 작업을 유지했습니다. 각 task_complete 호출은 다음 항목으로 초점을 전환했습니다. 이는 단순히 채팅 응답에 "실행 계획(Execution Plan)"이라고 적는 것과는 다릅니다. 계획 상태(plan state)는 세션(Session)의 일부로 지속되며 장기 실행 작업 중에도 계속 표시됩니다.

2. 삭제 작업이 프롬프트 텍스트를 신뢰하는 대신 승인 절차로 진입함

에이전트(Agent)가 업로드된 일회용 초안을 삭제하려고 시도했을 때, 단순히 프롬프트(prompt)에서 삭제가 허용되었다고 해서 fs_delete_files가 바로 실행되지는 않았습니다. 세션(Session)은 waiting_approval 상태로 진입하여 대상 파일, 위험 수준(risk level), 그리고 승인/거절(approve/reject) 컨트롤을 표시했습니다. 원래의 도구 호출(tool call)은 사용자가 이를 승인한 후에야 재개되었습니다.

An xAgent file deletion paused for high-risk approval while the task list remains on the deletion step

프롬프트는 의도(intent)를 표현하며, 승인 정책(approval policy)은 해당 동작을 실행할 수 있는지 여부를 결정합니다. 이들은 서로 다른 계층(layers)에 속합니다. 장기 실행 작업 가이드에서는 대기 및 재개 동작에 대해 더 자세히 설명합니다.

3. 첫 번째 완료(Completion) 역시 독립적인 수락(Acceptance) 단계에서 실패함

에이전트는 처음에 두 파일이 모두 생성되고 검증되었다고 보고했습니다. 우리는 그 문장을 증거로 취급하지 않았습니다. 우리는 마크다운(Markdown) 파일을 다시 열고 실제 CSV 파서(parser)를 사용하여 실행 항목(action-items) 파일을 가져왔습니다. 그 결과 네 가지 결함이 발견되었습니다:

1. 충돌 설명에 따옴표로 묶이지 않은 쉼표(comma)가 포함되어 있어, 7개 열로 구성된 CSV가 8개 열로 파싱되었습니다.
2. 한 행에서 빈 필드가 누락되어 상태(status)와 의존성(dependency)이 잘못된 열로 밀려났습니다.
3. 마크다운 날짜에 잘못된 대시(dash) 문자가 포함되었습니다.
4. 요약(executive summary)에서 근거 없는 "정상 진행 중(on track)"이라는 주장을 했으며, 브리프(brief)에는 요청된 실행 항목 테이블이 포함되지 않았습니다.

이것이 에이전트와 전통적인 자동화(automation) 사이의 가장 중요한 차이점 중 하나입니다. 워크플로(workflow)는 도구가 성공을 반환했다고 단언할 수 있지만, 개방형 산출물(open-ended artifact)은 여전히 구조적 및 의미적 수락 테스트(structural and semantic acceptance tests)가 필요합니다. 에이전트의 완료 주장(completion claim)은 스스로를 검증할 수 없습니다.

4. 결함들이 새로운 지속적인 수정 계획(Persistent Repair Plan)으로 진입함

우리는 정확한 결함(defects), 올바른 필드 매핑(field mapping), 그리고 수락 기준(acceptance criteria)을 동일한 세션(Session)으로 다시 보냈습니다. 에이전트(Agent)는 파일을 제자리에서 수정하기 전에 새로운 지속적인 수정 계획(persistent repair plan)을 생성해야 했습니다. 에이전트는 CSV 검사, 수정, 파서 검증(parser validation), Markdown 검사, 수정 및 검증을 별도의 작업(tasks)으로 분리했습니다.

A new persistent repair plan in xAgent, with separate CSV and Markdown inspection and validation steps

수정 후, CSV는 A1:G6로 파싱되었습니다: 하나의 헤더 행, 다섯 개의 데이터 행, 그리고 모든 행에 7개의 열이 포함되었습니다. 충돌하는 두 날짜는 하나의 필드에 그대로 남아 있었고, 할당되지 않은 소유자(owner)와 마감일(due-date) 값은 빈 상태로 유지되었습니다. 우리는 Markdown을 별도로 다시 열어 날짜, 요약, 충돌 테이블, 그리고 눈에 보이는 액션 아이템(action-item) 테이블을 확인했습니다.

xAgent completing the repair plan and reporting concrete validation results for both artifacts

이 루프(loop)의 가치는 에이전트가 첫 번째 시도에서 완벽했다는 점에 있지 않습니다. 결함이 명시적인 작업(tasks)이 되고, 수정 프로세스를 통해 지속되며, 다시 확인되었다는 점에 있습니다.

비용, 신뢰성 및 제어의 트레이드오프 (Trade-offs)

에이전트(agent)가 보편적으로 우월한 자동화 계층(automation layer)인 것은 아닙니다. 에이전트는 해석(interpretation)과 경로 선택(path selection)을 사람으로부터 모델(model)로 옮기며, 이 과정에서 모델 호출(model calls), 컨텍스트(context), 재시도(retries), 그리고 수락 확인(acceptance checks)이 추가됩니다. 경로가 더 개방적일수록 비용과 지연 시간(latency)은 예측하기 어려워집니다.

신뢰성 또한 단 하나의 최종 답변만으로는 판단할 수 없습니다. 프로덕션 수락 프로세스(production acceptance process)는 최소한 다음 사항들을 포함해야 합니다:

• 소스 무결성 (Source integrity): 에이전트가 모든 입력을 읽고 사실, 충돌, 누락된 정보를 분리했는가?
• 프로세스 상태 (Process state): 실제로 계획을 수립하고, 도구(tools)를 호출하며, 작업을 진행했는가, 아니면 단순히 해당 단계들을 설명하기만 했는가?
• 구조적 정확성 (Structural correctness): 실제 파서(parsers)가 CSV, JSON, 표(tables) 및 문서를 읽을 수 있는가?
• 의미적 정확성 (Semantic correctness): 모든 요약된 주장(summary claim)이 허구의 소유자, 날짜 또는 결론 없이 근거를 갖추고 있는가?
• 액션 경계 (Action boundaries): 삭제, 전달 및 외부 쓰기(external writes) 작업이 권한 및 승인 절차를 거쳤는가?
• 복구 (Recovery): 실패 후에도 세션(Session)이 컨텍스트(context), 원래의 호출(calls) 및 중간 산출물(intermediate artifacts)을 유지할 수 있는가?

결정 체크리스트 (Decision Checklist)

자동화, 에이전트 또는 하이브리드 설계를 선택하기 전에 이 체크리스트를 사용하세요: