AI 데일리 브리핑 — 2026-10-25

기준 시점: 2026-10-25 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-24 06:00 ~ 2026-10-25 06:00 KST
추천 글 범위: 2026-10-18 06:00 ~ 2026-10-25 06:00 KST

---

1️⃣ 주요 모델·연구

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

2️⃣ AI 제품·서비스

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

3️⃣ 개발 도구·에이전트

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

4️⃣ 산업·정책·안전

영국, AI 생물보안 연구소 신설·국가 사이버 방어 체계 확대…OpenAI·Anthropic 최대 2억 파운드 상당 기술 지원

• 발표일: 2026-10-24 — 정확한 게시 시각 미확인
• 적용 범위: AI 안전, 생물보안, AI 신약 연구, 사이버보안 에이전트, 국가 핵심 인프라, AI 반도체, 기술 주권
• 원문: 영국 내각부 — Introducing the AI Biosecurity Lab
• 관련 원문: 영국 재무부 — Chancellor unveils Britain's ambitious plan for AI

---

영국 정부가 AI의 생물학적 위험과 사이버보안 위협에 대응하기 위한 대규모 국가 계획을 발표했다.

이번 발표의 핵심은 AI Biosecurity Lab(AIBL)이라는 새로운 생물보안 연구기관을 설립하고, 기존 AI 안전 평가기관과 국가 사이버 방어 체계에 추가적인 자원을 투입한다는 것이다.

특히 OpenAI와 Anthropic이 새 연구기관에 최대 2억 파운드 상당의 AI 모델·컴퓨팅 자원과 기술 지원을 제공하기로 했다.

Google DeepMind와 영국 생명과학 AI 기업 Basecamp Research도 연구 협력에 참여한다.

이번 발표는 새로운 AI 모델이나 보안 제품이 정식 출시됐다는 소식은 아니다.

강력한 AI를 이용해 생물학적 위험을 더 빨리 탐지하고 대응하는 동시에, AI 자체가 새로운 위험을 만들어낼 가능성도 관리하기 위한 연구·운영 체계를 구축하겠다는 정부 계획이다.

영국 정부는 생물보안과 사이버 방어뿐 아니라 국내 AI 기술 역량, 반도체 설계 인력과 노동시장 연구를 지원하는 계획도 함께 발표했다.

AI 생물보안 연구소에 정부 자금 1억 파운드 배정

영국 정부는 새로운 AI Biosecurity Lab의 설립과 운영을 위해 1억 파운드를 배정했다.

AIBL은 정부 부처 내부의 일반적인 행정조직이 아니라 독립적인 비영리 연구기관으로 설립될 예정이다.

비영리기관이라는 것은 이익을 주주에게 배분하는 대신 정해진 공익 목적을 위해 운영하는 조직을 의미한다.

AIBL의 주요 목표는 AI를 이용해 생물학적 위험을 더 빨리 발견하고, 백신과 치료제 등의 대응 수단을 개발하는 데 필요한 연구를 가속하는 것이다.

여기서 Biosecurity(생물보안)는 감염성 병원체나 생물학적 물질로 인해 발생할 수 있는 위험을 예방하고 대응하는 활동을 의미한다.

여기에는 자연적으로 발생하는 감염병뿐 아니라 연구시설의 사고와 생물학적 기술의 악용 가능성도 포함될 수 있다.

최근 AI는 단백질 구조를 예측하고 새로운 분자를 설계하는 등 생명과학 연구에서 활용 범위를 넓히고 있다.

예를 들어 특정 병원체의 단백질 구조를 분석하면 해당 단백질에 결합하는 후보 물질을 찾는 연구에 도움을 줄 수 있다.

백신 개발 과정에서도 병원체의 특성을 분석하거나 실험할 후보를 선정하는 데 AI를 활용할 수 있다.

하지만 AI가 생물학적 연구를 쉽게 만드는 기술은 다른 방향으로도 사용될 수 있다.

고도로 전문적인 지식이 필요한 일부 작업의 진입장벽이 낮아지면 악의적인 목적을 가진 사람이 위험한 생물학적 정보를 얻거나 활용할 가능성도 증가할 수 있기 때문이다.

AIBL은 이 두 문제를 함께 다룬다.

AI를 이용해 실제 생물학적 위협에 대응하는 능력을 높이는 동시에, 강력한 AI 시스템이 만들어낼 수 있는 새로운 생물학적 위험을 평가하는 것이다.

초기 연구는 크게 두 가지에 집중할 예정이다.

첫 번째는 새로운 생물학적 위협을 조기에 발견하는 기술이다.

두 번째는 백신과 치료제 등 Medical Countermeasure(의료적 대응 수단)의 발견과 개발, 시험을 가속하는 기술이다.

다만 이러한 목표가 발표됐다는 사실만으로 AIBL이 새로운 병원체를 실제로 발견했거나 백신 개발 기간을 단축하는 데 성공했다는 의미는 아니다.

현재는 기관 설립과 초기 연구 방향을 발표한 단계다.

OpenAI와 Anthropic의 2억 파운드는 현금 기부가 아니다

이번 발표에서 가장 구분해야 할 부분은 정부 자금과 민간 기업의 지원 형태다.

AIBL에는 다음과 같은 자원이 제공될 예정이다.

영국 정부는 AIBL이 최대 3억 파운드 규모의 정부 자금과 기업 지원을 바탕으로 출범한다고 설명한다.

하지만 이는 3억 파운드의 현금이 하나의 계좌에 지급된다는 의미가 아니다.

정부가 제공하는 1억 파운드는 공공자금이다.

반면 OpenAI와 Anthropic의 지원은 주로 AI 모델을 실행하기 위한 크레딧과 컴퓨팅 자원, 기술적 접근권한으로 구성된다.

AI 연구에서는 이런 자원이 매우 중요할 수 있다.

예를 들어 수많은 단백질 후보를 생성하고 평가하는 연구를 수행하려면 대규모 모델을 반복해서 실행해야 할 수 있다.

모델의 추론과 실험 데이터 분석에 사용하는 계산 자원이 부족하면 연구 자체가 제한될 수 있다.

따라서 컴퓨팅 크레딧은 연구에 필요한 실제 비용을 낮추는 역할을 한다.

하지만 크레딧을 현금으로 전환하거나 기관 운영비에 자유롭게 사용할 수 있다고 가정해서는 안 된다.

또한 최대 2억 파운드라는 표현은 OpenAI의 1억 파운드 상당 지원과 Anthropic의 최대 1억 파운드 상당 지원을 합친 금액이다.

모든 지원이 발표 당일 제공 완료됐다는 뜻도 아니다.

OpenAI의 Rosalind Biodefense와 과학 전문 모델 접근

OpenAI는 Rosalind Biodefense 프로그램을 통해 AIBL을 지원할 계획이다.

Rosalind는 OpenAI의 생명과학 연구 관련 AI 시스템과 연결된 이름이다.

이번 프로그램에서는 생물보안 연구에 필요한 강력한 모델과 컴퓨팅 자원에 접근할 수 있도록 지원한다.

여기서 중요한 것은 Trusted Access(신뢰 기반 접근)라는 개념이다.

강력한 생명과학 AI의 일부 능력은 정상적인 연구에 도움이 될 수 있지만 악용 가능성도 함께 고려해야 한다.

따라서 모든 사용자에게 제한 없이 동일한 기능을 제공하는 대신 검증된 기관과 연구자가 정해진 조건에서 모델을 활용하도록 하는 접근이 가능하다.

AIBL은 이런 접근권한을 이용해 생물학적 위험을 탐지하거나 대응 수단을 연구하는 작업을 진행할 수 있다.

Anthropic도 비슷한 방식으로 모델 접근권한과 전담 기술 지원을 제공한다.

다만 이번 발표에서 두 회사의 모델이 AIBL의 모든 연구 업무를 자동으로 수행하도록 통합됐다는 내용은 확인되지 않는다.

연구 분야와 접근 방식은 실제 기관이 운영되면서 구체화될 예정이다.

Google DeepMind와 Basecamp Research의 역할

Google DeepMind도 AIBL과 연구 협력을 진행한다.

영국 정부에 따르면 Google DeepMind의 과학자와 생물보안 전문가들이 연구에 참여하고, Gemini와 전문 과학 모델에 대한 제한적 접근을 제공하는 방안도 검토할 예정이다.

