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

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

---

1️⃣ 주요 모델·연구

DeepSeek, 코딩·에이전트 성능을 개선한 ‘DeepSeek-V4.1-Flash-1017’ 공개…프로젝트 생성 능력 강화하고 실행 비용 절감

• 발표일: 2026-10-17 — 정확한 게시 시각 미확인
• 적용 범위: 오픈웨이트 LLM, 코딩 에이전트, 멀티모달 AI, 소프트웨어 자동 개발, 강화학습, 모델 추론 비용 최적화
• 원문: DeepSeek — DeepSeek-V4.1-Flash-1017: Wish-Driven Programming Made Real
• 관련 원문: Hugging Face — DeepSeek-V4.1-Flash-1017 모델 카드

중국 AI 기업 DeepSeek이 기존 DeepSeek-V4.1-Flash의 추론과 코딩, 에이전트 작업 성능을 개선한 DeepSeek-V4.1-Flash-1017을 공개했다.

이번 모델은 완전히 새로운 아키텍처를 도입한 차세대 모델이 아니라 지난 9월 공개된 V4.1-Flash의 후속 업데이트다.

DeepSeek은 기존 모델의 주요 구조를 유지하면서 복잡한 작업의 성공률을 높이고, 작업을 완료하는 데 필요한 시간과 출력 토큰을 줄이는 데 집중했다고 설명한다.

새 모델은 10월 17일부터 DeepSeek 웹사이트와 모바일 앱, API에서 사용할 수 있으며 모델 가중치도 Hugging Face와 ModelScope에 공개됐다.

이번 발표에서 특히 강조한 방향은 Wish-Driven Programming, 즉 사용자가 원하는 결과를 자연어로 설명하면 AI가 프로젝트를 구성하고 실제 결과물까지 만드는 개발 방식이다.

코드를 작성하는 능력에서 프로젝트를 완성하는 능력으로

기존의 AI 코딩 도구는 개발자가 작성 중인 코드의 일부를 자동완성하거나 특정 함수의 구현을 제안하는 방식으로 발전했다.

하지만 최근 코딩 에이전트는 훨씬 긴 작업을 수행한다.

예를 들어 사용자가 브라우저에서 실행되는 레이싱 게임을 만들어 달라고 요청했다고 가정해 보자.

에이전트는 단순히 게임 캐릭터를 움직이는 함수 하나를 생성하는 것으로 작업을 완료할 수 없다.

게임 화면과 입력 처리, 물리적 움직임, 충돌 판정, 점수 계산과 게임 종료 조건을 함께 구현해야 한다.

이후 실제로 게임을 실행하고 오류가 발생하면 수정해야 한다.

이처럼 여러 단계를 거쳐 최종 결과물을 완성하는 작업을 End-to-End Task(종단 간 작업)라고 한다.

DeepSeek은 새로운 모델의 학습 과정에서 이런 프로젝트 단위의 작업 수행 능력을 강화했다고 설명한다.

여기에는 Reinforcement Learning(RL, 강화학습)과 Self-Feedback(자기 피드백)이 사용됐다.

강화학습은 모델이 행동한 결과를 평가하고, 더 높은 보상을 얻는 방향으로 행동 전략을 개선하는 학습 방식이다.

자기 피드백은 모델이 생성한 결과를 다시 검토하거나 실행 결과를 확인해 수정 방향을 찾는 과정이다.

예를 들어 AI가 웹 애플리케이션을 생성했다면 실제 실행 결과를 확인하고, 오류가 발견되면 코드를 수정하는 과정을 반복할 수 있다.

DeepSeek은 이런 방식으로 단순 코드 생성뿐 아니라 실제 프로젝트를 완성하기까지 이어지는 일련의 행동을 개선했다고 설명한다.

공식 발표에서는 다음과 같은 결과물을 시연했다.

• 자금성의 건축물을 재현한 3D 모델
• 브라우저에서 실행되는 레이싱 게임
• Godot 엔진을 이용한 Portal 2 재현 프로젝트
• 선사시대부터 현대까지의 변화를 표현한 3D 장면

Godot은 게임과 인터랙티브 애플리케이션을 개발하는 데 사용하는 오픈소스 게임 엔진이다.

여기서 중요한 점은 시연 영상만으로 일반적인 프로젝트 개발 성공률을 판단할 수는 없다는 사실이다.

공개된 예시는 모델이 수행할 수 있는 작업의 범위를 보여주지만, 임의의 요구사항을 전달했을 때 얼마나 자주 완성된 결과물을 만드는지는 별도의 평가가 필요하다.

DeepSeek은 이를 보완하기 위해 여러 코딩·에이전트 벤치마크 결과도 공개했다.

Terminal-Bench와 실제 코딩 평가에서 성능 개선

이번 업데이트의 핵심은 모델이 실제 개발 환경에서 작업을 수행하는 능력이 개선됐다는 점이다.

DeepSeek이 공개한 비교 결과는 다음과 같다.

가장 큰 변화 가운데 하나는 Terminal-Bench 4.0에서 나타났다.

Terminal-Bench는 언어모델이 실제 터미널 환경에서 명령어를 실행하고, 파일을 수정하고, 여러 단계의 작업을 수행할 수 있는지 평가하는 벤치마크다.

일반적인 코딩 문제처럼 함수 하나의 출력을 채점하는 것과 다르다.

에이전트가 실제 작업 환경에서 어떤 명령을 실행하고, 오류를 어떻게 해결하며, 최종 상태를 올바르게 만드는지를 확인한다.

이번 평가에서는 31.2%에서 42.3%로 11.1%포인트 향상됐다.

DeepSeek은 Terminal-Bench 4.0 평가에 Claude Code 하네스를 사용했다고 밝혔다.

Harness(하네스)는 언어모델에 파일 읽기, 터미널 실행, 코드 수정 등의 도구를 제공하고 실제 실행 과정을 관리하는 소프트웨어 계층이다.

같은 언어모델이라도 어떤 하네스와 도구를 사용하는지에 따라 작업 성공률이 달라질 수 있다.

따라서 코딩 에이전트를 비교할 때는 모델 자체의 차이뿐 아니라 평가에 사용한 실행 환경도 확인해야 한다.

DeepSWE v1.1에서도 성능이 개선됐다.

DeepSWE는 실제 소프트웨어 저장소의 복잡한 개발 작업을 해결하는 능력을 평가한다.

새 모델은 이 평가에서 77.0%를 기록했다.

기존 모델의 74.2%보다 2.8%포인트 높은 결과다.

이번 모델 카드에는 GPT-5.6 Sol과 Claude Opus 5의 비교 결과도 포함됐다.

DeepSeek이 공개한 동일 평가표에서 GPT-5.6 Sol은 73.0%, Claude Opus 5는 74.0%였다.

다만 이 수치를 모든 코딩 에이전트에서 DeepSeek이 두 모델보다 우수하다는 의미로 해석해서는 안 된다.

