agentic workflow

한 줄로 말하면

agentic workflow는 LLM이 도구를 쓰고, 중간 결과를 읽고, 다음 행동을 고르며 일을 끝까지 밀어가는 작업 흐름이야. 핵심은 “AI가 알아서 한다”가 아니야. 어떤 행동은 위임하고, 어떤 행동은 기록하고, 어느 지점에 사람을 세울지 정하는 설계 문제야.

비유로 이해하기

일반 자동화는 컨베이어벨트에 가까워. 입력이 들어오면 정해진 순서대로 처리하고, 예외가 생기면 멈춰. agentic workflow는 일을 맡긴 주니어 동료에 더 가까워. 목표를 주면 필요한 문서를 찾고, 도구를 실행하고, 막히면 다른 길을 시도하지.

이 비유는 여기까지야. 실제 회사에서는 “동료처럼 믿는다”로 끝낼 수 없어. 어떤 채널의 기억을 볼 수 있는지, 어떤 도구를 실행할 수 있는지, 누가 요청했는지, 무슨 응답과 도구 호출을 남겼는지까지 같이 설계해야 해. 그래서 에이전트의 자율성은 항상 권한, 기록, 관측, 비용 통제와 한 묶음으로 움직여.

정확한 정의

agentic workflow는 보통 네 층으로 이뤄져.

flowchart TD
    A["목표와 맥락"] --> B["계획"]
    B --> C["도구 실행"]
    C --> D["결과 검증"]
    D -->|"부족하면 다시"| B
    D --> E["사람에게 보고하거나 승인 요청"]
    F["권한 범위"] -.-> C
    G["세션 기록과 감사"] -.-> B
    G -.-> C
    G -.-> D
    H["관측과 개선"] -.-> D
    H -.-> B

첫째, 목표와 맥락이 있어야 해. 사용자가 무엇을 원하는지, 어떤 문서·채널·코드베이스·업무 데이터를 볼 수 있는지가 여기 들어가. 둘째, 계획이 있어야 해. 한 번 답하고 끝나는 챗봇이 아니라, 단계를 나누고 순서를 잡아야 하지. 셋째, 도구 실행도 붙어야 해. 검색, 파일 수정, 코드 실행, 티켓 조회, 클라우드 리소스 조회 같은 실제 행동이 여기에 들어가. 넷째, 결과 검증이 있어야 해. 테스트·리뷰·로그·사람 승인 중 무엇이든, “이 행동이 맞았는가”를 확인하는 장치가 필요해.

기업용 agentic workflow에는 다섯째 층도 붙는다. 실행 중 나온 관측값과 피드백을 다시 작업 흐름으로 넣는 개선 루프야. Microsoft는 기업용 에이전트 플랫폼을 설명하면서 구축, 맥락화, 실행, 거버넌스, 개선을 한 시스템으로 묶어야 한다고 말해. Foundry 쪽에는 평가와 추적 기록, Agent 365 쪽에는 누가 어떤 에이전트를 배포했고 무엇에 접근하며 비용이 얼마인지 보는 목록이 붙어.¹

Anthropic은 여기서 한 번 더 선을 그어. 정해진 코드 경로가 LLM과 도구를 순서대로 엮으면 workflow고, LLM이 자기 과정과 도구 사용을 동적으로 정하면 agent라고 구분해.² 그래서 agentic workflow를 설계할 때 처음부터 “완전 자율 에이전트”를 목표로 잡으면 위험해. prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer처럼 더 작은 패턴을 먼저 붙이고, 그 한계를 측정한 뒤에만 자율성을 늘리는 쪽이 더 안정적이야.

NVIDIA와 LangChain의 Nemotron 3 Ultra 사례는 이 층을 모델 바깥의 실행 하네스로 보여줘. LangChain은 Deep Agents 벤치마크에서 실행 기록을 보고, 모델을 다시 학습시키는 대신 시스템 프롬프트, 도구 설명, 미들웨어를 조정했다고 설명해. NVIDIA가 제시한 열린 스택도 모델 하나가 아니라 Nemotron 모델, LangChain Deep Agents 코드, OpenShell 보안 실행 환경, NemoClaw 참조 청사진을 묶은 형태야.³ agentic workflow에서 성능은 모델 이름만의 문제가 아니야. 모델이 어떤 도구 설명을 읽고, 어떤 중간 규칙을 거치며, 어떤 안전한 실행 공간에서 행동하는지도 같은 설계 대상이 된다.

