OpenConnector, Composio, Nango, Pipedream: 어디까지 오픈 소스일까요?

AI Agent를 Gmail, Notion, Slack에 연결해 처음 작업을 성공시키면 활용 범위가 넓어집니다. 질문에 답하던 도우미가 메일을 찾고 문서를 수정하며 실제 업무를 처리하기 시작합니다.

계속 사용하다 보면 더 구체적인 질문이 생깁니다. 필요한 작업이 없으면 직접 추가할 수 있을까요? 요청이 실패하면 어디까지 확인할 수 있을까요? 고객이 인증 정보를 사내 환경에 보관하도록 요구하면 연결 서비스도 옮길 수 있을까요?

이때부터 공개된 코드의 범위와 직접 운영할 수 있는 부분이 중요해집니다. OpenConnector, Composio, Nango, Pipedream은 모두 앱 연동에 사용할 수 있지만, 공개 코드와 배포 방식, 라이선스는 서로 다릅니다.

어떤 부분의 코드가 공개되어 있나요?

SDK, 커넥터, 런타임은 서로 다른 역할을 담당합니다.

• SDK는 매개변수를 구성해 요청을 보내고 결과를 받습니다. 소스를 보면 클라이언트의 호출 방식을 확인할 수 있습니다.
• 커넥터 실행 코드는 작업을 외부 API 요청으로 바꾸고 매개변수와 응답을 처리합니다. 이 부분이 공개되어 있으면 구현을 검토하고 확장할 수 있습니다.
• 커넥터 런타임은 작업을 실행하며 인증 정보, 권한, 실행 기록 등을 관리합니다. 소스와 배포 방법이 공개되어 있어야 팀이 이 부분을 직접 운영할 수 있습니다.

그림 1. 커넥터 실행 코드는 런타임 안에서 동작합니다. 실제 구현은 제품마다 다릅니다.

SDK가 공개되어 있다는 사실만으로 게이트웨이 소스도 공개되어 있다고 판단할 수는 없습니다. 커넥터 코드를 수정할 수 있는지와 플랫폼 전체를 직접 배포할 수 있는지도 따로 확인해야 합니다.

네 제품 비교

제품	주요 공개 코드	자체 호스팅	확인할 범위
OpenConnector	Connector SDK, oo CLI, 게이트웨이, provider 정의, 작업 실행 코드, Web Console	Docker와 Node.js 공개 배포 방법, Cloudflare 지원	핵심 저장소는 Apache-2.0, SDK와 CLI는 MIT. 작업별 실행 코드와 인증 요건 확인 필요
Composio	공개 기본 저장소에 SDK, CLI, 프레임워크 어댑터 포함	기업용 자체 호스팅 및 비공개 환경 배포 제공	SDK 저장소의 MIT 라이선스를 게이트웨이 구현에 그대로 적용할 수는 없음
Nango	연동 플랫폼 소스와 연동 함수 코드	무료 및 Enterprise 자체 호스팅	기본 저장소는 Elastic License 2.0. 무료 자체 호스팅은 기능이 제한됨
Pipedream	컴포넌트 코드, 문서, 관련 패키지	일반적으로 Pipedream 호스팅 환경에서 실행	기본 저장소는 Source Available. 컴포넌트 공개가 플랫폼 전체의 자체 배포를 뜻하지는 않음

출처: OpenConnector, Composio 저장소, Composio 배포 방식, Nango 자체 호스팅, Pipedream 컴포넌트.

필요한 provider가 아직 없다면

팀에서 새 고객 관리 시스템을 도입했다고 가정해 보겠습니다. Agent가 고객을 조회하고 후속 대응 기록을 수정해야 하지만, 기존 목록에는 이 서비스가 없습니다.

사용자에게 유용한 확장 지점은 게이트웨이에 provider를 추가하는 것입니다. 새 서비스의 인증 방식, 작업 매개변수, 실행 로직을 정의하면 됩니다. SDK와 CLI는 기존 호출 방식을 사용하므로 일반적으로 그 소스를 수정할 필요가 없습니다.

OpenConnector에서는 세 가지 방법을 선택할 수 있습니다.

• 직접 구현: 자체 게이트웨이에 provider를 추가하고 업무 일정에 맞춰 사용합니다.
• PR 제출: 구현을 프로젝트에 기여해 다른 사용자도 서비스를 연결할 수 있게 합니다.
• issue 등록: 필요한 서비스와 작업을 설명하면 저희 팀이 지원을 추가할 수 있습니다.

이러한 provider나 작업 추가 요청은 보통 24~36시간 안에 관련 기능을 병합합니다. 이는 팀의 일반적인 처리 속도이며, API 복잡도, 테스트 계정, 외부 서비스의 인증 조건에 따라 달라질 수 있습니다.

목록에 없는 서비스도 연동을 진행할 수 있는 길이 있습니다. 직접 구현하거나 유지보수 팀과 협력하면서 기존 호출 도구를 그대로 활용할 수 있습니다. provider 기여 안내 · 요청 등록

OpenConnector의 공개 코드에는 Connector SDK, oo CLI, 게이트웨이, 작업 정의와 실행 코드, Web Console이 포함됩니다. 앱 코드는 SDK를, 명령줄은 oo connector를, 호환 Agent는 MCP를 사용할 수 있으며 HTTP/OpenAPI로도 접근할 수 있습니다. SDK와 CLI 모두 OOMOL 호스팅 서비스와 자체 런타임에 연결됩니다. 개발자 도구

코드는 OpenConnector, Connector SDK, oo CLI 저장소에서 관리합니다. 팀은 클라이언트부터 실행까지 살펴보고, 자체 환경에서 연결 계정과 작업 권한, 민감 정보를 가린 실행 기록을 관리할 수 있습니다.