모델마다 추론 설정과 도구 사용 방식, 작업당 비용이 다를 수 있으며 다른 벤치마크에서는 순위가 달라진다.

실제로 Terminal-Bench 4.0에서는 Claude Opus 5가 51.8%로 새 DeepSeek 모델보다 높은 점수를 기록했다.

ProgramBench에서도 Claude Opus 5가 37.0%로 DeepSeek의 29.1%보다 높았다.

반면 DeepSeek은 일부 자동화·코딩 평가에서 경쟁력 있는 결과를 보여준다.

이처럼 모델의 성능을 비교할 때는 하나의 종합 점수보다 실제로 수행하려는 작업과 가까운 평가 결과를 살펴볼 필요가 있다.

모든 성능 수치는 DeepSeek이 공개한 평가 결과다.

외부에서 개발한 벤치마크를 사용했더라도 이번 비교표의 모든 모델별 실행 결과가 독립적으로 재검증됐다는 의미는 아니다.

에이전트 자동화와 장기 작업에서도 개선

코딩 외의 에이전트 작업에서도 성능 향상이 나타났다.

Automation-Bench v1.0.6에서는 기존 54.8%에서 60.5%로 개선됐다.

Automation-Bench는 여러 애플리케이션과 도구를 사용하는 실제 업무 자동화 능력을 평가한다.

예를 들어 사용자의 요청을 분석한 뒤 필요한 정보를 조회하고, 여러 작업을 연결하고, 최종 결과를 만드는 과정을 포함한다.

여기서는 단순한 지식의 양보다 어떤 도구를 언제 사용해야 하는지 결정하는 능력이 중요하다.

또 다른 평가인 Agents' Last Exam에서는 31.8%에서 35.4%로 개선됐다.

이 벤치마크는 여러 산업의 복잡한 업무를 에이전트가 장시간 수행할 수 있는지 평가한다.

하나의 답변을 생성하는 작업보다 복잡한 계획과 여러 단계의 실행이 필요하다.

이런 평가에서 성능이 높아졌다는 사실은 새 모델이 도구를 사용하는 작업에서 더 좋은 결과를 만들 가능성이 있다는 의미다.

그러나 실제 기업의 업무 자동화 환경에서 같은 성공률을 보장하는 것은 아니다.

실제 업무에는 사용자별 접근권한과 데이터 품질, 예외적인 상황 등 벤치마크에서 충분히 다루지 못한 조건이 존재할 수 있기 때문이다.

멀티모달 이해 능력도 개선

DeepSeek-V4.1-Flash-1017은 텍스트뿐 아니라 이미지를 함께 이해하는 멀티모달 모델이다.

멀티모달 AI는 텍스트, 이미지, 음성, 영상처럼 서로 다른 형태의 정보를 함께 처리하는 기술을 의미한다.

이번 모델 카드에서는 시각적 정보를 이해하는 여러 벤치마크에서도 성능이 개선됐다고 밝혔다.

대표적인 결과는 다음과 같다.

Chartography는 그래프와 시각적인 데이터를 이해하는 능력을 평가한다.

BabyVision은 시각적 패턴과 공간적 관계를 이해하는 능력에 초점을 맞춘 평가다.

이런 능력은 단순한 이미지 설명뿐 아니라 실제 개발 환경에서도 활용될 수 있다.

예를 들어 코딩 에이전트가 웹페이지의 스크린샷을 확인하면서 레이아웃 오류를 수정하거나, 차트 이미지를 분석해 데이터에 관한 질문에 답하는 작업이 가능하다.

다만 새 모델은 기존 DeepSeek-V4.1-Flash의 후속 업데이트이므로, 이번 발표에서 멀티모달 처리 구조 자체가 완전히 새롭게 설계됐다고 볼 근거는 없다.

모델 카드가 강조하는 변화는 기존 구조 위에서 평가 성능과 작업 효율을 높였다는 점이다.

긴 답변을 줄이고 작업 효율 개선

DeepSeek은 이번 모델이 기존 버전보다 작업을 완료하는 데 필요한 시간과 출력 길이를 줄였다고 설명한다.

언어모델의 비용은 입력과 출력에 사용한 Token(토큰) 수에 영향을 받는다.

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

일반적인 생성형 모델은 입력을 처리한 뒤 다음 토큰을 하나씩 생성하면서 답변을 완성한다.

답변이 길어질수록 추가적인 계산이 필요하다.

코딩 에이전트에서는 이런 비용이 더 크게 나타날 수 있다.

예를 들어 에이전트가 하나의 오류를 수정하면서 파일을 여러 번 읽고, 도구를 호출하고, 테스트를 실행한다면 모델 호출도 여러 번 발생한다.

각 단계에서 불필요하게 긴 설명을 생성하거나 잘못된 도구 호출을 반복하면 작업 전체의 비용과 시간이 증가한다.

DeepSeek은 새 모델이 이런 작업에서 더 높은 성공률을 유지하면서 출력 길이와 실행 시간을 줄이는 방향으로 개선됐다고 밝혔다.

이런 성능과 비용 사이의 균형을 Pareto Frontier(파레토 최적 경계)라는 개념으로 설명한다.

일반적으로 성능이 높아지면 비용도 증가하는 경우가 많다.

반대로 비용을 줄이면 성능이 떨어질 수 있다.

하지만 같은 비용에서 성능이 높아지거나, 같은 성능에서 비용이 줄어든다면 기존보다 더 좋은 선택지가 만들어진다.

DeepSeek은 이번 업데이트가 이러한 성능·비용 관계를 개선했다고 주장한다.

다만 공식 모델 카드에는 모든 벤치마크에서 실제 소요 시간과 토큰 수가 얼마나 감소했는지를 확인할 수 있는 상세 수치가 함께 제공되지는 않았다.

따라서 특정 비율의 비용 절감을 모든 작업에 적용할 수 있다고 단정해서는 안 된다.

MIT 라이선스로 가중치 공개

새 모델의 가중치는 MIT 라이선스로 공개됐다.

MIT는 상업적 사용과 수정, 재배포를 폭넓게 허용하는 라이선스다.

개발자는 모델을 자체 인프라에서 실행하거나 조직의 데이터에 맞게 추가 학습할 수 있다.

또한 모델 카드에는 여러 차례의 대화, 도구 호출, 추론 모드와 이미지 입력을 처리하는 프롬프트 형식이 공개됐다.

DeepSeek은 이를 위한 Python 참조 구현과 Rust 기반의 deepseek-recipe 라이브러리도 제공한다.

deepseek-recipe는 여러 API 형식의 요청을 DeepSeek 모델에 맞는 입력 구조로 변환하고, 모델의 출력을 다시 애플리케이션에서 사용할 수 있는 형태로 해석하는 도구다.

지원 대상에는 Chat Completions와 Responses API 형식이 포함된다.

모델 추론 자체와 도구 실행, HTTP 통신은 이를 사용하는 애플리케이션이 별도로 구성해야 한다.

