Unvarnished Truth: Databricks CEO가 1만 2천 명 회사의 나쁜 소식을 Genie 에이전트로 듣는 법

직원이 150명을 넘으면 CEO는 나쁜 소식을 사람에게서 듣기 어렵습니다. Databricks CEO 알리 고스디는 그 빈자리를 사내 데이터 위에서 일하는 에이전트 Genie로 메웁니다. 따라 하려면 조사 원자료와 영업 기록을 에이전트가 읽게 하고, 답마다 근거를 달게 하고, 사용 한도부터 걸어야 합니다.

요약

TechCrunch의 Julie Bort는 Databricks가 AI 에이전트 Genie의 새 버전을 내놓은 2026년 11월 11일, CEO 알리 고스디(Ali Ghodsi)를 만났습니다. 고스디는 제품 데모 대신 자기가 실제로 쓰는 Genie 화면과 최근 대화, 차트를 보여 줬습니다. 회사 설명에 따르면 새 Genie는 시간이 오래 걸리는 multistep 작업(여러 단계를 거쳐야 끝나는 일)을 감독 없이 처리하고, Databricks가 만든 온톨로지(회사 데이터의 뜻과 관계를 정리한 구조)로 고객이 플랫폼에 쌓아 둔 정보에서 맥락을 가져옵니다. 고스디가 보여 준 일은 세 가지입니다. 직원 만족도 조사에서 점수가 낮은 부분을 분석했고, 그 점수를 올리겠다며 일부 임원이 낸 개선안을 평가해 몇 개를 버렸고, 잠재 고객 앞에서 반응이 나빴던 큰 영업 피치를 요약하면서 그 고객이 구매 전에 필요하다고 한 기능까지 뽑았습니다.

고스디가 이렇게 쓰는 이유는 Dunbar’s number(사람이 안정적으로 유지할 수 있는 관계 수의 대략적 한계)입니다. 그는 그 수를 150으로 듭니다. 작은 스타트업에서는 CEO가 모두를 알고 직원도 나쁜 소식을 편하게 전합니다. 직원이 약 1만 2천 명인 지금은 영업 담당자가 망친 통화를 털어놓지 않고, 인사 담당자도 자기 아이디어가 안 먹힐 것 같다고 말하지 않습니다. 그래서 사람의 보고를 기다리지 않고 에이전트가 데이터에서 문제를 꺼내 오게 합니다. 이런 사내 사용(dogfooding)은 Databricks가 Genie를 경영진용 상시 에이전트로 내세우는 이유 중 하나이고, 비용 걱정에는 Unity Gateway로 사용 한도를 걸고 더 싼 open-weight 모델로 바꾸면 된다고 답합니다. 아래에서는 이 쓰임을 여섯 가지 메커니즘으로 풀고, 비슷한 나쁜 소식 브리프를 만들 때 필요한 데이터, 출력 형식, 일정을 붙입니다.

핵심 메커니즘

Dunbar’s Number Gap: 150명을 넘으면 보고가 걸러진다

조직이 커지면 CEO와 직원 사이의 개인적 관계가 끊기고, 그만큼 나쁜 소식이 위로 올라오지 않는다는 고스디의 진단입니다. 입력은 현장에서 생기는 실패 신호입니다. 망친 영업 통화, 낮은 만족도 점수, 효과가 의심스러운 개선안 같은 것들입니다. 사람의 보고 라인은 단계마다 이 신호를 줄이거나 빼는데, 담당자가 자기에게 불리한 소식을 먼저 꺼낼 이유가 없기 때문입니다. 에이전트는 이미 기록된 데이터를 직접 읽으니 이 걸러짐을 건너뜁니다. 직원이 150명을 넘고 실패 신호가 조사·CRM·회의 기록처럼 데이터로 남는 조직에 맞습니다. 기록이 남지 않는 대화나 에이전트에 읽기 권한이 없는 영역에서는 효과가 없습니다. 원문의 예는 영업 담당자와 인사 매니저입니다. 작은 예를 들면(가상 예시), 직원 3,000명 제조사에서 영업 보고서에는 핵심 고객과의 관계가 양호하다고 적혀 있어도 CRM 메모에 경쟁사 견적 이야기가 석 달째 반복된다면, 에이전트는 그 반복을 CEO 브리프에 올립니다.

Weak-spot Analysis: 만족도 조사에서 낮은 곳부터 판다

