목차
title: Retool로 운영도구 빠르게 만들기
YAML
️ 배경
새로운 비즈니스 모델을 기획하던 도중에 데모 버전의 서비스가 필요했습니다. 서비스에 대한 기획들이 완벽하게 정의되지 않았고, 데이터 구조, 서비스의 흐름 등 서비스의 전반적인 요소들이 바뀔 가능성이 높았기 때문에 단단한 아키텍처를 가지고 개발을 섣불리하기 어려운 상황이었습니다.
이른 시일 내에 서비스를 만들고 고객의 피드백을 받아봐야 했기 때문에, 본 서비스도 최대한 간단하게 작성하고 뒤의 운영툴도 노코드 툴로 개발하게 되었습니다. 처음 써보기에 개발하기 까다롭지만, 개발 리소스를 최소한으로 하고 변동이 큰 기획에 빠르게 대응하기 위해서였습니다.
노코드 툴 (No-code), Retool
저희는 이번 작업에서 Retool을 이용했습니다. Retool은 회사 내부 운영 도구를 Drag-and-drop으로 쉽게 만들 수 있는 노코드 툴입니다.
장점
쉽고 간단한 외부와의 연결
표나 테이블을 나타내기에 적합하고 데이터에 집중되어 있기 때문에 외부 서비스와 연결 부분에서 제공되는 게 많습니다. MySQL, Redis, GraphQL 등 많이 쓰이는 서비스들을 쉽게 연결할 수 있습니다.
Resources 설정
높은 응용도
본격적으로 retool을 사용하기 전에는 단순하게 대시보드 형태로 데이터 보여주는 화면만 가능하다고 생각했었습니다. 그러나 쓰고 보니 제공되는 컴포넌트와 JavaScript 스크립트 코드를 이용하면 다양한 형태의 화면도 가능합니다. 또한 컴포넌트별로 세세한 기능들이 제공되어서 다른 컴포넌트와 결합하여 사용할 수 있습니다.
예를 들어 Table row 클릭에 따라 액션을 설정할 수 있습니다. 그 외에도 제공된 여러 Event에 따라 다양한 설정이 가능합니다.
Releases version 관리
Releases 기능을 사용하여 앱의 변경 사항을 버전화할 수 있습니다. 모든 사용자가 사용하는 라이브 버전으로 변경할 수 있으며 이 기능을 통해 변경 사항을 안전하게 테스트, 빌드 및 릴리즈할 수 있습니다. 버전을 변경하고 현재 작업 버전을 이전 버전의 변경 사항으로도 되돌릴 수 있습니다. (참고: https://docs.retool.com/docs/releases-and-history )
Retool을 내부 VPC를 설정해서, 자체적으로 Hosting할 수도 있습니다. 그럴 때는 Github등의 Git기반 코드 관리가 가능합니다. 자세한 내용은 이 페이지를 참고 하십시오.
단점
난이도의 한계
간단한 테이블 형태의 화면 제작은 쉽고 빠르지만 복잡하고 난이도 있는 페이지는 어렵습니다. 컴포넌트의 형태도 정해져 있고, 그 안에서 활용하여 만들어낼 수 있는 화면도 한계가 있기 때문에 복잡한 앱을 만들기엔 적합하지 않습니다. (참고 : https://retool.com/templates/)
한정적인 디자인 커스텀
Retool 내에서 컴포넌트별로 스타일을 지정할 수 있습니다. 하지만 기본적인 텍스트 색, 배경색, 선의 굵기, 선의 색 정도만 제공하고 있습니다.
텍스트의 크기, padding 등의 값들은 앱 내에 Global CSS로 하나하나 지정해줘야 합니다. 설정이 제대로 안 들어가는 속성도 있고, 툴 자체에서 제공되지 않기 때문에 불편한 점이 있었습니다.
컴포넌트 스타일 설정 화면
global css로 style 지정
최적화의 한계
앱의 속도를 개선하기 위해 최적화에 대한 시도를 많이 했었습니다.
테이블마다 각각의 데이터를 넣어줘야 해서 초기 렌더링 시, 한꺼번에 DB 코드들이 작동하게 됩니다. 그러다 보니 새로고침할 때마다 n개의 테이블의 데이터를 가져오면서 DB Connecition이 몇 배로 늘어나게 되었습니다. Global CSS와 비슷하게 JavaScript 코드를 지정할 수 있었습니다. 이 방식으로 탭의 값에 따라 특정 테이블값만 가져올 수 있도록 하고자 하였지만, DB trigger 함수가 작동되지 않았습니다.
그래서 쿼리로 필터링하여 DB 데이터를 불러오지 않고 초기에 한 번씩만 데이터 테이블을 가져온 후, 그 데이터를 활용하여 필터링이나 매핑한 값을 내부 state로 정의하여 앱에서 사용하는 방식으로 변경하였습니다.
공개 앱에서 사용자 인증의 문제
retool 앱을 공개적으로 다른 사람에게 공유하고자 할 때, 사용자 인증을 사용할 수 없습니다. 즉, 링크를 공개하면 모두에게 다 보이게 됩니다.
Custom Authentication in Public Apps
Like OAuth 2.0 and other SSO based auth options, custom auth workflows store defined
variables using a relation with the authenticating user's Retool account.
Because public app viewers do not use a retool account, custom auth is not supported in public apps.
retool 문서에 따르면 공개 상태의 사용자는 retool 계정을 사용하지 않고 앱을 사용하기 때문에 공개 앱에서는 사용자 인증을 제공하고 있지 않는다고 기록되어 있습니다. 또한 완전히 익명이므로 시스템을 사용할 사용자가 없다고 판단하여 사용자 정보를 수집하지 않는다고 나와 있습니다.
그래서 사용자 인증을 원하는 경우, 앱을 Public 상태가 아닌 Viewer 상태로 공유하고 사용자에게 권한을 부여하여 Retool 계정으로 로그인해야 합니다.
쓰면서 알게 된 것들
Staging / Production 구분 방법
retool에서 Environments 설정하고 별도의 테스트를 할 수 있습니다. 설정에서 각각의 환경을 정의하고 변경하고 삭제할 수 있습니다.
환경에 따라 리소스 설정도 구분하여 할 수 있습니다. production / staging으로 구분하여 데이터를 다르게 표시하고 테스트도 가능합니다.
외부 API를 JWT로 인증해서 쓰기 위해 해야 하는 것
외부 API인증시, JWT기반으로 API 인증을 할 수 있도록 Custom API를 지원합니다. API resource 설정 하단에 Authentication의 옵션으로 Custom Auth가 있습니다. Auth workflow를 추가하여 Form modal 설정 후에 로그인하여 받아온 token으로 API Header에 값을 전달할 수 있습니다.
외부 API를 JWT로 인증해서 쓰려고 할 때, Staging에서 자꾸 풀리는 경우가 있다.
Custom Auth 설정 후에 Preview 상태에서 테스트했을 때, 로그인했음에도 불구하고 제대로 로그인 인증이 안 돼서 인증 팝업이 계속 뜨는 오류가 있었습니다. Edit 상태에서는 문제가 없었으나 preview 상태에서만 이러한 오류가 발생하였습니다.
Data 생성은 API로, 수정은 DB에 직접 연결해서 처리하는 것이 좋습니다.
retool은 데이터베이스에 직접 연결이 가능하기 때문에 데이터 다룰 때 DB와 API 두 가지를 적절하게 사용하였습니다. 저희의 경우 데이터 생성 시에 고유 UUID가 같이 담겨야 하므로 API로 생성하였고, 수정이나 삭제할 땐 DB로 처리하였습니다.
결론
노코드 툴을 처음 접했을 때 과연 이걸로 어디까지 작업이 가능할까, 간단하고 쉬운 화면만 가능하지 않을까라는 생각과 편견이 있었습니다. 여러 시행착오를 거치고 retool을 하나하나 써가면서 생각한 것 외로 다양한 기능들을 제공하고 그것들을 활용해서 화면을 만들 수 있다는 걸 깨달았습니다.
앞에서 설명한 것과 비슷한 상황이라면 노코드 툴을 사용하여 작업하는 걸 훨씬 더 효율적이고 알맞는 방식이라고 생각합니다. 앞으로 프로토타입 형식의 모델이 필요하다면 노코드 툴을 적극적으로 활용할 계획입니다.
저자 소개
김해린은 현재 Front-end 개발자로 일하고 있습니다. 개발 뿐만 아니라 다양한 분야를 접하고 즐기려고 노력하고 있습니다.