System of Record for Agents: 에이전트가 일하는 회사를 받칠 데이터 기반, Databricks의 네 가지 질문

에이전트가 회사 일을 맡으려면 더 똑똑한 모델보다 회사의 정의·권한·평가 기록이 먼저 필요합니다. Databricks는 이 기록을 System of Record for Agents라 부르고, 회사 온톨로지에 묶은 에이전트의 답변 정확도가 약 50%에서 84.5%로 올랐다고 밝혔습니다. 옮기려면 핵심 지표의 정의와 주인을 정하고 에이전트마다 신원과 예산을 주는 일부터 시작합니다.

요약

a16z의 Ben Horowitz와 Michael McGuiness는 2026년 10월 27일, Databricks CEO Ali Ghodsi의 이야기를 바탕으로 에이전트 시대에 회사의 모양이 어떻게 바뀌는지 썼습니다. 출발점은 Databricks 안에서 일어난 변화입니다. 3년 전에는 모든 사용에 사람이 끼어 있었지만 지금은 에이전트가 보내는 쿼리가 사람보다 많습니다. 에이전트가 띄우는 데이터베이스는 하루 1,700만 개가 넘습니다. 저자들은 에이전트가 사람보다 1,000배 많아지는 회사를 가정하고, 그 회사의 일을 무엇이 받쳐야 하는지 묻습니다.

답은 System of Record for Agents(에이전트가 읽고 쓰는 회사의 공식 기록 시스템, Ghodsi는 SORA라고 부름)입니다. Ghodsi는 “AI does not have an intelligence problem”이라고 말합니다. 문제는 맥락이라는 것입니다. 에이전트에게는 회사의 데이터, 권한, 피드백, 직원 머릿속에 있는 암묵지가 없습니다. 이 기록 시스템은 네 질문에 답해야 합니다. 무엇이 사실인가, 그것이 무슨 뜻인가, 무엇이 허용되는가, 잘 됐는가입니다. Databricks 자체 테스트에서는 에이전트를 회사 온톨로지(회사에 무엇이 있고 서로 어떻게 이어지며 어느 출처가 우선인지 정리한 모델)에 묶자 답변 정확도가 약 50%에서 84.5%로 올랐습니다. 저자들은 여기서 더 나아가 기록이 한곳에 모이면 판단은 현장으로 흩어질 수 있고, 피라미드형 조직의 모양도 바뀐다고 봅니다. 아래에서는 네 질문을 하나씩 풀고 우리 회사에서 첫 프로토타입을 만들 때 필요한 필드와 일정을 덧붙입니다.

핵심 메커니즘

System of Record for Agents: 네 질문에 답하는 회사의 공식 기록

System of Record(회사가 공식 기준으로 삼는 기록 시스템)는 원래 ERP, CRM처럼 사람이 입력하고 사람이 보던 시스템입니다. 저자들은 에이전트가 이 기록의 주된 사용자가 되면 기록이 담아야 할 것이 늘어난다고 봅니다. 사실만으로는 부족하고 그 사실의 의미, 누가 무엇을 할 수 있는지, 결과가 좋았는지까지 담아야 합니다. Databricks는 네 질문에 제품을 하나씩 대응시킵니다. 사실과 상태는 Lakehouse와 Lakebase가, 의미는 Genie Ontology가, 권한은 Unity Gateway가, 평가는 Genie와 Agent Bricks가 맡습니다. 원문은 메인프레임, 클라이언트-서버, SaaS로 넘어갈 때마다 기록 시스템의 주인이 바뀌었다고 짚습니다. 에이전트가 하나둘일 때는 기존 시스템에 API를 붙여도 됩니다. 에이전트가 부서마다 수십 개로 늘고 같은 지표를 서로 다르게 계산하기 시작하면 이 층이 필요해집니다.

Genie Ontology와 OntoRank: 회사 용어의 뜻과 권위를 정하기

Genie Ontology는 회사 지식을 계속 갱신되는 그래프(지식 그래프)로 만듭니다. 원문이 든 예는 매출을 어떻게 계산하는지, 지난주 스탠드업 회의 기록에 무슨 말이 있었는지입니다. 질문이 올 때마다 회사 데이터 전체를 뒤지지 않고 이 그래프를 먼저 봅니다. 같은 용어의 정의가 여러 개면 OntoRank(Google PageRank에서 이름을 딴 권위 순위)가 어느 정의를 믿을지 정합니다. 원문이 밝힌 신호는 셋입니다. 누가 그 정의를 만들었는지, 얼마나 널리 쓰이는지, 얼마나 최근에 바뀌었는지입니다. 가중치와 공식은 원문에서 밝히지 않았습니다. 앞의 정확도 약 50%에서 84.5%라는 결과가 이 층에서 나왔습니다. 가상 예시로, 영업은 출고 기준, 재무는 인식 기준 매출을 쓴다면 재무팀이 만들고 대시보드 대부분이 쓰는 정의가 높은 점수를 받습니다.

