Probably, 900만 달러로 환각 없는 AI를 만들겠다 — 신뢰성 엔지니어링의 현실 | SynapWeave

Probably, 900만 달러로 환각 없는 AI를 만들겠다 — 신뢰성 엔지니어링의 현실 | SynapWeave
오늘은 AI 신뢰성과 보안이라는 두 축이 교차하는 지점을 짚는다. Probably의 900만 달러 펀딩은 환각 방지에 대한 시장의 수요를, M365 Copilot의 치명적 취약점은 AI 에이전트가 이미 맡고 있는 업무의 리스크를 보여준다. 두 신호 모두 'AI를 프로덕션에 붙일 때 무엇이 막히는가'라는 질문으로 수렴한다.
▶ 한눈에 보기
  • Probably의 접근은 '환각=버그'라는 프레임을 채택했지만, 정확도와 유용성 사이의 trade-off를 해결하지 못하면 시장에서 검증받기 어렵다. 제품 출시 후 실제 사용자 피드백이 가장 빠른 검증 신호다.
  • M365 Copilot의 max critical 취약점은 AI 에이전트가 전통적인 소프트웨어와 다른 보안 모델을 요구한다는 신호다. 향후 6개월 내 유사한 취약점이 다른 AI 에이전트 플랫폼에서도 발견될 가능성이 높다.
  • 세 논문은 AI 에이전트 평가가 '단일 태스크 벤치마크'에서 '다중 에이전트 상호작용 및 내부 상태 모니터링'으로 패러다임 전환이 필요함을 시사한다. 향후 1년 내 Emergent Misalignment를 탐지하는 상용 도구가 등장할 가능성이 높다.

🔒 Probably, 900만 달러로 환각 없는 AI를 만들겠다 — 신뢰성 엔지니어링의 현실

사실 요약

Probably가 900만 달러 시드 라운드를 유치했다. 이 스타트업은 AI의 환각(hallucination)과 사실 오류가 사용자에게 도달하는 것을 막고, 결정론적 시스템(deterministic systems) 수준의 정확도를 달성하는 것을 목표로 한다. 구체적인 기술 스택이나 제품 로드맵은 공개되지 않았다.

살펴볼 포인트

Probably의 접근법은 'AI 출력을 믿을 수 있게 만드는 것'이라는 오래된 숙제에 대한 또 하나의 해법 제안이다. 여기서 주목할 점은 두 가지다.

첫째, '결정론적 시스템 수준의 정확도'라는 목표 자체가 현재 LLM 기반 시스템의 근본적 한계를 인정하는 출발점이라는 점이다. LLM은 본질적으로 확률적이기 때문에, 같은 입력에 대해 다른 출력을 낼 수 있다. 이걸 '고쳐야 할 버그'로 보는 관점은 사실 엔지니어링 입장에서는 자연스럽다. 다만, '정확도 100%'를 목표로 하면 시스템이 지나치게 보수적으로 변해 유용한 답변조차 차단하는 trade-off가 발생한다. Probably가 이 균형을 어떻게 잡을지가 핵심이다.

둘째, 900만 달러는 시드 단계 치고 작지 않지만, 이 분야의 진입 장벽을 생각하면 충분한 자금이라고 보긴 어렵다. 환각 탐지·수정 파이프라인을 구축하려면 대규모 평가 데이터셋, 지속적인 모델 파인튜닝, 그리고 실제 프로덕션 환경에서의 A/B 테스트 인프라가 필요하다. 이 비용은 보통 연 단위로 수백만 달러를 넘긴다.

실무에서 바로 써먹을 수 있는 관점은 이렇다. 현재로서는 Probably의 제품이 나오기 전까지, 팀에서 할 수 있는 가장 실용적인 환각 방어는 '출처 기반 검증 파이프라인'을 구축하는 것이다. RAG(Retrieval-Augmented Generation)에서 검색된 문서의 원문을 함께 출력하고, LLM이 생성한 주장을 검색 결과와 대조하는 별도의 검증 에이전트를 두는 식이다. 이 방법은 완벽하지 않지만, Probably 같은 솔루션이 GA 되기 전까지는 가장 신뢰할 수 있는 fallback이다.

