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

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

---

1️⃣ 주요 모델·연구

Google, 우주에 배치한 데이터센터급 TPU에서 첫 AI 응답 생성 성공…Gemma 4 실행으로 우주 AI 컴퓨팅 가능성 검증

• 발표일: 2026-10-30 — 정확한 게시 시각 미확인
• 적용 범위: AI 반도체, 우주 컴퓨팅, TPU, 온디바이스 AI, 분산 AI 인프라, 하드웨어 신뢰성 연구
• 원문: Google Research — We've received our first response from the Project Suncatcher prototype satellite

Google이 우주에 배치한 데이터센터급 TPU에서 실제 생성형 AI 모델을 실행하고, 지구에서 보낸 질문에 대한 응답을 성공적으로 수신했다고 발표했다.

이번 발표는 새로운 AI 모델의 출시가 아니다.

지구의 데이터센터에서 사용하던 종류의 AI 가속기를 실제 인공위성에 탑재해 모델 추론을 수행했다는 실험적 성과다.

Google은 이를 Project Suncatcher의 첫 번째 중요한 기술 검증 단계라고 설명했다.

Project Suncatcher는 우주 환경에서 AI 계산을 수행하는 장기 연구 프로젝트다.

현재 AI 인프라의 대부분은 지상의 데이터센터에 구축돼 있다.

데이터센터에는 대량의 전력과 냉각 설비, 고속 네트워크가 필요하다.

AI 모델의 규모가 증가하고 사용량이 늘어나면서 이런 인프라를 어디에 어떻게 구축해야 하는지가 중요한 문제가 되고 있다.

Google은 장기적으로 우주의 태양에너지와 새로운 컴퓨팅 구조를 활용할 가능성을 연구하고 있다.

하지만 이번 실험은 우주 데이터센터의 경제성이나 에너지 효율이 입증됐다는 의미는 아니다.

아직 실제 하드웨어의 작동 가능성을 검증하는 초기 단계다.

10월 1일 발사한 위성에서 실제 모델 실행

Google은 2026년 10월 1일 Project Suncatcher의 시제품 위성을 발사했다.

발사 이후 연구팀은 위성에 탑재된 장비를 단계적으로 가동하고 검사했다.

이 과정을 Commissioning(초기 가동 및 성능 확인)이라고 한다.

새로운 장비를 설치한 뒤 실제 운영에 앞서 전력 공급과 통신, 주요 기능이 정상적으로 작동하는지 확인하는 절차다.

이번 실험에서는 위성에 탑재된 호스트 컴퓨터와 TPU 모듈의 전원을 켰다.

이후 초기 머신러닝 작업을 실행해 실제 연산이 가능한지 확인했다.

Google은 10월 30일 발표에서 이번 주에 데이터센터급 TPU를 이용한 첫 번째 AI 응답 생성에 성공했다고 밝혔다.

TPU는 Tensor Processing Unit의 약자로, Google이 신경망의 행렬 연산을 효율적으로 처리하도록 설계한 AI 가속기다.

일반적인 CPU가 다양한 작업을 범용적으로 수행하도록 만들어졌다면, TPU는 머신러닝에서 반복적으로 사용되는 대규모 행렬 계산에 특화돼 있다.

지구에서 질문을 보내고 위성에서 답변 생성

연구팀은 지상의 통신 시설을 이용해 위성에 프롬프트를 전달했다.

Prompt(프롬프트)는 AI 모델에게 전달하는 질문이나 작업 지시를 의미한다.

위성에서 실행한 모델은 Google의 오픈 모델 계열인 Gemma 4였다.

연구팀은 모델에게 우주에 관한 하이쿠를 작성하도록 요청했다.

하이쿠는 짧은 시 형식이다.

위성은 전달된 프롬프트를 처리하고 새로운 시를 생성했다.

이후 위성이 노르웨이의 스발바르 지역 상공을 지나는 동안 지상으로 응답을 전송했다.

Google은 이 응답이 우주에 있는 데이터센터급 TPU에서 생성된 첫 AI 응답이라고 설명했다.

연구팀은 이후 우주에 관한 다른 시 형식과 시스템 상태를 설명하는 텔레메트리 질문도 시험했다.

Telemetry(텔레메트리)는 장비의 온도와 전력, 동작 상태처럼 운영 상황을 파악하기 위해 수집하는 측정 정보를 의미한다.

따라서 이번 실험은 단순히 미리 저장한 문장을 위성에서 재생한 것과 다르다.

지구에서 새로운 입력을 전달하고 위성의 AI 모델이 이를 처리한 뒤 결과를 다시 지구로 보낸 과정이다.

우주에서 AI를 실행하려면 해결해야 할 문제

이번 성과가 중요한 이유는 우주 환경이 일반적인 데이터센터와 크게 다르기 때문이다.

첫 번째 문제는 온도다.

지상의 데이터센터는 냉각 설비를 이용해 서버와 GPU의 온도를 관리한다.

반면 우주에서는 장비의 위치와 태양광 노출, 방열 구조에 따라 온도가 크게 달라질 수 있다.

두 번째는 방사선이다.

우주에는 지상보다 높은 수준의 방사선이 존재할 수 있다.

방사선은 반도체 내부의 데이터나 계산 결과에 오류를 발생시킬 가능성이 있다.

예를 들어 메모리에 저장된 비트가 예상하지 못하게 변경될 수 있다.

이를 Single-Event Upset(단일 입자에 의한 비트 오류)과 같은 현상으로 설명할 수 있다.

AI 모델에서는 가중치와 중간 계산 결과가 정확하게 유지돼야 한다.

따라서 방사선 환경에서 장기간 실행했을 때 오류가 얼마나 발생하는지 확인해야 한다.

세 번째는 통신이다.

지상의 데이터센터는 고속 네트워크를 통해 서버 사이에 대량의 데이터를 전달할 수 있다.

반면 위성과 지상 사이의 통신은 위성의 위치와 통신 시설의 가시 범위에 영향을 받는다.

특히 여러 위성을 연결해 하나의 AI 작업을 수행하려면 안정적인 위성 간 데이터 전송 기술이 필요하다.

2027년에는 위성 두 대를 연결하는 실험 계획

Google은 앞으로 TPU의 우주 환경 안정성을 더 자세하게 시험할 계획이다.

주요 검증 대상에는 온도 변화와 방사선 노출이 포함된다.

이후 2027년에는 서로 연결된 두 개의 위성을 이용하는 실험을 목표로 하고 있다.

이 단계에서는 하나의 위성에서 모델을 실행하는 것뿐 아니라 서로 다른 우주 컴퓨팅 장치가 데이터를 교환하는 구조도 검토할 수 있다.

하지만 이번 발표에서 위성 두 대를 이용한 분산 학습이나 대규모 추론이 이미 성공했다고 밝힌 것은 아니다.

또한 실제 상용 우주 데이터센터의 구축 일정이나 비용, 지상 데이터센터 대비 전력 효율도 검증 결과로 제시되지 않았다.

현재까지 확인된 성과는 실제 궤도에 있는 TPU에서 생성형 AI 추론을 수행하고 지상으로 결과를 전송하는 과정이 정상적으로 작동했다는 사실이다.

이번 연구는 AI 인프라의 발전이 반도체의 성능 경쟁을 넘어 계산 장치를 어디에 배치하고 어떤 극한 환경에서 운영할 수 있는지 탐색하는 방향으로 확대되고 있음을 보여준다.

---

2️⃣ AI 제품·서비스

에스티 로더·Microsoft, 전 세계 1만4천 명 이상에게 Copilot 확대…브랜드·고객·제조 데이터를 연결하는 기업 AI 플랫폼 구축

• 발표일: 2026-10-30 — 정확한 게시 시각 미확인
• 적용 범위: 기업용 생성형 AI, Microsoft Copilot, 고객 데이터 플랫폼, AI 에이전트, 제품 개발, 제조·공급망 자동화
• 원문: The Estée Lauder Companies — Strategic Partnership with Microsoft

글로벌 화장품 기업 에스티 로더 그룹(The Estée Lauder Companies)이 Microsoft와 새로운 전략적 협력을 발표했다.

이번 발표는 일반 소비자를 위한 새로운 AI 서비스가 출시됐다는 의미는 아니다.

대기업이 여러 브랜드와 지역, 업무 부서에 흩어져 있는 데이터를 연결하고, 이를 기반으로 생성형 AI와 업무 자동화를 확대하는 사례다.

에스티 로더 그룹은 에스티 로더와 크리니크, M·A·C, 라 메르, 조 말론 런던 등 여러 브랜드를 운영한다.

이처럼 여러 브랜드를 운영하는 기업에서는 데이터가 서로 다른 시스템에 저장되는 문제가 발생할 수 있다.

예를 들어 고객의 구매 기록은 전자상거래 시스템에 존재할 수 있다.

상품의 성분과 개발 이력은 연구개발 시스템에 저장돼 있을 수 있다.

제조 일정과 재고정보는 또 다른 업무 시스템에 존재할 수 있다.

이런 데이터를 AI에 연결하려면 모델 자체의 성능뿐 아니라 서로 다른 시스템에 저장된 정보를 일관된 방식으로 관리하는 구조가 필요하다.

1만4천 명 이상의 사무직 직원에게 Copilot 제공

이번 발표에서 이미 진행된 성과 가운데 하나는 Microsoft Copilot의 내부 도입 확대다.

에스티 로더 그룹은 전 세계 1만4천 명 이상의 사무직 직원에게 Copilot 접근권한을 제공했다고 밝혔다.

Copilot은 문서 작성과 자료 요약, 이메일과 회의 업무 등에서 AI 기능을 제공하는 Microsoft의 제품 계열이다.

기업은 이를 이용해 반복적인 문서 작업이나 정보 검색을 지원할 수 있다.

예를 들어 글로벌 마케팅 담당자는 서로 다른 지역의 판매 자료를 요약하거나 회의 기록을 정리할 수 있다.