Unity Gateway: 에이전트마다 신원·예산·가드레일 주기

직원 한 명이 하루에 에이전트를 수백 개 띄우면 직원 계정에 권한을 주는 방식은 감당이 안 됩니다. Ghodsi는 회사 곳곳에 흩어진 데이터베이스 하나하나에 에이전트 접근 권한을 줄 수는 없다고 말합니다. Unity Gateway는 회사 안의 모든 모델, 에이전트, AI 도구에 각자 신원을 줍니다. 신원마다 예산과 가드레일을 걸고 모든 행동을 기록합니다. 그래서 어떤 AI가 무엇을 했고 어떤 데이터에 접근했고 비용이 얼마였는지 볼 수 있습니다. 상태와 가드레일은 가운데에 두고, 질문하고 실행하는 주체는 현장으로 흩어 놓는 구조입니다.

Evaluation Loop: 팀이 쓴 시험으로 에이전트를 맞추기

네 번째 질문 “잘 됐는가”는 평가입니다. 업무 사용자는 Genie에서 프롬프트 하나로 공유 가능한 에이전트를 만들고, 이 에이전트는 점점 Slack이나 Salesforce 안에서 일합니다. 엔지니어는 Agent Bricks로 더 손이 많이 가는 운영용 에이전트를 만듭니다. 어느 쪽이든 팀이 직접 시험을 씁니다. 받아들일 수 있는 결과가 무엇인지, 절대 나오면 안 되는 실수가 무엇인지를 적고 Databricks 도구로 에이전트를 그 기준에 맞춰 최적화합니다. 원문은 이렇게 AI가 루프가 된다고 말합니다. 에이전트가 일하고 사람이 고치고 그 교정이 공유 기록에 남아 다음 실행이 나아집니다. 루프가 정해진 일을 믿을 만하게 해내면 사람은 다음 미해결 문제로 옮겨 갑니다.

Lakebase와 LTAP: 에이전트가 몇 초 만에 데이터베이스를 복제하고 버리기

에이전트가 실험하려면 데이터베이스를 싸고 빠르게 복제할 수 있어야 합니다. Databricks는 2025년에 서버리스 Postgres 회사 Neon을 인수했습니다. Neon의 데이터베이스는 이미 대부분 에이전트가 만들고 있었습니다. 이를 합친 Lakebase는 데이터를 레이크에 싸게 두고 연산만 수요에 따라 늘리고 줄입니다. 운영 데이터베이스와 Lakehouse가 저장소를 함께 쓰므로 운영 데이터가 바뀌면 파이프라인 없이 분석가와 에이전트가 바로 봅니다. Databricks는 이것을 LTAP(Lake Transaction/Analytical Processing, 트랜잭션과 분석을 레이크 위에서 함께 처리)라고 부릅니다. 바뀐 부분만 복사하므로 페타바이트 규모도 몇 초 만에 복제됩니다. 에이전트는 격리된 분기(branch)를 만들어 실험하고 끝나면 버립니다. 지난해 출시된 Lakebase는 연 매출 런레이트(현재 매출 속도를 1년으로 환산한 값) 1억 달러를 넘었고 가장 많이 쓰는 사용자는 에이전트입니다.

Centralized Memory, Decentralized Decisions: 기록을 모으면 판단은 흩어진다

저자들이 회사 모양을 이야기할 때 쓰는 논리입니다. Ronald Coase는 1937년에 회사가 거래 비용 때문에 존재하고, 안에서 조율하는 비용이 시장에서 사는 비용과 같아지는 지점까지 커진다고 했습니다. Herbert Simon은 기록을 한곳에 모으면 결정을 흩어 놓을 수 있다고 봤습니다. 보스턴의 항공권 판매 직원은 시카고행 마지막 좌석을 팔 때 다른 직원에게 일일이 묻지 않습니다. 공유 기록을 보고 팔면 기록이 모두에게 갱신됩니다. 20세기 회사가 피라미드였던 것은 보고로 사실이 올라가고 결정이 내려오는 위계가 곧 정보 처리 장치였기 때문입니다. 저자들은 에이전트가 보고·검색·반복 업무를 맡아 조율 비용을 낮추면 회사가 감당할 수 있는 복잡성의 한계가 올라가고 모양도 바뀐다고 봅니다.