DeepSeek은 코딩 에이전트 실행 환경인 DeepSeek Harness v0.2.1-rc.1 이상의 사용도 권장했다.

이번 발표는 코딩 에이전트의 성능 경쟁이 단순히 더 많은 코드를 생성하는 방향에서 벗어나고 있다는 점을 보여준다.

실제 프로젝트를 얼마나 완성할 수 있는지, 여러 도구를 얼마나 정확하게 사용하고, 작업당 어느 정도의 시간과 비용을 소비하는지가 중요한 평가 기준으로 자리 잡고 있다.

---

2️⃣ AI 제품·서비스

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

---

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

DeepSeek, 자체 검색 엔진 기반 ‘Search & Fetch API’ 일반 공개…코딩 에이전트가 실시간 웹 정보를 직접 검색·수집

• 발표일: 2026-10-17 — 정확한 게시 시각 미확인
• 적용 범위: AI 에이전트, 웹 검색 API, RAG, 코딩 도구, DeepSeek API, 정보 수집 자동화
• 원문: DeepSeek — Search & Fetch 공식 개발자 문서
• 관련 원문: DeepSeek — DeepSeek-V4.1-Flash-1017 발표

DeepSeek이 자체 검색 엔진을 기반으로 한 Search API와 Fetch API를 모든 개발자에게 공개했다.

이번 발표는 DeepSeek-V4.1-Flash-1017 모델 업데이트와 함께 이뤄졌지만, 모델 성능 개선과는 별개의 API 기능 확대다.

그동안 AI 개발에서 중요한 과제 가운데 하나는 언어모델이 학습하지 않은 최신 정보를 어떻게 가져올 것인가였다.

언어모델은 사전학습 과정에서 수많은 문서와 코드를 학습한다.

하지만 모델이 학습한 뒤 새롭게 공개된 기술 문서나 뉴스, 소프트웨어 변경사항은 모델의 파라미터에 자동으로 반영되지 않는다.

예를 들어 개발자가 오늘 공개된 라이브러리의 새로운 API 사용 방법을 질문하면 모델이 과거 버전의 사용법을 설명할 수 있다.

이 문제를 해결하기 위해 사용되는 대표적인 기술이 RAG(Retrieval-Augmented Generation)다.

RAG는 모델이 답변을 생성하기 전에 질문과 관련된 외부 정보를 검색해 입력에 추가하는 방식이다.

이번 DeepSeek API는 이런 외부 정보 검색과 웹페이지 수집을 공식적으로 지원한다.

Search API와 Fetch API의 역할

두 API는 서로 다른 역할을 담당한다.

Search API는 검색어와 관련된 웹페이지를 찾아 구조화된 결과를 반환한다.

개발자는 검색어와 반환받을 결과 수, 페이지 본문을 함께 가져올지 등을 설정할 수 있다.

결과 수는 한 번의 요청에서 1~50개 사이로 지정할 수 있다.

Search API가 반환하는 정보에는 다음과 같은 항목이 포함될 수 있다.

• 웹페이지의 제목과 URL
• 검색 결과의 요약과 관련성 점수
• 페이지의 게시일
• 출처 웹사이트
• 검색 결과의 신뢰도 등급
• 선택적으로 포함되는 페이지 본문

검색 결과에는 Rerank Score(검색 결과의 관련성을 평가하는 점수)도 제공된다.

Reranking은 처음 검색된 여러 자료의 순서를 질문과의 관련성에 따라 다시 결정하는 과정이다.

DeepSeek은 관련성, 출처의 신뢰도와 정보의 최신성을 결합해 점수를 계산한다고 설명한다.

하지만 높은 점수를 받은 검색 결과가 반드시 사실이라는 뜻은 아니다.

검색 관련성은 해당 자료가 질문과 얼마나 관련 있는지를 나타낼 뿐, 자료에 포함된 모든 주장이 정확하다는 보장은 아니다.

Fetch API는 이미 알고 있는 URL의 웹페이지를 가져오는 기능이다.

이 API는 웹페이지의 내용을 Markdown 형식으로 반환한다.

Markdown은 제목과 문단, 목록, 링크 등을 비교적 간결한 텍스트 문법으로 표현하는 방식이다.

일반적인 HTML 문서에는 실제 내용뿐 아니라 화면 배치와 스타일, 메뉴 등을 표현하는 코드가 포함된다.

반면 Markdown으로 변환하면 언어모델이 읽어야 하는 불필요한 정보의 양을 줄일 수 있다.

따라서 AI 에이전트가 기술 문서를 읽거나 여러 웹페이지를 분석하는 작업에 적합하다.

검색과 본문 수집을 분리한 구조

두 기능을 별도의 API로 제공하는 이유는 검색과 페이지 분석의 목적이 다르기 때문이다.

예를 들어 사용자가 특정 기술의 최신 변경사항을 조사해 달라고 요청했다고 가정해 보자.

에이전트는 먼저 Search API를 이용해 관련 문서를 찾는다.

검색 결과의 제목과 요약, 게시일을 확인한 뒤 실제로 읽어야 할 문서를 선택할 수 있다.

이후 Fetch API를 이용해 선택한 문서의 본문을 가져온다.

이렇게 하면 검색된 모든 페이지의 전문을 무조건 가져올 필요가 없다.

AI 에이전트가 처리해야 하는 데이터의 양과 모델의 입력 토큰 사용량을 줄이는 데 도움이 될 수 있다.

개발자는 Search API에서 need_content 옵션을 사용해 검색 결과와 본문을 함께 요청할 수도 있다.

즉 작업의 특성에 따라 검색 결과만 받아오거나, 본문을 함께 가져오거나, 필요한 페이지를 나중에 별도로 읽는 방식을 선택할 수 있다.

검색어의 범위와 언어를 제어

Search API는 여러 검색 연산자를 지원한다.

예를 들어 특정 웹사이트의 문서만 검색하거나 특정 언어의 자료를 우선적으로 찾을 수 있다.

게시일을 기준으로 검색 결과를 제한하는 기능도 제공한다.

검색 연산자는 개발자가 원하는 자료의 범위를 좁히는 데 사용된다.

예를 들어 최근 일주일 동안 공개된 공식 문서를 조사한다면 날짜 제한과 도메인 제한을 함께 활용할 수 있다.

이는 최신성이 중요한 AI 브리핑이나 기술 문서 분석에서 유용한 기능이다.

다만 검색 API가 게시일을 반환한다고 해서 모든 웹페이지의 실제 공개 시각을 정확하게 확인할 수 있다는 의미는 아니다.

웹사이트가 날짜 정보를 잘못 표시하거나 수정일을 게시일로 제공할 가능성도 있다.

따라서 게시 시각이 중요한 작업에서는 원문과 검색 결과의 메타데이터를 함께 확인하는 것이 필요하다.

API 가격과 무료 사용 범위

DeepSeek은 Search API와 Fetch API의 가격을 동일하게 책정했다.