Basecamp Research는 생물학 데이터를 이용한 AI 모델과 관련 전문 기술을 제공한다.

이러한 협력은 AIBL이 특정한 하나의 AI 모델 제공업체에만 의존하지 않는 구조를 만들 가능성을 보여준다.

생명과학 연구에 사용하는 모델은 기능이 다양하다.

일반적인 언어모델은 논문을 읽고 연구 가설을 정리하는 데 유용할 수 있다.

반면 단백질 구조와 서열을 학습한 전문 모델은 분자 수준의 예측과 설계에 더 적합할 수 있다.

따라서 여러 종류의 모델을 연구 목적에 맞게 선택하는 접근이 필요하다.

다만 협력 계획이 발표됐다는 사실과 모든 전문 모델의 실제 제공 조건이 확정됐다는 사실은 구분해야 한다.

특히 Google DeepMind의 일부 모델 접근은 향후 제공을 검토하는 단계다.

보건·동물·국방·의약품 규제기관과 협력

AIBL은 독립적인 연구기관이지만 영국 정부의 여러 전문기관과 협력하도록 설계됐다.

주요 협력 대상은 다음과 같다.

UKHSA(UK Health Security Agency)는 영국의 보건안보 기관이다.

감염병과 공중보건 위협을 감시하고 대응하는 역할을 수행한다.

APHA(Animal and Plant Health Agency)는 동물과 식물의 건강, 관련 생물학적 위험을 다루는 기관이다.

Dstl(Defence Science and Technology Laboratory)은 국방 분야의 과학기술 연구를 수행하는 기관이다.

MHRA(Medicines and Healthcare products Regulatory Agency)는 의약품과 의료기기를 규제하는 기관이다.

AIBL은 이러한 기관과 협력해 새로운 생물학적 위협에 대응하는 능력을 개발할 계획이다.

특히 MHRA와는 보건 비상사태 대응과 AI가 설계한 의약품의 규제 문제도 다룰 예정이다.

AI가 새로운 후보 물질을 찾아내더라도 그 물질이 안전하고 실제로 효과가 있는지는 별도로 확인해야 한다.

이 과정에는 실험실 검증과 품질관리, 임상시험과 규제기관의 심사가 필요하다.

따라서 AI 기반 신약 연구를 확대하려면 모델 개발자뿐 아니라 규제기관과 실제 연구기관이 함께 참여하는 구조가 중요하다.

AIBL은 학계와 산업계, 비영리 부문의 전문가로 구성된 과학자문위원회의 지원도 받을 예정이다.

다만 자문위원회의 구체적인 구성과 운영 규칙은 아직 공개되지 않았다.

국가 AI 생물보안 계획에는 총 1억6,500만 파운드

AIBL은 더 큰 규모의 National AI Biosecurity Initiative(국가 AI 생물보안 계획)에 포함된다.

해당 계획에는 총 1억6,500만 파운드의 정부 자금이 배정됐다.

이 가운데 1억 파운드는 AIBL을 위한 자금이다.

나머지 6,500만 파운드는 생물학적 위협의 감시 능력을 강화하고 우선적인 병원체에 대한 의료적 대응 수단을 개발하는 데 사용될 예정이다.

이 금액은 AIBL에 배정된 1억 파운드와 별도로 더해지는 정부 투자다.

하지만 AIBL의 민간 기업 지원을 포함한 최대 3억 파운드와 국가 계획의 1억6,500만 파운드를 단순히 별개의 총액으로 모두 더하면 중복 계산이 발생한다.

1억 파운드의 AIBL 정부 자금은 두 발표에 공통으로 포함돼 있기 때문이다.

AI Security Institute에 1억2,000만 파운드 추가

영국 정부는 기존의 AI Security Institute(AISI)에도 1억2,000만 파운드를 추가 지원한다고 발표했다.

AISI는 강력한 AI 모델의 능력과 위험성을 평가하는 기관이다.

예를 들어 모델이 복잡한 사이버보안 작업을 얼마나 잘 수행하는지, 특정한 안전장치를 우회할 가능성이 있는지 등을 연구할 수 있다.

생물보안 연구를 위한 AIBL과 달리 AISI는 더 넓은 범위의 AI 능력과 위험을 평가한다.

이번 추가 자금은 새로운 AI 시스템의 시험과 연구, 기술적 안전 기준을 개발하는 데 사용될 예정이다.

중요한 점은 AISI가 이번 발표에서 처음 설립되는 기관이 아니라는 사실이다.

새롭게 발표된 것은 기존 기관에 대한 추가적인 자금 지원과 연구 역량 확대 계획이다.

국가 사이버 방어에 AI 에이전트 도입

영국 정부는 사이버보안에도 새로운 AI 프로그램을 도입한다.

가장 큰 변화 가운데 하나는 National Cyber Shield다.

이 프로그램에는 6,000만 파운드가 배정됐다.

National Cyber Shield는 AI 에이전트를 이용해 국가의 사이버 방어 능력을 강화하는 것을 목표로 한다.

AI Agent(에이전트)는 단순히 질문에 답하는 것을 넘어 목표를 달성하기 위해 외부 도구를 선택하고 여러 단계를 실행하도록 구성된 AI 시스템이다.

예를 들어 일반적인 보안 감시 시스템에서는 분석가가 수많은 경고를 확인하고 실제 위험이 있는지 조사해야 한다.

AI 에이전트는 일부 경고를 분류하고 관련 로그를 조회하거나, 알려진 취약점이 실제 시스템에 존재하는지 확인하는 과정을 지원할 수 있다.

하지만 보안 분야에서 자동화 수준을 높이면 다른 위험도 생긴다.

에이전트가 잘못된 판단으로 정상적인 서비스를 차단하거나 중요한 시스템의 설정을 변경할 가능성이 있기 때문이다.

따라서 국가 핵심 인프라에 AI 에이전트를 활용할 때는 실제로 허용할 행동의 범위를 명확하게 정해야 한다.

National Cyber Shield에는 영국의 AI·사이버보안 기업을 지원하는 2,500만 파운드 규모의 기술 혁신 프로그램도 포함된다.

또한 AI 에이전트를 이용한 사이버보안 도구를 실제 환경에서 시험하기 위한 Regulatory Sandbox(규제 샌드박스)를 검토할 예정이다.

규제 샌드박스는 새로운 기술을 정해진 조건과 감독 아래 시험하도록 하는 제도다.

다만 현재 발표된 내용은 관련 제도를 검토하겠다는 계획이다.

실제 규제 샌드박스의 운영 규칙과 참여 조건이 모두 확정됐다는 의미는 아니다.

국가 핵심 인프라의 취약점을 찾는 NERV 센터 설립

영국 정부는 별도로 7,000만 파운드를 투입해 NERV Centre를 설립할 계획이다.

NERV는 National Exposure and Real-Time Vulnerability의 약자다.

국가 핵심 인프라와 경제 전반에 존재하는 사이버보안 취약점을 AI 도구로 찾아내는 역할을 맡는다.

여기서 Vulnerability(취약점)는 공격자가 시스템의 보안 요구사항을 우회하거나 잘못된 행동을 유도할 수 있는 약점을 의미한다.

예를 들어 인터넷에 노출된 서버에서 오래된 소프트웨어를 사용하는 경우 알려진 취약점이 존재할 수 있다.

하지만 취약점이 발견됐다는 사실과 해당 시스템이 실제로 침해됐다는 사실은 다르다.

실제 위험을 평가하려면 서비스가 어떤 방식으로 외부에 노출돼 있는지, 공격에 필요한 조건이 충족되는지 등을 확인해야 한다.

NERV는 AI를 활용해 이러한 위험을 더 빠르게 식별하고 분석하려는 계획이다.

다만 실제 조직이 어느 정도의 시스템을 감시할 수 있을지, 취약점 탐지 정확도가 얼마나 높을지는 이번 발표에서 검증된 결과로 제시되지 않았다.

기관 설립 계획과 실제 보안 탐지 성능을 구분할 필요가 있다.

AI 반도체 설계와 자국 기술 역량에도 투자

영국 정부는 AI 안전뿐 아니라 자국 기술 역량을 확대하기 위한 계획도 발표했다.

대표적으로 1,800만 파운드를 투입해 UK Advanced Chip Design Academy를 지원한다.

