Retool vs. AI 네이티브 앱 플랫폼: 그것이 다스리는 것은 누가 앱을 여느냐이지, 로직이 무엇을 하느냐가 아니다
Retool은 로코드에서 최고의 접근 거버넌스를 갖췄다 — RBAC, 감사 로그, SSO, 셀프 호스팅. 그러나 비즈니스 로직은 화면마다 흩어진 JavaScript라, 어떤 사람도 diff로 검토할 수 없고 어떤 AI도 감사할 수 없다. 그것이 그 간극이다.
TL;DR: Retool의 접근 거버넌스는 로코드에서 최고다 — 쿼리 단위까지 내려가는 RBAC, 행 수준 보안, 감사 로그, SSO, Enterprise에서의 셀프 호스팅. 그중 어느 것도 문제가 아니며, 문제인 척해서도 안 된다. 문제는 그것이 다스리는 계층이다. RBAC는 어떤 역할이 어떤 리소스에 닿을 수 있는지를 통제한다. 그러나 실제 비즈니스 권한 — 이 사람이 12,000달러짜리 환불을 발행할 수 있는가? — 은 손으로 쓴 JavaScript 안에 살아 있으며, 버튼의 Hidden 속성, 입력란의 disabled 바인딩, 쿼리의 transformer에 흩어져 있다. 그중 둘이 일치한다는 보장은 없고, 비엔지니어는 그중 어느 것도 읽을 수 없으며, 그 표현식들을 쓰는 AI는 어떤 풀 리퀘스트가 검토할 수 있는 것보다도 빠르게 권한 결정을 만들어낸다. 간극은 보안이 아니다. 권한이 선언되고 검토 가능한 사실이 아니라 코드라는 점이다.
세상에서 가장 평범한 Retool 앱을 그려보라 — 환불 콘솔이다. 엔지니어가 오후 한나절에 만든다 — 주문 테이블, “환불” 버튼, 쿼리 몇 개. 지원팀이 그것을 쓴다. 훌륭하다. 이것이 최상의 상태의 Retool이며, Retool은 이 점에서 진정으로 카테고리 최고다.
이제 여섯 달이 지났다. 그것을 만든 엔지니어는 팀을 옮겼다. 보안팀이 접근 검토를 진행하며 새 담당자에게 한 줄짜리 질문을 던진다: “어떤 역할이 10,000달러를 넘는 환불을 발행할 수 있고, 그것은 정확히 어디서 강제되는가?”
답하기 위해 새 담당자가 무엇을 해야 하는지 지켜보라. 들여다볼 단일한 장소가 없다. 그는 앱을 열고 JavaScript를 읽기 시작한다.
grep 테스트
“어디서 강제되는가”가 실제 Retool 앱에서 정말로 어떻게 보이는지 여기 있다. 큰 환불을 발행하는 권한은 적어도 세 개의 독립적인 표현식에 흩어져 있고, 저마다 손으로 쓰였으며, 저마다 모양이 다르다:
// 1. refundButton → "Hidden" 속성
{{ currentUser.groups.includes('admin') ||
(currentUser.groups.includes('support_lead') && refundAmount.value <= 10000) }}
// 2. refundAmount input → "disabled" 속성
{{ !currentUser.groups.includes('support_lead') }}
// 3. issueRefund query → transformer (여기가 실제로 쓰기를 하는 부분이다)
if (refundAmount.value > 10000 && !currentUser.groups.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 엔지니어의 반박은 정당하며, 정확하게 답해야 한다: “우리에겐 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이 올바른 선택인 경우 — 그리고 메타데이터 모델이 당신에게 대가를 치르게 하는 경우
양방향으로 정직하라. 한쪽으로 치우친 글은 실제로 결정을 내리는 사람에게 무가치하기 때문이다.
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로 검토할 수 있는 사실이어야 한다 — 일치해야 하고 대개는 일치하는, 일치하지 않는 그 분기까지의, 세 표현식의 창발적 속성이 아니라.