Claude in Microsoft Foundry 정식 출시는 이 다섯째 층이 왜 중요한지 더 선명하게 보여줘. Microsoft는 기업 AI 프로젝트가 모델 품질보다 조달, 거버넌스, 네트워킹, 데이터 때문에 멈춘다고 설명해. 그래서 Claude를 Foundry 안에 넣을 때도 Messages API와 Foundry Agent Service만 붙인 게 아니라, Microsoft Entra ID 인증, Azure RBAC, 기존 거버넌스 정책, 사용량 추적, Azure 청구, 데이터 구역(data zone), zero data retention 선택지를 같이 붙였어.⁴ agentic workflow가 기업 안으로 들어간다는 건 모델 호출을 여는 일이 아니라, 모델 호출을 이미 있는 통제 체계 안에 앉히는 일이야.

여기에 업무별 신뢰도라는 평가 축이 붙기 시작해. Microsoft가 MIT Technology Review Insights와 함께 조사한 Agent Confidence Index는 AI·데이터·클라우드 분야 기술 전문가 300명에게 101개 업무를 놓고 신뢰 수준을 물었어. 평균 점수는 64점이고, 30개 업무는 70점을 넘었어. 자동 보고서 생성은 83.5점, 새 기능의 반복 코드 생성은 82.5점, 인증서 만료 감시와 갱신은 81.5점이야. 반대로 서비스 메시 설정과 장애 대응은 37.5점, 데이터베이스 스키마 이전 스크립트는 46.5점, 메모리 누수 탐지는 48.5점에 머물러.⁵ 그래서 agentic workflow의 실제 경계는 “에이전트를 쓰느냐 마느냐”가 아니라, 어떤 업무를 어느 신뢰 점수까지 올렸고 어디서 사람 판단을 요구하느냐로 갈라져.

여기에 현장 엔지니어링 층이 붙으면 흐름은 더 두꺼워져. Microsoft Frontier Company는 6,000명의 산업·엔지니어링 전문가를 고객 안에 붙여 AI 시스템을 함께 설계하고, 배포하고, 계속 개선하겠다고 설명해. 여기서 반복되는 단어는 모델 성능이 아니라 성과 측정, 고객 고유 지식 보호, 관측, 거버넌스, 보안, FinOps야.⁶ 에이전트가 실제 업무 안으로 들어갈수록 workflow는 프롬프트 묶음이 아니라 운영 체계가 된다.

왜 중요한가

자율성이 길어질수록 생산성만 커지는 게 아니라 실패 반경도 커져. 한 번의 응답이 틀리는 것과, 에이전트가 몇 시간 동안 잘못된 도구를 실행하는 것은 다른 문제야.

그래서 2026년의 제품 신호는 한쪽으로만 가지 않아. Anthropic의 Claude Tag는 Slack 안에서 @Claude를 팀원처럼 부르고, 선택한 채널·도구·데이터·코드베이스에 접근하게 해. 회사는 이 방식이 비동기 작업과 장시간 자율 실행으로 이어진다고 설명하고, 내부 제품팀 코드의 65%가 Claude Tag 내부 버전에서 만들어진다고 주장해.⁷ 이건 자율 실행 시간이 길어지는 쪽 신호야.

동시에 Microsoft 생태계의 GitHub Copilot은 반대쪽 장치를 두껍게 만들고 있어. GitHub는 엔터프라이즈 고객이 Copilot agent session data를 스트리밍 endpoint나 REST API로 받아 볼 수 있게 했고, 그 안에는 prompt, response, tool call 같은 활동 기록이 포함된다고 설명해.⁸ 이건 “더 자율적인 에이전트”를 허용하려면 “더 관찰 가능한 에이전트”가 필요하다는 신호야.

