Rayfin 프리뷰, AI 앱에 붙는 Fabric 백엔드
Microsoft가 Rayfin을 공개했습니다. AI 코딩 에이전트가 만든 앱을 Fabric의 DB·인증·GraphQL·거버넌스로 배포합니다.
- 무슨 일: Microsoft가 Build 2026에서
RayfinSDK·CLI와 Fabric Apps 프리뷰를 공개했습니다.- 앱을 코드나 자연어로 설명하면 데이터베이스, 인증, GraphQL API, 스토리지, 접근 정책을 Fabric 백엔드로 묶습니다.
- 개발자 영향: AI 코딩 에이전트가 만든 앱을
npx rayfin up으로 Fabric tenant 안에 배포하는 경로가 생겼습니다. - 주의점: Fabric 용량, SSO, schema 변경, 가격 문서는 배포 전에 확인해야 할 운영 조건입니다.
Microsoft가 Build 2026에서 공개한 Rayfin은 AI 코딩 에이전트가 만든 앱을 프로덕션에 붙일 때 생기는 백엔드 공백을 겨냥합니다. Microsoft Build Live는 2026년 6월 2일 Rayfin을 "open-source SDK and CLI"로 소개하며, 앱을 코드나 자연어로 설명하면 데이터베이스, 인증, 스토리지, 접근 정책을 포함한 "typed, governed backend"를 생성한다고 설명했습니다. 같은 발표에서 배포 대상은 Microsoft Fabric이고, 앱 데이터는 OneLake에 들어가며, 기존 tenant의 보안·거버넌스·컴플라이언스 통제를 상속한다고 밝혔습니다.
이 발표는 GitHub Copilot 앱, Microsoft Foundry, Agent 365, Windows 365 for Agents와 같은 Build 2026의 에이전트 스택 안에 놓여 있습니다. GitHub Copilot 앱이 worktree 기반 병렬 세션, GitHub Issue, Pull Request, CI, merge 흐름을 묶는다면 Rayfin은 그 앱이 실제 조직 데이터와 만나는 지점을 맡습니다. AI가 화면과 코드를 빠르게 만들더라도, 사내 앱에는 인증, 데이터 모델, row-level authorization, 감사, 배포 URL, 용량 계산이 필요합니다.

