Funes Days

CareerContact to Email

백오피스의 즐거운 대안, Appsmith [1]. 소개 및 설치

자유로운 데이터 연결, 시각화 UI에 자바스크립트로 무한 커스텀까지 가능하다고?

published at: 2024-07-28

backoffice

2편 링크: 백오피스의 즐거운 대안, Appsmith [2]. DB 연결 예제

그만한 백오피스 만들 수 있음 내가 SaaS 회사를 차렸겠지

개발자라면 누구나 겪어봤을 상황 하나. 목요일 늦은 오후, 퇴근을 30분 남겨두고 운영팀에서 대량 쿠폰 발급 기능이 필요하다고 슬랙 채널에 나를 멘션한다.

운영팀: “쿠폰 발급 히스토리 쪽 화면 재활용하면, 발급 화면도 만들 수 있지 않나요?”

나: “(얼씨구, 이젠 코드 상황도 훤히 아나보네?) 형태는 비슷해보여도 상태관리 쪽 커플링이 심해서… (대충 어려운 단어로 못한다는 이야기)“

운영팀: “저번에 디자인 시스템 반영하면서 테이블 레이아웃은 공용화 하신다 했던 것 같은데요? 암튼 신상품 출시가 내일이라 출시 시점에 맞춰서 발급되어야 한댔어요. 부탁드릴게요! (기도손 이모티콘)“

…개발자는 결국 마지막 댓글에 ‘확인’ 이모티콘을 남기고 만다. “확장에 열려 있고 수정에 닫혀 있는” 공용 컴포넌트 만들기, 관심사의 분리 챙기기, DRY… 그게 그렇게 쉽게 될 거였으면 내가 회사를 차려서 SaaS를 팔고 있었겠지!

매주 밀어붙여야 할 스쿼드 이슈가 산더미이다 보니, 백오피스 수정은 매번 기술부채고 뭐고 대충 만들어 커밋하기 일쑤고, 코드 개선은 항상 우선순위에서 밀리기 일쑤다. 그러다보니 다음 요청, 다음 요청을 해결할수록 기능 추가는 더 까다로워지고 버그는 쏟아진다. 자, 어떤가? git log graph를 따라 끝없이 커밋을 굴리는 한 명의 시지프스가 보이지 않는가?

백오피스 개발은 클라이언트 개발만큼이나 어려울 수 있다. 이 영역이 흔들리면 클라이언트 개발 리소스까지 빼앗긴다는 점에서 백오피스가 제대로 서는 건 개발팀 전체를 위해 무엇보다 중요한 일일 수 있다. 데이터베이스 연결, 사용자 인증, 권한 관리, 데이터 시각화 등 다양한 요소를 고려해야 하고, 팀마다 다른 입맛을 고려해야 할 수도 있다. 그 모든 요구사항을 직접 코딩을 해서 해결한다는 건 작은 규모의 조직에선 불가능할 수 있다. 적절한 수준의 구현 능력을 보여주는 솔루션으로의 ‘위임’이 절실해지는 순간이다.

편리한 대시보드 구축을 위한 low-code 플랫폼을 찾아보자!

이런 고민을 해결하려면 로우-코드(low-code) 플랫폼을 도입해 보는 것도 좋은 선택이 될 수 있다. 로우-코드 플랫폼은 최소한의 코딩으로 빠르게 대시보드를 만들 수 있게 해주는 도구다. 여러 로우코드 플랫폼중 가장 유명한 세 가지를 자세히 비교해보자.

Retool

링크: https://retool.com/

장점:

  1. 다양한 데이터 소스 연동: Retool은 SQL, MongoDB, REST API, GraphQL 등 다양한 데이터 소스와의 연동이 매우 용이하다. 이러한 다중 데이터 소스 지원은 복잡한 데이터 환경에서 유연하게 대처할 수 있다.
  2. 풍부한 UI 컴포넌트: 차트, 테이블, 폼 등 다양한 UI 컴포넌트를 제공하여 복잡한 대시보드를 손쉽게 구성할 수 있다.
  3. 커스텀 JavaScript: JavaScript를 활용해 원하는 기능을 자유롭게 추가할 수 있어, 특정 비즈니스 로직을 유연하게 구현할 수 있다.
  4. 사용자 권한 관리: 사용자별로 세밀한 권한 설정이 가능해 보안성이 높은 환경을 구축할 수 있다.