Microsoft가 더 넓게 내놓은 Agent Platform 설명은 이 흐름을 한 단계 더 밀어. 에이전트를 GitHub에서 만들고, Microsoft IQ로 기업 맥락을 붙이고, Foundry에서 실행하고, Agent 365로 통제하고, 행동 결과와 사람 피드백을 다시 개선 루프로 넣는 구조야.¹ 여기서 중요한 건 모델 이름이 아니야. agentic workflow가 제품으로 굳을수록 질문은 “어떤 모델이 똑똑한가”에서 “그 모델이 어떤 권한·맥락·관측·정책 안에서 움직이는가”로 옮겨가.

Claude in Foundry 정식 출시는 이 질문을 조달과 데이터 거주성(data residency)까지 끌고 내려와. 기업은 Claude를 기존 Azure 계정으로 사고, Azure 청구서의 단일 사용량 항목으로 보고, 모델별 세부 사용량은 Foundry 안에서 확인할 수 있어. 데이터는 Azure에서 처리되고, 고객은 Global 또는 US data zone을 고를 수 있어. 민감한 업무에는 API 호출 뒤 프롬프트와 완성문을 Anthropic이 보관하지 않는 zero data retention도 선택할 수 있다고 설명돼.⁴ 결국 에이전트의 생산 배포 경계는 “어떤 모델을 쓸 수 있나”보다 “그 모델이 우리 조직의 인증, 권한, 데이터, 비용 규칙을 통과하나”에 더 가까워져.

Azure Brain은 그 질문을 운영 현장에서 더 구체화해. Microsoft는 Brain을 Azure Resource Graph 위의 cloud health intelligence system으로 설명해. 여기에는 서비스·리전·가용 영역·의존성 그래프 같은 topology, error rate·latency·throughput 같은 runtime state, 진행 중인 배포와 계획된 작업이라는 intent, 과거 장애와 완화 이력, 그리고 고객 tenant가 실제로 겪는 오류와 지연이 함께 들어가.⁹ 그래서 agentic operations에서 먼저 필요한 것은 “복구 에이전트”가 아니라, 에이전트들이 같은 현실을 보고 같은 단어로 판단하게 만드는 상태 모델이야.

Agent Confidence Index는 이 질문에 숫자 축을 붙여. 높은 점수를 받은 업무는 반복적이고, 기준이 잘 정해져 있고, 되돌리기 쉬운 일이야. 낮은 점수를 받은 업무는 여러 시스템을 건드리고, 실패 비용이 크고, 맥락 판단이 필요한 일이야. Microsoft 글에서 기술 전문가의 59%는 에이전트 도입의 최우선 과제로 “사람을 루프 안에 두는 것”을 골랐어.⁵ 이건 보수적 태도가 아니라 설계 원칙에 가까워. 에이전트가 맡는 일의 범위가 넓어질수록, 사람은 모든 단계를 손으로 처리하는 사람이 아니라 어느 단계가 위임 가능한지 판정하는 사람으로 이동해.

KTern.AI의 SAP 전환 사례는 이 숫자 축이 실제 장기 업무에서 어떻게 인프라 요구로 바뀌는지 보여줘. SAP 전환은 몇 달에서 1년 넘게 이어지고, 고객별 업무 규칙과 기존 코드, ERP 시스템, 프로세스 예외가 계속 얽혀. AWS 글에서 KTern.AI는 Amazon Bedrock AgentCore 위에 20개 넘는 전문 에이전트를 올리고, 오래 유지되는 맥락, 안전한 도구 접근, 고객별 격리, 신원·권한, 관측, 평가를 AgentCore가 맡게 했다고 설명해.¹⁰ 여기서 핵심은 “에이전트가 SAP를 안다”가 아니야. 오래 달리는 업무일수록 기억, 도구 권한, 고객별 격리, 추적, 평가가 실행 구조의 일부가 된다는 점이야.