단순 계산하면 호출 한 번당 0.00075달러다.

이 가격은 검색 또는 페이지 수집 API를 호출하는 비용이다.

검색 결과를 언어모델에 전달하고 답변을 생성하는 과정에서 발생하는 모델 API 비용은 별도로 고려해야 한다.

DeepSeek은 일부 코딩 에이전트에서 사용하는 검색·수집 기능을 일정 기간 무료로 제공한다.

대상에는 DeepSeek Harness, Claude Code, Codex 등이 포함된다.

다만 DeepSeek API 사용자가 서버 측 도구 호출을 통해 해당 기능을 사용하는 경우에 적용되는 조건이다.

모든 사용자가 별도의 제한 없이 무료 검색 API를 호출할 수 있다는 의미는 아니다.

DeepSeek은 이 경로의 유료 과금을 2026년 10월 31일 16:00 UTC, 한국 시간으로 11월 1일 01:00 KST부터 시작한다고 밝혔다.

검색 결과를 신뢰하는 것과 검색 결과를 실행하는 것은 다르다

AI 에이전트가 실시간 웹페이지를 읽게 되면 새로운 보안 문제도 발생한다.

대표적인 공격이 Prompt Injection(프롬프트 인젝션)이다.

Prompt Injection은 AI 모델이 읽는 문서나 웹페이지에 악의적인 지시를 숨겨, 모델이 원래 사용자의 요청과 다른 행동을 하도록 유도하는 공격이다.

예를 들어 에이전트가 라이브러리의 사용 방법을 찾기 위해 웹페이지를 읽는다고 가정해 보자.

정상적인 페이지에는 설치 방법과 API 설명이 포함된다.

하지만 공격자가 조작한 페이지에는 특정 파일을 외부 서버로 전송하라는 지시가 포함될 수 있다.

모델이 외부 문서에 포함된 내용을 사용자의 지시와 같은 수준으로 취급하면 문제가 발생할 수 있다.

따라서 Search API와 Fetch API를 에이전트에 연결할 때는 외부 자료를 참고 정보로 취급하고, 실제 파일 수정이나 명령 실행 권한과 분리하는 설계가 필요하다.

이번 API는 웹 검색과 수집 기능을 제공하지만, 검색된 자료의 사실성과 안전성을 자동으로 보장하지는 않는다.

DeepSeek은 웹페이지의 접근 가능 여부와 보안 정책에 따라 Fetch 요청이 거부될 수 있다고 명시했다.

이번 발표는 언어모델 제공업체가 모델 자체뿐 아니라 에이전트가 외부 세계의 정보를 가져오는 기본 도구까지 직접 제공하는 방향으로 확장되고 있음을 보여준다.

최근 AI 에이전트의 품질은 모델의 추론 능력만으로 결정되지 않는다.

어떤 정보를 검색하고, 얼마나 정확하게 수집하며, 수집한 자료를 실제 작업에 어떻게 연결하는가도 중요한 요소가 되고 있다.

---

4️⃣ 산업·정책·안전

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

---

📚 추천 글

Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore

• 저자: Rui Li, Alok Singh, Bharathi Srinivasan, Chandana Srinivas, Mihir Gadgil, Madhu Samhitha Vangara
• 발행: AWS Artificial Intelligence Blog
• 게시일: 2026-10-16
• 원문: AWS — Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore

AI 에이전트가 실제 서비스에 배포된 이후에도 계속 올바르게 작동하고 있는지 어떻게 확인할 수 있을까?

이 글은 AWS가 실제 기업용 멀티에이전트 시스템을 운영하면서 구축한 9단계 평가 프레임워크를 설명한다.

AI 에이전트의 개발 과정과 배포 과정, 실제 운영 환경을 하나의 검증 체계로 연결했다는 점에서 읽어볼 가치가 있다.

특히 일반적인 웹 서비스의 오류 모니터링과 AI 에이전트의 품질 모니터링이 어떻게 다른지 구체적으로 보여준다.

일반적인 서비스는 오류가 발생하지만 AI 에이전트는 조용히 잘못될 수 있다

전통적인 웹 애플리케이션에서는 서버가 정상적으로 작동하는지 확인하기 위해 여러 지표를 사용한다.

예를 들어 HTTP 응답 시간이 갑자기 길어지거나 500 오류가 증가하면 서비스에 문제가 발생했다고 판단할 수 있다.

사용자가 로그인할 수 없거나 주문 API가 실패하는 상황도 비교적 명확하게 발견된다.

하지만 AI 에이전트에서는 다른 문제가 발생할 수 있다.

모델이 여전히 정상적으로 응답하고, API 오류도 발생하지 않으며, 응답 시간도 이전과 비슷한데 답변의 정확도만 떨어질 수 있기 때문이다.

예를 들어 영업팀이 고객의 매출 정보를 질문했는데 에이전트가 실제로는 다른 고객의 데이터를 반환했다고 가정해 보자.

데이터베이스 조회는 성공했다.

모델도 정상적인 문장을 생성했다.

사용자에게는 오류 메시지가 나타나지 않는다.

하지만 최종 답변은 잘못됐다.

AWS는 이런 문제를 Silent Degradation(조용한 품질 저하)이라고 설명한다.

일반적인 서버 모니터링 지표만으로는 이런 오류를 발견하기 어렵다.

따라서 AI 에이전트에는 응답이 정상적으로 생성됐는지뿐 아니라 실제로 올바른 판단과 행동을 수행했는지 평가하는 시스템이 필요하다.

실제 운영 시스템: AWS 영업 조직의 멀티에이전트

이번 글에서 소개하는 시스템은 AWS의 Sales, Marketing, and Global Services 조직이 실제로 사용하는 내부 업무 도구다.

영업 담당자와 관리자가 자연어로 질문하면 여러 전문 에이전트가 필요한 정보를 조사한다.

예를 들어 특정 지역의 매출과 영업 성과를 분석하는 Performance Insights Agent가 있다.

고객에 관한 정보를 분석하는 Customer Insights Agent도 사용된다.

또 다른 Data Insights Agent는 사용자의 자연어 질문을 SQL로 변환해 데이터베이스에서 필요한 정보를 조회한다.

SQL(Structured Query Language)은 데이터베이스에서 데이터를 검색하고 처리하는 데 사용하는 언어다.

이렇게 여러 에이전트가 협력하는 구조를 Multi-Agent System(멀티에이전트 시스템)이라고 한다.

문제는 하나의 하위 에이전트가 잘못된 정보를 반환하면 최종 답변까지 영향을 받을 수 있다는 점이다.

예를 들어 고객 정보를 찾는 에이전트가 서로 다른 두 회사를 같은 회사로 잘못 판단했다면, 매출을 분석하는 에이전트는 올바른 SQL을 실행하더라도 다른 회사의 매출 데이터를 가져올 수 있다.

따라서 최종 답변만 평가해서는 정확한 원인을 찾기 어려울 수 있다.