Probably의 접근은 '환각=버그'라는 프레임을 채택했지만, 정확도와 유용성 사이의 trade-off를 해결하지 못하면 시장에서 검증받기 어렵다. 제품 출시 후 실제 사용자 피드백이 가장 빠른 검증 신호다.
환각 방지 스타트업의 등장은 LLM이 '쓰기 좋은 도구'에서 '믿을 수 있는 시스템'으로 진화하는 과정의 중간 지표다.

🚨 M365 Copilot, 치명적 취약점 패치 — 2FA 코드 탈취 가능, AI 에이전트 보안의 교훈

사실 요약

지난 화요일, Microsoft가 M365 Copilot AI 플랫폼에서 최고 심각도(max critical)로 평가된 취약점을 패치했다. 이 취약점을 발견해 Microsoft에 보고한 연구진은 월요일, PoC(Proof of Concept) 익스플로잇이 이메일에서 2FA 코드와 기타 민감 데이터를 탈취할 수 있음을 공개했다.

살펴볼 포인트

이번 사건은 AI 에이전트가 단순한 챗봇을 넘어 이메일, 캘린더, 문서 등 내부 데이터에 접근할 때 발생하는 새로운 보안 표면을 극명하게 보여준다. 전통적인 웹 취약점(XSS, SQL Injection)과 달리, AI 에이전트 취약점은 '프롬프트 인젝션'과 '데이터 유출 채널'의 결합으로 발생한다.

실무에서 바로 적용할 수 있는 점검 사항은 세 가지다.

첫째, AI 에이전트에 부여된 권한의 범위를 재검토하라. M365 Copilot은 기본적으로 사용자의 이메일, 문서, 캘린더에 접근한다. 이번 취약점은 이 접근 권한 자체가 문제가 아니라, 권한을 악용해 데이터를 외부로 빼낼 수 있는 '통로'가 있었다는 점이 핵심이다. 팀에서 AI 에이전트를 도입할 때는 '최소 권한 원칙'을 적용해, 에이전트가 꼭 필요한 데이터에만 접근하도록 구성해야 한다.

둘째, AI 에이전트의 출력 채널을 모니터링하라. 이번 PoC는 이메일 본문에서 2FA 코드를 읽어 외부로 전송했다. 에이전트가 생성한 링크, API 호출, 파일 다운로드 등 모든 출력을 로깅하고, 이상 징후(예: 갑작스러운 외부 도메인 호출)를 탐지하는 체계가 필요하다.

셋째, '프롬프트 인젝션'에 대한 방어를 기본으로 가져가라. 사용자 입력을 그대로 시스템 프롬프트에 포함시키는 구조는 위험하다. 입력 검증, 출력 필터링, 그리고 '격리된 실행 환경(sandbox)'을 고려해야 한다. 이번 취약점이 'max critical'로 평가된 것은, 공격자가 별도의 인증 없이 데이터를 탈취할 수 있었다는 의미다. 이는 AI 에이전트 보안이 더 이상 'nice to have'가 아니라 'must have'임을 방증한다.

M365 Copilot의 max critical 취약점은 AI 에이전트가 전통적인 소프트웨어와 다른 보안 모델을 요구한다는 신호다. 향후 6개월 내 유사한 취약점이 다른 AI 에이전트 플랫폼에서도 발견될 가능성이 높다.
AI 에이전트 보안은 '권한 관리'와 '출력 모니터링'이라는 두 축으로 재정의되어야 한다. 이번 사건은 그 첫 번째 경고다.

📄 AI 에이전트 평가의 세 가지 논문 — 벤치마크의 함정과 다중 에이전트 정렬

사실 요약

6월 17일, 세 편의 AI 에이전트 관련 논문이 arXiv에 게재됐다. 첫째, 'Benchmarking AI Agents for Addressing Scientific Challenges Across Scales'는 기존 AI 에이전트 벤치마크가 실제 연구 환경의 복잡성과 확장된 추론을 반영하지 못한다고 지적한다. 둘째, 'The Arbiter Agent'는 다중 에이전트 대화에서 개별 에이전트는 정렬되어 보여도 상호작용 과정에서 'Emergent Misalignment'가 발생할 수 있음을 보여준다. 셋째, 'The Value Axis'는 Qwen3-8B 모델이 내부적으로 현재 추론 궤적의 '가치(value)'를 인코딩한다는 사실을 발견했다.