Microsoft Frontier Company는 그 질문을 제품 밖의 조직 설계까지 넓혀. 기업은 자기 데이터, 전문성, 업무 흐름, 의사결정 방식을 AI 안에 넣고 싶어 하지만, 동시에 그 지식이 모델 학습으로 평준화되는 건 피하고 싶어 해. Microsoft는 이 조직을 설명하면서 고객의 데이터와 지식재산, 경쟁 우위가 차별성을 잃는 방식으로 모델 학습에 쓰이지 않아야 한다고 선을 그어.⁶ 그래서 기업용 agentic workflow의 핵심은 “더 많은 자동화”가 아니라 “내 조직의 지식이 쌓이되 새지 않게 하는 반복 구조”에 가까워져.

실제 예시

Claude Tag는 팀 단위 공유 에이전트의 예시야. 개인 채팅창 하나에 갇힌 비서가 아니라, Slack 채널 안에서 여러 사람이 같은 Claude를 부르고 이어서 대화할 수 있어. 관리자는 Claude가 접근할 채널·도구·정보를 정하고, 채널별 기억을 분리하고, 토큰 지출 한도와 활동 로그를 볼 수 있어.⁷ 여기서 자율성은 “어디든 갈 수 있음”이 아니라 “정해진 공간 안에서 오래 움직일 수 있음”이야.

Copilot agent session streaming은 감사 가능한 코딩 에이전트의 예시야. 기업은 GitHub Copilot CLI, VS Code, Visual Studio, JetBrains 계열 IDE 같은 여러 클라이언트에서 나온 세션 활동을 한곳으로 보낼 수 있어. 보안팀 입장에서는 “AI가 코드를 만들었다”보다 “누가 어떤 요청을 했고, 에이전트가 어떤 도구를 호출했는가”가 더 중요해져.⁸

Microsoft Agent Platform은 기업용 에이전트를 생산 시스템처럼 다루는 예시야. 에이전트는 GitHub에서 소스·테스트·배포·관측·개선 생애주기를 따르고, Foundry에서는 여러 모델·도구·행동·평가·추적 기록을 붙여 실행돼. Agent 365는 조직 안의 에이전트를 한 목록에 모아 누가 배포했는지, 어떤 데이터와 도구에 접근하는지, 어떻게 행동하고 비용이 얼마나 드는지 보게 한다고 설명돼.¹ 이건 “에이전트 하나”보다 “에이전트 재고 전체”를 관리하는 문제에 가까워.

Claude in Microsoft Foundry는 멀티모델 선택권이 운영 계층과 결합되는 예시야. 개발자는 Claude의 Messages API, prompt caching, extended thinking, tool streaming을 쓰고, Foundry Agent Service는 Claude를 추론 코어로 삼아 여러 단계 계획, 도구 사용, 업무 실행을 엮어. 동시에 접근은 Microsoft Entra ID와 Azure RBAC로 관리하고, 응답은 Foundry Control Plane의 평가와 규칙 검사를 통과하게 할 수 있어.⁴ Momentic은 이 조합으로 릴리스 전 UI 테스트를 자동으로 돌리고, Everstar는 원전 안전 분석 시간을 크게 줄였다고 소개돼. 여기서 반복되는 단어도 성능이 아니라 신뢰성, 보안, 처리량, 거버넌스야.

NVIDIA와 LangChain의 Deep Agents 사례는 모델 개선과 워크플로우 개선을 분리해 보는 예시야. LangChain은 실행 기록에서 실패 지점을 찾고, 모델 재학습 없이 프롬프트, 도구 설명, 미들웨어를 조정했어. NVIDIA는 이 조합이 공개 모델 중 높은 정확도와 낮은 실행 비용을 냈다고 주장하지만, 이 숫자는 발표 주체의 벤치마크로 분리해 읽어야 해.³ 더 중요한 신호는 “모델을 바꾸지 않아도 에이전트 행동이 달라진다”는 구조야. 에이전트의 품질 관리는 모델 선택, 하네스 조정, 평가 반복을 함께 보는 쪽으로 이동하고 있어.