AWS는 이를 해결하기 위해 도구, 개별 에이전트, 전체 멀티에이전트 시스템을 각각 독립적으로 평가하도록 설계했다.

9단계 평가 프레임워크

AWS의 평가 체계는 아홉 단계로 구성된다.

이 구조는 일반적인 소프트웨어의 CI/CD(지속적 통합 및 지속적 배포)와 연결된다.

CI는 코드 변경이 발생할 때 자동화된 검증을 수행하는 절차다.

CD는 검증된 변경사항을 실제 환경에 배포하는 과정을 의미한다.

AWS는 여기에 AI 모델의 답변 품질과 도구 선택, 안전성 평가를 추가했다.

예를 들어 PR이 생성되면 에이전트가 기존에 올바르게 처리하던 질문을 다시 실행한다.

이때 잘못된 답변이 증가하거나 중요한 도구 호출이 실패하면 변경사항의 배포를 차단할 수 있다.

이런 방식을 Regression Testing(회귀 테스트)이라고 한다.

새로운 기능을 추가한 뒤 이전에는 정상적으로 작동하던 기능에 문제가 발생하지 않았는지 확인하는 과정이다.

15개의 핵심 테스트와 200개의 종합 평가

AWS는 모든 PR에서 전체 평가 데이터셋을 실행하지 않는다.

전체 평가를 수행하면 시간과 비용이 많이 들기 때문이다.

대신 중요한 실패 유형을 대표하는 15개의 Sentinel Test를 사용한다.

Sentinel은 시스템의 중요한 상태를 감시하는 감시자라는 의미다.

이 테스트에는 잘못된 고객 식별이나 매출 집계, 데이터 접근권한 문제처럼 실제 업무에 큰 영향을 주는 사례가 포함된다.

이 단계에서 중요한 품질 문제가 발견되면 PR 병합을 차단한다.

실제 배포 전에는 더 큰 규모의 평가를 수행한다.

AWS는 200개의 검증용 질문을 사용해 새로운 에이전트가 기존 운영 버전보다 좋은 결과를 만드는지 확인한다.

단순히 평균 점수만 비교하지도 않는다.

새 버전의 평균 점수가 높더라도 특정한 중요한 질문에서 실패하는 비율이 증가했다면 배포를 차단할 수 있다.

예를 들어 전체 답변의 평균 정확도가 높아졌지만 금융 데이터를 잘못 처리하는 사례가 증가했다면 새로운 모델을 바로 배포하기 어렵다.

이처럼 평균 점수와 개별 실패 유형을 함께 확인하는 것이다.

실제 운영 중 30분마다 품질 평가

배포가 완료됐다고 해서 평가가 끝나는 것은 아니다.

AWS는 운영 환경에서도 30분 간격으로 에이전트의 품질을 평가한다.

여기서 중요한 설계 선택은 단 한 번의 평가 실패로 즉시 장애 경보를 발생시키지 않는다는 점이다.

언어모델의 결과는 확률적인 특성을 가지고 있어 같은 질문에서도 조금씩 다른 답변이 생성될 수 있다.

이런 특성 때문에 한 번의 평가에서 낮은 점수가 나왔다고 해서 전체 서비스의 품질이 실제로 저하됐다고 판단하기 어렵다.

AWS는 여러 번의 평가 결과를 비교해 지속적인 문제가 발생하는지 확인한다.

연속된 세 번의 평가 구간에서 기준을 위반하면 운영 담당자에게 경보를 전달한다.

AWS는 처음에는 15분 간격으로 평가했지만 잘못된 경보가 지나치게 많이 발생했다고 설명한다.

반대로 60분 간격에서는 실제 문제를 발견하는 데 너무 오래 걸렸다.

이런 경험을 바탕으로 30분 간격을 선택했다.

또한 하루에 한 번 전체 평가 데이터셋을 실행해 장기적인 품질 변화를 확인한다.

모델의 오류를 더 정확하게 찾는 방법

평가 과정에서 문제가 발생하면 AWS는 실행 기록을 분석한다.

이를 Trace(실행 추적 기록)라고 한다.

Trace에는 에이전트가 어떤 도구를 선택했는지, 어떤 순서로 실행했으며, 어떤 입력과 출력을 주고받았는지 기록된다.

AWS는 Amazon CloudWatch와 OpenTelemetry를 이용해 이런 정보를 수집한다.

OpenTelemetry는 애플리케이션의 실행 기록과 성능 지표를 표준화된 방식으로 수집하는 오픈소스 기술이다.

예를 들어 최종 답변에 잘못된 매출 수치가 포함됐다면 다음과 같은 원인을 구분할 수 있다.

데이터베이스에 저장된 원본 데이터가 잘못됐을 수 있다.

모델이 잘못된 SQL을 생성했을 수도 있다.

데이터베이스가 올바른 정보를 반환했지만 모델이 이를 잘못 요약했을 가능성도 있다.

각 상황은 수정해야 하는 위치가 다르다.

따라서 최종 결과가 잘못됐다는 사실만으로는 충분하지 않다.

어느 단계에서 처음 문제가 발생했는지 추적할 수 있어야 한다.

AWS는 이런 평가 체계를 구축한 이후 문제를 발견하는 데 걸리는 평균 시간이 수일에서 수주 수준이던 상태에서 4시간 미만으로 감소했다고 밝혔다.

이는 AWS 내부 운영 사례에서 측정한 결과다.

모든 AI 서비스에서 같은 개선 효과가 보장된다는 의미는 아니다.

실제 오류를 다음 회귀 테스트로 전환

이번 글에서 가장 중요한 부분은 마지막 단계인 Feedback Loop다.

AWS는 실제 서비스에서 발견한 오류를 일회성으로 수정하고 끝내지 않는다.

잘못된 답변을 생성한 질문과 실행 기록을 새로운 평가 데이터로 추가한다.

예를 들어 특정 고객의 회사 이름을 잘못 인식해 다른 고객의 정보를 반환했다면 해당 사례를 이후의 자동화 테스트에 추가한다.

그러면 비슷한 오류가 다시 발생했을 때 배포 전에 탐지할 수 있다.

또한 AWS는 실제 실패 기록을 분석해 시스템 프롬프트와 도구 설명을 개선하는 기능도 사용한다.

System Prompt(시스템 프롬프트)는 언어모델이 작업을 수행할 때 따라야 할 기본 지침이다.

도구 설명은 모델이 어떤 상황에서 특정 함수를 사용해야 하는지 알려주는 정보다.

AWS가 공개한 사례에서는 프롬프트에 포함된 구체적인 매출 금액과 고객 이름이 다른 질문의 답변에 잘못 사용되는 문제가 발생했다.

연구팀은 예시 데이터의 실제 고객 이름과 금액을 일반적인 자리표시자로 변경했다.

