FDE(포워드 디플로이드 엔지니어)는 어떤 도구를 쓰나? 온톨로지 우선 오픈 스택
FDE가 60–180일짜리 배포에서 실제로 무엇을 만드는가, 이 일을 정의하는 다섯 가지 고통, 그리고 2026년의 모방 물결이 왜 직군만 베끼고 그 아래의 기반은 베끼지 못했는가.
요약: 포워드 디플로이드 엔지니어링(FDE)은 엔터프라이즈 AI에서 가장 빠르게 성장하는 직군입니다 — 채용 공고는 전년 대비 1,165% 증가(Live Data Technologies 집계를 채용 마켓플레이스 Paraform이 전달) — 그리고 2026년 OpenAI, Anthropic, AWS, Microsoft가 각각 자체 포워드 디플로이드 조직을 세웠습니다. 이들이 모두 베끼고 있는 플레이북은 Palantir의 온톨로지 우선 방법입니다. 이 글은 채용 콘텐츠가 결코 다루지 않는 두 가지를 이야기합니다: FDE가 60–180일짜리 배포에서 실제로 무엇을 만드는가, 그리고 이 모방 물결이 왜 직군만 베끼고 그 아래의 기반은 베끼지 못했는가. 그 사이에는 손으로 쌓아 올린 스택 위에서 이 일을 할 때 반복되는 다섯 가지 고통 — 배관 작업이 프로젝트를 삼키고, 데모는 보안 심사에서 죽고, 요구사항은 코드보다 빨리 바뀌고, 패턴은 고객을 넘어 복리가 되지 않고, 인계는 관계를 망칩니다 — 과, 개방형 온톨로지 우선 스택이 각각을 어떻게 제거하는지가 있습니다. 그리고 이 직군의 다음 물결을 정의할 질문으로 끝맺습니다: 온톨로지 인계. 고객의 온톨로지는 고객 자신의 저장소에 타입 있는 오픈 파일로 남는가, 아니면 남의 플랫폼 속 갱신 협상 카드가 되는가?
아무도 정직하게 설명하지 않는 일
채용 공고는 “0→1의 모호함”과 30만–55만 달러 연봉 밴드를 이야기합니다(Perspective AI, TechTarget). 실제 일은 남의 담장 안에서 AI를 돌아가게 만드는 것입니다: 그들의 데이터, 그들의 권한, 그들의 컴플라이언스 부서, 그들이 정의하는 “충분함”. Palantir는 오래전에 방법을 제도화했습니다: AI FDE는 LLM 애플리케이션을 내놓기 전에 고객 전용 온톨로지를 먼저 구축하고, 주당 30–40%를 디스커버리에 씁니다(Palantir AI FDE 가이드). 방법은 옳습니다. 일주일이 실제로 어디로 사라지는지는 그 아래의 도구가 결정합니다.
포워드 디플로이드 엔지니어가 실제로 만드는 것
배포는 대략 60–180일 동안 진행되며, 인계 전까지 네 개의 산출물을 정해진 순서로 만들어냅니다 — 각각이 다음의 입력이기 때문입니다. 채용 공고가 결코 설명하지 않는 부분이 바로 여기입니다:
| 배포 일차 | 실제로 쓰이는 것 | 완료 판정 |
|---|---|---|
| 0–15 · 수집 어댑터 | 소스 시스템마다 어댑터 하나 — 그들의 ERP, 그들의 티켓 도구, 그리고 사실상 진짜 원천인 스프레드시트. 읽기 경로부터: 이관이 아니라 연결. | 화면의 비즈니스 객체가 오늘 아침 그들 시스템에서 나온 실제 레코드를 보여준다. |
| 15–45 · 엔티티 해석 | 아무도 데모하지 않는, 화려하지 않은 절반. “고객”은 네 시스템에서 네 개의 서로 다른 키입니다: 매칭 규칙, 생존 규칙, 그리고 온톨로지가 정규로 취급할 식별자를 씁니다. | 같은 회사인 두 레코드가 병합되고, 고객 운영 책임자도 그래야 했다고 동의한다. |
| 30–60 · 권한 매핑 | 그들의 조직도를 역할, 권한 세트, 행 수준 공유, 필드 규칙으로 옮긴다. 단 세 사람만 볼 수 있는 필드까지 포함해서. | 보안 심사가 회의가 아니라 파일 읽기가 된다: 검토자가 누가 무엇을 보는지 짚을 수 있다. |
| 45–90 · 첫 워크플로 | 끝에서 끝까지 도는 프로세스 두세 개 — 승인 체인, 분류 큐, 갱신 — 과 그 주변의 액션·뷰·알림. | 당신 회사 사람이 아닌 누군가가 그 앱에서 실제 하루치 업무를 끝낸다. |
| 90–180 · 인계 | 시드 데이터, 인수 픽스처, 번역된 레이블, 패키징된 앱, 그리고 그들 팀이 실제로 돌릴 수 있는 리뷰 체크리스트. | 그들의 엔지니어가 당신에게 전화하지 않고 변경을 배포한다. |
앞의 네 행이 공유하는 점에 주목하세요: 어느 것도 통상적인 의미의 애플리케이션 코드가 아닙니다. 그것들은 정의입니다 — 무엇이 존재하는지, 무엇을 같은 것으로 볼지, 누가 무엇을 할 수 있는지, 일이 어떻게 흐르는지. 손으로 쌓은 스택에서는 이 모두가 결국 코드로 표현되고, 아래의 다섯 고통이 무는 이유가 바로 그것입니다.
두 번째 배포가 이 모델이 돈을 버는지 실패하는지 갈리는 지점입니다. 저 표의 어느 것도, 하는 동안 느껴지는 만큼 고객 전용이지 않습니다. “고객”에 대한 엔티티 해석은 다음 고객에서 키만 다른 구조적으로 같은 문제이고, 승인 체인은 임계값과 승인자 역할만 다른 같은 모양입니다. 그래서 두 번째 프로젝트에서 측정할 가치가 있는 숫자는 하나뿐입니다 — 그것을 리네임 비율이라고 부릅시다: 두 번째 배포 중에서, 이미 보유한 타입 있는 정의를 이름만 바꾼 비중이며 다시 쓴 비중이 아닙니다. 손으로 짠 코드베이스에서 이 비율은 0에 가깝고 아무도 알아채지 못합니다. 두 번째 배포도 어쨌든 나가니까요 — 첫 번째와 같은 비용이 들 뿐입니다. 타입 있는 메타데이터에서는 셀 수 있습니다. 면이 유한하기 때문입니다: HotCRM 규모의 프로젝트는 객체 15개, 플로 17개, 액션 10개, 권한 프로파일 6개, 공유 규칙 5개입니다. 다음 고객이 무엇을 물려받는지 말 그대로 열거할 수 있습니다.
이것이 그 일입니다. 이 글의 나머지는 저 표의 각 행을 필요 이상으로 어렵게 만드는 다섯 가지 반복되는 고통과, 무엇이 그것을 제거하는지에 관한 것입니다.
고통 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)이고, 완전한 HotCRM도 앱 전체가 150k 토큰 미만입니다 — 비즈니스 로직은 100k 미만, UI는 약 50k입니다. 어느 규모든 코딩 에이전트가 시스템 전체를 컨텍스트에 담습니다: 승인 체인 변경은 플로·권한·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 아래의 타입 있는 객체·플로·권한, 컴파일된 산출물, 그리고 리뷰 체크리스트. 보안팀은 정의 전체를 검토할 수 있습니다 — 번들 레퍼런스는 16k 토큰이고 완전한 HotCRM도 150k 미만이지, 30만 줄의 코드가 아닙니다. 고객 자신의 코딩 에이전트가 당신이 쓰던 그 루프로 유지보수를 이어갑니다 — 이 포맷은 애초에 에이전트가 쓰라고 만들어졌기 때문입니다. 플랫폼 운영까지 맡기고 싶다면 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개 언어 — 모든 계층이 갖춰져 앱 전체가 150k 토큰 미만입니다. 비즈니스 로직은 100k 미만, UI는 약 50k이며, 전체가 하나의 에이전트 컨텍스트 윈도우에 들어갑니다.
2026년의 모방 물결은 직군을 베끼고 기반은 베끼지 못했다
단 1년 만에 업계는 엔터프라이즈 AI를 이렇게 전달한다고 결론지었습니다. 아래는 모두 그 약속을 한 회사 자신이 내놓은, 날짜가 붙은 약속입니다 — 인용할 가치가 있는 이유가 바로 그것입니다:
| 2026년 | 약속 내용 | 발표 주체 |
|---|---|---|
| 5월 | OpenAI가 과반 지분의 배포 회사를 설립하며 40억 달러 이상을 약정하고, 컨설팅사 Tomoro와 약 150명의 포워드 디플로이드 엔지니어를 함께 인수 | OpenAI |
| 6월 11일 | Anthropic과 DXC가 다년 제휴를 발표. DXC가 이미 은행·항공사·보험사를 위해 운영 중인 시스템 안에서 일할 Claude 인증 포워드 디플로이드 엔지니어를 수만 명 양성 | Anthropic |
| 6월 30일 | AWS가 포워드 디플로이드 엔지니어링 조직에 10억 달러를 투입하고, 5~6명 단위 팀을 고객 내부에 상주시킴 | CNBC |
| 7월 2일 | Microsoft가 Frontier를 출범 — 25억 달러와 6,000명 — 같은 일을 위해 | CNBC |
이 물결과 함께 도는 숫자가 둘 더 있는데, 되풀이하기보다 출처를 밝히는 편이 옳습니다. FDE 채용 공고 전년 대비 +1,165%는 Live Data Technologies의 집계를 Paraform이 전달한 것으로 — FDE 채용을 사업으로 하는 채용 마켓플레이스입니다 — 세는 대상은 공고이지 채워진 자리가 아닙니다. Salesforce의 “1,000명 FDE 팀”은 Salesforce 자체 블로그에서 나온 것으로, 공시된 인원이 아니라 의향 표명입니다. 둘 다 방향으로는 사실이고, 둘 다 감사받지 않았습니다.
이제 일하는 사람에게 중요한 부분입니다. 저 표의 모든 약속은 엔지니어와 달러로 표시되어 있습니다. 두 번째 배포가 첫 번째보다 싸질지를 결정하는 것 — 엔지니어의 산출물이 무엇에 쓰이는가 — 으로 표시된 것은 하나도 없습니다. Palantir의 방법이 통하는 이유는 FDE가 고객 전용 온톨로지에 쓰고 애플리케이션이 거기서 파생되기 때문입니다 — 기반이 곧 제품이고, 엔지니어는 그것이 고객에게 닿는 경로입니다. 똑같은 사람을 기반 없는 조직에 채용해도, 바깥에서 보는 일의 모습은 1년쯤은 똑같습니다.
그래서 어떤 포워드 디플로이드 조직에든 — 들어가려는 조직, 사려는 상대, 지금 만들고 있는 조직 — 던져야 할 유용한 질문은 엔지니어가 몇 명이냐가 아닙니다. 기반에 관한 세 가지 질문입니다:
- 엔지니어가 떠날 때, 그 일은 어떤 파일에 남았는가? 티켓도, 노트북도, 맞춤 서비스도 답이 아닙니다. 고객 저장소에 있는 타입 있는 정의는 답입니다.
- 고객이 당신 없이 그것을 읽을 수 있는가? 정의가 특정 벤더 콘솔 안에서만 읽힌다면, 고객은 자기 온톨로지를 다시 빌려 쓰는 것이고, 당신이 일을 잘할수록 그 골은 깊어집니다.
- 두 번째 배포는 첫 번째에서 무엇을 물려받았는가? 목록을 요구하세요. 아무도 내놓지 못하면 리네임 비율은 0입니다.
이 글의 답은 세 질문 모두 같고, 그것이 위의 모든 내용을 관통하는 온톨로지 우선 관점의 이유입니다: 산출물은 개방형 비즈니스 온톨로지 — Apache-2.0 아래 고객 자신의 저장소에 있는 타입 있는 객체·플로·권한 — 이며, 고객은 그것을 읽고, 보유하고, 자신의 코딩 에이전트에게 넘길 수 있습니다. 직군을 베끼는 것은 채용 계획이고 한 분기면 됩니다. 기반을 베낀다는 것은 고객이 남겨 두고 싶어 할 만큼 그것을 개방한다는 뜻이며, 2026년 물결에서 거의 아무도 내리지 않은 제품 결정입니다.
이 스택이 고치지 못하는 것
상대편도 공정하게: Foundry급 데이터 페더레이션과 분석 파이프라인은 Palantir의 홈그라운드입니다 — 40개 레거시 시스템에서 페타바이트를 융합하는 프로젝트라면 다른 도구 클래스입니다. 조직 변화 관리는 어떤 스택도 고치지 못합니다. 이미 닫힌 플랫폼에 전면 표준화한 고객이라면 남는 것이 합리적일 수 있습니다. 주장은 더 좁습니다: 포워드 디플로이드 업무의 애플리케이션 계층 — 비즈니스를 모델링하고 그 위에 거버넌스된 앱을 내놓는 일 — 에서는 위의 다섯 고통이 이제 제거 가능하고, 온톨로지는 인질이 아니라 인계물이 될 수 있습니다.
FDE 체크리스트
- 어떤 UI 이야기보다 먼저 고객의 명사와 동사를 객체와 플로로 모델링한다.
- 정의 전체를 컨텍스트 크기로 유지해 에이전트가 통째로 추론하고 리팩터링할 수 있게 한다.
- 권한은 기본을 보수적으로; 모든 권한 변경은 diff에 명시한다.
- 인계하는 것은 저장소, 컴파일된 산출물, 리뷰 체크리스트다 — 당신 테넌트의 로그인이 아니다.
- MCP를 켜 둔 채 넘겨, 고객 자신의 AI가 그들의 권한 안에서 앱을 다루게 한다.
- 두 번째 배포에서 리네임 비율을 세어 본다. 넘어온 것이 없다면 문제는 그 프로젝트가 아니라 기반이다.
루프를 돌려 보세요
코딩 에이전트를 오픈 스택으로 향하게 하세요 — 스캐폴드에 AGENTS.md와 스킬 번들이 들어 있어, 에이전트는 처음부터 포맷의 규칙을 읽은 상태로 시작합니다:
npm create objectstack@latest client-app && cd client-app
npx os dev --ui # 앱은 이미 실행 중 — 첫 객체를 에이전트와 함께 모델링플랫폼 운영까지 맡기고 싶은 고객에게는 ObjectOS — ObjectStack 위의 상용 프로덕션·운영 플랫폼, 온라인 구축과 질의, 관리형 또는 프라이빗 배포, 거버넌스 내장 — 가 있습니다.