Windows Agent Arena(WAA) 사례도 같은 구분을 데스크톱 작업에서 보여줘. 보도에 따르면 소르테크-인제대 공동 연구팀은 같은 Gemini 3.1 Pro Preview 기반 구성에서 세이프툴만 둔 경우와, 세이프툴 오케스트레이션·UI 자동화·최적화 파이프라인을 결합한 경우를 비교했어. 후자의 WAA 154개 과제 단일 실행 성공률은 64.22%였고, 전자는 41.56%였다고 해.¹¹ 이 수치는 연구팀이 제시한 사례이므로 다른 환경에 그대로 일반화할 수는 없어. 다만 이 사례에서는 모델 가중치만이 아니라 후보 행동을 다시 정렬하고, 단계별로 검증하며, 모달 창 같은 실패를 복구하는 흐름이 결과의 일부였어.¹¹

KTern.AI의 Amazon Bedrock AgentCore 사례는 장기 기업 업무의 예시야. KTern.AI는 SAP 역공학, 표준 프로세스 적합성 검토, 맞춤 코드 분석, 테스트 케이스 생성, 프로세스 마이닝, 예외 탐지 같은 역할을 전문 에이전트로 나눴어. AgentCore의 실행 계층은 실행과 격리를 맡고, 메모리는 프로젝트 맥락을 유지하고, 게이트웨이는 SAP API와 고객 ERP 시스템 접근을 연결하고, 신원·관측 계층은 권한과 추적을 맡아.¹⁰ 그래서 “여러 에이전트”라는 말보다 더 중요한 건 각 에이전트가 어떤 기억을 공유하고, 어떤 도구에 접근하며, 어떤 로그와 평가로 관리되는가야.

Microsoft Frontier Company는 고객 안에 박히는 실행 조직의 예시야. Microsoft는 25억 달러를 투자해 고객사와 공동 설계, 공동 혁신, 배포, 지속 개선을 하겠다고 했고, LSEG Workspace에는 구조화·비구조화 금융 콘텐츠를 가로질러 질문에 답하는 기능을 넣었다고 설명해. 이 기반은 고객 피드백과 실시간 사용자 테스트로 계속 다듬어진다고 해.⁶ 여기서 agentic workflow는 소프트웨어 기능만이 아니라 산업 지식, 변화 관리, 고객 피드백, 성과 측정이 묶인 배포 방식이야.

Agent Confidence Index는 에이전트에게 맡길 업무를 고르는 예시야. 보고서 작성, 반복 코드 생성, 인증서 갱신, 실시간 데이터 감시는 이미 위임 가능한 쪽에 가까워. 서비스 메시 설정, 데이터베이스 이전, 메모리 누수 탐지는 아직 사람이 중심에 서야 하는 쪽에 가까워.⁵ 중요한 건 낮은 점수의 업무도 완전히 제외되는 게 아니라는 점이야. 에이전트가 초안, 탐색, 후보 좁히기까지 맡고, 마지막 위험 판단은 사람이 하는 식으로 workflow가 쪼개진다.

Anthropic의 고객지원 예시는 이 경계가 왜 업무별로 달라지는지 보여줘. 고객지원은 대화가 자연스럽게 이어지고, 주문 내역·지식베이스·티켓·환불 도구를 붙일 수 있고, 사용자가 정의한 해결 기준으로 성공 여부를 볼 수 있어.² 그래서 고객지원은 “자동 채점기가 약한 업무”라기보다, 대화형 업무 안에서도 해결 기준과 도구 경계가 비교적 잘 잡히는 쪽에 가깝다. 반대로 금융·법무처럼 결과의 책임과 해석 비용이 큰 업무는 같은 방식으로 곧장 길게 달리기 어렵다.

Azure의 agentic cloud operations는 운영 현장의 예시야. Azure Copilot observability agent는 원격 측정 신호, 애플리케이션 구성도, 의존성, 평소 동작 기준선을 계속 분석해 문제 징후를 묶고 원인 후보를 찾도록 설계됐어. Microsoft는 이 흐름을 관측, 거버넌스, 최적화가 이어지는 루프로 설명하고, 행동은 사람의 정책과 접근 권한 안에서 반복 가능하고 감사 가능해야 한다고 말해.¹² 여기서 에이전트는 혼자 복구 버튼을 누르는 존재가 아니라, 신호를 묶고 다음 행동을 좁히며 사람의 결정 지점을 앞으로 당기는 운영 동료에 가까워.

