ObjectOS
시작하기
← 전체 글
AI와 에이전트 개발자 게시됨 · · 작성자 ObjectStack Team

FDE(포워드 디플로이드 엔지니어)는 어떤 도구를 쓰나? 온톨로지 우선 오픈 스택

포워드 디플로이드 업무를 정의하는 다섯 가지 고통: 배관이 첫 주를 삼키고, 데모는 보안 심사에서 죽고, 요구사항은 코드보다 빨리 바뀌고, 패턴은 복리가 되지 않고, 인계는 신뢰를 망칩니다. 각각의 구체적 해법을 제시합니다.

FDE(포워드 디플로이드 엔지니어)는 어떤 도구를 쓰나? 온톨로지 우선 오픈 스택
  • 포워드 디플로이드 엔지니어
  • 온톨로지
  • Palantir
  • MCP
  • ObjectStack

요약: 포워드 디플로이드 엔지니어링(FDE)은 엔터프라이즈 AI에서 가장 빠르게 성장하는 직군입니다 — 채용은 전년 대비 약 1,000% 증가, OpenAI는 전담 배포 회사에 40억 달러를 약정했습니다. 통하는 플레이북은 Palantir의 온톨로지 우선 방법입니다. 그런데 현직 FDE에게 실제 일주일이 어떤지 물으면, 반복해서 나오는 다섯 가지 고통을 듣게 됩니다: 배관 작업이 프로젝트를 삼키고, 데모는 보안 심사에서 죽고, 요구사항은 코드보다 빨리 바뀌고, 패턴은 고객을 넘어 복리가 되지 않고, 인계는 관계를 망칩니다. 이 글은 다섯 가지를 하나씩 구체적으로 짚고, 개방형 온톨로지 우선 스택이 각각을 어떻게 제거하는지 보여줍니다 — 그리고 이 직군의 다음 물결을 정의할 질문으로 끝맺습니다: 온톨로지 인계. 고객의 온톨로지는 고객 자신의 저장소에 타입 있는 오픈 파일로 남는가, 아니면 남의 플랫폼 속 갱신 협상 카드가 되는가?

아무도 정직하게 설명하지 않는 일

채용 공고는 “0→1의 모호함”과 30만–55만 달러 연봉 밴드를 이야기합니다(Perspective AI, TechTarget). 실제 일은 남의 담장 안에서 AI를 돌아가게 만드는 것입니다: 그들의 데이터, 그들의 권한, 그들의 컴플라이언스 부서, 그들이 정의하는 “충분함”. Palantir는 오래전에 방법을 제도화했습니다: AI FDE는 LLM 애플리케이션을 내놓기 전에 고객 전용 온톨로지를 먼저 구축하고, 주당 30–40%를 디스커버리에 씁니다(Palantir AI FDE 가이드). 방법은 옳습니다. 일주일이 실제로 어디로 사라지는지는 그 아래의 도구가 결정합니다. 고통 다섯 가지, 하나씩 봅니다.

고통 1 — 첫 주는 언제나 배관 공사

모든 프로젝트는 똑같이 시작합니다: 화면에 업무 객체 하나를 띄우기 전에 인증, SSO, 역할, CRUD API, 관리 UI, 파일 스토리지, 감사 테이블이 필요합니다. 그중 어느 것도 고객이 당신을 고용한 이유가 아닙니다. 당신의 차별점 — 그들의 비즈니스를 이해하는 데 쓸 30–40%의 시간 — 은 지난 고객에서도 똑같이 지었던 무차별한 기반을 다시 짓는 60%에 짓눌립니다.

이 스택이 바꾸는 것: 기반은 이미 있습니다. 명령 하나면 점심 전에 Console, 로그인과 SSO, 역할/행/필드 수준 권한, 감사 로그, REST API, MCP 서버가 모두 돌아갑니다:

npm create objectstack@latest client-app && cd client-app
npx os dev --ui   # Console은 :3000 — 인증·권한·감사는 이미 강제 적용 중

유도 가능한 것은 전부 런타임이 유도합니다. 남는 것은 오직 당신만 쓸 수 있는 것 — 고객의 객체, 플로, 권한 규칙 — 뿐입니다. 첫 주는 디스커버리와 모델링, 즉 당신이 진짜 차별화된 그 일이 됩니다.

