코딩 에이전트(coding agent)는 몇 분 만에 앱을 작성할 수 있습니다. 하지만 그 앱을 프로덕션(production) 환경에 올리는 것은 여전히 느린 과정입니다. 구축해야 할 데이터베이스, 연결해야 할 API, 구성해야 할 인증(authentication), 적용해야 할 액세스 정책(access policies), 그리고 관리해야 할 인프라(infrastructure)가 필요하기 때문입니다. 프롬프트에서 코드 생성(prompt-to-code)과 프롬프트에서 프로덕션(prompt-to-production) 사이의 이 간극은 대부분의 에이전트 기반 개발(agentic development)이 조용히 정체되는 지점입니다.

Build 2026에서 Microsoft는 이 간극을 메우기 위한 승부수를 던졌습니다. Rayfin은 개발자와 코딩 에이전트가 코드 내에서 완전한 애플리케이션 백엔드(backend)를 정의한 다음, 단 한 번의 명령으로 Microsoft Fabric에 직접 배포할 수 있게 해주는 오픈 소스 SDK 및 CLI입니다. 수동적인 데이터베이스 설정, API 배관 작업(plumbing), 인프라 작업이 필요 없습니다. 백엔드는 관리형 Fabric 아티팩트(artifact)로 안착하며, 데이터는 OneLake에 저장됩니다.

이것이 아키텍트(architect)의 주목을 받을 가치가 있는 이유는, 이것이 완성되었기 때문이 아니라(현재 퍼블릭 프리뷰 상태입니다) 그것이 겨냥하고 있는 계층(layer) 때문입니다. 만약 코딩 에이전트가 실행(execution) 단계는 압축하지만 전달(deliver) 계층은 그대로 둔다는 개발자 경제학 논거를 읽어보셨다면, Rayfin은 그에 대한 대응책입니다. 즉, Microsoft가 전달(deliver) 단계까지 압축하려고 시도하고 있는 것입니다.

요약 (TL;DR)

• 정의. 코드(데이터 모델, API, 액세스 정책, 비즈니스 로직)로 백엔드를 정의하고 이를 Microsoft Fabric으로 즉시 배포하는 오픈 소스 SDK 및 CLI입니다.
• 한 번의 명령어로 끝나는 핵심 가치. 단 한 번의 배포로 데이터베이스, 인증, 액세스 정책, API가 프로비저닝(provisioning)되며, 수동 설정이나 인프라 작업이 필요하지 않습니다.
• 데이터의 행방. 앱 데이터는 기본적으로 OneLake에 저장되며, 중간에 파이프라인(pipeline)을 거칠 필요 없이 Power BI, 노트북(notebooks), 데이터 에이전트(data agents)에서 즉시 사용할 수 있습니다.
• 런칭 파트너. Replit이 독점 런칭 파트너로 참여하여, 빌드 환경은 거버넌스(governance)가 적용된 Fabric 테넌트(tenant)로 배포되는 AI 우선의 바이브 코딩(vibe-coding) 인터페이스를 제공합니다.
• 설계자의 주의사항. 이는 배관 작업(plumbing)을 압축하는 것이지, 판단(judgment)을 압축하는 것이 아닙니다. 또한 앱과 데이터를 Fabric에 결합(coupling)하게 됩니다. 이 두 가지 모두 기본값이 아닌 결정 사항입니다.

확인된 사실 vs 논평

Microsoft가 확인한 내용. 오픈 소스 SDK 및 CLI로서의 Rayfin, 정의-배포-실행(define-deploy-run) 워크플로, 데이터베이스·인증·액세스 정책·API의 단일 명령 프로비저닝, OneLake로의 데이터 저장, 상속된 거버넌스를 가진 관리형 Fabric 아티팩트(artifact)로서 실행되는 앱, 그리고 런칭 파트너로서의 Replit은 모두 인라인으로 링크된 Microsoft의 Fabric 발표 내용입니다. Rayfin은 2026년 6월 2일 Build 2026에서 발표되었으며, 초기 릴리스(퍼블릭 프리뷰로 보고됨) 단계입니다.

논평 (본인). 전달 계층(deliver-layer) 프레임워크, 결합 및 락인(lock-in) 트레이드오프, 성숙도에 대한 주의, 그리고 '빌드할 것인가 기다릴 것인가'에 대한 가이드는 문서화된 메커니즘에 대한 저의 해석이며, Microsoft의 입장이 아닙니다.

Rayfin이 실제로 하는 일

Microsoft의 Fabric 발표에 따르면, Rayfin은 3단계 루프를 실행하며, 흥미로운 점은 각 단계가 사용자의 부담을 어떻게 덜어주는가 하는 것입니다.

