Base44는 자연어 대화를 중심으로 화면, 데이터 엔터티, 인증, 백엔드 함수, 외부 연동과 호스팅을 한 작업 공간에서 구성하는 AI 애플리케이션 빌더다. 사용자는 만들고 싶은 제품을 설명하고, 실시간 미리 보기와 대시보드에서 생성 결과를 확인한 뒤 페이지, 데이터 규칙, 역할과 자동화 흐름을 반복해서 다듬는다.
이 도구를 사용해 보셨나요? 평점을 남겨 주세요
Base44는 자연어 대화를 중심으로 화면, 데이터 엔터티, 인증, 백엔드 함수, 외부 연동과 호스팅을 한 작업 공간에서 구성하는 AI 애플리케이션 빌더다. 사용자는 만들고 싶은 제품을 설명하고, 실시간 미리 보기와 대시보드에서 생성 결과를 확인한 뒤 페이지, 데이터 규칙, 역할과 자동화 흐름을 반복해서 다듬는다. 공개 웹사이트뿐 아니라 로그인형 업무 앱, 사내 운영 도구, 고객 포털, AI 기능이 있는 서비스와 게시된 웹 앱을 감싼 모바일 스토어 패키지에도 활용할 수 있다.
통합형 환경은 프런트엔드, 데이터베이스, 인증 공급자와 배포 환경을 처음부터 조립하는 시간을 줄인다. 그러나 제품 정의, 접근 제어, 장애 처리와 운영 책임까지 없애지는 않는다. 한 문장으로 앱을 만든 뒤 곧바로 공개하기보다 사용자와 데이터 경계를 먼저 정하고, 가장 작은 완결 흐름을 구현하고, 역할별 권한과 실제 데이터를 검증한 다음 연동과 자동화를 단계적으로 추가해야 한다.
이 글은 2026년 8월 8일에 확인한 공식 문서와 출처가 식별된 외부 자료를 기준으로 한다. Base44는 빠르게 바뀌므로 요금제 권한, 크레딧, 모델, 베타 기능은 구매나 배포 시점의 작업 공간에서 다시 확인해야 한다. Wix 인수, Base1 출시 보도, 리뷰 사이트의 의견은 각각 기업 사건, 단계적 배포, 제한된 사용자 표본으로 다루며 현재 모든 계정에 동일하게 제공되는 기능으로 확대 해석하지 않는다.
Base44는 자연어 제품 설명을 실제로 작동하는 애플리케이션으로 바꾸고 관리형 환경 안에서 실행한다. 편집기의 중심은 AI 채팅, 실시간 미리 보기, 관리 대시보드다. 채팅은 페이지, 엔터티, 폼, 권한과 로직을 만들거나 수정하고, 미리 보기는 사용자 흐름을 실행하며, 대시보드는 데이터, 사용자, 도메인, 로그, 보안과 배포를 관리한다.
따라서 단순한 랜딩 페이지 생성기보다 범위가 넓다. 공식 개발자 문서는 영구 데이터, 인증, 실시간 구독, 서버리스 함수, 연동과 호스팅을 다루며, JavaScript SDK와 CLI를 이용해 외부 프런트엔드가 Base44 백엔드를 사용할 수 있다고 설명한다. 비개발자는 대화식 인터페이스에서 시작하고, 개발자는 코드 보기와 GitHub 흐름으로 제어 범위를 넓힐 수 있다.
공식 빠른 시작 과정에서는 요구 사항을 채팅에 입력하고, 생성된 페이지와 데이터를 미리 보고, 대시보드에서 권한을 구성한 뒤 Base44 호스팅 주소에 게시한다. 결과물은 레코드를 저장하고 사용자를 인증하며 서버 측 작업과 자동화 흐름을 실행할 수 있으므로 정적인 목업에 그치지 않는다.
반면 AI는 비즈니스 규칙이 올바른지, 한 테넌트의 레코드가 다른 테넌트에 노출되지 않는지 스스로 보증하지 못한다. 결제 화면이 환불과 중복 요청을 처리하는지, API 오류 후 상태가 일관적인지는 팀이 검증해야 한다. Base44는 구현 속도를 높이는 도구이지 제품 책임자, 테스터와 보안 검토자를 대신하는 도구가 아니다.
Wix는 2025년 6월 18일 Base44 인수 완료를 발표하면서 Base44가 별도 제품과 사업으로 운영된다고 밝혔다. 이는 소유권과 기업 전략에 관한 사실이다. Wix의 특정 편집 기능, 요금제 또는 인프라가 Base44 계정에 자동으로 통합됐다는 근거로 사용할 수 없다.
TechCrunch는 2026년 6월 Base44가 자체 특화 모델 Base1을 단계적으로 출시하기 시작했다고 보도했다. 단계적 출시는 계정마다 시점과 제공 범위가 다를 수 있다는 뜻이다. 프로젝트가 Base1에 의존한다면 실제 작업 공간에서 모델 선택 가능 여부, 크레딧 비용과 동작을 확인해야 한다.
Default 모드는 요청을 앱에 적용하므로 범위와 승인 기준이 분명한 기능 변경에 적합하다. Discuss 모드는 앱을 수정하지 않고 데이터 모델, 역할과 위험을 논의하는 용도다. Edit 모드는 미리 보기의 요소를 선택해 시각적 속성을 직접 또는 AI의 도움으로 조정한다. 수동 편집과 AI 편집의 크레딧 조건은 현재 화면에서 확인해야 한다.
애매한 요구 사항은 먼저 Discuss에서 가정과 대안을 정리한 뒤 Default로 구현하는 편이 안전하다. 간격, 색상과 개별 요소 스타일은 Edit에서 다루고, 권한이나 데이터 로직은 사용자 역할, 조건, 상태, 제외 사항과 검증 결과를 포함한 규칙으로 요청하는 것이 좋다.
Base44는 페이지와 컴포넌트를 생성하고 채팅과 시각 편집으로 디자인을 수정할 수 있다. 실시간 미리 보기는 빠른 확인에 유용하지만 보기 좋은 첫 화면만으로 품질을 판단하면 안 된다. 빈 데이터, 로딩, 긴 이름, 오류 메시지, 좁은 화면, 키보드 탐색과 권한 부족 상태를 실제 콘텐츠로 확인해야 한다.
다국어 앱은 긴 레이블과 줄바꿈이 내비게이션과 폼을 깨뜨리지 않는지도 살펴야 한다. 열 개의 데모 레코드가 잘 보인다고 해서 대량 목록, 페이지네이션과 느린 네트워크까지 검증된 것은 아니다.
플랫폼은 데이터 엔터티와 레코드 관리 화면을 제공하며 AI가 필드를 만들고 폼과 뷰를 연결할 수 있다. 개발자 문서는 유연한 NoSQL 계층, 실시간 구독과 엔터티 접근 규칙을 설명한다.
화면 수를 늘리기 전에 지속되는 비즈니스 개념을 엔터티로 정의하고, 소유자와 조직 관계, 허용되는 상태를 정해야 한다. 다중 조직 앱에서는 모든 비공개 레코드에 테넌트 관계가 필요하며, 서로 다른 두 조직의 테스트 계정으로 직접 URL과 데이터 작업을 교차 시도해야 한다.
공식 빌드 흐름에는 관리형 인증, 앱 공개 범위, 초대 사용자, 사용자 및 관리자 역할, 데이터 권한과 다른 사용자로 실행하는 테스트가 포함된다. 현재 로그인 문서는 완전히 사용자 정의된 인증 흐름과 완전한 화이트라벨 내장 로그인 화면을 지원하지 않는다고 설명한다.
로그인은 신원을 확인하지만 권한은 데이터 범위를 결정한다. 버튼을 숨기는 것만으로는 레코드를 보호할 수 없다. 생성, 조회, 수정, 삭제 권한을 각각 확인하고, 민감한 작업은 서버 측에서 현재 사용자의 역할과 소유 관계를 다시 검사해야 한다.
대상 요금제에서는 브라우저에 둘 수 없는 로직을 백엔드 함수로 실행할 수 있다. 외부 API 비밀, 웹훅 검증, 결제 확인과 권한 있는 데이터 처리가 대표적인 예다. 키는 비밀 저장 시설에 보관하고 프런트엔드 코드, 일반 필드나 채팅 프롬프트에 넣지 않아야 한다.
생성된 함수는 입력 검증, 인증, 권한, 멱등성, 시간 초과와 오류 응답을 검토해야 한다. 서비스 역할을 사용할 때는 범위를 줄이고, 클라이언트가 전달한 사용자 ID를 신원 증거로 신뢰하지 않는다.
Base44 문서는 일반 작업을 위한 내장 연동, 외부 서비스에 인증하는 커넥터, OpenAPI 명세에서 가져오는 작업 공간 사용자 정의 연동을 구분한다. 관리형 자격 증명을 사용하면 비밀을 프런트엔드에서 분리할 수 있다.
연동은 외부 서비스의 제약과 크레딧 비용도 함께 가져온다. 어떤 계정이 연결을 소유하는지, 어떤 권한 범위를 승인했는지, 인증 만료 시 어떤 일이 생기는지 기록해야 한다. 페이지네이션, 속도 제한, 재시도와 부분 실패를 시험하지 않은 동기화는 완성된 기능이 아니다.
공식 문서에 따르면 2026년 7월 6일부터 생성된 앱은 Workflows를 사용하고, 이전 앱은 기존 Automations가 남아 있을 수 있다. 한 앱은 둘 중 하나만 제공한다. Workflows는 일정, 엔터티 변경, 앱 내 Agent 대화나 지원되는 커넥터 이벤트로 시작해 여러 작업, 조건과 지연을 연결하고 실행별 진행 상태를 보여 준다.
따라서 과거 튜토리얼의 Automation 메뉴를 새 앱에 그대로 적용하면 안 된다. 새 흐름은 명확한 시작 조건과 종료 상태를 갖고 스스로를 반복 실행하지 않도록 설계해야 한다. 이메일, 결제나 외부 레코드 변경에는 멱등 키와 재조정 절차가 필요하다.
앱은 Base44 호스팅 주소를 받고 편집기에서 게시할 수 있다. 대상 요금제는 사용자 도메인을 연결할 수 있으며 플랫폼이 HTTPS 인증서를 관리한다. 외부 프런트엔드를 별도 호스트에 두고 Base44의 데이터와 함수만 사용하는 구성도 문서화돼 있다.
게시 버튼은 릴리스 관리의 대체물이 아니다. 검토한 버전, 역할 테스트, 최신 보안 검사, 유효한 비밀, 핵심 연동과 롤백 방식을 체크리스트로 남긴다. 데이터 모델을 바꾼 릴리스는 새 레코드뿐 아니라 기존 레코드로도 시험해야 한다.
현재 문서는 Builder 이상에서 ZIP 다운로드나 GitHub 연결을 사용할 수 있다고 안내한다. GitHub 연동은 앱과 저장소의 양방향 동기화, 로컬 개발, 브랜치와 풀 리퀘스트 기반 검토를 지원한다. 코드 보기, CLI와 JavaScript SDK도 개발자 흐름에 포함된다.
그러나 코드와 CSV를 내려받는다고 관리형 인증, 데이터베이스와 호스팅이 동일한 자체 운영 구성으로 복제되지는 않는다. 이탈 계획은 계정, 데이터, 파일, 함수, 연동, 워크플로와 도메인을 각각 대체하는 방법까지 포함해야 한다.
Base44는 모바일 브라우저와 iOS·Android 빌더 앱에서 프로젝트를 생성하고 편집할 수 있다고 문서화한다. 게시된 앱은 모바일 브라우저에서 실행되거나 홈 화면에 추가될 수 있다. 일부 도메인과 보안 관리 작업은 데스크톱이 필요할 수 있다.
스토어 제출용 결과는 게시된 웹 앱을 감싼 안전한 web-view 래퍼다. 독립적인 네이티브 재구현이 아니며 현재 네이티브 푸시 알림과 완전한 오프라인 모드를 제공하지 않는다. Apple과 Google 개발자 계정, 개인정보 고지와 스토어 심사는 앱 소유자가 담당한다.
창업자는 로그인, 폼, 저장된 레코드와 한 가지 핵심 행동을 가진 초기 앱으로 제품 가설을 검증할 수 있다. 정적인 발표 자료보다 가입, 입력, 결과와 재방문이 중요한 아이디어에 특히 유용하다.
첫 버전은 한 사용자 여정과 한 사업 결과만 증명하는 편이 좋다. 마켓플레이스는 한쪽을 수동으로 운영하고, 추천은 감사 가능한 규칙으로 시작할 수 있다. 요구가 검증되기 전에 거대한 스키마와 자동화를 만드는 것은 빠른 개발의 장점을 없앤다.
재고 추적, 승인 큐, 온보딩 목록, 이슈 레지스터와 서비스 대시보드는 엔터티, 역할, Workflows를 조합해 만들 수 있다. 일반 SaaS가 정확히 맞지 않는 구체적이고 경계가 분명한 업무에 적합하다.
내부 앱도 직원, 고객, 재무 정보를 다룰 수 있다. Base44가 원본 시스템인지 다른 플랫폼의 복제본인지 정하고, 동기화 충돌과 실패를 누가 해결하는지 문서화해야 한다.
인증과 데이터 권한을 사용하면 고객별 주문, 문서, 요청과 메시지를 보여 주는 포털을 만들 수 있다. 모든 레코드에 사용자 또는 조직 소유 관계를 두고 목록과 함수에서 같은 조건을 집행해야 한다.
서로 다른 두 고객 계정으로 경계를 넘는 조회를 시도한다. 개인화된 대시보드가 보여도 기본 쿼리가 다른 조직 데이터를 반환한다면 포털은 안전하지 않다.
공개 사이트와 계산기, 영업 파이프라인, 프로젝트 상태 화면, 문서 처리기나 연구 보조 도구를 만들 수 있다. 콘텐츠 중심 사이트라면 CMS의 편집, SEO, 리디렉션과 접근성 흐름도 비교해야 한다. Base44의 통합형 강점은 로그인과 데이터, 앱 동작이 필요한 경우 더 크다.
대시보드의 각 지표는 정의, 출처 필드, 시간대와 누락 데이터 규칙을 가져야 한다. AI 결과에는 근거와 검토 상태를 저장하고, 환불이나 권한 변경처럼 영향이 큰 동작은 사람이 승인하도록 한다.
새 리드가 확인 메일을 보내고 일정 시간이 지난 뒤 상태를 검사해 팀에 알리는 흐름처럼 여러 단계를 연결할 수 있다. 실행 기록은 어느 단계가 실패했는지 파악하는 데 도움을 준다.
재실행 시 동일한 청구서나 레코드가 중복 생성되지 않도록 외부 식별자를 저장한다. 외부 호출이 일부만 성공한 경우를 위해 운영자가 확인하고 복구할 수 있는 화면을 마련한다.
대상 사용자, 해결할 문제, 가장 중요한 흐름과 저장할 정보를 정한다. 공개 여부, 역할, 민감 필드, 연동, 예상 규모와 첫 버전에서 제외할 범위를 명시한다. “멋진 앱” 대신 사용자가 어떤 조건에서 무엇을 하고 어떤 기록이 남아야 하는지 쓴다.
앱을 수정하기 전에 엔터티, 관계, 역할, 오류 경로와 가정을 제안해 달라고 요청한다. 조직 관계가 왜 필요한지, 웹훅을 왜 검증해야 하는지 설명하게 하고 잘못된 가정을 수정한다. 이 단계는 재작업과 크레딧 낭비를 줄인다.
계정 생성, 하나의 레코드 제출, 올바른 역할의 조회와 하나의 핵심 행동을 구현한다. 모든 대시보드와 연동을 한 번에 요구하지 않는다. 생성 후 새 세션과 새로 고침에서도 데이터와 권한이 유지되는지 확인한다.
중요 엔터티의 생성, 읽기, 수정, 삭제를 별도로 시험한다. 외부 자격 증명을 비밀 시설로 옮기고 민감 호출이 백엔드에서 실행되는지 확인한다. 보안 검사를 실행한 뒤 각 권고를 직접 판단하고, 역할별 더미 계정으로 승인되지 않은 작업을 시도한다.
연결 계정과 범위를 확인하고 정상 호출, 오류, 인증 만료와 중복 이벤트를 시험한다. 워크플로의 트리거, 작업, 조건, 지연, 최종 상태와 처리 완료 표식을 정의한다. 금액이나 고객 상태를 바꾸는 흐름은 검토 큐나 대사 보고서를 둔다.
긴 이름, 비어 있는 선택 필드, 특수 문자와 경계값을 채운다. 데스크톱과 모바일에서 내비게이션, 포커스, 폼 오류, 느린 작업과 역할별 상태를 확인한다. 스토어 래퍼를 만들기 전에 웹 흐름이 완전해야 한다.
중요 데이터와 코드를 내보내고 검토된 버전이나 브랜치를 저장한다. 현재 요금제, 연동, 도메인과 보안 검사 결과를 기록한다. 가능한 경우 제한된 사용자에게 먼저 공개하고, 실패 함수, 워크플로 실행과 크레딧 사용을 관찰한다.
“승인 페이지를 추가해 줘”보다 “관리자는 자기 조직의 대기 요청만 승인하며 행위자와 시간을 저장한다”가 테스트 가능하다. 기능과 시각 변경도 분리해 회귀 원인을 명확히 한다.
인증, 스키마, 결제와 디자인 개편을 한 요청에 섞지 않는다. 작은 변경은 전후 상태가 선명하고 무관한 작업을 버리지 않고 되돌릴 수 있다. 요구, 프롬프트, 영향 범위, 테스트와 배포를 외부 변경 기록에 남긴다.
메시지 크레딧과 연동 크레딧은 별도이며 모델과 작업에 따라 소비가 달라진다. Discuss로 계획하고 불필요한 이벤트를 일찍 거르며 가능한 경우 호출을 묶는다. 최초 빌드뿐 아니라 수정, 예약 작업과 유지 비용을 관찰한다.
연동을 끊고, 인증을 만료시키고, 이벤트를 두 번 보내고, 필수 데이터를 누락시킨다. 사용자가 실행 가능한 오류를 보고 운영자가 재시도하거나 대사할 수 있는지 검증한다. 파괴적 작업에는 확인과 감사 기록을 둔다.
엔터티, 데이터 내보내기, 함수, 연동, 비밀, 도메인과 인증 가정을 기록한다. 대상 요금제라면 GitHub나 정기 ZIP을 사용한다. 관리형 인증, 데이터베이스, 파일과 워크플로를 무엇으로 대체할지도 시험해야 한다.
외부 입력, 신원, 서비스 역할, 결제, 웹훅과 외부 API를 처리하는 코드를 우선 검토한다. 서버 측 검증과 권한을 확인하고 노출된 키와 테스트 값을 검색한다. 내장 검사는 보조 수단이지 보안 인증이 아니다.
사용자, 업무 흐름과 승인 기준을 정의할 수 있지만 초기 검증을 위해 전체 기술 스택을 조립하고 싶지 않은 팀에 적합하다. 제품 관리자와 디자이너도 정적 목업보다 실제 레코드와 역할이 있는 기능형 시제품을 만들 수 있다.
스프레드시트, 폼과 메신저에 흩어진 구체적인 프로세스를 구조화할 수 있다. 외부 고객에게 납품할 때는 작업 공간, 도메인, 데이터, 청구와 유지보수 소유권을 계약 전에 정한다.
개발자는 생성된 UI로 빠르게 시작하고 코드, GitHub, CLI와 SDK로 확장할 수 있다. 반대로 완전한 자체 호스팅, 특수 데이터베이스 보장이나 런타임 제어가 처음부터 필수라면 다른 기반이 더 적합할 수 있다.
완전 오프라인, 깊은 네이티브 기능, 완전 사용자 정의 인증, 독립 감사를 받은 규제 통제 또는 특수 배포 지역이 필수라면 Base44의 현재 경계와 맞지 않을 수 있다. 시제품으로 쓰더라도 데이터가 쌓이기 전에 프로덕션 기반을 결정한다.
주요 편집기는 브라우저에서 동작하며 게시 앱은 데스크톱과 모바일 브라우저에서 열린다. 공식 iOS·Android 빌더 앱도 문서화돼 있지만 일부 관리 작업은 데스크톱을 요구하므로 완전한 대체로 보지 않는다.
대상 요금제에서는 코드 보기, ZIP, GitHub, CLI와 JavaScript SDK를 사용할 수 있다. IPA와 AAB 생성 흐름은 웹 앱의 스토어 래퍼를 위한 것이며 네이티브 푸시나 완전 오프라인 능력을 추가하지 않는다.
현재 공식 결제 문서는 Free, Starter, Builder, Pro, Elite를 나열한다. 이 글은 가격, 정확한 앱 수와 크레딧 수치를 고정하지 않는다. 기능과 권한은 요금제 이름과 별도로 바뀔 수 있으므로 구매 직전 공식 표와 결제 화면에서 필요한 항목을 확인한다.
AI 빌드·편집은 메시지 크레딧, 연동과 자동화는 연동 크레딧을 사용한다. 모델과 작업 복잡도에 따라 소비가 달라질 수 있다. 장기 비용에는 반복 수정, 예약 실행, 외부 API, 도메인과 앱 스토어 계정도 포함한다.
GitHub, 내보내기, 사용자 도메인, 백엔드나 스토어 기능이 특정 단계에 묶일 수 있다. 크레딧만 비교하지 말고 프로덕션에 꼭 필요한 기능 목록을 현재 요금표와 일대일로 대조한다.
Lovable은 프롬프트 기반 웹 제품 생성, Replit은 AI 코딩 에이전트와 범용 클라우드 개발 환경, Bolt는 브라우저 프로젝트 파일과 웹 개발 흐름에 강점이 있다. 생성 스택, 백엔드 선택, Git 협업과 독립 인프라로의 이동 비용을 비교한다.
Softr는 포털과 내부 앱을 구조화된 블록으로 구축하는 데 초점을 둔다. Retool과 Microsoft Power Apps는 기업 연동, 관리와 거버넌스에서 성숙한 선택지가 될 수 있다.
맞춤 스택은 더 많은 엔지니어링과 운영을 요구하지만 런타임, 데이터베이스와 배포를 가장 세밀하게 통제한다. 규제 시스템, 깊은 네이티브 앱, 특수 성능 요구에는 더 안전한 기반일 수 있다.
Product Hunt와 G2에는 빠른 제작을 칭찬하는 의견과 크레딧, 지원, 복잡한 프로젝트를 지적하는 의견이 함께 있다. 확인 시점에 G2는 4개, Capterra는 3개의 리뷰만 표시했다. 이 작은 자기 선택 표본으로 전체 품질을 단정할 수 없다.
보안 검사는 권한 격차, 노출된 자격 증명, 로그인 검증, 패키지 취약점과 브라우저 보안 헤더를 확인하지만 모든 조치를 자동 적용하지 않는다. 공식 문서는 앱 소유자가 설정을 검토할 책임이 있다고 명시한다. 고위험 앱은 별도의 보안과 규정 준수 검토가 필요하다.
공식 개인정보 문서는 기본 미국 저장을 설명하고, 대상 요금제와 앱 생성일에 따른 EU 또는 영국 데이터 레지던시를 단계적으로 제공한다고 한다. 저장 위치와 처리 위치도 구분된다. 계약, 하위 처리자와 실제 지역을 최신 문서에서 확인하지 않고 규제 적합성을 주장하면 안 된다.
대상 요금제에서 코드와 컬렉션 데이터를 내보낼 수 있어도 관리형 인증, 데이터베이스와 호스팅은 동일한 자체 운영 서비스로 나오지 않는다. 이탈에는 사용자, 데이터, 파일, 함수, 연동과 워크플로의 재구축이 필요하다.
스토어 패키지는 web-view이며 네이티브 푸시와 완전 오프라인을 지원하지 않는다. 완전 사용자 정의 인증과 완전 화이트라벨 로그인 화면도 현재 지원되지 않으며 화이트라벨은 계획으로만 언급된다.
Workflows 전환과 모델 롤아웃은 오래된 튜토리얼이 빠르게 틀릴 수 있음을 보여 준다. 앱 성능은 데이터 모양, 쿼리, 연동과 트래픽에 좌우된다. 중요한 프로젝트는 실제 부하와 장애를 시험하고 현재 제한과 지원 조건을 공급자에게 확인한다.
공식 문서는 화면, 데이터, 인증, 백엔드 함수, 연동, 워크플로와 호스팅을 다룬다. 다만 생성 완료만으로 프로덕션 준비가 끝나는 것은 아니며 권한, 테스트와 운영을 별도로 검증해야 한다.
기본 앱은 채팅과 시각 편집으로 만들 수 있다. 복잡한 데이터, 보안, 연동과 이전에는 기술 지식이 유용하며, 개발자는 코드, GitHub, CLI와 SDK를 사용할 수 있다.
현재 문서는 Free와 Starter, Builder, Pro, Elite를 나열한다. 앱 제한, 크레딧과 기능은 바뀔 수 있으므로 실시간 요금표를 확인해야 한다.
메시지 크레딧은 AI 빌드와 편집, 연동 크레딧은 외부 작업과 자동화에 사용된다. 실제 소비는 모델과 작업에 따라 달라지므로 작업 공간의 사용 기록이 기준이다.
대상 요금제는 ZIP, GitHub와 엔터티 데이터 내보내기를 지원한다. 관리형 인증, 데이터베이스와 호스팅까지 자체 운영 환경으로 복제되지는 않으므로 전체 이전 계획이 필요하다.
대상 사용자는 스토어 준비 검사를 거쳐 제출 패키지를 만들 수 있다. 자체 개발자 계정과 심사 대응이 필요하고, 결과물은 web-view 래퍼라서 네이티브 푸시와 완전 오프라인은 제공하지 않는다.
공개 범위와 엔터티 권한을 설정하고, 비밀을 안전한 시설에 저장하며, 보안 검사를 실행하고 모든 역할로 권한 우회를 시험한다. 민감한 시스템은 독립 보안 및 규정 준수 검토를 추가한다.
둘 다 공식 문서에 있지만 요금제와 작업 공간 조건을 따른다. 도메인은 관리형 HTTPS를 사용하고 GitHub는 버전 관리와 로컬 협업에 활용할 수 있다. 현재 자격을 구매 전에 확인한다.
두 세대의 자동화 시스템이다. 2026년 7월 6일부터 만든 앱은 Workflows를 사용하며 과거 앱은 Automations가 남을 수 있다. 한 앱은 둘을 동시에 사용하지 않는다.
관리형 플랫폼의 경계가 제품 요구와 맞고 권한, 신뢰성, 비용, 이동성과 지원을 대표적인 파일럿으로 검증했다면 가능하다. 완전한 인프라 통제, 깊은 네이티브 기능, 특수 확장성이나 규제 배포가 필수라면 더 통제 가능한 기반을 선택해야 한다.
