AI & Data @Scale 2026이 밝혀낸 것

몇 주 전 Meta의 AI & Data @Scale 2026에서, Anthropic의 Claude Code 책임자인 Boris Cherny는 지난 8개월 동안 단 한 줄의 코드도 수동으로 작성하지 않았다고 언급했습니다. 그가 이끄는 시스템인 Claude Code가 생성한 커밋(commit)뿐이었습니다.

패러다임의 전환은 바로 이런 방식으로 일어납니다 — 조용하게, 그러다 한꺼번에.

병목 현상의 변화

올해 컨퍼런스의 주제는 _AI 네이티브 전환 (AI Native Transformation)_이었습니다. 이는 세션 전체를 듣기 전까지는 마케팅 용어처럼 들릴 수 있지만, 하루 종일 세션을 듣고 나면 그것이 매우 정확한 기술적 설명임을 깨닫게 되는 문구입니다.

지난 10년 동안 AI 시스템 구축의 병목 현상 (bottleneck)은 알고리즘적이었습니다: 더 유능한 모델, 확장 가능한 아키텍처 (architecture), 더 나은 학습 데이터가 그것이었습니다. 이제 그 병목 현상은 더 이상 주요한 문제가 아닙니다; 프런티어 (frontier)가 진화했습니다. 오늘날 모델들은 충분히 유능해졌으며, 이에 따라 제약 사항은 인프라 (infrastructure), 거버넌스 (governance), 그리고 우리가 구축한 것을 **평가 (evaluate)**하는 능력으로 이동했습니다.

Cherny보다 이를 더 생생하게 설명한 사람은 없었습니다. 그는 수백 개의 에이전트 (agents)를 관리하는 날들도 있고, 그 숫자가 수천 개에 달하는 날들도 있다고 설명했습니다. 하위 에이전트 (sub-agents)들이 서로에게 프롬프트 (prompt)를 보냅니다. 인간은 시스템 상위에 앉아 **의도 (intent)**를 지시하고, 병목 현상을 해소하며, 결과물을 검토합니다. 그는 루틴, 고차원 비동기 자동화 (async automations)를 중심으로 구축된 현재의 워크플로를 설명했는데, 이는 작업을 설정하고 병합 가능한 풀 리퀘스트 (pull requests)로 전달할 수 있게 해줍니다. 개발자 경험 (developer experience)이 근본적으로 변화했습니다. IDE는 더 이상 유일한 인터페이스가 아닙니다; 새로운 계층이 추가되었습니다: **프롬프트 (prompt), 작업 설명 (task description), 그리고 에이전트 대시보드 (agent dashboard)**입니다. 기술의 핵심이 실행 (execution)에서 지시 (direction)로 이동하고 있습니다.

거버넌스 (Governance): 당신의 보안 모델은 에이전트를 위해 구축되지 않았다

모델 능력 (model capability) 문제가 상당 부분 해결된다면, 안전한 배포를 가로막는 다음 제약 사항은 거버넌스 (governance)입니다. 오늘 가장 중요한 세션 중 하나는 Meta의 Komal Mangtani와 Ilia Shumailov가 진행한 세션으로, 에이전트가 등장하는 순간 소프트웨어 시스템 보안에 대해 우리가 알고 있는 많은 것들이 왜 작동을 멈추는지에 대해 두 파트에 걸쳐 다루었습니다.

Cambridge와 Google DeepMind에서의 경력을 보유한 Shumailov는 규칙 기반 (rules-based) 시스템이 해결할 수 없는 실패의 분류 체계 (taxonomy)를 제시하며 포문을 열었습니다. 핵심 문제는 다음과 같습니다. 기존의 보안은 개별적이고 열거 가능한 (enumerable) 요청을 수행하는 인증된 인간의 신원 (authenticated human identities)을 위해 구축되었습니다. 하지만 에이전트는 개별적이지도, 열거 가능하지도 않습니다. 에이전트는 **컨텍스트 윈도우 (context windows)**를 통해 체인을 형성하고, 재귀 (recurse)하며, 권한을 상속받습니다.