제품 개발 담당자는 여러 프로젝트의 진행 상황을 조사할 수 있다.

하지만 1만4천 명에게 접근권한이 제공됐다는 사실과 1만4천 명이 매일 AI를 적극적으로 사용한다는 사실은 다르다.

실제 활성 사용자 수와 사용량, 작업 시간의 감소는 이번 발표에서 구체적으로 제시되지 않았다.

또한 회사는 직원들이 더 복잡한 업무를 수행하는 생산성 에이전트를 시험하고 있다고 설명했다.

이는 일부 직원이 실제로 에이전트를 실험하고 있다는 의미이지, 모든 업무 자동화 기능이 이미 전사적으로 배포됐다는 뜻은 아니다.

브랜드와 지역을 연결하는 Unified Data Platform

이번 협력의 핵심 기술 가운데 하나는 Unified Data Platform(통합 데이터 플랫폼)이다.

통합 데이터 플랫폼은 서로 다른 시스템에 저장된 정보를 일관된 구조로 연결하고 활용하도록 만드는 환경이다.

예를 들어 회사의 여러 브랜드가 고객 데이터를 각자 다른 기준으로 관리하고 있다고 가정해 보자.

어떤 브랜드는 국가별로 데이터를 구분한다.

다른 브랜드는 온라인과 오프라인 판매 채널을 중심으로 정보를 관리할 수 있다.

이런 구조에서는 그룹 전체의 데이터를 일관되게 분석하기 어렵다.

에스티 로더와 Microsoft는 브랜드와 지역, 판매 채널과 업무 기능에 걸쳐 데이터를 연결하는 기반을 강화할 계획이다.

여기에는 고객 데이터뿐 아니라 제품 관련 정보도 포함된다.

예를 들어 고객의 선호와 구매 패턴을 분석할 때 실제로 어떤 상품이 판매되고 있는지, 해당 상품의 특징과 공급 상황은 어떤지 함께 참고할 수 있다.

그러나 데이터를 통합한다는 사실만으로 모든 직원이나 AI 에이전트가 모든 고객정보를 자유롭게 열람할 수 있다는 의미는 아니다.

기업은 데이터의 성격과 사용자 역할에 따라 접근권한을 관리해야 한다.

특히 고객의 개인정보와 구매 기록을 분석할 때는 해당 지역의 개인정보 보호 규정을 함께 고려해야 한다.

제품 개발부터 제조까지 AI 연결

에스티 로더는 AI 적용 범위를 일반적인 사무 업무에만 한정하지 않고 있다.

회사는 제품의 기획과 설계, 검증, 제조를 하나의 연결된 업무 흐름으로 관리하는 방안을 개발하고 있다.

예를 들어 새로운 화장품을 개발하는 과정에서는 소비자의 요구사항을 조사하고 제품의 성분과 품질을 검증해야 한다.

이후 생산 가능성을 확인하고 실제 제조 일정을 계획한다.

각 단계에서 사용하는 데이터와 담당 부서가 다를 수 있다.

AI가 이런 업무를 지원하려면 단순히 제품에 관한 설명을 생성하는 것보다 실제 연구개발과 제조 시스템의 데이터를 연결하는 기능이 필요하다.

에스티 로더는 이를 통해 제품 아이디어를 실제 판매 가능한 상품으로 만드는 과정을 개선하려 한다.

다만 이번 발표는 이러한 통합 업무 흐름의 개발 방향을 설명한 것이다.

새로운 AI 기반 제조 시스템이 모든 공장에서 정식으로 운영되고 있다는 의미는 아니다.

또한 신제품 개발 기간이 몇 퍼센트 단축됐는지, 제조 비용이 얼마나 감소했는지에 대한 독립적인 측정 결과도 제시되지 않았다.

기업용 AI에서 데이터 품질이 중요한 이유

이 사례는 기업용 생성형 AI를 실제 업무에 적용할 때 자주 발생하는 문제와 연결된다.

언어모델은 자연어를 이해하고 문서를 작성하는 데 뛰어날 수 있다.

하지만 회사가 실제로 사용하는 재고와 고객, 제조 데이터를 모른다면 현재 상황에 맞는 판단을 내리기 어렵다.

또한 서로 다른 부서가 같은 지표를 다른 기준으로 계산한다면 AI가 잘못된 정보를 조합할 수 있다.

따라서 기업용 AI의 품질은 모델 자체의 성능뿐 아니라 연결된 데이터가 얼마나 정확하고 최신 상태이며, 업무에 필요한 의미를 제대로 표현하는지에도 영향을 받는다.

이번 발표는 대기업의 AI 도입이 일부 직원에게 챗봇을 제공하는 단계에서 벗어나 회사 전체의 데이터를 연결하고 실제 업무 절차를 재설계하는 방향으로 확대되고 있음을 보여준다.

---

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

NVIDIA, GPU·스토리지 연결 상태를 분석하는 오픈소스 ‘gds-diag’ 공개…Claude·Codex용 진단 Skill도 제공

• 발표일: 2026-10-30 — 정확한 게시 시각 미확인
• 적용 범위: AI 인프라, GPU 스토리지, GPUDirect Storage, Python CLI, AI 코딩 에이전트, 시스템 진단, 오픈소스
• 원문: NVIDIA — How to Check and Configure NVIDIA GPUDirect Storage for Your Platform
• 관련 원문: GitHub — NVIDIA Magnum IO

NVIDIA가 GPU와 저장장치 사이의 데이터 전송 환경을 검사하는 오픈소스 명령줄 도구 gds-diag를 공개했다.

이번 발표의 핵심은 GPUDirect Storage라는 기술 자체가 처음 등장했다는 사실이 아니다.

이미 존재하던 고속 GPU 데이터 전송 기술을 실제 서버에서 올바르게 사용하고 있는지 확인하는 진단 도구와 AI 에이전트용 Skill이 제공됐다는 점이다.

AI 모델을 학습하거나 실행할 때는 GPU의 연산 성능이 중요하다.

하지만 GPU가 실제로 계산을 수행하려면 필요한 데이터가 제때 전달돼야 한다.

예를 들어 대규모 이미지 데이터를 이용해 모델을 학습한다고 가정해 보자.

GPU는 저장장치에서 이미지 데이터를 읽어와 모델의 계산을 수행한다.

그런데 데이터 전송이 느리면 GPU가 다음 데이터를 기다리는 시간이 발생할 수 있다.

이 경우 더 빠른 GPU를 사용하더라도 전체 학습 속도가 기대만큼 개선되지 않을 수 있다.

CPU 메모리를 거치지 않는 데이터 전송

일반적인 시스템에서는 저장장치의 데이터를 CPU가 사용하는 메모리로 읽어온 뒤 GPU 메모리로 복사하는 방식이 사용될 수 있다.

하지만 이런 과정에서는 중간 복사가 발생한다.

GPUDirect Storage(GDS)는 지원되는 환경에서 저장장치와 GPU 사이의 데이터 이동을 더 효율적으로 처리하도록 만든 NVIDIA의 기술이다.

예를 들어 일부 조건에서는 CPU 메모리를 거치는 불필요한 데이터 복사 과정을 줄일 수 있다.

이를 통해 CPU 사용량과 데이터 전송 지연을 줄이는 효과를 기대할 수 있다.

하지만 GDS를 설치했다는 사실만으로 항상 최적화된 데이터 경로가 사용되는 것은 아니다.

GPU와 저장장치의 종류, 파일시스템과 드라이버, 실제 서버의 연결 구조에 따라 다른 경로가 사용될 수 있다.

또한 GDS가 지원되지 않는 환경에서는 일반적인 데이터 전송 경로로 돌아갈 수 있다.

이런 동작을 Fallback(대체 실행 경로)이라고 한다.

문제는 프로그램이 정상적으로 실행되더라도 실제로는 최적화된 경로를 사용하지 않을 수 있다는 것이다.

따라서 성능 문제를 진단하려면 현재 시스템에서 어떤 경로가 사용되는지 확인해야 한다.

gds-diag의 주요 진단 기능

gds-diag는 이런 문제를 확인하기 위한 Python 기반 CLI 도구다.

CLI(Command-Line Interface)는 명령어를 입력해 프로그램을 실행하고 조작하는 인터페이스다.

NVIDIA는 도구를 하나의 Python 스크립트로 제공한다.

주요 기능은 다음과 같다.

이 도구는 물리 서버뿐 아니라 가상 머신과 컨테이너 환경도 검사할 수 있도록 설계됐다.

예를 들어 Kubernetes에서 AI 학습 프로그램을 실행하는 경우를 생각할 수 있다.

컨테이너 내부에서 GPU가 정상적으로 인식되더라도 GDS에 필요한 일부 장치와 드라이버 접근이 제한돼 있을 수 있다.

이런 경우 학습 프로그램은 실행되지만 기대했던 고속 데이터 전송 경로를 사용하지 못할 수 있다.

gds-diag의 container-check는 관련 구성을 조사하도록 만들어졌다.

실패 원인과 개선 방법을 함께 표시

gds-diag는 진단 결과를 네 가지 상태로 표시한다.

FAIL은 정상적인 사용을 막는 문제가 발견됐다는 의미다.

WARN은 잠재적인 문제가 존재한다는 의미다.

INFO는 참고할 만한 시스템 정보를 제공한다.

PASS는 해당 검사에서 문제가 발견되지 않았다는 의미다.

각 결과에는 문제에 관한 설명과 가능한 개선 방법이 포함된다.

예를 들어 특정 파일시스템 구성이 GDS의 직접 데이터 전송을 지원하지 않는다면 관련 제한을 설명할 수 있다.

또한 결과를 JSON 형식으로 출력할 수 있다.

JSON(JavaScript Object Notation)은 프로그램 사이에서 구조화된 데이터를 교환할 때 널리 사용하는 형식이다.

이를 이용하면 시스템 운영자가 진단 결과를 다른 모니터링 프로그램에 전달하거나 기록으로 보관할 수 있다.