그 결과 1만 건당 잘못된 사실 생성 건수가 138건에서 52건 미만으로 감소했고, 근거 기반 응답 비율도 93%에서 96%로 증가했다고 밝혔다.

이 수치 역시 AWS가 자체 운영 환경에서 측정한 결과다.

이번 글은 AI 에이전트의 품질을 개선하는 작업이 특정 모델의 성능을 평가하는 데서 끝나서는 안 된다는 점을 보여준다.

실제 운영에서 어떤 문제가 발생하는지 지속적으로 관찰하고, 이를 다음 개발과 배포의 검증 기준으로 연결하는 과정이 필요하다.

프런트엔드나 백엔드 서비스에 AI 에이전트를 실제 기능으로 도입하려는 개발자에게 특히 참고할 만한 사례다.

---

How to Rewrite Apache Spark UDFs for GPU Acceleration with AI Agents

• 저자: Rishi Chandra, Erik Ordentlich
• 발행: NVIDIA Technical Blog
• 게시일: 2026-10-13
• 원문: NVIDIA — How to Rewrite Apache Spark UDFs for GPU Acceleration with AI Agents

AI 코딩 에이전트가 단순히 새로운 기능을 만드는 데 그치지 않고 기존 프로그램의 성능 병목을 찾아 다른 기술로 변환하는 작업에도 활용될 수 있다는 사실을 보여주는 글이다.

NVIDIA는 Apache Spark에서 실행되는 사용자 정의 함수를 AI 코딩 에이전트로 수정해 GPU 가속이 가능한 코드로 변환하는 방법을 설명한다.

일부 실제 운영 환경에서는 이러한 방식으로 특정 연산의 처리 시간이 22분의 1 수준으로 감소했다고 밝혔다.

중요한 점은 이 결과가 모델 자체의 추론 속도를 개선한 것이 아니라 일반적인 데이터 처리 프로그램을 AI 에이전트가 최적화한 사례라는 것이다.

Spark와 GPU 가속의 관계

Apache Spark는 대규모 데이터를 여러 서버에서 병렬로 처리하기 위한 오픈소스 데이터 처리 시스템이다.

예를 들어 수백억 건의 로그를 분석하거나 대규모 고객 데이터를 집계하는 작업에 사용할 수 있다.

Spark에서는 SQL이나 DataFrame API를 이용해 데이터 처리 작업을 정의할 수 있다.

DataFrame은 여러 행과 열로 구성된 구조화된 데이터를 표현하는 방식이다.

예를 들어 사용자는 특정 열을 기준으로 데이터를 필터링하거나 여러 테이블을 결합하고 합계를 계산할 수 있다.

Spark는 이런 작업을 어떤 순서로 실행해야 가장 효율적인지 분석한다.

이를 Query Optimization(쿼리 최적화)이라고 한다.

NVIDIA는 Spark의 일부 연산을 GPU에서 실행할 수 있도록 cuDF 플러그인을 제공한다.

GPU는 수많은 데이터를 동시에 계산하는 데 특화돼 있다.

따라서 같은 연산을 대규모 데이터에 반복해서 적용하는 작업에서 CPU보다 높은 처리량을 제공할 수 있다.

하지만 모든 Spark 작업이 자동으로 GPU에서 실행되는 것은 아니다.

특히 UDF(User-Defined Function, 사용자 정의 함수)가 문제가 될 수 있다.

사용자 정의 함수가 GPU 성능을 떨어뜨리는 이유

UDF는 개발자가 직접 작성한 함수를 데이터 처리 과정에 사용하는 기능이다.

예를 들어 데이터의 특정 열에 포함된 문자열을 회사 내부 규칙에 따라 변경해야 한다고 가정해 보자.

Spark가 기본적으로 제공하는 함수만으로 처리하기 어렵다면 개발자가 별도의 함수를 만들 수 있다.

하지만 이런 함수의 내부 로직은 Spark의 최적화 엔진이 충분히 이해하지 못할 수 있다.

특히 CPU에서 실행하도록 작성된 UDF는 GPU 가속이 적용된 데이터 처리 과정에서 병목이 될 수 있다.

NVIDIA는 이런 상황을 다음과 같이 설명한다.

먼저 데이터가 GPU에서 열 단위로 처리된다.

그다음 CPU 전용 UDF가 필요해지면 데이터를 CPU가 처리할 수 있는 형태로 변환해야 한다.

이후 CPU에서 각 행을 처리한다.

함수 실행이 끝나면 다시 GPU가 사용할 수 있는 구조로 데이터를 변환해 다음 작업을 진행한다.

즉 GPU를 이용해 빠르게 처리하던 데이터가 중간에 CPU로 이동하면서 추가적인 변환과 데이터 전송 비용이 발생한다.

더 큰 문제는 GPU의 병렬 처리 능력을 활용할 수 있는 연산까지 CPU에서 순차적으로 실행하게 될 수 있다는 점이다.

세 가지 변환 방법

NVIDIA는 CPU UDF를 GPU에서 실행할 수 있는 형태로 변경하는 세 가지 방법을 소개한다.

첫 번째는 Spark SQL 표현식으로 변환하는 방법이다.

간단한 계산이나 문자열 처리에서는 사용자 정의 함수를 없애고 Spark가 기본적으로 이해할 수 있는 연산으로 표현할 수 있다.

이렇게 하면 Spark의 최적화 엔진이 해당 작업을 분석할 수 있다.

NVIDIA cuDF 플러그인도 이를 인식해 GPU 연산으로 변환할 수 있다.

두 번째는 cuDF의 열 단위 API를 직접 사용하는 방법이다.

기존 함수가 복잡해서 SQL 표현식으로 바꾸기 어렵다면 RapidsUDF 인터페이스를 사용할 수 있다.

이 방식에서는 데이터를 행 하나씩 처리하는 대신 GPU 메모리에 있는 열 단위 데이터 구조를 직접 사용한다.

이를 Columnar Processing(열 단위 처리)이라고 한다.

예를 들어 수백만 개의 숫자가 들어 있는 열 전체에 동일한 계산을 적용할 수 있다.

GPU가 이런 연산을 병렬로 실행하도록 만드는 것이다.

세 번째는 CUDA 커널을 직접 작성하는 방법이다.

CUDA는 NVIDIA GPU에서 범용 계산을 수행하도록 하는 프로그래밍 플랫폼이다.

CUDA 커널은 GPU에서 특정 계산을 실행하는 프로그램 단위다.

기존 SQL이나 cuDF 함수로 표현하기 어려운 복잡한 연산에서는 직접 GPU 커널을 작성할 수 있다.

다만 이 방법은 구현이 복잡하고 메모리 관리와 병렬 처리 구조를 직접 고려해야 한다.

따라서 일반적인 개발자에게는 부담이 클 수 있다.

AI 에이전트가 변환과 검증을 반복

NVIDIA는 이런 작업을 자동화하기 위해 cuDF Skills for Apache Spark를 공개했다.

