ObjectOS
← 전체 글
통합과 데이터 일반 게시됨 · · 작성자 ObjectStack Team

마이그레이션 없이 기존 비즈니스 시스템을 AI-native로 만들기

이미 운영 중인 데이터베이스에 ObjectOS를 연결하고, 코딩 에이전트가 테이블을 객체로 모델링하게 하면 원래 시스템을 건드리지 않고도 권한 아래에서 실제 데이터에 AI를 적용할 수 있습니다.

  • Data Sources
  • AI-Native
  • Architecture

“비즈니스에 AI를 붙이자”는 많은 제안은 조용히 재구축을 전제로 합니다. 데이터를 새 플랫폼으로 옮기고, 워크플로를 다시 만들고, 팀을 다시 교육하고, 마이그레이션이 잘 되기를 바랍니다. 바로 그 부분을 아무도 원하지 않습니다. CRM, ERP, 티켓 시스템, 자체 백오피스 같은 기록 시스템은 이미 동작하고 있고 데이터도 그 안에 있습니다.

ObjectOS의 입장은 반대입니다. 마이그레이션하지 말고 연결하세요.

한 문장으로 말하면

ObjectOS를 기존 데이터베이스에 연결하고 중요한 테이블을 객체로 설명하면, 모든 AI 에이전트, flow, API, dashboard가 그 데이터 위에서 바로 작동합니다. 데이터는 올바른 시스템으로 라우팅되고, 사용자가 이미 가진 권한으로 통제됩니다.

원래 애플리케이션은 바뀌지 않습니다. 행 데이터도 이동하지 않습니다. ObjectOS는 이미 운영 중인 시스템 위에 AI-native이며 권한을 이해하는 표면을 만듭니다.

구체적인 그림

40개 테이블짜리 Postgres CRM으로 영업팀을 운영한다고 해봅시다. 계정, 연락처, 영업기회, 라인 아이템, 활동 기록에는 수년간의 실제 데이터가 있습니다. 경영진은 자연어로 묻고 싶어 합니다.

“Q2에서 밀려난 엔터프라이즈 영업기회는 무엇이고, 담당자는 누구인가?”

재구축이라면 6개월 프로젝트입니다. ObjectOS라면 오후에 시작할 수 있습니다.

  1. CRM 데이터베이스를 읽기 전용 datasource로 연결합니다.
  2. 실제로 필요한 테이블들을 코딩 에이전트가 객체로 모델링하게 합니다.
  3. 데이터에 질문하고 첫 자동화를 연결합니다.

CRM은 건드리지 않습니다. 영업 담당자도 변화를 느끼지 않습니다. 같은 행 데이터 위에 AI-native 레이어가 생깁니다.

개념 다이어그램

오늘 어떻게 동작하나

1. 데이터베이스를 datasource로 연결

Datasource는 Postgres, MySQL, MongoDB, SQLite 같은 이름 있는 연결입니다. 자격 증명은 환경 변수에서 오며 소스에 직접 쓰지 않습니다. 먼저 분석만 하고 싶다면 읽기 복제본이나 읽기 전용 DB 사용자를 쓰면 됩니다.

import type { Datasource } from '@objectstack/spec';

export const BusinessDb: Datasource = {
  name: 'business_primary',
  label: 'Business System (Postgres)',
  driver: 'postgres',
  config: {
    connection: {
      host: process.env.BIZ_DB_HOST,
      user: process.env.BIZ_DB_USER,
      password: process.env.BIZ_DB_PASSWORD,
      database: process.env.BIZ_DB_NAME,
    },
  },
  pool: { min: 1, max: 10 },
  active: true,
};

2. 코딩 에이전트로 테이블을 객체로 모델링

테이블마다 객체를 손으로 작성할 필요는 없습니다. Claude Code 같은 코딩 에이전트가 연결된 schema를 읽고, 컬럼, 타입, 외래키를 확인해 첫 초안을 작성할 수 있습니다.