중요한 점은 gds-diag가 기본적으로 시스템을 자동 수정하는 도구가 아니라는 사실이다.

진단 결과와 가능한 개선 방법을 제공하지만 실제 설정 변경은 관리자나 별도의 자동화가 수행해야 한다.

Claude와 Codex에서 자연어로 진단

이번 공개에는 선택적으로 사용할 수 있는 Agent Skill(에이전트 스킬)도 포함됐다.

Skill은 AI 에이전트가 특정 작업을 수행하는 데 필요한 지침과 실행 방법을 묶은 구성요소다.

NVIDIA는 Claude와 Codex에서 이 Skill을 검증했다고 밝혔다.

예를 들어 관리자가 현재 서버에서 GDS를 사용할 수 없는 이유를 자연어로 질문할 수 있다.

에이전트는 필요한 진단 명령을 선택하고 실행한다.

이후 반환된 결과를 분석해 가능한 원인과 수정 방법을 설명할 수 있다.

이 구조에서는 두 종류의 역할이 분리된다.

실제 하드웨어와 소프트웨어 상태를 확인하는 작업은 결정적인 진단 프로그램이 수행한다.

반면 어떤 검사를 실행하고 결과를 어떻게 해석할지는 언어모델 기반 에이전트가 지원한다.

이는 AI 에이전트가 모든 판단을 직접 수행하도록 만드는 것보다 결과를 재현하고 검증하기 쉬운 구조다.

다만 에이전트가 시스템 설정을 변경하도록 허용할 경우에는 별도의 접근권한과 승인 절차가 필요하다.

잘못된 드라이버 설정이나 저장장치 구성 변경은 실제 학습 작업의 실행에 영향을 줄 수 있기 때문이다.

지원 환경과 실제 성능의 한계

gds-diag 자체는 Python 3.8 이상의 Linux 환경에서 사용할 수 있도록 설계됐다.

실제 GPUDirect Storage를 사용하려면 지원되는 NVIDIA 데이터센터급 GPU와 CUDA Toolkit 등의 조건이 필요하다.

NVIDIA는 CUDA Toolkit 12.2 이상을 관련 요구사항으로 제시했다.

하지만 진단 도구가 설치된다고 해서 모든 GPU가 GDS를 사용할 수 있는 것은 아니다.

또한 이번 발표에서는 gds-diag를 설치하면 AI 모델의 학습 속도가 몇 퍼센트 개선된다는 종합적인 성능 수치를 제시하지 않았다.

이 도구의 직접적인 목적은 GPU의 계산을 가속하는 것이 아니라 성능을 제한하는 잘못된 데이터 전송 설정을 찾아내는 것이다.

이번 공개는 AI 인프라의 운영에서도 AI 에이전트가 실제 시스템 진단을 지원하는 방향으로 활용되고 있음을 보여준다.

특히 정확한 상태 확인은 기존 프로그램이 담당하고, 에이전트는 검사 절차의 선택과 결과 해석을 지원하는 방식은 다른 종류의 서버 운영 자동화에도 적용할 수 있는 설계다.

---

4️⃣ 산업·정책·안전

Anthropic 연구자가 제출한 AI 학습 거부 신호 초안 공개…OpenAI도 공통 robots.txt 규칙 도입 계획 발표

• 발표일: 2026-10-30 — 정확한 게시 시각 미확인
• 적용 범위: AI 학습 데이터, 웹 콘텐츠 저작권, robots.txt, IETF, 웹 크롤러, 콘텐츠 이용 정책, AI 거버넌스
• 원문: IETF — Machine-Readable Training Preference Signal
• 관련 원문: OpenAI — Making it easier for websites to express AI training preferences

웹사이트 운영자가 자신의 콘텐츠를 생성형 AI 학습에 사용하도록 허용하거나 제한하는 의사를 여러 AI 기업에 공통으로 전달하기 위한 새로운 기술 초안이 공개됐다.

이번 제안은 Anthropic 소속 Kevin Kelley가 IETF에 제출한 문서다.

IETF(Internet Engineering Task Force)는 인터넷에서 사용하는 통신 규격과 기술 표준을 논의하는 국제 기술 커뮤니티다.

같은 날 OpenAI도 새로운 공통 신호를 지원할 계획이라고 발표했다.

이번 발표의 핵심은 AI 기업이 웹사이트의 콘텐츠 사용 의사를 확인하는 방법을 단순화하려는 것이다.

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

이번에 공개된 문서는 IETF에서 승인된 최종 표준이 아니라 개인이 제출한 Internet-Draft 초안이다.

IETF 자체가 이를 공식 기술 표준으로 승인했다는 의미는 아니다.

또한 새로운 국제 저작권법이 만들어진 것도 아니다.

기존 robots.txt의 문제

웹사이트 운영자는 일반적으로 robots.txt 파일을 이용해 자동화된 크롤러의 접근에 관한 의사를 표시할 수 있다.

Crawler(크롤러)는 웹사이트를 자동으로 방문해 페이지를 읽고 수집하는 프로그램이다.

예를 들어 검색엔진은 크롤러를 이용해 웹페이지를 분석하고 검색 결과에 반영할 수 있다.

기존 robots.txt에서는 크롤러를 식별하는 이름과 접근 가능한 경로를 지정한다.

하지만 생성형 AI 서비스가 증가하면서 웹사이트 운영자가 관리해야 할 크롤러도 많아졌다.

예를 들어 특정한 웹사이트가 일반 검색엔진의 수집은 허용하면서 생성형 AI의 학습에는 콘텐츠를 사용하지 않기를 원할 수 있다.

이 경우 AI 제공업체마다 다른 크롤러 이름을 확인하고 별도의 규칙을 관리해야 할 수 있다.

또한 새로운 AI 제공업체가 등장할 때마다 규칙을 추가해야 하는 부담이 생긴다.

이번 초안은 이런 문제를 해결하려 한다.

회사별 크롤러 대신 사용 목적을 표시

제안된 방식에서는 특정한 회사의 크롤러 이름 대신 콘텐츠 사용 목적을 나타내는 공통 토큰을 사용한다.

초안에서 정의한 토큰은 다음과 같다.

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

이 설정은 사이트 전체의 콘텐츠를 AI 학습에 사용하지 않기를 원하지만 /press-kit/ 아래의 자료에 대해서는 다른 의사를 표시하는 예시다.

여기서 Disallow는 해당 경로에 대한 제한 의사를 나타낸다.

Allow는 예외적으로 허용하는 경로를 지정한다.

중요한 점은 기존 robots.txt 문법을 크게 변경하지 않는다는 것이다.

이번 제안은 새로운 명령어나 파일 형식을 만드는 대신 기존의 User-Agent, Allow, Disallow 구조를 재사용한다.

따라서 웹사이트 운영자는 기존과 비슷한 방식으로 규칙을 작성할 수 있다.

다만 __usage_ai-training은 실제 웹 크롤러의 이름을 나타내는 것이 아니다.

AI 학습에 관한 콘텐츠 사용 의사를 표현하기 위한 정책 토큰이다.

크롤링 허용과 AI 학습 허용은 다른 문제

이번 초안에서 특히 중요한 부분은 웹페이지에 접근하는 행위와 수집한 콘텐츠를 AI 학습에 사용하는 행위를 구분한다는 점이다.

예를 들어 어떤 웹사이트가 검색엔진의 크롤러 접근을 허용한다고 가정해 보자.

해당 콘텐츠를 일반 검색 결과에 표시하는 것은 허용할 수 있다.

하지만 같은 콘텐츠를 대규모 생성형 AI 모델의 학습 데이터로 사용하는 것에는 동의하지 않을 수 있다.

반대로 콘텐츠의 AI 학습은 허용하지만 일부 민감한 웹 경로의 접근은 차단하려 할 수도 있다.

따라서 하나의 robots.txt 규칙으로 모든 콘텐츠 사용 목적을 표현하기는 어렵다.

이번 제안은 AI 학습에 관한 선호를 일반적인 크롤러 접근 정책과 독립적으로 표시하도록 만든 것이다.

이런 구조는 뉴스와 출판, 기술 문서와 같은 콘텐츠를 제공하는 웹사이트에 유용할 수 있다.

예를 들어 사이트 운영자는 웹페이지의 검색 노출을 유지하면서 AI 학습에 관한 의사를 별도로 표현할 수 있다.

OpenAI는 향후 수개월 동안 구현할 계획

OpenAI는 이번 공통 신호를 존중할 계획이라고 밝혔다.

하지만 10월 30일에 이미 모든 OpenAI 크롤러가 새로운 신호를 처리하기 시작했다는 의미는 아니다.

OpenAI는 앞으로 수개월 동안 관련 기능을 구현하고 구체적인 운영 방식을 다시 안내하겠다고 설명했다.

또한 기존에 제공하던 robots.txt 기반의 크롤러 제어 기능도 계속 유지한다고 밝혔다.

따라서 현재 사용 중인 웹사이트 운영자가 기존 크롤러 설정을 즉시 제거해야 하는 것은 아니다.

새로운 공통 신호가 실제로 어느 기업에 적용되는지는 각 제공업체의 구현 상태를 확인해야 한다.

자발적인 신호이며 법적 강제력은 별개

이번 제안이 해결하지 못하는 문제도 있다.

첫 번째는 신호의 준수 여부다.

robots.txt에 사용 제한 의사를 표시하더라도 이를 존중하지 않는 크롤러가 존재할 수 있다.

제안된 공통 신호 자체가 모든 인터넷 프로그램의 접근을 기술적으로 차단하는 장치는 아니다.

두 번째는 저작권과 라이선스 문제다.

어떤 콘텐츠의 학습 사용이 법적으로 허용되는지는 국가별 법률과 계약, 실제 사용 방식 등에 따라 달라질 수 있다.

따라서 robots.txt의 신호만으로 모든 저작권 분쟁이 해결되는 것은 아니다.

세 번째는 기존에 이미 수집된 자료의 처리다.

