OpenConnector를 직접 운영할까, OOMOL 호스팅을 쓸까? 먼저 업무를 연결하세요

Google, Zoom, monday.com을 애플리케이션이나 에이전트에 연결하려고 할 때, OpenConnector가 오픈 소스이니 자체 게이트웨이를 배포해 볼까 생각할 수 있습니다.

자체 게이트웨이에는 분명한 가치가 있습니다. 인증 정보를 어디에 저장할지, 어떤 작업을 허용할지, 호출을 어떻게 기록할지 직접 결정할 수 있습니다. 하지만 서비스를 실행한 뒤에도 쉽게 과소평가하는 일이 남습니다. 각 앱의 인증 설정을 준비하는 일입니다.

빠르게 기능을 출시하려는 대부분의 팀에는 OOMOL 호스팅으로 시작해 SDK로 업무를 연동하는 방식을 권합니다. 연결 서비스와 인증 정보를 자체 인프라에 두어야 하거나 게이트웨이 및 커넥터 구현을 수정해야 한다면 OpenConnector를 직접 운영하세요.

단계적으로 진행할 수도 있습니다. 호스팅으로 업무 연동을 먼저 구현하면서 자체 OAuth 앱을 준비하고, 준비가 끝나면 이전하는 방식입니다.

지금 필요한 것부터 살펴보세요

현재 요구 사항	권장 선택
앱을 빨리 연결하고 싶고 외부 호스팅을 사용할 수 있음	OOMOL 호스팅으로 시작
연결을 공유하고 멤버 접근 권한과 허용 작업을 한곳에서 관리해야 함	OOMOL 호스팅의 팀 기능 사용
자체 OAuth 앱을 쓸 계획이지만 설정이나 심사가 진행 중임	호스팅으로 시작하고 준비 후 이전 검토
인증 정보, 연결 게이트웨이, 실행 기록을 자체 인프라에 보관해야 함	OpenConnector 자체 운영
커넥터 코드 수정, 게이트웨이 맞춤 설정, 외부로 나가는 네트워크 연결 제어가 필요함	OpenConnector 자체 운영

기업 규모도 선택에 영향을 줍니다. 더 직접적인 질문은 팀에 어느 정도의 관리 권한이 필요한지, 얼마나 많은 유지보수를 맡을 준비가 되어 있는지입니다.

자체 운영은 OAuth 설정부터 시작되는 경우가 많습니다

Docker로 OpenConnector를 실행하면 연결 게이트웨이가 준비됩니다. OAuth 승인이 필요한 서비스에 접근하려면 각 서비스의 개발자 콘솔에서 자체 OAuth 앱도 만들어야 합니다.

서로 다른 두 가지 인증 정보를 구분해야 합니다. OAuth 앱의 Client ID와 Client Secret은 애플리케이션을 식별합니다. 사용자가 계정 접근을 승인한 뒤 발급되는 액세스 토큰은 사용자가 허용한 리소스에 접근하는 데 쓰입니다.

앞의 정보는 미리 준비하고, 토큰은 계정 승인 과정에서 발급받습니다.

Google의 경우 프로젝트 생성, 필요한 API 활성화, OAuth 클라이언트 생성, 콜백 URL 등록, 요청할 권한 선택 등이 필요합니다. 권한 범위와 사용 방식에 따라 앱 검증도 필요할 수 있습니다. Google OAuth 공식 문서

다른 OAuth 서비스에도 각각의 설정과 배포 규칙이 있습니다. 하나를 연결할 때는 감당하기 쉬워도 여러 앱을 연결하면 클라이언트 설정, 콜백 URL, 권한 범위와 심사 상태를 따로 유지해야 합니다.

내부 테스트와 다수 고객 대상 제공의 요구 사항도 다를 수 있습니다. 자체 계정이나 테스트 사용자부터 연결할 수 있는 서비스가 있는 반면, 특정 용도에는 관리자 승인이나 추가 심사가 필요한 서비스도 있습니다. 서비스 제공자의 콘솔과 문서를 확인하세요.