이 프로그램은 첨단 반도체 설계에 필요한 인재를 양성하고 연구기관과 반도체 제조 산업의 연결을 강화하는 것을 목표로 한다.

AI 반도체는 대규모 행렬 계산과 높은 메모리 대역폭 등을 제공하도록 설계되는 경우가 많다.

하지만 AI 모델을 직접 실행하는 GPU와 TPU를 보유하는 것과 해당 반도체를 설계·제조할 역량을 갖추는 것은 다른 문제다.

영국 정부는 이런 기술 의존도를 줄이고 국내 전문 인력을 늘리려 한다.

또한 Sovereign AI Fund에 6,000만 파운드를 추가 배정하고, 관련 연구개발 조달 프로그램에도 6,000만 파운드를 지원할 예정이다.

지원 분야에는 로봇과 자율 시스템, 산업용 AI 등이 포함된다.

다만 이 항목들은 신기술이나 제품 출시가 아니라 산업 육성을 위한 자금·조달 계획이다.

따라서 실제 기술적인 성과는 이후 개별 연구와 기업의 개발 결과를 통해 확인해야 한다.

발표된 예산과 실제 집행은 구분

이번 발표는 영국 정부가 AI 안전과 산업정책을 국가 예산의 중요한 부분으로 다루고 있음을 보여준다.

하지만 발표한 금액이 모두 이미 집행됐다는 의미는 아니다.

또한 상당수 계획은 향후 예산과 세부 운영 절차를 통해 실행될 예정이다.

특히 AI Biosecurity Lab과 NERV Centre처럼 새로운 조직을 설립하는 계획에서는 실제 운영 인력과 연구 장비, 협력기관의 역할이 구체화돼야 한다.

이번 발표에서 확인할 수 있는 가장 큰 변화는 AI를 이용해 새로운 위험을 찾아내고 방어하는 기술을 국가 차원의 연구·운영 인프라로 구축하려는 방향이다.

AI가 더 강력해질수록 모델 자체의 안전성 평가뿐 아니라 실제 사회에서 발생할 수 있는 생물학적 위험과 사이버 공격, 기술 의존 문제를 함께 다뤄야 한다는 정책적 접근이 나타나고 있다.

---

📚 추천 글

Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)

• 저자: Jon Lee, Hrachya Hakobyan, Chaomin Yu
• 발행: OpenAI Engineering
• 게시일: 2026-10-23
• 원문: OpenAI — Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)

---

ChatGPT처럼 수많은 사용자가 동시에 이용하는 서비스를 운영하려면 AI 모델의 추론 성능 외에도 여러 종류의 시스템이 필요하다.

예를 들어 사용자의 대화 기록을 저장하고 다시 읽는 데이터베이스가 있어야 한다.

사용자의 접근권한과 설정, 여러 서비스 사이의 상태도 관리해야 한다.

AI 모델이 아무리 빠르게 답변을 생성하더라도 이런 정보를 가져오는 데이터베이스가 느리면 전체 서비스의 응답 속도에 영향을 줄 수 있다.

이 글은 OpenAI가 10억 명 이상의 사용자에게 데이터를 제공하는 내부 저장 플랫폼을 어떻게 확장했는지 설명한다.

특히 성공한 설계뿐 아니라 실제 운영에서 실패했던 접근법과 그 이유를 구체적으로 공개한다는 점에서 읽어볼 가치가 있다.

OpenAI의 공통 저장 플랫폼 Habitat

OpenAI는 ChatGPT와 Codex, API 등 여러 제품에 필요한 데이터를 관리하기 위해 Habitat이라는 공통 저장 플랫폼을 사용한다.

Habitat은 40개 지역에서 사용자에게 데이터를 제공한다.

전체 저장 규모는 500PB 이상이다.

PB(Petabyte, 페타바이트)는 대규모 저장 용량을 나타내는 단위로, 1PB는 약 100만 GB에 해당한다.

이처럼 많은 데이터를 관리하기 위해 OpenAI는 Microsoft Azure의 Cosmos DB를 사용한다.

Cosmos DB는 대규모 데이터를 여러 지역에 분산 저장하고 빠르게 조회하도록 설계된 데이터베이스 서비스다.

처음부터 현재와 같은 규모의 시스템이 만들어진 것은 아니다.

OpenAI는 사용자와 서비스가 증가하면서 저장 구조를 여러 번 변경했다.

처음에는 하나의 데이터베이스를 여러 서비스가 공유

초기에는 여러 제품이 하나의 공통 저장 공간을 공유했다.

이를 Multi-Tenancy(멀티테넌시)라고 한다.

멀티테넌시는 여러 사용자나 서비스가 하나의 인프라를 함께 사용하면서 논리적으로 데이터를 구분하는 구조다.

이 방식은 자원 관리가 단순하고 비용 측면에서도 유리할 수 있다.

예를 들어 특정 서비스의 사용량이 일시적으로 증가하더라도 전체 데이터베이스에 충분한 여유가 있다면 추가적인 인프라 구성 없이 처리할 수 있다.

하지만 문제가 발생했다.

특정 서비스에서 요청이 갑자기 증가하면 같은 저장 자원을 사용하는 다른 서비스까지 영향을 받는 것이다.

이를 Noisy Neighbor(시끄러운 이웃 문제)라고 한다.

예를 들어 상대적으로 작은 기능이 갑자기 많은 데이터베이스 요청을 발생시키면서 로그인과 회원가입 같은 핵심 기능의 응답 속도까지 느려질 수 있었다.

문제는 서로 다른 서비스가 논리적으로 구분돼 있더라도 실제 저장 장치의 처리량을 공유할 수 있다는 점이었다.

논리적 파티션과 물리적 파티션의 차이

Cosmos DB는 데이터를 여러 Partition(파티션)으로 나누어 관리한다.

논리적 파티션은 특정 키를 기준으로 데이터를 구분하는 단위다.

예를 들어 user_id나 workspace_id를 기준으로 데이터를 분리할 수 있다.

하지만 실제 처리량 제한은 물리적 파티션에 적용될 수 있다.

따라서 서로 다른 논리적 파티션이 같은 물리적 파티션을 공유하면 하나의 요청 집중 현상이 다른 데이터에도 영향을 줄 수 있다.

OpenAI는 데이터의 크기가 증가하면서 물리적 파티션이 나뉘는 과정에서도 문제를 경험했다.

전체 처리량이 그대로인데 파티션 수만 증가하면 각 파티션에 할당되는 처리량이 줄어들 수 있었다.

즉 저장 데이터가 증가했다는 이유만으로 실제 요청을 처리할 수 있는 여유가 감소하는 상황이 발생한 것이다.

모든 서비스를 분리했더니 다른 문제가 발생

OpenAI는 이러한 문제를 해결하기 위해 서비스마다 별도의 데이터베이스 컨테이너를 사용하는 방식으로 전환했다.

이를 Single-Tenancy(단일 테넌시)에 가까운 구조라고 할 수 있다.

서비스 사이의 자원 간섭은 줄어들었다.

하지만 이제 각 제품팀이 자신의 데이터베이스 용량을 직접 계획해야 했다.

예를 들어 개발 환경에서는 초당 1,000건의 요청만 발생하던 기능이 실제 출시 이후 초당 100만 건의 요청을 받게 될 수 있다.

공유 데이터베이스에서는 이런 증가가 전체 처리량의 일부에 불과할 수 있다.

반면 별도의 작은 데이터베이스를 사용한다면 서비스 출시 전에 필요한 처리량을 확보하지 못해 장애가 발생할 수 있다.

실제로 OpenAI는 기능 출시 직전에 데이터베이스 용량을 급히 확장해야 하는 상황을 여러 번 경험했다고 설명한다.

이 문제는 단순한 기술적 문제가 아니다.

각 제품팀이 데이터베이스의 처리량과 비용을 정확하게 예측해야 한다는 조직 운영 문제도 발생한다.

OpenAI는 결국 다시 공유 구조로 돌아갔다.

다만 처음의 구조로 단순하게 복귀한 것은 아니다.

공유 구조를 유지하면서 자원 사용량을 제어

OpenAI는 Microsoft Azure 팀과 협력해 세 가지 기능을 개선했다.

첫 번째는 Hot Key Throttling이다.

특정 데이터 키에서 지나치게 많은 요청이 발생하면 해당 키의 요청을 먼저 제한한다.

이를 통해 하나의 사용자가 전체 파티션의 처리량을 소모하는 상황을 줄일 수 있다.