조사 결과 전체를 고르게 요약하지 않고, 점수가 낮은 문항과 영역에 집중해 원인을 찾게 하는 사용법입니다. 입력은 직원 만족도 조사 결과이고, 에이전트는 회사가 낮은 점수를 받은 부분을 골라 분석하며, 출력은 고스디가 기자에게 보여 준 대화 기록과 차트입니다. 원문은 어떤 문항이 낮았는지, 점수가 얼마였는지는 밝히지 않았습니다. 정기 조사 데이터가 쌓여 있고 경영진이 전사 평균보다 약한 곳을 먼저 보고 싶을 때 씁니다. 응답자가 적은 팀까지 쪼개면 누가 답했는지 드러날 수 있으므로 그 단위에서는 쓰지 않습니다.

Proposal Triage: 임원 개선안을 에이전트가 먼저 평가한다

낮은 점수를 올리겠다며 임원들이 낸 개선안을 Genie가 평가하고, 고스디가 그 결과를 보고 일부를 버린 방식입니다. 입력은 개선안과 앞 단계의 약점 분석이고, 처리는 각 안이 실제 약점과 맞물리는지 따지는 일이며, 출력은 남길 안과 버릴 안입니다. 원문이 어떤 안을 버렸는지는 밝히지 않았습니다. 이 메커니즘은 인사 담당자가 자기 아이디어가 실패할 것 같아도 말하지 않는다는 앞의 진단과 짝을 이룹니다. 제안한 사람에게 스스로 약점을 말하라고 하는 대신 제3자 평가를 붙이는 것입니다. 마지막 결정은 CEO가 합니다.

Lost-deal Debrief: 실패한 피치에서 구매 조건을 뽑는다

잘 안 된 영업 피치를 요약하고, 고객이 사기 전에 필요하다고 말한 기능을 추려 내는 사용법입니다. 입력은 잠재 고객 앞에서 한 큰 피치의 기록이고, 출력은 피치 경과 요약과 구매 전 요구 기능 목록입니다. 원문은 기록이 녹취인지 메모인지 밝히지 않았습니다. 영업 담당자가 망친 통화를 굳이 보고하지 않는다는 진단에 대한 직접 대응이며, 큰 딜일수록 CEO에게 들어갈 가치가 큽니다. 요구 기능 목록은 그대로 제품 로드맵 논의의 재료가 됩니다.

Ontology-grounded Agent: 회사 정의 위에서 여러 단계를 혼자 돈다

TechCrunch는 새 Genie가 Databricks가 만든 온톨로지에서 맥락을 받아 multistep 작업을 감독 없이 끝낸다고 전합니다. 같은 날 나온 Databricks 블로그는 이 온톨로지(Genie Ontology)를 더 자세히 설명합니다. 입력은 두 갈래입니다. 하나는 대시보드, SQL 쿼리, 노트북, Power BI 같은 semantic model에서 배운 지식이고, 다른 하나는 팀이 Unity Catalog에 직접 정의한 지식(Metric Views로 인증한 KPI, Domains로 나눈 업무 영역 등)입니다. 지식끼리 충돌하면 OntoRank가 출처의 권위, 인증 여부, 만든 사람의 전문성, 인기, 최신성으로 순위를 매기고, 가장 높은 맥락을 에이전트에 넘깁니다. 권한은 Unity Catalog가 관리해 사람과 에이전트 모두 볼 수 있는 것만 봅니다. 고스디의 사용 예에 대입하면, 만족도 점수 산식이나 딜 단계 정의를 에이전트가 매번 새로 추측하지 않고 회사가 정한 정의로 읽는다는 뜻입니다.

Cost Guardrail: 사용 한도와 싼 모델로 비용을 묶는다

에이전트가 경영진과 현업 전체로 퍼지면 AI 비용이 커진다는 걱정에 대한 고스디의 답입니다. 입력은 에이전트 작업 요청이고, Unity Gateway가 회사가 정한 사용 한도를 적용하며, 필요하면 더 싼 open-weight 모델(가중치가 공개된 모델)로 바꿔 돌립니다. Databricks 블로그는 Unity Gateway가 에이전트 연결, 사용 한도, 가드레일, 감사 기록을 함께 다룬다고 설명합니다. 원문에는 실제 비용 수치나 가격이 나오지 않습니다.

통념과 다른 주장

저자가 든 사례

직원 만족도 조사: 낮은 점수 영역 분석

구분	내용
상황	직원 만족도 조사에서 회사가 낮은 점수를 받은 부분이 있음
한 일	Genie에게 그 부분을 분석하게 함. 고스디가 대화와 차트를 기자에게 보여 줌
결과	구체 문항과 점수는 원문에서 밝히지 않음
연결	Weak-spot Analysis, Dunbar’s Number Gap

