Airtable은 AI 네이티브 앱 플랫폼으로, 자연어로 설명하면 팀의 실제 업무 데이터 위에서 동작하는 테이블과 인터페이스, 자동화, AI 에이전트를 만들어 주며 관리자 거버넌스와 기업용 규정 준수를 함께 제공합니다.
이 도구를 사용해 보셨나요? 평점을 남겨 주세요
Airtable은 일반 업무 담당자가 직접 다룰 수 있는 관계형 데이터베이스를 기반으로 하되, 그 위에 인공지능을 제품의 중심축으로 올려놓은 협업 플랫폼입니다. 공식 사이트 첫 화면은 "인공지능이 개인의 일하는 방식을 바꾸었다면, Airtable은 팀이 협업하는 방식을 바꾼다"는 주장을 전면에 내세우며, 스스로를 "미래를 만들어 가는 회사들을 위한 기록 시스템"이라고 소개합니다. 이 문장은 단순한 홍보 문구가 아니라 제품 구조를 그대로 설명하는 표현입니다. 데이터가 흩어진 채로 남아 있으면 아무리 좋은 모델을 붙여도 결과가 신뢰받지 못하기 때문에, 먼저 팀의 사실 관계를 한곳에 모아 두는 기록 계층을 확보하고 그 위에서 자동화와 에이전트를 돌리겠다는 설계입니다.
2025년 6월 24일 최고경영자가 공개한 서한은 이번 개편의 성격을 분명히 규정했습니다. 서한은 이번 인공지능 중심 개편을 회사의 "다시 창업하는 순간"이라고 표현했으며, 기존 플랫폼 위에 기능 몇 개를 얹은 것이 아니라고 못박았습니다. 즉 인공지능은 부가 계층이 아니라 본선입니다. 이 차이는 실제 사용 경험에서도 드러납니다. 기존 도구들이 흔히 취하는 방식은 완성된 표 옆에 보조 버튼을 하나 붙이는 형태지만, Airtable은 애플리케이션을 만드는 시작점 자체를 대화로 바꾸어 놓았습니다.
그럼에도 바닥에 깔린 개념은 여전히 익숙합니다. 데이터는 베이스(base)라는 단위 안에 담기고, 각 표의 열은 텍스트, 숫자, 날짜, 선택지, 첨부 파일, 담당자 같은 필드 유형으로 구분됩니다. 표와 표는 연결 레코드로 이어지며, 이 연결 덕분에 한 건의 고객 정보가 계약, 청구, 지원 이력과 하나의 사실로 묶입니다. 스프레드시트에 익숙한 사람이 데이터베이스 이론을 새로 배우지 않고도 구조화된 데이터를 다룰 수 있다는 점이 오랜 기간 이 제품의 핵심 자산이었고, 지금의 인공지능 기능도 결국 이 구조화된 바닥 위에서 동작합니다.
정리하면 Airtable은 세 겹으로 이해하는 편이 정확합니다. 가장 아래에는 업무 담당자가 직접 설계하고 수정하는 관계형 데이터 계층이 있습니다. 그 위에는 자동화와 인터페이스가 놓여 데이터를 흐르게 하고 사람에게 보여 줍니다. 가장 위에는 대화형 구축기와 에이전트가 자리 잡아, 만드는 일과 처리하는 일을 동시에 떠맡습니다. 도입을 검토할 때는 이 세 겹 중 어디에 무게중심을 두는지에 따라 체감 가치가 크게 달라집니다.
Omni는 필요한 것을 자연어로 설명하면 데이터 표, 인터페이스, 자동화까지 포함한 완성형 애플리케이션을 생성해 주는 대화형 구축기입니다. 빈 화면에서 필드를 하나씩 만들며 시작하는 대신, "어떤 업무를 어떻게 처리하고 싶은지"를 문장으로 적는 것에서 출발합니다. 중요한 점은 결과물이 닫혀 있지 않다는 사실입니다. 생성된 구조는 기존의 시각적 편집 도구로 계속 손볼 수 있어, 처음 만든 형태에 만족하지 못하더라도 처음부터 다시 만들 필요가 없습니다. 생성은 초안을 빠르게 얻는 수단이고, 최종 형태는 사람이 결정합니다.
에이전트는 데이터를 분석하고, 내용을 생성하며, 조사를 대신 수행합니다. Field Agents는 각 레코드 안에서 작동해 행 단위로 결과를 채워 넣습니다. 이 밖에도 여러 형태가 제공됩니다. 문서 분석 에이전트는 계약서나 청구서를 훑어 위험 요소를 찾아냅니다. 웹 조사 에이전트는 잠재 고객 정보를 보완하고, 경쟁사를 분석하며, 뉴스를 요약합니다. 번역과 이미지 생성도 지원됩니다. 이러한 에이전트는 데이터가 새로 추가되거나 갱신될 때 자동으로 실행되도록 설정할 수 있어, 사람이 매번 버튼을 누르지 않아도 처리 흐름이 이어집니다.
자동화는 트리거와 동작을 조합하는 노코드 방식으로 구성됩니다. 조건 분기와 반복 같은 기본 흐름은 화면에서 클릭으로 만들 수 있고, 표준 블록으로 표현하기 어려운 논리는 자바스크립트로 확장할 수 있습니다. 협업 도구와 업무용 오피스 제품군 같은 대표적인 외부 서비스와는 기본 연결이 제공되므로, 상태가 바뀌었을 때 담당 채널에 알리거나 문서를 만들어 두는 일을 별도 개발 없이 처리할 수 있습니다.
인터페이스 디자이너는 데이터를 그대로 노출하는 대신 역할에 맞춘 화면을 만들도록 돕습니다. 코드를 쓰지 않고 목록, 상세, 대시보드 형태의 화면을 구성할 수 있으며, 누가 무엇을 볼 수 있는지도 여기서 정합니다. 다만 공식 안내에는 권한과 관련된 일부 기능이 특정 유료 등급에서만 제공된다는 단서가 붙어 있으므로, 외부 협력사나 대규모 조직에 화면을 배포할 계획이라면 등급 조건을 먼저 확인해야 합니다.
관리자는 워크스페이스 단위에서 인공지능 사용 여부를 켜고 끌 수 있고, 어떤 데이터에 접근할 수 있는지도 통제합니다. 모든 활동은 거버넌스 대상이며 감사가 가능합니다. 최상위 기업 등급에서는 관리 패널, 감사 로그, 기업용 키 관리, 데이터 유출 방지 기능이 추가로 제공됩니다. 규제 산업에서 도입을 검토한다면 이 계층이 실질적인 판단 기준이 됩니다.
HyperDB는 1억 건이 넘는 대규모 데이터셋을 다루기 위한 통로입니다. 일반 베이스의 레코드 한계와는 다른 층위의 기능으로, 대량의 원천 데이터를 참조해야 하는 상황을 겨냥합니다. 다만 이는 기업 수준의 역량이므로, 낮은 등급에서 레코드 한도를 우회하는 수단으로 이해해서는 안 됩니다.
웹 API는 표준적인 REST 의미론을 따르며, 데이터는 JSON으로 표현되고 결과는 일반적인 HTTP 상태 코드로 전달됩니다. 즉 별도의 특수한 통신 규약을 배울 필요 없이 익숙한 방식으로 연동할 수 있습니다. 다만 등급별 호출 한도가 다르므로 설계 단계에서 호출량을 반드시 고려해야 합니다.
기능 요청, 버그, 릴리스 일정, 담당자를 하나의 베이스에 모아 두고, 각 항목을 연결 레코드로 이어 두면 어떤 요청이 어느 릴리스에 담겼는지 추적할 수 있습니다. 인터페이스 디자이너로 경영진용 요약 화면과 실무자용 작업 화면을 따로 만들면, 같은 데이터를 보면서도 각자 필요한 정보만 보게 됩니다.
기획, 초안, 검수, 배포로 이어지는 단계를 상태 필드로 관리하고, 상태가 바뀔 때마다 담당 채널에 알림이 가도록 자동화를 걸어 둡니다. 여기에 생성 에이전트를 붙이면 초안 요약, 제목 후보, 다국어 번역 같은 반복 작업을 레코드 안에서 처리할 수 있습니다. 다만 생성 결과는 발행 전에 사람이 반드시 확인해야 합니다.
거래 단계와 담당자, 예상 금액을 표로 관리하면서, 웹 조사 에이전트로 신규 잠재 고객의 공개 정보를 보완하고 경쟁 상황을 정리합니다. 새 레코드가 들어올 때 자동으로 조사가 실행되게 해 두면, 영업 담당자가 첫 통화를 하기 전에 배경 정보가 이미 채워져 있는 상태를 만들 수 있습니다.
문서 분석 에이전트로 계약서와 청구서를 훑어 위험 요소를 뽑아내고, 그 결과를 레코드의 필드로 남깁니다. 원본 파일은 첨부로 보관하고 검토 의견은 구조화된 필드에 담기므로, 나중에 조건별로 검색하거나 집계하기가 쉬워집니다. 판단 자체는 담당자가 내리고, 에이전트는 읽는 시간을 줄이는 역할을 맡습니다.
지원자, 포지션, 면접 일정, 평가 기록을 서로 연결해 두면 한 사람의 전체 이력을 한눈에 볼 수 있습니다. 단계 전환 시 알림을 보내고 평가 요약을 자동 생성하도록 구성하면 관리 부담이 줄어듭니다. 다만 인사 데이터는 민감하므로 인터페이스 단계에서 열람 범위를 반드시 좁혀야 합니다.
자산 관리, 공급업체 목록, 예산 집행처럼 그동안 개별 표로 흩어져 있던 자료를 하나의 베이스로 합치면, 부서 간 중복 입력이 사라지고 숫자의 출처가 명확해집니다. 규모가 커져 일반 베이스의 한도를 넘어서는 상황이 예상된다면 상위 등급이나 대규모 데이터셋 통로를 함께 검토해야 합니다.
먼저 자동화하고 싶은 업무를 한 문장으로 적습니다. "무엇을 기록하고, 누가 갱신하며, 어떤 결정을 내리는가"가 그 문장에 담겨야 합니다. 이 정의가 흐릿하면 이후 단계에서 필드가 계속 늘어나고 구조가 무너집니다.
정의한 문장을 그대로 Omni에 설명해 표, 화면, 자동화가 포함된 초안을 생성합니다. 이 단계의 목표는 완성이 아니라 논의할 대상을 손에 쥐는 것입니다. 참고로 애플리케이션을 구축하는 행위 자체는 크레딧을 소비하지 않으므로, 마음 편히 여러 번 시도해도 됩니다.
생성된 표를 열어 필드 유형이 실제 데이터의 성격과 맞는지 확인합니다. 날짜를 텍스트로 받고 있지는 않은지, 선택지로 관리해야 할 값이 자유 입력으로 남아 있지는 않은지 점검합니다. 반복되는 값은 별도 표로 분리하고 연결 레코드로 이어야 나중에 집계가 가능합니다.
표 사이의 연결을 정리한 다음, 참조와 집계 필드로 필요한 숫자를 끌어옵니다. 이 부분이 스프레드시트와 가장 크게 갈리는 지점이며, 처음 쓰는 사람이 가장 많이 헤매는 구간이기도 합니다. 한 번 제대로 잡아 두면 이후 화면과 자동화가 훨씬 단순해집니다.
역할별로 화면을 나누고, 각 화면이 어떤 데이터를 보여 줄지 정합니다. 사람마다 필요한 정보가 다르므로 원본 표를 그대로 공유하기보다 화면을 통해 접근하도록 하는 편이 안전합니다. 권한 관련 세부 기능은 등급에 따라 다르니 사전에 확인합니다.
상태 변경, 신규 레코드 생성처럼 명확한 시점을 골라 자동화를 겁니다. 에이전트를 데이터 추가나 갱신 시점에 자동 실행되도록 설정할 때는 처음부터 전체에 적용하지 말고 일부 레코드로 먼저 시험합니다.
워크스페이스 수준에서 인공지능 사용 여부와 접근 가능한 데이터를 정합니다. 조직 정책상 특정 데이터가 처리 대상에서 빠져야 한다면 이 단계에서 명시적으로 제외합니다.
일정 기간 운영하며 크레딧 소비와 좌석 수 변화를 지켜봅니다. 예상보다 소비가 빠르다면 어떤 자동화가 원인인지 찾아 실행 조건을 좁힌 뒤에 적용 범위를 넓히는 순서가 안전합니다.
첫째, 구조를 먼저 잡고 자동화를 나중에 붙입니다. 필드 유형과 표 사이의 관계가 어긋난 상태에서 자동화를 얹으면, 잘못된 데이터가 더 빠르게 퍼질 뿐입니다. 초기 며칠은 구조 정리에만 쓰는 편이 결과적으로 빠릅니다.
둘째, 편집 권한을 습관적으로 부여하지 않습니다. 좌석 기준 과금 구조에서는 편집 권한이 필요한 협업자마다 비용이 발생합니다. 실제로 편집 권한을 가볍게 나눠 주다가 청구액이 예상을 넘었다는 이야기가 사용자 커뮤니티에서 반복적으로 나옵니다. 대부분의 구성원은 인터페이스만으로 충분한 경우가 많습니다.
셋째, 레코드 한도를 처음부터 계산에 넣습니다. 한도는 워크스페이스가 아니라 베이스 단위로 적용되며, 무료 등급은 1000건, Team 등급은 50000건입니다. 로그성 데이터를 그대로 쌓으면 생각보다 빨리 한계에 닿으므로, 보관 주기를 정하거나 요약 표를 따로 두는 설계가 필요합니다.
넷째, 에이전트 실행 조건을 좁게 시작합니다. 크레딧 소비량은 입력 데이터, 선택한 모델, 출력 데이터에 따라 달라지므로 고정값으로 예측하기 어렵습니다. 특정 조건을 만족하는 레코드에만 먼저 적용해 실제 소비 곡선을 확인한 뒤 확대하는 방식이 안전합니다.
다섯째, 크레딧이 공유 자원이라는 점을 팀 전체가 인지해야 합니다. 크레딧은 워크스페이스 또는 조직 수준에서 함께 쓰는 몫이며 개인에게 묶이지 않습니다. 편리한 구조이지만, 한 팀이 대량 자동화를 돌리면 다른 팀이 쓸 몫이 줄어들 수 있습니다. 대량 처리를 계획한다면 미리 공유하는 절차를 두는 편이 좋습니다.
여섯째, 생성 결과에 대한 검토 단계를 구조 안에 넣습니다. 대화형 구축기가 만든 애플리케이션도, 에이전트가 채운 필드도 사람의 확인이 필요합니다. "검토 완료" 같은 상태 필드를 두고 그 값이 참일 때만 다음 단계로 넘어가도록 자동화를 설계하면, 검토가 형식이 아니라 실제 관문이 됩니다.
일곱째, 외부 연동은 호출 한도를 기준으로 설계합니다. 무료 등급은 워크스페이스당 월 1000회, Team 등급은 월 100000회이며 Business 등급부터는 횟수 제한이 없습니다. 짧은 주기로 반복 조회하는 방식보다는 변경이 발생했을 때만 호출하는 방식이 한도를 절약합니다.
여덟째, 되돌리기 이력의 길이를 알고 씁니다. 무료 등급의 수정 이력과 스냅숏 보관 기간은 2주이고, Team과 Business 등급은 1년입니다. 분기 단위로 과거 상태를 되짚어야 하는 업무라면 무료 등급으로 운영하기 어렵습니다.
첫째, 스프레드시트로 운영하다 한계를 느낀 중소 규모 팀입니다. 값의 중복과 버전 충돌이 반복되고 있다면 관계형 구조로 옮길 시점입니다.
둘째, 정보 시스템 담당 인력 없이 자체 업무 도구가 필요한 부서입니다. 개발 인력을 배정받기 어려운 상황에서 담당자가 직접 만들고 고칠 수 있다는 점이 실질적인 가치가 됩니다.
셋째, 반복적인 조사와 요약 업무가 많은 영업 및 마케팅 조직입니다. 잠재 고객 정보 보완과 경쟁 정보 정리 같은 작업을 레코드 단위로 자동화할 수 있습니다.
넷째, 문서를 대량으로 읽어야 하는 법무, 조달, 재무 담당자입니다. 계약서와 청구서에서 위험 요소를 뽑아내는 작업의 초벌을 맡길 수 있습니다.
다섯째, 여러 부서의 데이터를 한곳으로 모으려는 운영 담당자입니다. 부서별로 흩어진 표를 통합하고 화면 단위로 배포하는 데 적합합니다.
여섯째, 감사와 통제 요건이 있는 규제 산업의 팀입니다. 관리자 통제, 감사 로그, 데이터 유출 방지 같은 요건을 상위 등급에서 다룰 수 있습니다.
일곱째, 시제품을 빠르게 만들어 보여 줘야 하는 기획자와 컨설턴트입니다. 대화형 구축기로 논의용 초안을 짧은 시간에 만들 수 있습니다.
여덟째, 방대한 원천 데이터를 참조해야 하는 조직입니다. 1억 건 이상 규모를 다루어야 한다면 대규모 데이터셋 통로가 검토 대상이 됩니다.
주된 사용 환경은 웹 브라우저입니다. 별도 설치 없이 접속만 하면 되고, 기능 갱신이 서비스 측에서 이루어지므로 버전 관리 부담도 없습니다. 팀 전체가 같은 화면을 보며 협업한다는 점에서도 브라우저 중심 운영이 기본값입니다.
공식적으로 데스크톱 애플리케이션과 모바일 애플리케이션도 제공됩니다. 다만 각 스토어의 평점, 설치 용량, 요구되는 운영체제 버전 같은 세부 수치는 독립적으로 확인하지 못했습니다 (정보 확인 필요). 사내 배포 정책상 최소 운영체제 버전을 명시해야 하는 조직이라면 공식 배포 페이지에서 직접 확인하시기 바랍니다.
프로그래밍 방식으로 접근할 때는 웹 API를 사용합니다. 이 인터페이스는 표준적인 REST 의미론을 따르고, 데이터를 JSON으로 주고받으며, 처리 결과를 표준 HTTP 상태 코드로 알려 줍니다. 등급별 호출 한도는 앞서 정리한 대로이며, 연동 규모가 큰 경우 이 한도가 실질적인 설계 제약이 됩니다.
무료 등급은 베이스당 1000건의 레코드, 1GB의 첨부 파일 용량, 2주의 수정 이력과 스냅숏 보관, 워크스페이스당 월 1000회의 API 호출을 제공합니다. 개인 사용이나 개념 검증에는 충분하지만 팀 운영에는 금방 좁아집니다.
Team 등급은 연간 결제 기준 사용자당 월 20달러입니다. 베이스당 50000건의 레코드, 20GB의 첨부 파일 용량, 1년의 수정 이력, 월 100000회의 API 호출을 제공합니다. 대부분의 실무 팀이 처음 검토하는 지점입니다.
Business 등급은 연간 결제 기준 사용자당 월 45달러입니다. 베이스당 125000건의 레코드, 100GB의 첨부 파일 용량, 1년의 수정 이력을 제공하며 API 호출 횟수에는 제한이 없습니다. 연동이 많거나 통제 요건이 강한 조직에 해당합니다.
Enterprise Scale 등급은 개별 견적으로 제공됩니다. 관리 패널, 감사 로그, 기업용 키 관리, 데이터 유출 방지 같은 통제 기능이 이 등급에 속합니다.
인공지능 크레딧은 등급별로 유료 사용자 수에 따라 월 단위 몫이 배정됩니다. 이 몫은 무료와 Team 등급에서는 워크스페이스 수준에서, Business와 Enterprise 등급에서는 조직 수준에서 함께 쓰이며 개인에게 고정되지 않습니다. 소비량은 동작마다 달라지는데, 입력 데이터의 양, 선택한 모델, 출력 데이터의 양이 변수로 작용합니다. 추가 구매는 셀프서비스 기준으로 월 10000 크레딧에 20달러, 월 100000 크레딧에 200달러, 월 400000 크레딧에 800달러입니다. 한 가지 중요한 점은, 대화형 구축기로 애플리케이션을 만드는 행위 자체는 크레딧을 소비하지 않는다는 사실입니다. 즉 비용은 만드는 과정이 아니라 운영 중 실행되는 처리에서 발생합니다.
개인정보 보호와 규정 준수 측면도 예산 검토와 함께 살펴볼 부분입니다. 공식 설명에 따르면 모델 제공 측은 고객 데이터를 보관하지 않으며, 고객 데이터는 모델 학습에 사용되지 않습니다. 기업 고객은 어떤 모델을 사용할지 직접 결정할 수 있고, 선택 가능한 제공업체에는 주요 모델 제공업체들이 포함됩니다. 인증으로는 SOC 2 Type 2, ISO/IEC 27001:2022, ISO/IEC 27701:2019, HIPAA, TX-RAMP Level 2를 보유하고 있습니다. 유럽 연합 내 데이터 저장 선택지가 제공되며, 기업 고객은 자체 키로 저장 데이터를 암호화할 수 있습니다. 유럽 경제 지역과 영국, 스위스 거주자는 접근, 이동, 정정, 삭제, 처리 제한, 동의 철회, 반대의 일곱 가지 권리를 가지며, 미국의 적용 대상 주 거주자는 접근, 삭제, 정정, 이의 제기 권리를 가집니다. 개인정보 처리방침은 2026년 7월 15일에 최근 갱신되었습니다.
Notion은 문서와 지식 베이스 영역에서 더 강합니다. 자유로운 문서 작성과 정보 정리가 중심이고 데이터베이스는 그것을 보조하는 형태이므로, 팀의 주된 산출물이 문서라면 더 잘 맞습니다.
Smartsheet는 전통적인 프로젝트 포트폴리오 관리에 가깝습니다. 일정과 자원 배분을 정형화된 방식으로 관리해야 하는 조직이라면 익숙한 개념을 그대로 쓸 수 있습니다.
Monday.com은 업무 관리가 우선이고 데이터베이스 성격은 그다음입니다. 팀의 진행 상황을 시각적으로 관리하는 데 초점이 맞춰져 있어, 복잡한 데이터 모델보다 협업 흐름이 중요할 때 선택지가 됩니다.
구글 스프레드시트에 스크립트를 결합하는 방식은 비용이 가장 낮습니다. 다만 관계형 구조와 권한 배포 기능이 부족하므로, 데이터가 늘고 참여자가 많아질수록 유지 비용이 다른 형태로 되돌아옵니다.
Baserow와 NocoDB는 오픈소스이며 자체 서버에 설치해 운영할 수 있습니다. 데이터를 특정 지역이나 자사 인프라 안에 두어야 하거나 비용을 최우선으로 삼는 경우에 검토할 만합니다.
Retool은 이미 보유한 데이터베이스 위에 내부 도구를 만드는 데 초점을 둡니다. 코드 작성이 전제되므로 개발 인력이 있는 조직에 적합하며, 기록 시스템 자체를 새로 만들려는 목적과는 방향이 다릅니다.
첫째, 좌석 기준 과금 구조입니다. 편집 권한이 필요한 협업자 한 사람마다 비용이 발생하며, 사용자 커뮤니티에서는 편집 권한을 가볍게 부여했다가 청구액이 예상을 넘었다는 이야기가 반복적으로 나옵니다. 비용이 사용량이 아니라 인원수에 따라 늘어난다는 점은 조직이 커질수록 부담으로 작용합니다.
둘째, 레코드 한도는 베이스 단위로 적용됩니다. 무료 등급의 1000건, Team 등급의 50000건은 실제 운영에서 생각보다 빨리 채워집니다. 대규모 데이터셋을 위한 통로는 기업 수준의 역량이며 낮은 등급의 한도를 메우는 보완재가 아닙니다.
셋째, 크레딧 소비가 가변적이어서 과소평가하기 쉽습니다. 소비량은 입력 데이터와 선택한 모델, 출력 데이터에 따라 달라집니다. 게다가 크레딧이 공유 자원이므로 한 팀의 자동화가 공동의 몫을 소진할 수 있습니다.
넷째, 학습 곡선이 실재합니다. 연결, 참조, 집계로 이어지는 관계형 사고방식이 스프레드시트 사용자에게는 주된 진입 장벽입니다. 도입 초기에 이 개념을 함께 익히는 시간을 계획에 넣지 않으면, 표를 흉내 낸 평평한 구조만 남게 됩니다.
다섯째, 일부 기능이 등급별로 잠겨 있습니다. 특히 권한과 관련된 항목이 그러하므로, 외부 이해관계자에게 화면을 배포하는 시나리오라면 필요한 등급을 사전에 확인해야 합니다.
여섯째, 소유권 변경이 진행 중입니다. 2026년 8월 4일 Bending Spoons가 Airtable 인수에 관한 최종 계약을 체결했다고 발표했으며, 기업 가치는 12억 8500만 달러입니다. 다만 거래는 아직 완료되지 않았습니다. 규제 승인 등 통상적인 조건이 충족되어야 하며 연내 완료가 예상되고, 거래 종결 전까지 두 회사는 독립적으로 운영됩니다. 현재 제품, 브랜드, 도메인에는 변화가 없지만, 여러 해에 걸친 조달 결정을 내릴 때는 거래 완료 이후의 가격 정책과 제품 방향이 새 소유자에 의해 결정될 수 있다는 점을 고려해야 합니다.
일곱째, 대화형 구축기가 만든 애플리케이션은 여전히 사람의 검토가 필요합니다. 구조가 그럴듯해 보여도 필드 유형이나 관계 설정이 실제 업무와 어긋날 수 있으므로, 생성 결과를 그대로 운영에 투입하는 것은 권장되지 않습니다.
가장 큰 차이는 표 사이의 관계입니다. 스프레드시트는 각 시트가 독립적이어서 같은 정보를 여러 곳에 반복해 적게 되지만, Airtable은 연결 레코드로 표를 이어 하나의 사실을 한 번만 기록합니다. 또한 각 열이 텍스트, 날짜, 담당자, 첨부 파일처럼 명확한 유형을 가지므로 입력 오류가 줄어듭니다. 여기에 역할별 화면과 자동화를 붙일 수 있다는 점이 더해집니다.
아닙니다. 2025년 6월 24일 최고경영자 서한은 이번 개편을 회사의 "다시 창업하는 순간"이라고 표현하면서, 기존 플랫폼 위에 인공지능 기능을 추가한 형태가 아니라고 분명히 밝혔습니다. 실제로 애플리케이션을 만드는 출발점 자체가 대화형 구축기로 바뀌었고, 에이전트가 레코드 단위에서 작동합니다. 다만 바닥에 깔린 관계형 데이터 구조는 그대로 유지됩니다.
개인에게 고정되지 않습니다. 등급별로 유료 사용자 수에 따라 월 단위 몫이 정해지지만, 그 몫은 무료와 Team 등급에서는 워크스페이스 수준에서, Business와 Enterprise 등급에서는 조직 수준에서 함께 사용됩니다. 이 구조 덕분에 특정 인원에게 몫이 묶여 낭비되는 일은 줄어들지만, 반대로 한 팀의 대량 자동화가 공동 몫을 빠르게 소진할 수 있습니다.
대화형 구축기로 애플리케이션을 구축하는 행위 자체는 크레딧을 소비하지 않습니다. 따라서 구조를 여러 차례 다시 만들어 보며 최적의 형태를 찾는 데에는 비용 부담이 없습니다. 크레딧은 운영 중 실행되는 처리, 즉 데이터 분석이나 내용 생성 같은 동작에서 소모됩니다. 소비량은 입력 데이터, 선택한 모델, 출력 데이터에 따라 달라집니다.
제한이 뚜렷합니다. 베이스당 1000건의 레코드, 1GB의 첨부 용량, 2주의 수정 이력과 스냅숏 보관, 워크스페이스당 월 1000회의 API 호출이 전부입니다. 개념을 검증하거나 소규모 개인 업무를 정리하는 데는 쓸 만하지만, 여러 사람이 데이터를 쌓는 실제 운영에서는 금세 한계에 닿습니다. 특히 2주라는 이력 보관 기간은 실수 복구 관점에서 짧습니다.
공식 설명에 따르면 모델 제공 측은 고객 데이터를 보관하지 않으며, 고객 데이터는 모델 학습에 사용되지 않습니다. 또한 기업 고객은 어떤 모델을 사용할지 직접 결정할 수 있습니다. 관리자는 워크스페이스 수준에서 인공지능 사용 여부와 접근 가능한 데이터 범위를 통제할 수 있으므로, 특정 데이터를 처리 대상에서 제외하는 운영도 가능합니다.
보유 인증으로는 SOC 2 Type 2, ISO/IEC 27001:2022, ISO/IEC 27701:2019, HIPAA, TX-RAMP Level 2가 있습니다. 유럽 연합 내 데이터 저장 선택지가 제공되며, 기업 고객은 자체 키로 저장 데이터를 암호화할 수 있습니다. 관리 패널, 감사 로그, 데이터 유출 방지 같은 통제 기능은 최상위 기업 등급에 속하므로, 요건이 강한 조직이라면 등급 선택 단계에서 이를 함께 고려해야 합니다.
한도는 베이스 단위이므로, 먼저 데이터를 성격별로 나누어 여러 베이스로 분리하는 방법을 검토할 수 있습니다. 보관 주기를 정해 오래된 기록을 정리하거나, 상세 로그 대신 요약 표를 유지하는 설계도 도움이 됩니다. 등급을 올리면 Team은 50000건, Business는 125000건까지 늘어납니다. 1억 건이 넘는 대규모 데이터셋을 다루어야 한다면 별도의 대규모 데이터셋 통로가 검토 대상이지만, 이는 기업 수준의 역량입니다.
2026년 8월 4일 Bending Spoons가 인수에 관한 최종 계약 체결을 발표했고 기업 가치는 12억 8500만 달러입니다. 다만 거래는 아직 완료되지 않았으며 규제 승인 등 통상적인 조건이 남아 있고 연내 완료가 예상됩니다. 종결 전까지 두 회사는 독립적으로 운영되며 제품, 브랜드, 도메인은 현재 변화가 없습니다. 단기 도입에는 영향이 적지만, 여러 해에 걸친 계약을 검토한다면 종결 이후의 가격 정책과 제품 방향을 변수로 두는 편이 현실적입니다.
웹 API는 표준적인 REST 의미론을 따르고 JSON으로 데이터를 주고받으며 표준 HTTP 상태 코드로 결과를 알려 주므로, 기술적인 진입 장벽은 높지 않습니다. 실제로 확인해야 할 것은 호출 한도입니다. 무료 등급은 워크스페이스당 월 1000회, Team 등급은 월 100000회이며 Business 등급부터는 제한이 없습니다. 짧은 주기로 반복 조회하기보다 변경이 발생한 시점에만 호출하도록 설계하면 한도를 훨씬 여유 있게 쓸 수 있습니다.
