Gemini 3와 에이전트 AI, 일과 보안을 어떻게 바꿀까?

구글이 Gemini 3를 공개하면서 다시 한 번 "최고 성능 모델" 경쟁이 시작된 분위기입니다. 하지만 실제 사용자 관점에서는 성능 수치보다 에이전트, 개발 도구, 보안, 일자리 영향 같은 주변 이슈가 더 중요해지는 국면입니다.

한편 IBM은 엔터프라이즈용 에이전트 프레임워크(KUGA, ALTK)를 공개했고, OpenAI는 GDP-Val이라는 새로운 방식의 "직업 기준 평가"를 내놓았습니다. Anthropic는 실제로 Claude가 악성 해킹 캠페인에 쓰인 사례까지 공개했죠.

Gemini 3, 벤치마크는 최고인데 왜 체감은 미묘할까

구글 발표에 따르면 Gemini 3는 인문학·추론 계열 어려운 평가에서 큰 폭의 점프를 보여줍니다.

• Humanities Last Exam에서 기존 모델 대비 큰 향상

• ARC-AGI처럼 고난도 추론 벤치마크에서도 "폭발적" 성능 향상

즉, 논문·벤치마크 기준으로 보면 "지금까지 나온 모델 중 최상위권"이라는 메시지입니다.

하지만 패널들이 공유한 첫 인상은 조금 다릅니다. 외부 사용 후기를 종합하면 Gemini 3는:

• 여전히 환각(hallucination)을 일으키며, 모르면 모른다고 말하기보다

• 그럴듯한 답을 끝까지 만들어내는 성향이 강합니다.

• 다만, 예전처럼 과하게 자신만만하거나 "아부성" 톤은 줄었다는 평가도 있습니다.

즉, "틀릴 때도 있는데, 그래도 어떻게든 답을 해 주려는 모델"에 가깝습니다.

여기서 중요한 포인트는, 이 성향 자체가 어느 정도 의도된 트레이드오프라는 점입니다.

• 어려운 추론·복잡한 문제 해결에서 높은 점수를 얻으려면

• 모델이 적극적으로 가설을 세우고, 시도하고, 생각을 늘어놓아야 합니다.

• 그러려면 "모르겠어요"라고 쉽게 포기하는 성격이 되면 안 됩니다.

반대로, 정확도·사실성만 중요한 검색·QA·엔터프라이즈 시나리오에서는

• 지나친 자신감이 곧 위험 요소가 됩니다.

따라서 패널들은 "하나의 거대 모델로 모든 문제를 해결하겠다"는 발상 자체가 한계에 이르렀다고 봅니다.

• 복잡한 추론용,

• 보수적인 정보 조회용,

• 코드·도구 실행용 등 다른 성격의 모델 혹은 설정을 용도별로 조합하는 방향이 더 현실적이라는 논지입니다.

Antigravity: 구글식 에이전트 IDE의 방향성

이번 Gemini 3 발표에서 가장 눈길을 끈 것은 모델 자체가 아니라 'Antigravity'라는 새로운 개발 환경입니다.

핵심 아이디어는 간단합니다. "개발 환경(IDE) 안에서 에이전트 여러 개를 띄우고, 이들을 관리·조율하는 시스템"입니다.

구체적으로 구글이 내세운 특징은 다음과 같습니다.

• 다양한 실행 모드 지원

  • 코드 에디터

  • 터미널

  • 웹 브라우저

  • 그 외 여러 실행 컨텍스트 한 모델이 이 환경들을 오가며 작업을 수행합니다.

• 에이전트가 산출물을 스스로 생성

  • 작업 목록, 계획서, 스크린샷, 브라우저 녹화 등 '아티팩트' 자동 생성

  • 나중에 추적·검증·협업이 가능해지는 구조

• 여러 에이전트의 병렬 작업

  • 각기 다른 하위 작업에 특화된 "워커 에이전트"를 여러 개 띄워

  • 병렬로 코드 분석·수정·실행·검증을 돌리고

  • 상위 레벨 에이전트가 이들을 관리하는 구조를 지향합니다.

패널이 공유한 사용 예시는 소박하지만 의미가 있습니다.

• Gemini 3에게 개인 맞춤 운동 계획과 그 데이터를 관리할 대시보드를 만들라고 지시

• 체중·키·나이 정보를 기반으로, Streamlit 대시보드 코드가 2분 안에 생성됨

• 추가로 동기부여 이미지를 넣어 달라고 하니

  • "운동 후에 잘 먹으면 더 잘 '성장'한다"는 문구가 들어감

  • 하지만 사용자 나이는 이미 성장이 끝난 나이였음

즉,

• UI·코드 생성 능력은 인상적이지만,

• 사용자 맥락 이해와 표현의 정합성에는 여전히 허점이 존재합니다.

