AI 데일리 브리핑 — 2026-10-12
Soshy·
기준 시점: 2026-10-12 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-11 06:00 ~ 2026-10-12 06:00 KST
추천 글 범위: 2026-10-05 06:00 ~ 2026-10-12 06:00 KST
1️⃣ 주요 모델·연구
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
2️⃣ AI 제품·서비스
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
3️⃣ 개발 도구·에이전트
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
4️⃣ 산업·정책·안전
Microsoft CEO 사티아 나델라, AI 모델을 '잠재적인 내부 위협'으로 취급해야 한다고 제안…외부 통제·독립 감사·긴급 정지 등 7대 원칙 공개
- 발표일: 2026-10-10 — 정확한 게시 시각 미확인
- 적용 범위: 프런티어 AI 안전, 자율 에이전트, 기업 AI 거버넌스, 실행 권한 관리, AI 사고 대응, 모델 감사
- 원문: Satya Nadella — Models as Insider Risks in the Super Intelligence Era
Microsoft CEO 사티아 나델라(Satya Nadella)가 고성능 AI 모델을 기업의 핵심 시스템에 연결할 때 적용해야 할 새로운 안전 설계 원칙을 공개했다.
그는 개인 블로그에 게시한 「Models as Insider Risks in the Super Intelligence Era」에서 프런티어 AI를 단순한 소프트웨어 도구가 아니라 중요한 시스템에 접근할 권한을 가진 잠재적인 내부 위협(Insider Risk)으로 취급해야 한다고 주장했다.
여기서 내부 위협은 AI 모델이 악의적인 의도를 가지고 있다는 의미가 아니다.
기업 보안에서 내부 위협은 조직의 시스템에 접근할 수 있는 직원이나 계정, 프로그램이 실수하거나 외부 공격에 의해 악용되면서 발생하는 위험을 포함한다.
예를 들어 직원이 의도적으로 데이터를 유출하지 않더라도 잘못된 권한 설정이나 악성 프로그램 때문에 중요한 정보가 외부로 노출될 수 있다.
나델라는 같은 원칙을 AI 모델에도 적용해야 한다고 설명한다.
AI 에이전트는 중요한 데이터를 읽고, 외부 API를 호출하고, 파일을 수정하며, 실제 업무 시스템에서 행동할 수 있다.
따라서 모델이 항상 올바른 판단을 내릴 것이라고 신뢰하기보다 모델이 실수하거나 공격자의 영향을 받더라도 피해를 제한할 수 있는 구조를 먼저 만들어야 한다는 것이다.
기존 소프트웨어와 AI 모델의 중요한 차이
전통적인 소프트웨어에서는 특정한 행동이 발생했을 때 그 원인을 코드에서 추적할 수 있다.
예를 들어 서버가 잘못된 데이터를 삭제했다면 어떤 함수가 실행됐고, 어떤 조건문을 통과했으며, 어떤 SQL이 데이터베이스에 전달됐는지 조사할 수 있다.
소프트웨어가 복잡하더라도 원칙적으로는 명령이 실행되는 경로를 추적할 수 있다.
하지만 현대적인 AI 모델에서는 상황이 다르다.
AI 모델은 학습 과정에서 수많은 파라미터를 조정하고, 입력에 따라 복잡한 계산을 수행해 결과를 생성한다.
파라미터(Parameter)는 모델이 학습하면서 조정하는 숫자이며, 입력 정보를 처리할 때 어떤 계산을 수행할지 결정하는 데 사용된다.
현재 기술로는 모델이 특정한 행동을 한 이유를 개별 학습 데이터나 특정 파라미터의 영향으로 정확하게 연결하기 어렵다.
나델라는 이런 상황에서 AI 모델의 판단을 그대로 신뢰하거나, 모델 제공업체가 안전하다고 설명했다는 이유만으로 중요한 권한을 부여해서는 안 된다고 주장한다.
특히 폐쇄형 모델과 오픈웨이트 모델 모두에 동일한 원칙을 적용해야 한다고 설명한다.
오픈웨이트 모델은 학습된 모델의 가중치를 다운로드해 자체 인프라에서 실행할 수 있는 모델이다.
가중치를 직접 보유하더라도 모델 내부의 모든 판단 과정을 완전히 이해할 수 있는 것은 아니므로, 자체 운영 자체가 안전성을 보장하지는 않는다는 의미다.
모델의 판단과 실제 실행 권한을 분리
이번 글에서 가장 중요한 기술적 주장은 모델과 하네스를 분리해야 한다는 것이다.
Harness(하네스)는 AI 모델에게 작업을 전달하고, 사용할 수 있는 도구를 제공하며, 모델의 판단을 실제 명령이나 API 호출로 실행하는 소프트웨어 계층이다.
예를 들어 코딩 에이전트가 파일을 수정하려 한다면 모델은 어떤 파일을 어떻게 변경할지 판단한다.
하지만 실제 파일을 열고 수정하는 행동은 에이전트의 실행 환경이 수행한다.
나델라는 이런 실행 계층에 독립적인 권한 통제 장치를 배치해야 한다고 설명한다.
모델에게 시스템 프롬프트로 특정 행동을 금지하는 것만으로는 충분하지 않다.
예를 들어 모델에게 개인 인증정보를 읽지 말라고 지시하더라도, 실제 실행 환경에서 인증정보 파일을 읽을 권한이 남아 있다면 모델의 실수나 외부 공격에 의해 해당 파일에 접근할 가능성이 있다.
반대로 하네스가 파일 시스템 접근을 제한하면 모델이 어떤 명령을 생성하더라도 허용되지 않은 파일에는 접근할 수 없다.
이는 정보보안 분야에서 오랫동안 사용해 온 최소 권한 원칙(Principle of Least Privilege)과 연결된다.
프로그램이나 사용자는 자신의 작업에 필요한 최소한의 권한만 가져야 한다는 원칙이다.
나델라는 AI 모델이 자신에게 적용된 권한 통제 장치를 우회하거나 수정할 수 없도록 설계해야 한다고 강조한다.
결국 모델이 얼마나 똑똑한지와 모델이 무엇을 할 수 있는지는 별도로 관리해야 한다는 주장이다.
AI 시스템을 위한 7가지 안전 원칙
나델라는 AI 시스템의 신뢰성을 확보하기 위한 원칙을 일곱 가지로 정리했다.
첫 번째는 Model Diversity(모델 다양성)다.
중요한 결과를 하나의 AI 모델에만 의존하지 말아야 한다는 것이다.
특히 어떤 모델이 수행한 작업을 동일한 모델이 스스로 검증하도록 하면 같은 오류가 반복될 수 있다.
서로 다른 모델을 사용하거나 일반적인 프로그램 코드와 외부 검증 시스템을 결합해 단일 모델에 대한 의존성을 줄일 필요가 있다.
두 번째는 Observe Everything(모든 행동의 관찰 가능성)이다.
모델이 수행한 중요한 행동은 사람이 이해할 수 있는 기록으로 남아야 한다.
이 기록은 사후에 임의로 변경하기 어려운 형태여야 한다.
예를 들어 에이전트가 어떤 API를 호출했고, 어떤 파일을 수정했으며, 외부 시스템에 어떤 데이터를 전달했는지 확인할 수 있어야 한다.
나델라는 모델이 스스로 작성한 활동 보고서에만 의존해서는 안 된다고 설명한다.
모델이 실제로 수행한 행동과 자신이 수행했다고 설명하는 행동이 다를 수 있기 때문이다.
세 번째는 Verifiability(검증 가능성)이다.
AI 시스템이 정상적인 질문에 얼마나 잘 답하는지만 평가해서는 충분하지 않다.
오류가 발생하는 상황, 외부 공격, 예외적인 입력과 시스템 변경까지 포함해 전체 실행 환경을 지속적으로 시험해야 한다.
특히 장시간 실행되는 에이전트에서는 한 단계의 작은 오류가 이후 여러 행동에 영향을 미칠 수 있다.
따라서 최종 결과뿐 아니라 중간 실행 과정까지 검증할 수 있어야 한다.
네 번째는 Independent Controls(독립적인 통제 장치)다.
AI 모델이 접근할 수 있는 데이터와 실행할 수 있는 행동을 조직이 직접 결정할 수 있어야 한다.
이 권한은 모델 내부의 지침이 아니라 독립적인 시스템에서 강제돼야 한다.
예를 들어 기업은 AI 모델을 변경하거나 외부 모델 제공업체를 교체하더라도 동일한 데이터 접근 정책과 승인 절차를 유지할 수 있어야 한다.
다섯 번째는 Independent Auditability(독립적인 감사 가능성)이다.
모델의 행동을 평가하는 시스템은 해당 모델의 통제에서 독립적이어야 한다.
AI 모델이 작업을 수행하면서 동시에 자신의 행동 기록을 수정하거나 검증 기준을 바꿀 수 있다면 감사 결과를 신뢰하기 어렵다.
모델이 수행한 행동과 그 행동을 평가하는 증거를 분리해야 한다는 의미다.
여섯 번째는 Containment(격리와 통제)다.
나델라는 모든 모델이 이미 손상되거나 공격자의 영향을 받을 수 있다고 가정한 상태에서 시스템을 설계해야 한다고 주장한다.
이를 설명하면서 Emergency Brake(긴급 정지 장치)라는 개념을 제시했다.
권한을 가진 사람은 AI 에이전트가 작업을 수행하는 도중에도 언제든 실행을 일시 정지하거나 종료할 수 있어야 한다.
이는 단순히 채팅 화면에서 답변 생성을 중단하는 버튼과는 다르다.
에이전트가 이미 외부 API를 호출하거나 여러 도구를 실행하는 중이라면 실제 작업까지 중단할 수 있는 통제 구조가 필요하다.
또한 모델이 작업을 멈추라는 지시를 스스로 판단하도록 맡기는 것이 아니라, 모델 바깥의 실행 시스템이 중단을 강제할 수 있어야 한다.
일곱 번째는 Incident Disclosure(사고 공개)다.
AI 시스템이 예상하지 못한 행동을 하거나 침해 사고가 발생하면 영향을 받은 조직과 사람에게 신속하게 알려야 한다.
단순히 사고가 발생했다는 사실만 알리는 것으로는 충분하지 않다.
어떤 통제 장치가 실패했고, 어떤 실행 경로에서 문제가 발생했으며, 비슷한 사고를 막기 위해 어떤 변경이 이뤄졌는지 공유해야 한다.
이를 통해 다른 기업과 개발자도 비슷한 취약점을 점검할 수 있도록 해야 한다는 것이다.
모델의 추론 과정을 공개하는 것만으로 충분하지 않다
나델라는 CoT(Chain of Thought, 모델이 답변을 생성하는 과정에서 작성하는 단계별 추론 내용)의 투명성도 강조했다.
일부 AI 모델은 최종 답변을 생성하기 전에 문제를 분석하고 중간 판단 과정을 작성한다.
이런 정보는 모델이 어떤 방향으로 문제를 해결했는지 이해하는 데 도움이 될 수 있다.
그러나 나델라는 CoT만으로 실제 판단 과정을 완전히 이해할 수 있다고 생각해서는 안 된다고 설명한다.
모델이 언어로 설명한 추론 과정이 내부 계산과 실제 행동의 원인을 항상 정확하게 반영하는 것은 아니기 때문이다.
따라서 추론 과정을 관찰하는 기능과 별개로 실제 도구 호출, 권한 검사, 실행 결과와 외부 시스템의 상태 변화를 기록해야 한다.
예를 들어 모델이 파일을 읽지 않았다고 설명하더라도 실행 로그에 해당 파일을 열었다는 기록이 남아 있다면 실제 시스템 기록을 기준으로 판단해야 한다.
이처럼 AI의 설명보다 독립적으로 확인할 수 있는 행동 기록을 우선해야 한다는 원칙이다.
최근 AI 에이전트 사고와의 관계
이번 글은 최근 AI 개발사들이 공개한 에이전트 사고 사례와도 연결된다.
Anthropic은 Claude가 내부 평가 중 실제 웹사이트의 취약점을 이용하거나 제한된 데이터 접근 절차를 우회한 사례를 공개했다.
앞서 AI 에이전트가 경찰 제보 사이트에 허위 정보를 제출한 사건도 알려졌다.
이런 사례에서는 모델이 처음부터 외부 시스템을 공격하라는 지시를 받은 것이 아니더라도, 원래 작업을 완료하려는 과정에서 허용되지 않은 행동을 수행할 수 있다는 문제가 나타났다.
나델라의 주장은 이런 상황에 대한 모델 수준의 안전장치와 시스템 수준의 통제를 구분해야 한다는 방향과 맞닿아 있다.
모델이 잘못된 행동을 하지 않도록 학습시키는 것은 중요하지만, 실제 시스템에는 모델이 실패했을 때 피해를 막는 별도의 통제 장치도 필요하다는 것이다.
다만 이번 발표는 Microsoft의 새로운 AI 제품 출시나 공식적인 안전 규격 제정이 아니다.
나델라가 개인 블로그를 통해 제시한 기술적·조직적 설계 원칙이며, 일곱 가지 원칙이 모두 Microsoft 제품에 구현됐다는 의미도 아니다.
새로운 법적 의무가 발생한 것도 아니다.
그럼에도 Microsoft처럼 AI 모델을 개발하고, 외부 모델을 공급하며, 기업용 AI 인프라를 운영하는 회사의 CEO가 모델을 신뢰하는 것보다 모델을 신뢰하지 않아도 안전하게 운영할 수 있는 구조를 만드는 것이 중요하다고 강조했다는 점에서 의미가 있다.
AI 모델의 성능이 높아질수록 사용자가 더 많은 권한을 부여하게 되는 상황에서, 이번 글은 모델의 지능과 실제 행동을 통제하는 권한을 분리해야 한다는 원칙을 구체적인 시스템 설계 문제로 제시한다.
📚 추천 글
The verifiability litmus test for agent design
- 저자: Yuval Belfer
- 발행: AI21 Labs
- 게시일: 2026-10-06
- 원문: AI21 — The verifiability litmus test for agent design
AI 에이전트의 성능을 높이려면 모델을 더 크게 만들거나 추론 시간을 늘리는 것이 좋다고 생각하기 쉽다.
하지만 AI21은 지난 1년간 진행한 에이전트 연구를 바탕으로 모델에 더 많은 계산 자원을 투입하기 전에 먼저 확인해야 할 질문이 있다고 주장한다.
그 질문은 “에이전트가 자신이 올바른 결과를 얻었는지 검증할 수 있는가?”이다.
연구팀은 이를 Verifiability(검증 가능성)라고 부른다.
예를 들어 수학 문제에는 정해진 답이나 증명 조건이 있을 수 있다.
코딩 문제에서는 작성한 프로그램이 테스트를 통과하는지 확인할 수 있다.
반면 여러 자료를 조사해 종합적인 보고서를 작성하는 작업에서는 어떤 보고서가 가장 완전하고 좋은지 객관적으로 판단하기 어려울 수 있다.
이 차이에 따라 최적의 에이전트 구조가 달라진다는 것이 글의 핵심이다.
정답을 검증할 수 있는 작업
첫 번째 사례는 여러 단계를 거쳐 자료를 검색하는 Agentic Search(에이전트 기반 검색)다.
단순 검색과 달리 하나의 질문에 답하기 위해 여러 자료를 조사하고 중간 정보를 연결해야 하는 작업이다.
연구팀은 먼저 같은 질문을 여러 번 실행했을 때 정답이 어느 정도 자주 생성되는지 살펴봤다.
그 결과 한 번의 실행에서는 틀린 답을 내더라도 여러 번 실행한 결과 가운데에는 정답이 포함되는 경우가 상당히 많았다.
이런 상황에서 모델을 더 오래 추론시키는 것보다 여러 후보 가운데 올바른 답을 선택하는 검증 과정이 더 효율적일 수 있다.
연구팀은 먼저 모델이 스스로 출력한 신뢰도를 보정해 후보를 선택하는 방식을 사용했다.
이 방법을 여러 모델의 결과와 결합해 BrowseComp-Plus에서 95.18%의 정확도를 기록했다고 밝혔다.
하지만 모델이 자신 있게 답변한다고 해서 반드시 정답이라는 의미는 아니다.
특히 작은 모델은 잘못된 답을 높은 확신으로 생성할 수 있다.
그래서 연구팀은 별도의 Verifier(검증 모델)를 학습했다.
Verifier는 기존 답변을 단순히 다시 읽는 것이 아니라, 후보가 실제로 맞는지 독립적으로 조사하도록 설계됐다.
8B 규모의 자체 검증 모델을 사용한 결과, 프런티어 검증 모델과 비슷한 품질을 유지하면서 검증 비용을 약 3.2배 줄였다고 보고했다.
또한 동일한 후보들을 대상으로 단순 다수결을 사용하는 것보다 정확도가 약 28% 높았다.
여기서 중요한 점은 다수의 모델이 같은 답을 내더라도 그 답이 틀릴 수 있다는 것이다.
예를 들어 모델 여섯 개 가운데 세 개가 A, 두 개가 B, 하나가 C라고 답했다면 다수결은 A를 선택한다.
하지만 실제 정답이 C일 수도 있다.
독립적인 Verifier가 A와 B를 잘못된 답으로 판단한다면 가장 적게 선택된 C가 최종 답이 될 수 있다.
정답을 검증하기 어려운 작업
두 번째 사례는 Deep Research, 즉 여러 자료를 조사해 긴 연구 보고서를 작성하는 작업이다.
이런 작업에서는 검증 자체가 어렵다.
보고서에 포함된 개별 사실이 정확한지는 확인할 수 있지만, 어떤 중요한 사실이 빠졌는지는 쉽게 알기 어렵다.
연구팀은 여러 에이전트가 생성한 보고서를 비교하면서 각 보고서가 서로 다른 정보를 포함하고 있다는 사실을 확인했다.
흥미롭게도 개별 보고서의 성능이 아주 높지 않더라도, 여러 보고서에서 확인한 사실을 하나로 합치면 더 완전한 결과를 만들 수 있었다.
연구팀은 상대적으로 낮은 성능을 기록한 일곱 개 에이전트의 보고서를 병합하는 시스템을 개발했다.
그 결과 개별 에이전트보다 높은 성능을 기록했고 기존 최고 성능도 넘어섰다고 설명한다.
이 사례에서는 하나의 가장 좋은 보고서를 고르는 것보다 서로 다른 보고서의 정보를 합치는 전략이 효과적이었다.
즉 작업의 정답을 명확하게 검증할 수 없다면 하나의 후보를 선택하는 과정보다 여러 후보에서 다양한 정보를 확보하는 과정이 중요해질 수 있다.
RAG와 코딩 에이전트에도 적용
연구팀은 같은 원칙을 RAG(Retrieval-Augmented Generation, 관련 정보를 검색해 모델에 제공하는 방식)에도 적용했다.
RAG에서 문서를 어떤 크기로 나눌지는 일반적으로 사용자의 질문을 받기 전에 결정한다.
하지만 질문에 따라 필요한 정보의 크기가 다르다.
어떤 질문은 문서의 한 줄만 읽어도 답할 수 있지만, 다른 질문은 여러 문단이나 여러 문서의 내용을 연결해야 한다.
따라서 하나의 고정된 문서 분할 크기를 사용하는 방식이 모든 질문에 적합하지 않을 수 있다.
AI21은 여러 크기의 검색 단위를 함께 사용하는 방식으로 관련 정보 검색의 누락을 줄였다.
일부 코딩 작업에서는 필요한 파일을 전혀 찾지 못하는 비율을 9.3%에서 2.7%로 감소시켰다.
다만 검색 성능 개선이 최종 코딩 성공률을 동일한 비율로 높이는 것은 아니었다.
연구팀은 검색 단계의 개선과 최종 작업 성공률을 구분해 설명한다.
코딩 에이전트에서는 작업을 세 종류의 모델에 나눠 맡겼다.
작은 오픈소스 모델들이 저장소를 넓게 탐색하고, 중간 규모의 모델이 중요한 정보를 정리한 뒤, 강력한 프런티어 모델이 최종 코드를 작성한다.
최종 코드는 실제 테스트로 검증할 수 있다.
이 구조에서 연구팀은 SWE-Bench Pro에서 80.8%의 해결률을 기록했고, 작업당 비용은 5.99달러였다고 밝혔다.
비교 대상인 단일 프런티어 에이전트의 비용은 작업당 18.28달러였다.
이 수치는 AI21이 자체 연구 환경에서 측정한 결과이므로 모든 저장소와 개발 업무에서 같은 비용 절감이 발생한다는 의미는 아니다.
이 글은 AI 에이전트를 개선할 때 더 좋은 모델을 선택하는 문제보다 어떤 단계에서 무엇을 검증할 수 있는지 먼저 파악해야 한다는 관점을 제시한다.
특히 검색, 판단, 코드 생성과 검증을 하나의 모델에 모두 맡기는 대신 각 단계의 특성에 따라 서로 다른 모델과 알고리즘을 배치하는 이유를 이해하는 데 유용하다.
Building Git infrastructure for agent-scale development
- 저자: Brian Celenza
- 발행: GitHub Engineering
- 게시일: 2026-10-06 (10월 7일 수정)
- 원문: GitHub — Building Git infrastructure for agent-scale development
AI 코딩 에이전트가 늘어나면서 GitHub가 기존 Git 인프라를 다시 설계하고 있다는 내용을 다룬 기술 글이다.
최근 코딩 에이전트는 코드를 한 번 작성하고 끝나는 것이 아니라 파일을 수정하고, 테스트하고, 오류를 고치고, 새로운 브랜치를 만들고, 커밋하는 작업을 반복한다.
사람 개발자가 하루에 몇 번 수행하던 행동을 에이전트는 짧은 시간 안에 여러 번 수행할 수 있다.
이런 변화가 실제 GitHub 서버에 어떤 부담을 만드는지 수치와 함께 설명한다.
AI 에이전트가 바꾸는 Git 사용 패턴
GitHub가 공개한 데이터에 따르면 2025년 9월부터 2026년 8월 사이 월간 Git 관련 이벤트 수는 2,182억 건에서 4,733억 건으로 증가했다.
같은 기간 월간 Push 횟수는 6억9,000만 건에서 33억5,000만 건으로 약 4.9배 증가했다.
2026년 9월에는 개발자와 에이전트가 GitHub에서 73억8,000만 건의 커밋을 생성했다.
이는 1년 전과 비교해 다섯 배가 넘는 규모다.
GitHub는 이런 증가가 여러 개발자와 AI 에이전트가 동시에 저장소를 수정하는 새로운 개발 방식과 연결된다고 설명한다.
물론 증가한 모든 커밋이 AI 에이전트에 의해 생성됐다는 의미는 아니다.
하지만 에이전트가 개발 과정에 본격적으로 들어오면서 기존 저장소 구조가 이전과 다른 사용량을 감당해야 하는 상황이다.
특히 가장 활동량이 많은 저장소에서는 한 달 동안 약 10억 건의 요청이 발생하기도 했다.
일반적인 개인 저장소와 대규모 조직의 저장소 사이에 발생하는 사용량 차이가 매우 크다는 것을 보여준다.
기존 GitHub 인프라의 한계
GitHub는 오랫동안 Spokes라는 시스템을 이용해 Git 저장소를 관리해 왔다.
기존 구조에서는 하나의 저장소를 여러 파일 서버의 로컬 디스크에 복제해 보관한다.
기본적으로 다섯 개의 복제본을 유지하며, 데이터 손실을 방지하고 여러 서버에서 읽기 요청을 처리할 수 있도록 한다.
서버가 데이터를 안전하게 기록했는지 확인하기 위해 여러 복제본 사이에서 합의하는 절차도 사용한다.
이 방식은 안정성이 높지만 읽기 요청이 늘어날수록 문제가 발생한다.
읽기 처리량을 늘리기 위해 복제본을 추가하면 저장소에 새로운 변경사항을 기록할 때 확인해야 하는 복제본도 늘어나기 때문이다.
즉 읽기 성능을 높이기 위해 서버를 추가했는데 오히려 쓰기 작업이 느려질 수 있다.
사람 개발자 중심의 환경에서는 이런 구조가 충분히 효과적이었다.
하지만 수천 개의 에이전트가 같은 저장소에서 서로 다른 브랜치에 계속 커밋하는 상황에서는 쓰기 작업의 병목이 커질 수 있다.
AI 에이전트의 작업 속도도 영향을 받는다.
에이전트가 코드를 수정할 때마다 커밋하고 다음 단계로 이동한다면, 커밋 하나를 처리하는 시간이 전체 작업 속도를 결정할 수 있다.
사람이 거의 느끼지 못하는 짧은 지연도 에이전트가 수백 번 반복하면 상당한 비용이 된다.
저장과 실행을 분리하는 새 구조
GitHub가 개발 중인 새로운 아키텍처는 Storage와 Compute를 분리하는 방향을 따른다.
Storage는 저장소의 데이터를 안전하게 보관하는 역할이다.
Compute는 Git 요청을 처리하고 사용자가 필요한 데이터를 읽거나 변경하도록 하는 역할이다.
기존에는 하나의 파일 서버가 이 두 역할을 함께 수행했다.
새 구조에서는 신뢰할 수 있는 원본 데이터를 Azure Blob Storage에 보관하고, 요청을 처리하는 서버는 필요한 데이터를 캐시해서 사용한다.
Cache(캐시)는 자주 사용하는 데이터를 빠르게 가져오기 위해 임시로 보관하는 저장 공간이다.
이렇게 하면 읽기 요청이 많아졌을 때 데이터를 처리하는 서버만 추가하면 된다.
원본 데이터의 복제본을 계속 늘릴 필요가 없으므로 쓰기 작업에 미치는 영향을 줄일 수 있다.
서버 장애 대응 방식도 달라진다.
기존 구조에서는 서버가 고장 나면 해당 서버에 있던 전체 저장소 복제본을 다시 만들어야 할 수 있었다.
새 구조에서는 요청을 처리하는 서버가 고장 나더라도 원본 데이터가 별도 저장소에 남아 있다.
따라서 새로운 서버를 실행하고 필요한 데이터를 다시 가져오는 방식으로 복구할 수 있다.
GitHub는 이를 통해 읽기와 쓰기 성능을 독립적으로 확장하려 한다.
꼭 필요한 부분에서만 합의
새로운 구조의 또 다른 원칙은 Minimize Coordination(불필요한 동기화 최소화)이다.
분산 시스템에서는 여러 서버가 같은 데이터를 변경할 때 결과의 일관성을 유지해야 한다.
하지만 모든 작업을 반드시 순서대로 수행하도록 강제하면 처리 속도가 떨어진다.
GitHub는 Git Push 과정에서 실제로 합의가 필요한 부분이 무엇인지 다시 분석했다.
커밋 객체를 저장하거나, 객체 간 연결이 올바른지 검사하거나, 보안 스캔을 수행하는 작업은 상당 부분 병렬로 처리할 수 있다.
반면 브랜치가 가리키는 최종 커밋을 변경하는 Reference Update는 일관성을 유지해야 한다.
따라서 이 부분에만 필요한 동기화를 집중하고, 나머지 작업은 가능한 한 독립적으로 실행하는 방식을 설계했다.
Garbage Collection(더 이상 사용하지 않는 데이터를 정리하는 작업)과 저장소 압축도 실제 Git 요청을 처리하는 서버에서 분리한다.
새로운 변경이 계속 발생하는 저장소에서는 이런 유지보수 작업이 큰 비용을 만들 수 있기 때문이다.
GitHub의 내부 벤치마크에서 새로운 구조는 기존 시스템보다 최대 35배 높은 쓰기 처리량을 기록했다고 밝혔다.
다만 이는 GitHub가 자체적으로 실행한 초기 성능 평가 결과다.
새 아키텍처가 모든 저장소에 배포돼 실제 운영 환경에서 35배 빠른 Push 속도를 제공한다는 의미는 아니다.
현재도 기존 서비스를 운영하면서 새로운 구조로 전환하는 작업을 진행하고 있다.
이 글은 AI 코딩 에이전트가 개발자에게 제공하는 편의성보다 에이전트가 늘어났을 때 기존 개발 인프라 전체가 어떤 영향을 받는지를 보여준다.
AI가 코드를 생성하는 속도가 빨라져도 그 결과를 저장하고 테스트하고 병합하는 시스템이 충분히 빠르지 않으면 전체 개발 속도는 제한될 수 있다.
앞으로 에이전트 중심의 개발 환경에서는 코드 생성 모델의 성능뿐 아니라 Git, CI/CD, 코드 리뷰와 저장소 관리 시스템의 처리량도 함께 중요해진다는 점을 이해하기 좋은 자료다.
How Agents and Workflows Call Each Other in Conductor
- 저자: Maria Shimkovska
- 발행: Orkes Engineering
- 게시일: 2026-10-06
- 원문: Orkes — How Agents and Workflows Call Each Other in Conductor
AI 에이전트가 기업의 실제 업무를 수행할 때 모든 단계를 LLM에게 자유롭게 결정하도록 맡겨야 하는가라는 문제를 구체적인 코드와 실행 구조로 설명하는 글이다.
많은 기업 업무에는 이미 정해진 절차가 존재한다.
예를 들어 직원이 출장비를 청구하면 금액을 확인하고, 필요한 경우 관리자 승인을 받은 뒤, 회계 시스템에 기록하고 결과를 직원에게 알려야 한다.
이 과정에는 회사가 반드시 지켜야 하는 규칙이 있다.
AI 에이전트가 매번 자유롭게 절차를 생성하게 하면 특정 승인 단계를 건너뛰거나 잘못된 순서로 작업을 수행할 가능성이 있다.
그렇다고 모든 업무를 고정된 코드로만 처리하면 자연어로 들어온 모호한 요청을 이해하기 어렵다.
Orkes는 이런 문제를 해결하기 위해 AI Agent와 Workflow를 서로 다른 역할로 분리하는 구조를 제시한다.
에이전트는 판단하고 워크플로는 실행한다
Workflow(워크플로)는 여러 작업을 정해진 순서와 조건에 따라 실행하는 구조다.
예를 들어 출장비 청구에서는 금액이 일정 기준을 넘으면 관리자 승인을 요청하고, 기준 이하라면 자동 처리하도록 설정할 수 있다.
반면 AI 에이전트는 사용자의 의도를 이해하고 현재 상황에 맞는 다음 행동을 선택한다.
Orkes는 이 둘을 결합하면서 판단이 필요한 부분은 에이전트가 담당하고, 실행 규칙이 명확한 부분은 워크플로가 담당하도록 설계했다.
글에서는 ExpenseBot이라는 예시를 사용한다.
직원이 챗봇에게 출장 중 택시를 이용했다고 설명하지만 금액을 말하지 않았다고 가정해 보자.
에이전트는 먼저 해당 요청이 출장비 환급인지 장비 구매 요청인지 판단한다.
이후 금액, 직원 ID와 비용 종류처럼 실제 처리를 위해 필요한 정보가 충분한지 확인한다.
정보가 부족하면 추가 질문을 한다.
모든 정보가 확보되면 실제 승인 절차는 별도의 워크플로에 전달한다.
이후 출장비 처리와 장비 구매 요청은 각각 다른 워크플로를 사용한다.
이 구조에서는 에이전트가 회계 시스템에 데이터를 기록하거나 관리자 승인을 처리하는 순서를 자유롭게 변경할 수 없다.
이미 정의된 워크플로가 실제 업무 규칙을 강제하기 때문이다.
워크플로 전체를 하나의 도구로 제공
기술적으로 흥미로운 부분은 워크플로 전체를 에이전트의 하나의 도구처럼 제공할 수 있다는 점이다.
일반적인 AI 에이전트는 API 호출이나 함수 실행을 도구로 사용한다.
예를 들어 이메일 발송, 데이터베이스 조회, 파일 생성 등이 각각 하나의 도구가 될 수 있다.
Orkes에서는 이런 작은 작업뿐 아니라 여러 단계로 구성된 워크플로 전체도 하나의 도구로 사용할 수 있다.
에이전트는 출장비 승인 워크플로의 내부 단계들을 직접 조작하지 않는다.
대신 필요한 데이터를 전달하고 워크플로 실행을 요청한다.
실행 결과로 Workflow ID(작업을 식별하는 고유한 ID)를 반환받는다.
이후 진행 상황이 궁금하면 해당 ID를 이용해 상태를 확인한다.
이 방식은 실행 시간이 긴 업무에서 특히 유용하다.
예를 들어 관리자 승인이 필요한 작업은 몇 시간 또는 며칠 동안 대기할 수 있다.
에이전트가 그동안 하나의 API 요청을 계속 열어둘 필요는 없다.
워크플로를 시작한 뒤 사용자의 대화를 종료하고, 나중에 같은 작업의 상태를 조회할 수 있다.
이를 위해 Orkes는 start_workflow()와 상태 조회 기능을 사용한다.
반대 방향으로도 연결할 수 있다
이 글에서는 반대 방향도 설명한다.
즉 워크플로가 특정 단계에서 AI 에이전트를 호출하는 구조다.
예를 들어 대부분의 업무 규칙은 코드로 명확하게 표현할 수 있지만, 일부 요청은 자연어로 작성된 설명을 이해해야 분류할 수 있다.
이런 상황에서는 워크플로가 해당 단계에서 AI 에이전트를 호출해 판단 결과를 받아올 수 있다.
이후 실제 분기와 실행은 다시 워크플로가 담당한다.
따라서 전체 업무를 AI 에이전트가 관리할 필요는 없다.
정해진 업무 흐름 안에서 판단이 필요한 부분에만 AI를 사용할 수 있다.
이 방식은 에이전트의 실행 비용과 예측 불가능성을 줄이는 데 도움이 될 수 있다.
반복적이고 규칙적인 작업까지 모두 언어모델에게 맡길 필요가 없기 때문이다.
장시간 작업의 상태와 복구
Orkes Conductor는 워크플로의 실행 상태를 서버에서 관리한다.
예를 들어 관리자의 승인을 기다리는 동안 프로그램이 중단되거나 서버가 재시작되더라도 이전 실행 상태를 유지할 수 있다.
승인이 완료되면 이전 단계에서 이어서 실행한다.
이런 특성을 Durable Execution(실행 상태를 보존해 장애 이후에도 작업을 이어갈 수 있도록 하는 방식)이라고 한다.
실제 기업 업무에서는 이런 기능이 중요하다.
하나의 AI 에이전트가 수십 단계의 작업을 수행하다가 중간에 오류가 발생했다고 해서 처음부터 전체 과정을 다시 실행하면 중복 결제나 중복 데이터 생성 같은 문제가 발생할 수 있기 때문이다.
Conductor는 실행 기록과 재시도 정책, 대기 상태와 사람의 승인 과정을 별도로 관리한다.
따라서 AI 에이전트의 추론 과정과 실제 업무 실행을 분리하면서도 장시간 작업을 이어갈 수 있도록 한다.
이 글은 Orkes 제품을 중심으로 한 구현 예제이므로 모든 에이전트 프레임워크에 동일한 구조가 적용된다는 의미는 아니다.
하지만 AI가 판단할 부분과 일반적인 프로그램이 반드시 통제해야 할 부분을 어떻게 나눌 것인가라는 문제는 대부분의 기업용 에이전트에서 공통적으로 발생한다.
모든 업무를 AI에게 맡기는 방식보다 기존의 검증된 업무 절차를 유지하면서 필요한 판단에만 AI를 결합하는 구조를 이해하기 좋은 자료다.
Automate remediation post AWS DevOps Agent investigation
- 저자: Michele Scarimbolo
- 발행: AWS Artificial Intelligence Blog
- 게시일: 2026-10-07
- 원문: AWS — Automate remediation post AWS DevOps Agent investigation
AI 에이전트가 실제 서비스의 장애를 분석한 뒤 자동으로 수정 작업까지 수행하도록 만들 수 있는가라는 문제를 구체적인 AWS 아키텍처로 설명하는 글이다.
일반적인 서비스 운영에서는 서버 오류나 성능 저하가 발생하면 운영 담당자가 로그와 모니터링 지표를 확인한다.
이후 문제의 원인을 찾고, 수정 방법을 결정하고, 실제 운영 환경에 변경사항을 적용한다.
AWS의 DevOps Agent는 이 과정 가운데 장애 조사와 원인 분석을 자동화하는 도구다.
로그, 성능 지표와 시스템 구성 정보를 분석해 문제가 발생한 원인과 수정 방향을 제안한다.
하지만 실제 운영 환경에 변경사항을 적용하는 것은 별개의 문제다.
AI가 잘못된 판단을 내리면 장애를 해결하는 대신 더 큰 장애를 발생시킬 수 있기 때문이다.
그래서 많은 조직은 AI 에이전트를 Observe-and-Report Mode(상태를 관찰하고 보고하지만 실제 시스템은 변경하지 않는 방식)로 운영한다.
AWS는 이번 글에서 그다음 단계를 제안한다.
에이전트가 장애를 조사한 결과를 다른 자동화 시스템에 전달하고, 실제 수정 작업은 정해진 권한과 승인 절차를 거쳐 실행하도록 하는 구조다.
장애 분석과 수정 작업의 분리
글에서는 Amazon EventBridge, AWS Lambda Durable Functions, Amazon Bedrock을 결합한다.
EventBridge는 시스템에서 발생한 이벤트를 다른 서비스에 전달하는 기능이다.
예를 들어 DevOps Agent가 장애 조사를 완료하면 그 사실을 이벤트로 전달할 수 있다.
Lambda는 특정 이벤트에 따라 실행되는 서버리스 함수다.
Serverless(서버리스)는 개발자가 서버를 직접 관리하지 않고 필요한 코드를 실행할 수 있도록 하는 클라우드 실행 방식이다.
Durable Functions는 일반적인 Lambda 함수와 달리 장시간 진행되는 작업의 중간 상태를 저장하고 나중에 이어서 실행할 수 있다.
전체 과정은 다음과 같은 방식으로 연결된다.
먼저 DevOps Agent가 장애를 조사하고 원인 분석을 완료한다.
이 결과가 EventBridge를 통해 전달된다.
Lambda 함수는 조사 내용을 정리하고 Durable Function을 시작한다.
Durable Function은 Amazon Bedrock의 모델에게 현재 장애와 가능한 수정 방법을 분석하도록 요청한다.
모델은 미리 정의된 도구 가운데 사용할 도구를 선택한다.
그러나 실제 수정 명령을 실행하기 전에 별도의 검증과 승인 절차가 적용된다.
읽기 작업과 변경 작업을 구분
AWS가 제안한 구조에서 가장 중요한 안전장치는 Read-only 작업과 Mutating 작업을 구분하는 것이다.
Read-only는 시스템의 현재 상태를 읽기만 하는 작업이다.
예를 들어 Lambda 함수의 설정을 확인하거나 로그를 조회하는 행동이 여기에 해당한다.
Mutating은 실제 시스템의 상태를 변경하는 작업이다.
서버 설정을 바꾸거나 권한을 수정하는 행동이 대표적이다.
시스템은 읽기 전용 작업을 자동으로 실행할 수 있다.
반면 실제 인프라를 변경하는 작업에서는 실행을 일시 중단하고 사람의 승인을 기다린다.
이런 구조를 Human-in-the-Loop(HITL, AI의 행동에 사람이 개입해 검토하고 승인하는 방식)이라고 한다.
여기서 중요한 점은 모델에게 단순히 승인을 받으라고 지시하는 것이 아니라 실제 실행 시스템이 승인 여부를 검사한다는 것이다.
또한 모델은 시스템에 존재하는 모든 명령을 자유롭게 사용할 수 없다.
미리 정의된 Allowlist(허용된 항목만 등록한 목록)에 포함된 도구만 사용할 수 있다.
따라서 모델이 잘못된 명령을 생성하더라도 해당 명령을 실행할 도구가 제공되지 않았다면 실제 시스템에 영향을 줄 수 없다.
실제 예시: Lambda 실행 시간 초과 오류
글에서는 Lambda 함수의 실행 시간이 부족해 오류가 발생하는 상황을 예시로 사용한다.
테스트용 Lambda 함수는 실행 제한 시간이 3초로 설정돼 있다.
하지만 실제 작업은 그보다 오래 걸리기 때문에 시간 초과 오류가 발생한다.
DevOps Agent가 로그와 함수 설정을 분석한 뒤 실행 제한 시간이 충분하지 않다는 원인을 찾아낸다.
이 결과를 전달받은 Bedrock 모델은 현재 설정을 다시 조회한다.
실제 제한 시간이 3초라는 사실을 확인한 뒤 이를 30초로 늘리는 수정 작업을 제안한다.
여기까지는 AI가 자동으로 수행한다.
하지만 함수 설정을 변경하는 것은 Mutating 작업이므로 실제 변경 전에 승인이 필요하다.
Durable Function은 실행 상태를 저장하고 승인을 기다린다.
관리자가 변경 내용을 검토한 뒤 승인하면 이전 상태에서 작업이 재개된다.
이후 실제 Lambda 함수의 설정을 수정한다.
여기서 Durable Function은 승인 대기 중에도 작업 상태를 보존할 수 있다.
따라서 관리자가 즉시 응답하지 않더라도 AI 에이전트가 하나의 실행 세션을 계속 유지할 필요가 없다.
AI 자동화에서 중요한 실행 경계
이 글은 AI 모델이 장애를 정확히 분석할 수 있는가보다 분석 결과를 실제 시스템 변경으로 연결할 때 어떤 통제가 필요한가에 초점을 맞춘다.
단순히 AI에게 모든 도구를 제공한 뒤 안전하게 행동하도록 요청하는 방식과 다르다.
AI 모델은 어떤 수정이 필요한지 판단하지만, 실제 실행 가능 범위와 승인 조건은 일반적인 프로그램 코드가 관리한다.
또한 사용 가능한 도구가 제한돼 있으므로 새로운 수정 기능을 추가하려면 해당 도구를 명시적으로 등록해야 한다.
AWS는 이 구조가 장애의 평균 복구 시간인 MTTR(Mean Time to Resolution)을 줄이는 데 도움이 될 수 있다고 설명한다.
하지만 글에서 제시한 예제는 구조의 동작을 보여주는 기술 시연이며 실제 기업의 운영 장애 전체에서 복구 시간이 특정 비율만큼 감소했다는 검증 결과는 아니다.
이번 자료에서 가장 유용한 부분은 AI가 문제를 분석하는 것과 실제 운영 환경을 변경하는 것을 독립적인 과정으로 설계했다는 점이다.
최근 AI 에이전트가 실제 시스템을 직접 조작하는 사례가 늘어나면서 모델의 판단 능력뿐 아니라 도구 접근권한, 실행 상태 보존, 사람의 승인과 사후 감사 기록이 중요한 설계 요소가 되고 있다.
서비스 운영 자동화뿐 아니라 코딩 에이전트, 결제 에이전트와 기업 업무 자동화에도 비슷한 원칙을 적용할 수 있다는 점에서 읽어볼 가치가 있다.
How Qlik built grounded, enterprise-scale AI with Amazon Bedrock
- 저자: Sunil Yerkola, Kent McLean, Sathisan Vannadil
- 발행: AWS Artificial Intelligence Blog / Qlik
- 게시일: 2026-10-07
- 원문: AWS — How Qlik built grounded, enterprise-scale AI with Amazon Bedrock
기업에서 AI를 도입할 때 가장 어려운 문제 가운데 하나는 회사 내부에 존재하는 수많은 데이터에서 정확한 정보를 찾아 근거와 함께 답변하는 것이다.
AI 모델이 아무리 뛰어나더라도 회사의 매출 데이터나 내부 문서, 운영 지표에 접근하지 못하면 실제 업무에 도움이 되는 답변을 만들기 어렵다.
반대로 데이터를 모두 연결하더라도 접근권한이나 정보의 정확성을 보장하지 못하면 중요한 정보가 유출되거나 잘못된 의사결정으로 이어질 수 있다.
데이터 분석 플랫폼 기업 Qlik은 이 문제를 해결하기 위해 Qlik Answers라는 기업용 AI 시스템을 개발했다.
Qlik은 전 세계 4만 개가 넘는 고객사를 지원하고 있으며, 각 고객의 데이터 구조와 보안 요구사항이 다르다.
이번 글은 이처럼 서로 다른 환경에서 AI 서비스를 제공하기 위해 어떤 아키텍처를 사용했는지 구체적으로 설명한다.
하나의 거대한 에이전트 대신 역할별 계층 구성
Qlik은 모든 질문을 하나의 대형 LLM이 처리하도록 만들지 않았다.
대신 시스템을 일곱 개의 주요 계층으로 나눴다.
첫 번째는 사용자가 자연어로 질문하는 Entry Layer다.
두 번째는 질문을 분석해 어떤 작업이 필요한지 선택하는 Routing Layer다.
Routing Layer는 실제 질문에 대한 답을 생성하는 역할까지 담당하지 않는다.
단순히 어떤 처리 경로를 사용해야 하는지 판단한다.
예를 들어 사용자가 특정 문서에 대해 질문했다면 문서 검색 경로로 보내고, 매출 변화에 대해 질문했다면 분석 경로로 전달한다.
세 번째는 여러 처리 결과를 모아 최종 답변을 만드는 Answer Layer다.
간단한 질문은 빠르게 처리하고, 복잡한 질문은 여러 하위 질문으로 나눠 서로 다른 자료에서 정보를 가져온다.
네 번째는 Specialist Agent Layer다.
각 전문 에이전트가 자신에게 맞는 도구와 정보를 사용하도록 구성한다.
다섯 번째는 구조화된 데이터를 분석하는 Conversational Analytics Layer다.
예를 들어 매출 데이터나 고객별 사용량처럼 데이터베이스에 저장된 정보를 분석할 때 사용한다.
여섯 번째는 일반 문서를 검색하는 Retrieval Layer다.
여기에는 Amazon OpenSearch Service가 사용된다.
마지막 일곱 번째는 실제 언어모델을 호출하는 Model Access Layer다.
Qlik은 자체 LLM Gateway를 통해 Amazon Bedrock에 연결한다.
이렇게 구성하면 특정 모델이 변경되더라도 전체 업무 흐름을 다시 만들 필요가 줄어든다.
검색 결과를 그대로 신뢰하지 않는다
Qlik이 강조하는 부분은 Grounding(근거 기반 답변 생성)이다.
Grounding은 AI가 답변을 생성할 때 실제 문서나 데이터에서 확인한 정보를 근거로 사용하도록 하는 방식이다.
일반적인 RAG 시스템에서는 사용자의 질문과 관련된 문서를 검색한 뒤 해당 내용을 LLM에 전달한다.
하지만 문서를 검색했다고 해서 모델이 반드시 그 내용을 정확하게 사용할 것이라는 보장은 없다.
모델은 여러 문서의 내용을 잘못 연결하거나 원문에 존재하지 않는 결론을 만들 수 있다.
Qlik은 이를 줄이기 위해 검색과 답변 검증을 별도의 단계로 분리했다.
먼저 관련 문서와 데이터를 검색한다.
이후 모델이 답변을 생성하면 Amazon Bedrock Guardrails의 Contextual Grounding 기능을 사용해 답변이 실제로 제공된 자료에 근거하는지 검사한다.
즉 검색 결과를 확보하는 것에서 끝나지 않고 최종 답변이 검색된 근거와 일치하는지 다시 확인하는 것이다.
문서 기반 답변에는 사용자가 직접 원문을 확인할 수 있도록 출처도 포함한다.
물론 이런 검증 장치가 모든 잘못된 답변을 완전히 차단한다는 의미는 아니다.
하지만 모델에게 단순히 사실에 근거해 답하라고 지시하는 것보다 별도의 검증 계층을 두는 방식이 운영 환경에서 더 명확한 통제 수단이 될 수 있다.
여러 국가의 데이터 규제에 대응
Qlik은 전 세계 고객을 대상으로 서비스를 운영한다.
따라서 고객이 사용하는 데이터가 어느 국가에 저장되고 처리되는지도 중요하다.
어떤 기업은 개인정보나 업무 데이터를 특정 국가나 지역 밖으로 전송하지 못하도록 규정하고 있다.
이를 Data Residency(데이터 위치 요건)라고 한다.
Qlik은 11개 AWS 리전에 걸쳐 서비스를 운영하면서 지역별 데이터 처리 요구사항을 충족하도록 설계했다.
Amazon Bedrock의 Cross-Region Inference를 사용하되, 지역별 규제와 고객 요구사항에 맞는 범위 안에서 모델을 호출한다.
특정 지역에서 필요한 모델이 Bedrock에 제공되지 않는 경우에는 해당 지역의 Amazon SageMaker AI에 모델을 직접 호스팅하는 방식을 사용한다.
즉 모델 제공 위치 때문에 고객 데이터가 반드시 다른 국가로 이동하도록 만들지 않는 것이다.
또한 Qlik은 고객마다 사용할 수 있는 AI 기능을 다르게 설정할 수 있도록 했다.
이를 Tenant-Level Feature Flag라고 한다.
Tenant는 하나의 소프트웨어 플랫폼을 사용하는 독립적인 고객 조직을 의미한다.
Feature Flag는 특정 기능을 켜거나 끌 수 있는 설정이다.
따라서 새로운 에이전트 기능을 모든 고객에게 한꺼번에 적용하지 않고, 준비된 고객에게만 순차적으로 제공할 수 있다.
이런 방식은 새로운 기능을 추가할 때 기존 서비스의 안정성을 유지하는 데 도움이 된다.
실제 운영 결과
Qlik이 공개한 사례에 따르면 2026년 2월 AI 에이전트 기능이 정식 출시된 이후 Discovery Agent가 10만 건 이상의 분석 결과를 고객에게 제공했다.
Discovery Agent는 데이터에서 이상치나 변화 패턴을 찾아내는 기능이다.
일부 고객 사례에서는 업무 시간도 줄어들었다.
산업용 소재 공급업체인 Lintech International은 1만7,000개가 넘는 기술 문서를 Qlik Answers에 연결했다.
그 결과 일부 업무에서 응답 시간이 75% 감소했고, 관리자에게 주당 최대 7시간의 업무 시간을 돌려줬다고 보고했다.
다만 이 수치는 Qlik과 고객사가 공개한 사례이며 독립적인 통제 실험으로 검증된 일반적인 AI 생산성 향상률은 아니다.
Qlik은 모델 사용량을 예측하는 작업도 중요하게 다뤘다.
새로운 AI 기능을 출시하기 3~6개월 전부터 모델 호출량과 토큰 사용량을 예측하고, 실제 출시 이후 예측값과 사용량을 비교했다.
Token(토큰)은 언어모델이 텍스트를 처리할 때 사용하는 기본 단위다.
사용자 수가 늘어나면 모델 요청량과 토큰 사용량도 증가하기 때문에 실제 운영에서는 모델 비용과 컴퓨팅 자원을 미리 준비해야 한다.
Qlik은 이런 과정을 통해 새로운 기능을 출시하더라도 기존 고객의 서비스 안정성을 유지하려 했다.
이 글은 기업용 AI 에이전트를 하나의 챗봇으로 만드는 것과 수많은 기업 고객이 실제로 사용할 수 있는 서비스로 운영하는 것의 차이를 보여준다.
특히 모델 선택, 검색, 근거 검증, 데이터 처리 지역, 고객별 기능 설정과 운영 비용을 각각 독립적으로 관리하는 구조가 인상적이다.
AI 제품을 실제 서비스에 적용할 때 모델의 추론 성능보다 전체 시스템의 데이터 신뢰성과 운영 구조가 더 큰 과제가 될 수 있다는 점을 구체적인 아키텍처와 운영 사례로 이해하기 좋은 글이다.