고통 2 — 보안 심사에서 죽는 데모

이 곡선을 알 겁니다. 첫 주 금요일: 복사해 온 CSV 위에 급조한 UI를 얹은 데모 — 회의실은 박수. 두 달째: 정보보안팀이 세 가지 질문을 들고 들어옵니다. AI는 정확히 무엇을 볼 수 있나? AI가 행동할 때 누구의 권한이 적용되나? 감사 기록은 어디 있나? 데모 스택에게 정직한 대답은 재구축이고, 재구축이야말로 프로젝트가 죽는 자리입니다.

이 스택이 바꾸는 것: 거버넌스는 나중에 덧대는 것이 아니라 기반입니다. 검증 게이트는 공유 모델을 선언하지 않은 객체를 아예 받지 않습니다:

export const Ticket = ObjectSchema.create({
  name: 'support_ticket',
  label: 'Ticket',
  sharingModel: 'private',        // 필수 — 없으면 게이트가 거부
  fields: {
    subject:  Field.text({ label: 'Subject', required: true }),
    status:   Field.select({ label: 'Status', options: [/* 고객의 실제 상태들 */] }),
    approver: Field.lookup('sys_user'),
  },
});

런타임에서는 모든 호출 — 사람의 UI든, REST든, MCP를 거친 AI 에이전트든 — 이 같은 RBAC, 같은 행·필드 수준 보안을 통과하고 같은 감사 로그에 남습니다. 정보보안팀이 *“AI는 무엇을 볼 수 있나?”*라고 물으면, 답은 그들이 직접 읽을 수 있는 파일입니다: 런타임이 강제하는 권한 메타데이터이지, 슬라이드 속 약속이 아닙니다. 금요일의 데모와 프로덕션 배포는 같은 산출물입니다. 재구축은 없습니다 — “거버넌스 없는 버전”이 애초에 존재한 적 없기 때문입니다.

고통 3 — 요구사항은 코드보다 빨리 바뀐다

회의 도중 운영 책임자가 말합니다: “참, 20% 넘는 할인은 먼저 지역 매니저 승인을 거칩니다.” 수작업 코드베이스라면 스키마 마이그레이션, API 세 군데, UI 한 군데, 그리고 일주일입니다 — 그리고 고객 눈에는, 그들이 구체적으로 말하는 순간 당신이 느려진 것으로 보입니다. 포워드 디플로이드 업무의 생사는 회의실 안에서의 반복 속도에 달려 있습니다.

이 스택이 바꾸는 것: 애플리케이션 전체가 압축된 타입 메타데이터입니다 — 완전한 CRM이 1,792줄, 약 16k 토큰(직접 세어 보세요: find examples/app-crm/src -name '*.ts' | xargs cat | wc -l). 코딩 에이전트가 시스템 전체를 컨텍스트에 담는다는 뜻입니다: 승인 체인 변경은 플로·권한·UI를 가로지르는 하나의 일관된 diff로, 회의가 끝나기 전에 작성되고, os validate가 걸러내고, Console이 실시간으로 미리 보여줍니다. “이걸 바꾸면 뭐가 깨질까?”는 에이전트가 정말로 답할 수 있는 질문입니다 — 전부 보이니까요. 요구사항 변경은 일정의 위협이기를 멈추고, 그 자체가 데모가 됩니다.

고통 4 — 패턴이 복리가 되지 않는다

고객 A의 승인 체인 코드는 고객 B의 코드베이스로 옮겨지지 않습니다 — 프레임워크 버전도, 인증도, 모든 것이 다릅니다. 그래서 모든 프로젝트가 0에서 시작하고, 3인 부티크는 Palantir 모델의 경제학을 성립시키는 레버리지를 영원히 쌓지 못합니다. 포워드 디플로이드 컨설팅이 작게 머무는 조용한 이유입니다.