더 위험하게도, 에이전트는 자신이 소비하는 데이터에 의해 조작될 수 있습니다. 문서, 데이터베이스 행, 또는 API 응답을 검색하는 에이전트는 해당 콘텐츠로부터 의도하지 않은 방식으로 행동하도록 지시받을 수 있습니다. 이것이 바로 **간접 프롬프트 주입 (indirect prompt injection)**입니다. 직접적인 공격과 달리, 사용자는 아무런 잘못을 하지 않았습니다. 공격 표면 (attack surface)은 구문론적 (syntactic)인 것이 아니라 **의미론적 (semantic)**입니다. 따라서 규칙 기반 필터로는 이를 잡아낼 수 없습니다.

두 세션 모두에서 네 가지 실패 모드 (failure modes)가 핵심 프레임워크로 도출되었습니다:

• 신원 혼동 (Identity confusion): 에이전트가 사용자 신원을 잘못 나타내거나 상속받는 현상
• 권한 남용 (Entitlement creep): 멀티 에이전트 체인을 통해 권한이 누적되는 현상
• 재귀적 유출 (Recursive leakage): 에이전트 간에 민감한 컨텍스트가 흘러나가는 현상
• 데이터 페이로드(data payloads)를 통한 프롬프트 주입: 검색된 콘텐츠에 내장된 공격

Mangtani는 이어서 Meta의 아키텍처적 대응책을 제시했습니다. 바로 DataVM이라 불리는 기술에 기반한 심층 방어 (defense-in-depth) 스택입니다. DataVM은 통합된 신뢰 실행 환경 (trusted execution environment)으로서, 에이전트가 생성될 때 입력값, 도구 호출 (tool calls), 그리고 출력값을 하나의 관리되는 범위 내로 제한합니다. 폭발 반경 (blast radius)은 정책에 의해서가 아니라 구조적으로 제한됩니다. DataVM이 아키텍처 측면에서 중요한 이유는 그것이 뒤집어 놓은 방식에 있습니다. 즉, 데이터 저장소를 신뢰하고 예외적인 경우에만 접근을 거부하는 대신, 에이전트의 전체 운영 범위가 시작되기 전에 미리 제한됩니다.

규제 산업, 즉 금융 서비스 (financial services), 의료, 법률 분야에서 AI 제품을 구축하는 누구에게나 이것은 미래의 문제가 아닙니다. 현재의 문제입니다.

평가 (Evaluation): 측정 속도보다 빠른 구축 속도

거버넌스 (governance)가 첫 번째 새로운 병목 구간이라면, 평가는 두 번째이자 아마도 가장 눈에 보이지 않는 병목 구간일 것입니다. Snorkel AI의 CEO인 Alex Ratner는 오늘 가장 과소평가된 주장을 펼쳤습니다. 바로 AI를 측정하는 우리의 능력이 AI를 개발하는 능력을 따라잡지 못하고 있다는 점입니다.

그는 이를 **평가 격차 (evaluation gap)**라고 불렀으며, 이 격차를 해소하는 것이 이 분야가 직면한 가장 중요한 문제 중 하나라고 규정했습니다.

AI 에이전트를 위한 관측성 (observability) 스택은 세 가지 계층으로 구성됩니다: 모니터링 및 로깅 (monitoring and logging), 벤치마크 (benchmarks), 그리고 평가 도구 (evaluation tools). 세 가지 모두 중요하지만, 벤치마크가 핵심입니다. 왜냐하면 실제 신호 (signal)를 가진 벤치마크만이 다른 모든 것들이 직접 묻기를 피하려는 질문, 즉 _'이 에이전트가 실제로 해야 할 일을 제대로 하고 있는가?'_라는 질문에 답할 수 있기 때문입니다.

Ratner는 오늘날의 에이전트들이 가장 흔히 실패하는 세 가지 차원을 설명했으며, 차세대 벤치마크가 반드시 신호를 제공해야 하는 지점들을 짚어주었습니다:

