
Notion이냐 Airtable이냐…10명 팀은 문서와 데이터에서 3,000달러 갈린다

문서 승인과 프로젝트 기록이 중심인 팀에는 Notion이, 고객·거래·게시 기록의 관계를 계속 갱신하는 팀에는 Airtable이 적합하다. 연간 결제에서 10명 모두 유료 좌석을 쓴다면 Notion Business의 사용자당 월 20달러와 Airtable Business의 사용자당 월 45달러를 적용한 비용은 각각 연 2,400달러와 5,400달러로, 차이는 3,000달러다.
두 제품 모두 정보를 모으고 업무 상태를 표시할 수 있다. 차이는 팀이 매일 완성하는 결과물이 긴 문서인지, 여러 테이블에 나뉜 기록의 연결인지에 있다. 전자가 중심이라면 본문과 의견을 한곳에서 다루는 구성이 중요하고, 후자라면 같은 고객이나 콘텐츠를 여러 업무에서 일관되게 참조하는 구조가 중요하다.
연 3,000달러 차이를 바꾸는 좌석과 레코드
위 금액은 공개된 달러 요금에 같은 수의 유료 좌석과 12개월을 곱한 비교값이다. 한국 팀의 실제 원화 지출은 환율과 세금, 계약 조건, 도중에 추가한 좌석에 따라 달라진다. 특히 사람 수가 같아도 두 제품에서 유료로 계산되는 역할이 다르면 연간 차이 역시 달라진다.
Notion은 작업공간 구성원에게 유료 좌석을 부과한다. 개별 페이지에 초대하는 게스트는 무료지만 작업공간의 모든 팀 공간에 접근하는 구성원과 접근 범위가 같지 않다. 따라서 팀원이 프로젝트 문서와 위키를 폭넓게 작성·관리해야 한다면, 일부 페이지만 공유하는 게스트를 동일한 좌석으로 간주할 수 없다.
Airtable의 셀프서비스 요금제 안내는 Business에서 소유자·제작자·편집자를 과금 대상으로, 댓글 작성자와 읽기 전용 협업자를 비과금 대상으로 구분하며, Team과 Business의 베이스당 레코드 한도를 각각 5만 건과 12만 5,000건으로 제시한다. 같은 안내에 따르면 Team에서는 댓글 작성자도 과금 대상이다. ‘댓글만 쓰는 사람은 무료’라는 판단을 다른 등급까지 확대하면 견적이 틀어진다.
가령 구성원 가운데 소수만 Airtable의 고객 기록을 수정하고 나머지는 결과를 열람한다면 전원 유료 편집자라는 계산을 그대로 적용하기 어렵다. 반대로 콘텐츠 운영자가 모두 게시 상태를 고쳐야 한다면 읽기 전용 권한으로 좌석을 줄일 수 없다. 비용 비교에는 직책보다 실제로 필요한 수정 권한을 넣어야 한다.
레코드 한도도 테이블 하나가 아니라 베이스 안의 여러 테이블을 합산해 판단한다. 고객, 거래, 활동을 별도로 쌓는 CRM에서는 고객 수가 적어도 활동 기록이 빠르게 늘 수 있다. 한도에 이르면 기존 데이터가 없어지는 것은 아니지만 새 레코드를 추가할 수 없으므로, 현재 행 수만큼 기록이 늘어나는 방식도 살펴야 한다.
문서 승인: 본문과 판단이 같은 곳에 있어야 할 때
원고, 제안서, 정책 문서처럼 본문 자체가 결과물이라면 Notion의 페이지 중심 구성이 편하다. 문서 데이터베이스의 각 항목을 본문 페이지로 쓰고 담당자, 마감일, 승인 상태를 속성으로 붙일 수 있다. 검토자는 항목을 열어 원문과 의견을 함께 확인하므로, 목록의 상태와 별도 파일의 내용을 번갈아 찾는 단계를 줄일 수 있다.
Notion의 공유·권한 안내는 데이터베이스의 내용은 수정하되 속성 구조와 보기는 바꾸지 못하는 권한, 댓글만 남기는 권한, 열람만 하는 권한을 구분한다. Business에서는 새 항목을 만들 수 있으면서 별도 접근 권한이 없는 기존 항목은 보거나 수정하지 못하는 권한도 제공한다. 초안 작성자와 검토자의 작업 범위를 나눌 때 유용한 차이다.
조건부로 승인 흐름을 설계한다면 작성자는 본문을 수정하고 검토자는 댓글을 남기며 승인 권한을 가진 사람이 상태를 변경하도록 할 수 있다. 다만 상태 속성은 승인 절차 전체가 아니다. 수정 요청 뒤 어느 본문을 다시 검토할지, 승인 후 누가 재수정할 수 있는지를 정해야 완료 표시가 실제 결정을 뜻한다.
Airtable에서도 문서별 담당자와 승인 상태를 기록할 수 있다. 그러나 업무 시간이 긴 본문을 읽고 고치며 의견을 주고받는 데 집중된다면, 레코드 사이의 관계보다 문서 안의 작업 맥락이 선택을 좌우한다. 이 경우 낮은 구독료는 팀이 자주 쓰는 작업 방식과 함께 얻는 이점이다.
CRM: 고객 명단보다 연결된 활동이 중요할 때
고객 이름과 연락처, 진행 상태를 간단히 관리하는 수준이라면 Notion 데이터베이스로도 시작할 수 있다. 고객마다 여러 거래가 있고 거래마다 통화·제안·후속 조치가 쌓인다면 구조가 복잡해진다. 고객 정보를 거래와 활동 항목마다 복사하면 연락처나 담당자가 바뀔 때 수정할 곳도 늘어난다.
Airtable의 연결 레코드 안내는 테이블 간 일대다·다대다 관계를 만들고, 관계 자체에 정보를 저장해야 할 때 연결 테이블을 쓰는 방식을 설명한다. CRM에 적용하는 조건부 설계라면 고객, 거래, 활동을 별도 테이블로 두고 서로 연결할 수 있다. 한 활동에 여러 담당자가 참여하며 각자의 역할까지 기록해야 한다면 참여 관계도 독립된 기록으로 다룰 수 있다.
Notion에도 데이터베이스 사이의 관계형 속성이 있으므로 고객 페이지와 관련 거래를 연결하는 것 자체는 가능하다. 판단 기준은 관계형 기능의 존재 여부보다 팀이 그 관계를 얼마나 자주 수정하고 조회하는지다. 고객 기록을 열 때 회의 메모와 제안서 본문을 읽는 일이 많으면 페이지 구성이 자연스럽고, 거래와 활동의 상태를 계속 갱신한다면 레코드 중심 구성이 더 직접적이다.
권한 설계도 CRM에서 달라진다. 영업 담당자가 거래를 수정해야 하는지, 관리자가 고객 정보만 관리해야 하는지, 다른 부서는 결과만 보면 되는지에 따라 Airtable의 유료 좌석 수가 정해진다. 열람 인원이 많은 팀이라면 전체 인원에 동일한 편집 권한을 주는 가정보다 역할별 견적이 실제 지출에 가깝다.
콘텐츠 캘린더: 날짜보다 원고와 게시 건의 관계
게시일, 담당자, 채널, 승인 상태를 정하고 각 일정에서 원고를 작성한다면 Notion의 문서 데이터베이스가 간결하다. 편집자는 일정 항목을 열어 본문과 수정 의견을 확인하고, 승인자는 같은 항목에서 상태를 볼 수 있다. 캘린더는 원고를 찾는 보기이며 실제 작업은 문서에서 이뤄지는 셈이다.
하나의 콘텐츠가 여러 캠페인이나 채널에 쓰인다면 구분할 대상이 늘어난다. 조건부 설계로 콘텐츠, 캠페인, 채널별 게시 건을 각각 기록하면 원고의 승인 상태와 개별 게시 건의 발행 상태를 섞지 않을 수 있다. 뉴스레터 원고가 소셜 채널에도 쓰일 때 원고는 같아도 게시일, 담당자, 결과는 서로 다를 수 있기 때문이다.
이처럼 게시 건마다 별도 상태와 결과를 축적하는 팀에는 Airtable의 연결된 테이블 구성이 적합하다. 반면 채널별 기록이 적고 일정 항목을 여는 주된 이유가 본문 수정이라면 Notion에서 관리할 구조가 단순하다. 두 제품의 캘린더 화면이 비슷해 보여도 날짜 뒤에 연결해야 할 정보가 다르면 유지할 데이터 구조도 달라진다.
도구를 옮길 때는 관계를 다시 세워야 한다
구독료만 비교하면 이전 작업의 무게가 빠진다. Notion에서 원고와 회의록을 페이지로 관리했다면 새 도구에서 본문, 첨부 자료, 의견을 어느 기록에 둘지 정해야 한다. Airtable에서 고객과 거래를 별도 테이블로 연결했다면 각 테이블의 항목을 옮기는 것과 항목 사이의 대응 관계를 복원하는 것은 다른 작업이다.
특히 고객 이름만으로 거래를 다시 연결하면 이름이 같은 항목이나 변경된 이름에서 혼동이 생길 수 있다. 이전 작업에서는 고객별 거래와 거래별 활동처럼 유지해야 할 관계를 식별한 뒤 누락과 중복을 확인해야 한다. 이는 제품 요금표에서 계산할 수 있는 고정 비용이 아니라 기존 데이터 구조와 기록 상태에 따라 달라지는 팀의 작업량이다.
선택은 결국 가장 자주 완성하는 산출물과 수정 권한을 함께 보는 문제다. 문서 승인과 프로젝트 기록이 중심이고 CRM이 간단하다면 Notion이 비용과 작업 방식에서 유리하다. 고객·거래·활동 또는 콘텐츠·캠페인·게시 건의 관계를 지속적으로 운영한다면 Airtable에 더 높은 좌석 비용을 지불할 이유가 생긴다. 그 비용은 팀 전체 인원이 아니라 실제로 기록을 고쳐야 하는 사람의 수로 판단해야 한다.
함께 읽기:
관련 기사
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.




