어제 오후, 우리 팀의 한 엔지니어가 Anthropic이 SaaStr 무대에서 자사 내부 GTM 스택을 훑는 것을 지켜보다가, 그 슬라이드를 스크린샷으로 찍고 Zero에게 질문 하나를 던졌다. 이 중에 우리가 빠뜨린 건 뭐지? 6시간 19분 뒤, Snowflake는 모든 Zero 고객을 위한 프로덕션에 라이브로 올라가 있었다. 그것은 우리가 1년 동안 출시한 180번째쯤 되는 연동이었고, 점점 더 그다음 것을 작성하는 사람은 아예 엔지니어가 아니다. 그것을 가능하게 만드는 프레임워크와, 그 위에 얹힌 내부 스킬을 여기 소개한다.
에이전트 플랫폼에 대해 아무도 말해주지 않는 것
LLM은 병 속에 든 뇌다. 그 자체로는 당신의 데이터 웨어하우스에 대한 시를 써줄 수는 있어도, 실제로 그것을 열 수는 없다. 챗봇을 에이전트로 바꾸는 것, 당신의 팀이 실제로 돈을 내고 사는 것은, 에이전트가 당신이 이미 쓰는 도구 안으로 손을 뻗어 그 안에서 일을 해낼 수 있느냐다.
우리는 그 손길을 **커넥터 계층(connector layer)**이라고 부른다. Zero를 1년 동안 만든 끝에, 우리는 그것이 에이전트 제품에서 가장 중요한 단 하나의 인프라라고 믿는다. 그래서 우리는 우리만의 것을 만들었다. 더 중요한 것은, 팀의 누구든 그것을 작성할 수 있게 해주는 워크플로를 그 주위에 만들었다는 점이다.
왜 MCP가 아닌가. 왜 Zapier가 아닌가.
둘 다 초기에 우리에게 요청받았다. 둘 다 각자의 용도에는 좋다. 어느 쪽도 우리가 필요로 한 것은 아니었다.
MCP는 프로토콜이지 제품이 아니다. 자기 서비스를 어떤 LLM이든 닿을 수 있게 하고 싶은 도구 작성자에게는 훌륭하다. 하지만 오늘날 배포되는 MCP 서버는 모델에게 도구 목록을 건네주고 그것을 안전하게 호출하리라 믿는다. 조직별 자격 증명 금고도, 어떤 엔드포인트를 칠 수 있는지에 대한 방화벽도, 호출을 그것을 승인한 사람에게 다시 연결해주는 감사 로그도 없다. 한 에이전트가 고객의 프로덕션 Stripe를 건드릴 수도 있고 다른 에이전트가 그 CEO의 Gmail에서 이메일 초안을 쓸 수도 있는 제품에서, "모델을 믿어라"는 보안 모델이 아니다.
Zapier 방식의 연동 플랫폼은 다른 문제를 푼다. 결정론적 트리거를 결정론적 액션에 배선한다. 에이전트는 그런 식으로 작동하지 않는다. 에이전트는 생각하는 도중에 다음 단계가 Snowflake에 쿼리한 다음 Linear 티켓을 작성하는 것이라고 결정한다. 미리 만들어진 레시피가 아니라, 지금 당장 자격 증명과, 범위가 지정된 HTTP 클라이언트와, 감사 추적이 필요하다.
그래서 우리는 지루한 것을 만들었다. 각 항목이 인증 메타데이터, 어떤 비밀이 샌드박스에 주입되는지에 대한 환경 매핑, 허용된 호스트의 방화벽, 그리고 OAuth나 토큰의 특이사항을 위한 작은 핸들러를 담고 있는 연동 레지스트리다. 그것이 인프라다.
하지만 인프라는 이 이야기에서 흥미로운 부분이 아니다. 흥미로운 부분은 그 위에서 벌어진 일이다.
모두를 커넥터 작성자로 만든 스킬
새로운 SaaS가 우리의 연동 백로그에 하루에 대략 두 번씩 떨어진다. 어떤 것은 고객 요청에서 온다. 어떤 것은 팀원이 Zero가 자기에게 필요한 무언가를 못 한다는 걸 알아차린 데서 온다. 어떤 것은 잠재 고객의 스택에 우리가 아직 만나본 적 없는 도구가 들어 있는 BD 대화에서 온다.
그 하나하나가 엔지니어의 대기열을 거쳐야 했다면, 우리는 일주일에 하나를 출시했을 것이다. 우리는 하루에 하나를 출시한다.
그 이유는 우리가 **커넥터 작성 스킬(connector-authoring skill)**이라고 부르는 내부 도구다. 그것은 Zero 스킬로, 우리가 고객에게 출시하는 것과 똑같은 형태이지만, 우리 자신의 코드베이스를 향해 안쪽을 가리키고 있다. 팀의 누군가 "Notion 커넥터를 추가하고 싶어요"라고 말하면, Zero가 그를 단계별로 안내한다:
- 사용자 시나리오에서 시작한다. 사용자가 이 도구로 실제로 하고 싶은 것이 무엇인가? "데이터베이스를 쿼리한다", "페이지를 만든다", "워크스페이스 전체를 검색한다". 이 스킬은 파일 하나를 건드리기 전에 구체적인 사용자 스토리를 고집한다. 커넥터의 목표는 API를 빠짐없이 감싸는 것이 아니라 에이전트 역량을 가능하게 하는 것이다.
- 인증 형태를 식별한다. OAuth, API 토큰, 또는 둘 다. 이 스킬은 각 형태가 무엇을 수반하는지 안다. OAuth라면 동의 UI와 리디렉트 배관, API 토큰이라면 조직별 비밀 주입과 사용자가 토큰을 얻는 곳. 작성자는 도구에 맞는 형태를 고르고, 그 아래의 모든 것이 거기서 따라 나온다.
- 엔드포인트를 시나리오에 매핑한다. "REST API 전체를 감싸기"가 아니다. 사용자 스토리를 충족하는 몇 안 되는 엔드포인트만. 잘 고른 엔드포인트 세 개를 가진 커넥터가, 에이전트가 결코 손대지 않는 마흔 개를 가진 커넥터를 이긴다.
- 열두 개의 파일 골격을 잡는다. 레지스트리 항목, 핸들러, 방화벽 패턴, 플랫폼 아이콘, 환경 매핑 배관, 그리고 Zero에게 그 커넥터를 사용하는 법을 가르치는 에이전트 대면 스킬. 스킬이 골격을 쓰고, 작성자는 의도를 쓴다.
- 두 개의 PR을 연다. 하나는 커넥터 프레임워크로, 하나는 스킬 라이브러리로. 둘 다 엔지니어가 리뷰하지만, 그 리뷰는 정확성에 관한 것이지 프레임워크가 어떻게 작동하는지 작성자에게 가르치는 것이 아니다.
예전에는 제도적 지식이 필요했던 것(어느 인증 형태, 어느 엔드포인트, 어느 두 저장소의 어느 열두 파일, 방화벽 패턴이 동적 서브도메인과 어떻게 결합되는지)이 이제는 스킬 자체에 담겨 있다. 작성자는 사용자 공감을 가져온다. 스킬은 골격을 가져온다.
이것이 디자이너나 BD 리드나 PM이 커넥터를 출시하게 되는 방식이다. 그들은 사용자가 무엇을 원하는지 안다. 스킬은 나머지 전부를 안다.
사례 연구: Snowflake, 어제
어제 Anthropic은 SaaStr 무대에서 자사 내부 GTM 스택을 훑었다. 기록 시스템으로 Salesforce, 보강용으로 Clay, 라우팅용으로 LeanData, 통화용으로 Gong, 티켓용으로 Jira, 지원용으로 Intercom(Fin), 계약용으로 Ironclad, 데이터 웨어하우스로 Snowflake. [발표 링크]
우리 엔지니어 중 한 명이 그 슬라이드를 스크린샷으로 찍어 질문 하나와 함께 Zero에 떨궜다. "이 중에 우리가 커넥터를 빠뜨린 건 뭐지?"
뒤이어 실제로 벌어진 타임라인은 이렇다. 모든 시각은 PDT.
16:59. 스크린샷이 도착한다. Zero는 그것을 커넥터 카탈로그와 비교한다. 10개 중 7개가 이미 존재한다(Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). 세 개가 빠져 있고(Clay, LeanData, Snowflake), 데이터 웨어하우스가 GTM 스택의 토대이므로 Snowflake가 가장 가치 있는 것으로 표시된다. 17:00에 답이 도착한다.
17:01. 후속 질문: "이 중에 api-token 커넥터로 할 수 있는 건 뭐지?" Zero가 인증 문서를 끌어온다. Clay는 개인 API 키가 있고, Snowflake는 최근 Programmatic Access Token을 출시했으며, LeanData는 OAuth 전용이고 Salesforce에 묶여 있다. 17:02에 판정: Snowflake 먼저(가장 가치 높고 인증이 가장 깔끔), 그다음 Clay.
17:04. 엔지니어가 "진행"이라고 말한다. 커넥터 작성 스킬이 그것을 받아 든다. 17:07까지 Clay를 범위에서 제외하고(유일한 공개 표면이 테이블별 웹훅뿐이라 실제로 만들 커넥터가 없다) Snowflake의 형태를 확정한다. SNOWFLAKE_PAT 비밀 + SNOWFLAKE_ACCOUNT 변수, Snowflake REST API 및 SQL API v2에 대한 bearer 인증, Zendesk를 본뜬 동적 서브도메인 방화벽 패턴.
17:35. 두 PR이 같은 분에 열린다:
vm0-skills#176: 에이전트 대면 스킬. Snowflake SQL을 작성하는 법, 결과를 포맷하는 법, 일시적 오류에 재시도하는 법.vm0#13356: 커넥터 자체. 레지스트리 항목, PAT 핸들러, 방화벽 생성기, 플랫폼 아이콘, 환경 매핑 배관.
18:22. 스킬 PR 병합.
18:42. 커넥터 PR 병합.
18:52. 릴리스 PR 자동으로 열림.
23:18. web@v12.369.0과 나머지 릴리스 트레인이 프로덕션에 배포된다. Snowflake가 모든 조직에 라이브된다.
"Anthropic 스택의 스크린샷"에서 "Zero가 당신의 웨어하우스를 쿼리할 수 있음"까지 6시간 19분. 엔지니어 한 명. 대화 한 번. "커넥터 팀"으로의 인계는 0건.
여기서의 처리량은 엔지니어가 빨라서가 아니다. 커넥터 작성 스킬이 예전에는 제도적 지식을 요하던 부분들을 떠맡았기 때문이다. 어느 인증 형태를 고를지, 어느 엔드포인트가 사용자 시나리오에 매핑되는지, 어느 두 저장소의 어느 열두 파일이 들어가야 하는지, 방화벽 패턴이 동적 서브도메인과 어떻게 결합되는지. 작성자는 의도를 썼다. 스킬은 골격을 썼다. 나머지는 프로덕션이 했다.
이것이 프레임워크가 우리에게 사주는 것이다. 단지 속도뿐만이 아니라(속도도 진짜이지만), 누가 그 일을 떠맡을 수 있느냐다. Snowflake 작성자는 마침 엔지니어였다. 꼭 그래야 했던 것은 아니다.
왜 api-token이 일급 시민인가
따로 끄집어낼 만한 각주다. 사람들을 놀라게 한 의도적인 설계 선택이기 때문이다.
대부분의 에이전트 플랫폼은 OAuth를 유일한 참된 인증으로 취급하고 api-token을 레거시 도구를 위한 대체 수단으로 본다. 우리는 그 반대로 한다. API 토큰은 우리 커넥터 모델에서 일급 시민이다. 같은 동의 UI, 같은 조직별 금고, 같은 감사 추적, 같은 방화벽 강제가 적용된다.
이유는 두 가지다.
첫째는 api-token 인증이 첫 사용까지의 시간이 더 짧다는 것이다. Snowflake가 최근 Programmatic Access Token을 출시한 것이 정확히 이 이유 때문이다. OAuth 절차를 요구하지 않는, 수명이 길고 범위를 지정할 수 있고 철회 가능한 자격 증명. PAT를 가진 사용자는 Zero에서 1분도 안 되어 생산적으로 일할 수 있다. OAuth 흐름은 아무리 깔끔해도 더 오래 걸리고 사용자에게 더 많은 것을 요구한다.
둘째는 OAuth가 항상 제공되는 것은 아니다라는 점이다. 어떤 엔터프라이즈 도구는 아예 OAuth를 내놓지 않거나, 엔터프라이즈 SKU 뒤에 막아둔 것을 내놓는다. api-token을 (대체 수단이 아니라) 동등한 것으로 취급한다는 것은, 그런 도구들을 "곧 출시" 무덤에 방치하는 대신 제대로 지원할 수 있다는 뜻이다.
어제 출시된 Snowflake 커넥터는 api-token이다. 고객 이메일 스레드를 실어 나르는 Gmail 커넥터는 OAuth다. 둘 다 같은 프레임워크, 같은 스킬, 같은 리뷰를 거친다. 작성자는 도구에 맞는 형태를 고르고, 프레임워크가 어느 쪽이든 싸게 만들 수 있게 해준다.
180개 남짓의 연동이 실제로 무엇을 풀어주는가
숫자 자체가 핵심은 아니다. 핵심은 이 밀도에서 에이전트가 당신이 불러내는 도구이기를 멈추고 당신이 그 안에서 살아가는 환경이 되기 시작한다는 것이다.
Zero가 당신의 CRM에, 그리고 당신의 데이터 웨어하우스에, 그리고 당신의 지원 받은편지함에, 그리고 당신의 디자인 도구에, 그리고 당신의 저장소에 커넥터를 가지고 있을 때, 단일 연동 에이전트는 할 수 없는 일을 할 수 있다. Snowflake 쿼리를 끌어와, 열려 있는 Linear 티켓과 교차 참조하고, 고객 성공 팀이 사는 Slack 채널에 요약을 올릴 수 있다. Gong 통화를 읽고, 잠재 고객이 물어본 기능을 찾고, 그것이 로드맵에 있는지 확인하고, 후속 이메일 초안을 쓰는 것을 단 한 번의 동작으로 해낼 수 있다.
새 커넥터 하나하나는 가치를 선형으로 더하지 않는다. 조합적으로 더한다. 180번째 커넥터는 1번째보다 더 가치 있다. 앞서 온 179개와 조합되기 때문이다.
그것이 프레임워크 뒤에 깔린 베팅이다. 그리고 스킬 뒤에 깔린 베팅은, 복리의 속도가 당신 팀에서 몇 명이 그 더미에 보탤 수 있도록 허용되느냐에 달려 있다는 것이다.
다음은 무엇인가
우리는 커넥터 작성 스킬을 고객에게 여는 작업을 하고 있다. 당신이 팀을 위해 Zero를 운영하고 있고 연동이 필요한 내부 도구(당신의 청구 시스템, 당신의 웨어하우스, 당신의 커스텀 내부 관리자 패널)가 있다면, 어제 Snowflake를 출시한 바로 그 워크플로가 당신 것을 출시하는 데 쓰는 워크플로가 될 것이다. 같은 골격, 같은 인증 모델, 같은 방화벽, 같은 감사 추적. 다른 작성자.
그것이 흥미롭게 들린다면, 이야기 나누고 싶다.