이 스택이 바꾸는 것: 패턴은 타입 메타데이터이고, 타입 메타데이터는 이식 가능합니다. 고객 A를 위해 모델링한 승인 체인은 고객 B의 저장소에 넣고 이름만 바꾸면 되는 플로 정의입니다. 프로젝트가 쌓일수록 자신만의 라이브러리 — 객체, 플로, 권한 세트, 시드 데이터 — 가 쌓이고, 에이전트가 몇 분 만에 다음 고객에게 적용합니다. 그리고 라이브러리를 0에서 시작할 필요도 없습니다: HotCRM은 완전하고 포크 가능한 레퍼런스 — 15개 객체, 17개 플로, 4개 대시보드, 2개 AI 코파일럿, 4개 언어 — 로, 이 규약의 정본 예제로 만들어졌습니다. 포크하고 네임스페이스를 바꾸면, 프로젝트는 빈 저장소가 아니라 돌아가는 시스템에서 시작합니다.

고통 5 — 인계가 관계를 망친다

모든 프로젝트는 끝나고, 오늘 그 끝은 두 가지 방식 중 하나로 나쁘게 끝납니다. 플랫폼을 넘기면, 고객은 자신의 온톨로지를 영원히 빌려 씁니다 — 당신은 남의 판매 채널이 되었고, 고객은 성공한 파일럿을 두려워하는 법을 배웠습니다: 온톨로지가 좋을수록 락인은 깊으니까요. 맞춤 코드베이스를 넘기면, 그들의 팀은 유지하지 못하고, 시스템은 썩어 가고, 18개월 뒤 그 부패에는 당신 이름이 붙습니다.

이 스택이 바꾸는 것: 이것이 온톨로지 인계 — FDE 플레이북이 끝내 풀지 않은 결말입니다. 당신이 넘기는 것은 고객의 저장소입니다: Apache-2.0 아래의 타입 있는 객체·플로·권한, 컴파일된 산출물, 그리고 리뷰 체크리스트. 보안팀은 이미 모든 줄을 읽었습니다 — 30만 줄이 아니라 16k 토큰이니까요. 고객 자신의 코딩 에이전트가 당신이 쓰던 그 루프로 유지보수를 이어갑니다 — 이 포맷은 애초에 에이전트가 쓰라고 만들어졌기 때문입니다. 플랫폼 운영까지 맡기고 싶다면 ObjectOS가 있고, 같은 오픈 정의 위에서 돕니다 — 떠나도 온톨로지를 잃지 않습니다. 다음 계약은 락인으로 짜내는 것이 아니라 새로운 일로 얻어냅니다. 그 차이가 복리로 쌓이는 당신의 평판입니다.

FDE의 완전한 메타데이터 툴킷

온톨로지는 데이터 모델만이 아닙니다. 포워드 디플로이드 프로젝트는 디스커버리부터 인계까지 단계마다 메타데이터 타입을 사용합니다 — 그리고 모두가 같은 종류의, 타입 있고 검증 가능하며 이식 가능한 정의입니다:

단계답해야 할 고객의 질문사용하는 메타데이터 타입
1 · 명사 모델링”우리 비즈니스에는 무엇이 있나?”객체와 필드(관계, 검증 규칙, 수식) · 데이터소스(기존 DB 연결, 마이그레이션 불필요) · 시드 데이터(데모와 검수용)
2 · 동사 모델링”일은 실제로 어떻게 흐르나?”플로(승인 체인, 상태 기계, 레코드 트리거, 스케줄) · 승인(다단계, 대기열, 레코드 잠금) · 액션(권한 검사되는 버튼과 서버 작업)
3 · 사람을 위한 화면”우리 직원은 어디서 일하나?”앱과 내비게이션 · 뷰(목록/칸반/캘린더/간트) · 페이지와 폼 · 대시보드와 리포트(경영진이 찾는 KPI)
4 · 보안 심사 통과”누가 무엇을 보고 무엇을 할 수 있나?”권한 세트와 역할(RBAC) · 행·필드 수준 보안 · 공유 규칙 · 감사(런타임 내장 — 선언하면 제공)
5 · 고객이 진짜 원하는 AI”AI가 우리에게 뭘 해 주나?”AI 에이전트(영업/고객지원 코파일럿) · AI 도구와 스킬 · MCP 노출(ai: { exposed: true })
6 · 인계와 복리”당신이 떠난 뒤에는?”번역(글로벌 고객용 다국어 레이블) · 앱 매니페스트와 패키징(하나의 objectstack.json으로 컴파일, 어떤 환경에든 설치)

