AI 에이전트에 Airtable 연결하기

1. Airtable 베이스를 죽이는 것

이런 베이스들이 어떻게 끝나는지를 정직하게 볼 필요가 있습니다. 같은 양상이 반복되고, 그것은 도구의 품질과 아무 상관이 없기 때문입니다.

• 베이스는 한 사람이 만든다. 잘 만들어졌고, 업무에 정확히 맞고, 설계한 본인에게는 명확합니다. 여기가 가장 좋은 시점입니다.
• 입력은 같은 그 한 사람에게 쏠린다. 다른 사람들은 베이스를 보기만 하고 채우지 않습니다 — 악의가 아니라, 행을 채우려면 어느 열에 무엇이 들어가는지 알아야 하기 때문입니다.
• 바쁜 한 달이 지난다. 갱신하지 않은 3주면 충분합니다. 그 뒤로는 아무도 숫자를 믿지 않고, 그래서 아무도 고치지 않고, 그래서 정말로 틀린 것이 됩니다.

비용은 Airtable 구독료가 아닙니다. 그것은 소박합니다. 비용은, 대체하고 있는 진짜 소프트웨어에 해당하는 반나절과, 그것을 갖고 있지 않다는 사실의 곱 — 그리고 낡은 표를 보고 내리는 판단입니다. 도구를 살 여력이 없는 기업의 전형적인 그림입니다. 자체 제작은 옳은 선택이고, 그만큼 누군가가 유지할 것을 요구합니다.

2. 에이전트가 Airtable에서 하는 일

Airtable의 공식 커넥터는 귀하가 지정한 베이스에 읽기 및 쓰기 접근을 줍니다. 구체적으로는 다음과 같습니다.

• 레코드 읽기. 한 건을 찾아내고, 두 테이블을 맞춰 보고, 손으로 훑는 대신 베이스를 봐야만 답할 수 있는 물음에 답합니다.
• 레코드 만들기. 빠져 있는 행 — 새 연락처, 들어온 주문, 착수한 현장 — 을 금요일이 아니라 그 사실이 일어난 시점에 추가합니다.
• 레코드 갱신하기. 상태를 바꾸고, 비어 있던 항목을 채우고, 다른 곳에서 바뀐 값을 고칩니다.

이것을 쓸모 있게 만드는 조합은 거의 언제나 같습니다. 정보가 생겨나는 도구 — 메일함, 결제, 잡힌 약속 — 에서 벌어진 일을 에이전트가 읽고, 그 기록을 Airtable에 남깁니다. 베이스는 옮겨 적는 작업이기를 그치고 거울이 됩니다.

3. Airtable 고유의 제약 — 한 번에 하나의 베이스

범위는 두 층으로 지정하며, 이는 형식이 아닙니다. Airtable에서는 같은 계정이 서로 아무 상관 없는 베이스들을 품고 있는 경우가 매우 많기 때문입니다.

• 워크스페이스. 한 팀이나 한 고객의 베이스들을 묶는 단위입니다.
• 베이스 그 자체. 에이전트는 귀하가 지정한 것을 보고, 다른 것은 보지 않습니다.

이 페이지에서 가장 구체적인 조언이 이것입니다. 에이전트에게 필요한 베이스만 공유하십시오. 많은 기업이 의식하지 못한 채, 영업 관리표와 프로그램의 손이 닿아서는 안 될 정보 — 급여 파일, 면담 기록, 진행 중인 협상 — 를 함께 Airtable에 둡니다. 베이스를 지정하는 30초의 동작이 이 문제를 결정적으로 정리합니다.

이 커넥터가 대부분보다 덜 노출된 이유도 같습니다. 아무에게도 말을 걸지 않기 때문입니다. 쓰는 것이 고객에게 닿지도, 공개되지도, 돈을 빼가지도 않습니다. 여기서의 위험은 보이거나 바뀌는 데이터이고, 베이스를 지정함으로써 닫힙니다.

4. 하지 않는 일