“business_primary에 연결해 accounts, contacts, opportunities, line_items 각각에 대해 ObjectSchema.create를 사용하는 src/objects/<name>.object.ts 파일을 만들어라. SQL 컬럼을 적절한 Field.* 타입으로 매핑하고, 외래키는 Field.lookup(...)으로 바꾸고, 각 객체에 datasource: 'business_primary'를 설정하라.”

결과물은 당신이 소유하고 commit하는 일반 소스 코드입니다. 필요한 컬럼만 남기고, AI에 노출하면 안 되는 컬럼을 제거하고, 라벨, 검증, 권한을 추가할 수 있습니다.

3. 객체를 datasource에 바인딩

각 객체가 datasource를 가질 수 있고, namespace 단위 라우팅 규칙을 선언할 수도 있습니다.

datasourceMapping: [
  { namespace: 'biz', datasource: 'business_primary' },
  { default: true,    datasource: 'default' },
]

데이터 위치 결정이 여러 파일에 흩어지지 않고 한곳에 머뭅니다.

4. AI가 작업하게 하기

테이블이 객체가 되는 순간 AI 레이어가 사용할 수 있습니다. ObjectOS의 list_objects, describe_object, query_records, aggregate_data, data-chat 에이전트는 ObjectQL을 거쳐 각 객체를 바인딩된 datasource로 라우팅합니다.

사용자가 Q2에서 밀려난 영업기회를 물으면, 에이전트는 테이블 전체를 프롬프트에 넣지 않습니다. biz_opportunity에 대한 ObjectQL을 만들고, stage와 close date에 WHERE를 걸고, owner에 join하여 Postgres에서 실행합니다. 더 중요한 점은 그 쿼리가 로그인한 사용자로서 실행된다는 것입니다. 담당자가 다른 지역의 deal을 볼 수 없다면 에이전트도 볼 수 없습니다.

왜 안전한가

  • AI는 사용자로 행동하며 사용자를 넘어서지 않습니다. 객체, 레코드, 필드 권한은 런타임에서 강제됩니다.
  • 원하면 읽기 전용으로 시작합니다. 객체를 읽기 전용 연결이나 DB 사용자에 바인딩할 수 있습니다.
  • 모든 것이 감사됩니다. 읽기, 쓰기, 권한 상승은 누가, 무엇을, 언제, 왜 했는지 기록됩니다.
  • 데이터는 네트워크 안에 남습니다. ObjectOS는 당신의 환경에서 실행됩니다.

재구축 vs. 연결

새 플랫폼으로 재구축ObjectOS로 연결
첫 가치까지 시간몇 달오후
기록 시스템 리스크높음없음
데이터 위치이동그대로
모델링수동 재구현실제 schema에서 에이전트가 초안 작성
권한재구축 및 재감사상속
되돌리기어려움datasource 분리

첫날 얻는 것

  • 실시간 레코드에 대한 자연어 분석.
  • 감사 가능한 governed automation.
  • 같은 메타데이터에서 생성되는 API와 Console.
  • 사람과 AI에 동일하게 적용되는 권한 모델.

이미 제공되는 것과 예정된 것

위 흐름은 datasource, 객체별 라우팅, ObjectQL pushdown, AI 에이전트 레이어로 오늘 동작합니다. 한 단계 schema import, 외부 소유 schema 바인딩, 내장 write-safety gate 같은 더 풍부한 turn-key federation은 ADR-0015에서 설계 중입니다.

자주 묻는 질문

모든 테이블을 모델링해야 하나요? 아닙니다. AI와 자동화가 다룰 테이블만 모델링하면 됩니다.

운영 DB에 쓰나요? 허용할 때만 씁니다. 읽기 전용 연결이면 쓰기가 불가능합니다.

데이터가 모델 제공자에게 가나요? ObjectOS는 당신의 환경에서 실행됩니다. 어떤 AI 제공자를 쓰고 무엇을 보여줄지는 당신이 제어합니다.

schema가 바뀌면요? 코딩 에이전트를 다시 실행해 영향을 받는 객체를 재생성하거나 diff합니다.

이미 비즈니스 데이터베이스가 있다면 거의 다 온 것입니다. 연결하고, 몇 개 테이블을 모델링하고, 데이터에 질문해 보세요.