배포 (deploy) 단계가 핵심입니다. 단 한 번의 명령으로 수동 설정이나 인프라 작업 없이 완료됩니다. 그 보상은 데이터에 다음에 일어나는 일입니다. 앱이 작성하는 모든 것은 OneLake에 직접 저장되며, 그 사이의 복사본이나 파이프라인 없이 Power BI, 노트북, 데이터 에이전트가 즉시 이를 읽을 수 있습니다. 애플리케이션은 관리형 Fabric 아티팩트 (artifact)로 실행되므로, 자체적인 거버넌스를 유지하는 대신 Fabric의 거버넌스를 상속받습니다.

출시 환경(launch surface) 또한 중요합니다. Replit은 독점 출시 파트너이며, 이는 의도된 경로가 다음과 같음을 의미합니다: 에이전트가 '바이브 코딩 (vibe coding)'을 수행하는 AI 우선 환경에서 빌드한 다음, 해당 앱을 안전하게 관리되는 Fabric 테넌트 (tenant)로 배포하는 것입니다. 에이전트는 백엔드 정의를 작성하고, Rayfin은 이를 데이터 플랫폼 내부에서 실제로 구현합니다.

이것이 압축되지 않은 계층을 겨냥하는 이유

이 사이트의 개발자 경제학 관련 글은 Brad DeLong의 견해를 따라, 에이전트는 실행 (execution) 계층을 압축하는 반면 결정 (decide) 및 전달 (deliver) 계층은 자동화에 저항한다고 주장했습니다. 이러한 프레임워크에서 '전달 (deliver)'이란 작동하는 아티팩트와 프로덕션에서 실행되는 관리된 개체 사이의 모든 것, 즉 프로비저닝 (provisioning), 보안, 데이터 플러밍 (data plumbing), 운영 표면 (operational surface)을 의미합니다.

Rayfin은 바로 그 부분을 압축하려는 직접적인 시도입니다. 에이전트가 더 잘 결정하도록 만들려는 것이 아닙니다. 사람이 일주일 동안 '글루 코드 (glue code)'를 짜는 데 시간을 쓰지 않고도 에이전트의 출력을 배포 가능하게 만들려는 것입니다. 이것이 대규모로 작동한다면, 전달 (deliver) 계층의 상당 부분을 맞춤형 수작업에서 단 한 번의 명령으로 이동시키는 것이며, 이는 진정으로 새로운 변화입니다.

한 줄 요약: 전달 (deliver) 계층을 맞춤형 수작업(human glue)에서 단 한 번의 명령으로 이동시키는 것.

그것은 낙관적인 해석이며, 타당한 해석이기도 합니다. 하지만 불완전하기도 합니다. 왜냐하면 전달 (deliver)의 메커니즘을 압축하는 것이 그 안에 담긴 판단 (judgment)을 압축하는 것과 같지는 않기 때문입니다.

이것이 진정으로 해결하는 것

여기서 세 가지는 실질적이며 명확하게 명시할 가치가 있습니다.

글루 코드 (Glue-code) 제거. 데이터베이스를 구축하고, 인증 (auth)을 연결하며, API를 호스팅하는 지루한 작업은 에이전트 기반 개발 (agentic development)에서 병렬화가 불가능하며 누구에게도 즐거움을 주지 못하는 부분입니다. 이를 배포 (deploy) 명령 하나로 축소하는 것은 데모용 기술이 아니라 실질적인 생산성 향상입니다.

상속된 거버넌스 (Inherited governance). 앱이 관리형 Fabric 아티팩트 (artifact)로 실행되기 때문에, 거버넌스를 새로 만드는 대신 테넌트 (tenant)의 기존 거버넌스 내에 위치하게 됩니다. 규제를 받는 Microsoft 기업에게는, 기본적으로 빠른 앱보다 기본적으로 거버넌스가 적용된 앱이 더 가치가 있습니다.

분석 준비가 된 데이터 (Analytics-ready data). 파이프라인 없이 OneLake에 앱 데이터가 착륙한다는 것은 운영 데이터 (operational data)와 분석 데이터 (analytical data) 사이의 간극이 제로로 좁혀짐을 의미합니다. 앱이 방금 작성한 데이터는 이미 Power BI와 Fabric 데이터 에이전트 (data agents)에 의해 쿼리 (query)할 수 있습니다. 운영 데이터를 의사결정으로 전환하는 것이 존재 이유인 팀들에게 이것이 바로 핵심 기능입니다.

이것이 당신을 무엇에 결합(coupling)시키는가

이제 설계자 (architect)의 다른 시각으로 보겠습니다. 이러한 이점들 각각은 동시에 결합 (coupling) 결정이기도 합니다.