Azure Brain은 그 운영 동료가 기대는 바닥을 보여줘. 예를 들어 배포 중 특정 리전에서 오류율이 흔들리면, Brain은 배포 의도, 의존성 그래프, 과거 장애 패턴, 고객에게 보이는 오류를 한곳에서 맞춰 보고 “이 배포가 고객-visible impact를 만들고 있으니 멈춰야 한다”는 결론을 downstream system에 전달하는 식이야. 그 결론을 배포 시스템은 rollout gate로, incident management는 단일 incident 생성으로, customer communication system은 영향받은 tenant 범위의 알림 초안으로 소비해.⁹ 이건 에이전트가 더 많은 버튼을 누른다는 말이 아니야. 여러 시스템이 같은 판단을 소비하게 만드는 구조가 먼저 있다는 뜻이야.

이 예시들을 같이 보면 방향이 보인다. 코딩처럼 테스트와 diff가 있는 곳에서는 에이전트가 더 오래 달릴 수 있어. 클라우드 운영처럼 관측 신호와 정책 경계가 있는 곳도 비슷한 길이 열리고 있어. 금융 정보 업무처럼 고객 피드백과 실시간 테스트가 붙는 곳은 중간 지대야. 대신 기업 배포에서는 그 긴 실행을 추적하는 로그, 권한 경계, 비용 통제, 사람의 개입 지점이 함께 붙어. 고객 응대·환불·법무처럼 자동 채점이 약한 곳에서는 같은 길이 더 느리게 열릴 가능성이 높아.

헷갈리지 말아야 할 점

• agentic workflow는 무인 실행과 같은 말이 아니야. 사람의 승인이 중간에 여러 번 들어가도, 모델이 계획·도구 사용·검증 루프를 맡으면 agentic workflow야.
• workflow와 agent를 섞어 부르면 안 돼. 정해진 경로를 따라 여러 LLM 호출과 도구를 엮는 것은 workflow고, 모델이 다음 단계와 도구 사용을 직접 고르는 것은 agent야. 둘 다 유용하지만 비용, 지연, 오류 반경이 다르다.
• 모델 선택권은 통제의 반대말이 아니야. Claude를 Foundry에서 쓸 수 있다는 말은 외부 모델을 아무렇게나 붙인다는 뜻이 아니야. 기업에서는 오히려 인증, 권한, 데이터 구역, 보존 정책, 과금 항목이 정리될 때 모델 선택권이 생산 환경으로 들어와.
• 자율성이 늘면 통제가 사라지는 게 아니야. 통제의 위치가 바뀌어. 단계별 승인에서 권한 스코프, 활동 기록, 사후 리뷰, 예외 알림으로 옮겨갈 수 있어.
• 신뢰도 점수는 업무 전체의 허가증이 아니야. 같은 “데이터베이스 이전”이라도 스크립트 초안, 리스크 탐색, 실제 적용은 실패 비용이 달라. 점수는 어디를 쪼개고 어디에 사람을 세울지 정하는 출발점이지, 통째로 자동화해도 된다는 허락이 아니야.
• 관측성은 사후 보고서가 아니야. 에이전트가 오래 움직이려면 실행 중 신호를 읽고, 원인 후보를 좁히고, 다음 행동을 제한하는 장치가 필요해. 로그는 기록인 동시에 행동을 멈추거나 고치는 입력이야.
• 공통 상태 모델 없이 에이전트만 늘리면 더 위험해져. triage agent, diagnosis agent, communication agent가 저마다 다른 신호를 보고 판단하면 자신감 있는 시스템들이 생산 환경에서 서로 충돌할 수 있어. 먼저 같은 현실을 보게 해야 해.
• 코딩 에이전트의 성공을 모든 업무에 그대로 옮기면 안 돼. 코드는 테스트와 diff가 있어서 검증이 쉽다. 고객 환불, 의료 상담, 투자 판단처럼 결과를 자동 채점하기 어려운 업무는 사람이 서야 할 지점이 더 많아.
• 여러 에이전트를 붙인다고 항상 나아지지 않아. 병렬화가 이득인 일도 있지만, 책임 소재와 컨텍스트 충돌이 생기면 단일 에이전트보다 나빠질 수 있어.