새로운 신호를 추가했다고 해서 과거에 수집된 모든 데이터가 자동으로 삭제되거나 학습된 모델의 가중치에서 제거된다는 보장은 없다.

또한 이번 초안에는 웹사이트 운영자의 선호를 보다 쉽게 전달하는 기술적 방법이 제시돼 있지만, 콘텐츠 사용에 관한 모든 권리 관계를 검증하는 절차까지 포함된 것은 아니다.

이번 발표는 생성형 AI와 웹 생태계 사이의 관계가 변화하고 있음을 보여준다.

웹페이지를 기술적으로 수집할 수 있는가라는 문제에서, 수집한 콘텐츠를 어떤 목적으로 사용할 수 있는가라는 문제로 논의가 확대되고 있다.

---

Google·Mandiant, 실제 침해 사고에 사용된 AI 공격 에이전트 조사…23초 동안 27개 행동 수행한 사례 확인

• 발표일: 2026-10-30 — 정확한 게시 시각 미확인
• 적용 범위: AI 사이버보안, 에이전트 악용, 실제 침해 사고 분석, 기업 보안, 클라우드 접근권한, 위협 인텔리전스
• 원문: Google Threat Intelligence Group·Mandiant — ARTEX and Friends: Enter Agentic Offensive Frameworks

Google Threat Intelligence Group과 Mandiant가 실제 사이버 침해 사고에서 사용된 AI 기반 공격 프레임워크를 조사한 결과를 공개했다.

이번 보고서의 중요한 특징은 AI가 공격에 사용될 수 있다는 가능성을 연구실에서 시뮬레이션한 결과가 아니라 실제 침해 사고 대응 과정에서 관찰한 행동을 분석했다는 점이다.

조사 대상에는 ARTEX와 Hexstrike, CAIRN 등의 에이전트형 보안 도구가 포함됐다.

이 도구들은 정상적인 보안 연구나 시스템 점검에도 활용될 수 있다.

하지만 공격자가 허용되지 않은 시스템에 사용하면 실제 침해를 자동화하는 수단이 될 수 있다.

Google은 2026년 8월 말부터 이러한 도구를 악용하는 사례를 확인했다고 설명했다.

따라서 보고서에 등장하는 공격이 모두 10월 30일에 발생한 것은 아니다.

10월 30일의 새로운 발표는 여러 실제 침해 사고에 대한 분석 결과와 공통적인 공격 패턴을 공개한 것이다.

AI 에이전트가 공격에 사용되는 방식

기존의 사이버 공격에서는 사람이 여러 도구를 직접 실행하는 경우가 많았다.

예를 들어 공격자가 특정 시스템에 접근한 뒤 어떤 계정과 서버에 접근할 수 있는지 확인할 수 있다.

이후 다른 서버로 이동하거나 추가적인 권한을 확보하려 시도할 수 있다.

이런 과정에서는 공격자가 명령을 실행하고 결과를 확인한 뒤 다음 행동을 결정한다.

반면 AI 에이전트형 도구는 이런 반복적인 작업의 일부를 자동화할 수 있다.

AI Agent(에이전트)는 주어진 목표를 달성하기 위해 외부 도구를 선택하고 여러 단계의 행동을 수행하도록 구성된 AI 시스템이다.

예를 들어 특정한 명령이 실패하면 오류 메시지를 분석하고 다른 접근을 시도할 수 있다.

또한 수집된 정보를 바탕으로 다음에 조사할 시스템을 결정할 수 있다.

하지만 이번 보고서에서 확인된 공격이 모두 사람의 개입 없이 완전히 자율적으로 수행됐다는 의미는 아니다.

Google은 실제 공격자가 목표와 인증정보를 제공하고 에이전트가 후속 작업을 수행하도록 한 사례를 확인했다.

즉 공격자의 판단과 AI 기반 자동화가 결합된 형태였다.

미국과 유럽의 여러 산업에서 실제 침해 관찰

Google과 Mandiant는 여러 공격자가 ARTEX를 사용한 사례를 조사했다.

확인된 활동에는 금전적인 이익을 목적으로 하는 공격과 사이버 첩보 활동이 의심되는 사례가 포함됐다.

Wiz가 함께 추적한 일부 공격에서는 미국과 유럽의 여러 조직이 영향을 받았다.

대상 산업에는 기업용 소프트웨어와 산업 자동화, 반도체 제조·설계, 통신 분야 등이 포함됐다.

Google은 정부와 기술, 화학·소재와 제조 분야에서도 관련 활동을 관찰했다고 설명했다.

다만 모든 피해가 동일한 공격자에 의해 발생한 것은 아니다.

또한 여러 공격에서 같은 오픈소스 도구가 사용됐다는 사실만으로 공격자들의 조직적 연관성이 확정되는 것은 아니다.

계정 침해 이후 4시간, 빠른 경우 15분

Google은 일부 공격에서 최초로 침해된 계정이 사용된 시점부터 더 깊은 시스템 접근에 도달하기까지 걸린 시간을 분석했다.

관련 캠페인에서는 일반적으로 약 4시간이 걸렸다.

일부 사례에서는 15분 만에 더 깊은 접근이 이뤄졌다.

이 결과는 공격자가 이미 확보한 계정을 이용하는 상황에서 측정된 것이다.

따라서 AI가 인터넷에 존재하는 아무 시스템이나 15분 만에 완전히 침해할 수 있다는 의미는 아니다.

또한 최초 계정을 확보하기까지 걸린 시간은 별도로 고려해야 한다.

하지만 이미 유효한 인증정보가 노출된 상태라면 이후 침해가 매우 빠르게 진행될 수 있다는 점을 보여준다.

23초 동안 27개 행동 수행

보고서에서는 자동화된 행동이 사람의 일반적인 작업 속도와 어떻게 다른지도 설명했다.

한 사례에서는 약 23초 동안 27개의 행동이 기록됐다.

이 행동들은 AWS 환경의 여러 보안 설정과 접근 가능성을 빠르게 조사하는 과정에서 발생했다.

다른 사례에서는 하나의 프로그램 실행 과정에서 240개 이상의 로그 이벤트가 발생했다.

에이전트는 실행 오류가 발생한 뒤 접근 방식을 반복해서 변경했다.

이런 현상은 AI 에이전트가 실패한 결과를 받아들이고 새로운 시도를 수행할 수 있다는 점을 보여준다.

하지만 속도가 빠르다고 해서 항상 더 정교한 공격이 이뤄지는 것은 아니다.

Google은 일부 에이전트의 행동이 숙련된 공격자에 비해 상당히 많은 오류와 불필요한 실행 기록을 남겼다고 설명했다.

즉 자동화로 공격 속도는 증가했지만 행동이 오히려 더 쉽게 탐지될 가능성도 존재했다.

공격 기술보다 기존 보안 약점이 중요

이번 보고서에서 눈여겨볼 부분은 여러 공격이 완전히 새로운 취약점에만 의존하지 않았다는 사실이다.

일부 공격자는 이미 침해된 계정과 정상적인 관리 API, 잘못된 접근권한 설정 등을 활용했다.

예를 들어 정상적인 사용자에게 지나치게 넓은 클라우드 접근권한이 부여돼 있다면 공격자는 해당 계정을 이용해 여러 자원을 조사할 수 있다.

Least Privilege(최소 권한 원칙)는 사용자나 프로그램이 자신의 업무에 필요한 권한만 가져야 한다는 보안 원칙이다.

이 원칙이 제대로 적용되지 않은 환경에서는 하나의 계정이 침해됐을 때 피해 범위가 커질 수 있다.

AI 에이전트는 이미 존재하는 잘못된 권한 설정을 더 빠르게 찾아낼 수 있다.

따라서 AI가 사용됐다는 이유만으로 기존의 보안 원칙이 무의미해지는 것은 아니다.

오히려 계정의 접근권한과 인증정보 보호, 네트워크 격리가 더 중요해질 수 있다.

실제 보안 감시 방식도 달라져야 한다

기존의 보안 감시 시스템은 특정한 명령이나 이벤트 하나가 위험한지 확인하는 데 집중할 수 있다.

하지만 AI 에이전트는 짧은 시간 동안 여러 시스템을 조사하고 다양한 행동을 연결할 수 있다.

따라서 개별 이벤트만 확인하면 전체 행동의 의미를 놓칠 수 있다.

예를 들어 하나의 계정이 평소 접근하지 않던 여러 서버를 빠르게 조회하고, 이어서 새로운 인증정보를 사용하기 시작한다면 전체 행동 패턴이 중요하다.

이를 Behavioral Detection(행동 기반 탐지)이라고 한다.

단순히 알려진 공격 코드의 문자열을 찾는 것이 아니라 실제 계정과 프로그램이 어떤 방식으로 행동하는지 분석하는 접근이다.

또한 여러 보안 이벤트를 시간 순서대로 연결해 공통적인 원인을 찾는 기술도 필요하다.

Google은 AI 기반 공격 프레임워크가 현재까지는 비교적 초기 단계에 있으며 일부 공격에서는 많은 로그와 오류가 남는다고 평가했다.

하지만 모델과 실행 도구가 발전하면 공격자가 자동화할 수 있는 작업의 범위와 정확도도 달라질 수 있다.

이번 보고서는 AI의 사이버보안 위험을 논의할 때 모델의 이론적인 공격 능력과 실제 공격자가 이를 어떻게 활용하고 있는지를 구분해서 살펴볼 필요가 있음을 보여준다.

---

OpenAI, ChatGPT의 폭력 관련 콘텐츠 제한·청소년 보호 강화 발표…2027년부터 반기별 안전 보고서 공개 계획

• 발표일: 2026-10-30 — 정확한 게시 시각 미확인
• 적용 범위: 생성형 AI 안전, 청소년 보호, 콘텐츠 정책, 위험 행동 탐지, 연령 추정, 플랫폼 거버넌스
• 원문: OpenAI — Community safety report and new protections for teens

OpenAI가 ChatGPT의 폭력 관련 콘텐츠 정책과 청소년 보호 기능을 강화하겠다고 발표했다.

