AI 데일리 브리핑 — 2026-10-17
Soshy··조회수 —
기준 시점: 2026-10-17 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-16 06:00 ~ 2026-10-17 06:00 KST
추천 글 범위: 2026-10-10 06:00 ~ 2026-10-17 06:00 KST
1️⃣ 주요 모델·연구
Reflection AI, 5,010억 파라미터 오픈웨이트 모델 ‘Beam’ 정식 공개…Apache 2.0 라이선스로 가중치 배포 시작
- 발표일: 2026-10-16 — 정확한 게시 시각 미확인
- 적용 범위: 오픈웨이트 LLM, 코딩 에이전트, 장기 추론, 모델 파인튜닝, 기업용 AI, 자체 호스팅
- 원문: Reflection AI — Beam is now available
- 관련 원문: Hugging Face — Beam 1.0 모델 컬렉션
- 관련 원문: AWS — Introducing Reflection Beam: an open-weight model for agentic coding on AWS
Reflection AI가 대규모 언어모델 Beam의 가중치를 공개하고 개발자가 직접 실행하거나 추가 학습할 수 있도록 했다.
Beam은 지난 10월 5일 처음 소개된 모델이다. 당시에는 모델의 주요 사양과 개발 방향이 공개됐지만, 일반 개발자가 가중치를 다운로드해 자체 환경에서 실행할 수 있는 상태는 아니었다.
10월 16일의 새로운 변화는 실제 모델 가중치와 실행 도구, 안전성 평가 자료가 공개됐다는 점이다.
Reflection AI는 이번 발표를 통해 Beam을 단순한 모델 API가 아니라 개발자가 자신의 환경에서 실행하고 수정할 수 있는 개방형 AI 시스템으로 제공하기 시작했다.
5,010억 파라미터 가운데 230억 개만 활성화
Beam은 전체 5,010억 개(501B)의 파라미터를 가진 대형 언어모델이다.
하지만 토큰 하나를 처리할 때 활성화되는 파라미터는 약 230억 개(23B)다.
여기에는 MoE(Mixture of Experts) 구조가 사용된다.
MoE는 하나의 거대한 신경망 전체를 매번 실행하는 대신 여러 전문 신경망 가운데 입력에 필요한 일부만 활성화하는 방식이다.
일반적인 Dense 모델에서는 모델을 실행할 때 대부분의 파라미터가 계산에 참여한다.
반면 MoE에서는 특정 입력을 처리하는 데 필요한 전문가 네트워크만 선택적으로 사용한다.
이렇게 하면 모델 전체에 많은 지식을 저장하면서도 매번 모든 파라미터를 계산하는 비용을 줄일 수 있다.
하지만 한 가지 중요한 구분이 있다.
활성 파라미터가 230억 개라고 해서 230억 파라미터 모델과 동일한 메모리에서 실행할 수 있는 것은 아니다.
모델을 실행하려면 활성화되지 않는 전문가 네트워크의 가중치도 저장해야 하기 때문이다.
따라서 Beam은 일반적인 개인용 컴퓨터보다 여러 GPU를 사용하는 서버 환경에 적합하다.
Beam은 최대 100만 토큰의 컨텍스트를 지원한다.
컨텍스트는 모델이 하나의 작업에서 참고할 수 있는 입력과 이전 대화, 도구 실행 기록의 범위를 의미한다.
긴 컨텍스트는 여러 파일로 구성된 코드베이스를 분석하거나 장시간 실행되는 에이전트의 작업 상태를 유지하는 데 유용하다.
다만 입력 가능한 토큰 수가 많다고 해서 그 안의 모든 정보를 정확하게 활용할 수 있다는 의미는 아니다.
긴 입력에서 관련 정보를 찾아내고 서로 떨어진 내용을 연결하는 능력은 별도로 평가해야 한다.
코딩 에이전트와 장시간 작업에 초점
Reflection AI는 Beam을 일반적인 질의응답보다 코딩, 추론과 장시간 실행되는 에이전트 작업에 초점을 맞춰 개발했다고 설명한다.
예를 들어 사용자가 기존 서비스의 오류를 수정하라고 요청했다면 코딩 에이전트는 단순히 수정 코드를 생성하는 것으로 작업을 완료할 수 없다.
먼저 관련 파일을 찾고 현재 동작을 이해해야 한다.
이후 코드를 변경하고 테스트를 실행한 뒤, 문제가 해결되지 않았다면 다른 방법을 시도해야 한다.
이런 작업에서는 모델이 여러 차례 도구를 호출하고 이전 결과를 참고하면서 판단을 이어가는 능력이 필요하다.
Reflection AI는 Beam을 개발하면서 이런 작업에 필요한 에이전트 실행 환경까지 함께 설계했다고 밝혔다.
실제로 회사는 강화학습 과정에서 약 13억 개의 샌드박스 실행을 사용했다고 설명한다.
여기서 샌드박스는 모델이 코드를 실행하거나 도구를 사용할 수 있도록 만든 격리된 실험 환경이다.
강화학습은 모델이 수행한 행동의 결과에 따라 보상을 제공하고, 더 좋은 행동을 선택하도록 학습시키는 방법이다.
모델이 작성한 코드가 실제로 테스트를 통과했는지 확인하거나, 여러 단계의 작업을 올바르게 완료했는지 평가하는 데 활용할 수 있다.
Reflection AI에 따르면 최종 강화학습 과정의 일부 구간에서는 Google Cloud와 AWS의 23개 클러스터에서 약 88만 개의 가상 CPU가 동시에 사용됐다.
이는 모델 자체의 추론 성능 수치가 아니라 학습과 평가를 수행하기 위해 사용한 실행 인프라의 규모다.
세 가지 가중치 형식 공개
Beam의 가중치는 세 가지 형식으로 제공된다.
BF16은 모델의 숫자를 16비트 부동소수점 형식으로 표현한다.
상대적으로 높은 수치 정밀도를 유지할 수 있지만 메모리 사용량이 크다.
FP8은 8비트 부동소수점 형식을 사용한다.
BF16보다 적은 메모리를 사용하면서 일부 최신 GPU의 최적화된 연산 기능을 활용할 수 있다.
NVFP4는 4비트 수준의 낮은 정밀도를 이용한다.
이처럼 모델 가중치의 숫자 표현 정밀도를 낮춰 메모리 사용량과 계산 비용을 줄이는 기술을 Quantization(양자화)이라고 한다.
양자화를 적용하면 같은 모델을 상대적으로 적은 메모리에서 실행할 수 있다.
하지만 정밀도를 낮추는 과정에서 일부 계산 결과가 달라질 수 있으므로 실제 작업의 정확도는 별도로 확인해야 한다.
Reflection AI는 이번 공개에 Speculative Decoding용 보조 모델도 포함했다.
Speculative Decoding은 상대적으로 가벼운 모델이 여러 출력 토큰을 미리 예측하고 큰 모델이 이를 검증하는 방식이다.
예측이 올바르다면 큰 모델이 토큰을 하나씩 생성하는 과정을 일부 줄일 수 있다.
이런 최적화는 사용자가 여러 번 도구를 호출하는 코딩 에이전트에서 응답 지연시간과 비용을 줄이는 데 도움이 될 수 있다.
Apache 2.0 라이선스와 실제 활용 범위
Beam의 가중치는 Apache 2.0 라이선스로 공개됐다.
Apache 2.0은 상업적 사용과 수정, 재배포를 폭넓게 허용하는 오픈소스 라이선스다.
따라서 기업은 Beam을 자체 서버에서 실행하거나 조직의 데이터와 업무에 맞게 추가 학습할 수 있다.
모델을 실행하는 방법도 여러 가지가 제공된다.
Reflection AI는 Hugging Face Transformers, vLLM, SGLang, NVIDIA Dynamo, Unsloth, Axolotl 등과의 연동을 소개했다.
또한 AWS, Google Cloud, Microsoft Azure와 여러 추론 서비스 제공업체를 통해 모델을 사용할 수 있다.
AWS는 같은 날 Amazon SageMaker JumpStart를 통한 Beam 배포 방법을 공개했다.
JumpStart를 사용하면 개발자가 모델 서버의 모든 구성요소를 직접 설치하지 않고 관리형 엔드포인트를 구성할 수 있다.
초기 제공 지역은 미국 동부의 버지니아와 오하이오다.
더 복잡한 GPU 배치와 확장 정책이 필요한 조직은 SageMaker HyperPod와 SGLang, vLLM을 조합해 자체 추론 환경을 구성할 수 있다.
다만 Beam의 가중치가 무료로 공개됐다는 사실과 실제 실행 비용이 무료라는 사실은 다르다.
대규모 모델을 실행하려면 상당한 GPU 메모리와 전력, 네트워크 자원이 필요하다.
또한 Apache 2.0 라이선스로 가중치를 사용할 수 있다는 것과 모델의 모든 학습 데이터와 내부 개발 과정이 공개됐다는 것도 구분해야 한다.
이번 발표는 오픈웨이트 AI의 경쟁이 모델의 가중치를 공개하는 수준에서 실제 서비스 배포와 추가 학습, 도구 사용 환경까지 제공하는 방향으로 확대되고 있다는 점을 보여준다.
Anthropic·하버드 연구진, Claude로 양자회로 설계 최적화…일부 연산에서 양자 게이트 수 최대 17분의 1로 감소
- 발표일: 2026-10-16 — 정확한 게시 시각 미확인
- 적용 범위: AI for Science, 양자컴퓨팅, 수학적 증명, 양자 알고리즘, 과학 연구 에이전트, 코드 검증
- 원문: Anthropic — Designing more efficient quantum circuits with Claude
Anthropic과 하버드대학교 연구진이 Claude를 이용해 기존보다 적은 계산 자원으로 실행할 수 있는 새로운 양자회로를 설계한 연구 결과를 공개했다.
이번 연구에는 Claude Mythos 5가 사용됐다.
연구진은 화학, 최적화, 양자 시뮬레이션, 정수론과 수치 계산에 사용되는 여덟 가지 기본 연산을 대상으로 실험했다.
결과적으로 Claude는 여러 연산에서 기존에 발표된 방법보다 적은 양자비트와 게이트를 사용하는 새로운 회로 설계를 찾아냈다.
이번 연구에서 중요한 것은 AI가 단순히 기존 회로의 코드를 정리하거나 계산 순서를 조금 바꾼 것이 아니라는 점이다.
연구진은 일부 결과에서 기존 알고리즘이 불가피하다고 여겼던 중간 정보 저장 방식을 수학적으로 다시 설계했다고 설명한다.
양자컴퓨터에서는 중간 계산을 마음대로 삭제할 수 없다
일반적인 컴퓨터는 비트를 사용한다.
비트는 0 또는 1의 값을 가진다.
반면 양자컴퓨터는 Qubit(큐비트, 양자비트)을 사용한다.
큐비트는 양자역학의 중첩 상태를 이용해 여러 상태를 함께 표현할 수 있다.
양자컴퓨터의 계산은 이러한 큐비트에 Quantum Gate(양자 게이트)라는 연산을 적용하는 방식으로 진행된다.
양자 게이트는 일반 컴퓨터의 논리 연산과 비슷한 역할을 하지만 중요한 차이가 있다.
양자회로의 기본 연산은 가역적(Reversible)이어야 한다.
가역적이라는 것은 어떤 계산 결과에서 이전 상태를 다시 복원할 수 있어야 한다는 의미다.
일반적인 프로그램에서는 더 이상 필요하지 않은 중간 계산 결과를 삭제하거나 덮어쓸 수 있다.
그러나 양자회로에서는 이런 정보를 마음대로 버리면 계산의 가역성이 깨질 수 있다.
그래서 중간 계산 결과를 정리할 때는 이전 계산을 반대 방향으로 실행하는 Uncomputation(역계산)이 필요할 수 있다.
이 과정은 추가적인 게이트와 큐비트를 요구한다.
결국 양자 알고리즘을 설계할 때는 두 가지 자원을 함께 고려해야 한다.
하나는 계산에 필요한 큐비트 수이고, 다른 하나는 실제로 실행해야 하는 게이트 수다.
중간 정보를 많이 저장하면 계산을 반복하지 않아도 되지만 큐비트가 많이 필요하다.
반대로 정보를 저장하지 않으려면 같은 계산을 반복해야 할 수 있어 게이트 수가 증가한다.
Claude가 발견한 새로운 가역 알고리즘
연구진은 먼저 타원곡선에서 두 점을 더하는 연산을 최적화하도록 Claude에 요청했다.
타원곡선 연산은 현대 암호학과 양자 알고리즘에서 중요한 수학적 연산이다.
여기에는 Modular Inversion(모듈러 역원 계산)이라는 작업이 포함된다.
일반적인 나눗셈과 달리 정해진 정수 범위에서 곱셈의 역연산을 수행하는 방법이다.
기존 컴퓨터에서는 divsteps라는 알고리즘을 이용해 이 계산을 효율적으로 수행할 수 있다.
하지만 divsteps는 계산 도중 여러 조건에 따라 서로 다른 연산을 선택한다.
이를 양자회로로 구현하려면 어떤 선택을 했는지 기록해야 하므로 많은 큐비트가 필요할 수 있다.
Claude는 여기서 다른 접근을 제안했다.
각 단계에서 어떤 분기가 선택됐는지 별도로 저장하지 않고, 현재 남아 있는 숫자들의 상태에서 과거 분기 정보를 다시 복원할 수 있는지 탐색한 것이다.
초기에는 간단한 규칙을 시험했지만 256비트 숫자에서는 제대로 작동하지 않았다.
이후 Claude는 수학적 관계를 분석해 새로운 대수적 항등식을 찾았다.
이를 이용해 분기 기록을 복원하는 공식을 도출했다.
연구진은 대규모 수치 실험을 통해 결과를 확인했고, 수학적 증명 도구인 Lean을 이용해 주요 성질을 형식적으로 검증했다.
Formal Verification(형식 검증)은 프로그램이나 수학적 명제가 정해진 논리 규칙을 만족하는지 엄밀하게 확인하는 방법이다.
이 과정을 통해 Claude는 분기 기록을 따로 저장하지 않는 가역적 divsteps 구현을 만들었다.
Claude는 약 53시간 동안 이 문제를 탐색했다.
연구진의 설명에 따르면 초기 문제 정의와 일부 방향 조정을 제외하면 상당 부분 자율적으로 진행됐다.
큐비트와 게이트 수의 절충 관계 개선
새로운 설계에서는 중간 정보를 저장하지 않아도 되지만, 이를 복원하기 위한 계산이 추가로 필요하다.
Claude는 모든 분기를 저장하거나 모두 재계산하는 두 극단 사이에서 여러 설계안을 만들었다.
그 가운데 하나는 기존의 가장 작은 설계보다 큐비트를 12% 더 사용하지만 게이트 수는 17분의 1 수준으로 줄였다.
여기서 17배라는 수치는 모든 양자 알고리즘이 17배 빨라졌다는 뜻이 아니다.
특정 타원곡선 연산을 구현하는 회로에서 기존 설계와 비교한 게이트 수의 차이다.
실제 양자 하드웨어에서의 실행 시간은 게이트의 종류와 오류율, 하드웨어 연결 구조와 오류 정정 비용에도 영향을 받는다.
연구진은 다른 양자 최적화 알고리즘에서도 성능을 개선했다.
대상은 DQI(Decoded Quantum Interferometry)라는 최적화 알고리즘에 필요한 Reed–Solomon 디코더였다.
Reed–Solomon은 통신과 저장장치의 오류 정정에 널리 사용되는 수학적 코드다.
Claude는 기존 확장 유클리드 알고리즘 대신 Berlekamp–Massey 알고리즘을 기반으로 회로를 다시 설계했다.
Berlekamp–Massey는 데이터에 나타나는 규칙을 점진적으로 찾아 오류의 위치를 복원하는 데 활용되는 알고리즘이다.
새로운 접근은 양자회로의 고정된 연산 순서에 더 적합했다.
또한 불필요한 중간 정보를 저장하지 않도록 설계를 변경했다.
연구진은 4억300만 회의 모의 디코딩을 실행해 예외적인 상황이 얼마나 자주 발생하는지 측정했다.
기존 방식대로 최악의 경우를 모두 고려하면 665개의 큐비트를 준비해야 했지만, 새로운 설계에서는 19개의 큐비트만 사용하는 방식을 제안했다.
약 1만 번에 한 번 정도는 예외적인 상황으로 인해 실패할 수 있지만, 연구 대상 알고리즘에서 허용하는 오류 범위 안에 있다는 설명이다.
그 결과 해당 디코딩 단계의 게이트 수가 기존 설계보다 12배 감소했다.
실제 양자컴퓨터에서 실행한 결과는 아니다
이번 연구 결과는 새로운 양자회로를 실제 양자컴퓨터에서 실행해 성능 향상을 측정한 것은 아니다.
주요 결과는 수학적 증명과 일반 컴퓨터를 이용한 시뮬레이션, 회로 자원 계산을 통해 평가됐다.
또한 새로운 알고리즘이 실제 하드웨어에서 얼마나 효과적으로 작동하는지 확인하려면 양자컴퓨터의 오류율과 연결 구조 등을 고려한 추가적인 검증이 필요하다.
그럼에도 이번 연구는 AI를 과학 연구에 활용하는 방식의 변화를 보여준다.
AI가 논문을 읽고 기존 연구를 정리하는 수준을 넘어 새로운 수학적 구조를 제안하고, 이를 코드로 구현한 뒤, 외부 검증 프로그램의 결과를 바탕으로 반복해서 개선하는 작업에 참여했다는 점이다.
특히 정답을 명확하게 검증할 수 있는 수학적·계산적 문제에서는 AI 에이전트와 독립적인 검증기를 결합하는 접근이 새로운 연구 방법으로 발전할 가능성이 있다.
Anthropic, Claude가 25년 넘게 미스터리였던 NIST 암호곡선의 생성 과정을 규명했다고 발표
- 발표일: 2026-10-16 — 정확한 게시 시각 미확인
- 적용 범위: 암호학, AI 기반 수학 연구, 암호 표준 검증, 난수 생성기 분석, 사이버보안
- 원문: Anthropic — Claude reveals ECDSA curve origins
Anthropic이 Claude를 이용해 오랫동안 설명되지 않았던 NIST 타원곡선 암호 표준의 일부 매개변수가 어떻게 만들어졌는지 규명한 연구 결과를 공개했다.
이번 결과는 새로운 암호 공격 방법을 발견했다는 발표가 아니다.
오히려 암호 표준의 설계 과정에 존재했던 오래된 의문을 해결하면서 해당 곡선에 의도적인 취약점이 포함됐을 가능성을 낮추는 증거를 제시한 연구다.
타원곡선 암호에서 문제가 됐던 숫자
ECDSA(Elliptic Curve Digital Signature Algorithm)는 타원곡선 수학을 이용해 전자서명을 생성하고 검증하는 암호 알고리즘이다.
전자서명은 메시지가 실제로 특정한 개인이나 조직에서 작성됐고 전송 과정에서 변경되지 않았는지 확인하는 데 사용된다.
ECDSA는 웹 보안과 여러 디지털 시스템에서 오랫동안 사용돼 왔다.
NIST는 2000년 관련 표준을 발표하면서 여러 타원곡선의 매개변수를 지정했다.
여기에는 P-192, P-224, P-256, P-384, P-521 등의 곡선이 포함된다.
그런데 일부 곡선의 매개변수가 어떤 과정을 통해 만들어졌는지는 충분히 설명되지 않았다.
암호학에서는 이런 정보가 중요하다.
표준을 만드는 사람이 특정한 숫자를 의도적으로 선택해 자신만 알고 있는 약점을 만들었을 가능성을 배제하려면, 해당 숫자가 어떤 절차로 생성됐는지 확인할 수 있어야 하기 때문이다.
NIST 표준에는 곡선의 매개변수를 생성할 때 사용된 Seed(시드) 값이 포함돼 있었다.
시드는 난수 생성기의 초기 상태를 정하거나 다른 수학적 매개변수를 계산할 때 사용하는 값이다.
문제는 이 시드 자체가 어디에서 유래했는지 알려지지 않았다는 점이었다.
Claude가 발견한 오래된 난수 생성기
Anthropic에 따르면 연구자들은 과거에 시드가 특정 문장을 해시한 결과일 수 있다고 추측했다.
하지만 이런 가설을 이용한 검색에서는 원래 생성 과정을 찾아내지 못했다.
Claude는 다른 방향으로 접근했다.
1990년대에 사용되던 C 언어 표준 라이브러리의 난수 생성기 가운데 시드와 비슷한 패턴을 만드는 것이 있는지 조사했다.
그 과정에서 lrand48라는 의사난수 생성기를 발견했다.
PRNG(Pseudorandom Number Generator, 의사난수 생성기)는 초기 상태를 바탕으로 무작위처럼 보이는 숫자들을 계산하는 프로그램이다.
실제로는 정해진 알고리즘을 사용하므로 같은 초기 상태를 사용하면 같은 숫자열을 다시 생성할 수 있다.
Claude는 NIST 시드의 일부 비트에서 lrand48의 출력과 일치하는 특징을 발견했다.
이후 가능한 내부 상태를 계산하고 여러 난수 생성기의 출력 패턴을 비교했다.
일부 경우에는 LLL 알고리즘도 사용했다.
LLL은 정수 격자 문제를 계산하는 수학적 알고리즘으로, 특정한 조건에서 숨겨진 숫자 관계를 찾는 데 사용할 수 있다.
Claude는 이런 방법을 통해 NIST 곡선의 여러 시드가 lrand48에서 생성됐다는 사실을 재구성했다.
더 나아가 난수 생성기의 초기 상태가 Unix Timestamp(유닉스 타임스탬프)에서 비롯됐다는 점도 찾아냈다.
Unix Timestamp는 1970년 1월 1일을 기준으로 경과한 시간을 나타내는 숫자다.
재구성된 초기 시각은 1997년 5월부터 1998년 4월 사이에 집중돼 있었다.
이는 해당 암호 표준의 개발 시기와도 맞아떨어진다.
재현 가능한 결과라는 점이 중요하다
이번 결과가 단순한 추측에 그치지 않는 이유는 Claude가 찾아낸 방법으로 공개된 시드를 다시 생성할 수 있기 때문이다.
예를 들어 P-256 곡선의 시드는 특정 초기값에서 난수 생성기를 1,842번 반복 실행한 뒤 얻어지는 값과 일치했다.
Anthropic은 여러 곡선에서 같은 방식으로 재현 가능한 결과를 확인했다고 밝혔다.
이 결과는 모델이 그럴듯한 설명을 만들어냈다는 사실보다 외부 프로그램을 이용해 수학적으로 검증할 수 있는 생성 절차를 찾아냈다는 점에서 의미가 있다.
다만 의사난수 생성기가 오늘날의 암호학적 난수 생성기보다 약하다는 사실을 기존 ECDSA 표준이 취약하다는 의미로 해석해서는 안 된다.
여기서 사용된 난수 생성기는 암호곡선의 공개 매개변수를 구성하는 시드를 만들기 위해 사용된 것이다.
개인의 비밀키를 생성하는 과정과는 다르다.
Anthropic 역시 이번 발견이 ECDSA 곡선에 새로운 공격 방법이나 취약점을 제공하지 않는다고 명확하게 설명했다.
오히려 오래된 암호 표준의 매개변수 생성 과정이 단순하고 재현 가능한 절차였다는 사실을 확인한 것이다.
이번 사례는 AI가 수학 연구에 기여하는 방식이 새로운 공식을 만드는 데만 국한되지 않음을 보여준다.
오래된 기술 표준에 남아 있는 불명확한 설계 과정이나 역사적 계산 절차를 역으로 추적하는 작업에서도 AI가 연구 도구로 활용될 수 있다는 사례다.
2️⃣ AI 제품·서비스
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
3️⃣ 개발 도구·에이전트
Reflection AI, 터미널 기반 코딩 에이전트 ‘Mirror CLI’ 공개…독립 워크트리와 병렬 작업, 도구 실행 승인 지원
- 발표일: 2026-10-16 — 정확한 게시 시각 미확인
- 적용 범위: 코딩 에이전트, CLI 개발 도구, Git Worktree, MCP, 병렬 에이전트, 오픈소스 개발 환경
- 원문: Reflection AI — Mirror CLI 개발자 문서
- 관련 원문: Reflection AI — Beam is now available
Reflection AI가 새로운 코딩 에이전트 Mirror CLI를 초기 베타 형태로 공개했다.
Mirror CLI는 사용자가 터미널에서 자연어로 작업을 요청하면 코드베이스를 읽고, 파일을 수정하고, 명령을 실행하면서 문제를 해결하는 개발 도구다.
이번 발표는 Beam 모델의 가중치 공개와 함께 진행됐지만, Mirror CLI는 모델 자체와 별개의 실행 환경이다.
Reflection AI는 Beam을 Mirror CLI와 함께 개발하고 학습시켜 두 시스템이 효율적으로 작동하도록 했다고 설명한다.
그러나 Mirror CLI는 Beam에만 고정된 도구는 아니다.
개발자는 다른 모델이나 추론 서비스 제공업체를 연결할 수도 있다.
AI 모델과 코딩 에이전트의 차이
언어모델은 기본적으로 입력을 받아 출력을 생성한다.
하지만 실제 코드 수정은 모델이 생성한 텍스트만으로 완료되지 않는다.
파일 시스템에서 코드를 읽고, 필요한 파일을 수정하고, 테스트 명령을 실행할 수 있어야 한다.
이런 작업을 관리하는 소프트웨어 계층을 Harness(하네스)라고 한다.
하네스는 모델에게 어떤 도구를 제공할지 결정하고, 도구 호출을 실제 명령으로 변환하며, 작업 진행 상태를 관리한다.
Mirror CLI는 이러한 역할을 수행한다.
개발자는 프로젝트 디렉터리에서 Mirror를 실행하고 원하는 작업을 설명할 수 있다.
에이전트는 파일을 검색하거나 수정하고 필요한 터미널 명령을 실행한다.
사용자는 각 단계에서 무엇이 진행되고 있는지 확인할 수 있다.
Mirror는 실행 기록과 추론 과정, 도구 호출 결과를 서로 다른 표시 수준으로 보여주는 기능도 제공한다.
단순히 최종 결과만 보는 대신 에이전트가 어떤 판단과 행동을 수행했는지 확인할 수 있도록 만든 것이다.
여러 에이전트가 서로 다른 작업을 동시에 수행
Mirror CLI의 특징 가운데 하나는 Git Worktree를 이용한 병렬 작업이다.
Git Worktree는 하나의 Git 저장소에서 여러 작업 디렉터리를 사용할 수 있도록 하는 기능이다.
예를 들어 개발자가 로그인 기능을 수정하는 동안 다른 에이전트가 테스트 코드를 작성하도록 할 수 있다.
두 작업이 같은 디렉터리에서 동시에 진행되면 서로 파일을 수정하면서 충돌할 수 있다.
반면 Worktree를 분리하면 각 에이전트가 독립적인 파일 상태에서 작업할 수 있다.
Mirror는 Worktree마다 별도의 대화 기록과 작업 상태를 관리한다.
한 에이전트의 화면으로 이동하더라도 다른 에이전트의 실행이 자동으로 중단되지 않는다.
또한 개발자는 이전 대화를 다시 열거나 특정 시점으로 돌아가 새로운 접근법을 시도할 수 있다.
다만 대화 기록을 되돌리는 기능과 실제 파일을 되돌리는 기능은 구분해야 한다.
Mirror의 /rewind는 대화 상태를 이전 시점으로 되돌리지만, 이미 수정된 파일까지 자동으로 복구하지는 않는다.
파일 변경사항을 되돌리려면 Git 등의 버전 관리 기능을 사용해야 한다.
이런 구분은 여러 에이전트가 동시에 코드를 수정하는 환경에서 중요하다.
Python 인터페이스와 Rust 실행 엔진 분리
Mirror CLI는 크게 두 부분으로 구성된다.
Python 프런트엔드는 프롬프트와 Skills, 개발자 도구와 확장 기능을 관리한다.
Rust 기반 에이전트 코어는 실제 모델 호출과 실행 흐름을 담당한다.
이렇게 분리하면 사용자가 직접 사용하는 인터페이스와 핵심 실행 엔진을 독립적으로 개발하고 평가할 수 있다.
Reflection AI는 핵심 실행 엔진을 상대적으로 작게 유지해 모델의 코딩 성능을 평가할 때 하네스의 복잡성이 결과에 미치는 영향을 줄이려 했다고 설명한다.
또한 개발자는 AGENTS.md와 Skills를 통해 프로젝트 규칙을 제공할 수 있다.
Skills는 특정 작업에 필요한 지침과 도구 사용 방법을 묶은 재사용 가능한 구성요소다.
외부 서비스와의 연결에는 MCP(Model Context Protocol)도 지원된다.
MCP는 AI 에이전트가 다른 프로그램과 데이터에 접근할 수 있도록 하는 통신 규격이다.
Mirror는 이를 통해 Linear, Notion 등 외부 서비스와 연결할 수 있으며, Python 확장 기능도 제공한다.
실행 승인은 샌드박스와 다르다
Mirror CLI는 기본적으로 Manual Approval Mode를 사용한다.
이 모드에서는 파일 수정과 셸 명령 실행, 외부 서비스 도구 호출 등의 작업 전에 사용자 승인을 요청한다.
개발자는 자동 실행 모드로 전환할 수도 있다.
자동 실행 모드에서는 에이전트가 도구 호출마다 별도의 승인을 받지 않고 작업을 진행한다.
하지만 Reflection AI는 문서에서 중요한 주의사항을 명시했다.
승인 모드는 샌드박스가 아니다.
에이전트가 실행하는 명령은 기본적으로 사용자의 계정 권한을 사용한다.
따라서 사용자가 승인했거나 자동 실행을 허용한 명령은 실제 파일과 시스템에 영향을 줄 수 있다.
특히 삭제나 외부 데이터 전송 같은 작업에서는 별도의 실행 격리와 접근권한 제한이 필요할 수 있다.
Mirror는 모델 서비스에 사용하는 API 키가 실행되는 명령의 환경변수에 그대로 노출되지 않도록 관리한다고 설명한다.
그러나 이것만으로 모든 인증정보나 로컬 파일에 대한 접근이 차단되는 것은 아니다.
실제 업무에 사용할 때는 실행 환경과 접근권한을 별도로 확인해야 한다.
현재 Mirror CLI는 초기 베타 단계다.
명령과 일부 동작 방식은 향후 버전에 따라 변경될 수 있다.
이번 공개는 코딩 에이전트 경쟁이 모델의 코드 생성 능력뿐 아니라 병렬 작업 관리, 프로젝트 지침, 실행 기록과 도구 사용의 통제 방식까지 확대되고 있음을 보여준다.
🖥️ AI 인프라·반도체
NVIDIA, 로컬 AI 개발용 ‘RTX Spark’ 생태계 확대…74B 모델을 24GB에 담는 Nemotron Bolt와 Windows on Arm 도구 공개
- 발표일: 2026-10-16 — 정확한 게시 시각 미확인
- 적용 범위: AI PC, NVIDIA GPU, 로컬 코딩 에이전트, Windows on Arm, 온디바이스 LLM, 모델 양자화, 개발 인프라
- 원문: NVIDIA — Code, Test, and Deploy on One Machine with NVIDIA RTX Spark
NVIDIA가 개인용 컴퓨터에서 AI 모델과 코딩 에이전트를 직접 실행할 수 있도록 설계한 RTX Spark의 개발 환경과 모델 생태계를 확대한다고 발표했다.
이번 발표에서는 하드웨어 자체뿐 아니라 Windows on Arm 개발 환경, 로컬 AI 실행 도구와 새로운 경량 모델이 함께 소개됐다.
RTX Spark는 NVIDIA의 GB10 시스템온칩(SoC)을 기반으로 한다.
SoC(System on a Chip)는 CPU와 GPU 등 여러 컴퓨터 구성요소를 하나의 반도체 패키지에 통합한 구조다.
RTX Spark에는 최대 128GB의 통합 메모리가 제공된다.
또한 NVIDIA는 최대 1PFLOPS의 FP4 AI 연산 성능을 지원한다고 설명한다.
FLOPS는 초당 수행할 수 있는 부동소수점 연산량을 나타내는 지표다.
FP4는 숫자를 매우 낮은 정밀도로 표현하는 형식이다.
다만 1PFLOPS라는 수치는 특정 낮은 정밀도의 연산 조건을 기준으로 한 이론적 성능이다.
모든 AI 모델이나 일반적인 프로그램이 같은 속도로 실행된다는 의미는 아니다.
클라우드 AI와 로컬 AI의 역할을 나누는 구조
최근 코딩 에이전트는 주로 클라우드의 대형 모델을 사용한다.
개발자의 컴퓨터는 코드와 도구를 실행하고, 모델의 추론은 외부 서버에서 수행하는 구조가 일반적이다.
이 방식은 강력한 모델을 사용할 수 있다는 장점이 있다.
그러나 코드 검색이나 간단한 오류 분류처럼 상대적으로 쉬운 작업에도 외부 모델을 호출하면 지연시간과 비용이 발생할 수 있다.
NVIDIA는 이런 작업을 로컬 모델이 먼저 처리하고, 필요한 경우에만 클라우드 모델을 호출하는 방식을 강조한다.
이를 Hybrid Routing(하이브리드 라우팅)이라고 한다.
예를 들어 사용자가 프로젝트에서 특정 함수를 찾으라고 요청하면 로컬 모델이 처리할 수 있다.
반면 복잡한 아키텍처 설계나 장기적인 추론이 필요하다면 더 강력한 클라우드 모델로 요청을 전달할 수 있다.
이런 구조는 모든 작업에 하나의 모델을 사용하는 것보다 비용을 세밀하게 관리할 수 있다는 장점이 있다.
다만 어떤 작업을 로컬에서 처리하고 어떤 작업을 클라우드로 전달할지 결정하는 라우터의 품질이 중요하다.
잘못된 요청 분류는 오히려 작업 실패나 불필요한 모델 호출을 늘릴 수 있다.
74B 모델을 24GB로 압축한 Nemotron 3.5 Bolt
이번 발표에는 새로운 로컬 AI 모델 Nemotron 3.5 Bolt 74B-A9B도 포함됐다.
이 모델의 전체 파라미터는 약 740억 개이며, 토큰 하나를 처리할 때는 약 90억 개의 파라미터가 활성화된다.
여기에는 MoE 구조가 사용된다.
NVIDIA는 이 모델을 2비트 양자화해 약 24GB 크기로 제공한다고 설명한다.
2비트 양자화는 모델 가중치를 매우 적은 비트 수로 표현해 메모리 사용량을 줄이는 방식이다.
그러나 정밀도를 낮추면 정보 손실이 발생할 수 있다.
NVIDIA는 이를 보완하기 위해 Quantization-Aware Training(양자화 인식 학습)을 사용했다고 밝혔다.
양자화 인식 학습은 모델을 학습하는 과정에서 낮은 정밀도의 계산이 가져올 영향을 반영해 성능 저하를 줄이는 방법이다.
Nemotron 3.5 Bolt는 llama.cpp, vLLM, Ollama, Unsloth, LM Studio 등에서 실행할 수 있도록 제공된다.
또한 Hermes와 OpenClaw 같은 코딩·업무 에이전트에도 연결할 수 있다.
NVIDIA는 가중치뿐 아니라 학습 데이터와 학습 방법도 공개한다고 설명했다.
다만 24GB라는 수치는 모델 가중치를 저장하는 데 필요한 공간을 나타낸다.
실제 추론에는 모델의 중간 계산 결과와 KV Cache, 실행 프로그램의 메모리도 필요하다.
따라서 메모리가 정확히 24GB인 컴퓨터에서 모든 설정으로 정상 실행된다는 뜻은 아니다.
Windows on Arm 개발 환경 확대
NVIDIA는 Microsoft와 협력해 Windows on Arm에서 사용할 수 있는 개발 도구도 확대했다.
Windows on Arm은 ARM 명령어 구조를 사용하는 프로세서에서 실행되는 Windows 환경이다.
많은 개발 도구는 오랫동안 x86 기반 프로세서를 중심으로 발전해 왔다.
따라서 ARM 기반 PC에서는 일부 라이브러리나 도구를 별도로 빌드해야 하는 문제가 발생할 수 있다.
NVIDIA는 이번 발표에서 Windows on Arm용 PyTorch-CUDA 빌드, Python 3.15의 기본 네이티브 지원, 2,000개 이상의 Conda 패키지를 소개했다.
또한 주요 Python 패키지 1만5천 개 가운데 97% 이상에 ARM 호환 버전이 제공된다고 밝혔다.
이러한 변화는 AI 모델을 실행하는 작업과 일반적인 애플리케이션 개발을 같은 PC에서 진행하기 쉽게 만든다.
개발자가 코드를 작성하고 모델을 실행한 뒤 테스트하는 작업을 서로 다른 환경으로 옮기는 부담을 줄이려는 것이다.
실제 개발 작업 성능 비교
NVIDIA는 RTX Spark와 Intel Panther Lake 기반 시스템의 성능을 비교한 결과도 공개했다.
| 평가 작업 | NVIDIA가 발표한 상대 성능 |
|---|---|
| 로컬 코딩 에이전트 | 최대 4.6배 |
| 모델 미세조정 | 최대 2.7배 |
| 코드 컴파일 | 최대 1.8배 |
코딩 에이전트 평가는 Qwen3.8-27B 모델을 사용한 AA-AgentPerf-local 테스트를 기준으로 했다.
미세조정은 Llama-3.1-8B의 LoRA 학습을 사용했다.
컴파일 성능은 Linux 커널 컴파일을 측정했다.
이 수치들은 NVIDIA가 특정 하드웨어와 작업 조건에서 측정한 자체 벤치마크 결과다.
일반적인 프런트엔드 개발이나 모든 코딩 에이전트에서 같은 비율의 성능 향상이 나타난다는 의미는 아니다.
또한 모델 추론과 일반적인 코드 컴파일은 GPU 사용 방식이 다르기 때문에 하나의 수치로 전체 개발 성능을 평가하기 어렵다.
NVIDIA는 로컬 에이전트의 보안을 위해 OpenShell과 Microsoft Execution Containers를 활용한 실행 격리도 지원한다고 설명한다.
이런 기술은 AI 에이전트가 코드를 실행할 때 접근할 수 있는 파일과 시스템 자원을 제한하는 데 사용할 수 있다.
RTX Spark 기반 노트북은 현재 제공되고 있으며, 소형 데스크톱 제품은 2026년 11월 출시 예정이다.
이번 발표는 로컬 AI 개발 환경의 역할이 단순히 작은 모델을 시험하는 수준에서 벗어나 코딩 에이전트 실행, 모델 추가 학습과 애플리케이션 배포 전 검증을 하나의 컴퓨터에서 수행하는 방향으로 발전하고 있음을 보여준다.
4️⃣ 산업·정책·안전
중국, AI 모델·에이전트·컴퓨팅 기술 23종을 수출통제 대상에 추가하는 개정안 발표…임시 사전 등록은 즉시 시행
- 발표 시각: 2026-10-16 17:00 KST (중국 현지시간 16:00)
- 적용 범위: 중국 AI 산업정책, 기술 수출통제, 오픈소스 모델, AI 컴퓨팅 클러스터, 사이버보안, 해외 AI 서비스
- 원문: 중국 상무부·과학기술부 — 수출금지·제한 기술목록 개정안 및 임시 등록 조치
- 관련 원문: 중국 상무부 — 개정안에 대한 공식 질의응답
중국 상무부와 과학기술부가 AI를 포함한 첨단기술의 해외 이전을 관리하기 위한 새로운 수출통제 개정안을 발표했다.
이번 발표는 중국에서 개발한 모든 AI 모델의 해외 제공을 금지하는 조치가 아니다.
중국 정부는 수출금지·제한 기술목록에 추가할 기술의 범위를 정하고, 해당 기술의 해외 이전을 관리하는 방안을 공개했다.
동시에 최종 개정안이 확정되기 전까지 일부 기술 수출에 대한 사전 등록 의무를 적용하기 시작했다는 점이 중요하다.
AI 기술 23종을 포함한 총 40종의 기술
이번 개정안은 세 분야를 대상으로 한다.
AI 분야에는 23종의 기술이 포함된다.
생물의약 분야에는 5종, 태양광 분야에는 12종이 포함된다.
전체적으로는 총 40종의 기술이 새롭게 관리 대상에 추가될 예정이다.
중국 상무부에 따르면 이 가운데 14종은 수출금지 대상으로, 26종은 수출제한 대상으로 제안됐다.
여기서 주의할 점은 14종의 수출금지 기술이 모두 AI 기술이라는 의미는 아니라는 사실이다.
금지·제한 분류는 AI와 생물의약, 태양광 기술을 모두 합친 기준이다.
AI 관련 목록에는 대형 언어모델과 AI 에이전트, 컴퓨팅 클러스터, 정보처리 기술 등이 포함된다.
특히 중국 정부는 보안상 위험이 큰 기술을 관리 대상으로 제시했다.
예를 들어 AI를 이용해 악성코드를 자동으로 생성하고 변형하는 기술은 수출금지 대상의 사례로 소개됐다.
AI를 이용해 소프트웨어 취약점을 자동으로 발견하는 기술은 수출제한 대상의 사례로 제시됐다.
여기서 취약점 탐지는 프로그램의 보안상 약점을 찾아내는 작업이다.
같은 기술은 정상적인 보안 점검에 활용할 수도 있지만 악의적인 공격자가 취약점을 찾는 데 사용할 수도 있다.
중국 정부는 이런 이중용도 기술(Dual-Use Technology)의 확산 위험을 주요 근거로 제시했다.
이중용도 기술은 정상적인 산업이나 연구에 사용할 수 있지만 군사·공격 목적으로도 활용할 수 있는 기술을 의미한다.
모델 API 제공과 기술 자체의 해외 이전은 구분
이번 개정안에서 가장 중요한 부분 가운데 하나는 어떤 형태의 해외 제공을 기술 수출로 볼 것인가에 대한 설명이다.
중국 정부는 제한 대상 AI 기술을 해외로 이전하는 행위와, 중국의 AI 서비스를 해외 고객에게 제공하는 행위를 구분했다.
공식 질의응답에 따르면 제한 대상 모델을 해외에 설치해 현지에서 운영하는 경우에는 기술 수출통제 대상에 포함될 수 있다.
하지만 중국 기업이 자체 모델을 이용해 해외 고객에게 API 호출, 웹사이트, 애플리케이션 또는 SaaS 서비스를 제공하는 경우에는 해당 AI 모델 기술의 수출통제 대상에 포함되지 않는다고 설명했다.
SaaS(Software as a Service)는 사용자가 프로그램을 직접 설치하거나 운영하지 않고 인터넷을 통해 서비스 형태로 이용하는 방식이다.
예를 들어 중국 기업이 자국 서버에서 모델을 실행하고 해외 개발자가 API로 답변을 받는 방식과, 모델 가중치나 핵심 기술을 해외 기업에 이전하는 방식은 다르게 취급될 수 있다는 뜻이다.
또한 경량 모델을 해외 사용자의 기기에 설치하는 일부 형태도 통제 범위에서 제외된다고 설명했다.
다만 이는 이번 개정안의 기술 수출통제 범위에 관한 설명이다.
서비스 운영에 적용되는 개인정보 보호법이나 사이버보안 규정 등 다른 법률까지 면제한다는 의미는 아니다.
오픈소스와 공개된 학술 연구는 원칙적으로 제외
중국 상무부는 AI 기술의 개방적인 연구와 국제 협력을 계속 지원하겠다는 입장도 밝혔다.
이번 개정안에서는 이미 오픈소스로 공개됐거나 학술 논문을 통해 공공 영역에 공개된 관련 기술을 수출관리 범위에 포함하지 않는다고 설명했다.
이는 모든 AI 모델의 가중치나 연구 결과를 해외로 공개할 때 허가를 받아야 한다는 해석과는 차이가 있다.
또한 일부 제한 기술을 해외의 자사 클라우드에서 운영하거나, 해외에서 공동 연구를 수행하고, 국제 표준화 작업에 참여하는 경우에는 자동 허가 등 간소화된 절차를 적용할 계획이다.
다만 실제로 어떤 기술과 거래에 해당 절차가 적용되는지는 최종 개정안의 구체적인 기준을 확인해야 한다.
최종 개정안은 아직 확정되지 않았다
이번 조치는 두 단계로 나뉜다.
첫 번째는 최종 수출금지·제한 기술목록의 개정이다.
이는 아직 확정되지 않았다.
중국 정부는 2026년 10월 16일부터 11월 15일까지 공개적으로 의견을 수렴한다.
두 번째는 임시 사전 등록 조치다.
이 조치는 발표일부터 적용된다.
해당 기술을 해외로 이전하려는 기업은 기술 수출 전에 중국 상무부의 시스템에 관련 정보를 등록해야 한다.
등록 대상에는 기술 소유권의 해외 이전, 중국 내 기술의 해외 사용허가, 기술 소유자나 실질적 지배자의 해외 주체로의 변경 등이 포함된다.
이미 진행 중이지만 아직 완료되지 않은 거래도 대상에 포함될 수 있다.
중요한 점은 사전 등록 의무가 즉시 시행됐다는 사실과, 최종 개정안에서 모든 기술의 수출이 즉시 금지됐다는 주장은 다르다는 것이다.
이번 발표는 AI의 국제적 확산을 관리하는 방법이 모델 서비스 자체를 차단하는 방식뿐 아니라 핵심 기술과 지식재산권, 모델의 해외 배포 구조를 구분하는 방향으로 세분화되고 있음을 보여준다.
특히 중국에서 개발한 오픈웨이트 모델을 해외에서 활용하는 기업과 개발자에게는 어떤 자료가 공개 기술에 해당하고 어떤 거래가 기술 이전에 해당하는지 구분하는 일이 중요해질 수 있다.
영국 경쟁시장청, Microsoft의 기업용 소프트웨어 시장 지위에 대한 규제 강화 제안…Copilot과 경쟁 AI의 접근성도 조사
- 발표일: 2026-10-16 — 정확한 게시 시각 미확인
- 적용 범위: 영국 디지털 시장 규제, Microsoft Copilot, 기업용 AI, 소프트웨어 경쟁, 데이터 상호운용성, 멀티클라우드
- 원문: 영국 CMA — CMA takes first steps to ensure choice in business software
- 관련 원문: 영국 CMA — Microsoft 기업용 소프트웨어 시장 지위 조사
영국의 경쟁시장청 CMA(Competition and Markets Authority)가 Microsoft의 기업용 소프트웨어 사업에 대해 전략적 시장 지위(Strategic Market Status, SMS)를 부여하는 방안을 공식적으로 제안했다.
이번 발표는 Microsoft가 경쟁법을 위반했다는 최종 판결이 아니다.
영국 정부가 시장 조사 결과를 바탕으로 Microsoft에 특별한 경쟁 규제 체계를 적용할 필요가 있는지 판단하기 위한 잠정적인 결론과 공개 협의 절차를 시작한 것이다.
그런데 이번 조사에는 기존의 Word, Excel, Teams뿐 아니라 AI 업무 도구인 Microsoft Copilot도 포함돼 있다는 점이 중요하다.
기존 업무 소프트웨어와 AI의 결합
Microsoft의 기업용 소프트웨어는 오랫동안 여러 조직의 핵심 업무 도구로 사용돼 왔다.
예를 들어 직원들은 Word로 문서를 작성하고 Excel로 데이터를 분석하며, Outlook과 Teams를 통해 의사소통한다.
이런 프로그램에는 조직의 문서와 일정, 협업 기록이 축적된다.
최근 Microsoft는 이러한 제품에 Copilot을 결합하고 있다.
Copilot은 사용자가 자연어로 문서를 작성하고 데이터를 분석하거나 여러 업무를 자동화하도록 돕는 AI 서비스다.
문제는 기존 소프트웨어 시장에서 강력한 위치를 가진 기업이 AI 기능까지 통합할 경우 다른 AI 기업이 경쟁하기 어려워질 가능성이 있다는 점이다.
예를 들어 사용자가 이미 Microsoft 365를 이용하고 있다면 Copilot은 문서와 일정, 협업 도구에 쉽게 연결될 수 있다.
반면 외부 AI 서비스가 같은 수준의 기능을 제공하려면 Microsoft 제품의 데이터와 API에 접근해야 할 수 있다.
이런 접근이 제한되거나 비용이 높다면 경쟁 제품의 기능을 구현하기 어려워질 수 있다.
CMA는 이런 상황에서 기업이 원하는 AI 도구를 자유롭게 선택하고 조합할 수 있는지 검토하겠다고 밝혔다.
전략적 시장 지위란 무엇인가
Strategic Market Status(SMS)는 영국의 디지털 시장 경쟁법에서 사용하는 개념이다.
특정 기업이 중요한 디지털 시장에서 상당하고 지속적인 시장 지배력을 가지고 있고, 전략적으로 중요한 위치에 있다고 판단될 때 적용할 수 있다.
SMS로 지정됐다는 사실만으로 해당 기업이 위법행위를 저질렀다고 확정되는 것은 아니다.
하지만 지정 이후에는 경쟁을 촉진하기 위한 별도의 의무나 조치를 적용할 수 있다.
예를 들어 고객이 다른 제품으로 전환하기 쉽게 만들거나 경쟁 기업의 서비스가 필수적인 기능에 접근할 수 있도록 요구할 수 있다.
CMA는 이번 조사에서 Microsoft가 다섯 가지 영역에서 강한 시장 지위를 가지고 있다고 판단했다.
대상에는 PC 운영체제, 생산성 소프트웨어, 보안 소프트웨어, 서버 운영체제와 관계형 데이터베이스 관리 시스템이 포함된다.
또한 기존 사용자가 다른 제품으로 전환하기 어렵다는 점을 주요 문제로 제시했다.
이를 Switching Cost(전환 비용)라고 한다.
전환 비용은 사용자가 제품이나 서비스를 바꿀 때 발생하는 금전적 비용뿐 아니라 데이터 이전, 직원 교육, 기존 시스템과의 연결 변경에 필요한 부담까지 포함한다.
CMA에 따르면 Microsoft의 기업용 소프트웨어는 영국의 100만 개 이상의 기업과 공공기관에서 사용되며, 월간 사용자는 약 2,000만 명에 이른다.
Copilot과 외부 AI의 경쟁 조건
CMA는 앞으로 조사할 주요 항목 가운데 하나로 Microsoft 제품에 통합된 AI와 외부 AI 서비스의 경쟁 조건을 제시했다.
예를 들어 Copilot이 Word나 Excel에 깊게 통합돼 있는 상황에서 외부 AI 제공업체가 같은 수준의 데이터를 활용하거나 기능을 제공할 수 있는지 검토할 수 있다.
또한 Microsoft의 보안 제품과 기업용 소프트웨어를 묶어 판매하는 방식도 조사 대상에 포함됐다.
Microsoft의 소프트웨어 라이선스를 다른 클라우드 환경에서 실행할 때 발생하는 제한도 검토할 예정이다.
다만 CMA가 이미 특정 API 공개나 Copilot 기능 분리를 명령한 것은 아니다.
현재는 어떤 문제가 존재하는지 추가 자료를 확보하고, 필요한 조치를 검토하는 단계다.
클라우드 전환과 상호운용성도 조사
CMA는 이번 발표와 함께 Microsoft와 AWS의 클라우드 서비스 경쟁 상황에 관한 조사 결과도 공개했다.
두 기업은 다른 클라우드 서비스로 이전할 때 발생하는 일부 데이터 전송 비용을 없애거나 줄이는 조치를 진행하고 있다.
또한 경쟁 클라우드와의 연결을 확대하는 작업도 추진하고 있다.
하지만 CMA는 아직 충분하지 않은 부분이 있다고 설명했다.
특히 서로 다른 클라우드에서 IAM(Identity and Access Management, 사용자와 프로그램의 접근권한을 관리하는 기술)을 일관되게 사용하는 문제를 추가로 검토할 계획이다.
예를 들어 기업이 AWS와 Azure를 함께 사용한다면 사용자와 AI 에이전트가 어떤 데이터에 접근할 수 있는지 일관되게 관리해야 한다.
이런 기능이 충분히 호환되지 않으면 기업이 하나의 클라우드 제공업체에 더 강하게 의존할 수 있다.
확정된 규제는 아니다
CMA는 Microsoft에 SMS를 부여하는 방안에 대해 의견을 수렴한다.
의견 제출 기한은 2026년 11월 13일이다.
최종 지정 여부는 2027년 2월 13일까지 결정할 예정이다.
따라서 이번 발표를 Microsoft에 새로운 경쟁법상 의무가 즉시 적용된 것으로 해석해서는 안 된다.
또한 잠정적인 시장 조사 결과와 실제 위법행위의 인정은 구분해야 한다.
이번 발표가 보여주는 변화는 기업용 AI 시장의 경쟁 조건이 어떤 모델이 더 뛰어난 답변을 생성하는가에만 달려 있지 않다는 점이다.
기존 업무 소프트웨어가 보유한 사용자 기반과 데이터, API 접근권한과 결제 구조까지 AI 서비스의 경쟁에 영향을 미칠 수 있다.
이에 따라 AI 시장의 경쟁 정책도 모델의 성능뿐 아니라 기존 업무 플랫폼과 새로운 AI 서비스가 공정하게 연결될 수 있는가라는 문제를 다루기 시작했다.
📚 추천 글
How Meta Built Forum With AI-Native Engineering
- 저자: Shengbo Guo, Bohou Luo, Shubhojeet Sarkar, Vivian Qu 외 Meta Engineering 연구진
- 발행: Meta Engineering
- 게시일: 2026-10-15
- 원문: Meta Engineering — How Meta Built Forum With AI-Native Engineering
AI 코딩 에이전트를 이용해 새로운 서비스를 개발할 때 단순히 코드를 빠르게 생성하는 것보다 무엇이 더 중요한지 보여주는 글이다.
Meta는 새로운 커뮤니티 앱 Forum을 개발하면서 AI 에이전트를 단순한 코드 자동완성 도구가 아니라 실제 개발 과정에 참여하는 구성요소로 활용했다.
Forum은 Facebook 그룹의 대화를 더 깊이 살펴볼 수 있도록 설계된 별도 애플리케이션이다.
Meta는 작은 개발팀으로 이 제품을 개발하면서 기존의 개발 방식을 상당 부분 변경했다.
특히 코드를 얼마나 많이 생성했는가보다 실제로 검증돼 배포할 수 있는 기능을 얼마나 완성했는가를 주요 성과 기준으로 삼았다.
Human-in-the-Loop에서 Human-on-the-Loop로
기존 AI 코딩 도구에서는 개발자가 직접 작업을 진행하고 필요한 순간에 AI의 도움을 받는 경우가 많다.
예를 들어 개발자가 코드를 작성하다가 특정 함수를 생성하도록 요청하거나 오류 메시지의 원인을 설명해 달라고 요청한다.
이 방식은 Human-in-the-Loop에 가깝다.
사람이 실행 과정의 각 단계에 참여하면서 작업을 진행하는 방식이다.
Meta는 Forum 개발에서 Human-on-the-Loop라는 방식을 시험했다.
이 구조에서는 에이전트가 계획 수립과 코드 작성, 빌드, 테스트, 오류 수정 과정을 반복한다.
개발자는 전체 목표를 정하고 결과를 검토하며 필요한 경우 개입한다.
즉 사람의 역할이 모든 명령을 직접 실행하는 것에서 작업의 목표와 품질을 책임지는 역할로 이동하는 것이다.
다만 Meta는 모든 개발 단계를 완전히 자율화한 것은 아니라고 설명한다.
일부 작업은 여전히 개발자가 매 단계에 개입해야 하며, 최종 변경사항에는 엔지니어의 승인이 필요하다.
에이전트가 코드를 생성한 뒤 스스로 검증
Meta는 AI 에이전트의 작업을 평가하는 기준을 코드 컴파일 성공 여부보다 높게 설정했다.
프로그램이 정상적으로 컴파일된다고 해서 기능이 올바르게 작동한다는 의미는 아니기 때문이다.
예를 들어 React Native 앱에서 화면을 수정했을 때 코드가 정상적으로 빌드되더라도 버튼의 위치가 잘못됐거나 특정 사용자 흐름이 깨졌을 수 있다.
이를 방지하기 위해 Meta는 빌드 결과와 단위 테스트, UI 명세와 실제 화면의 일치 여부를 에이전트의 실행 과정에 포함했다.
에이전트는 코드 변경을 완료한 뒤 검증을 실행한다.
검증에 실패하면 결과를 분석하고 코드를 다시 수정한다.
이 과정을 반복해 정해진 기준을 통과한 변경사항만 개발자에게 전달한다.
생성된 PR에는 테스트 계획과 실행 기록, 검증 결과가 첨부된다.
개발자는 코드를 처음부터 직접 실행해 보는 대신 이미 수집된 검증 자료를 바탕으로 변경사항을 검토할 수 있다.
Meta는 이 방식으로 개발자가 검토해야 하는 미완성 결과의 양을 줄일 수 있었다고 설명한다.
문제는 프롬프트보다 개발 환경에 있었다
이 글에서 특히 중요한 부분은 Meta가 발견한 주요 실패 원인이다.
초기 에이전트는 애플리케이션의 현재 화면 상태를 제대로 이해하지 못했다.
예를 들어 사용자가 특정 그룹 화면을 수정하라고 요청했는데, 에이전트가 비슷한 구조의 홈 화면을 수정하는 문제가 발생했다.
또는 화면에 있는 버튼의 위치를 추측한 뒤 잘못된 좌표를 클릭하기도 했다.
Meta는 이런 문제를 해결하기 위해 프롬프트를 더 길게 작성하는 대신 실제 UI 상태를 직접 확인하는 도구를 제공했다.
에이전트는 시뮬레이터에서 현재 화면의 View Hierarchy를 읽을 수 있게 됐다.
View Hierarchy(뷰 계층 구조)는 화면에 표시된 UI 요소들이 어떤 부모·자식 관계로 구성돼 있는지 나타내는 정보다.
에이전트는 실제로 화면에 존재하는 요소를 조회하고, 수정하려는 화면의 경로를 확인한 뒤 작업할 수 있었다.
Meta에 따르면 이러한 변경 이후 잘못된 화면을 수정하는 문제가 크게 감소했다.
핵심은 모델에게 화면을 잘 이해하라고 지시하는 것보다 실제 상태를 확인할 수 있는 도구를 제공하는 것이 더 효과적이었다는 점이다.
실험용 코드와 실제 배포 코드를 물리적으로 분리
Meta는 AI를 이용한 빠른 실험을 지원하면서도 실제 사용자에게 영향을 주지 않도록 별도의 빌드 구조를 설계했다.
일반적인 애플리케이션에서는 새로운 기능을 실험할 때 Feature Flag(특정 기능을 켜거나 끌 수 있는 설정)를 사용한다.
하지만 Feature Flag만 사용하면 비활성화된 실험 코드도 실제 제품의 빌드 결과물에 포함될 수 있다.
Meta는 이를 더 강하게 분리했다.
실험용 애플리케이션과 실제 배포용 애플리케이션을 서로 다른 빌드 구성으로 만들었다.
두 빌드는 같은 코드베이스와 디자인 시스템을 공유하지만, 실험용 플러그인 코드는 실제 배포 빌드에 포함되지 않는다.
따라서 실험 코드가 실행되지 않도록 설정하는 것보다 강한 분리 효과를 얻을 수 있다.
AI 에이전트가 새 기능을 시험하는 과정에서 문제가 발생하더라도 실제 사용자용 앱에는 해당 코드가 존재하지 않도록 만든 것이다.
AI 에이전트를 실제 사용자처럼 테스트에 활용
Meta는 개발 과정에서 에이전트를 실제 사용자처럼 앱을 조작하는 테스트 도구로도 활용했다.
에이전트는 빠른 스크롤과 화면 이동, 그룹 탐색과 미디어 로딩을 반복했다.
이런 방식으로 앱의 메모리 사용량과 오류, UI 회귀 문제를 관찰했다.
Regression(회귀 오류)은 새로운 변경사항을 적용한 뒤 이전에는 정상적으로 작동하던 기능에 문제가 발생하는 현상이다.
테스트 과정에서는 특정한 메모리 문제도 발견됐다.
에이전트는 해당 오류를 재현하고 원인을 조사한 뒤 수정안을 제안했다.
Meta에 따르면 수정 이후 반복적인 테스트에서 메모리 증가량과 페이지 오류가 대략 절반 수준으로 줄었다.
또한 Forum은 약 8주 만에 Facebook Groups의 주요 기능과 비슷한 수준에 도달했다고 설명한다.
다만 이는 Meta의 자체 개발 프로젝트에서 관찰된 결과다.
모든 개발팀이 AI 에이전트를 도입하면 같은 시간 안에 비슷한 제품을 만들 수 있다는 뜻은 아니다.
이번 글에서 가장 인상적인 부분은 Meta가 모델을 더 좋은 모델로 교체하는 것보다 기존 코드와 개발 도구를 에이전트가 이해하기 쉽게 바꾸는 데 집중했다는 점이다.
AI 에이전트가 개발 과정에 깊이 참여할수록 코드를 생성하는 속도만큼 작업 상태의 가시성, 자동화된 검증과 안전한 실험 환경이 중요해진다는 사실을 구체적인 개발 사례로 보여준다.
Scaling Indic Pretraining: 2.8 Trillion Tokens and an Open Data Generation Pipeline
- 저자: Mohammed Safi Ur Rahman Khan, Mitesh Khapra, Anoop Kunchukuttan 외 NVIDIA·AI4Bharat 연구진
- 발행: NVIDIA / IIT Madras AI4Bharat / Hugging Face
- 게시일: 2026-10-16
- 원문: Hugging Face — Scaling Indic Pretraining: 2.8 Trillion Tokens and an Open Data Generation Pipeline
영어가 아닌 언어에서도 성능이 좋은 AI 모델을 만들기 위해 필요한 것이 무엇인지 구체적으로 설명하는 글이다.
NVIDIA와 인도의 IIT Madras 산하 연구조직 AI4Bharat는 인도에서 사용되는 22개 언어를 위한 대규모 AI 학습 데이터 생성 프로젝트를 공개했다.
연구팀은 약 2조8천억 토큰 규모의 데이터를 구축했다고 밝혔다.
다만 이번 글이 공개된 시점에는 전체 데이터셋이 아직 다운로드 가능한 상태가 아니었다.
연구팀은 데이터셋을 곧 공개할 계획이며, 데이터 생성 과정의 코드와 방법을 먼저 공유했다고 설명한다.
이 구분은 중요하다.
이번 글은 대규모 데이터를 실제로 생성한 방법과 검증 결과를 공개한 기술 자료이지, 모든 데이터의 배포가 이미 완료됐다는 발표는 아니다.
왜 언어별 학습 데이터가 중요한가
대형 언어모델은 방대한 텍스트 데이터에서 언어의 구조와 지식, 문제 해결 패턴을 학습한다.
그런데 인터넷에 존재하는 텍스트의 양은 언어별로 크게 다르다.
영어는 과학 논문과 기술 문서, 프로그래밍 자료와 교육 콘텐츠가 풍부하다.
반면 일부 언어에서는 같은 수준의 자료를 확보하기 어렵다.
AI 모델이 해당 언어의 문장 구조를 이해할 수 있더라도 전문적인 질문에 답하거나 복잡한 추론을 수행하는 능력은 제한적일 수 있다.
인도의 언어 환경은 특히 복잡하다.
인도에서는 여러 언어와 문자 체계를 사용한다.
또한 같은 언어를 사용하더라도 전통적인 문자 대신 로마자로 발음을 적어 의사소통하는 경우가 많다.
예를 들어 힌디어 문장을 데바나가리 문자로 작성할 수도 있고, 영어 알파벳을 이용해 발음대로 적을 수도 있다.
이를 Romanization(로마자 표기)이라고 한다.
연구팀은 이런 차이를 고려해 22개 언어의 원래 문자 데이터와 12개 언어의 로마자 표기 데이터를 구축했다.
총 34개의 언어·문자 조합을 다루는 것이다.
영어 문서를 단순히 번역하는 것으로 충분하지 않다
연구팀은 먼저 품질이 좋은 영어 문서를 수집했다.
대상에는 수학과 과학, 프로그래밍, 일반 지식과 질문·답변 자료가 포함됐다.
하지만 영어 문서를 다른 언어로 무조건 번역하면 오류가 발생할 수 있다.
예를 들어 수학 문서에서 수식을 잘못 변경하거나 프로그래밍 코드의 변수 이름을 번역하면 원래 의미가 달라질 수 있다.
표의 열과 행이 뒤바뀌거나 숫자의 단위가 변경되는 문제도 발생할 수 있다.
연구팀은 이를 해결하기 위해 문서 전체의 문맥을 유지하는 번역 방식을 사용했다.
문장 하나만 독립적으로 번역하는 대신 문서의 제목과 구조, 앞뒤 설명을 함께 참고하도록 한 것이다.
이 과정에는 대형 언어모델이 사용됐다.
번역 결과는 별도의 품질 평가 모델이 검사했다.
연구팀은 의미 보존과 언어의 자연스러움, 수식과 표의 정확성 등을 평가했다.
특정 기준을 충족하지 못하는 문서는 다시 수정하도록 했다.
이런 방식은 Synthetic Data Generation(합성 데이터 생성)의 한 사례다.
합성 데이터는 사람이 직접 작성한 원본이 아니라 프로그램이나 AI 모델을 이용해 생성한 데이터다.
생성한 데이터를 다시 검증하고 수정
이번 프로젝트에서 가장 흥미로운 부분은 데이터 생성 이후의 검증 과정이다.
일반적으로 합성 데이터를 대량으로 만들면 생성량이 많다는 사실 자체에 주목하기 쉽다.
그러나 잘못된 데이터가 대규모로 포함되면 모델 학습에 부정적인 영향을 줄 수 있다.
연구팀은 번역한 문서를 원본과 비교하면서 오류 유형을 분석했다.
품질 점수가 낮은 문서에서는 수식과 코드, 표 구조를 다시 확인하고 필요한 부분을 수정했다.
이런 방식으로 약 4,384억 토큰에 해당하는 데이터를 보완했다고 설명한다.
또한 데이터의 원본 출처를 추적할 수 있도록 각 생성 결과를 기존 문서와 연결했다.
이는 AI가 생성한 문서를 검증할 때 중요한 설계다.
최종 결과가 이상하거나 잘못된 정보가 포함됐을 때 원본 문서와 생성 과정을 다시 확인할 수 있기 때문이다.
실제 모델 학습에 적용한 결과
NVIDIA는 생성한 데이터를 실제 모델 학습에도 활용했다.
대상은 Nemotron 3.5 Super VL이다.
연구팀은 약 100억 개의 인도 언어 토큰을 해당 모델의 추가 사전학습에 사용했다.
이 데이터는 합성 데이터만으로 구성된 것은 아니다.
인도 언어로 실제 작성된 원본 데이터도 함께 사용됐다.
이를 Continued Pretraining(추가 사전학습)이라고 한다.
이미 학습된 모델에 새로운 대규모 데이터를 제공해 특정 언어나 분야에 대한 능력을 보완하는 방식이다.
연구팀은 여러 인도 언어 평가에서 약 4.98~9.82%포인트의 성능 향상을 보고했다.
다만 이 수치를 합성 데이터의 효과만으로 해석해서는 안 된다.
추가 학습에는 자연적으로 작성된 인도 언어 데이터도 포함됐으며, 여러 학습 조건이 함께 영향을 미쳤을 수 있기 때문이다.
또한 해당 수치는 NVIDIA와 AI4Bharat가 공개한 자체 평가 결과다.
이번 글은 다국어 AI의 성능을 높이는 일이 단순히 번역된 문장을 많이 수집하는 문제가 아니라는 점을 보여준다.
원본 지식의 품질, 번역 과정에서의 의미 보존, 문자 체계의 차이와 합성 데이터의 검증 절차를 함께 고려해야 한다.
한국어처럼 영어와 다른 언어 구조를 가진 환경에서 전문적인 AI 서비스를 개발할 때도 참고할 만한 연구다.
The Missing Piece in LLM Memory: Why Long Context and Retrieval Aren't Enough for Belief Revision
- 저자: Rahul Vimalkanth, Tanish Chudiwal
- 발행: Hugging Face Community
- 게시일: 2026-10-15
- 원문: Hugging Face — The Missing Piece in LLM Memory: Why Long Context and Retrieval Aren't Enough for Belief Revision
AI 모델의 컨텍스트가 점점 길어지고 있는데도 장시간 대화에서 과거의 잘못된 정보를 계속 사용하는 이유는 무엇일까?
이 글은 그 원인을 단순한 기억 용량의 부족이 아니라 기억을 수정하는 방법의 문제로 설명한다.
최근 언어모델은 매우 긴 컨텍스트를 지원한다.
일부 모델은 100만 토큰 이상의 입력을 처리할 수 있다.
하지만 긴 컨텍스트가 있다고 해서 모델이 이전 대화의 모든 정보를 올바르게 활용하는 것은 아니다.
특히 새로운 정보가 과거의 정보와 충돌할 때 문제가 발생할 수 있다.
정보를 기억하는 것과 기억을 수정하는 것은 다르다
예를 들어 코딩 에이전트가 다음 함수를 사용하고 있다고 가정해 보자.
get_user(user_id)
그런데 다른 개발자가 코드를 변경해 다음과 같이 수정했다.
get_user(org_id, user_id)
에이전트가 새로운 함수 정의를 확인했다고 하더라도 이전 정의가 대화 기록에서 자동으로 사라지지는 않는다.
긴 컨텍스트에는 두 정의가 모두 존재할 수 있다.
이때 모델이 과거 정의를 다시 사용하면 오류가 발생한다.
문제는 새로운 정보를 읽지 못했다는 것이 아니다.
과거에 올바르던 정보가 더 이상 유효하지 않다는 사실을 모델의 현재 판단에 반영하지 못한 것이다.
저자들은 이를 Belief Revision(믿음 수정 또는 지식 상태 갱신)이라고 설명한다.
여기서 믿음은 인간의 심리적인 신념을 의미하지 않는다.
모델이 현재 질문을 받았을 때 어떤 답변이나 행동을 선택하는지에 영향을 주는 내부 정보 상태를 뜻한다.
RAG만으로 해결되지 않는 이유
RAG(Retrieval-Augmented Generation)는 외부 문서를 검색해 언어모델에 제공하는 방식이다.
검색 시스템을 사용하면 과거의 대화 기록이나 저장된 문서를 필요할 때 다시 읽을 수 있다.
그러나 검색된 정보 가운데 어떤 것이 최신이고 어떤 것이 오래된 정보인지 판단하는 문제는 여전히 남는다.
예를 들어 사용자의 과거 주소와 새로운 주소가 모두 검색됐다고 가정해 보자.
검색 시스템은 두 기록을 모델에 전달할 수 있다.
하지만 어느 주소를 현재 주소로 사용할지는 별도의 판단이 필요하다.
저자들은 이런 상황에서 정보를 다시 가져오는 능력과 현재 유효한 정보를 선택하는 능력을 구분해야 한다고 설명한다.
기억을 많이 보관하거나 정확하게 검색하는 것만으로는 충분하지 않다는 것이다.
Attention과 메모리 갱신의 차이
글에서는 이 문제를 이해하기 위해 Attention(어텐션) 구조부터 설명한다.
Attention은 모델이 입력의 서로 다른 부분 사이의 관련성을 계산하는 방법이다.
일반적인 Transformer에서는 이전 입력의 정보를 KV Cache에 저장할 수 있다.
KV Cache는 이미 처리한 입력에서 계산한 정보를 보관해 이후 토큰을 생성할 때 같은 계산을 반복하지 않도록 하는 구조다.
하지만 KV Cache는 기본적으로 이전 계산 결과를 저장하는 데 초점을 맞춘다.
정보가 잘못됐다는 사실이 새롭게 확인됐을 때 기존 정보를 어떤 방식으로 수정해야 하는지는 별개의 문제다.
저자들은 이를 설명하기 위해 Linear Attention(선형 어텐션)을 사용한다.
Linear Attention은 과거의 정보를 고정된 크기의 상태에 압축해 저장하는 방식이다.
모든 이전 정보를 개별적으로 유지하는 대신 하나의 누적된 상태에 반영한다.
이는 메모리 사용량을 줄일 수 있다는 장점이 있다.
하지만 새로운 정보가 들어왔을 때 기존 상태를 어떻게 변경해야 하는지가 중요해진다.
단순한 정보 누적은 오래된 정보를 제거하지 못한다
저자들은 Additive Memory(가산적 메모리)의 한계를 설명한다.
가산적 메모리는 새로운 정보가 들어올 때 기존 상태에 해당 정보를 더하는 방식이다.
이 방법은 서로 모순되지 않는 사실을 계속 축적하는 데 적합할 수 있다.
예를 들어 사용자가 좋아하는 음식에 관한 새로운 정보를 추가하는 상황에서는 유용할 수 있다.
하지만 사용자가 예전에 좋아하던 음식을 더 이상 좋아하지 않게 됐다면 상황이 다르다.
새로운 정보를 단순히 추가하면 과거의 선호와 현재의 선호가 같은 메모리에 함께 남을 수 있다.
결국 모델은 서로 충돌하는 두 정보를 가지고 판단해야 한다.
이를 해결하려면 기존 정보를 얼마나 유지하고 새로운 정보로 얼마나 수정할지 결정하는 규칙이 필요하다.
글에서는 이를 Update Rule(갱신 규칙)이라고 부른다.
예를 들어 새로운 정보와 기존 메모리가 예측한 결과 사이의 차이를 계산하고, 해당 차이만큼 상태를 수정하는 방법을 사용할 수 있다.
이런 접근은 Delta Rule과 연결된다.
Delta Rule은 현재 예측값과 새롭게 주어진 목표값의 차이를 이용해 모델의 상태를 조정하는 방법이다.
다만 이번 글은 이런 방식 하나가 모든 장기 기억 문제를 해결한다고 주장하지 않는다.
기억을 저장하는 구조와 읽는 방식, 정보를 수정하는 방식 사이의 차이를 체계적으로 설명하는 데 목적이 있다.
실제 에이전트 설계와의 관계
이 논의는 장시간 실행되는 코딩 에이전트와 조사 에이전트에 직접적으로 연결된다.
예를 들어 코딩 에이전트는 작업 도중 다른 개발자가 병합한 변경사항을 확인할 수 있다.
조사 에이전트는 처음에 세운 가설이 새로운 증거에 의해 틀렸다는 사실을 발견할 수 있다.
이런 상황에서 에이전트는 단순히 새 정보를 기억하는 것이 아니라 기존 계획과 판단 기준을 업데이트해야 한다.
저자들은 메모리를 설계할 때 저장 용량과 검색 성능뿐 아니라 다음과 같은 문제를 고려해야 한다고 설명한다.
새 정보가 들어왔을 때 기존 상태에 추가할 것인지, 일부를 교체할 것인지, 오래된 정보를 약화할 것인지 결정해야 한다.
또한 새로운 정보가 잘못됐을 가능성이 있을 때는 기존 상태를 무조건 덮어쓰지 않는 방법도 필요하다.
이는 기억의 안정성(Stability)과 가변성(Plasticity) 사이의 균형 문제다.
안정성이 너무 높으면 오래된 정보를 수정하지 못할 수 있다.
반대로 가변성이 너무 높으면 일시적인 오류나 잘못된 정보에 의해 기억이 쉽게 변경될 수 있다.
이번 글은 새로운 제품이나 실험 결과를 발표하는 자료라기보다 여러 메모리 아키텍처를 비교하고 개념을 정리한 기술 에세이다.
수학적인 설명이 상당히 포함돼 있지만, AI가 긴 대화를 기억하는 것과 그 대화에서 얻은 지식을 올바르게 수정하는 것은 다른 문제라는 관점을 이해하는 데 유용하다.
Build self-improving document processing using Amazon Bedrock AgentCore
- 저자: Erik Cordsen, Sourabh Jain, Vivek Mittal
- 발행: AWS Artificial Intelligence Blog
- 게시일: 2026-10-14
- 원문: AWS — Build self-improving document processing using Amazon Bedrock AgentCore
기업에서 문서를 자동으로 처리하는 AI 시스템을 만들 때 가장 어려운 문제 가운데 하나는 문서의 형식이 계속 달라진다는 점이다.
예를 들어 여러 공급업체에서 보내는 주문서나 송장을 자동으로 처리한다고 가정해 보자.
어떤 회사는 문서의 왼쪽 위에 주문번호를 표시하고, 다른 회사는 표 안에 주문번호를 포함할 수 있다.
같은 회사의 문서라도 시간이 지나면서 양식이 변경될 수 있다.
기존의 템플릿 기반 시스템에서는 문서 양식이 바뀔 때마다 추출 규칙을 수정해야 하는 경우가 많았다.
AWS는 이런 문제를 해결하기 위해 문서 구조를 분석하고, 필요한 정보를 추출하고, 실패한 결과를 바탕으로 추출 방법을 수정하는 멀티에이전트 시스템을 구현했다.
이 글은 실제 배포 가능한 샘플 코드를 제공하면서 각 에이전트의 역할과 데이터 흐름을 구체적으로 설명한다.
문서 추출을 하나의 LLM에게 모두 맡기지 않는다
AWS의 예제는 여덟 개의 전문 에이전트를 사용한다.
전체 시스템은 크게 문서 식별 단계와 문서 처리 단계로 나뉜다.
먼저 Analyzer 에이전트가 Amazon Textract를 이용해 문서의 텍스트를 추출한다.
Textract는 이미지나 스캔 문서에서 문자와 표, 양식 정보를 추출하는 AWS 서비스다.
이후 Matcher 에이전트가 해당 문서와 비슷한 자료가 이전에 처리됐는지 검색한다.
여기에는 Vector Search(벡터 검색)가 사용된다.
Vector Search는 문장이나 문서의 의미를 숫자로 표현한 뒤 서로 얼마나 비슷한지 비교하는 검색 방법이다.
기존에 처리한 문서와 충분히 비슷하다면 이전에 저장한 추출 규칙을 재사용할 수 있다.
반대로 새로운 문서 유형이라면 별도의 학습 흐름을 실행한다.
새로운 문서 형식을 스스로 학습하는 과정
처음 보는 주문서가 들어오면 Instructions Agent가 필요한 정보를 추출하기 위한 지침을 만든다.
예를 들어 주문번호, 거래처 이름, 주문 날짜와 상품 목록을 추출하도록 지침을 작성할 수 있다.
Extractor 에이전트는 해당 지침을 이용해 문서에서 데이터를 추출한다.
결과는 JSON 형태로 정리된다.
그러나 JSON 형식으로 결과를 만들었다고 해서 데이터가 정확하다고 볼 수는 없다.
예를 들어 주문번호가 있어야 할 위치에 잘못된 값이 들어가거나, 상품의 수량과 단가를 잘못 읽을 수 있다.
이를 검사하기 위해 Validator 에이전트가 별도로 실행된다.
Validator는 결과가 정해진 데이터 구조를 따르는지 확인하고, 실제 업무 규칙도 검사한다.
예를 들어 각 상품의 수량과 단가를 곱한 값이 합계와 일치하는지 확인할 수 있다.
또는 거래처가 실제로 등록된 업체인지 검사할 수 있다.
검증에 실패하면 Instructions Fixer 에이전트가 오류 원인을 분석한다.
이후 데이터 추출 지침을 수정하고 다시 추출 작업을 실행한다.
검증에 성공한 지침은 별도 저장소에 보관한다.
비슷한 문서가 다시 들어오면 해당 지침을 재사용하는 것이다.
예시: 상품 코드 형식 오류 수정
AWS는 자전거 부품을 판매하는 가상의 기업을 이용해 실제 처리 예시를 제시했다.
새로운 거래처의 주문서를 처음 처리했을 때 상품 코드를 추출하는 과정에서 오류가 발생했다.
거래처의 상품 코드는 SB-004였지만 내부 ERP 시스템에서는 AB-SB-004라는 형식을 사용해야 했다.
ERP(Enterprise Resource Planning)는 기업의 주문과 재고, 회계 등 주요 업무 데이터를 통합 관리하는 시스템이다.
Validator는 추출된 상품 코드가 내부 형식과 일치하지 않는다는 사실을 발견했다.
Instructions Fixer는 오류를 분석한 뒤 거래처 상품 코드 앞에 AB-를 추가하도록 추출 지침을 수정했다.
이후 다시 실행한 검증에서는 정상적인 결과를 얻었다.
시스템은 이 지침을 저장했다.
두 번째 주문서가 같은 거래처에서 도착했을 때는 처음부터 지침을 생성할 필요가 없었다.
Matcher가 이전에 저장한 지침을 찾아 재사용했기 때문이다.
AWS가 공개한 예제에서 첫 주문서는 3분49초, 두 번째 주문서는 1분30초에 처리됐다.
다만 이는 샘플 환경에서 실행한 두 개 문서의 결과다.
모든 문서 처리 작업에서 같은 시간 절감 효과가 발생한다는 의미는 아니다.
모델 자체가 학습되는 것은 아니다
여기서 중요한 구분이 있다.
AWS는 이번 시스템을 Self-Improving(자기 개선) 문서 처리 시스템이라고 설명한다.
하지만 매번 문서를 처리할 때 언어모델의 가중치를 다시 학습시키는 것은 아니다.
실제로 저장하고 개선하는 것은 문서 추출에 사용하는 지침과 처리 방법이다.
예를 들어 특정 거래처의 상품 코드 변환 규칙을 학습했다면 해당 규칙을 다음 요청에서 재사용하는 것이다.
모델의 파라미터를 변경하지 않더라도 외부 저장소에 축적된 실행 경험을 통해 시스템의 성능을 개선할 수 있다는 접근이다.
이는 최근 AI 에이전트에서 중요하게 다뤄지는 장기 기억과도 연결된다.
에이전트가 이전에 처리한 문제의 해결 방법을 저장해 비슷한 문제가 발생했을 때 다시 활용하는 것이다.
일반적인 프로그램이 결과를 검증해야 한다
AWS는 모든 검증을 언어모델에게 맡기지 않았다.
문서의 JSON 구조와 상품 코드, 금액 계산과 거래처 정보는 일반적인 프로그램 코드와 데이터베이스를 통해 확인한다.
이는 중요한 설계 선택이다.
LLM은 문서의 의미를 이해하고 다양한 표현을 처리하는 데 유용하다.
하지만 정해진 상품 코드 규칙이나 금액 계산처럼 명확한 정답이 있는 작업은 일반적인 프로그램으로 검증하는 편이 더 안정적일 수 있다.
AWS는 실제 시스템에서 Amazon Aurora DSQL을 이용해 기준 데이터를 관리하고, AWS Lambda를 이용해 검증 함수를 실행한다.
외부 도구 연결에는 MCP(Model Context Protocol)를 사용한다.
또한 실제 운영에서는 문서에 포함된 개인정보나 민감한 계약 정보를 보호할 수 있도록 접근권한과 실행 기록을 관리해야 한다고 설명한다.
비용과 한계
AWS는 샘플 아키텍처의 예상 운영 비용도 공개했다.
미국 동부 리전에서 매달 10개의 학습용 문서와 1,000개의 일반 문서를 처리하는 조건에서는 약 58달러의 월간 비용을 예상했다.
이 가운데 상당 부분은 모델 추론 비용이다.
다만 이는 샘플 모델과 서비스 구성, 처리량을 기준으로 계산한 예상 비용이다.
실제 기업의 문서가 더 복잡하거나 모델 호출 횟수가 많다면 비용이 증가할 수 있다.
또한 샘플에서 사용하는 데이터와 업무 규칙은 가상의 기업을 기준으로 만들어졌다.
실제 서비스에 적용하려면 조직의 문서 구조와 데이터 검증 규칙을 별도로 구현해야 한다.
이번 글은 AI 에이전트가 단순히 문서에서 정보를 추출하는 역할에서 나아가 실패한 작업의 원인을 분석하고, 성공한 처리 방법을 저장해 다음 업무에 재사용하는 구조를 이해하는 데 유용하다.
특히 기업용 AI 서비스를 개발할 때 모델의 추론 능력과 일반적인 소프트웨어 검증, 장기 기억을 어떻게 결합할 수 있는지 구체적인 구현 사례를 제공한다.