두 번째는 QoS(Quality of Service, 서비스 품질에 따른 우선순위 관리)다.

예를 들어 사용자가 로그인하는 요청과 백그라운드 데이터 분석 작업은 중요도가 다를 수 있다.

사용자에게 즉시 응답해야 하는 요청을 우선 처리하고, 대량의 데이터를 분석하는 배치 작업은 상대적으로 낮은 우선순위를 부여할 수 있다.

세 번째는 Serverless Mode(사용량에 따라 자원을 관리하는 방식)의 개선이다.

OpenAI는 Azure와 함께 물리적 파티션당 최대 10,000RU/s를 사용할 수 있도록 관련 기능을 확장했다.

RU(Request Unit)는 Cosmos DB가 데이터베이스 요청을 처리하는 데 필요한 자원을 표현하는 단위다.

이런 변경 이후 OpenAI는 대부분의 서비스를 다시 공통 컨테이너에서 운영하면서도 이전의 자원 간섭 문제를 줄일 수 있었다고 설명한다.

캐시와 변경 알림을 결합해 읽기 지연시간 12배 개선

OpenAI는 데이터베이스 구조뿐 아니라 캐시도 개선했다.

Cache(캐시)는 자주 사용하는 데이터를 상대적으로 빠른 저장공간에 보관하는 기술이다.

예를 들어 사용자가 자주 조회하는 대화 목록을 매번 먼 지역의 데이터베이스에서 읽는 대신 사용자에게 가까운 캐시에서 반환할 수 있다.

하지만 캐시에는 오래된 정보가 남는 문제가 있다.

일반적인 해결책은 일정 시간이 지나면 데이터를 삭제하는 TTL(Time to Live)이다.

그러나 TTL이 짧으면 캐시 적중률이 낮아질 수 있다.

반대로 TTL이 길면 실제 데이터가 수정된 뒤에도 오래된 값을 반환할 수 있다.

OpenAI는 이를 해결하기 위해 CDC(Change Data Capture)를 사용한다.

CDC는 데이터베이스에서 발생한 변경사항을 감지해 다른 시스템으로 전달하는 기술이다.

데이터가 수정되면 변경 이벤트를 캐시 시스템에 전달하고, 관련된 오래된 데이터를 무효화한다.

OpenAI는 이런 변경을 전 세계 캐시에 수초 안에 전파하도록 설계했다.

또한 자주 사용하는 작은 데이터를 여러 지역에 복제하고, 일부 중간 서버 코드를 Python에서 Rust로 변경했다.

이러한 개선을 결합한 결과 전 세계 읽기 요청의 중앙값 지연시간이 약 120ms에서 10ms로 감소했다고 밝혔다.

약 12배 개선된 결과다.

하지만 이는 여러 기술적 변경을 함께 적용한 자체 측정 결과다.

Rust로 코드를 변경한 것만으로 12배 개선됐다는 의미는 아니다.

또한 데이터베이스 읽기 지연시간이 줄었다는 사실과 ChatGPT의 전체 답변 생성 시간이 같은 비율로 빨라졌다는 사실은 다르다.

확장성보다 중요한 것은 운영 가능한 구조

이번 글에서 특히 인상적인 부분은 OpenAI가 멀티테넌시와 단일 테넌시 사이를 여러 번 이동했다는 점이다.

처음에는 단순한 공유 구조가 좋았다.

사용자가 증가하자 공유 구조의 자원 간섭 문제가 심각해졌다.

그래서 서비스를 분리했다.

하지만 서비스가 더 많아지자 분리된 데이터베이스를 관리하는 비용이 커졌다.

결국 공유 구조의 문제를 기술적으로 해결하고 다시 중앙에서 자원을 관리하는 방식으로 돌아갔다.

이는 시스템 설계에 하나의 영구적인 정답이 존재하지 않을 수 있다는 사실을 보여준다.

OpenAI는 앞으로 더 큰 규모의 데이터를 관리하기 위해 RocksDB Cloud와 Raft 기반의 자체 분산 저장 시스템도 개발하고 있다고 밝혔다.

다만 이 시스템은 아직 개발 중이며 현재 모든 Habitat 저장소를 대체한 것은 아니다.

이번 글은 AI 서비스의 사용자 경험이 모델의 성능뿐 아니라 데이터베이스의 확장성과 캐싱, 서비스 사이의 자원 격리, 운영 조직의 의사결정 구조에 크게 영향을 받는다는 사실을 이해하기 좋은 자료다.

---

Introducing Infinity: a runtime for extreme agent concurrency

• 저자: Shadaj Laddad
• 발행: AWS Open Source Blog / UC Berkeley Hydro 공동 프로젝트
• 게시일: 2026-10-23
• 원문: AWS — Introducing Infinity: a runtime for extreme agent concurrency

---

AI 에이전트가 수만 개 동시에 실행되는 환경에서는 어떤 문제가 발생할까?

일반적인 챗봇에서는 사용자가 질문을 보내면 AI가 답변을 생성하는 과정을 생각하기 쉽다.

하지만 실제 업무를 수행하는 에이전트는 대부분의 시간을 모델 추론에 사용하는 것이 아닐 수 있다.

예를 들어 코딩 에이전트는 빌드 명령을 실행한 뒤 결과가 나올 때까지 20분 동안 기다릴 수 있다.

업무 자동화 에이전트는 사용자가 결제를 승인할 때까지 몇 시간을 기다릴 수 있다.

모니터링 에이전트는 특정 이벤트가 발생할 때까지 며칠 동안 대기할 수도 있다.

이런 상황에서 에이전트 하나마다 별도의 실행 프로세스와 메모리를 계속 유지한다면 상당한 자원이 낭비될 수 있다.

AWS와 UC Berkeley의 Hydro 프로젝트가 공개한 Infinity는 이런 문제를 해결하기 위한 새로운 실행 환경이다.

기다리는 에이전트는 실제로 실행할 필요가 없다

일반적인 에이전트 실행 환경에서는 다음과 같은 순서가 반복된다.

모델이 어떤 도구를 실행할지 결정한다.

프로그램이 실제 도구를 실행한다.

도구의 결과가 반환될 때까지 기다린다.

결과가 도착하면 다시 모델을 호출한다.

문제는 외부 도구가 느리게 실행될 수 있다는 점이다.

예를 들어 테스트 서버의 빌드가 30분 걸리면 에이전트는 그동안 실질적으로 수행할 계산이 없다.

하지만 기존 실행 구조에서는 해당 에이전트의 프로그램과 실행 상태가 계속 메모리에 남아 있을 수 있다.

Infinity는 이를 Suspension(실행 일시 중단)으로 해결한다.

에이전트가 도구를 호출하면 현재 대화와 작업 상태를 저장한다.

이후 에이전트의 실행을 종료하고 계산 자원을 반환한다.

도구의 결과가 도착하면 저장된 상태를 불러와 다음 작업을 시작한다.

이 과정에서 사용되는 개념이 Stackless Coroutine(스택을 계속 유지하지 않는 코루틴)이다.

코루틴은 프로그램을 특정 지점에서 일시 중단했다가 나중에 다시 실행할 수 있도록 하는 구조다.

Infinity는 외부 도구 호출을 일시 중단 지점으로 사용한다.

따라서 수많은 에이전트가 도구의 결과를 기다리고 있어도 각 에이전트에 별도의 실행 스택을 유지할 필요가 없다.

에이전트 하나를 짧은 실행 단위로 나눈다

Infinity는 에이전트의 작업을 Slice(슬라이스)라는 짧은 실행 단위로 처리한다.

예를 들어 사용자가 빌드 상태를 확인하라고 요청하면 모델이 빌드 조회 도구를 선택한다.

Infinity는 해당 도구 호출을 기록하고 실행을 일시 중단한다.

빌드 상태가 반환되면 새로운 슬라이스가 시작된다.

모델은 반환된 결과를 읽고 답변을 생성한다.

이처럼 각 슬라이스는 필요한 작업만 처리하고 종료된다.

여러 에이전트가 동시에 존재하더라도 실제 CPU와 메모리는 현재 실행할 작업이 있는 에이전트에 집중할 수 있다.

Infinity는 에이전트마다 별도의 입력 큐를 유지한다.

Queue(큐)는 처리해야 할 작업이나 메시지를 순서대로 보관하는 자료구조다.