이 중 어느 것도 Rayfin을 피해야 할 이유는 아닙니다. 이것들은 도입하기 전에 답해야 할 질문들입니다. 데이터가 OneLake에 속하고 라이프사이클이 Fabric에 속하는 앱이라면 매우 적합합니다. 클라우드 간에 휴대 가능해야 하거나, 시스템 기록 데이터 (system-of-record data)가 분석 자산 (analytics estate)에 머물러서는 안 되는 앱이라면 적합하지 않으며, 배포 명령의 편리함이 아무리 높더라도 그 사실은 변하지 않습니다.

또한 단순한 성숙도의 문제도 있습니다. 이것은 퍼블릭 프리뷰 (Public Preview) 단계입니다. 메커니즘은 문서화되어 있고 방향성도 명확하지만, 첫날부터 제공되는 프리뷰의 신뢰성과 Fabric 아티팩트 (Artifacts)로서 프로덕션 앱을 실행할 때의 장기적인 비용 구조는 아직 검증된 기록이 없습니다. 아키텍처는 실제적인 것으로 취급하되, 운영상의 성숙도는 아직 입증되지 않은 것으로 간주하십시오.

배포(Deliver)는 압축하지만, 책임(Accountability)은 압축하지 않습니다

이것이 아키텍트가 지켜야 할 선입니다. Rayfin은 배포(Deliver)의 메커니즘을 압축합니다. 하지만 배포(Deliver) 과정에서의 판단(Judgment)까지 압축하지는 않습니다.

| 배포 명령이 할 수 있는 일 |
| --- | --- |
| 데이터베이스 프로비저닝 (Provisioning) | 이 앱이 해당 데이터를 소유해야 하는지, 혹은 OneLake가 적절한 홈인지 결정할 수 없음 |
| ... |

따라서 이 스택의 나머지 부분이 요구하는 것과 동일한 규율이 여전히 적용됩니다. 에이전트(Agent)가 백엔드 정의를 초안합니다. 하지만 그것이 존재해야 하는지 결정하고, 제대로 작동하는지 검증하며, 프로덕션 환경에서 이를 소유하는 것은 여전히 인간의 몫입니다. Rayfin은 일주일 분량의 배관 작업 (Plumbing)을 제거해 줍니다. 하지만 아키텍트를 제거하지는 않습니다.

저렴한 배포는 판단의 가치를 높이는 것이지, 낮추는 것이 아닙니다. 잘못된 것을 출시하는 비용이 방금 낮아졌으므로, 출시되는 것들의 양은 곧 증가할 것입니다.

언제 선택해야 하는가

짧고 솔직한 의사결정 스케치입니다.

• 선택하십시오 (Reach for it): Microsoft 기반의 데이터 중심 앱을 구축 중이고, 데이터가 어차피 OneLake에 속해야 하며, 거버넌스 (Governance)를 새로 구축하기보다 상속받기를 원하고, 현재로서는 프리뷰 수준의 성숙도를 감수할 수 있는 경우.
• 기다리십시오 (Wait): 클라우드나 런타임 (Runtime) 간의 이식성 (Portability)이 필요할 때, 앱의 시스템 레코드 (System-of-record) 데이터가 분석 플랫폼에 위치해서는 안 될 때, 또는 워크로드 (Workload)가 프리뷰 단계의 리스크를 감당할 수 없을 때.
• 어느 쪽이든 (Either way): 인간의 검토 단계 (Human gates)를 유지하십시오. 저렴한 배포는 더 많은 것들이 출시될 것이기 때문에, 검증과 책임의 중요성을 낮추는 것이 아니라 오히려 더 높입니다.

Rayfin은 프롬프트에서 프로덕션(production)으로 넘어가는 간극에 대해 누군가가 내놓은 답변 중 가장 흥미로운 것 중 하나입니다. 정확히 말하자면, 이 간극이 단지 코드에 관한 것인 양 가장하지 않기 때문입니다. Rayfin은 배포(deployment), 데이터(data), 그리고 거버넌스(governance)를 실제 작업으로 취급하며, 실제로도 그러합니다. 무엇을 대상으로 지정할지에 대한 판단은 이전과 정확히 동일한 위치에 머물러 있습니다.

다음 글 읽기

• Coding Agents and Developer Economics on the Microsoft Stack - Rayfin이 공략하기 위해 구축된 전달 계층(deliver-layer)에 관한 논쟁.
• Copilot Credits Went Live: What Work IQ and Cowork Actually Cost - Microsoft가 에이전트 작업을 측정하고 관리하는 방식의 또 다른 2026년 6월의 변화.
• Foundry Hosted vs In-Process vs Copilot Studio Agents - 에이전트가 실제로 실행될 위치를 선택하기.

이 기사는 원래 az365.ai에 게시되었습니다. 저는 Alex Pechenizkiy이며, Microsoft AI 스택에 대해 정직하고 특정 벤더에 치우치지 않은 분석을 작성하는 Azure 및 Power Platform 솔루션 아키텍트입니다. 더 많은 내용은 az365.ai에서 확인하세요.