임원 개선안: 평가하고 일부 폐기

구분	내용
상황	일부 임원이 낮은 점수에 대한 개선안을 냄
한 일	Genie로 개선안을 평가
결과	고스디가 일부 안을 버림. 어떤 안인지는 원문에서 밝히지 않음
연결	Proposal Triage

실패한 영업 피치: 구매 전 요구 기능 정리

구분	내용
상황	잠재 고객 앞에서 한 큰 피치의 반응이 나빴음
한 일	Genie가 피치를 요약하고 고객이 구매 전에 필요하다고 한 기능을 정리
결과	고객명, 기능 목록, 이후 결과는 원문에서 밝히지 않음
연결	Lost-deal Debrief

팟캐스트 준비와 기자 인터뷰

구분	내용
상황	팟캐스트 출연과 TechCrunch 인터뷰
한 일	과거 출연분을 검토해 예상 질문을 만들게 함. 인터뷰 도중에는 기자에게 무슨 말을 할지 조언하게 함
결과	기자는 그 조언이 나쁘지 않았다고 적음
연결	경영자의 일상 업무를 맡는 상시 에이전트라는 Databricks의 제품 방향

개인 생활: 보안이 의심되는 도구 대신

구분	내용
상황	개인 용도의 에이전트가 필요
한 일	고스디가 보안이 의심된다고 본 OpenClaw, Instinct, Muse 대신 Genie를 씀
결과	원문에서 구체 용도는 밝히지 않음
연결	Cost Guardrail과 같은 맥락의 통제 가능성

기술 디테일: 나쁜 소식 브리프를 에이전트로 돌리려면

아래는 원문에 없는 내용으로, 비슷한 경영진용 에이전트를 실제로 돌릴 때 필요한 것을 정리한 가상 예시입니다.

데이터를 세 묶음으로 연결합니다 (Dunbar’s Number Gap, Weak-spot Analysis, Lost-deal Debrief와 연결). 첫째는 조사 원자료입니다. 문항별 점수, 주관식 응답, 부서·직급 코드가 필요하고 개인 식별 정보는 빼고 넣습니다. 둘째는 영업 기록입니다. CRM의 기회(opportunity) 단계 이력, 통화 전사, 회의 메모를 딜 ID로 묶습니다. 셋째는 임원 개선안 문서로, 제안자, 겨누는 문제, 예산, 일정을 필드로 받습니다. 에이전트는 요청한 사람의 권한으로만 읽게 하고, 조사 데이터는 응답자 5명 미만 그룹을 상위 단위로 합친 뒤에 넘깁니다.

약점 분석은 고정 스키마로 받습니다 (Weak-spot Analysis와 연결). 자유 문장 요약은 경영회의 때마다 모양이 달라져 비교가 안 됩니다. 문항 ID, 점수, 전사 평균과의 차이, 응답 수, 주관식 주제, 근거 ID를 필드로 받고, 데이터가 모자라 판단하지 못한 항목은 unknown에 따로 적게 합니다.

{
  "survey_id": "ENG-2026H2",
  "weak_areas": [
    {
      "item_id": "Q14",
      "area": "성장 기회",
      "score": 3.1,
      "company_avg": 3.9,
      "gap": -0.8,
      "groups": ["영업본부"],
      "n": 212,
      "verbatim_themes": ["승진 기준이 불분명", "교육 예산 축소"],
      "evidence_ids": ["agg_q14_sales", "text_cluster_07"]
    }
  ],
  "unknown": ["Q22: 응답 수 부족으로 그룹 분석 생략"]
}

개선안은 채점표로 평가합니다 (Proposal Triage와 연결). 약점 연결, 근거, 실행 비용·기간, 측정 지표 네 항목을 0점, 3점, 5점으로 채점하고, 항목마다 근거 문장과 item_id를 함께 내게 합니다. 같은 안을 temperature 0~0.2로 3회 돌려 항목 점수 편차가 1점을 넘으면 사람 검토로 넘깁니다. 제안자 이름은 채점 입력에서 빼야 직급이 점수에 끼어들지 않습니다. 가능하면 다른 계열 모델로 한 번 더 채점해 두 모델의 총점 차이가 4점(20점 만점)을 넘는 안만 따로 봅니다.

실패 딜 디브리프는 근거 시각을 붙입니다 (Lost-deal Debrief와 연결). 출력 필드는 deal_id, stage_lost, summary, customer_requirements[](기능, 필수 여부 must_have, 근거 위치 source_ref), competitor_mentions, next_action입니다. 요구 기능마다 통화 전사의 시각이나 메모 줄 번호를 source_ref로 달게 하고, 근거가 없는 요구는 출력에서 뺍니다. 같은 기능이 여러 딜에서 반복되면 주간 브리프에서 묶어 보여 줍니다.