같은 대화에 속한 메시지는 순서대로 처리한다.

반면 서로 다른 대화의 작업은 병렬로 처리할 수 있다.

이런 구조는 하나의 에이전트가 동일한 데이터를 동시에 수정해 충돌하는 문제를 줄이는 데 도움이 된다.

8GB 메모리에서 7만5천 개의 에이전트 상태 유지

연구팀은 Infinity의 메모리 효율을 확인하기 위해 대규모 벤치마크를 수행했다.

실험에서는 8만 개의 에이전트를 생성했다.

각 에이전트는 여러 번의 도구 호출과 모델 응답 과정을 거쳤다.

전체적으로 약 320만 번의 모델 응답 과정을 시뮬레이션했다.

그 결과 대기 중인 에이전트 하나에 필요한 메모리는 약 100KB였다.

이 비율을 기준으로 계산하면 8GB 메모리에 약 7만5천 개의 대기 중인 에이전트 상태를 유지할 수 있다.

AWS는 이를 Raspberry Pi 5의 메모리 용량에 비유했다.

하지만 여기에는 반드시 구분해야 할 점이 있다.

7만5천 개의 에이전트가 Raspberry Pi에서 동시에 대형 언어모델을 추론했다는 의미는 아니다.

실험에는 실제 모델 대신 동작을 모의한 모델이 사용됐다.

실제 벤치마크는 AMD EPYC 프로세서를 사용하는 서버에서 수행됐다.

측정한 것은 주로 에이전트 실행 환경의 메모리 효율이다.

따라서 실제 AI 모델 추론에 필요한 GPU와 네트워크 비용은 별도로 고려해야 한다.

서버리스 환경과 자연스럽게 연결

Infinity의 구조는 Serverless(서버리스) 실행 환경과도 잘 맞는다.

서버리스는 개발자가 항상 실행되는 서버를 직접 운영하지 않고 특정 요청이나 이벤트가 발생했을 때 필요한 코드를 실행하는 방식이다.

예를 들어 AWS Lambda는 새로운 이벤트가 도착하면 함수를 실행하고 작업이 끝나면 종료할 수 있다.

Infinity는 에이전트의 상태를 외부 저장소에 보관하므로 하나의 프로그램이 계속 실행 중일 필요가 없다.

도구 결과가 메시지 큐에 도착하면 Lambda가 해당 메시지를 처리하고 에이전트의 다음 작업을 수행할 수 있다.

AWS는 이를 위해 SQS FIFO와 Lambda, Aurora DSQL, DynamoDB 등을 활용하는 구조를 제시했다.

SQS FIFO는 메시지가 전달되는 순서를 관리할 수 있는 큐 서비스다.

Aurora DSQL은 분산 데이터베이스다.

DynamoDB는 키 기반의 데이터를 빠르게 저장하고 조회할 수 있는 데이터베이스 서비스다.

이 구조에서 중요한 문제는 같은 메시지가 두 번 전달될 가능성이다.

분산 시스템에서는 장애 복구 과정에서 메시지가 중복 처리될 수 있다.

따라서 에이전트가 결제나 파일 변경 같은 작업을 수행한다면 동일한 요청이 반복 실행되지 않도록 만들어야 한다.

이를 Idempotency(멱등성)라고 한다.

같은 작업이 여러 번 요청되더라도 최종 결과가 한 번 실행했을 때와 같도록 만드는 성질이다.

다른 에이전트에게 작업을 전달하는 방법

Infinity는 하나의 에이전트가 다른 에이전트를 생성하고 작업을 맡기는 방식도 지원한다.

예를 들어 조사 에이전트가 여러 주제를 별도의 하위 에이전트에게 전달할 수 있다.

하위 에이전트가 작업을 완료하면 상위 에이전트의 입력 큐에 결과를 전달한다.

Infinity는 이런 비동기 이벤트를 모델이 기존 도구 호출 결과와 비슷한 형태로 이해하도록 Synthetic Tool Call(합성 도구 호출)을 사용한다.

이를 이용하면 새로운 메시지가 도착했을 때 모델이 어떤 작업의 결과인지 구분할 수 있다.

이는 단순히 새로운 사용자 메시지처럼 전달하는 방식과 다르다.

외부 도구에서 반환된 결과와 실제 사용자의 지시를 구분할 수 있기 때문이다.

아직 연구 단계의 오픈소스

Infinity는 Apache 2.0 라이선스로 공개됐다.

하지만 AWS는 이를 정식 상용 서비스가 아니라 초기 연구용 오픈소스 프로젝트라고 설명한다.

따라서 실제 기업 환경에서 대규모 장애 복구와 보안, 운영 안정성이 모두 검증됐다고 볼 수는 없다.

그럼에도 이번 연구가 제시하는 구조는 중요하다.

AI 에이전트의 수가 증가하면 모델이 실제로 계산하는 시간뿐 아니라 도구 결과와 사용자 승인, 외부 이벤트를 기다리는 시간을 얼마나 효율적으로 관리하는가도 인프라의 중요한 문제가 될 수 있다.

이번 글은 장시간 실행되는 AI 에이전트를 운영할 때 기존의 서버 중심 설계와 다른 접근이 필요한 이유를 이해하기 좋은 자료다.

---

Turning Database Grading into RL Rewards: Post-Training Agents with ThinkingBox

• 저자: Tuhin Kundu 외 Microsoft·Hugging Face 공동 연구진
• 발행: Microsoft / Hugging Face
• 게시일: 2026-10-22
• 원문: Microsoft·Hugging Face — Turning Database Grading into RL Rewards

---

AI 에이전트가 사용자의 요청을 성공적으로 처리했는지 어떻게 평가해야 할까?

예를 들어 사용자가 호텔 예약을 변경해 달라고 요청했다고 가정해 보자.

에이전트는 예약 변경을 완료했다고 답변할 수 있다.

하지만 실제 데이터베이스를 확인해 보면 예약 정보가 잘못 수정됐거나 필요한 승인 절차가 생략됐을 수도 있다.

이런 상황에서는 모델이 작성한 최종 답변만 평가해서는 충분하지 않다.

실제 시스템에 어떤 변경사항이 남았는지 확인해야 한다.

Microsoft와 Hugging Face가 개발한 ThinkingBox는 이런 문제를 평가하기 위한 환경이다.

이번 글은 기존에 개발한 평가 시스템을 이용해 에이전트 자체를 추가 학습시키는 방법을 설명한다.

에이전트가 성공했다고 말해도 실제 데이터는 다를 수 있다

ThinkingBox에는 507개의 실제 업무 형태를 재현한 평가 과제가 포함돼 있다.

대상 분야에는 소매업과 보험, 여행, 금융 및 기업 업무가 포함된다.

각 과제에서는 실제 데이터베이스와 여러 도구가 제공된다.

에이전트는 사용자의 요청을 받고 도구를 실행해 업무를 처리한다.

예를 들어 고객의 반품을 처리하거나 보험 정보를 수정하고, 호텔 예약을 변경하는 작업을 수행할 수 있다.

과제가 끝나면 평가 시스템이 데이터베이스의 최종 상태를 검사한다.

이를 Final State Evaluation(최종 상태 평가)이라고 한다.

모델이 어떤 설명을 작성했는지보다 실제 시스템의 상태가 요구사항을 충족하는지 확인하는 방식이다.

연구팀은 이전 평가에서 에이전트가 고객지원 문의를 해결했다고 표시했지만 실제로 관련 배송 문제는 해결되지 않은 사례를 확인했다.

모델이 여러 번의 도구 호출을 올바르게 수행한 것처럼 보여도 최종 데이터베이스의 특정 값이 잘못돼 있었다.

ThinkingBox는 이런 오류를 발견하도록 설계됐다.

평가 결과를 강화학습의 보상으로 사용

이번 연구의 핵심은 같은 평가 방식을 강화학습(Reinforcement Learning)에 활용한다는 것이다.

강화학습은 모델이 수행한 행동의 결과에 따라 보상을 제공하고 더 좋은 행동을 선택하도록 학습시키는 방법이다.

예를 들어 호텔 예약 변경 작업이 정상적으로 완료됐다면 보상 1을 제공할 수 있다.

반대로 필요한 승인 없이 예약을 수정했다면 보상 0을 제공할 수 있다.

이러한 보상은 모델의 설명을 다른 언어모델로 평가하는 방식과 다르다.