이번 변경은 새로운 AI 모델을 공개한 것이 아니다.

사용자의 나이와 대화 맥락, 반복적인 위험 신호를 고려해 응답과 계정 이용을 제한하는 방식을 확대하려는 정책·제품 변경이다.

OpenAI는 이번 발표에서 두 가지 주요 계획을 소개했다.

첫 번째는 폭력과 지역사회 안전에 관한 정기 보고서를 공개하는 것이다.

두 번째는 청소년과 위험 행동이 의심되는 대화에 추가적인 보호장치를 적용하는 것이다.

다만 새로운 보호장치가 발표 당일부터 모든 사용자에게 완전히 적용된 것은 아니다.

OpenAI는 관련 기능을 향후 몇 주 동안 단계적으로 배포할 계획이라고 밝혔다.

과거의 대규모 폭력 사건에 관한 상세 정보 제한

OpenAI는 모든 사용자에게 적용되는 콘텐츠 정책을 강화할 예정이다.

기존에도 실제 폭력 행위를 계획하거나 실행하도록 돕는 지시는 금지돼 있었다.

이번 변경은 과거의 대규모 폭력 사건에 관한 정보 제공에도 추가적인 제한을 적용한다.

예를 들어 과거 사건에 사용된 무기와 장비, 이를 확보한 방법을 세부적으로 재구성하는 답변을 제한할 계획이다.

또한 피해 규모를 상세하게 비교하거나 공격자의 유명세를 높이는 방식으로 사건을 설명하는 것도 제한한다.

이러한 변경은 사용자의 나이와 질문 목적에 관계없이 적용된다.

하지만 사건 자체에 관한 모든 설명을 금지하는 것은 아니다.

예를 들어 사건이 사회에 어떤 영향을 미쳤는지, 피해자와 지역사회가 어떤 피해를 경험했는지 설명하는 것은 계속 가능하도록 한다.

또한 위험 신호를 인식하고 유사한 사건을 예방하는 데 도움이 되는 정보도 제공할 수 있다.

즉 역사적 사건의 이해와 예방에 관한 정보는 유지하면서 실제 공격을 재현하는 데 활용될 수 있는 세부 내용을 제한하려는 방향이다.

개별 질문뿐 아니라 이전 대화의 맥락 고려

이번 발표에서는 대화 맥락에 따른 위험 판단도 강조됐다.

예를 들어 어떤 질문 하나만 보면 일반적인 정보 요청처럼 보일 수 있다.

하지만 사용자가 이전 대화에서 특정한 위험 행동에 반복적으로 관심을 보였다면 같은 질문의 의미가 달라질 수 있다.

OpenAI는 최근 대화에서 확인된 위험 신호를 바탕으로 이후 질문에 더 보수적으로 대응하는 기능을 확대하려 한다.

이는 단순한 문자열 필터와 다르다.

문장 하나의 표현만 확인하는 대신 여러 대화에 걸친 행동 패턴을 고려하는 것이다.

다만 어떤 행동이 실제 위험한 의도를 나타내는지 판단하는 일에는 상당한 불확실성이 있다.

예를 들어 기자나 연구자가 위험한 사건을 반복적으로 조사하는 상황도 존재할 수 있기 때문이다.

따라서 시스템이 단순한 주제 반복과 실제 위험을 구분하는 것이 중요하다.

OpenAI는 정신건강 및 폭력 예방 전문가와 협력해 관련 기능을 개발하고 있다고 설명했다.

반복적인 위험 대화는 자동 종료 가능

OpenAI는 특정한 상황에서 ChatGPT가 대화를 자동으로 종료하는 기능도 개발하고 있다.

예를 들어 사용자가 심각한 폭력 행위에 반복적으로 집착하는 위험 신호가 나타나면 해당 대화를 중단할 수 있다.

비슷한 이유로 여러 대화가 중단된다면 계정 이용이 일시적으로 제한될 수도 있다.

다만 이번 발표는 이러한 기능을 단계적으로 도입할 계획에 관한 설명이다.

10월 30일 현재 모든 대화에서 동일한 자동 중단 기준이 적용되고 있다고 볼 수는 없다.

또한 단순히 폭력 관련 주제를 언급했다는 사실만으로 자동으로 계정이 중단된다는 의미도 아니다.

실제 위험 판단에는 대화의 내용과 맥락, 반복적인 행동 등이 고려될 수 있다.

청소년에게는 더 강한 제한 적용

OpenAI는 만 18세 미만 사용자에게 적용하는 보호 기능도 강화한다.

기존에는 청소년이 무기를 확보하거나 실제 폭력 행위를 계획하는 데 도움이 되는 정보를 제한했다.

이번 변경에서는 직접적인 폭력 의도가 확인되지 않는 질문에도 일부 제한을 확대한다.

예를 들어 무기와 보안 시스템에 관한 실용적인 정보가 실제 위험에 활용될 가능성이 있다면 더 보수적으로 응답하도록 설계한다.

다만 청소년이 위험한 상황을 예방하거나 도움을 요청하는 행동까지 제한하려는 것은 아니다.

OpenAI는 청소년이 폭력 상황에서 벗어나는 방법이나 신뢰할 수 있는 어른에게 도움을 구하는 방법에 관해서는 계속 지원한다고 설명했다.

연령 추정 시스템의 지속적인 업데이트

OpenAI는 사용자의 연령을 추정하는 시스템도 개선했다고 밝혔다.

기존에는 사용자 행동과 여러 신호를 분석해 만 18세 미만일 가능성을 평가했다.

이번 업데이트에서는 사용자가 서비스를 계속 이용하는 동안 새로운 신호를 반영하도록 했다.

즉 처음 계정을 사용할 때의 판단을 영구적으로 유지하는 대신 이후 정보를 참고해 연령 추정을 갱신하는 구조다.

하지만 연령 추정이 항상 정확한 것은 아니다.

실제 성인이 청소년으로 잘못 분류될 수 있다.

OpenAI는 이런 상황에서 별도의 신원 확인 절차를 통해 성인임을 증명하고 청소년 보호 설정을 해제할 수 있도록 한다고 설명했다.

이때 Persona라는 외부 연령 확인 서비스가 사용된다.

보호자 알림과 개인정보 문제

OpenAI는 보호자와 연결된 청소년 계정에 관한 알림 기능도 확대하려 한다.

기존에는 일부 심각한 안전 문제나 정책 위반으로 계정이 비활성화된 상황에서 보호자에게 알림을 전달할 수 있었다.

이번에는 반복적인 폭력 관련 대화로 청소년 계정의 사용이 일시 중단되는 경우에도 보호자에게 알리는 기능을 개발하고 있다.

하지만 새로운 보호자 알림 기능은 아직 도입 계획 단계다.

또한 안전을 위한 대화 분석과 개인정보 보호 사이에는 균형이 필요하다.

예를 들어 위험 신호를 탐지하기 위해 대화의 맥락을 분석하더라도 불필요한 개인정보의 처리나 공개는 제한해야 한다.

OpenAI는 이번 발표에서 이러한 문제를 지속적으로 검토하겠다고 설명했다.

2027년부터 정기적인 안전 보고서 공개

OpenAI는 Community Safety Report도 새롭게 발행할 계획이다.

첫 번째 보고서는 2027년 초 공개할 예정이다.

대상 기간은 2026년 하반기다.

이후에는 6개월마다 보고서를 발행할 계획이다.

보고서에는 위험 행동을 탐지하고 검토하는 방법과 새로운 보호장치, 익명화된 사례와 관련 통계 등이 포함될 예정이다.

OpenAI는 2026년 3분기에 잠재적인 폭력 관련 위협에 대해 200건 이상의 법 집행기관 신고·통보를 수행했다고 밝혔다.

다만 이는 OpenAI가 공개한 신고 건수다.

모든 신고가 실제로 범죄를 예방했다는 의미는 아니다.

또한 이번 발표 시점에는 첫 번째 Community Safety Report가 아직 공개되지 않았다.

따라서 정기 보고서가 실제로 어느 정도의 데이터를 제공하고 외부에서 효과를 평가할 수 있도록 할지는 향후 확인해야 한다.

이번 발표는 생성형 AI의 안전 정책이 개별 답변의 허용 여부를 판단하는 방식에서 벗어나 사용자의 연령과 반복적인 행동 패턴, 실제 사회적 위험과 외부 대응 체계를 함께 고려하는 방향으로 확대되고 있음을 보여준다.

---

📚 추천 글

From synthetic enterprise data evaluations to real Microsoft Copilot AI confidence

• 저자: Somya Chatterjee, Harshita Sahijwani 외 Microsoft Research 연구진
• 발행: Microsoft Research
• 게시일: 2026-10-30
• 원문: Microsoft Research — From synthetic enterprise data evaluations to real Microsoft Copilot AI confidence

기업용 AI를 평가하려면 어떤 종류의 테스트 데이터를 준비해야 할까?

일반적인 챗봇은 공개된 질문과 정답으로 성능을 평가할 수 있다.

예를 들어 수학 문제나 프로그래밍 문제를 해결하도록 하고 실제 정답과 비교할 수 있다.

하지만 기업용 AI 비서는 다른 종류의 정보를 처리한다.

예를 들어 사용자가 지난주 회의에서 어떤 결정을 내렸는지 질문할 수 있다.

또는 특정 프로젝트의 일정이 마지막 보고 이후 어떻게 달라졌는지 물어볼 수 있다.

이런 질문에 정확하게 답하려면 단순히 일반적인 지식을 많이 알고 있는 것만으로는 부족하다.

직원과 부서, 회의와 이메일, 프로젝트 문서 사이의 관계를 이해하고 실제로 어떤 일이 어떤 순서로 발생했는지 추적할 수 있어야 한다.

문제는 기업의 실제 데이터를 평가에 사용하는 일이 어렵다는 것이다.

기업의 이메일과 회의 기록에는 개인정보와 기밀정보가 포함될 수 있다.