Skills는 AI 에이전트가 특정 작업을 수행할 때 필요한 지침과 절차, 도구 사용 방법을 묶은 구성요소다.

이번 Skills는 네 단계로 구성된다.

gen-test는 기존 UDF의 동작을 확인하는 테스트를 생성한다.

convert-to-{x}는 UDF를 SQL이나 cuDF, CUDA 기반 구현으로 변환한다.

benchmark는 변경 전후의 처리 성능을 비교한다.

optimize는 실제 실행 결과를 분석해 추가적인 최적화를 시도한다.

중요한 점은 에이전트가 코드를 새로 작성했다고 해서 곧바로 성공으로 판단하지 않는다는 것이다.

기존 함수와 같은 결과를 반환하는지 먼저 검사한다.

그다음 실제로 성능이 개선됐는지 측정한다.

성능이 개선되지 않았거나 기존 함수와 다른 결과를 반환한다면 다시 수정해야 한다.

즉 코드 생성과 검증, 성능 측정을 하나의 반복적인 작업 흐름으로 결합했다.

NVIDIA는 이런 작업에 필요한 테스트 환경과 빌드 설정, 참고 자료도 Skills에 포함했다고 설명한다.

이를 통해 AI 에이전트가 기존 코드를 수정하는 데 집중할 수 있도록 했다.

실제 운영에서 22배 속도 개선

NVIDIA는 한 대형 소비자 기술 기업이 이 방식을 실제 서비스에 적용한 사례를 공개했다.

해당 기업은 운영 중인 Spark 데이터 처리 시스템에서 30개 이상의 UDF를 GPU 가속이 가능한 형태로 변경했다.

그 가운데 한 UDF는 약 6,000억 개의 행을 처리하는 작업에 사용됐다.

입력 데이터의 크기는 약 16TB, 출력 데이터는 약 17.4TB였다.

기존 CPU UDF에서 해당 연산이 소비한 누적 처리 시간은 274.55시간이었다.

GPU 가속이 가능한 cuDF 기반 구현으로 변경한 뒤에는 12.78시간으로 줄었다.

약 21.5배, 즉 22배에 가까운 속도 개선이다.

다만 이 수치는 전체 데이터 파이프라인의 실행 시간이 274시간에서 12시간으로 줄었다는 의미가 아니다.

특정 연산의 누적 처리 시간을 비교한 결과다.

실제 작업 전체의 실행 시간은 다른 연산과 데이터 전송, 저장소의 처리 속도에도 영향을 받는다.

NVIDIA에 따르면 해당 UDF는 3,000개 이상의 작업에서 사용되고 있었다.

따라서 하나의 함수 최적화가 여러 데이터 처리 파이프라인에 영향을 줄 수 있었다.

이런 사례에서는 AI 에이전트가 새로운 기능을 개발하는 것보다 이미 운영 중인 시스템의 비효율적인 부분을 찾아 개선하는 데 더 큰 가치를 만들 수도 있다.

최적화된 코드의 의미를 보존하는 것이 중요

이런 변환 작업에서 가장 중요한 조건은 기존 함수의 동작이 유지돼야 한다는 점이다.

예를 들어 숫자를 계산하는 함수에서 null 값이 입력됐을 때 어떤 결과를 반환하는지 확인해야 한다.

문자열을 처리하는 함수라면 특수문자나 잘못된 인코딩을 어떻게 처리하는지도 중요하다.

CPU 코드와 GPU 코드가 일반적인 입력에서는 같은 결과를 반환하더라도 예외적인 입력에서는 다르게 작동할 수 있다.

따라서 성능을 개선하기 전에 기존 함수의 실제 동작을 검증할 수 있는 테스트가 필요하다.

NVIDIA의 사례는 이런 검증 과정을 AI 에이전트의 작업에 포함했다는 점에서 의미가 있다.

모델이 코드를 생성하는 능력이 높아졌더라도 실제 프로그램의 결과와 성능을 독립적으로 측정해야 한다는 원칙은 달라지지 않는다.

이번 글은 AI 에이전트를 이용한 개발 자동화가 단순한 코드 작성에서 실제 시스템의 성능 분석과 최적화, 검증까지 확장될 수 있다는 점을 구체적인 사례로 보여준다.

---

Switzerland Does Top AI Research, but Too Little of It Stays

• 저자: Joel Niklaus
• 발행: Hugging Face Community / 독립 연구 분석
• 게시일: 2026-10-16
• 원문: Hugging Face — Switzerland Does Top AI Research, but Too Little of It Stays

AI 연구 수준이 높은 국가가 반드시 AI 산업에서도 강한 경쟁력을 가지는 것은 아닐 수 있다.

이 글은 스위스의 AI 연구 성과와 스타트업 투자, 기업 인수와 연구 인력 데이터를 직접 수집해 뛰어난 연구 성과가 왜 자국 산업과 인재로 충분히 연결되지 않는가라는 문제를 분석한다.

단순히 국가별 AI 투자 규모를 비교하는 글과 다르다.

저자는 주요 AI 학술대회의 논문 데이터를 직접 수집하고, 연구기관과 국가별 기여도를 계산한 뒤 기업 투자와 인수, 대학원 진학 데이터를 함께 비교했다.

분석에 사용한 코드와 데이터도 공개했다.

인구 대비 AI 논문 생산량은 세계 최상위권

저자는 CVPR, ICCV, ECCV, ACL, EMNLP, NAACL, COLM, NeurIPS, ICML, ICLR, AAAI 등 11개 주요 AI 학술대회의 논문을 분석했다.

대상 기간은 2023년부터 2025년까지다.

이 기간에 발표된 주요 학술대회의 논문은 총 60,337편이었다.

이 가운데 스위스 연구기관이 참여한 논문은 1,240편이었다.

인구 100만 명당 약 138편에 해당한다.

인구가 100만 명 이상인 국가와 지역 가운데 싱가포르와 홍콩만 더 높은 수치를 기록했다.

주요 비교 대상은 다음과 같다.

이 결과만 보면 스위스의 AI 연구 경쟁력은 매우 높은 수준이다.

특히 스위스에는 ETH Zurich와 EPFL처럼 국제적으로 높은 평가를 받는 연구기관이 있다.

하지만 논문 수를 비교할 때는 연구에 참여한 인원과 국가별 인구 규모를 함께 고려해야 한다.

인구가 많은 국가는 전체 논문 수가 많더라도 인구 대비 수치가 상대적으로 낮을 수 있기 때문이다.

저자는 공동 연구의 기여도를 계산하는 방식도 사용했다.

예를 들어 한 논문에 스위스 연구자 두 명과 미국 연구자 두 명이 참여했다면, 해당 논문의 기여도를 두 국가에 절반씩 나누는 방식이다.

이런 분석을 Fractional Counting(분할 기여도 계산)이라고 한다.

모든 공동 저자에게 동일한 기여도가 있다고 가정한다는 한계는 있지만, 국제 공동 연구를 국가별로 비교할 때 단순한 논문 수보다 세밀한 정보를 제공할 수 있다.