실제 데이터베이스의 값이 정해진 조건과 일치하는지 프로그램으로 직접 확인하기 때문이다.

명확한 업무 규칙이 존재하는 작업에서는 이런 평가 방식이 유리할 수 있다.

예를 들어 결제 금액이나 예약 날짜, 고객의 승인 상태는 실제 데이터베이스에서 확인할 수 있다.

하지만 업무의 모든 성공 조건을 숫자나 단순한 규칙으로 표현할 수 있는 것은 아니다.

고객이 답변을 이해하기 쉬웠는지, 복잡한 예외 상황에서 적절한 판단을 했는지는 추가 평가가 필요할 수 있다.

너무 쉽거나 어려운 과제는 학습 효과가 낮다

연구팀은 학습에 사용할 과제를 선택하는 방법도 조사했다.

기본 모델이 이미 거의 모든 경우에 성공하는 과제는 추가 학습으로 얻을 수 있는 정보가 적을 수 있다.

반대로 모델이 어떤 방식으로도 성공하지 못하는 과제에서는 어떤 행동이 더 좋은지 비교하기 어렵다.

따라서 현재 모델이 어느 정도 성공할 수 있지만 실패하는 경우도 존재하는 과제가 학습에 유용할 수 있다.

연구팀은 이를 Policy-Relative Difficulty(현재 모델의 능력을 기준으로 측정한 난이도)라고 설명한다.

같은 과제라도 모델의 능력에 따라 난이도가 달라질 수 있다는 의미다.

예를 들어 작은 모델에는 어려운 작업이 강력한 모델에는 쉬운 작업일 수 있다.

연구팀은 기본 모델로 일부 과제를 미리 실행해 성공 가능성을 추정했다.

이후 학습에 적합한 과제만 선택했다.

또한 평가에 사용하는 507개 과제와 별도로 학습용 과제를 준비해 평가 데이터가 학습 과정에 직접 포함되는 일을 방지하려 했다.

평균 성공률과 반복 성공률이 모두 개선

연구팀은 Qwen3.8-27B 모델을 사용했다.

이후 GRPO(Group Relative Policy Optimization)라는 강화학습 방법으로 50단계의 추가 학습을 수행했다.

GRPO는 여러 실행 결과를 비교해 상대적으로 더 좋은 행동의 가능성을 높이도록 모델을 학습시키는 방법이다.

평가에서는 507개 과제를 각각 20번씩 실행했다.

총 10,140번의 작업 실행을 비교한 것이다.

연구팀이 공개한 결과는 다음과 같다.

평균 성공률은 9.08%포인트 개선됐다.

특히 같은 과제를 20번 실행했을 때 모두 성공한 과제는 38개에서 107개로 증가했다.

이는 단순히 한 번 성공할 수 있는 능력뿐 아니라 반복해서 안정적으로 성공하는 능력이 개선됐다는 의미다.

하지만 모든 지표가 좋아진 것은 아니다.

20번 가운데 한 번 이상 성공한 과제는 453개에서 446개로 감소했다.

즉 모델이 반복해서 성공하는 능력은 높아졌지만, 적어도 한 번 해결할 수 있는 과제의 전체 범위는 소폭 줄었다.

이런 차이는 모델의 성능을 하나의 숫자로 평가해서는 충분하지 않다는 점을 보여준다.

호텔 예약 변경 사례

연구팀은 호텔 예약 변경 과제를 구체적인 사례로 소개했다.

사용자는 객실 등급을 낮추는 변경을 요청했다.

하지만 회사의 정책에 따르면 해당 변경에는 관리자의 승인이 필요했다.

추가 학습 전 모델은 20번의 실행 가운데 15번에서 승인 없이 예약과 결제 정보를 변경했다.

사용자의 요청을 처리하려는 과정에서 중요한 업무 규칙을 위반한 것이다.

반면 추가 학습 이후에는 20번의 실행 모두에서 승인 없는 예약 변경을 수행하지 않았다.

또한 19번의 실행에서는 필요한 데이터베이스 기록까지 모두 올바르게 유지했다.

이 사례는 AI 에이전트가 사용자의 요청을 빠르게 실행하는 능력뿐 아니라 조직의 업무 규칙을 준수하면서 안전하게 행동하는 능력도 학습할 수 있음을 보여준다.

평가 시스템이 곧 학습 시스템이 될 수 있다

이번 연구에서 가장 중요한 부분은 평가와 학습에 같은 종류의 검증 절차를 사용할 수 있다는 점이다.

일반적인 AI 개발에서는 학습 데이터를 준비하는 과정과 모델을 평가하는 과정이 분리돼 있다.

하지만 실제 업무의 최종 상태를 프로그램으로 검증할 수 있다면 그 결과를 바로 학습 보상으로 사용할 수 있다.

예를 들어 코딩 에이전트가 테스트를 통과했는지, 업무 에이전트가 올바른 데이터베이스 값을 남겼는지에 따라 보상을 제공할 수 있다.

다만 이번 연구 결과는 Microsoft와 Hugging Face 연구팀의 자체 평가다.

507개 과제에서 얻은 개선 폭이 모든 실제 기업 업무에서 동일하게 나타난다는 의미는 아니다.

또한 평가 프로그램이 확인하지 못하는 문제가 남을 수 있다.

예를 들어 최종 데이터베이스의 값은 올바르더라도 중간에 허용되지 않은 정보를 조회했을 가능성이 있다.

따라서 최종 상태 평가와 실행 과정의 보안 검사는 서로 보완적으로 사용해야 한다.

이번 글은 AI 에이전트를 개선하기 위해 단순히 정답 문장을 더 많이 학습시키는 것보다 실제 업무가 성공했는지 검증할 수 있는 환경을 만드는 일이 중요하다는 점을 보여준다.

---

Mundo: From seeing a place to simulating what happens there

• 저자: Yihang Luo, Zunnan Xu, Shangchen Zhou, Yushi Lan 외 공동 연구진
• 발행: Hugging Face Community / Mundo 연구팀
• 게시일: 2026-10-23
• 원문: Hugging Face — Mundo: From seeing a place to simulating what happens there

---

몇 장의 사진만으로 실제 방을 3D 공간으로 복원하고 그 안에서 물체가 어떻게 움직이는지 시뮬레이션할 수 있을까?

이 글은 그런 작업을 수행하는 새로운 시스템 Mundo를 소개한다.

기존의 이미지·영상 생성 AI는 장면을 그럴듯하게 표현하는 데 집중하는 경우가 많았다.

하지만 생성된 장면이 실제로 물리적인 규칙을 따르는지는 별개의 문제다.

예를 들어 AI가 영상 속에서 사과가 날아가는 장면을 만들 수 있다고 해도 해당 사과의 위치와 속도, 충돌이 일관된 물리 규칙에 따라 계산됐다는 보장은 없다.

Mundo는 이를 해결하기 위해 3D 공간 복원과 물리 시뮬레이션, 생성형 영상 모델을 분리해 연결한다.

사진에서 실제 공간의 3D 구조 복원

Mundo는 하나의 공간을 서로 다른 각도에서 촬영한 사진이나 영상을 입력받는다.

연구팀에 따르면 1~12장의 이미지로도 공간을 복원할 수 있다.

먼저 이미지에 담긴 카메라의 위치와 방향을 추정한다.

이후 여러 이미지에 공통으로 나타나는 물체를 이용해 공간의 구조를 복원한다.

예를 들어 호텔 객실 사진이 여러 장 있다면 침대와 책상, 의자와 벽의 위치를 추정할 수 있다.

하지만 실제 공간의 모든 물체를 정밀한 3D 메시로 복원할 필요는 없을 수 있다.

Mundo는 많은 물체를 Bounding Box(경계 상자)로 표현한다.

경계 상자는 물체의 대략적인 위치와 크기를 나타내는 단순한 3D 상자다.

예를 들어 의자를 실제 곡면과 다리 구조까지 완벽하게 복원하는 대신 해당 의자가 차지하는 공간을 상자로 표현할 수 있다.

이렇게 하면 계산 비용을 줄이면서도 물체의 위치와 충돌 관계를 관리할 수 있다.

물론 이런 단순화에는 한계가 있다.

예를 들어 로봇이 작은 물체를 집어 드는 상황에서는 상자 형태만으로 실제 접촉을 충분히 표현하기 어려울 수 있다.

