Retool RBAC와 감사 로그: 거버넌스를 갖춘 AI 앱 개발용 Retool 평가
Retool의 RBAC, 감사 로그, 접근 정책을 Retool 공식 문서로 검증한다. AI가 생성한 앱에서 무엇을 다스리는지, 엔터프라이즈 앱에서 Retool과 Lovable은 어떻게 다른지, 그리고 남는 권한 간극까지.
TL;DR: 거버넌스를 갖춘 AI 앱 개발을 위해 Retool을 평가하고 있다면, 그 접근 계층은 합격이며, 그렇지 않은 척해서는 안 된다. Retool에는 권한 그룹을 통한 RBAC, 누가 AI 빌더를 쓸 수 있는지에 대한 역할 기반 제어, 모든 쿼리 실행을 기록하는 감사 로그, SSO, 셀프 호스팅, 그리고 (2026년 10월부터 Postgres 대상 퍼블릭 베타로) 어떤 쿼리도 빠져나갈 수 없는 리소스 접근 정책이 있다. 2026년 6월부터는 Lovable, Cursor, Claude Code로 만든 앱에도 이 제어들을 적용한다. Retool이 주지 않는 것은 선언된 사실로서의 비즈니스 권한이다. “이 사람이 12,000달러짜리 환불을 발행할 수 있는가?”는 여전히 컴포넌트 속성과 쿼리 로직에 흩어진 JavaScript 안에 사는 경우가 많고, AI는 어떤 풀 리퀘스트가 검토할 수 있는 것보다도 빠르게 그 표현식들을 쓴다. 간극은 기본 보안이 아니다. 권한이 코드이지, 검토자가 한곳에서 읽을 수 있는 규칙이 아니라는 점이다.
세상에서 가장 평범한 Retool 앱을 그려보라 — 환불 콘솔이다. 엔지니어가 오후 한나절에 만든다 — 주문 테이블, “환불” 버튼, 쿼리 몇 개. 지원팀이 그것을 쓴다. 훌륭하다. 이것이 최상의 상태의 Retool이며, Retool은 이 점에서 진정으로 카테고리 최고다.
이제 여섯 달이 지났다. 그것을 만든 엔지니어는 팀을 옮겼다. 보안팀이 접근 검토를 진행하며 새 담당자에게 한 줄짜리 질문을 던진다: “어떤 역할이 10,000달러를 넘는 환불을 발행할 수 있고, 그것은 정확히 어디서 강제되는가?”
답하기 위해 새 담당자가 무엇을 해야 하는지 지켜보라. 들여다볼 단일한 장소가 없다. 그는 앱을 열고 JavaScript를 읽기 시작한다.
grep 테스트
“어디서 강제되는가”가 실제 Retool 앱에서 정말로 어떻게 보이는지 여기 있다. 큰 환불을 발행하는 권한은 적어도 세 개의 독립적인 표현식에 흩어져 있고, 저마다 손으로 쓰였으며, 저마다 모양이 다르다:
// 1. refundButton → "Hidden" 속성
{{ current_user.groups.map(g => g.name).includes('admin') ||
(current_user.groups.map(g => g.name).includes('support_lead') && refundAmount.value <= 10000) }}
// 2. refundAmount input → "disabled" 속성
{{ !current_user.groups.map(g => g.name).includes('support_lead') }}
// 3. issueRefund query → transformer (여기가 실제로 쓰기를 하는 부분이다)
if (refundAmount.value > 10000 && !current_user.groups.map(g => g.name).includes('finance')) {
throw new Error('Refunds over $10k require finance');
}세 군데. 미묘하게 다른 세 가지 조건. 버튼은 일부 사용자에게 자신을 숨기고, 입력란은 다른 사용자에게 자신을 비활성화하며, 쿼리는 세 번째 집합에 대해 오류를 던진다. 그것들은 하나의 일관된 규칙 — “지원 리드는 10,000달러까지, 그 위로는 재무” — 으로 합산되도록 되어 있지만, 그렇게 된다는 보장은 아무것도 없다. 버튼을 숨겨도, 누군가 다른 경로로 도달하면 그 밑의 쿼리는 여전히 실행된다. 다음 분기에 두 번째 쓰기 경로를 추가하면서 finance 검사를 잊으면, 어떤 화면도 드러내지 않는 구멍이 생긴다.
이것을 grep 테스트라고 부르자: “누가 X를 할 수 있는가”에 답하려면, 하나의 선언된 규칙을 읽는가, 아니면 앱을 grep 하는가? grep이라면, 그 앱은 권한 계층에서 다스려지지 않는다 — 그저 코드로 되어 있을 뿐이며, 접근 거버넌스(Retool이 완벽하게 해내는 것)는 실제로 당신을 해칠 수 있는 것보다 한 계층 위에 앉아 있다.
대조를 위해, 같은 권한을 선언된 사실로 보자 — 어느 버튼이나 쿼리를 거쳐 왔든, 런타임이 모든 경로에서 강제하는 하나의 규칙이다:
action: issue_refund
who_can_run:
- role: SupportLead when: amount <= 10000
- role: Finance when: amount > 10000
requires_approval: when: amount > 10000 # 던져지는 에러가 아니라, 예방적 게이트
audit: always읽을 곳 하나. 바꿀 곳 하나. 검토자 — 또는 AI — 가 추론할 대상 하나. 손으로 유지되는 세 개의 표현식과 하나의 선언된 규칙 사이의 차이는, “앱이 코드로 되어 있다”와 “앱의 권한이 다스려진다” 사이의 차이 전부다.
Retool RBAC와 감사 로그: 각 통제가 실제로 다루는 범위
grep 테스트가 공정하려면 Retool이 실제로 갖춘 통제를 정확히 적어야 한다. 아래는 2026년 11월 Retool 자체 문서와 대조해 확인한 내용이다:
| 통제 | 무엇을 다스리는가 | 어디서 멈추는가 |
|---|---|---|
| 권한 그룹(RBAC) | 그룹은 “역할을 부여하고 앱, 리소스, 워크플로, 에이전트에 대한 접근을 통제한다”(Retool 권한 가이드) | 누가 열고 편집하고 쿼리할 수 있는가이지, 일단 들어온 사람에게 특정 액션이 무엇을 해도 되는가가 아니다 |
| Assist RBAC(2026년 2월, Business 및 Enterprise) | 역할별로 Ask와 Build 모드, Ask 모드만, 또는 AI 빌더 접근 없음(변경 로그) | 누가 변경을 생성할 수 있는가이지, 생성된 변경이 무엇을 허용하는가가 아니다 |
| 감사 로그 | “쿼리 실행과 비밀번호 재설정 같은” 사용자 행동을 정확한 쿼리, 파라미터, IP 주소, 응답 시간과 함께 기록한다. Cloud에서 1년 보존, Business와 Enterprise에서 CSV 내보내기, Enterprise에서 Datadog 또는 Splunk 스트리밍(감사 로그) | 탐지적: 실행된 것을, 실행된 뒤에 기록한다 |
current_user 행 필터 | 값은 “인증된 세션으로부터 서버 측에서 계산되어” 각 쿼리에 주입된다(행 수준 보안) | 쿼리마다, 손으로: “필터를 빠뜨린 쿼리는 필터링되지 않은 데이터를 반환한다.” |
| 리소스 접근 정책 | 리소스의 테이블, 열, 행 접근을 앱, 쿼리 라이브러리, 원시 SQL, 에이전트에서 오는 모든 쿼리에 강제한다(접근 정책) | PostgreSQL 한정, 2026년 10월부터 퍼블릭 베타. 행 필터는 “사용자가 생성하는 행이나 사용자가 쓰는 값을 검증하지 않는다” |
| AI로 코딩한 앱의 거버넌스(2026년 6월) | Lovable, Replit, Cursor, Claude Code로 만든 앱은 “기존 권한과 감사 추적을 상속한다”. “권한은 데이터 소스에 연결된다”(Retool 뉴스룸) | 같은 계층: 데이터 소스 권한이지, 액션 수준의 비즈니스 규칙이 아니다 |
그중 두 행이 나머지보다 중요하다. 바로 이 글이 주장하는 방향으로 Retool이 움직이고 있음을 보여주기 때문이다.
접근 정책은 세 개의 표현식이 아니라 선언된 규칙이다. 리소스에 걸린 정책은 모든 쿼리에 적용되어 “어떤 쿼리도 빠져나갈 수 없다”. 쿼리마다 거는 current_user 필터의 정반대다. 데이터 권한 — 지원 리드가 어떤 행을 읽거나 삭제할 수 있는가 — 에 대해서는, Postgres에서 이것으로 grep 테스트의 대부분이 해소된다. 이 글의 6월 버전에 대한 정직한 업데이트는, Retool이 이제 그 계층에 대해 진짜 답을 갖고 있다는 것이다.
정책이 표현하지 못하는 것은 환불 규칙이다. 접근 정책 문서가 설명하는 것은 테이블, 열, 행에 대한 읽기, 쓰기, 삭제 접근이다. 금액 임계값, 승인 게이트, 쓰이는 값에 대한 조건은 설명하지 않는다. 그리고 행 필터는 사용자가 쓰는 내용을 명시적으로 검사하지 않는다. “지원 리드는 10,000달러까지, 그 위로는 재무, 선을 넘으면 승인”은 액션과 그 인자에 관한 규칙이므로, 여전히 위의 버튼, 입력란, transformer 안에 산다. 정책은 데이터 권한을 한곳으로 옮긴다. 비즈니스 권한은 JavaScript에 남는다.
이 표를 점수표로 읽으면 Retool은 보안 검토가 물을 모든 접근 거버넌스 질문을 통과한다. 그것이 한곳에서 답할 수 없는 질문은 이 글 맨 위의 질문이다: 어떤 역할이 10,000달러를 넘는 환불을 발행할 수 있고, 그것은 어디서 강제되는가?
왜 소스 관리가 이것을 메우지 못하는가
빈틈없는 Retool 엔지니어의 반박은 정당하며, 정확하게 답해야 한다: “우리에겐 Git으로 뒷받침되는 소스 관리와 감사 로그와 RBAC가 있다. 변경은 PR에서 검토된다. 접근은 다스려진다. 무엇이 빠졌는가?”
구체적으로 세 가지다.
첫째, Retool 앱의 PR은 컴포넌트 전반에 흩어진 JavaScript와 바인딩의 검토다 — 당신은 코드 리뷰를 하고 있으며, 이는 (a) 엔지니어를 요구하고, (b) *“이 변경이 누가 큰 환불을 발행할 수 있는지를 바꿨다”*는 구조화된 표현이 존재하지 않음을 뜻한다. 검토자는 세 컴포넌트 떨어진 Hidden 표현식에 대한 손질이 권한 경계를 옮겼다는 것을 알아차려야 한다. 흩어진 로직의 diff는 당신이 가장 봐야 할 바로 그것을 숨긴다.
둘째, 소스 관리가 검토하는 것은 코드이지, 사실로서의 권한이 아니다. “이 PR이 10,000달러 초과를 환불할 수 있는 사람을 바꿨는가?”는 Git diff가 직접 답하는 질문이 아니다. 그것은 머릿속에서 코드를 추적해 답하는 질문이다. 위의 선언된 규칙은 그 diff를 사소하게 만든다: who_can_run이 바뀌었거나, 바뀌지 않았거나.
셋째 — 그리고 이것이 업계가 향하는 방향에 가장 중요한데 — 로코드의 전제 자체가 비엔지니어와 AI가 앱을 바꾼다는 것이며, 흔히 비주얼 에디터 안에서, 흔히 아무 PR 없이 그렇게 한다는 것이다. 당신이 기대고 있는 거버넌스(PR 검토)는 로코드가 바로 그것을 위해 존재하는 변경들에는 존재하지 않는다. 감사 로그는 Hidden 속성이 바뀌었다고 사후에 말해줄 것이다 — 탐지적이지, 예방적이지 않다 — 그러나 그것이 출시되기 전에 그것이 어떤 권한을 부여했는지는 아무도 검토하지 않았다.
AI는 이것을 깨뜨리지 않는다. 이것을 증폭한다.
여러 해 동안 grep 테스트는 견딜 만했다. 사람이 JavaScript를 썼고, 다른 사람이 각 규칙이 어디 사는지에 대한 지식을 지녔기 때문이다. 흩어진 로직은, 사람이 만들고 기억한다면, 헤쳐 나갈 수 있다.
같은 앱에 AI를 겨누면 경제 논리가 양방향으로 뒤집힌다. AI는 1분에 쉰 개의 바인딩과 열두어 개의 transformer를 생성할 수 있다 — 어떤 검토자가 추적할 수 있는 것보다 빠르게 권한 결정을 만들어낸다. 그리고 그것이 만든 것을 검토하려면, 당신은 다시 화면을 가로질러 JavaScript를 읽는 자리로 돌아온다. diff를 떠볼 권한의 구조화된 단일 표현이 여전히 없기 때문이다. “Retool AI”와 에이전트(2025)는 실재하고 유용하지만, 그것들은 같은 손으로 지은 토대 위에서 자동화한다: 에이전트는 다스려진다(Retool은 그것이 호출하는 대상을 한정할 수 있다). 그러나 에이전트가 편집하는 앱은 — AI든 사람이든 코드가 아니라 사실로서 검토할 수 있는 어떤 형태로도 — 권한이 다스려지지 않는다.
AI가 가장 빠르게 만들어내는 것이 바로 Retool이 가장 검토하기 어렵게 만드는 것이다.
엔터프라이즈 앱을 위한 Retool vs. Lovable
사람들이 흔히 하는 또 다른 비교는 Retool 대 Lovable이며, 보통 “내부 도구 빌더 vs. AI 앱 생성기”라는 틀로 짜인다. 엔터프라이즈 앱에 더 유용한 틀은 이것이다: 각 통제는 누구의 사용자를 다스리는가?
| Retool | Lovable | |
|---|---|---|
| AI가 만드는 것 | Retool의 컴포넌트 런타임 위에서 도는 앱으로, 기존 리소스에 연결된다 | 풀스택 프로젝트 코드. 기본적으로 “Lovable의 관리형 인프라에 존재하며”, GitHub, GitLab, Bitbucket과 동기화된다(Lovable for Enterprise) |
| 역할 | 권한 그룹이 앱과 그 뒤의 리소스, 워크플로, 에이전트에 대한 접근을 통제한다 | 소유자, 관리자, 편집자, 뷰어, 외부 협업자가 앱을 만드는 워크스페이스를 다스린다(같은 페이지) |
| 최종 사용자 데이터 접근 | 데이터 소스 권한, current_user 필터, 접근 정책 | 내장 백엔드의 “사용자별 데이터를 위한” 행 수준 보안으로, 생성된 프로젝트의 일부다. Quick scan은 “게시할 때마다 실행되어 데이터베이스 접근 규칙을 검사한다” |
| 감사 | 쿼리 수준 감사 로그, Cloud에서 1년 | 워크스페이스 감사 로그는 “13주간 보존”되며, SIEM 또는 스토리지 버킷으로 예약 내보내기가 가능하다 |
| 셀프 호스팅 | Retool 관리형 또는 자체 관리형 셀프 호스팅 인스턴스(셀프 호스팅 Retool) | 백엔드와 데이터베이스는 “셀프 호스팅 Supabase를 포함해” 당신이 운영하는 인프라로 옮길 수 있다. 빌더 자체는 SaaS로 남는다 |
둘째와 셋째 행의 구분이 엔터프라이즈 적합성을 가른다. Lovable의 역할과 감사 로그는 앱을 만드는 사람들을 다스린다. 앱을 쓰는 사람들은 생성된 프로젝트 자체 백엔드 안의 접근 규칙이 보호하며, 그 규칙은 게시할 때마다 스캔이 검사한다. Retool은 앱을 쓰는 사람들을 다스린다. 앱이 Retool 안에서 돌기 때문이다. 그래서 Retool의 2026년 6월 행보는 생성 능력으로 경쟁하는 대신, Lovable과 비슷한 도구로 만든 앱을 자신의 데이터 소스 권한 아래에서 호스팅하는 것이다.
따라서 현실적인 엔터프라이즈 패턴은 “Retool이냐 Lovable이냐”가 아니라 “어디서든 생성하고, 거버넌스가 있는 곳에서 실행한다”이다. 어느 쪽도 grep 테스트를 바꾸지 않는다: Lovable 앱의 환불 임계값은 생성된 코드 안에, Retool 앱의 것은 바인딩과 transformer 안에 살며, 두 경우 모두 검토자는 코드를 읽어서 비즈니스 권한을 재구성한다.
Retool이 올바른 선택인 경우 — 그리고 메타데이터 모델이 당신에게 대가를 치르게 하는 경우
양방향으로 정직하라. 한쪽으로 치우친 글은 실제로 결정을 내리는 사람에게 무가치하기 때문이다.
Retool의 접근 거버넌스는 진정으로 동급 최고이며, 많은 앱에서 grep 테스트는 표면화되지 않는다: 신뢰받는 직원이 운용하고, SSO 뒤에 있으며, 그것을 쓴 바로 그 엔지니어들이 유지하는 내부 도구로서, “지원 리드는 10,000달러까지 환불할 수 있다”가 우연히 일치하고 좀처럼 바뀌지 않는 세 군데에서 강제되는 경우다. 그런 경우 — 그리고 요건이 기이할 때 언제든 SQL과 임의의 JavaScript로 뛰어들 자유를 위해 — Retool은 탁월하며, 짧은 시간 안에 내부 도구를 배선하는 용도에서는 매우 강하다.
그리고 선언된 메타데이터 모델은 반대 방향으로 실제 대가가 있다: 당신은 날것의 유연성을 가독성과 맞바꾼다. 모델에 그것을 위한 자리가 없을 때 속성에 임의의 JavaScript를 그저 붙여 넣을 수는 없다. 진정으로 이례적인 로직을 선언된 규칙으로 표현하는 것은 어디에나 쓰는 {{ }}보다 더 제약된다. 일회용 도구에게 그 제약은 순전한 오버헤드다. 이 모델이 본전을 뽑는 것은, “누가 무엇을 할 수 있는가”가 — 감사인, 규제 당국, 혹은 다음 담당자에 의해 — 증명을 요구받을 무언가일 때, 그리고 변경을 하는 것이 원래 작성자가 아니라 AI일 때뿐이다.
그것이 경계선이다. 그 아래에서 Retool은 실력으로 이긴다. 그 위에서 grep 테스트는, 여섯 달 뒤 클립보드를 든 누군가 앞에서 당신이 떨어지는 시험이다.
ObjectStack의 입장
ObjectStack은 Retool이 옳게 해내는 것 — 강력한 접근 제어, 셀프 호스팅, 당신 자신의 인프라 — 을 지키면서, 권한을 같은 다스려지는 계층으로 내린다. 앱의 로직은 열린, 읽을 수 있는 메타데이터다: issue_refund 같은 액션은 자신의 who_can_run, 자신의 승인 게이트, 자신의 감사 요건을 지니고, 한 번 선언되어 런타임이 모든 경로에서 강제한다. AI의 변경은 그 선언된 권한에 대한 diff다 — “이 변경은 SupportLead가 25,000달러까지 환불하게 한다”는 비엔지니어가 출시 전에 읽고 승인할 수 있는 한 줄이지 — 나중에 grep으로 발견하는 Hidden 표현식이 아니다.
“JavaScript로 뛰어들어 점심 전에 도구를 출시한다”에서 Retool을 능가할 생각은 없다. 주장은 더 좁고 경계선 위에서만 중요하다: AI가 당신의 내부 소프트웨어를 쓰고 있을 때, 누가-무엇을-할-수-있는가는 한곳에서 읽고 diff로 검토할 수 있는 사실이어야 한다 — 일치해야 하고 대개는 일치하는, 일치하지 않는 그 분기까지의, 세 표현식의 창발적 속성이 아니라.