연구 성과가 반드시 자국의 스타트업 투자로 연결되지는 않는다

저자는 다음으로 AI 연구자 수와 민간 투자 규모를 비교했다.

분석에는 Stanford의 AI Index 2026과 여러 투자 데이터가 사용됐다.

그 결과 스위스는 AI 연구 인력이 많은 국가임에도 불구하고 연구자당 민간 투자 규모는 미국과 이스라엘보다 낮았다.

2013년부터 2025년까지의 AI 연구자당 민간 투자 규모는 다음과 같았다.

스위스의 연구 수준이 낮기 때문이라고 설명하기는 어렵다.

연구 성과 자체는 높은 수준이기 때문이다.

저자는 그보다 연구 결과를 실제 기업으로 발전시키는 과정에서 충분한 성장 자본을 확보하지 못하는 문제에 주목한다.

예를 들어 대학 연구실에서 새로운 AI 기술을 개발했다고 가정해 보자.

해당 기술을 이용해 스타트업을 설립하는 것은 가능할 수 있다.

하지만 수백 명의 직원을 채용하고 대규모 컴퓨팅 인프라를 확보하며 글로벌 서비스를 운영하려면 초기 연구비보다 훨씬 많은 자본이 필요하다.

이 과정에서 국내 투자자가 충분한 자금을 제공하지 못하면 기업은 해외 투자에 의존하게 될 수 있다.

실제로 스위스 스타트업에 투자된 성장 자본 가운데 스위스 투자자가 제공한 비율은 약 21%였다.

반면 미국 투자자가 제공한 비율은 약 36%였다.

유럽 스타트업의 낮은 기업가치와 자금 조달 규모

저자는 유럽과 미국의 초기 스타트업 투자 조건도 비교했다.

2025년의 중간값을 기준으로 유럽 스타트업의 Seed 투자 라운드에서 평가된 기업가치는 약 700만 달러였다.

같은 시기 미국의 중간값은 약 1,690만 달러였다.

Seed Round(시드 투자)는 스타트업이 제품 개발과 초기 사업 운영을 위해 투자금을 확보하는 초기 단계의 투자다.

기업가치가 낮다는 것은 같은 금액의 투자금을 받더라도 창업자가 더 많은 지분을 제공해야 할 수 있다는 의미다.

예를 들어 기업가치가 100억 원인 회사가 20억 원을 투자받는 경우와, 기업가치가 300억 원인 회사가 20억 원을 투자받는 경우는 창업자의 지분 희석 정도가 달라진다.

저자는 이런 차이가 유럽 스타트업이 미국 기업과 경쟁하는 과정에서 불리하게 작용할 수 있다고 설명한다.

다만 이 비교는 AI 스타트업만을 대상으로 한 자료는 아니다.

일부 생명공학 기업을 제외한 유럽과 미국의 전체 스타트업 투자 데이터를 포함한다.

따라서 이 결과를 모든 스위스 AI 스타트업에 동일하게 적용할 수는 없다.

스위스 AI 스타트업 40개 가운데 34개가 해외 기업에 인수

기업 인수 데이터에서도 흥미로운 결과가 나타났다.

저자가 2010년 이후 확인할 수 있었던 스위스 AI 스타트업 인수 사례는 총 40건이었다.

이 가운데 34건은 해외 기업에 의한 인수였다.

미국 기업이 인수한 사례는 22건이었다.

대표적인 예로 Apple의 Faceshift 인수와 Amazon의 RIVR 인수가 포함된다.

물론 해외 기업에 인수됐다는 사실이 반드시 실패를 의미하는 것은 아니다.

스타트업 창업자와 투자자에게는 성공적인 투자 회수 방법이 될 수 있다.

또한 해외 기업에 인수된 이후에도 연구개발 조직이 스위스에 남아 있을 수 있다.

하지만 국가의 산업 경쟁력이라는 관점에서는 다른 질문이 발생한다.

정부와 대학이 장기간 투자해 구축한 연구 성과가 실제로 어느 국가의 기업과 산업에 축적되는가라는 문제다.

저자는 특히 자국 기업이 초기 기술기업을 인수하거나 고객이 되는 역할이 부족하다고 지적한다.

분석한 40건 가운데 스위스 기업이 인수한 사례는 6건에 불과했다.

석사과정은 늘었지만 박사과정의 자국 학생은 감소

인력 데이터에서도 비슷한 문제가 나타났다.

스위스의 자연과학·컴퓨터과학 관련 분야에서 석사과정 학생은 증가했다.

2010년 스위스 국적 석사과정 학생은 903명이었다.

2025년에는 2,234명으로 증가했다.

하지만 같은 기간 스위스 국적 박사과정 학생은 662명에서 564명으로 감소했다.

반면 외국 국적 박사과정 학생은 증가했다.

저자는 이런 차이가 스위스의 연구기관이 해외 인재에 크게 의존하고 있음을 보여준다고 설명한다.

실제로 스위스의 주요 대학들은 세계 여러 나라에서 연구자를 유치하고 있다.

이는 국제적인 연구 경쟁력의 원천이 될 수 있다.

하지만 장기적으로 자국 학생들이 연구 경력을 선택하도록 만드는 제도도 중요하다는 것이 저자의 주장이다.

연구 성과를 산업으로 연결하려면

저자는 해결책으로 단순히 논문 수를 늘리는 것을 제안하지 않는다.

연구비를 안정적으로 확보하고, 스타트업이 자국에서 성장 자본을 조달할 수 있도록 돕고, 국내 기업이 새로운 AI 기술의 초기 고객이 되는 환경을 만들어야 한다고 주장한다.

특히 기업이 실제로 사용할 수 있는 기술을 개발했다면 국내 기업이 이를 구매하거나 도입하는 과정이 중요하다고 설명한다.

또한 대학원과 산업 연구를 연결하는 박사과정 등을 확대할 필요가 있다고 제안한다.

이 글의 장점은 저자가 자신의 분석이 가진 한계도 구체적으로 공개했다는 점이다.

예를 들어 연구자의 국가별 소속 정보가 잘못 분류될 가능성이 있다.

외부에 공개되지 않은 스타트업 인수 사례는 분석에서 빠질 수 있다.

또한 일부 투자 데이터는 AI 스타트업만을 따로 구분하지 못한다.

따라서 제시된 수치를 완벽한 국가 경쟁력 순위로 받아들이는 것은 적절하지 않다.

그럼에도 논문과 투자, 기업 인수와 인력 데이터를 연결해 기술 연구의 성공과 산업적 성공은 서로 다른 문제라는 점을 보여준다는 데 의미가 있다.

AI 산업의 발전을 이해할 때 모델의 성능과 컴퓨팅 인프라뿐 아니라 자본, 인재, 실제 고객과 기업 생태계가 어떻게 연결되는가도 중요하다는 사실을 생각해 볼 수 있는 글이다.