OpenConnector는 OAuth 설정 저장, 계정 연결, 작업 실행을 제공합니다. 자체 OAuth 앱을 사용할 때는 앱 생성과 제공자 요구 사항 충족을 팀이 맡아야 합니다. 자세한 절차는 OAuth 앱 설정 가이드를 참고하세요.

호스팅으로 업무 연동에 시간을 쓰세요

일정 조회, 이메일 정리, 프로젝트 기록 갱신 같은 기능을 출시하는 것이 당장의 목표라면 필요한 연결을 먼저 구현할 수 있습니다.

관리형 OAuth 앱을 지원하는 연동에서는 OOMOL이 제공자별 앱 생성과 유지보수 부담을 줄여 줍니다. 사용자는 여전히 자신의 계정을 연결하고 필요한 권한을 승인해야 합니다. API key나 다른 인증 방식을 쓰는 서비스에도 해당 설정을 제공해야 합니다.

계정 연결 후에는 OOMOL 호스팅이 인증 정보 저장, 토큰 갱신, 실제 앱 호출을 담당합니다. 백엔드는 SDK로 연결을 선택하고 매개변수를 보내 결과를 받습니다. 제공자의 원본 토큰을 업무 코드나 에이전트 프롬프트에 넣을 필요가 없습니다. 호스팅 Connector 가이드

그림: 두 배포 방식의 호출 관계. 게이트웨이 위치와 관리 책임은 달라지지만, 외부 앱 접근에는 제공자의 승인과 네트워크 연결이 필요합니다.

여러 사람이 사용할 때는 팀 관리 기능도 유용합니다. 관리자가 멤버를 관리하고 각 연결에 허용되는 작업을 설정한 다음, 사용할 수 있는 멤버를 지정합니다.

예를 들어 같은 이메일 계정에 연결을 두 개 만들 수 있습니다. 하나는 읽기만 허용해 정보를 확인해야 하는 멤버에게 배정합니다. 다른 하나는 발송을 허용해 외부 소통 담당자에게만 배정합니다. 멤버는 승인된 작업을 사용하고 메일 계정의 원본 액세스 토큰은 받지 않습니다. 팀 및 연결 권한 설명

앱이 늘어나도 누가 무엇을 사용할 수 있는지 관리할 수 있습니다. 특정 데이터 접근은 원래 앱 계정의 권한과 승인 범위에도 제한됩니다.

제품의 각 최종 사용자가 자기 계정을 연결해야 한다면 호스팅 측에서는 Connector for SaaS와 ProjectConnector 클라이언트를 사용해 사용자별 연결을 분리하세요.

실행 환경을 직접 관리해야 한다면 OpenConnector를 선택하세요

처음부터 요구 사항이 명확한 팀도 있습니다. 인증 정보를 자체 키와 저장소로 보호하고, 게이트웨이를 기업 네트워크에서 실행하며, 실행 기록을 내부 규칙대로 보관해야 하는 경우입니다.

이런 요구 사항이 배포 방식을 결정합니다. OpenConnector를 직접 운영하면 게이트웨이, 인증 정보, 작업 정책, 실행 기록뿐 아니라 데이터베이스, 백업, 업그레이드, 네트워크 접근도 관리할 수 있습니다.

오픈 소스의 가치에는 코드에 대한 관리 권한도 포함됩니다. 연결 런타임, 커넥터 정의, 작업 실행 코드, 웹 콘솔의 소스가 공개되어 있으며 Connector SDK와 oo CLI도 오픈 소스입니다. 호출 과정을 검토하거나 연동을 추가하고 구현을 수정할 때 기존 프로젝트에서 시작할 수 있습니다. 외부 서비스의 API 승인 요구 사항과 이용 약관은 별도로 준수해야 합니다.

관리 권한에는 유지보수 책임도 따릅니다. 키 관리, 접근 보호, 업데이트, 백업, 장애 대응을 담당할 사람이 필요합니다. 보안은 이러한 작업을 어떻게 수행하는지에 달려 있습니다.

환경에 맞는 배포 방식을 선택하세요.

