1,000+ SaaS 연결과 런타임 경계를 단일 스택으로 통합하는 오픈소스 커넥터
OpenConnector는 1,000개 이상의 SaaS 제공자와 9,400개가 넘는 사전구성 액션을 표준화된 스키마와 런타임 경계로 에이전트에 노출하는 오픈소스 인증 게이트웨이이다.
TL;DR
OpenConnector는 에이전트가 사용자 계정에 안전하게 접근하도록 하기 위해 1,000개 이상의 SaaS 제공자와 9,400개 이상의 사전구성 액션을 단일 런타임 경계로 제공하는 오픈소스 인증 게이트웨이이다. 런타임은 API 키와 OAuth2 자격증명을 내부에 보관하고 액션별 입력·출력 스키마와 요구 스코프를 노출하여 에이전트가 일관된 계약을 통해 호출하도록 한다. 로컬 Docker/Node, Cloudflare Workers(D1/R2/Static), 또는 OOMOL의 호스티드 런타임으로 배포할 수 있으며 Connector SDK와 oo CLI를 통해 개발·디버깅·MCP 연동을 지원한다. 이 구조는 에이전트 쪽에서 자격증명을 직접 관리하지 않으면서도 정책 적용과 실행 로그 보관을 가능하게 하여 통합 비용과 보안 검증 부담을 줄이는 대안이 된다.
주요 기능
- 커넥터 카탈로그를 제공하여 GitHub, Gmail, Notion 등 1,000개 이상의 제공자에 대해 동일한 액션·스키마 식별자를 사용하고 런타임에서 일관된 호출 인터페이스를 제공한다.
- 다양한 인증 방식을 지원하여 API 키, OAuth2, 커스텀 자격증명, 무인증 제공자까지 런타임에서 안전하게 자격증명을 보관하고 토큰 갱신과 암호화를 처리한다.
- 런타임에서 액션의 요청·응답 스키마와 필요한 스코프를 노출하고 lazy-loaded executor 소스를 통해 실행을 격리하며 실행 로그와 정책을 검사 가능한 형태로 유지한다.
- 여러 배포 경로를 지원하여 로컬 Docker/Node.js, Cloudflare Workers(D1/R2/Static), 그리고 OOMOL의 호스티드 런타임 중 요구사항에 맞춰 선택적으로 배포할 수 있다.
어떻게 동작하는가
OpenConnector는 에이전트와 애플리케이션이 SDK, CLI, MCP, HTTP/OpenAPI 중 하나로 게이트웨이에 요청을 보내면 런타임가 자격증명 경계로서 제공자 토큰과 키를 보관하고 액션 실행을 중계하도록 설계되었다. 각 액션은 입력·출력 스키마와 요구 스코프를 갖는 계약으로 정의되며 에이전트는 이 계약을 통해 안전하게 호출을 구성하고 결과를 받는다. 런타임은 토큰·정책·임시 파일 전송·실행 로그를 관리하여 제공자 자격증명이 에이전트 프로세스 밖에 머물도록 보장한다.
해결 문제
에이전트가 사용자 계정에 접근할 때 각기 다른 서비스별 인증 방식과 토큰 관리를 직접 구현해야 하는 복잡성을 해소한다. OpenConnector는 중앙 런타임에서 자격증명을 안전하게 보관하고 표준화된 액션 계약을 통해 에이전트가 일관된 방식으로 다양한 SaaS에 접근하도록 한다. 이로 인해 에이전트 측에서 자격증명을 저장하거나 각 제공자별 로직을 중복 구현할 필요가 줄어들며 감사와 정책 적용이 가능한 경계가 확보된다.
지금 주목받는 이유
대형 SaaS 통합과 에이전트 사용 증가로 인해 사용자 계정에 대한 안전한 재사용 가능한 접근 경계가 필요해졌다. OpenConnector는 이미 구축된 1,000개 이상의 제공자 커버리지와 MCP·OpenAPI·SDK 연동을 통해 에이전트 통합 비용을 낮추는 실무적 가치를 제공했다. 또한 Cloudflare Workers 호환성과 오픈소스 성격으로 다양한 배포 시나리오를 지원한다는 점에서 주목받고 있다.
차별점
- 광범위한 제공자 커버리지를 유지하여 단일 카탈로그에서 1,000개 이상의 SaaS 제공자와 9,400개 이상의 사전구성 액션을 노출한다는 점이 차별점이다. 이 카탈로그는 동일한 provider id와 action id를 오픈소스와 상용 배포 모두에서 재사용할 수 있게 설계되어 에코시스템 일관성을 제공한다. 제공자별로 미리 정의된 스키마와 스코프가 있어 통합 비용이 낮아진다.
- 런타임 경계에 초점을 둔 설계로서 제공자 자격증명을 에이전트 프로세스 밖에 보관하고 액션 실행을 대리하는 구조가 특징이다. 이 방식은 토큰 갱신, 암호화 저장, 실행 로그와 정책 적용을 중앙에서 관리함으로써 보안 및 감사 요건을 충족한다. 에이전트는 메타데이터와 안전한 계정 라벨만 받아 실행을 진행한다.
- Cloudflare Workers와의 호환성, 로컬 Docker/Node 배포, 그리고 OOMOL의 호스티드 런타임을 모두 지원하여 배포 유연성이 크다. 특히 Workers+D1+R2 조합으로 경량 엣지 런타임을 구성할 수 있어 인프라 제약이 있는 팀에도 적합하다. 또한 Connector SDK와 oo CLI를 통해 개발자 워크플로와 디버깅을 연결하는 도구 체인이 제공된다.
사용 사례
- 에이전트 제품에서 여러 사용자의 다양한 SaaS 계정을 재사용 가능한 방식으로 호출해야 할 때 유용하다. 런타임에 자격증명을 보관하고 액션 스키마를 통해 안전한 호출 계약을 제공함으로써 에이전트가 민감한 자격증명을 직접 다루지 않게 만든다.
- 팀 내부 도구나 개발자 툴체인에서 공통된 커넥터 레이어를 두어 OAuth 클라이언트 구성, 토큰 갱신, 액션 정책을 중앙에서 통제할 때 적용할 수 있다. 이로 인해 접근 권한과 실행 로그를 일관되게 관리할 수 있다.
- 경량 호스팅 환경이나 엣지 환경에서 런타임을 운영해야 할 때 Cloudflare Workers + D1/R2 조합으로 빠르게 배포하고 스케일링할 수 있다. 또한 OOMOL의 호스티드 런타임을 이용하면 OAuth 승인 제약으로 배포가 지연되는 팀도 즉시 연결 경험을 사용할 수 있다.
시작하기
로컬에서 빠르게 시작하려면 Docker Compose로 전체 런타임과 웹 콘솔을 빌드·기동하면 된다. 예를 들어 docker compose up --build를 실행하면 http://localhost:3000에서 콘솔과 OpenAPI 문서를 확인할 수 있다. 이후 제공자 연결을 등록하고 curl로 액션을 호출해 동작을 검증하거나 Connector SDK와 oo CLI를 통해 프로덕션 연동을 진행하면 된다.
요구사항
- Node.js 22 이상이 개발 및 일부 런타임 경로에서 요구된다.
- 로컬 자가 호스팅 시 Docker 또는 Node 환경이 필요하며, Cloudflare 배포를 원하면 Workers 계정과 D1/R2 리소스가 필요하다.
- OAuth2 클라이언트 구성, 데이터베이스(로컬에서는 SQLite)와 임시 파일 전송을 위한 스토리지 권한이 런타임 운영에 요구된다.
이미지 분석


1k
Stars
49
Forks
+212
Trending
0
조회수
관련 토론
아직 관련 토론이 없습니다.
댓글
댓글을 작성하려면 로그인이 필요합니다.