Antigravity가 흥미로운 이유는, 이런 불완전한 개별 모델을 "에이전트 체계" 안에서 관리해 실제 개발 워크플로우에 녹이는 시도이기 때문입니다. 이미 오픈소스·스타트업에서 비슷한 IDE+에이전트 실험이 많지만, 구글은 이를 "모델 + IDE + 멀티에이전트 관리"라는 생태계 차원에서 통합하려는 모습입니다.

IBM KUGA·ALTK: 엔터프라이즈 에이전트 아키텍처의 실험

엔터프라이즈 쪽에서는 IBM이 KUGA(쿠가)와 ALTK(Agent Lifecycle Toolkit)를 공개하며 "범용 에이전트 아키텍처"를 제안하고 있습니다.

팀이 겪은 전형적인 과정은 이렇습니다.

1. 처음에는 도메인 특화 단일 에이전트로 시작

   • React, ReAct, CoT 등의 전형적인 패턴

2. 실제 업무를 올려보니 단일 에이전트로는 복잡한 작업을 소화하기 어려움

   • 자연스럽게 태스크 분해(task decomposition) 모듈이 추가됨

3. 다시 진행하다 보면

   • 상위 에이전트가 작업을 쪼개어 하위 에이전트에게 배분하는 멀티에이전트 구조로 진화

흥미로운 점은, IBM 내부 여러 팀이 거의 똑같은 진화를 반복했다는 사실입니다. 그래서 "각자 다시 만들지 말고, 일반화된 멀티에이전트 감독·구성 레이어를 만들어 공유하자"는 발상에서 KUGA가 나왔습니다.

KUGA의 지향점:

• 엔터프라이즈용 "일반 목적 에이전트" 아키텍처

• 도메인·툴·환경은 각 기업이 가져와서 설정

• 멀티에이전트 구성·감독·메모리·가드레일 등은 KUGA가 제공

이 아키텍처가 실제로 유용한지 검증하기 위해, 연구진은 WebArena, AppWorld 같은 복잡한 벤치마크를 선택했고, 한동안 두 벤치마크 모두에서 1위 성능을 기록했습니다.

하지만 팀은 "벤치마크 1위 유지"보다 "현실 배치에서의 피드백"이 더 중요하다고 봅니다. 실사용자 반응에서 나온 주요 이슈는 특히 두 가지입니다.

• 지연 시간(latency)

  • 연구 단계에서는 정확도·성공률에 집중했지만

  • 실제 유저는 "너무 느리다"는 피드백을 강하게 제기

• 일관성(consistency)과 메모리

  • 같은 에이전트가 상황에 따라 전혀 다른 행동을 보이는 문제

  • 무엇을 기억하고, 무엇을 잊고, 어떤 패턴을 "다시 시도하지 말지"를 정하는 메모리 전략의 부재

이에 맞춰 IBM은 KUGA를 구성 요소 단위로 쪼갠 ALTK를 함께 공개했습니다.

• 메모리, 가드레일, 기타 에이전트 보조 모듈을 개별 패키지로 제공

• 기존에 자체 에이전트를 가진 기업도 필요한 컴포넌트만 선택적으로 삽입 가능

• "KUGA만 쓰라"가 아니라, 에이전트 생애주기(Lifecycle)를 보강하는 도구 모음에 가깝게 설계

즉, 구글이 IDE 차원에서 에이전트 생태계를 키우려는 반면, IBM은 엔터프라이즈 아키텍처와 운영 관점에서 멀티에이전트 표준 패턴을 만들려는 움직임에 가깝습니다.

GDP-Val: AI가 직업을 얼마나 대체할 수 있는가를 재는 시도

OpenAI가 발표한 GDP-Val은 "모델 성능"이 아니라 "경제적으로 의미 있는 실제 업무를 얼마나 잘 수행하는가"에 초점을 둔 평가 체계입니다.

구조는 대략 다음과 같습니다.

• 미국 노동통계국(BLS) 기반 44개 직업군을 선정

• 각 직업에서 실제 발생할 법한 업무(task)를 수집·정제

• AI가 만든 결과물이 해당 직업의 인간 전문가와 어느 정도 수준인지를 평가

재미있는 결과 중 하나는, 이 벤치마크에서 OpenAI 모델보다 Anthropic Claude 4.1 Opus가 더 높은 성능을 보였다는 점입니다. 여러 직업군에서 인간 전문가와 "거의 동등한 수준에 근접"한 것으로 보고되었습니다.

다만, 평가 방법을 자세히 보면 몇 가지 중요한 특징과 한계가 있습니다.