맥락 층을 먼저 고정합니다 (Ontology-grounded Agent와 연결). 만족도 점수 산식, 부서 코드 체계, 딜 단계 정의처럼 답을 좌우하는 정의 10개 안팎을 먼저 정하고 주인 부서를 붙입니다. Databricks는 블로그에서 이런 맥락이 있는 Genie가 가상의 영국 에너지 회사 작업공간 과제(과제당 5회 실행)에서 통과율 91%를 냈고, 비교한 다른 두 에이전트는 58%와 45%였다고 밝혔습니다. 자사 벤치마크이므로 우리 데이터로 같은 질문을 정의 연결 전후로 돌려 직접 비교합니다.

비용은 작업 종류로 나눠 묶습니다 (Cost Guardrail과 연결). 주관식 묶기와 통화 전사 요약처럼 양이 많은 일은 open-weight 소형 모델에, 개선안 채점과 주간 브리프 작성처럼 판단이 필요한 일만 큰 모델에 맡깁니다. 에이전트마다 월 한도를 두고 80%에 이르면 담당자에게 알림을 보내며, 한도를 넘으면 큰 모델 호출만 막고 요약은 계속 돌립니다.

실패하는 경우를 미리 정합니다. 기록에 남지 않은 복도 대화는 에이전트가 잡지 못하므로 브리프에 “데이터 없음” 칸을 둬서 빈 곳을 드러냅니다. 소그룹 조사 결과는 익명성을 깨므로 5명 미만이면 합치거나 막습니다. 영업 담당자가 통화 분석을 감시로 받아들이면 기록 자체가 줄어드니, 디브리프는 개인 평가에 쓰지 않는다는 규칙을 먼저 공지합니다.

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

아래 역할과 일정은 원문에 없는 내용으로, 경영진용 나쁜 소식 브리프를 시범 운영할 때 필요한 것을 정리한 가상 예시입니다.

역할	하는 일	산출물
CEO·사업부장	브리프로 답을 듣고 싶은 질문 3개 결정, 개선안 최종 판단	질문 목록, 결정 기록
비서실·전략기획	브리프 운영, 에이전트 결과 검토 후 경영회의 안건화	주간 브리프
CHRO·HR 분석	조사 원자료 제공, 익명성 기준(5명 미만 합침) 결정	조사 데이터 세트, 익명성 규칙
영업 운영	CRM 기회 이력과 통화 전사를 딜 ID로 연결	실패 딜 데이터 세트
데이터팀	정의 10개 고정, 권한 설정, 비용 한도 설정	정의 레코드, 한도 설정표
정보보호·법무	녹취 동의, 개인정보 처리 범위 검토	검토 의견서

시작 전 준비물: 최근 2회분 직원 만족도 조사 원자료, 최근 6개월 실패 딜 20건 안팎의 CRM 기록과 통화 전사, 최근 조사 뒤 임원들이 낸 개선안 문서, 경영진이 지금 보고 있는 조사·영업 보고서(비교 기준)를 모읍니다.

주	할 일	산출물
1주	질문 3개 고정, 데이터 권한과 익명성 규칙 확인, 정의 10개 작성	질문 목록, 정의 레코드
2주	만족도 조사 약점 분석을 3회 돌려 결과 편차 확인, HR 분석가가 사람 분석과 대조	약점 분석 JSON, 대조표
3주	개선안 채점과 실패 딜 디브리프 실행, 영업 리더와 결과 검토	채점표, 딜 디브리프
4주	경영회의에서 브리프 1회 사용, 판정	판정 메모

인터뷰·확인 질문

• 지난 1년 동안 경영진이 너무 늦게 안 나쁜 소식은 무엇이었고, 그 신호는 어느 데이터에 먼저 남아 있었나?
• 만족도 조사에서 경영진 보고서에 빠지는 항목은 무엇인가?
• 실패한 딜을 지금은 누가, 어떤 형식으로, 언제 보고하나?
• 임원 개선안은 지금 무엇을 기준으로 채택하고, 채택 뒤 효과를 누가 재나?
• 에이전트가 쓴 결과를 직원이 알게 되면 어떤 반응이 예상되나?