외부 연구자에게 해당 자료를 제공하기도 어렵다.

Microsoft Research는 이를 해결하기 위해 실제 기업처럼 작동하는 가상의 업무 환경을 생성하는 방법을 개발했다.

가상의 직원과 조직, 업무 기록 생성

연구팀은 하나의 기업을 흉내 내는 데이터 환경을 만들었다.

Microsoft는 이를 Synthetic Tenant(합성 테넌트)라고 부른다.

Tenant(테넌트)는 하나의 기업이나 조직이 사용하는 독립적인 업무 환경을 의미한다.

합성 테넌트에는 실제 사람이 아닌 가상의 직원들이 존재한다.

각 직원은 담당 업무와 직책, 소속 부서와 보고 관계를 가진다.

또한 가상의 이메일과 회의 기록, 문서와 프로젝트가 생성된다.

예를 들어 제약회사에 관한 합성 테넌트에서는 임상시험과 규제기관 제출 자료에 관한 업무가 등장할 수 있다.

자본시장 관련 기업에서는 고객 포트폴리오와 규제 준수 검토, 거래 관련 업무가 생성된다.

IT 기업에서는 개발 일정과 코드 리뷰, 스프린트 계획과 제품 출시 준비 기록이 포함된다.

이렇게 하면 일반적인 문서 검색보다 실제 기업 업무에 가까운 질문을 평가할 수 있다.

완전히 무작위로 데이터를 생성하지 않는다

이번 연구에서 중요한 점은 합성 데이터를 현실에 가깝게 만들기 위해 공개된 실제 통계와 문서를 참고했다는 사실이다.

연구팀은 미국 노동부의 O*NET 자료를 활용했다.

O*NET은 직업별 업무와 필요한 능력, 직무 특성을 체계적으로 정리한 데이터베이스다.

이를 이용해 어떤 직업이 어떤 종류의 업무를 수행하는지 반영했다.

또한 실제 채용공고를 분석해 직책과 조직 구조를 구성했다.

미국 SEC 공시 자료를 이용해 기업의 규모와 사업부 구조, 재무적 맥락도 반영했다.

중요한 구분이 있다.

실제 공개 자료를 통계적·구조적 참고자료로 사용한 것이지, 실제 기업 직원의 이메일이나 고객 데이터를 복사한 것이 아니다.

Microsoft는 실제 고객의 데이터를 합성 환경 생성에 사용하지 않았다고 밝혔다.

이렇게 하면 현실적인 업무 구조를 만들면서도 고객의 개인정보를 보호할 수 있다.

시간에 따라 변하는 기업 환경

일반적인 테스트 데이터는 특정 시점의 문서와 정답으로 구성되는 경우가 많다.

하지만 실제 기업의 업무는 계속 변화한다.

예를 들어 프로젝트 일정이 월요일에 변경되고 수요일에 다시 수정될 수 있다.

목요일 회의에서는 새로운 담당자가 결정될 수도 있다.

따라서 사용자가 지난번 회의 이후 무엇이 달라졌는지 질문하면 실제 사건의 발생 순서를 이해해야 한다.

Microsoft는 이런 문제를 해결하기 위해 합성 테넌트에 시간에 따라 변화하는 업무 기록을 포함했다.

가상의 이메일 대화가 여러 주에 걸쳐 이어질 수 있다.

프로젝트 일정과 보고 관계도 변경될 수 있다.

이런 구조는 기업용 AI의 Temporal Reasoning(시간적 추론)을 평가하는 데 필요하다.

시간적 추론은 사건의 발생 순서와 특정 시점의 상태를 이해하는 능력이다.

예를 들어 같은 고객에 대해 과거에는 A가 담당자였지만 현재는 B가 담당자일 수 있다.

AI가 두 정보를 구분하지 못하면 오래된 자료를 바탕으로 잘못된 답변을 생성할 가능성이 있다.

질문도 자동으로 생성

기업 환경을 생성한 뒤에는 평가에 사용할 질문이 필요하다.

예를 들어 특정 프로젝트의 현재 담당자가 누구인지 질문할 수 있다.

또는 지난주 회의 이후 변경된 결정사항을 정리하도록 요청할 수 있다.

연구팀은 이런 질문을 자동으로 생성하기 위한 6단계 파이프라인을 구축했다.

Pipeline(파이프라인)은 데이터를 입력받아 여러 단계를 거쳐 결과를 만드는 처리 과정이다.

먼저 일반적인 업무 질문의 유형을 정의한다.

이후 특정 산업과 관련된 질문만 선택한다.

선택한 질문을 해당 기업의 업무 용어와 상황에 맞게 수정한다.

그다음 실제 합성 환경에 존재하는 문서와 기록에 연결한다.

마지막으로 자연스러운 표현으로 변경하고 정답의 유효성과 다른 질문과의 중복 여부를 검사한다.

여기서 중요한 것은 질문에 대한 근거가 실제로 합성 환경 안에 존재해야 한다는 점이다.

AI가 아무리 그럴듯하게 답변하더라도 평가 환경에 정답을 확인할 자료가 없다면 정확성을 판단하기 어렵기 때문이다.

합성 데이터의 품질을 평가하는 네 가지 기준

Microsoft는 생성한 업무 환경의 품질을 여러 관점에서 평가했다.

첫 번째는 Structural Fidelity(구조적 충실도)다.

기업의 조직 구조와 보고 관계, 팀의 규모가 현실적인지 확인한다.

두 번째는 Contextual Relevance(맥락 관련성)다.

질문과 업무 기록이 해당 산업의 실제 업무와 관련돼 있는지 평가한다.

세 번째는 Behavioral Realism(행동의 현실성)이다.

가상의 직원들이 실제 직장인처럼 의사소통하고 협력하는지 확인한다.

네 번째는 Content Safety(콘텐츠 안전성)다.

생성된 자료에 개인정보와 유해한 내용, 실제 인물을 부적절하게 모방한 정보가 포함되지 않았는지 검사한다.

이러한 검사를 거쳐 생성된 환경은 여러 팀이 공통으로 사용할 수 있도록 관리한다.

자체 평가에서 합성 데이터 품질 39% 개선

Microsoft는 초기 데이터 생성 방법과 개선된 방법을 비교한 결과를 공개했다.

회사 내부의 종합 품질 평가에서는 새로운 방법의 점수가 39% 개선됐다.

일부 산업별 환경에서는 1.0 만점에 0.9를 넘는 품질 점수도 기록했다.

다만 이 수치는 Microsoft의 자체 평가 체계에서 얻어진 결과다.

실제 사용자와 AI가 상호작용할 때의 모든 오류를 같은 비율로 줄였다는 의미는 아니다.

또한 연구팀은 데이터셋 하나를 생성할 때 약 10만 달러 상당의 비용을 절감할 수 있다고 추정했다.

프로젝트 전체의 예상 절감액은 약 30만 달러였다.

이 역시 실제 회계상 확정된 절감액보다는 기존 수작업 방식과 자동화된 방식의 비용을 비교한 추정치다.

이번 글에서 중요한 부분은 평가 데이터의 재현성(Reproducibility)이다.

재현성은 같은 조건에서 실험을 다시 실행했을 때 같은 결과를 얻을 수 있는 성질이다.

AI 모델의 새로운 버전을 평가할 때 테스트 환경이 계속 바뀐다면 성능 차이의 원인을 구분하기 어렵다.

반면 같은 합성 기업 환경과 평가 질문을 반복해서 사용하면 모델 변경에 따른 효과를 더 정확하게 비교할 수 있다.

이번 글은 기업용 AI의 정확성을 높이는 작업이 모델을 더 강력하게 만드는 데서 끝나지 않는다는 사실을 보여준다.

개인정보를 보호하면서도 실제 업무처럼 복잡한 평가 환경을 만들고, 그 환경을 여러 모델 버전에서 재사용하는 기술도 기업용 AI의 신뢰성을 높이는 중요한 요소다.

---

How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway

• 저자: Nikhil Kumar, Anant Murarka, Bhupesh Chadha, Shakir Khan
• 발행: MoEngage / AWS Artificial Intelligence Blog
• 게시일: 2026-10-29
• 원문: AWS — How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway

AI 에이전트가 기업의 내부 API를 400개 이상 사용해야 한다면 어떤 문제가 발생할까?

일반적인 에이전트 개발에서는 모델에게 사용할 수 있는 도구의 이름과 설명을 제공한다.

예를 들어 주문 조회와 고객 검색, 캠페인 생성 등의 도구를 등록할 수 있다.

사용자의 요청이 들어오면 모델은 관련된 도구를 선택해 실행한다.

하지만 실제 기업에서는 이런 도구가 수백 개 이상 존재할 수 있다.

또한 하나의 도구가 민감한 개인정보나 기업의 운영 시스템에 접근할 수도 있다.

따라서 단순히 많은 도구를 등록하는 것만으로는 안전한 에이전트 시스템을 만들기 어렵다.

이번 글은 고객 참여 플랫폼 MoEngage가 이런 문제를 실제 운영 환경에서 해결한 사례를 설명한다.

MoEngage는 1,350개 이상의 소비자 브랜드에 고객 참여 기능을 제공한다.

플랫폼에는 푸시 알림과 이메일, SMS, WhatsApp 등을 이용한 마케팅 캠페인 관리 기능이 포함된다.

회사의 내부에는 약 400개의 REST API가 존재한다.

이 API들은 25개 엔지니어링팀이 개발했고 AWS의 7개 리전에서 운영된다.

문제는 AI 에이전트가 이런 API를 안전하게 사용하도록 연결하는 일이었다.

모든 팀이 MCP 서버를 따로 만들면?

MCP(Model Context Protocol)는 AI 에이전트가 외부 프로그램과 데이터를 호출할 수 있도록 하는 통신 규격이다.

기본적인 접근은 각 업무팀이 자신의 API를 MCP 서버로 제공하는 것이다.