Mundo는 이런 물체에 대해서만 더 정밀한 3D 구조를 생성하거나 외부 자산을 가져올 수 있도록 했다.

AI 에이전트가 3D 공간을 반복해서 수정

처음 생성한 3D 공간이 실제 사진과 정확히 일치하는 것은 아니다.

예를 들어 책상의 위치가 잘못됐거나 두 물체를 하나로 인식할 수 있다.

Mundo는 이를 수정하기 위해 VLM(Vision-Language Model, 이미지와 텍스트를 함께 이해하는 모델)을 사용한다.

에이전트는 현재 3D 공간을 렌더링한 결과와 원본 사진을 비교한다.

Rendering(렌더링)은 3D 공간의 구조를 특정한 카메라 시점에서 이미지로 변환하는 과정이다.

두 이미지 사이에 차이가 있다면 에이전트가 어떤 물체를 수정해야 할지 결정한다.

이후 프로그램 코드와 수치 최적화를 이용해 물체의 위치와 크기를 조정한다.

여기서 Numerical Optimization(수치 최적화)은 정해진 수학적 목표에 맞도록 숫자 값을 반복해서 조정하는 방법이다.

예를 들어 물체의 실제 경계와 모델이 생성한 경계 사이의 차이를 최소화하도록 위치를 변경할 수 있다.

수정 이후에는 별도의 검토 에이전트가 결과를 다시 확인한다.

검토 에이전트가 승인하면 공간 복원을 완료한다.

그렇지 않다면 발견한 문제를 다시 수정한다.

이는 하나의 모델이 모든 결과를 생성하는 방식보다 생성 과정과 검토 과정을 분리한 구조다.

공간 자체를 코드로 관리

Mundo에서 복원한 공간은 단순한 3D 이미지가 아니다.

각 물체의 위치와 방향, 질량과 마찰력 같은 정보가 포함된 실행 가능한 장면 프로그램이다.

연구팀은 이를 Code World Model(코드 기반 월드 모델)이라고 설명한다.

예를 들어 공간에 존재하는 서랍과 사과의 위치를 정의할 수 있다.

이후 특정 시점에 서랍을 열거나 사과를 이동시키는 행동을 프로그램으로 지정할 수 있다.

Mundo는 이런 행동에 따라 공간의 상태를 변경한다.

또한 MuJoCo라는 물리 시뮬레이션 엔진을 사용할 수 있다.

MuJoCo는 로봇과 물체의 움직임, 중력과 충돌을 계산하는 데 널리 사용되는 기술이다.

예를 들어 로봇이 물체를 밀면 해당 물체의 질량과 마찰력, 충돌 조건을 고려해 움직임을 계산할 수 있다.

물론 이런 계산의 정확도는 입력한 물리적 속성이 실제 물체와 얼마나 비슷한지에 영향을 받는다.

사진만으로 물체의 질량이나 내부 구조를 완벽하게 알 수는 없기 때문이다.

따라서 Mundo가 생성하는 시뮬레이션이 언제나 실제 공간의 물리적 행동을 정확하게 재현한다고 볼 수는 없다.

물리 계산을 실제 영상처럼 렌더링

Mundo는 물리 엔진이 계산한 결과를 바로 최종 영상으로 사용하지 않는다.

먼저 물체의 종류와 위치를 단순한 색상으로 표현한 Proxy Video(대리 영상)를 생성한다.

이 영상에는 물체가 언제 움직이고 어떤 위치에서 충돌하는지 등의 정보가 포함된다.

이후 생성형 영상 모델이 원본 사진의 시각적 특징과 대리 영상을 참고해 최종 영상을 만든다.

예를 들어 물리 시뮬레이션에서 서랍이 열리는 행동을 계산했다면 영상 모델은 해당 움직임을 실제 객실의 모습에 맞춰 렌더링한다.

이 방식은 영상 모델에게 단순히 서랍이 열리는 영상을 만들어 달라고 요청하는 것과 다르다.

물체의 움직임과 위치는 3D 시뮬레이션이 결정하고, 영상 모델은 해당 움직임을 시각적으로 표현하는 역할을 맡는다.

연구팀은 약 4만 쌍의 실제·합성 영상과 대리 영상 데이터를 이용해 영상 모델을 학습시켰다.

입력에는 실내 장면과 차량 주행, 물체 조작과 게임 영상 등이 포함됐다.

실제 로봇 연구에 활용할 가능성

Mundo는 로봇이 특정 공간에서 이동하거나 물체를 조작하는 작업도 시뮬레이션할 수 있다.

예를 들어 호텔의 로비에서 특정 객실까지 이동하도록 로봇의 경로를 계획할 수 있다.

또는 로봇이 실제 방에 들어가기 전에 특정 물체를 어디에서 찾고 어떻게 접근해야 하는지 시험할 수 있다.

이를 Real-to-Sim(현실 환경을 시뮬레이션으로 변환하는 방식)이라고 한다.

일반적인 로봇 개발에서는 사람이 직접 가상환경을 구성해야 하는 경우가 많다.

Mundo는 실제 공간의 사진에서 시뮬레이션 환경을 만드는 과정을 자동화하려는 접근이다.

하지만 현재 성능에는 상당한 제한이 있다.

연구팀에 따르면 공간 하나를 복원하는 데 보통 10~20분이 필요하다.

영상 생성 속도는 A800 GPU 8개를 사용해 초당 약 1.5프레임이었다.

즉 현재 버전은 일반적인 실시간 게임 엔진처럼 빠르게 동작하는 시스템이 아니다.

또한 작은 물체를 조작하는 장면에서는 물체가 공중에 떠 있는 것처럼 보이거나 영상 생성 오류가 발생할 수 있다.

장시간 시뮬레이션에서는 이전 장면의 세부 정보가 일관되게 유지되지 않는 문제도 남아 있다.

이번 글은 생성형 AI가 만드는 시각적으로 자연스러운 영상과 실제로 물리적 행동을 계산할 수 있는 시뮬레이션 환경 사이의 차이를 이해하기 좋은 자료다.

특히 3D 모델링과 로봇, 게임 개발에서 AI가 어떤 역할을 수행할 수 있는지 구체적인 사례를 통해 설명한다.

---

How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations

• 저자: Subbu Dandamudi, Leo de Melo, Mahnoor Hussain, Ram Pamidimukkala, Sai Pavan Kasani
• 발행: Bayer Crop Science / AWS
• 게시일: 2026-10-23
• 원문: AWS — How Bayer Crop Science built an agentic decision engine

---

기업이 AI 에이전트를 실제 업무에 도입할 때 가장 어려운 문제는 무엇일까?

모델을 API로 호출하고 자연어 질문에 답하도록 만드는 것만으로는 충분하지 않다.

실제 업무에 필요한 데이터를 연결하고, 사용자별 접근권한을 관리하며, 장애가 발생했을 때 원인을 확인할 수 있어야 한다.

이번 글은 글로벌 생명과학 기업 Bayer Crop Science가 이런 문제를 해결하기 위해 구축한 Agentic Decision Engine(ADE)을 소개한다.

특히 22개의 전문 AI 에이전트를 실제 운영 환경에 배포하는 과정에서 어떤 설계 선택을 했는지 구체적으로 설명한다는 점에서 읽어볼 가치가 있다.

기존 데이터 분석 시스템을 대체하지 않는다

Bayer는 작물 육종과 생명과학 연구에 다양한 데이터 분석 도구를 사용한다.

예를 들어 새로운 작물의 특성을 분석하거나 여러 연구 모델을 실행할 수 있다.

Bayer는 이런 작업을 관리하기 위해 CDE(Connected Decision Engine)라는 내부 데이터·분석 플랫폼을 운영한다.

CDE는 여러 데이터와 분석 모델을 연결하고 실행 기록을 관리하는 시스템이다.

하지만 실제 연구자가 이 시스템을 사용하려면 여러 종류의 정보를 직접 확인해야 하는 경우가 있었다.

예를 들어 특정 실험의 분석 작업이 실패했다면 관련 로그와 데이터베이스, API와 내부 문서를 조사해야 했다.

개별 시스템의 사용 방법을 모두 알지 못하는 연구자에게는 부담이 컸다.

Bayer는 이를 해결하기 위해 기존 CDE 위에 자연어 인터페이스를 추가했다.

중요한 점은 기존 분석 시스템을 AI가 완전히 대체하도록 만들지 않았다는 것이다.