단점:

  1. 비용: 셀프 호스팅이 가능하지만 여전히 클라우드 계정에 묶인다. 그냥 ‘배포’만 원하는 곳에 해준다는 거다. 사용자당 월 $10에서 $50까지 가격이 책정되어 있다. 편집자 시트는 별도 구매다.
  2. 학습 곡선: 다양한 기능을 제공하는 만큼, 처음 사용하는 개발자에게는 학습 곡선이 가파를 수 있다.
Bubble

링크: https://bubble.io/

장점:

  1. 드래그 앤 드롭 개발: 프로그래밍 지식이 거의 없어도 드래그 앤 드롭 방식으로 웹 애플리케이션을 쉽게 만들 수 있다.
  2. 올인원 솔루션: 데이터베이스 설계부터 프론트엔드 개발까지 모두 가능해 개발 프로세스를 간소화할 수 있다.
  3. 템플릿과 플러그인: 다양한 템플릿과 플러그인을 제공하여 빠르게 앱을 개발할 수 있다.

단점:

  1. 학습 시간: 직관적인 인터페이스에도 불구하고, 고급 기능을 활용하려면 Bubble의 특정 문법을 익히는 데 시간이 걸릴 수 있다.
  2. 커스텀 코드 제한: 커스터마이징 코드를 삽입하기 어렵기 때문에, 복잡한 로직 구현에는 한계가 있다.
  3. 비용: ‘단 한명’만 편집 가능한 무료 플랜이 있으며, 유료 플랜은 월 $29부터 시작한다. 월 $349 플랜으로 올라가도 편집자는 5명으로 한정된다.
Appsmith

링크: https://www.appsmith.com/

장점:

  1. 오픈소스: 완전 무료로 시작할 수 있으며, 셀프 호스팅이 가능해 데이터 보안이 중요한 환경에서도 사용할 수 있다.
  2. JavaScript 활용: JavaScript를 통해 커스텀 기능을 추가할 수 있어 유연성이 높다.
  3. 다양한 데이터 소스 지원: SQL, REST API, GraphQL 등 다양한 데이터 소스를 쉽게 연동할 수 있다.
  4. 사용자 친화적인 UI: 드래그 앤 드롭 인터페이스로 손쉽게 대시보드를 구성할 수 있다.

단점:

  1. 커뮤니티 규모: 다른 플랫폼에 비해 커뮤니티가 작아 정보를 찾기 어려울 수 있다.
  2. UI 컴포넌트 다양성: Retool에 비해 UI 컴포넌트의 다양성이 다소 부족할 수 있다.

비용: 셀프 호스팅이 가능하고 Retool과 달리 완전히 단독으로 사용할 수 있다. 클라우드 호스팅을 쓴다면 유료 플랜이 작동한다. (그래서 설정 창에 광고가 좀 있다)

세 플랫폼 도입을 고민한다면 조직 규모와 예산에 따라 선택지가 달라질 수 있다. Retool은 기업용 솔루션으로 안정적이지만 비싼 편이고, Bubble은 비개발자도 쉽게 사용할 수 있지만 복잡한 기능 구현에는 한계가 있다. (시트 제한을 생각하면 Bubble이 제일 비싸 보인다)

오늘 소개하려는 Appsmith가 정확히 중간 지점에 위치하는 툴이라고 생각한다, 완전한 셀프 호스팅이 가능하다는 점에서 가성비가 좋고 커스터마이징도 나름 강력하다.

확장성과 무료 두 마리 토끼를 잡은 Appsmith