통념과 다른 주장

저자가 든 사례

Novo Nordisk: 연구자가 데이터 엔지니어를 거치지 않기

항목	내용
상황	100년 된 헬스케어 회사 Novo Nordisk의 연구자는 데이터가 필요하면 데이터 엔지니어에게 쿼리를 부탁하고 기다렸습니다.
한 일	Genie에 자연어로 비만 관련 데이터 전체를 보여 달라고 묻습니다.
결과	임상시험, 인사이트, 시각화를 바로 받습니다. 단축 시간은 원문에서 밝히지 않았습니다.
연결	사실(What is true)과 의미(What does it mean) 층을 업무 사용자가 직접 쓰는 사례입니다.

Rivian: SQL을 모르는 분석가가 대시보드와 앱을 만들기

항목	내용
상황	Rivian의 재무 분석가는 SQL 경험이 없었습니다.
한 일	Genie로 CFO에게 올릴 매출 대시보드를 만들었습니다. 공급망 분석가는 입고 물량을 추적하는 앱을 만들었습니다.
결과	엔지니어나 데이터 과학자가 하던 일을 현업이 직접 했습니다. 기간·규모는 원문에서 밝히지 않았습니다.
연결	기록은 가운데, 판단과 실행은 현장이라는 구조의 사례입니다. 원문은 이를 두고 모두가 관리자가 된다고 표현합니다.

Block: world model과 조직도는 같은가

항목	내용
상황	Jack Dorsey는 3월에 낸 「From Hierarchy to Intelligence」에서 중간 관리층이 정보 흐름을 늦춘다고 썼습니다.
한 일	회사의 운영·결정·역량·우선순위를 계속 갱신하는 world model로 일을 조율하는 구상을 내놓았습니다. Databricks는 Square, Cash App, TIDAL에 걸친 Block의 페타바이트급 데이터를 관리하고, Block은 이를 써서 코딩 도우미 goose를 회사 맥락에 묶었습니다.
결과	Ghodsi는 철학에는 동의하지만 조직도와 정보 흐름은 별개라고 봅니다. 회의에서 생기는 질문은 거의 Genie가 답하지만 사람을 키우고 우선순위를 정하고 불만을 알아채는 관리자는 남는다고 말합니다. 둘 다 정보를 전달하는 일은 AI가 가져간다고 보고, 위계가 얼마나 사라질지에서 갈립니다.
연결	Centralized Memory 논리가 조직 설계로 이어지는 사례입니다.

기술 디테일: 첫 프로토타입을 만들려면

Genie Ontology 같은 의미 층을 돌리려면 지표 정의부터 레코드로 만듭니다. 처음부터 회사 전체 그래프를 만들지 않습니다. 에이전트가 가장 자주 받는 질문의 지표 10개 안팎(매출, 수주, 재고일수 등)만 정의 레코드로 등록합니다. 필드는 정의 ID, 이름과 동의어, 계산식, 원천 테이블, 주인, 상태, 사용 횟수, 마지막 변경일입니다. 계산식은 자연어 설명과 실행 가능한 SQL을 함께 둡니다. 아래 필드명과 값은 가상 예시입니다.

{
  "definition_id": "metric.revenue.recognized",
  "name": "매출(인식 기준)",
  "synonyms": ["매출", "revenue", "월 매출"],
  "formula_sql": "SELECT SUM(amount) FROM fin.revenue_recognized WHERE period = :month",
  "source_tables": ["fin.revenue_recognized"],
  "owner": "재무팀 결산파트",
  "status": "certified",
  "usage_30d": 412,
  "last_changed": "2026-09-30",
  "conflicts_with": ["metric.revenue.shipped"]
}

OntoRank처럼 권위 점수를 매기려면 원문의 세 신호를 숫자로 바꿉니다. 만든 사람(공식 주인 부서면 가점), 사용 범위(최근 30일 사용 횟수와 쓰는 대시보드·에이전트 수), 최신성(마지막 변경일)입니다. 첫 버전은 가중치를 0.5·0.3·0.2처럼 단순하게 두고(가상 예시), 상위 정의와 2위 점수 차가 작으면 에이전트가 하나를 고르지 말고 두 정의를 모두 보여 주며 묻게 합니다. 최신성은 양날입니다. 막 바뀐 정의가 아직 검증 전이면 status가 certified가 될 때까지 점수에 반영하지 않습니다.