핵심은 여섯 계층이 같은 재료라는 것입니다. 승인 체인도 데이터 모델과 똑같은 타입 메타데이터이고, AI 에이전트도 그렇습니다 — 같은 검증 게이트가 검사하고, 같은 diff에서 리뷰되고, 같은 저장소로 인계됩니다:

// The client's verbs: a discount approval — typed metadata, same as an object
export const DiscountApproval: Flow = {
  name: 'discount_approval',
  label: 'Discount Approval',
  type: 'record_change',
  status: 'active',
  nodes: [
    { id: 'start', type: 'start', label: 'Start',
      config: { objectName: 'crm_quote', triggerType: 'record-after-update',
                condition: 'record.discount > 0.20' } },
    { id: 'review', type: 'approval', label: 'Regional Manager Review',
      config: { approvers: [{ type: 'position', value: 'regional_manager' }], lockRecord: true } },
    { id: 'end', type: 'end', label: 'End' },
  ],
  edges: [/* start -> review -> end */],
};

// The AI the client actually wants: a service copilot — still metadata
export const ServiceCopilot = defineAgent({
  name: 'service_copilot',
  label: 'Service Copilot',
  instructions: 'Help support reps triage and resolve cases. Retrieve only within the user\'s permissions. Always cite case IDs.',
  skills: ['case_triage', 'customer_360'],
  knowledge: { topics: ['support_kb', 'sla_policies'] },
});

HotCRM이 이 어휘의 완전한 사용례입니다: 15개 객체, 17개 플로, 10개 액션, 4개 대시보드, 2개 AI 코파일럿, 6개 스킬, 6개 권한 프로필, 5개 공유 규칙, 4개 언어 — 모든 계층이 갖춰져 약 170k 토큰 — 전체가 여전히 하나의 에이전트 컨텍스트 윈도우에 들어갑니다.

이 스택이 고치지 못하는 것

상대편도 공정하게: Foundry급 데이터 페더레이션과 분석 파이프라인은 Palantir의 홈그라운드입니다 — 40개 레거시 시스템에서 페타바이트를 융합하는 프로젝트라면 다른 도구 클래스입니다. 조직 변화 관리는 어떤 스택도 고치지 못합니다. 이미 닫힌 플랫폼에 전면 표준화한 고객이라면 남는 것이 합리적일 수 있습니다. 주장은 더 좁습니다: 포워드 디플로이드 업무의 애플리케이션 계층 — 비즈니스를 모델링하고 그 위에 거버넌스된 앱을 내놓는 일 — 에서는 위의 다섯 고통이 이제 제거 가능하고, 온톨로지는 인질이 아니라 인계물이 될 수 있습니다.

FDE 체크리스트

  1. 어떤 UI 이야기보다 먼저 고객의 명사와 동사를 객체와 플로로 모델링한다.
  2. 정의 전체를 컨텍스트 크기로 유지해 에이전트가 통째로 추론하고 리팩터링할 수 있게 한다.
  3. 권한은 기본을 보수적으로; 모든 권한 변경은 diff에 명시한다.
  4. 인계하는 것은 저장소, 컴파일된 산출물, 리뷰 체크리스트다 — 당신 테넌트의 로그인이 아니다.
  5. MCP를 켜 둔 채 넘겨, 고객 자신의 AI가 그들의 권한 안에서 앱을 다루게 한다.

루프를 돌려 보세요

코딩 에이전트를 오픈 스택으로 향하게 하세요 — 스캐폴드에 AGENTS.md와 스킬 번들이 들어 있어, 에이전트는 처음부터 포맷의 규칙을 읽은 상태로 시작합니다:

npm create objectstack@latest client-app && cd client-app
npx os dev --ui   # 앱은 이미 실행 중 — 첫 객체를 에이전트와 함께 모델링

플랫폼 운영까지 맡기고 싶은 고객에게는 ObjectOS — 같은 오픈 정의 위의 상용 런타임, 온라인으로 만들고 질문하기, 거버넌스 내장 — 가 있습니다.