Appsmith를 추천하려는 이유를 다시 정리해보자.

  1. 직관적인 UI: 드래그 앤 드롭으로 기본적인 레이아웃을 빠르게 구성할 수 있으며, 컴포넌트 간의 데이터 바인딩도 쉽게 할 수 있다.
  2. 커스텀 기능 추가: JavaScript를 이용해 필요한 기능을 직접 구현할 수 있어 플랫폼의 한계에 묶이지 않는다.
  3. 무료 셀프 호스팅: 비용 절감뿐만 아니라 데이터 보안 측면에서도 큰 이점이다. 민감한 데이터를 자체 서버에서 관리할 수 있다.
  4. 다양한 데이터 소스와 연동 가능: SQL 데이터베이스, REST API, GraphQL 등 다양한 데이터 소스를 쉽게 연결할 수 있다.
  5. 확장성: 여러 워크스페이스를 만들 수 있어 팀 단위로 독립된 작업 공간을 제공할 수 있다. SMTP 연결을 통해 사내 유저만 초대할 수 있어 보안성도 높다. 권한 설정도 세밀하게 가능해서 각 유저별로 접근 권한을 다르게 줄 수 있다. 마지막으로, 모든 워크스페이스는 git 리포지토리와 개별 연동하여 형상관리를 할 수 있다. 혹시라도 배포 위치를 옮겨야 해서 인스턴스를 내리더라도 모든 워크스페이스는 git에 안전하게 저장해두고 재사용이 가능하다는 뜻이다.

github 리포지토리에 수많은 이슈가 쌓여 있지만 컨트리뷰터들이 지속적으로 문제를 개선하고 있다고 본다. 기본 기능이 괜찮아서 고급 기능에서 버그나 한계가 발견되더라도 커스텀으로 커버할 수 있는 수준이다.

Appsmith 설치 hands-on

첫머리에서 예로 들었던 대량 쿠폰 발급 화면 요청을 실제로 받아봤을 때, 필자는 appsmith를 사용해 쿠폰 발급 대상자 화면 만드는 데 30분, 발급 기능을 연결하는 데 30분 정도 소모해 운영을 성공시킨 경험이 있다. 운영 데모를 소개하기 앞서 대략적인 설치 흐름을 정리하도록 하겠다.

셀프 호스팅 설치

설치는 각 조직의 상황 따라 조금씩 다르겠지만 여기서는 표준적인 설치 방법인 docker와 ECS Fargate를 이용한 설치 방법을 소개하겠다.

알맞은 태스크 정의 만들기

우선 공식 문서의 배포 관련 페이지를 링크해 둔다. AWS ECS on Fargate | Appsmith

공식 문서에서는 모두 언급하지만, 여기서는 클러스터 생성 과정, 서비스 생성 과정은 생략하고 태스크 정의 부분만 설명하겠다.

태스크 정의에서 가장 중요한 부분은 컨테이너를 설정하고 볼륨을 연결하는 것이다. 새 태스크 정의 개정 생성 > 인프라 요구 사항 > 시작 유형 > Fargate를 선택한 뒤, 컨테이너 이미지를 appsmith가 제공해준 이미지를 그대로 사용한다.

이미지 이름: index.docker.io/appsmith/appsmith-ee

task_definition

그 후 해당 이미지에 연결할 환경변수를 입력해야 한다. 다른 것들은 대체로 자동생성이 되기에 신경 안 써도 되고 특별히 중요한 건 이메일 전송 부분인 듯하다.

appsmith는 내부에 mongodb와 redis, keycloak을 갖고 있다. 아무 설정도 하지 않으면 로컬 볼륨에 자신이 직접 생성해서 돌리지만, 외부 자원으로 연결하고 싶다면 따로 환경변수로 설정해야 한다. 화면을 띄우고 접속한 뒤에도 연결할 수 있는 것처럼 되어 있지만 비추한다.

일단 여기서는 이메일 관련 환경변수만 소개하겠다.