• 환경 복잡도 (Environment complexity): 실제 운영되는 세상은 얼마나 역동적이고 풍부한가? 정적이고 샌드박스화된 평가 (evals)는 실제 운영 환경에서의 실패율을 대폭 과소평가합니다.
• 자율성 지평 (Autonomy horizon): 에이전트가 오류를 축적하기 전까지 얼마나 멀리 독립적으로 행동할 수 있는가? 단일 턴 평가 (Single-turn evals)는 다단계 실패 전파 (multi-step failure propagation)를 포착하지 못합니다.
• 출력 복잡도 (Output complexity): 에이전트가 생성하는 결과물이 얼마나 정교하고 검증 가능한가? 합격/불합격 (Pass/fail) 지표는 부분적인 정확성을 완전히 놓칩니다.

그는 이어서 에이전트 벤치마크가 반드시 포착해야 하는 데이터인 전체 작업 루프 (full work loop) 개념을 소개했습니다: 작업 (tasks), 환경 (environments), 트레이스 (traces), 출력 (outputs), 그리고 검증기 (verifiers)입니다. 실제로 대부분의 팀이 생략하는 두 가지 요소는 트레이스 (traces) (에이전트 추론의 단계별 기록)와 검증기 (verifiers) (정확성을 확인하는 메커니즘)입니다. 이 두 가지가 없다면, 그것은 벤치마크가 아니라 데모에 불과합니다.

그는 실제 신호가 어떤 모습인지 보여주는 구체적인 벤치마크 사례들을 언급하며, 에이전트를 실제 환경의 엔드 투 엔드 (end-to-end) 작업에서 테스트하고, 단일 스냅샷이 아닌 시간에 따른 품질 저하를 측정해야 한다고 설명했습니다. 그 근저에 깔린 논거는 그 어떤 점수보다 부정하기 어렵습니다. AI 발전의 미래는 아키텍처의 돌파구보다는, 우리가 관리하고자 하는 시스템의 속도에 맞춰 평가 도구를 구축할 수 있는지 여부에 달려 있을지도 모릅니다.

사용자 에이전시 (User Agency): 자연어가 인터페이스가 될 때

세 번째 병목 구간은 가장 인간적인 문제입니다. 에이전트가 잘 통제되고 평가된다 하더라도, 사용자가 이해하거나 신뢰하지 못하는 것은 채택하지 않을 것이기 때문입니다. 오늘 세션 중 가장 제품 중심적이었던 발표는 Meta의 Qi Guo가 진행한 Instagram의 '알고리즘 맞춤 설정 (Tune-Your-Algorithm, TYA)' 기능 발표였습니다.

그 전제는 단순하며 오랫동안 미뤄져 왔던 것입니다: 사용자는 설정 메뉴나 토글 스위치가 아니라, **일상적인 언어 (plain language)**를 통해 자신이 보는 것을 형성하는 알고리즘을 이해하고 제어할 수 있어야 합니다.

TYA는 두 가지 혁신을 기반으로 구축되었습니다. 첫 번째는 **MRS 메모리 시스템 (MRS Memory System)**으로, 행동 신호(behavioral signals)로부터 도출된 사용자의 관심사와 의도(intent)를 지속적으로 업데이트하는 요약본인, 각 사용자의 영구적이고 구조화된 "전기(biography)"를 구축합니다. 두 번째는 **생각 후 추천 (Think-Then-Recommend, TTR)**으로, 추천을 생성하기 전에 사용자의 관심사와 복잡한 의도를 개인화된 하위 목표(sub-goals)로 분해하는 추론 계층 (reasoning layer)입니다.

핵심적인 아키텍처의 변화는 다음과 같습니다: 추천을 과거 신호에 기반한 **검색 문제 (retrieval problem)**가 아니라, 사용자 모델에 대한 **추론 문제 (reasoning problem)**로 보는 것입니다. 시스템은 추천하기 전에 먼저 생각합니다.

초기 결과는 강력한 제품-시장 적합성 (product-market fit)을 보여주었으며, 사용자들은 특히 투명성(transparency)과 주체성(agency)을 만족의 원천으로 꼽았습니다. 이 발견은 강조할 가치가 있습니다. 사용자들은 단순히 더 나은 추천을 원하는 것이 아니었습니다. 그들은 추천을 이해하고 싶어 했습니다. 수년 동안 추천 알고리즘은 설명이나 구제 수단 없이 무엇을 볼지 결정하는, 의도적으로 숨겨진 **블랙박스 (black boxes)**였습니다. TYA가 그 상자를 완전히 열어젖히는 것은 아니지만, 훨씬 더 읽기 쉽게 만듭니다. 사용자는 알고리즘이 자신의 관심사를 어떻게 해석했는지 확인하고, 일상적인 언어로 이를 수정할 수 있습니다. 제한된 시스템 내에서라도 수동적인 수신자에서 능동적인 참여자로 전환되는 이러한 변화가 제품-시장 적합성 신호를 이끌어낸 동력이었습니다.