• 베이스를 재편성하지 않습니다. 테이블, 필드, 뷰는 귀사의 작업입니다. 에이전트는 구조를 채울 뿐, 다른 구획이 더 나아 보인다는 이유로 다시 만들지 않습니다.
• 일괄 삭제를 하지 않습니다. 대량 정리는 휴지통이 있더라도 사실상 되돌릴 수 없습니다. 한 건씩 승인하거나, 아예 하지 않거나입니다.
• 빈 항목을 추정값으로 채우지 않습니다. 기입되지 않은 칸은 그럴듯한 값으로 메워지는 대신 비어 있는 채로 남습니다 — 그것이 베이스를 망가뜨리는 가장 눈에 띄지 않는 방법이고, 나중에 찾아내기가 가장 어려운 방법입니다.
• 완화하지 않는 한 승인 없이는 쓰지 않습니다. 이 커넥터에서는 어휘가 정해진 뒤에 완화하는 것이 합리적입니다. 여기서의 쓰기는 발송이나 공개와 달리 되돌릴 수 있기 때문입니다.

5. 자신이 설계하지 않은 구조에 쓰기

이것이 Airtable 고유의 어려움이며, 분명히 짚어 둘 가치가 있습니다. 베이스는 사적인 어휘 체계입니다. 「상태」 열에 담긴 값은 귀사에서만 통하고, 「프로젝트」 테이블은 다른 곳의 「프로젝트」와 같은 것을 가리키지 않으며, 비슷한 이름의 두 열이 서로 다른 것을 뜻하는 경우도 있습니다.

그런 구조를 이해하지 못한 채 쓰는 에이전트는 단정한 혼란을 만듭니다. 형태가 올바른 행이 잘못된 자리에 놓이는 것입니다. 이 함정을 피하는 것은 두 가지 습관으로 정리됩니다.

• 처음 며칠은 승인을 남겨 두십시오. 의심해서가 아니라, 에이전트가 무엇을 어디에 두는지 보기 위해서입니다. 거기서 자기 베이스의 애매함을 발견하게 됩니다 — 대개는 놀라움과 함께.
• 애매한 것에 이름을 붙이십시오. 「대기」라는 상태가 귀사에서는 「고객 대기」이지 「우리 대기」가 아니라고 한 번 말해 두는 것이, 나중의 어떤 수정보다 값집니다.

이 틀을 잡는 작업은 한 시간이면 되고 두 번은 없습니다. 덧붙이자면, 그것이 귀사 베이스가 갖게 될 최초의 설명서이기도 합니다.

6. 시간이 지나며 달라지는 것

• 1주 차. 쓰기가 승인을 거치고, 귀하는 정리 방식을 다듬습니다. 눈에 보이는 이득은 적습니다. 진짜 이득은 베이스가 한 사람에게 의존하기를 그친다는 것입니다.
• 3개월 차. 행은 사건이 일어난 그날 늘어납니다. 만들어 두었던 뷰와 대시보드가 다시 무언가를 말하기 시작합니다 — 옳지 않게 된 것이 아니라, 공급이 멈춰 있었을 뿐입니다.
• 2년 차. 베이스가 긴 기간에 걸쳐 빠짐없이 갖춰진 상태는 드물고 값집니다. 비교할 수 있고, 계절성이 보이고, 무언가를 그만둘 결정을 내릴 수 있습니다. 또한 이 베이스가 진짜 도구가 될 만한지 알게 되는 시점이기도 합니다 — 구멍 난 데이터로는 결정할 수 없던 물음입니다.

수치로 된 시간 절감은 약속하지 않습니다. 그것은 무엇을 어떤 빈도로 관리했느냐에 달렸습니다. 보장되는 것은, 아무도 채울 시간이 없을 때 베이스가 채워져 있다는 점입니다.

7. 자주 묻는 질문

더 읽기

다음으로 읽기: Google 스프레드시트 연결하기, Notion 연결하기, 또는 이용 가능한 모든 커넥터.