// 이메일 전송을 통해 타 멤버 초대할 것인지 체크
APPSMITH_MAIL_ENABLED=true 
// 이메일 발신자
APPSMITH_MAIL_FROM=<이메일 주소>
// SMTP 인증을 받을 이메일 주소
APPSMITH_MAIL_USERNAME=<이메일 주소>
// 이메일 발신자의 비밀번호*
// 예전에는 '앱 비밀번호'라 해서 MFA 설정이 되어 있는 계정을 위해
// 곧장 인증을 가능케 해주는 비밀번호를 제공했으나 이제 사라짐
// 필자 이메일은 MFA가 되어 있었음에도 1차 비밀번호만으로 통과함
// 구글이 SMTP에 대해서만 MFA를 자동 생략해주는 것일까?
APPSMITH_MAIL_PASSWORD=<비밀번호>
// SMTP 서버 주소
APPSMITH_MAIL_HOST=<예: smtp.gmail.com>
// 메일 포트: gmail은 TLS 연결이 의무이므로 무조건 587
APPSMITH_MAIL_PORT=587
// SMTP 인증 절차를 거칠 것인지? 
APPSMITH_MAIL_SMTP_AUTH=true
// TLS 연결을 허용할 것인지?: gmail은 무조건 해야 함
APPSMITH_MAIL_SMTP_TLS_ENABLED=true
// 답장을 받을 이메일 주소
APPSMITH_REPLY_TO=<이메일 주소>

EFS 볼륨 생성 및 연결 ECS Fargate는 무상태 컨테이너이다 보니 컨테이너가 종료되어도 상태를 유지할 만한 파일시스템 볼륨을 연결해야 한다.

먼저 문서를 따라 EFS 볼륨을 하나 생성하자. 관건은 내가 배포할 영역과 일치하는 VPC, 서브넷에 설치되어야 한다는 것이며 인바운드로 2049 포트가 열려 있는 보안 그룹을 연결해야 한다는 것이다.

Appsmith 문서: Create EFS Volume

appsmith_efs

일단 EFS 볼륨을 만들었다면, 태스크 정의 생성 화면으로 돌아와 보자. ‘파일 시스템 ID’가 방금 생성한 EFS 볼륨이므로 드롭다운을 열어 알맞은 것을 선택하자.

‘컨테이너 탑재 지점’에 주목하자. ‘컨테이너’는 아까 제작한 appsmith 컨테이너이며, ‘소스 볼륨’은 위의 ‘볼륨 이름’에 작성한 이름과 맞는 것으로 연결하면 된다. ‘컨테이너 경로’를 /appsmith-stacks 로 작성하는 게 가장 중요하다.

Appsmith Docker 설치 문서: Docker | Appsmith

문서를 살펴보면 docker-compose.yml 예시에 내부 볼륨 연결 경로가 /appsmtith-stacks 로 되어 있는 걸 알 수 있다. 여기에 맞게 경로를 정확히 맞춰 작성해야 한다.

services:
   appsmith:
     image: index.docker.io/appsmith/appsmith-ee
     container_name: appsmith
     ports:
         - "80:80"
         - "443:443"
     volumes:
         - ./stacks:/appsmith-stacks
     restart: unless-stopped

실행 후 초기 화면

서비스 실행 과정은 보통의 ECS 서비스 실행 과정과 동일하므로 생략한다. 다만 health check 주소가 궁금할 수 있다. 주소는 <host>/api/v1/health 이다.

서비스 실행을 마친 뒤 무사히 구동되기 시작했다면, 아래와 같은 화면이 뜰 것이다.

appsmith_init

(회사명 외에 특별히 중요한 정보가 없어서 스크린샷으로 남긴다.)

Appsmith의 정말 좋은 점이라면, workspace - application - 내부 page 단위로 업무 범위를 촘촘하게 쪼갤 수 있다는 점이다.

데모는 에피소드 2에서…

포스트를 쓰다 보니 너무 길어져서 실제 운영을 보여주는 데모 과정은 다음 에피소드에서 올리기로 하겠다. 덧붙여 며칠 전에 블로그 디자인을 완전 리뉴얼했는데, 혹시나 접속이 잘 안되는 부분이 있다면 기존 페이지를 이곳으로 옮겨두었으니 확인 바란다.

예전 블로그: legacy funes-days