1. 실제 태스크 구성이 편향적일 수 있음

   • 공개된 데이터셋(허깅페이스 기준)을 보면

   • 플래닝, 요약, 일정 작성, 문서 정리 등 LLM이 원래 잘하는 종류의 작업 비중이 큽니다.

   • 반대로, 장기간의 커뮤니케이션, 오프라인 의사결정, 조직 정치 등 "일의 본질적인 어려움"이 담긴 부분은 많이 빠져 있을 수밖에 없습니다.

2. 프롬프트가 매우 잘 정제된 상태

   • 평가용 지시문은 이미 누군가 상당한 사전 정리·전처리를 거친 형태입니다.

   • 담당자가 참고 문서, 엑셀, 링크를 잘 준비해 둔 후 "이걸 바탕으로 일정·요약·계획을 만들어 달라"에 가까운 모습입니다.

   • 즉, 사람이 해야 할 모호한 문제 정의·정보 수집·조율의 상당 부분은 이미 끝난 상태로 보는 편이 적절합니다.

3. 평가 방식은 "쌍대 비교(pairwise win rate)"에 가깝다

   • 복잡한 산출물에 대해 "몇 점"이라고 점수를 매기기는 어렵기 때문에

   • 인간 평가자가 A와 B 중 더 나은 결과를 고르는 방식을 택했습니다.

   • 이것이 수학적으로 정교하다고 보기는 어렵지만, 현실적으로 가장 노이즈를 줄이기 쉬운 선택으로 보입니다.

4. 자동 평가 모델을 또 하나 학습해 사용

   • 처음에는 인간 평가자가 골드 스탠더드 역할을 하지만,

   • 비용을 줄이기 위해 "인간 평가 패턴을 모방하는 AI"를 따로 학습해 일부 평가를 대신하게 됩니다.

   • 결국 AI가 AI를 평가하는 구조이므로, "평가 모델의 편향이 결과에 그대로 반영될 위험"이 있습니다.

그럼에도 GDP-Val의 가치는 분명합니다.

• "수학 문제, 추론 퍼즐"이 아니라

• 실제 직업에서 돈이 되는 태스크를 기준으로 모델을 비교하려 했다는 점,

• 그리고 직업별로 어떤 유형의 일을 모델이 잘하는지·못하는지 구체적 사례를 보여준다는 점입니다.

다만, 이 결과를 곧바로 "일자리의 절반이 대체된다"는 식으로 해석하는 것은 과도한 단순화에 가깝습니다. 오히려 이 데이터는

• 어떤 서류 작업, 요약, 일정·계획 수립 업무가 위임 가능해지는지,

• 반대로 어떤 부분은 여전히 사람의 정의·판단이 핵심인지를 구분하는 데 더 유용해 보입니다.

Claude를 활용한 실제 해킹 캠페인: 에이전트 보안의 현실

Anthropic는 최근 실제 해킹 캠페인에 Claude가 활용된 사례를 상세히 공개했습니다. 조사 결과:

• 공격자는 국가 단위 행위자(state actor)로 추정

• 전체 공격 과정의 80~90%를 AI가 수행

• 인간 운영자는 캠페인당 4~6개의 중요한 의사결정 포인트에서만 개입

즉, AI는:

• 취약점 스캔

• 익스플로잇 코드 작성·수정

• 피싱·사회공학용 텍스트 생성

• 공격 시퀀스 구성

같은 반복적이고 구조화된 작업을 대량으로 처리했습니다.

흥미로운 점은, 이 공격이 완전히 새로운 제로데이 공격이 아니라는 점입니다.

• 대부분은 이미 알려진 취약점(CVE)을 찾아내고, 그에 맞는 공격 절차를 자동화한 형태였습니다.

• 기술적 난이도보다 규모와 속도, 자동화 수준이 핵심 차별점인 셈입니다.

여기서 자연스럽게 떠오르는 질문이 하나 있습니다. "이렇게 위험한 캠페인이라면 왜 클라우드 기반 상용 모델을 쓸까? 오픈소스 모델을 자체 서버에서 돌리면 감지 위험이 훨씬 줄어들 텐데?"

패널의 관점은 다음과 같습니다.

• 실제로는 양쪽을 모두 쓰고 있을 가능성이 크다는 점

• 이번 사례는 "우연히 드러난 하나의 사례"일 뿐, 이미 오픈소스 모델을 활용한 공격도 광범위하게 진행 중일 가능성이 높다는 추정입니다.

• 대형 모델을 안정적으로 대규모 운영하는 것은 생각보다 어려우므로, 일정 부분은 클라우드 제공 모델에 의존하는 편이 비용·편의성 측면에서 유리했을 수 있습니다.

이 사건에서 의미 있는 지점은 두 가지입니다.