예를 들어 캠페인팀이 캠페인 관리용 MCP 서버를 만든다.

고객 세그먼트팀은 세그먼트 검색용 서버를 만든다.

통계팀은 캠페인 성과 분석용 서버를 만들 수 있다.

하지만 이렇게 하면 여러 MCP 서버의 배포와 버전, 보안 정책을 따로 관리해야 한다.

MoEngage는 20개 이상의 MCP 서버를 직접 운영하는 방안을 검토했지만 채택하지 않았다.

대신 각 업무팀은 기존 REST API를 계속 관리하고, 중앙 AI 플랫폼팀이 MCP 연결과 보안을 담당하는 구조를 선택했다.

이 설계에는 세 가지 중요한 요구사항이 있었다.

첫 번째는 내부 API를 인터넷에 공개하지 않는 것이다.

두 번째는 AI 모델이 자신의 사용자 신원과 접근권한을 직접 지정할 수 없도록 만드는 것이다.

세 번째는 모든 도구의 설명을 매번 모델에게 전달하지 않는 것이다.

API 명세를 그대로 도구로 변환

MoEngage는 Amazon Bedrock AgentCore Gateway를 사용했다.

이 서비스는 기존 API의 OpenAPI 명세를 바탕으로 MCP 도구를 생성하도록 지원한다.

OpenAPI는 REST API가 제공하는 기능과 입력·출력 형식을 구조화해 설명하는 규격이다.

예를 들어 내부 API에 캠페인 목록을 조회하는 기능이 있다고 가정해 보자.

개발팀은 해당 API의 OpenAPI 문서에 에이전트용 설명을 추가할 수 있다.

이후 자동화된 배포 과정에서 관련 도구가 AgentCore Gateway에 등록된다.

새로운 기능이 추가될 때마다 개발팀이 별도의 MCP 서버 프로그램을 작성할 필요가 줄어든다.

MoEngage는 업무팀이 이미 관리하는 API 명세를 도구 정의의 기준으로 사용했다.

하지만 모든 API를 자동으로 외부에 노출하는 것은 아니다.

업무팀이 명시적으로 에이전트용 기능으로 등록한 API만 사용할 수 있도록 설계했다.

이런 방식을 Opt-in(명시적 사용 허용)이라고 한다.

예를 들어 내부 관리용 데이터 초기화 API나 운영 시스템의 마이그레이션 API는 에이전트에게 제공하지 않을 수 있다.

모델이 사용자 신원을 결정하지 못하도록 제한

이번 사례에서 특히 중요한 부분은 접근권한을 관리하는 방식이다.

일반적인 도구 호출에서는 모델이 API에 전달할 파라미터를 생성한다.

예를 들어 고객 ID나 캠페인 ID를 지정할 수 있다.

하지만 사용자 신원과 접근권한까지 모델의 파라미터로 전달하면 문제가 발생할 수 있다.

모델이 잘못된 고객 ID나 사용자 역할을 생성할 수도 있고, 악의적인 외부 문서에 포함된 지시의 영향을 받을 수도 있기 때문이다.

MoEngage는 이를 해결하기 위해 사용자의 신원 정보를 모델이 볼 수 없는 별도의 요청 헤더에 포함하도록 설계했다.

실제 인증된 사용자의 정보는 서버 측 프로그램이 설정한다.

모델은 해당 값을 직접 변경할 수 없다.

또한 각 에이전트는 AWS IAM 역할을 이용해 자신의 신원을 증명한다.

IAM(Identity and Access Management)은 사용자나 프로그램의 접근권한을 관리하는 기술이다.

도구 접근 정책에는 Cedar라는 정책 언어를 사용한다.

Cedar는 어떤 주체가 어떤 자원에 어떤 행동을 수행할 수 있는지 규칙으로 표현하는 기술이다.

예를 들어 캠페인 품질을 검사하는 에이전트는 캠페인 목록과 설정을 읽을 수 있지만 실제 캠페인을 발송하는 기능은 사용할 수 없도록 구성할 수 있다.

중요한 점은 허용되지 않은 도구를 모델에게 전달한 뒤 모델이 사용하지 않기를 기대하는 방식이 아니라는 사실이다.

서버에서 접근 정책을 검사한 뒤 허용된 도구만 모델에게 제공한다.

400개 도구를 모두 입력하면 토큰 비용 증가

AI 에이전트는 어떤 도구를 사용할지 판단하기 위해 도구의 이름과 설명, 입력 형식을 알아야 한다.

하지만 도구가 400개라면 모든 도구의 설명을 매번 전달하는 데 상당한 토큰이 필요할 수 있다.

Token(토큰)은 언어모델이 텍스트를 처리하는 기본 단위다.

MoEngage는 전체 도구 목록을 전달하면 약 2만 토큰 이상이 필요하다고 추정했다.

이는 모델이 실제 사용자의 질문을 분석하기 전부터 상당한 입력 공간을 소비한다는 의미다.

또한 도구가 많으면 모델이 어떤 기능을 선택해야 할지 혼동할 가능성도 있다.

이를 해결하기 위해 MoEngage는 Semantic Tool Search(의미 기반 도구 검색)를 사용했다.

모델에게 처음부터 400개 도구를 제공하는 대신 하나의 검색 도구만 제공한다.

모델은 현재 작업에 필요한 기능을 자연어로 설명한다.

예를 들어 특정 캠페인의 현재 상태를 확인하는 도구를 검색할 수 있다.

검색 시스템은 의미적으로 관련된 몇 개의 도구를 반환한다.

모델은 이 중 필요한 도구만 실제로 호출한다.

이렇게 하면 전체 도구 목록을 항상 컨텍스트에 포함할 필요가 줄어든다.

내부 API는 인터넷에 공개하지 않음

MoEngage의 내부 API는 여러 AWS VPC에서 운영된다.

VPC(Virtual Private Cloud)는 클라우드 안에서 네트워크 접근 범위를 논리적으로 분리하는 환경이다.

회사는 이러한 API를 인터넷에 공개하지 않는다는 정책을 유지해야 했다.

따라서 AgentCore Gateway와 내부 API 사이의 연결도 사설 네트워크 안에서 구성했다.

여기에는 AWS의 VPC Endpoint와 VPC Lattice가 사용됐다.

VPC Endpoint는 클라우드 서비스를 사설 네트워크 경로로 접근하도록 지원하는 기능이다.

VPC Lattice는 여러 애플리케이션 서비스 사이의 네트워크 연결과 접근을 관리하는 기술이다.

이런 방식으로 각 API마다 별도의 공개 엔드포인트를 만들 필요를 줄였다.

7개 리전에서 실제 운영

MoEngage는 이번 구조를 7개 AWS 리전에서 운영하고 있다고 밝혔다.

현재 약 10개 내부 AI 에이전트가 관련 도구를 사용한다.

예를 들어 캠페인 품질 검사 에이전트는 캠페인의 설정과 대상 고객을 확인한다.

다른 에이전트는 메시지 발송 현황과 오류 패턴을 분석한다.

또 다른 에이전트는 사용자의 자연어 설명을 고객 세그먼트 검색 조건으로 변환한다.

회사는 이 시스템을 약 3개월 동안 실제 운영했다고 설명했다.

또한 기존의 여러 MCP 서버를 직접 구현하는 방식과 비교하면 약 6개월의 엔지니어링 작업을 절감한 것으로 추정했다.

새로운 API를 에이전트 도구로 연결하는 데 걸리는 시간도 며칠에서 수시간 수준으로 줄었다고 밝혔다.

다만 이러한 수치는 MoEngage의 자체 평가와 추정이다.

다른 조직에서 동일한 구조를 사용했을 때 같은 비용과 기간을 절감한다는 의미는 아니다.

이번 글의 가장 중요한 교훈은 AI 에이전트의 도구 사용 능력과 실제 조직의 보안 정책을 분리해서 관리해야 한다는 점이다.

모델은 사용자에게 필요한 기능을 선택한다.

하지만 어떤 기능에 접근할 수 있는지와 어떤 사용자 권한으로 실행하는지는 서버가 결정한다.

또한 업무팀이 기존 API를 계속 관리하면서 중앙 플랫폼팀이 공통적인 MCP 연결과 접근권한을 제공하는 구조는 여러 개발팀이 AI 에이전트를 도입할 때 참고할 만한 실제 운영 사례다.

---

We dug into Claude Code's memory. Here's exactly how it works

• 저자: Muskan Jain
• 발행: Supermemory Engineering Blog
• 게시일: 2026-10-28
• 원문: Supermemory — Claude Code auto memory: how it works

AI 코딩 에이전트는 지난주에 작업한 프로젝트의 규칙을 어떻게 기억할까?

예를 들어 개발자가 같은 저장소에서 여러 주 동안 작업한다고 가정해 보자.

처음에는 프로젝트의 구조와 코드 작성 규칙을 AI에게 설명한다.

이후 새로운 기능을 추가하고 오류를 수정한다.

며칠 뒤 다른 작업을 시작했을 때 AI가 이전에 합의한 규칙을 기억한다면 개발자가 같은 설명을 반복할 필요가 줄어든다.

하지만 일반적인 언어모델은 이전의 모든 작업을 영구적으로 기억하는 구조가 아니다.

새로운 세션을 시작하거나 입력으로 전달할 수 있는 정보의 범위를 초과하면 이전 작업의 일부를 참고하지 못할 수 있다.

이번 글은 이런 문제를 해결하기 위한 Claude Code의 자동 기억 구조를 실제 파일과 사용 사례를 통해 분석한 기술 자료다.

특히 단순히 새로운 기능을 소개하는 것이 아니라 기억을 어디에 저장하고 언제 불러오는지, 실제로 어떤 문제를 경험했는지 구체적으로 설명한다는 점에서 읽어볼 가치가 있다.

다만 저자는 Anthropic의 내부 소스코드를 직접 확인한 것은 아니라고 명시했다.

공식 문서와 실제 파일, 여러 테스트를 기반으로 분석한 결과이므로 내부 구현에 관한 일부 추정에는 오류가 있을 수 있다.

