> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Agent는 준비되었지만, 당신의 아키텍처는 아닐 수 있다

작성자: Catherine Brown (Arsalan Tavakoli-Shiraji 인터뷰) | 2026년 4월 29일

원문: [https://www.databricks.com/blog/agents-are-ready-your-architecture-probably-isnt](https://www.databricks.com/blog/agents-are-ready-your-architecture-probably-isnt)

***

> **참고**
> **요약**

* **활동과 가치 사이의 거리**: 대부분의 조직은 AI 활동은 많지만 실제 비즈니스 임팩트는 제한적입니다. 성공하는 조직은 모델 선택이 아니라 **아키텍처**에서 차별화됩니다.
* **반복되는 세 가지 실패 패턴**: 데이터 사일로, 거버넌스 공백, 그리고 분석용 인프라 위에 에이전트를 얹는 잘못된 토대.
* **에이전트가 행동을 취하면 거버넌스의 의미가 달라진다**: 출력만 생성할 때는 품질 저하가 최악이지만, 에이전트가 메시지를 보내고 레코드를 갱신하기 시작하면 거버넌스는 선택이 아니라 필수가 됩니다.

***

이 글은 Databricks 공동 창업자 겸 Field Engineering SVP인 Arsalan Tavakoli-Shiraji와의 인터뷰입니다. 그는 왜 많은 기업이 "AI는 많이 하는데 실제로 가치는 안 나오는" 단계에 머물러 있는지, 그리고 그 격차의 원인이 어디에 있는지에 대한 관찰을 공유합니다.

## AI 활동과 AI 가치 사이의 거리

대부분의 조직은 AI 이니셔티브를 어떤 형태로든 진행 중입니다. 하지만 실제 비즈니스 임팩트는 제한적입니다. Tavakoli-Shiraji는 기업을 세 부류로 나눕니다:

1. **실험하는 조직** — 다양한 모델과 프레임워크를 시험해보지만, 프로덕션으로 가는 길은 불명확
2. **특정 작업을 자동화하는 조직** — 좁은 범위에서 가치를 창출하지만, 전사 차원의 변환에는 도달하지 못함
3. **AI를 염두에 두고 설계하는 소수의 조직** — 처음부터 결과(outcome)를 정의하고 거꾸로 작업

> "성공하는 조직은 그들이 만들고자 하는 결과에서 시작해서, 거꾸로 일합니다."

## 반복되는 세 가지 아키텍처 실패

문제는 모델이 아닙니다. 인프라입니다. 그는 세 가지 패턴을 반복적으로 발견합니다:

### 1. 데이터 사일로

정보가 호환되지 않는 시스템에 흩어져 있고, 에이전트가 답하려면 여러 시스템을 가로질러 추론해야 하는 상황. 사일로 위에서는 어떤 똑똑한 에이전트도 완전한 답을 만들지 못합니다.

### 2. 거버넌스 공백

에이전트의 권한과 행동에 대한 통제가 부족한 상태. "이 에이전트는 어떤 데이터에 접근해도 되는가? 어떤 행동을 실행해도 되는가? 누구를 대신해서?" 같은 질문에 답할 수 없는 시스템.

### 3. 잘못된 토대

분석용으로 설계된 인프라 위에 에이전트 워크로드를 얹는 실수. 분석 시스템은 배치, 큰 쿼리, 낮은 동시성에 최적화되어 있습니다. 에이전트는 그 반대를 요구합니다.

## 대시보드와 배치 파이프라인 — 구조적 부조화

Tavakoli-Shiraji는 전통적인 BI 도구가 에이전트와 잘못된 속도로 작동한다고 지적합니다.

> "대시보드는 만들어지고, 몇 번 보여지고, 그러고는 제가 '대시보드 무덤(Dashboard Graveyard)'이라고 부르는 곳에 합류합니다."

배치 처리는 에이전트의 실시간 의사결정과 양립할 수 없는 지연을 도입합니다. 에이전트는 행동을 취해야 할 때, 어제의 데이터를 보면서 결정할 수 없습니다.

## Lakebase — 에이전트를 위한 트랜잭션 데이터베이스

이 부조화를 해결하기 위해 Databricks는 **Lakebase**를 에이전틱 애플리케이션 전용 트랜잭션 데이터베이스로 자리매김했습니다. Lakebase는:

* 높은 동시성과 낮은 지연 요구사항을 처리
* Postgres 호환으로 기존 애플리케이션과의 통합이 자연스러움
* Unity Catalog 거버넌스가 분석 데이터와 동일하게 적용
* Delta Lake와의 양방향 통합으로 분석/운영 경계를 매끄럽게 연결

분석 시스템과는 근본적으로 다른 요구사항—작은 트랜잭션이 초당 수천 건—을 충족하도록 설계되었습니다.

## 에이전트가 "행동"하면 거버넌스의 의미가 바뀐다

매우 중요한 구분이 있습니다:

* **시스템이 출력만 생성**할 때: 품질 저하가 최악의 결과
* **에이전트가 행동을 실행**할 때 (메시지 전송, 레코드 갱신, 결제 처리): 거버넌스는 필수

사람은 불완전한 권한 환경에서도 직관으로 길을 찾습니다. 에이전트는 그러지 못합니다. **에이전트는 명시적으로 부여된 권한대로만 행동**하며, 그 권한이 잘못 정의되면 잘못된 행동이 자동화됩니다.

## 성공적인 배포로 가는 길

두 가지 원칙이 반복적으로 등장합니다:

### 1. 기술 선택 전에 성공 지표를 정의하라

"우리는 GPT-4를 쓸 것이다"가 아니라 "우리는 X를 Y만큼 줄일 것이다"에서 시작합니다. 지표가 없으면 어느 모델, 어느 아키텍처가 적합한지 판단할 수 없습니다.

### 2. 파일럿 팀을 레거시 제약에서 격리하라

기존 시스템과 프로세스의 무게에 짓눌리지 않은 별도 팀이 빠르게 반복할 수 있도록 합니다. 검증된 후 점진적으로 확산합니다.

## 통합 시스템 아키텍처

성공하는 구현은 다음 계층을 통합합니다:

| 계층          | 역할            | Databricks 구성 요소          |
| ----------- | ------------- | ------------------------- |
| 거버넌스 분석 레이어 | 정형 데이터 추론     | Unity Catalog + Lakehouse |
| 트랜잭션 DB     | 운영 상태 저장      | Lakebase                  |
| 에이전트 개발 플랫폼 | 에이전트 빌드·평가·배포 | Agent Bricks              |
| 애플리케이션 레이어  | 사용자 워크플로우     | Databricks Apps           |
| 대화형 인터페이스   | 비즈니스 사용자 진입점  | Genie                     |

## 핵심 메시지

근본 명제는 이것입니다: **기업은 기존 워크플로우 위에 단순히 AI를 얹는 것이 아니라, 그 아래의 프로세스 자체를 다시 생각해야 한다.**

Tavakoli-Shiraji는 2차 산업혁명의 비유를 듭니다. 공장이 증기를 전기로 바꾸면서도 동일한 평면 배치를 유지했을 때, 효율성 향상은 미미했습니다. 전기의 진정한 가치는 공장 설계 자체를 다시 했을 때 드러났습니다. 오늘날 많은 조직이 같은 위험에 직면해 있습니다.

> 모델은 준비되었습니다. 도구도 준비되었습니다. 질문은 — **당신의 아키텍처는 준비되었습니까?**