에이전트 답에는 쓴 정의를 반드시 붙입니다. 구조화 출력으로 answer, definition_ids_used, sql_executed, confidence, unknown 필드를 받습니다. 정의 레코드에 없는 용어를 만나면 지어내지 말고 unknown에 넣게 하고, 이 목록을 매주 정의 담당자에게 보냅니다. SQL을 만드는 호출은 temperature 0으로 두고, 같은 질문을 3회 돌려 결과 숫자가 다르면 답을 보류합니다.

정확도 개선을 우리 데이터로 확인하려면 비교 실험을 직접 돌립니다. 원문의 약 50%에서 84.5%는 Databricks 자체 테스트이고 과제는 밝히지 않았습니다. 실제 질문 100~200개와 정답 숫자를 모은 평가셋을 만들고 같은 모델로 정의 레코드 없음과 있음 두 조건을 비교합니다. 정답 판정은 숫자 일치(허용 오차 0.5% 등)로 자동 채점합니다.

Unity Gateway 같은 권한 층을 흉내 내려면 에이전트를 사람처럼 등록합니다. 에이전트마다 agent_id, 만든 사람, 업무 목적, 읽기·쓰기 범위(scopes), 월 예산(budget_usd_month), 가드레일(개인정보 컬럼 차단, 쓰기 전 승인), 만료일을 둡니다. 모든 호출을 agent_id로 로그에 남기고 예산의 80%에서 알림, 100%에서 차단합니다. 주인이 퇴사하거나 90일간 호출이 없는 에이전트는 자동으로 멈춥니다.

두 은행 예의 은행 B가 되려면 결정 로그를 남깁니다. 에이전트가 낸 판단마다 facts_used(쓴 정의·데이터), model_version, human_override(바꿨으면 무엇을 왜), outcome(나중에 확인한 결과)을 남깁니다. 이 로그가 평가셋의 재료가 되고, 모델을 바꿀 때 새 모델을 같은 사례로 다시 채점하는 기준이 됩니다.

실패하는 경우를 미리 정합니다. conflicts_with가 있는 정의는 주인 부서끼리 하나를 고를 때까지 둘 다 보여 주게 합니다. 원천 테이블 이름이 바뀌면 SQL이 깨지므로 매일 정의 레코드의 SQL을 시험 실행해 실패를 알립니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	하는 일
스폰서	CFO 또는 COO	대상 지표 승인, 부서 간 정의 충돌 최종 결정
정의 주인	재무·영업·SCM 지표 담당 각 1명	정의 레코드 작성·인증, 주 1회 unknown 목록 처리
데이터 엔지니어	1~2명	원천 테이블 연결, 정의 SQL 검증, 결정 로그 저장
보안·IT 거버넌스	1명	에이전트 등록 양식, 예산·가드레일 기준
현업 사용자	질문을 가장 많이 받는 팀 5~10명	실제 질문 수집, 답 채점, override 기록

시작 전에 모을 것. 최근 3개월 동안 경영 회의와 보고에서 나온 데이터 질문 목록, 부서별로 쓰는 핵심 지표 정의서(엑셀이어도 됨), 그 지표를 쓰는 대시보드 목록, 현재 운영 중인 AI 도구·에이전트 목록과 주인입니다.

기간	할 일	산출물
1~2주	질문을 모아 지표 10개 선정, 정의 레코드 작성, 충돌 정의 찾기	정의 레코드 10개, 충돌 목록
3~4주	평가셋 100~200문항 작성, 정의 없음·있음 비교, 에이전트 등록·예산 설정	정확도 비교표, 에이전트 등록부
5~6주	섀도 운영: 현업이 평소처럼 일하며 같은 질문을 에이전트에도 묻고 채점	채택률, override 로그, 판정 보고서

현업에 물을 것.

1. 지난달 회의에서 숫자가 서로 달라 다시 확인한 지표는 무엇이었나요?
2. 그 지표의 공식 정의는 누가 정하고, 어디에 적혀 있나요?
3. 에이전트가 답할 때 어떤 근거가 붙어 있어야 그 숫자를 보고서에 쓰겠습니까?
4. 에이전트가 절대 읽거나 바꾸면 안 되는 데이터는 무엇인가요?