• Docker Compose: 자체 서버나 기업 네트워크에서 실행하며 저장소와 접근 범위를 직접 관리합니다.
• Cloudflare Workers: D1, R2 등 Cloudflare 인프라를 활용해 OpenConnector 배포를 직접 관리합니다. 클라우드 실행 환경을 사용할 수 있는 팀에 적합합니다.
• 소스 코드에서 실행: 커넥터 개발, 디버깅, OpenConnector 수정에 적합합니다.

Cloudflare는 클라우드 배포 방식입니다. 반드시 기업 내부망에서 실행해야 한다면 그 요구를 충족하는 서버 환경을 선택해야 합니다.

내부망 게이트웨이에도 필요한 외부 연결을 계획해야 합니다. Google, Zoom 같은 외부 SaaS를 호출하려면 해당 API와 승인 엔드포인트에 접근해야 합니다. 외부 네트워크와 완전히 분리된 환경에서는 대상 서비스에 접근 가능한 내부 인터페이스가 있는지 먼저 확인하세요.

배포 절차는 OpenConnector 자체 운영 가이드에 있습니다.

호스팅으로 시작하고 준비가 끝나면 이전하세요

자체 OAuth 앱을 쓸 계획이지만 설정이나 심사가 끝나지 않았다면 두 작업을 함께 진행할 수 있습니다. 호스팅으로 업무 연동을 검증하면서 자체 운영에 필요한 인증 정보와 환경을 준비하세요.

두 방식은 같은 @oomol-lab/connector SDK 패키지를 사용합니다. 호스팅 연결용 Connector, 제품 최종 사용자용 ProjectConnector, 자체 운영 런타임용 OpenConnector가 포함되어 있습니다. 작업 타입과 호출 규약은 공유하지만 인증 방식, 계정 경계, 사용 가능한 메서드는 다릅니다. TypeScript SDK 참고 문서

지원되는 작업의 식별자, 입력 매개변수, 호출 방식을 재사용할 수 있습니다. 이메일 검색 로직은 같은 작업 이름과 검색 조건을 유지한 채 자체 운영 런타임에 연결하는 클라이언트로 실행할 수 있습니다.

이전을 위해 다음을 준비하세요.

1. 새 환경에 OpenConnector를 배포하고 보호하며 자체 OAuth 앱을 설정합니다.
2. 계정 연결을 만들고 필요한 승인 범위를 확인합니다.
3. SDK 클라이언트, 서비스 URL, 런타임 토큰, 연결 선택을 조정합니다.
4. 필요한 작업의 실행 지원과 팀, 프로젝트 사용자, 권한 기능의 지원 범위를 확인합니다.
5. 자주 쓰는 작업 하나를 검증한 뒤 나머지 호출을 단계적으로 전환합니다.

계정 연결과 호스팅 관리 기능은 별도로 처리해야 합니다. 공통 SDK의 장점은 기존 작업 호출과 매개변수 구조를 유지해 각 API를 다시 연동하는 수고를 줄일 수 있다는 점입니다.

이전은 필수 과정이 아닙니다. 호스팅이 계속 업무와 관리 요구를 충족하면 그대로 사용할 수 있습니다. 실행 환경을 직접 관리해야 한다는 구체적인 요구가 생겼을 때 게이트웨이 운영을 맡으세요.

실제 작업 하나부터 시작하세요

지금 자체 운영이 필수는 아니라면 출시하고 싶은 기능을 하나 선택하세요. 오늘의 일정 읽기, 고객 이메일 검색, 프로젝트 진행 상황 조회 등이 될 수 있습니다.

OOMOL Console에서 앱을 연결하고 승인한 뒤 SDK 연동 가이드에 따라 백엔드에서 작업을 호출하세요. 먼저 작동을 확인하고 팀 멤버와 연결 권한을 설정하세요.

자체 운영이 이미 필수라면 OpenConnector 배포 가이드로 환경을 준비하고 OAuth 앱 설정을 완료하세요.

현재 요구에 맞는 시작점을 선택하세요. 호스팅은 업무 연동을 빠르게 구현하도록 돕고, 오픈 소스 OpenConnector는 필요할 때 코드, 인증 정보, 실행 환경을 직접 관리할 수 있게 해 줍니다.