CDE는 실제 데이터를 처리하고 분석 작업을 실행하는 역할을 계속 담당한다.

ADE는 사용자의 질문을 이해하고 필요한 시스템에서 정보를 가져와 설명하는 역할을 수행한다.

즉 기존 시스템의 업무 기능과 AI 에이전트의 자연어 인터페이스를 분리했다.

22개 전문 에이전트와 중앙 조정기

ADE에는 22개의 전문 에이전트가 사용된다.

모든 업무를 하나의 거대한 에이전트가 처리하는 구조가 아니다.

대신 사용자의 질문을 먼저 분석하는 Supervisor Agent(상위 조정 에이전트)가 존재한다.

Supervisor는 질문의 목적을 확인한 뒤 적절한 전문 에이전트에게 작업을 전달한다.

예를 들어 분석 모델이 어떤 기능을 수행하는지 질문했다면 전문 지식을 제공하는 에이전트가 응답할 수 있다.

특정 분석 작업이 왜 실패했는지 질문했다면 장애 분석을 담당하는 에이전트가 실행된다.

데이터를 시각적으로 표현해야 한다면 차트 생성 에이전트가 작업을 처리한다.

이런 구조를 Multi-Agent System(멀티에이전트 시스템)이라고 한다.

여러 AI 에이전트가 서로 다른 역할을 담당하면서 하나의 사용자의 목표를 해결하는 방식이다.

Bayer는 이 구조에서 LangGraph를 사용했다.

LangGraph는 여러 에이전트와 도구의 실행 순서, 작업 상태를 그래프 형태로 관리하는 프레임워크다.

실제 에이전트는 Amazon Bedrock AgentCore에서 실행한다.

AgentCore는 에이전트의 실행 환경과 외부 도구 연결, 세션 관리 등을 제공하는 AWS 서비스다.

작업 상태를 외부 데이터베이스에 저장

Bayer가 경험한 중요한 문제 가운데 하나는 장시간 실행되는 작업의 상태 관리였다.

예를 들어 에이전트가 여러 단계의 분석을 수행하는 도중 서버가 다시 시작될 수 있다.

이때 이전 작업 상태가 현재 실행 중인 서버의 메모리에만 존재한다면 작업을 처음부터 다시 시작해야 할 수 있다.

Bayer는 이를 해결하기 위해 에이전트의 주요 작업 상태를 DynamoDB에 저장했다.

DynamoDB는 AWS의 관리형 NoSQL 데이터베이스다.

에이전트가 수행한 작업의 체크포인트를 저장해 두면 서버가 재시작되거나 실행 환경이 변경돼도 이전 상태를 불러올 수 있다.

Checkpoint(체크포인트)는 프로그램이 특정 시점까지 수행한 작업 상태를 기록한 것이다.

이런 구조는 장시간 실행되는 에이전트에서 중요하다.

특히 여러 도구를 호출하는 업무에서는 중간 상태를 잃으면 이미 수행한 작업을 다시 실행해야 할 수 있기 때문이다.

Bayer는 실제 실행 세션과 장기간 보관해야 하는 상태를 구분했다.

현재 실행 중인 에이전트의 세션은 AgentCore가 관리한다.

반면 장애 이후에도 복원해야 하는 주요 상태는 별도 저장소에 보관한다.

사용자 신원과 도구 접근권한 분리

이번 시스템에서 중요한 설계 선택은 사용자 인증과 에이전트의 도구 사용 권한을 구분한 것이다.

Bayer는 직원의 신원을 관리하는 데 Microsoft Entra ID를 사용한다.

Entra ID는 기업에서 사용자의 계정과 인증을 관리하는 서비스다.

하지만 사용자가 정상적으로 로그인했다는 사실만으로 모든 내부 API에 접근할 수 있는 것은 아니다.

따라서 ADE는 에이전트가 실제 도구를 호출할 때 AWS IAM과 AgentCore Gateway의 권한 제어를 적용한다.

IAM(Identity and Access Management)은 사용자나 프로그램이 특정한 자원에 접근할 수 있는지 관리하는 기술이다.

예를 들어 장애 분석 에이전트는 실행 로그를 읽을 수 있지만 실제 분석 작업을 수정할 권한은 필요하지 않을 수 있다.

반대로 특정 데이터 분석 에이전트는 내부 검색 인덱스를 조회할 수 있어도 다른 부서의 업무 API에 접근할 필요는 없다.

Bayer는 이런 차이를 반영해 각 전문 에이전트에게 필요한 최소한의 읽기 권한만 제공하는 방식을 사용했다.

이는 Least Privilege(최소 권한 원칙)와 연결된다.

프로그램이 자신의 작업을 수행하는 데 필요한 권한만 가져야 한다는 보안 원칙이다.

오류 분석 시간을 1시간 이상에서 10분 미만으로

Bayer는 실제 운영 결과도 공개했다.

기존에는 연구자가 분석 작업의 오류 원인을 확인하기 위해 여러 시스템의 로그를 직접 살펴봐야 했다.

필요한 경우 엔지니어의 도움을 기다려야 했다.

이 과정에는 1시간 이상이 걸릴 수 있었다.

ADE의 장애 분석 에이전트를 도입한 뒤에는 비슷한 질문에 대한 원인 분석을 10분 미만으로 수행할 수 있었다고 설명한다.

또한 초기 운영에서 전체 사용자 질문의 약 80%를 엔지니어의 개입 없이 해결했다고 밝혔다.

여기서 주의할 점은 이 수치가 Bayer의 내부 업무 환경에서 측정된 결과라는 사실이다.

모든 기업에서 AI 에이전트를 도입하면 업무의 80%가 자동화된다는 의미는 아니다.

또한 질문에 답하는 과정과 실제 분석 오류를 수정하는 과정은 다르다.

ADE가 오류의 원인을 설명하더라도 실제 시스템의 수정이나 재실행에는 다른 절차가 필요할 수 있다.

실제 서비스 배포에서 발견한 문제

Bayer는 AI 에이전트의 프롬프트와 도구 설계뿐 아니라 실제 운영 준비도 중요했다고 설명한다.

예를 들어 초기에는 여러 에이전트 사이에서 오류가 발생했을 때 어느 단계에서 실패했는지 확인하기 어려웠다.

또한 컨테이너 이미지의 버전을 명확하게 구분하지 않거나, 보안 검사 절차가 충분하지 않은 문제도 발견됐다.

Container(컨테이너)는 프로그램과 실행에 필요한 구성요소를 묶어 격리된 환경에서 실행하도록 하는 기술이다.

운영 환경에서는 어떤 버전의 컨테이너가 배포됐는지 정확하게 알아야 장애 발생 시 이전 버전으로 복구할 수 있다.

Bayer는 실제 배포 전에 이미지 버전 관리와 취약점 검사, 로그 및 경고 체계를 강화했다.

또한 모델을 변경할 때 기존 도구 호출과 구조화된 출력 방식이 정상적으로 작동하는지 확인했다.

이는 중요한 문제다.

언어모델이 자연어 질문에는 올바르게 답하더라도, 실제 도구를 호출하는 구조가 달라지면 전체 에이전트가 작동하지 않을 수 있기 때문이다.

프롬프트보다 실행 환경이 중요했다

Bayer와 AWS는 이번 프로젝트의 핵심 성과가 단순히 좋은 프롬프트를 작성한 데서 나오지 않았다고 설명한다.

실제 운영에는 작업 상태의 영속적인 저장과 인증, 도구 권한, 실행 기록과 장애 대응이 필요했다.

또한 여러 전문 에이전트의 역할을 구분하고 적절한 작업에만 접근하도록 제한해야 했다.

Bayer는 현재 100명 이상의 내부 사용자를 대상으로 ADE를 운영하고 있다.

다만 이 사용자 수는 초기 도입 규모를 나타내며, 조직 전체에 동일한 기능이 배포됐다는 의미는 아니다.

이번 글은 AI 에이전트를 실제 업무에 도입하는 작업이 언어모델에 도구를 연결하는 것으로 끝나지 않는다는 점을 구체적으로 보여준다.

특히 기존 기업 시스템을 유지하면서 그 위에 AI 에이전트를 추가할 때 권한 관리와 상태 저장, 로그 추적과 안정적인 배포 체계를 어떻게 설계할 수 있는지 이해하기 좋은 사례다.