관련 문서

• 이 흐름을 기업 시장 확장으로 보면 Anthropic의 6월 — 성능 자랑을 넘어 남의 조직 안으로가 이어져.
• Claude를 만드는 회사 자체를 보려면 Anthropic.
• Copilot과 Azure까지 묶은 배포면을 보려면 Microsoft.
• 모델 바깥의 실행 하네스 사례는 NVIDIA Nemotron은 왜 모델 대신 도구 설명을 고쳤을까가 이어져.
• LangChain 계열의 상태 있는 에이전트 런타임은 LangGraph에서 따로 볼 수 있어.
• Amazon Bedrock AgentCore가 붙는 클라우드 사업자 맥락은 Amazon에서 이어져.

남은 질문들

• 팀 단위 공유 에이전트는 Slack·Teams·IDE 밖의 업무 도구에서도 표준 인터페이스가 될까?
• 기업은 Agent 365 같은 에이전트 목록과 로그를 실제 감사·보안·비용 운영에 쓰게 될까, 아니면 사후 책임 회피용 기록으로만 남을까?
• 자율 실행 시간이 길어질수록 비용 한도·권한 분리·메모리 삭제 같은 통제 장치는 어느 수준까지 제품 기본값이 될까?
• 자동 채점기가 없는 업무에서도 에이전트가 장시간 실행될 수 있을까, 아니면 승인형 워크플로우가 계속 우세할까?
• 실행 하네스와 평가 루프가 표준화되면 모델 교체보다 workflow 조정이 에이전트 성능 개선의 주된 손잡이가 될까?
• Brain 같은 cloud health intelligence system은 실제 복구와 비용 최적화까지 이어질까, 아니면 더 좋은 대시보드와 알림 체계에 머물까?

각주

1. Microsoft/Jay Parikh, 「AI alone won’t change your business. The system running it will」(2026-06-02) 공식 블로그. ↩︎ ↩︎² ↩︎³

2. Anthropic/Erik S.·Barry Zhang, 「Building effective agents」(2024-12-19) Engineering at Anthropic. ↩︎ ↩︎²

3. NVIDIA/Adel El Hallak, 「NVIDIA Nemotron Achieves Benchmark-Leading Performance With LangChain Deep Agents Harness」(2026-07-08) NVIDIA Blog. ↩︎ ↩︎²

4. Microsoft Azure Blog/Steve Sweetman, 「Claude in Microsoft Foundry is now generally available」(2026-06-29) 공식 블로그. ↩︎ ↩︎² ↩︎³

5. Microsoft/Amanda Silver, 「The 2026 Agent Confidence Index: Where 300 builders see real momentum」(2026-06-29) Microsoft Cloud Blog. ↩︎ ↩︎² ↩︎³

6. Microsoft/Judson Althoff, 「Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence」(2026-07-02) 공식 블로그. ↩︎ ↩︎² ↩︎³

7. Anthropic, 「Introducing Claude Tag」(2026-06-23) 공식 발표. ↩︎ ↩︎²

8. GitHub, 「Copilot agent session streaming is now in public preview」(2026-07-02) changelog. ↩︎ ↩︎²

9. Microsoft Azure Blog/Mark Russinovich, 「Meet Brain: The AI system behind Azure reliability」(2026-07-09) 공식 블로그. ↩︎ ↩︎²

10. AWS Machine Learning Blog/Vijayaraghavan C P·Prabhu G, 「How KTern.AI built agentic AI for SAP on Amazon Bedrock AgentCore」(2026-07-10) AWS Blog. ↩︎ ↩︎²

11. 전자신문/노동균, 「소르테크-인제대, ‘윈도 데스크톱 AI 에이전트’ 표준 벤치마크서 최고기록 경신」(2026-07-12) 기사. ↩︎ ↩︎²

12. Microsoft Azure Blog/Pang Ngernsupaluck, 「From insight to action: The next phase of agentic cloud operations」(2026-06-23) 공식 블로그. ↩︎