대부분의 통합 페이지는 로고 개수만 셉니다. Tajo는 실제로 작동하는 것을 세고, 그 차이를 보여드립니다.
"200개 연동 지원"은 거의 무엇이든 의미할 수 있고, 대개 그렇습니다. Tajo는 이 주장을 엄격하고 검증 가능한 정의를 가진 단계로 나눕니다. 카탈로그에만 있는 것, 관리되는 런타임에 등록된 것, 동기화로 데이터를 읽을 수 있는 것, 동기화나 발송의 목적지로 쓸 수 있는 것입니다. 아래 숫자는 플랫폼의 현재 정직한 상태입니다. 숫자가 바뀌면 이 페이지도 바뀝니다.
| 티어 | 현재 | 실제 의미 |
|---|---|---|
| 쓰기 목적지 Brevo, Shopify, HubSpot, Salesforce, Pipedrive, Zoho CRM. | 6 | 동기화나 발송의 목적지로 쓰이는 실제 쓰기 작업을 가진 커넥터입니다. 모든 쓰기는 런타임의 게이트를 거칩니다. 입력에 묶인 일회용 승인과 예산 한도입니다. |
| 동기화로 읽기 레코드를 동기화로 읽을 수 있는 등록된 연동. | 47 | 동기화의 소스입니다. 일부는 웹훅 생성, 채팅 답장, 읽기만 하는 POST 엔드포인트 같은 작업도 제공하지만, 이는 쓰기로 세지 않습니다. |
| 등록됨 실제 운영 런타임에 등록된 연동. | 55 | 자격 증명 확인을 마치고 거버넌스 아래에서 실행됩니다. 등록만으로는 레코드가 움직이지 않습니다. 각각이 무엇을 할 수 있는지는 위의 두 단계가 알려 줍니다. |
| 탐색 코퍼스 벤더가 공개한 API 명세의 작업으로, 에이전트가 여기서 초안을 작성합니다. | 27 벤더 / 5,937 오퍼레이션 | 이는 연결이 아니라 초안 작성을 위한 자료입니다. 이 벤더 중 하나를 스택에서 사용하고 있다면, 에이전트는 엔드포인트를 추측하는 대신 실제로 문서화된 API 오퍼레이션을 기반으로 초안을 작성합니다. |
| 카탈로그 등재 통합 카탈로그에 등재된 항목입니다. | 200 | 로드맵 상의 항목으로, Tajo가 파악하고 범위를 정의한 시스템입니다. 카탈로그 등재만으로는 데이터가 이동하지 않으며, Tajo는 그렇지 않은 척하지 않습니다. |
티어는 가장 검증된 것부터 가장 넓은 범위까지 순서대로 나열되어 있습니다. 모든 티어의 모든 통합은 다이제스트에 고정된 승인, 실패 시 거부로 처리되는 동의 규칙, 예산 상한, 위변조 방지 감사 로그라는 동일한 거버넌스 아래에서 운영됩니다. 전체 라이프사이클은 작동 방식 페이지에서 확인하세요.
단계가 올라갈수록 기준은 엄격하게 높아집니다. 시스템을 목록에 올리는 것은 쉽습니다. 관리되는 런타임에 등록하는 데는 작업이 필요하고, 그 레코드를 동기화로 읽는 데는 더 많은 작업이, 목적지로서 쓰는 데는 가장 많은 작업이 필요합니다. 이 사다리는 그 작업이 어디까지 왔는지 정확히 보여 줍니다.
커넥터는 동기화나 발송의 목적지로 쓰이는 실제 쓰기 작업이 있을 때만 셉니다. 웹훅 생성, 채팅 답장, 읽기만 하는 POST 엔드포인트 호출은 세지 않습니다. 그래서 55개 중 6개만 해당됩니다. 현재 인증 라벨을 단 연동은 없습니다.
얼리 액세스 파트너가 그 순서를 정합니다. 스택에 연결이 필요한 코퍼스 벤더가 있거나, 이미 연결된 통합을 쓰기 가능하도록 만들어야 한다면, 이것이 바로 Tajo의 에이전트와 팀이 존재하는 이유인, 고객 현장에 직접 투입되어 수행하는 작업입니다.
그 대안은 업계의 관행이기 때문입니다. 오래된 카탈로그 항목과 검증을 거친 목적지가 똑같아 보이는 로고 벽입니다. 그 차이가 프로젝트의 성패를 좌우하기 전까지는 말입니다. Tajo의 전제는 전적으로 검증 가능성에 있습니다. 확인할 수 있는 승인, 무엇이 실행되었는지 증명하는 실행 기록, 조용히 수정할 수 없는 감사 추적입니다. 수치를 부풀린 준비 상태 페이지는 그런 제품의 관문으로는 어울리지 않을 것입니다. 이 페이지는 그렇지 않습니다.
다음에 무엇을 등록하고 쓰기를 지원할지는 얼리 액세스 파트너가 정합니다. 연결해야 할 시스템을 알려 주시면 함께 만들어 가겠습니다.