Microsoft Learn의 Fabric Apps 문서는 Rayfin이 왜 별도 발표가 됐는지를 더 명확하게 보여줍니다. Fabric Apps는 TypeScript 데이터 모델에서 database schema와 GraphQL endpoint를 생성하고, built-in authentication, static hosting, Fabric SSO를 한 개발 워크플로로 제공합니다. 문서의 마지막 업데이트 날짜는 2026년 6월 2일이며, npm create @microsoft/rayfin@latest로 프로젝트를 만들고 npx rayfin up으로 Fabric workspace에 배포하는 흐름이 공개됐습니다.
| Rayfin/Fabric Apps 요소 | 공식 문서의 역할 | AI 앱 개발에서 바뀌는 부분 |
|---|---|---|
| TypeScript data model | @entity(), @text(), @uuid() 같은 decorator로 데이터 구조 정의 | 에이전트가 만든 앱의 데이터 계약을 코드 안에 남김 |
| Generated backend | database schema, GraphQL endpoints, authorization rules 생성 | UI 생성 뒤 API와 DB를 손으로 엮는 시간을 줄임 |
| Fabric SSO | 배포 후 Microsoft Entra ID 기반 Fabric brokered authentication 사용 | 사내 앱의 로그인과 권한 검사를 기존 조직 ID에 연결 |
| Rayfin CLI | up, --dry-run, status, db apply, staticapp deploy | 에이전트가 만든 변경을 배포 전 검토와 단계별 적용으로 나눔 |
Rayfin의 직접 경쟁자는 단순한 앱 빌더가 아닙니다. Replit, Vercel, Supabase, Firebase, AWS Amplify처럼 빠른 앱 배포와 백엔드 생성을 제공하는 도구가 이미 있습니다. Microsoft가 다르게 잡은 지점은 Fabric tenant입니다. Build Live는 Replit과의 파트너십도 언급했습니다. Replit에서 자연어로 앱을 만들고 Rayfin으로 배포하면 앱, 데이터, 서비스가 조직의 Fabric tenant 안에 남는다는 설명입니다.
이 구조는 AI 코딩 도구의 평가 기준을 바꿉니다. 지금까지 많은 팀은 "에이전트가 코드를 얼마나 잘 쓰는가"를 먼저 봤습니다. Rayfin 발표에서 더 가까운 질문은 "에이전트가 만든 앱이 어느 데이터 경계 안에서 실행되는가"입니다. Fabric Apps 문서는 배포된 앱이 단일 endpoint를 갖고, /api/graphql은 데이터 API, /auth는 인증 서비스로 쓰인다고 설명합니다. 조직 입장에서는 앱 생성 속도보다 endpoint, 권한, 용량, 데이터 저장 위치가 구매와 승인 절차를 좌우합니다.
Fabric Apps가 제공하는 인증 조건도 기사에서 빼놓기 어렵습니다. Microsoft Learn은 배포 후 Fabric SSO, 즉 Microsoft Entra ID single sign-on을 사용한다고 적습니다. 같은 문서는 배포된 애플리케이션에서 다른 인증 제공자는 사용할 수 없다고 설명합니다. 이는 장점과 제약을 동시에 만듭니다. Microsoft 365와 Fabric을 이미 운영하는 조직에는 승인 경로가 짧아지지만, 외부 사용자용 앱이나 비Microsoft ID 체계를 요구하는 제품에는 맞지 않을 수 있습니다.
개발 절차는 CLI 중심으로 공개됐습니다. npm create @microsoft/rayfin@latest -- my-app --workspace <workspacename>은 앱 템플릿, rayfin 설정, frontend source code를 생성합니다. 기존 프로젝트에는 npx rayfin init .을 쓸 수 있습니다. 이후 npx rayfin up은 backend를 Fabric에 배포하고 frontend development server를 시작합니다. 배포 전에는 npx rayfin up --dry-run, 배포 상태 확인에는 npx rayfin up status와 --json 옵션이 문서화됐습니다.
이 명령 목록에서 실무자가 봐야 할 부분은 schema 변경입니다. Microsoft Learn은 data model만 바뀐 경우 npx rayfin up db apply로 데이터베이스 변경을 적용할 수 있다고 안내합니다. 동시에 column type 변경이나 column 삭제 같은 destructive change는 실패할 수 있고, --force는 breaking change가 될 수 있다고 경고합니다. AI 에이전트가 schema를 바꾸는 순간은 프롬프트 결과물이 아니라 운영 변경입니다.
Rayfin은 Microsoft Fabric의 capacity 모델도 피하지 못합니다. Fabric Apps overview는 workspace에 Fabric capacity가 할당되어야 하고, Fabric Apps services가 그 capacity unit을 소비한다고 설명합니다. r/MicrosoftFabric에는 2026년 6월 4일 Rayfin cost calculation과 licensing을 묻는 글이 올라왔습니다. 구체적인 답변보다 중요한 사실은 초기 사용자가 기능보다 비용 문서와 capacity planning을 먼저 찾는다는 점입니다.
이 비용 질문은 AI 앱 플랫폼 경쟁에서 자주 반복됩니다. 코딩 에이전트가 앱을 만드는 시간은 줄어도, 앱이 DB, auth, storage, GraphQL, hosting을 쓰는 순간 비용 항목은 늘어납니다. Rayfin이 Fabric tenant 안의 관리형 서비스로 묶인다면 비용은 단일 SaaS 요금표보다 Fabric capacity, child service, SQL database, app hosting, 운영 계정 권한의 조합으로 읽어야 합니다. Microsoft가 가격과 quota 문서를 얼마나 명확히 내느냐가 초기 도입 속도에 영향을 줄 수 있습니다.
제품 포지션을 보면 Rayfin은 "AI가 백엔드를 대신 짜준다"보다 "AI가 만든 앱을 기업 데이터 경계 안에 넣는다"에 가깝습니다. Build Live는 Rayfin 배포 후 앱 데이터가 OneLake에 들어간다고 밝혔습니다. Fabric을 쓰는 조직에는 이 문장이 큽니다. 데이터 복사와 ETL 없이 앱 데이터가 기존 분석·거버넌스 체계 안에 남는다는 의미이기 때문입니다. 반대로 Fabric을 쓰지 않는 팀에는 Rayfin이 별도 클라우드 선택지가 아니라 Microsoft 데이터 플랫폼 선택으로 다가옵니다.
GitHub Copilot 앱과의 연결도 중요합니다. Microsoft Build Live는 Copilot 앱이 GitHub Issues, Pull Requests, 다른 세션을 출발점으로 쓰고, 각 세션을 git worktree로 분리한다고 설명했습니다. Rayfin이 같은 Build 페이지의 "GitHub App + Rayfin" 데모 카드에 묶인 것은 우연이 아닙니다. Copilot 앱이 여러 에이전트 세션을 병렬로 실행하고 검증·리뷰·CI·merge로 보내면, Rayfin은 그 결과물을 Fabric Apps 형태로 배포하는 다음 단계가 됩니다.
이 조합은 개발팀의 역할도 바꿉니다. 프론트엔드 초안, 데이터 모델 초안, GraphQL endpoint, 인증 연결이 한 번에 생성된다면 개발자는 모든 코드를 직접 쓰기보다 생성된 schema와 접근 정책을 검토해야 합니다. 에이전트가 만든 앱에서 가장 비싼 실수는 버튼 색이 아니라 잘못된 데이터 접근 권한입니다. Rayfin이 "governed backend"를 강조한 이유도 이 지점입니다.
Microsoft의 선택은 AI 앱 시장에서 백엔드를 다시 제품화하는 흐름과 맞닿아 있습니다. 2025년과 2026년의 AI 코딩 도구는 자연어로 화면을 만들고 코드를 수정하는 데 집중했습니다. Rayfin은 그 다음 질문을 건드립니다. 앱이 실제 조직에서 쓰이려면 누가 로그인하는지, 어떤 row를 읽는지, schema 변경이 배포되는지, 데이터가 어디에 남는지, 누가 reshare 권한을 갖는지 정해야 합니다. Fabric Apps 문서는 item permissions에서 Run and interact, Edit, Reshare 권한을 나눠 설명합니다.
다만 Rayfin은 아직 preview입니다. Microsoft Learn은 Fabric tenant administrator가 Fabric Apps workload를 켜야 한다고 안내합니다. 배포 후 인증은 Fabric SSO 중심이고, 앱이 Fabric workspace와 capacity에 묶입니다. 따라서 개발자 개인이 바로 모든 앱을 외부에 공개하는 도구라기보다, Fabric을 쓰는 조직 안에서 AI 에이전트가 만든 internal tool과 dashboard를 빠르게 관리형 서비스로 올리는 도구에 가깝습니다.
한국 개발팀이 읽을 때는 "Microsoft도 앱 빌더를 냈다"로 끝내면 손해입니다. Rayfin은 AI 코딩 에이전트의 출력물을 기업 승인 절차로 옮기는 장치입니다. 앱 생성은 Replit, Copilot, Cursor, Codex 같은 도구가 맡을 수 있습니다. 하지만 조직 데이터에 접근하는 순간 관리자는 Fabric capacity, Entra ID, OneLake, GraphQL endpoint, SQL schema, item permission을 봅니다. Rayfin은 그 운영 언어를 AI 앱 생성 흐름 안으로 끌어옵니다.
앞으로 확인할 지점은 세 가지입니다. 첫째, Rayfin CLI와 Fabric Apps가 실제로 어떤 오픈소스 라이선스와 repository 형태로 공개되는지입니다. Build Live는 open-source SDK and CLI라고 설명했지만, 기업 도입에는 package, issue, changelog, security policy가 필요합니다. 둘째, 가격과 quota 문서입니다. r/MicrosoftFabric의 초기 질문처럼 비용이 불명확하면 내부 PoC는 빨라져도 production 승인은 느려집니다. 셋째, AI 에이전트가 schema와 access policy를 수정할 때 어떤 리뷰 UX가 붙는지입니다.
Rayfin이 성공하려면 "앱을 빨리 만든다"보다 "앱이 조직 데이터 안에서 안전하게 움직인다"는 증거를 보여줘야 합니다. Microsoft가 가진 강점은 GitHub, Fabric, Entra ID, OneLake, Foundry를 한 발표 안에서 연결할 수 있다는 점입니다. 약점은 그 연결이 곧 의존성이라는 점입니다. AI 에이전트 앱의 백엔드가 Fabric으로 들어오는 순간, 개발자는 더 빠른 scaffolding과 더 많은 플랫폼 조건을 동시에 받게 됩니다.
실무 도입 순서는 작게 잡는 편이 맞습니다. 첫 PoC는 외부 고객용 서비스보다 Fabric workspace 안에서 쓰는 내부 dashboard나 승인 요청 도구가 적합합니다. 데이터 모델은 rayfin/data 아래 TypeScript class로 남기고, 배포 전 npx rayfin up --dry-run 결과와 생성된 GraphQL API 범위를 리뷰해야 합니다. Entra ID 그룹, Fabric item permission, SQL schema 변경 내역을 같은 PR에 붙여두면 에이전트가 만든 변경과 사람이 승인한 운영 변경을 분리해 볼 수 있습니다.
Rayfin이 흥미로운 이유는 백엔드 자동 생성 자체가 처음이라서가 아닙니다. 2026년의 새 지점은 AI 에이전트가 만든 앱이 곧바로 업무 데이터, 조직 ID, 분석 플랫폼, 배포 정책과 연결된다는 점입니다. Microsoft는 이 연결을 Fabric 안에서 닫으려 하고, 다른 플랫폼은 각자의 배포·DB·auth 조합으로 같은 문제를 풀게 됩니다. 개발팀은 모델 이름보다 데이터 위치, 권한 단위, schema migration 실패 조건을 먼저 비교해야 합니다.