진행 판정 기준(예시). 섀도 운영에서 세 조건을 모두 채우면 다음 도메인으로 넓힙니다. 평가셋 정확도가 정의 없음 대비 20%p 이상 오르고, 현업 채택률이 70% 이상이고, 등록되지 않은 에이전트의 데이터 접근이 0건입니다. 기준은 섀도 운영 전에 정해 둡니다.

AX 적용 제언. 국내 기업에서 이 구조를 처음 들일 곳은 경영 보고 지표입니다. 같은 매출과 재고를 부서마다 다르게 세는 일이 가장 흔하고, 정의가 하나로 모이면 효과가 바로 보입니다. 첫 투자는 그래프 도구가 아니라 정의 주인을 정하는 일에 둡니다. 스폰서는 IT가 아니라 숫자의 최종 책임을 지는 CFO가 맡는 편이 좋습니다. 에이전트 등록부와 결정 로그는 처음부터 함께 만듭니다. 모델을 바꿀 때 무엇을 잃지 않을지가 이 두 기록에 달려 있습니다. Block 사례처럼 조직 개편까지 바로 가기보다 정보를 전달하던 보고 업무를 줄이는 데서 시작하고, 관리자가 할 일(사람 육성, 우선순위)은 따로 남겨 둡니다.

원문 사례

항목	내용
저자·발표	Ben Horowitz, Michael McGuiness, a16z, 2026.10.27. Databricks CEO Ali Ghodsi의 발언을 바탕으로 씀
Databricks 규모	연 매출 런레이트 70억 달러+, 전년 대비 80% 성장, 지난달 기업가치 1,900억 달러
에이전트 사용	3년 전엔 모든 사용에 사람이 관여, 지금은 에이전트 쿼리가 사람보다 많음, 에이전트가 하루 1,700만 개+ DB 생성
기술 곡선	Spark(2010 오픈소스, 반복 작업 최대 10배 빠름), Lakehouse(2020, 런레이트 15억 달러+), Lakebase(2025 Neon 인수, 런레이트 1억 달러+), 에이전트
네 질문	What is true / What does it mean / What is allowed / Did it work
제품	Lakehouse·Lakebase, Genie Ontology·OntoRank, Unity Gateway, Genie(2024)·Agent Bricks
정확도	회사 온톨로지 grounding으로 약 50% → 84.5% (Databricks 자체 테스트)
모델 능력	Humanity’s Last Exam 2,500문항 중 절반 이상, METR 과제 길이 약 7개월마다 2배
사례	Novo Nordisk(Genie로 비만 데이터 조회), Rivian(SQL 모르는 분석가가 CFO 대시보드·입고 추적 앱), Block(world model, goose)
인용 인물	Coase, Herbert Simon, James Burnham, Marc Andreessen, Elon Musk, Satya Nadella, Jensen Huang, Alfred North Whitehead
기타	2026 Data + AI Summit 약 3만 명 중 약 10%가 AGI가 왔다고 손을 듦, 약 10년 전 직전 라운드 가치의 약 6배 인수 제안을 거절

핵심 개념

Lakehouse

값싼 데이터 레이크 위에 웨어하우스 수준의 신뢰성(트랜잭션, 스키마)을 얹어 둘을 하나로 쓰는 구조. Databricks가 2020년에 내놓았습니다.

Run rate

최근 매출 속도를 1년치로 환산한 값. 실제 연간 매출과는 다릅니다.

Grounding

모델의 답을 회사 데이터나 정의 같은 근거에 묶어 지어내지 않게 하는 일.

Managerial Revolution

James Burnham이 85년 전에 말한, 소유자 대신 전문 경영인이 큰 조직을 움직이게 된 변화. 원문은 에이전트가 두 번째 변화를 부른다고 봅니다.

Token capital

Satya Nadella의 말로, 회사가 쌓고 소유하는 AI 역량. 사람의 지식·판단(human capital)과 함께 학습 루프를 이룹니다.

Sovereign firm

모델 가격이 오르거나 모델이 단종돼도 배운 것을 잃지 않고 공급자를 바꿀 수 있는 회사.

내 메모

TODO: 내 생각 추가

원문: Ben Horowitz, Michael McGuiness, 「Databricks & the Future of the Firm」(a16z, 2026.10.27). 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 원문이 전한 내용을 AX Review가 다시 정리했습니다. 정확도와 매출 수치는 Databricks가 밝힌 것이고 원문을 그대로 옮겼습니다. 기술·현업 디테일, JSON 예시, 가중치, 일정·판정 기준, 인포그래픽은 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다. 원문 전체는 a16z에서 볼 수 있습니다.