이러한 설계적 함의는 보기보다 무시하기 어렵습니다. 자연어 (Natural language)는 단순히 더 편리한 입력 방식이 아닙니다. 그것은 사용자와 시스템 사이의 근본적으로 다른 관계를 의미합니다. 사용자가 설계자가 예상한 것을 탐색하는 대신 자신이 원하는 것을 설명할 수 있게 될 때, 인터페이스는 제약 사항이 아니라 대화의 시작점이 됩니다.

이것이 의미하는 바

모든 세션을 관통하는 핵심 줄기는 엔지니어, 사용자, 그리고 기계 사이의 관계를 재협상하는 것이었습니다. Intuit에서 AI 플랫폼 개발자 경험 (developer experience) 작업을 이끄는 사람으로서, 이는 추상적인 관찰이 아닙니다. 이는 현재 우리의 로드맵에 반영되고 있는 설계 및 엔지니어링 과제들입니다.

**엔지니어 (Engineers)**들은 **플릿 매니저 (fleet managers, 함대 관리자)**이자 **의도 디렉터 (intent directors)**가 되기 시작했습니다. 사용자들에게 제어권이 넘겨지고 있습니다. 기계가 **실행 (execution)**을 맡게 된 것입니다.

이러한 변화는 세 가지 새로운 필수 과제를 만들어냅니다:

• 배포하기 전에 거버넌스 (Govern before you ship)를 구축하십시오. 오늘 하루 동안 제시된 거버넌스 프레임워크 (governance frameworks)와 공격 분류 체계 (attack taxonomies)는 민감한 데이터에 접근하는 모든 에이전트 시스템 (agentic system)이 사용자에게 도달하기 전에 반드시 갖추어야 할 체크리스트입니다. 금융 서비스 (financial services) 분야에서 출시 후 거버넌스를 사후에 적용하는 것은 선택지에 없습니다.

• 구축한 것을 평가하십시오 (Evaluate what you build). 전체 작업 루프 (full work loop), 작업 (tasks), 환경 (environments), 트레이스 (traces), 출력 (outputs), 검증기 (verifiers)는 권장 사항이 아니라 명세 (spec)입니다. 에이전트를 구축하는 모든 팀은 대시보드와 병행하여, 그리고 프로덕션 (production)에 배포하기 전에 반드시 벤치마크 (benchmark)를 갖추어야 합니다.

• 자율성(agency)과 투명성을 위해 설계하십시오. TYA의 제품-시장 적합성 (product-market fit) 신호는 모든 AI 제품 팀에 던지는 직접적인 도전입니다. 사용자는 단순히 더 나은 알고리즘을 원하는 것이 아닙니다. 그들은 알고리즘을 이해하고 싶어 하며, 점점 더 알고리즘과 대화하기를 원합니다. 이는 단순히 해피 패스 (happy path)만을 위해 설계하는 것이 아니라, 가독성 (legibility)을 고려하여 사용자가 의미 있게 수정할 수 있을 정도로 시스템의 **추론 (reasoning)을 가시화 (visible)**해야 함을 의미합니다. 문제는 이를 위해 설계할 것인가가 아니라, 당신이 상자(black box)를 어디까지 열어 보일 용의가 있느냐 하는 것입니다.

다음 10년을 정의할 엔지니어는 가장 빠른 코더 (coders)가 아닐 것입니다. 그들은 지능형 시스템을 어떻게 거버넌스하고, 평가하며, 지시할지를 이해하는 사람들, 그리고 아마도 가장 중요하게는, 사용자가 똑같이 할 수 있도록 하는 경험을 어떻게 설계하고 구축할지를 아는 사람들일 것입니다.

당신의 팀은 어떤 병목 현상 (bottleneck)에 가장 먼저 부딪히게 될까요?