에어테이블 소개 : 임의 DB 조작 툴

(잠시 근무하는) 회사에서 구글스프레드시트를 사용하여 데이터를 생성하는 부서가 있다. 그 팀은 에어테이블을 이용하여 상태를 조작하고, 개발팀은 그 데이터들의 변화를 감지하여 모니터링 한다. 나는 그 중간 다리 역할을 맡게 되어 에어테이블을 자주 사용하게 되었다.
툴을 처음 봤을 때는 DB 같이 생긴게 View 정도의 용이겠거니 했는데 생각보다 많은 기능들을 지원하고 있다. DB 를 조회하는 것만 하는 줄 알았는데, 간단한 조작 및 양방향 통신이 가능하다. 
 
 

에어테이블

에어테이블 소개에는 "스프레드시트와 데이터베이스의 장점을 결합한 클라우드 기반 협업" 이라고 소개되어 있다. 
사용자는 각 컬럼에 속성을 부여하거나 업데이트 할 수 있다.
 

출처 : https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.alegria.group%2Fen%2Foutils-nocode-par-cas-d-usage%2Fairtable-crm&psig=AOvVaw2RwUSlAUVb55N5eOn6alQi&ust=1732515283134000&source=images&cd=vfe&opi=89978449&ved=0CBQQjRxqFwoTCJjg8MGo9IkDFQAAAAAdAAAAABAQ

 
 
또한 특정 속성을 감지한 경우 script 를 run 시켜 DB와 동기화 한다.

https://support.airtable.com/docs/run-a-script-action

 
 
DB는 이 script 를 감지하여 나머지 어플리케이션 레벨에서도 변화를 일으킬 수 있다. 그러나 트랜잭션 단위로 완전히 되돌릴 수 없는 경우가 많았다 (물론 코드 케이스를 잘 나누어 작성하면 가능할듯 하다). 또한 요청이 많아지면 가끔 에어테이블 자체 에러를 발생시킬 때도 있다고 한다. 
 

DB 가 있는데 왜 에어테이블을 사용하는가 ? 

에어테이블은 애초에 왜 존재하는가? 대해서 매우 의문이 들었다. 하지만 이것은 지극히 개발과 친숙한 사람의 관점이었으며
에어테이블의 존재 이유는 바로 비전문가도 쉽게 사용할 수 있다는 점. 

• 전통적 DB는 보통 SQL 쿼리 작성이나 별도 관리 툴을 필요로 한다.
• 에어테이블은 스프레드시트와 유사한 직관적인 UI를 제공해 코딩 지식이 없어도 데이터를 생성, 수정, 관리할 수 있다.
• 데이터 관리와 UI 설계를 한 곳에서 처리 가능.

👉 예) 마케팅 팀이 SQL을 몰라도 광고 데이터를 쉽게 관리하고 분석할 수 있음.
 
그러니 타 부서는 비교적 쉬운 에어테이블로 임의의 상태를 조작하고 있는 것이었다. 
 
 

데이터그립 DataGrip

Jetbrain 의 데이터그립도 개발자용 도구이며 에어테이블처럼 비개발자 대상의 툴은 아니라고 할 수 있다.
 

	DataGrip	Airtable
목적	데이터베이스 설계, 관리, 쿼리 작성 및 디버깅	데이터를 입력, 관리, 시각화 및 협업
기술요구사항	SQL 등 데이터베이스 언어 이해 필요	기술 지식 없이도 이해 가능
유연성	다양한 데이터베이스(MongoDB, PostgreSQL 등) 연결 가능	에어테이블 플랫폼 내에서만 데이터 관리 가능
자동화 및 통합	데이터베이스와 관련된 외부 툴과의 통합은 제한적	Zapier, Slack, Google Workspace와 통합 가능, 자동화 지원
설치 및 실행 환경	로컬에서 설치 후 사용(데스크탑 앱)	클라우드 기반, 어디서나 사용 가능

 
 
 

에어테이블의 한계 

하지만 앞서 말했듯 에어테이블은 요청이 많아질 수록 에러를 발생시킬 수 있으며 실제로 현업에서도 종종 일어난다고 한다. 따라서 프로젝트 초기 단계에서 데이터 구조를 빠르게 설정하고 테스트할 때 적합하다고 생각했다. 
 
내가 의문을 느낀 것은 실제 "결제" 시스템에서 에어테이블을 사용할 때 였다. 복잡한 user status 나 트랜잭션이 요구될 때 에어테이블이 끼어들면 너무 많은 것들을 고려해야 한다. 결제 과정에서 동시 작업이나, (고객이 수단을 변경하거나 취소하는 등) 의 변수가 많은데, 에어테이블을 중간에 껴서 DB 를 관리한다는 것이 위험하다고 느껴졌다.
 
회사의 도메인을 고려했을 때 비개발자가 매우 긴밀하게 DB 에 관여해야 하는 일이 생긴다. 또한 직접적으로 컬럼에 들어가는 값을 도출하는 수식을 세우기도 한다. 하지만 아이러니 하게도 그것을 프로그램화 하지는 않는다. 그분들이 그럴 이유도 없으며.. 그럴 수도 없다. 그렇다고 개발자들이 그 수식을 도출할 수는 없다. 개발자들 또한 그럴 수가 없다는 것이다. 모든 일들은 이 한계에서시작된다.. 😇
 
IT로 많은 것이 자동화 되는 세상을 겪으면서, 기술의 고도화 보다 중요한 것은 아무리 쉬운 기술이라도 “무결하게 전환할 수 있는 능력“이 아닐까 생각 하게 되었다.