진행 판정 기준(가상 예시): 4주 동안 에이전트가 기존 보고서에 없던 약점이나 딜 실패 요인을 2건 이상 찾았고, HR 분석가와 영업 리더가 그중 절반 이상을 사실로 확인했으며, 3회 반복 실행의 결론이 같고, 비용이 정한 한도 안이면 확대합니다. 새로 찾은 것이 없으면 질문을 바꿔 한 번 더 돌리고, 사실 확인률이 절반에 못 미치면 정의와 데이터 연결부터 다시 봅니다.

적용 제언. 국내 대기업과 중견기업에서는 CHRO와 함께 만족도 조사 약점 분석으로 시작하는 편이 가장 안전합니다. 데이터가 이미 정리돼 있고, 결과가 틀려도 고객에게 영향이 없기 때문입니다. 다음은 영업 운영과 함께하는 실패 딜 디브리프입니다. 수주 보고에서 빠지는 실패 이유를 모으면 제품 로드맵과 가격 정책 논의에 바로 들어갑니다. 두 가지가 자리 잡으면 경영회의 고정 안건으로 주간 나쁜 소식 브리프를 올립니다. 여기서 바뀌는 관행은 보고의 출발점입니다. 담당 임원이 정리해 올리는 보고 위에, 데이터에서 직접 올라온 신호를 한 장 더 얹는 것입니다. 이때 에이전트 결과를 임원 평가에 바로 쓰면 데이터 기록이 줄어들 수 있으니, 첫 6개월은 판단 재료로만 씁니다.

원문 사례

항목	내용
원문	TechCrunch, Julie Bort, 2026년 11월 11일
계기	Databricks의 AI 에이전트 Genie 새 버전 발표
Genie 설명(회사)	multistep 작업을 감독 없이 처리, Databricks가 만든 온톨로지로 고객 데이터에서 맥락 확보
화자	Ali Ghodsi(Databricks CEO)
사용 예	만족도 조사 약점 분석, 임원 개선안 평가와 일부 폐기, 실패한 영업 피치 요약과 구매 전 요구 기능 정리, 팟캐스트 준비(과거 출연 검토, 예상 질문), 인터뷰 중 조언
근거 개념	Dunbar’s number, 고스디가 든 수치 150
회사 규모	직원 약 1만 2천 명
개인 사용	보안이 의심된다고 본 OpenClaw, Instinct, Muse 대신 Genie
비용 통제	Unity Gateway로 사용 한도 설정, 더 싼 open-weight 모델로 교체
보강 자료	Databricks 블로그(2026.11.11): Genie Ontology GA, OntoRank, 자체 벤치마크 통과율 91%(비교 에이전트 58%, 45%)
원문에 없는 것	고객 도입 수, 가격, 성과 수치

핵심 개념

Genie

Databricks의 AI 에이전트입니다. 회사 데이터를 읽어 질문에 답하고, 새 버전은 여러 단계 작업을 맡습니다.

Dogfooding

회사가 자기 제품을 먼저 사내에서 쓰는 것입니다. 고스디의 Genie 사용이 이 경우입니다.

Harness

AI 모델을 감싸 도구를 호출하고 작업을 이어 가게 하는 소프트웨어입니다.

Open-weight model

학습된 가중치가 공개돼 회사가 직접 받아 돌릴 수 있는 모델입니다. 대체로 호출 비용이 낮습니다.

Unity Gateway

Databricks에서 에이전트 연결, 사용 한도, 가드레일, 감사 기록을 다루는 관문입니다.

Unity Catalog

Databricks의 데이터 카탈로그로, 데이터의 정의, 권한, 계보를 관리합니다.

OntoRank

Genie Ontology에서 서로 다른 지식이 충돌할 때 출처 권위, 인증, 작성자, 인기, 최신성으로 순위를 매기는 방식입니다.

Unsupervised task

사람이 단계마다 확인하지 않아도 에이전트가 끝까지 처리하는 작업입니다.

내 메모

TODO: 내 생각 추가

원문은 TechCrunch 「Databricks’ new AI agent tells CEO Ali Ghodsi the unvarnished truth」(Julie Bort, 2026.11.11)입니다. Genie Ontology, OntoRank, Unity Gateway의 기능과 벤치마크 수치는 같은 날 나온 Databricks 블로그 「Announcing GA: Genie Ontology」(databricks.com/blog/announcing-ga-genie-ontology)로 보강했습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 저자가 든 사례, 원문 사례는 원문이 전한 내용을 AX Review가 다시 정리했고, 기술 디테일, 현업 실행 디테일, 채점표, 일정, 인포그래픽은 실제로 돌릴 때 필요한 것을 새로 작성한 가상 예시입니다. 전체 내용은 원문에서 볼 수 있습니다.