Claude Code의 기억은 Markdown 파일로 저장

Claude Code에서는 개발자가 직접 작성하는 지침 파일과 AI가 자동으로 작성하는 기억을 구분한다.

예를 들어 프로젝트의 루트에 CLAUDE.md 파일을 만들 수 있다.

이 파일에는 코드 작성 규칙과 프로젝트의 구조, 테스트 방법 등을 기록할 수 있다.

Markdown은 제목과 목록, 강조 등을 간단한 텍스트 기호로 표현하는 문서 형식이다.

CLAUDE.md를 Git 저장소에 포함하면 다른 개발자도 같은 프로젝트 지침을 사용할 수 있다.

반면 Auto Memory(자동 기억)는 Claude Code가 이전 작업에서 유용하다고 판단한 정보를 직접 저장하는 기능이다.

저장된 정보는 별도의 Markdown 파일로 관리된다.

예를 들어 특정한 빌드 명령과 프로젝트의 특수한 구조, 과거에 발견한 오류의 원인 등을 기록할 수 있다.

저자는 자신의 컴퓨터에서 140개 이상의 자동 기억 파일을 확인했다고 밝혔다.

이처럼 자동 기억은 하나의 긴 문서가 아니라 여러 주제별 파일로 나뉘어 저장될 수 있다.

모든 기억을 매번 모델에게 전달하지 않는다

Claude Code는 자동 기억의 목록을 MEMORY.md라는 색인 파일로 관리한다.

Index(색인)는 필요한 정보를 빠르게 찾을 수 있도록 정리한 목록이나 자료구조다.

새로운 세션을 시작하면 Claude Code는 이 색인 파일을 참고할 수 있다.

하지만 모든 기억 파일의 내용을 처음부터 모델에게 전달하지는 않는다.

필요한 기억이 있다고 판단했을 때 해당 파일을 추가로 읽는다.

이를 On-Demand Retrieval(필요할 때 불러오는 검색 방식)이라고 한다.

예를 들어 프로젝트에서 사용하는 데이터베이스에 관한 질문이 들어오면 관련 기억 파일을 찾아 읽을 수 있다.

이런 구조는 모델의 입력 토큰 사용량을 줄이는 데 도움이 된다.

모든 과거 기록을 매번 전달하면 실제 질문과 관련 없는 정보까지 모델이 처리해야 하기 때문이다.

하지만 여기에는 새로운 문제가 발생한다.

필요한 기억이 저장돼 있더라도 모델이 해당 파일을 읽기로 결정하지 않으면 그 정보를 사용하지 못할 수 있다.

저자는 실제 테스트에서 이런 상황을 확인했다.

어떤 질문에서는 색인 파일만으로 필요한 정보를 찾아냈다.

반면 다른 질문에서는 관련 기억 파일이 존재했지만 모델이 해당 파일을 읽지 않고 Git 기록을 조사했다.

즉 기억을 저장하는 능력과 실제로 필요한 순간에 검색하는 능력은 서로 다르다.

기억 시스템의 세 가지 핵심 문제

저자는 AI 기억 시스템의 문제를 세 가지로 구분한다.

첫 번째는 Writing(무엇을 저장할 것인가)이다.

사용자와의 모든 대화를 영구적으로 저장할 필요는 없다.

예를 들어 개발자가 오늘만 사용할 임시 파일의 이름을 언급했다고 해서 그 정보를 몇 달 동안 기억할 필요는 없을 수 있다.

반대로 프로젝트의 중요한 설계 결정은 장기간 유지할 가치가 있다.

따라서 기억 시스템은 어떤 정보가 이후에도 유용할지 판단해야 한다.

두 번째는 Representation(어떤 형태로 저장할 것인가)이다.

기억을 단순한 텍스트 파일로 저장할 수도 있다.

하지만 정보 사이의 관계나 시간에 따른 변화를 추적하려면 다른 구조가 필요할 수 있다.

세 번째는 Retrieval(필요할 때 어떻게 불러올 것인가)이다.

저장된 정보가 많더라도 현재 작업과 관련된 기억을 찾지 못하면 효과가 떨어질 수 있다.

이 세 가지는 서로 연결돼 있다.

기억을 지나치게 많이 저장하면 검색 비용이 증가할 수 있다.

반대로 지나치게 적게 저장하면 실제로 필요한 정보가 누락될 수 있다.

현재 상태와 과거 이력의 차이

이번 글에서 흥미로운 부분은 기억이 변경되는 상황을 다룬다는 점이다.

예를 들어 프로젝트가 처음에는 MySQL을 사용했다고 가정해 보자.

이후 PostgreSQL로 데이터베이스를 변경했다.

현재 작업에서는 PostgreSQL을 사용해야 한다.

하지만 과거의 설계 결정과 변경 이유를 이해하려면 MySQL을 사용했던 이력도 참고할 가치가 있을 수 있다.

단순한 Markdown 파일에서는 현재 정보를 덮어쓰는 방식으로 기억을 수정할 수 있다.

하지만 이렇게 하면 과거의 상태가 사라질 수 있다.

반대로 과거 기록을 모두 유지하면 어떤 정보가 현재 유효한지 판단하기 어려워질 수 있다.

저자는 이를 해결하기 위한 방법으로 시간적 정보와 사실 사이의 관계를 관리하는 기억 구조를 소개한다.

Supermemory는 이런 목적을 위해 지식 그래프 기반 기억을 사용한다고 설명한다.

Knowledge Graph(지식 그래프)는 여러 정보와 그 사이의 관계를 구조적으로 표현하는 데이터 모델이다.

예를 들어 특정한 프로젝트 설정이 언제 변경됐고 어떤 과거 설정을 대체했는지 연결할 수 있다.

다만 이는 Supermemory가 자체적으로 설명하는 제품 설계다.

독립적인 평가에서 모든 종류의 기억 작업에 더 우수하다고 검증된 것은 아니다.

프로젝트 폴더를 옮기면 기억이 달라질 수 있다

저자는 실제 개발 과정에서 경험한 문제도 공개했다.

Claude Code의 자동 기억은 기본적으로 로컬 컴퓨터의 프로젝트 경로와 연결된다.

따라서 프로젝트 폴더의 위치를 변경하면 기존 기억과 새로운 폴더의 기억이 분리될 수 있다.

저자는 10월 14일에 작업 공간의 이름을 변경하면서 84개 기억 파일을 복사했다고 설명한다.

이후 시간이 지나면서 복사된 파일 가운데 3분의 1 이상이 서로 다른 내용으로 변경됐다.

이 사례는 기억을 여러 장소에 복사하면 어떤 버전이 최신인지 관리해야 하는 문제가 생길 수 있음을 보여준다.

일반적인 소프트웨어 개발에서도 파일을 복사해 여러 버전으로 관리하면 비슷한 문제가 발생한다.

이를 Data Consistency(데이터 일관성) 문제와 연결해 이해할 수 있다.

서로 다른 저장소나 기기에 존재하는 정보가 같은 현재 상태를 유지하는지에 관한 문제다.

Claude Code는 프로젝트 설정을 통해 기억 저장 위치를 고정할 수 있다.

저자는 Supermemory가 Git 원격 저장소를 기준으로 프로젝트를 식별하는 방식을 사용한다고 설명한다.

이 방식에서는 같은 저장소를 서로 다른 컴퓨터에 복제하더라도 하나의 기억에 연결할 수 있다.

하지만 기억이 외부 서비스에 저장되므로 개인정보와 데이터 접근권한에 관한 고려도 필요하다.

로컬 기억과 외부 기억 서비스의 차이

이번 글은 두 접근의 장단점을 비교한다.

로컬 기억의 장점은 데이터가 사용자의 컴퓨터에 저장되고 파일을 직접 확인할 수 있다는 점이다.

또한 네트워크 연결이 없어도 저장된 내용을 읽을 수 있다.

반면 여러 컴퓨터에서 동일한 기억을 사용하려면 별도의 동기화가 필요할 수 있다.

외부 기억 서비스는 여러 기기 사이에서 정보를 공유하고 검색하는 기능을 제공할 수 있다.

하지만 외부 서버에 어떤 정보가 저장되는지, 어떤 접근권한과 보관 정책이 적용되는지 확인해야 한다.

특히 회사의 소스코드와 내부 설계에 관한 정보를 저장한다면 기업의 보안 정책을 고려해야 한다.

기억이 있다고 해서 에이전트가 반드시 더 똑똑해지는 것은 아니다

이번 글에서 중요한 점은 기억의 양과 실제 에이전트의 작업 성공률을 구분해야 한다는 사실이다.

많은 기억이 저장돼 있더라도 현재 작업과 관련된 정보를 찾아내지 못하면 효과가 없다.

반대로 오래된 기억을 잘못 사용하면 현재 상황에 맞지 않는 결정을 내릴 수 있다.

예를 들어 과거에는 특정 테스트 명령을 사용했지만 현재는 실행 방법이 변경됐을 수 있다.

AI가 오래된 기억을 더 신뢰한다면 잘못된 명령을 실행할 수 있다.

따라서 좋은 기억 시스템은 정보를 오래 보관하는 것뿐 아니라 정보의 최신성과 유효성, 실제 작업과의 관련성을 함께 관리해야 한다.

저자는 자신의 비교가 엄격한 대규모 벤치마크가 아니라 실제 사용과 공식 문서를 바탕으로 한 탐색적 분석이라고 명시했다.

또한 글을 작성한 Supermemory는 기억 서비스를 판매하는 기업이므로 자사 방식의 장점을 강조할 수 있다.

따라서 독립적인 성능 검증 결과와 제품 개발자의 설명을 구분해서 읽는 것이 적절하다.

이번 글은 AI 코딩 에이전트를 오래 사용할수록 중요해지는 기억의 저장과 검색, 버전 관리와 개인정보 보호 문제를 실제 파일 구조와 사례를 통해 이해하는 데 유용한 자료다.