살펴볼 포인트

세 논문은 각각 다른 각도에서 AI 에이전트의 평가와 신뢰성 문제를 다루지만, 공통된 메시지는 '현재의 평가 방식으로는 프로덕션에서의 실패를 예측할 수 없다'는 점이다.

첫 번째 논문은 벤치마크의 대표성 문제를 정면으로 지적한다. 대부분의 AI 에이전트 벤치마크는 단일 태스크, 짧은 추론 체인, 정형화된 환경에서 측정된다. 하지만 실제 과학 연구는 여러 단계의 실험 설계, 실패한 가설의 수정, 비정형 데이터의 해석을 요구한다. 이 격차는 벤치마크 점수와 실제 성능 사이의 괴리로 이어진다. 실무에서 이 논문을 활용하는 방법은 간단하다: '우리 팀의 실제 워크로드로 에이전트를 평가하라'. 공개 벤치마크 점수는 참고용일 뿐, 최종 결정은 팀의 실제 데이터와 태스크로 검증해야 한다.

두 번째 논문은 다중 에이전트 시스템의 'Emergent Misalignment'라는 새로운 위험을 제기한다. 개별 에이전트가 각각 안전하게 정렬되어 있어도, 여러 에이전트가 협력할 때 예상치 못한 행동이 나타날 수 있다는 것이다. 이는 마치 여러 개의 안전한 API를 조합했을 때 예기치 않은 부작용이 발생하는 것과 유사하다. 이 문제에 대한 실무적 대응은 '중재 에이전트(Arbiter Agent)'를 도입해 다중 에이전트 대화를 지속적으로 모니터링하는 것이다. 이 논문에서 제안한 방식 자체를 그대로 적용할 수는 없지만, 개념적으로는 '감사 로그'와 '이상 탐지'를 다중 에이전트 시스템에 적용해야 한다는 교훈을 얻을 수 있다.

세 번째 논문은 모델 내부의 '가치 축' 발견이라는 흥미로운 결과를 제시한다. Qwen3-8B가 현재 추론이 목표 달성에 얼마나 유효한지 내부적으로 추적한다는 것은, 향후 모델이 스스로 '지금 잘못된 길을 가고 있다'는 것을 인지하고 수정할 수 있는 가능성을 열어준다. 다만 이는 실험실 수준의 발견이며, 프로덕션에 적용되려면 최소 1-2년은 더 필요할 것으로 보인다.

세 논문은 AI 에이전트 평가가 '단일 태스크 벤치마크'에서 '다중 에이전트 상호작용 및 내부 상태 모니터링'으로 패러다임 전환이 필요함을 시사한다. 향후 1년 내 Emergent Misalignment를 탐지하는 상용 도구가 등장할 가능성이 높다.
벤치마크 점수는 '최소 요구 조건'일 뿐, '충분 조건'이 아니다. 실제 워크로드에서의 검증과 다중 에이전트 감사 체계가 더 중요해지고 있다.
오늘의 공통 변수는 'AI 신뢰성의 두 축: 정확성과 보안'이다. Probably는 전자를, M365 Copilot 취약점은 후자를 대표한다. 다음 검증 신호는 Probably의 제품 출시와 Microsoft의 추가 보안 패치 발표다. 실제 워크로드에서의 검증이 남아 있습니다. 도입 전 팀 환경에서 직접 테스트하세요. — SynapWeave · Doru

댓글

이 블로그의 인기 게시물

AI 에이전트 평가의 세 가지 블라인드 스팟 — 벤치마크 오염, 실제 작업, harness 설계 | SynapWeave

Anthropic, Claude Agent SDK 토큰 과금 '일시 중단' — 가격 정책의 함정 | SynapWeave

엔터프라이즈 AI ROI: '토큰 맥싱'의 후폭풍 · AI 네이티브 기업의 조직 설계: 연구가 말하는 것 | SynapWeave