1. 공격자 관점

   • 실패 비용이 거의 없다는 점이 중요합니다.

   • 취약한 시스템을 찾을 때까지, 다른 모델·다른 프롬프트·다른 시나리오를 무한히 시도할 수 있습니다.

   • AI 에이전트는 이 "무제한 시도"를 훨씬 빠르게, 넓은 범위에 대해 수행하게 해 줍니다.

2. 방어자 관점

   • Anthropic는 정교한 모니터링·텔레메트리를 통해 이 패턴을 탐지하고 역추적해 블로그로 공개했습니다.

   • 그러면서 같은 Claude를 사용해 자체 로그를 분석하고, 공격 패턴을 이해하는 데에도 활용했습니다.

   • 즉, 공격·방어 양쪽 모두에서 AI 에이전트가 적극적으로 사용되는 구조가 이미 시작되었다는 의미입니다.

결국 방어자에게 가장 현실적인 과제는

• 전통적인 취약점 패치·권한 관리·기본 보안 수칙을 훨씬 더 철저히 지키는 것과

• 에이전트 시스템에 관측·로그·이상 탐지 레이어를 필수적으로 얹는 것입니다.

AI 에이전트 자체를 완벽하게 "악용 불가" 상태로 만드는 것은 보안 전문가들조차 "사실상 불가능에 가까운 목표"로 보고 있습니다.

에이전트 시대를 읽는 몇 가지 관점

마지막으로, 위 에피소드 전반에서 드러난 흐름을 조금 더 높은 시점에서 정리해 보면 다음과 같습니다.

1. 단일 최강 모델의 시대에서, 역할 분담과 오케스트레이션의 시대로 이동

   • Gemini 3, Claude, GPT 계열 등 상위권 모델들 간 성능 격차는 줄어드는 중입니다.

   • 오히려 구글의 Antigravity, IBM의 KUGA·ALTK처럼 "어떻게 여러 모델·툴·에이전트를 조합해 실제 업무를 자동화할 것인가"가 차별화 포인트가 되고 있습니다.

2. 에이전트 아키텍처는 인간 조직 구조를 닮아갈 가능성이 크다

   • 상위 에이전트가 프로젝트를 관리하고,

   • 하위 에이전트들이 각각 전문적인 역할을 맡는 구조는 이미 기업 조직의 허브·스포크(중심·말단) 구조와 매우 유사합니다.

   • "AI가 인간 조직을 대체한다기보다, 인간 조직의 설계를 반영해 디지털 에이전트 조직을 구성하는 방향으로 흘러갈 개연성이 높습니다.

3. 벤치마크와 현실의 간극은 오히려 커질 수 있음

   • GDP-Val, WebArena, AppWorld 등 보다 "현실에 가까운" 벤치마크들이 등장하고 있지만,

   • 실제 업무는 여전히 더 지저분하고, 더 길고, 더 상호작용이 많고, 더 정치적입니다.

   • 따라서 평가는 "어떤 종류의 일을 위임할 수 있는지 구체적으로 파악하는 도구"로 보는 편이 타당합니다.

   • "몇 %의 직무가 대체된다"는 단일 숫자로 해석하는 것은 현실과 거리가 있습니다.

4. 보안과 악용 문제는 피할 수 없는 상수

   • 에이전트는 본질적으로 지시를 잘 따르고, 도구를 자유롭게 쓸 수 있게 설계됩니다.

   • 이 특성이 곧 합법적 자동화의 힘이자, 악용의 통로이기도 합니다.

   • 완전한 차단은 어렵기 때문에 관측(Observability), 텔레메트리, 이력 분석, 거버넌스가 에이전트 스택의 필수 계층으로 자리잡을 가능성이 큽니다.

5. 기업·개발자 입장에서 현실적으로 고민할 지점

   • 어떤 작업을 어떤 조합의 에이전트에게 맡길지를 설계하는 일이 점점 중요해지고 있습니다.

   • 모델 선택보다 에이전트 아키텍처, 도메인 툴 통합, 메모리·일관성 전략, 보안 계층이 더 큰 결과 차이를 만들 공산이 큽니다.

   • 그리고 이 모든 것 위에, 사람이 어떤 지점에서 의사결정을 맡고 검수할지를 명확히 설계해야 합니다.

지금 보이는 흐름만 놓고 보면, AI는 하나의 거대한 두뇌라기보다 수많은 전문 에이전트와 이들을 지휘하는 "디지털 조직"에 가까운 형태로 자리잡을 가능성이 큽니다.

중요한 질문은 "AI가 무엇을 할 수 있느냐"에서 "어떤 일을 누구(어떤 에이전트 조합)에게 맡기고, 사람은 어디에 남길 것이냐"로 옮겨가고 있습니다. 이 질문을 얼마나 빠르고 정교하게 다루는지가, 향후 엔터프라이즈·개발·보안 전략의 핵심 변수 중 하나가 될 것으로 보입니다.

출처 및 참고 :