사용자의 모든 데이터를
하나의 인터페이스로. 마이그레이션 없이.
UDB는 에이전트가 다루는 데이터 플레인입니다: DDL이 필요 없는 런타임 정의 테이블에, 사용자가 이미 사용 중인 Postgres, MySQL, HTTP API, 파일 스토리지로 연결되는 통합 어댑터 계층을 더했습니다 — 자연어로 조회할 수 있고, 모든 조회마다 학습하는 시맨틱 매핑을 갖추고 있습니다.
문서 보기에이전트에게는 상태를 보관할 곳이 필요합니다. 데이터베이스 마이그레이션은 답이 아닙니다.
추론은 하지만 아무것도 지속시키지 못하는 에이전트는 매 턴마다 같은 사실을 다시 도출할 뿐입니다. 프로덕션 데이터베이스에 직접 연결을 내주면, 언어 모델에게 시스템 오브 레코드에 대한 통제되지 않은 쓰기 권한을 넘기는 셈입니다. 대신 벡터 스토어를 내주면 구조를 근사적인 검색과 맞바꾸는 셈입니다. UDB는 그 중간에 있는 선택지입니다: 요청 시점에 DDL 없이 정의할 수 있는 테이블에, 이미 사용 중인 시스템으로 연결되는 통제된 어댑터를 더했습니다 — 데이터를 옮기지 않고도 에이전트가 작업할 곳을 갖게 됩니다.
런타임 정의 테이블
에이전트는 요청 시점에 테이블을 생성하고 발전시킵니다 — 마이그레이션 파일도, 배포도, 스키마 리뷰도 필요 없습니다. 모든 테이블은 첫 쓰기부터 테넌트 단위로 격리됩니다.
이미 쓰고 있는 시스템으로 연결되는 어댑터
Postgres, MySQL, HTTP API, 파일 스토리지가 통제된 어댑터를 통해 연결됩니다. 어떤 데이터도 복제되지 않습니다 — UDB는 사용자가 설정한 연결을 통해 직접 읽고 씁니다.
자연어 조회
평범한 문장으로 질문하면 UDB가 알려진 테이블과 어댑터를 대상으로 이를 해석해 타입이 지정된 결과를 반환합니다 — 에이전트가 잘못 작성하기 쉬운 SQL 문자열이 아닙니다.
학습하는 시맨틱 매핑
해석에 성공한 조회는 의도와 스키마 사이의 매핑을 강화합니다. 그래서 비슷한 질문이 다음번엔 더 빠르고 더 정확하게 해석됩니다.
여러 백엔드, 하나의 인터페이스
런타임 테이블과 외부 어댑터는 같은 조회 인터페이스로 응답합니다. 에이전트는 어느 백엔드가 답을 갖고 있는지 알 필요도, 신경 쓸 필요도 없습니다.
기본으로 적용되는 테넌트 격리
모든 테이블, 어댑터 연결, 캐시된 매핑은 계정 단위로 범위가 지정됩니다. 테넌트 간 접근은 관례가 아니라 구조적으로 불가능합니다.
하나의 조회 인터페이스. 그 뒤의 모든 백엔드가 같은 방식으로 응답합니다.
해석 루프
질문 — 조회가 자연어로 들어옵니다 — 작업 중인 에이전트로부터든, 앱의 직접 호출로부터든. SQL도, 테이블명도 필요 없습니다.
해석 — 시맨틱 매핑이 알려진 런타임 테이블과 어댑터 스키마를 대상으로 이를 확인하며, 이전에 유사한 형태를 해석했던 모든 조회 이력을 활용합니다.
라우팅 — 매칭 결과가 백엔드를 결정합니다: 런타임 테이블이거나, Postgres·MySQL·HTTP API·파일 스토리지로 향하는 어댑터입니다.
조회 — 백엔드를 직접 조회합니다 — UDB에 먼저 복제되는 데이터는 없으며, 결과는 하나의 타입 지정된 형태로 정규화됩니다.
반환 — 어느 백엔드가 실제로 응답했는지와 무관하게, 결과는 단일 인터페이스를 통해 돌아옵니다.
강화 — 매핑이 강화됩니다: 이와 비슷한 형태의 다음 조회는 모호함이 줄어든 채 더 빠르게 해석됩니다.
테이블을 정의하고, 자연어로 조회하고, 어댑터를 연결하세요.
데이터의 복제본이 아니라, 접근 계층입니다.
설계부터 DDL 없음 — 런타임 테이블은 마이그레이션 파일이 아닌 API를 통해 생성·변경됩니다 — 에이전트가 필요로 하는 순간 스키마 변경이 곧바로 반영됩니다.
언제나 테넌트 격리 — 모든 테이블, 어댑터 연결, 캐시된 매핑은 계정 단위로 범위가 지정됩니다. 테넌트 간 접근은 구조적으로 불가능합니다.
데이터는 이동하지 않습니다 — 어댑터는 Postgres, MySQL, HTTP API, 파일 스토리지를 있는 그대로, 실시간으로 조회합니다 — UDB는 매핑과 캐시된 결과만 보관할 뿐, 시스템 오브 레코드의 복제본을 갖지 않습니다.
어댑터는 조용히 실패하지 않습니다 — 어댑터별로 연결 상태를 모니터링합니다. 자격 증명 오류나 연결 불가는 조용히 낡은 답을 내놓는 대신 오류로 드러납니다.
매핑을 들여다볼 수 있습니다 — 학습된 모든 시맨틱 매핑은 조회하고 수정할 수 있습니다 — 조회 해석 과정은 절대 블랙박스가 아닙니다.
보관 정책은 원본 시스템을 따릅니다 — 런타임 테이블과 캐시된 결과는 설정된 보관 정책을 따르며, 어댑터는 조회가 끝난 뒤에도 원본 시스템의 데이터를 별도로 보관하지 않습니다.
여러 백엔드를 하나의 조회 인터페이스로 다룬다는 것.
에이전트가 대화 도중 계정별 escalation_owner를 추적해야 합니다. 같은 턴 안에서 필드를 정의하고 값을 씁니다 — 티켓도, 배포도 필요 없습니다.
"연체 중이면서 최근 이메일을 열어보지 않은 고객은?"이라는 질문은 런타임 테이블(이메일 열람 기록)과 Postgres 어댑터(인보이스) 간의 조인으로 해석됩니다 — 에이전트는 백엔드가 두 개였다는 사실조차 모릅니다.
주문 이력을 담고 있는 10년 된 MySQL 인스턴스가 어댑터를 연결한 그날부터 자연어로 조회할 수 있게 됩니다 — ORM도, 익스포트도 필요 없습니다.
파일 스토리지 안의 CSV 내보내기 폴더가 테이블과 똑같이 응답합니다 — UDB는 이를 요약할 문서가 아니라 조회 가능한 소스로 취급하고 색인합니다.
에이전트가 처음으로 "활성 엔터프라이즈 계정"을 질문하면, UDB가 스키마를 확인하는 동안 잠깐의 지연이 있습니다. 50번째 질문에서는 곧바로 정확히 맞아떨어집니다.
에이전트에게 필요한 건 데이터 마이그레이션이 아니라 데이터 플레인입니다.
런타임 테이블, 통제된 어댑터, 이미 사용 중인 모든 시스템 위의 단일 인터페이스 — UDB는 방해가 되지 않습니다.