그림 2. 공식 저장소의 영문 화면입니다. 이름과 수치는 촬영 당시 버전을 보여 주며 현재 지원 규모를 보장하지 않습니다.

provider를 추가한 뒤에도 앱과 Agent는 같은 진입점을 사용합니다. 실제 도입 전에는 필요한 작업의 실행 코드가 있는지, 입력이 업무 요건을 충족하는지, 외부 서비스의 인증을 완료할 수 있는지 확인해야 합니다.

Composio의 공개 기본 저장소는 Python과 TypeScript SDK, CLI, 어댑터를 담은 SDK monorepo입니다. 클라이언트 동작을 확인하는 데 도움이 되지만 게이트웨이 내부 구현의 공개 여부까지 입증하지는 않습니다. Composio 저장소

Composio는 기업용 자체 호스팅과 비공개 환경 배포를 제공합니다. 따라서 클라우드에서만 쓸 수 있다고 설명하면 부정확합니다. 공개 소스로 시작할 수 있는 범위, 기업 계약이 필요한 범위, 배포 후 수정 가능한 부분을 구분해 비교해야 합니다. Composio MCP Gateway

Nango는 플랫폼 소스를 공개하며 자체 호스팅을 지원합니다. 무료 버전은 주로 인증과 API 프록시를 제공하고, 함수, 동기화, Webhook, MCP 등 전체 기능은 Cloud 또는 Enterprise 자체 호스팅에서 확인해야 합니다. Nango 설명

Pipedream에서는 컴포넌트 구현을 읽고, 직접 작성하고, PR로 기여할 수 있습니다. 다만 컴포넌트는 일반적으로 Pipedream의 서버리스 인프라에서 실행됩니다. 작업을 편집하는 능력과 기반 플랫폼 전체를 운영하는 능력은 별개입니다. Pipedream 문서

공개 코드에도 사용 조건이 있습니다

GitHub에서 소스를 볼 수 있어도 라이선스의 허용 범위는 같지 않습니다.

코드 범위	공개 라이선스
OpenConnector 핵심 저장소	Apache-2.0
Connector SDK	MIT
oo CLI	MIT
Composio 공개 SDK 저장소	MIT
Nango 기본 저장소	Elastic License 2.0
Pipedream 기본 저장소	Pipedream Source Available License

포크를 유지하거나 코드를 재배포하거나 이를 바탕으로 외부 서비스를 제공하려면 관련 조항을 먼저 확인해야 합니다. OpenConnector 라이선스는 프로젝트 자체 코드에 적용되며, 외부 API 약관이나 인증 요건, 브랜드 권리를 대체하지 않습니다.

직접 운영하면 유지보수도 맡게 됩니다

자체 배포에서는 런타임 상태, 최근 실패, 실행 기록을 살펴보고 설정이나 코드의 변경 여부를 결정할 수 있습니다.

그림 3. 공식 저장소의 화면 예시입니다. 표시된 통계는 현재 규모나 신뢰성 지표가 아닙니다.

대신 업그레이드, 백업, 키 관리, 인프라 운영과 일부 서비스의 OAuth 앱 등록을 담당해야 합니다. 제어할 수 있는 범위가 넓어지는 만큼 유지보수 책임도 생깁니다.

SaaS로 시작하고 성장에 맞춰 이전하기

OOMOL SaaS와 오픈 소스 OpenConnector는 커넥터 호출 계층에서 같은 구조를 사용합니다. provider ID, 작업 ID, 매개변수 계약이 같으므로 OOMOL 환경이든 자체 서버든 같은 작업 호출 규칙을 활용할 수 있습니다. 사용 방식

처음에는 SaaS를 사용하고, 사업 규모가 커지거나 고객이 자체 환경을 요구하면 OpenConnector를 배포한 뒤 SDK와 CLI의 연결 주소를 바꿀 수 있습니다. 지원되는 작업 호출과 입력을 재사용하므로 해당 연동을 처음부터 다시 구현할 필요가 없습니다.

진입점	자체 호스팅 전환 설정	재사용할 수 있는 부분
Connector SDK	OpenConnector 클라이언트에 자체 baseUrl과 런타임 토큰 설정	지원되는 작업 ID, 입력, execute 등의 호출 방식
oo CLI	OO_CONNECTOR_URL과 필요시 OO_CONNECTOR_TOKEN 설정	search, schema, run 등 커넥터 명령과 작업 입력

자세한 설정은 SDK 안내와 CLI 안내에 있습니다.

새 환경에는 외부 계정 연결, OAuth 앱, 인증 정보를 설정해야 합니다. SaaS의 팀 관리, 프로젝트 사용자, 다른 호스팅 기능을 사용한다면 지원 범위를 별도로 확인해야 합니다. 공통 구조는 커넥터 호출의 재사용을 돕지만 모든 계정과 기능을 자동으로 이전하지는 않습니다.

평가할 때는 자주 쓰는 작업을 SaaS에서 실행한 뒤, 같은 SDK나 CLI를 자체 인스턴스에 연결해 같은 작업과 입력을 시험해 보세요. 없는 서비스가 있다면 provider 추가나 issue 등록 과정도 확인할 수 있습니다.

빠르게 연동하면서 자체 운영 가능성도 남겨 두려는 팀은 OOMOL에서 앱을 연결하거나 자체 배포 안내에 따라 인스턴스를 만들고 일상적인 작업부터 검증할 수 있습니다.

---

브랜드 이미지와 제품 화면은 각 프로젝트의 공식 사이트 또는 저장소에서 가져왔으며 식별과 비교에 사용했습니다. 권리는 각 권리자에게 있습니다. 개념도는 이 글을 위해 제작했습니다.