UnifAPI가 OOMOL의 오픈소스 OpenConnector에 내장되었습니다. 워크스페이스 키로 한 번 연결해 팀과 공유하고, 읽기와 OAuth 쓰기를 함께 쓰세요.

한마디로: UnifAPI는 이제 OOMOL의 오픈소스 OpenConnector에 포함된 네이티브 provider로, 우리의 공개 데이터 카탈로그 전체 — 16개 플랫폼 모두 — 를 타입이 지정된, 호출 가능한 Actions로 미러링합니다. 관리자 한 명이 워크스페이스 API 키로 UnifAPI를 한 번 연결하면, 회사 전체가 그 공유 연결을 통해 실시간 공개 데이터를 읽습니다 — OOMOL이 이미 중개하는 OAuth 쓰기 도구 바로 옆에서 말입니다. 오프보딩은 OOMOL에서 클릭 한 번이면 끝납니다 — UnifAPI 쪽에서 로테이션할 것이 아무것도 없습니다.

에이전트 통합은 언제나 두 절반으로 나뉘어 왔습니다. 한 절반은 비공개입니다: 사용자 자신의 Gmail, Notion, Linear, Slack — 그 사용자만이 인가할 수 있는 데이터, 대개 OAuth를 통해, 대개 쓰기 권한과 함께. 다른 절반은 공개입니다: 게시물, 프로필, 동영상, 스레드, 순위, SERP — 브라우저를 가진 누구나 읽을 수 있는 근거, 바로 UnifAPI 제품의 전부입니다.

지금까지 팀들은 그 두 절반을 따로 배선했습니다: OAuth 도구에는 커넥터 플랫폼을, 공개 데이터에는 직접 키나 MCP 연결을, 그리고 "누가 접근 권한을 갖고 있고, 어떻게 회수하는가?"에는 서로 다른 두 개의 답을. 오늘 우리는 그 간극을 닫습니다. UnifAPI가 OOMOL의 OpenConnector에 내장 provider로 포함되어, 공개 데이터 절반과 OAuth 절반이 하나의 게이트웨이, 하나의 카탈로그, 하나의 팀 관리 표면 뒤에 함께 있게 됩니다.

OOMOL은 누구인가

OOMOL은 에이전트와 그것을 운영하는 팀을 위한 통합 인프라를 만듭니다. Composio와 비교해 봤다면 방향은 맞습니다 — 에이전트와 서드파티 서비스 사이의 인증을 중개하는 커넥터 게이트웨이 — 하지만 OOMOL은 특이한 방향에서 그 지점에 도착했고, 그 우회로가 제품에 고스란히 드러납니다.

이 회사는 2025년 중반 Hacker News에 OOMOL Studio로 처음 모습을 드러냈습니다. local-first, code-first(로컬 우선, 코드 우선) 워크플로 자동화 엔진으로 소개된 제품입니다. Zapier와 n8n이 사전 구축된 노드의 캔버스와 그 밖의 모든 것을 위한 비좁은 표현식 상자를 준다면, Studio는 VS Code 기반 위에 만들어졌습니다: 워크플로의 모든 블록이 컨테이너 안에서 실행되는 실제 Python 또는 Node.js 코드라서 서드파티 라이브러리가 어떤 머신에서든 동일하게 동작합니다. 캔버스 아래에는 Rust로 구현된 워크플로 엔진 OOCANA가 있어, 순수 YAML 파일로 선언된 플로와 블록을 스케줄링합니다. Blocks와 워크플로 템플릿은 공유 가능하므로, 팀은 노드 그래프의 스크린샷 대신 작동하는 조각들의 라이브러리를 축적하게 됩니다.

그 코어 주위로 에코시스템은 에이전트 인프라가 으레 성장하는 방식으로 자라났습니다: 에이전트가 게시된 도구를 검색하고, 검사하고, 실행하게 해주는 커맨드라인 릴레이인 oo CLI; 지속적 배포와 관리형 구성이 필요한 워크플로를 위한 호스팅 런타임인 OOMOL Cloud; 그리고 계정을 한 번 연결하면 자연어로 그 계정들을 넘나들며 일할 수 있는 데스크톱 앱인 Wanta.

이 모든 것을 잇는 결합 조직이 바로 OpenConnector — UnifAPI가 이제 꽂히는 그 조각입니다.

OpenConnector 들여다보기

OpenConnector는 Apache-2.0 오픈소스 커넥터 게이트웨이입니다. 태그라인은 "Connect Once. Use Everywhere."(한 번 연결하고, 어디서나 사용)이고, 문자 그대로의 의미입니다: 계정을 한 번 연결하면, 1,000개 이상의 provider와 9,400개 이상의 사전 구축된 Actions로 이루어진 공유 카탈로그가 팀이 사용하는 어떤 표면에서든 호출 가능해집니다 — 앱 코드에서는 TypeScript SDK, 로컬 에이전트 릴레이로는 oo CLI, 에이전트 호스트에서는 MCP, 커스텀 클라이언트에서는 순수 HTTP/OpenAPI, 그리고 관리와 디버깅을 위한 Web Console.

이어지는 이야기에는 두 가지 설계 결정이 중요합니다.

첫째, 모든 Action은 검사 가능한 계약입니다: 요청/응답 스키마, 필요한 스코프, 그리고 실행기 소스 자체까지 모두 읽을 수 있습니다. 에이전트가 호출하기 전에 그 Action이 무엇을 하는지 감사할 수 있습니다 — 우리가 OpenAPI에서 취하는 "마케팅이 아니라 계약을 읽어라"와 같은 자세입니다.

둘째, 자격 증명은 그것을 사용하는 에이전트와 아키텍처 차원에서 분리되어 있습니다. API 키와 OAuth 토큰은 저장 시 봉인되고(AES-256-GCM), 에이전트는 서버 측 흐름을 통해 호출할 뿐 원시 비밀 값을 결코 보지 못하며, 허용/차단 정책이 각 소비자가 호출할 수 있는 Actions의 범위를 지정하고, 모든 호출은 감사 기록 — 행위자, 스코프, 타임스탬프, 결과 — 을 남기며 실행 로그의 출력은 마스킹됩니다. 궤도를 벗어난 에이전트는 정책 계층에서 차단할 수 있습니다; 애초에 키를 쥔 적이 없으니까요.

이것이 기계 장치입니다. 이제 UnifAPI가 왜 그 안에 속하는지 이야기하겠습니다.

눈과 손이 만나다

UnifAPI의 포지셔닝은 첫날부터 일관됐습니다: eyes, not hands(손이 아니라 눈). 우리는 공개 데이터 — TikTok, LinkedIn, Instagram, YouTube, Twitter/X, Threads, Reddit, Hacker News, 뉴스, SEO와 GEO 시그널, 지도와 로컬 리스팅 — 를 읽고, 하나의 봉투로 정규화하며, 당신의 게시 자격 증명을 절대 보유하지 않습니다. 리서치, 모니터링, 감사, 단가 산정: 읽기입니다.

OOMOL의 카탈로그는 정반대의 절반에서 가장 강합니다. 그 1,000개 이상의 provider 대부분은 비공개 SaaS로 향하는 OAuth — 손입니다. 그 연결은 에이전트가 사용자가 실제로 소유한 계정 안에서 행동하게 합니다: Slack 메시지 보내기, Notion 페이지 업데이트, Linear 티켓 제출, 이메일 초안 작성.

그래서 각자의 빈틈이 상대방의 제품이 되었습니다. 쓰기 도구로 가득한 커넥터 게이트웨이에도 여전히 행동의 근거가 될 증거가 필요한데, 실시간이고 정규화되어 있으며 법적으로 신중한 공개 데이터 계층을 만드는 일은 기능이 아니라 전업 제품입니다. 공개 데이터 계층에도 발견 사항이 착지할 곳이 필요한데, 수백 개의 SaaS 앱으로 OAuth를 중개하는 일 역시 누군가의 전업입니다. 둘을 같은 게이트웨이 뒤에 놓으면, 어느 쪽도 자기 모델을 타협하지 않은 채 루프가 닫힙니다:

"이번 주 우리 출시에 대해 TikTok 크리에이터들이 무슨 말을 했는지 찾아라" → UnifAPI, 공개 읽기.

"다이제스트를 #marketing에 게시하고 후속 작업을 Linear에 등록하라" → OOMOL의 OAuth 연결, 비공개 쓰기.

당신의 어시스턴트는 둘 다 하나의 카탈로그를 통해 호출합니다. UnifAPI는 여전히 당신의 비공개 계정을 절대 건드리지 않고 — 그 경계는 우연이 아니라 하중을 받치는 구조입니다 — OOMOL은 공개 데이터 계층을 유지할 필요가 없습니다. 읽기는 그것을 실시간으로, 정규화된 상태로, 레코드당 가격으로 유지하는 일만 하는 provider에게서 오니까요.

키 하나로, 회사 전체가

우리가 가장 기대하는 부분은 OOMOL의 팀 계층이 UnifAPI 온보딩에 가져오는 변화입니다.

UnifAPI API 키는 하나의 Workspace에 속하고 그 워크스페이스의 credits를 소비합니다. 이 파트너십 이전에는, 키를 회사 전체에 공유한다는 것은 키 공유가 늘 의미하던 바로 그것이었습니다: 볼트나 env 파일에 붙여넣고, 랩톱이나 노트북 파일이나 저장소로 새어 나가지 않기를 바라며, 누군가 떠날 때마다 로테이션하고 — 그다음 옛 키가 캐시된 모든 곳을 추적해 다니는 것.

OOMOL을 통하면 팀 자격 증명이 마땅히 작동해야 하는 방식으로 작동합니다:

관리자 한 명이 UnifAPI 콘솔에서 키를 만들고 OOMOL에 UnifAPI 연결로 저장합니다 — 단 한 번. 팀의 모든 사람이 그 공유 연결을 통해 UnifAPI를 호출합니다 — Studio 워크플로에서, oo CLI나 MCP 뒤의 에이전트에서, SDK를 쓰는 백엔드 코드에서. 원시 키는 절대 돌아다니지 않습니다; 팀원들은 연결을 이름으로 참조하고 비밀 값은 게이트웨이 안에 봉인된 채 머뭅니다. 허용/차단 정책이 각 소비자가 호출할 수 있는 Actions를 결정하고 — 애널리스트의 리서치 에이전트는 TikTok과 Reddit을 읽을 수 있지만, 인턴의 실험은 SEO 엔드포인트를 건드릴 수 없습니다 — 감사 추적은 어떤 시스템이 어떤 연결을 무엇에 사용했는지 보여줍니다.

그리고 누군가 떠나면, OOMOL에서 그 사람의 접근을 제거합니다. 그게 전부입니다. 키 로테이션도, 재배포도, UnifAPI 쪽 변경도 전혀 없습니다 — 워크스페이스 키는 애초에 그 사람 손에 있었던 적이 없으니까요. 사용량은 계속 같은 UnifAPI 워크스페이스로 흘러들어, 과금은 하나의 잔액, 하나의 원장, 레코드당 가격으로 유지됩니다.

모든 UnifAPI 플랫폼이, 타입이 지정된 Actions로

이것은 로고 교체도, 엔드포인트 세 개를 감싼 얇은 래퍼도 아닙니다. OpenConnector의 UnifAPI provider는 우리 카탈로그를 플랫폼 대 플랫폼으로 미러링합니다: TikTok, Twitter/X, Instagram, YouTube, LinkedIn, Threads, Reddit, Hacker News, 뉴스, SEO, GEO, 지도, 로컬, 호텔, 이벤트, 그리고 렌더링된 브라우저 페치 — unifapi.com/apis 뒤에 있는 것과 동일한 16개 플랫폼과 220개 오퍼레이션이, 에이전트가 호출 전에 검사할 수 있는 입력·출력 스키마를 갖춘 타입 지정 Action으로 각각 생성됩니다.

Actions가 손으로 작성된 것이 아니라 타입이 지정된 오퍼레이션 정의에서 생성되기 때문에, provider는 우리의 OpenAPI 표면을 따라갑니다: 카탈로그가 늘어나면 커넥터도 함께 늘어납니다. 그리고 과금은 이동 중에 형태가 바뀌지 않습니다 — OOMOL을 통한 호출은 직접 HTTP나 MCP 사용과 동일한 레코드당 가격으로 UnifAPI 워크스페이스 credits를 소비하며, 모든 응답에 동일한 billing 메타데이터가 담깁니다.

오픈소스, 셀프호스팅 가능

OpenConnector는 Apache 2.0이고, UnifAPI provider는 공개 카탈로그에 포함되어 출시됩니다 — provider 소스를 직접 읽어볼 수 있습니다: API 키 인증을 표준 Bearer 헤더로 전송하고, 액션은 플랫폼별로 생성됩니다.

이것이 중요한 이유는, 위의 팀 이야기가 호스팅된 블랙박스에 대한 신뢰를 요구하지 않기 때문입니다. 게이트웨이 전체를 당신이 통제하는 인프라에서 운영할 수 있고 — Docker나 Node.js로 로컬에서, 영속 SQLite와 함께 Fly.io에서, 또는 D1과 R2를 갖춘 Cloudflare Workers에서 — 동일한 provider 카탈로그와 Action 계약을 그대로 얻습니다. OOMOL의 호스팅 런타임은 같은 인터페이스를 가진 제로옵스 경로이므로, 호스팅으로 시작해 나중에 셀프호스팅으로 옮기더라도(혹은 그 반대라도) 통합 코드는 바뀌지 않습니다.

자격 증명을 서드파티 SaaS로 라우팅하는 것에 보안 검토가 난색을 표할 팀에게, 이것은 "흥미롭다"와 "승인됨"의 차이입니다: 자격 증명 저장소, 정책 엔진, 감사 로그가 모두 당신 자신의 경계 안에 있을 수 있습니다.

OOMOL을 통해 UnifAPI 연결하기

설정은 의도적으로 심심하게 만들었습니다:

UnifAPI 콘솔에 로그인하고 워크스페이스 API 키를 만듭니다(한 번만 표시되며, unif_ 접두사가 붙습니다).
OOMOL에서 UnifAPI 연결을 추가하고 키를 붙여넣습니다. 그다음부터는 OpenConnector가 Authorization: Bearer 헤더를 처리합니다.
팀이 일하는 어디에서든 UnifAPI 오퍼레이션을 호출합니다 — Studio 워크플로, oo CLI, MCP로 연결된 어시스턴트, 또는 백엔드 코드의 SDK.

Claude나 Codex에서 Skills를 실행하는 개인 운영자라면, unifapi.com/mcp의 직접 경로가 여전히 3분 설정입니다. OOMOL은 UnifAPI를 팀 유틸리티로 만드는 경로입니다: 공유 연결, 범위가 지정된 정책, 감사 추적, 클릭 한 번의 오프보딩.

이것이 닫는 세 가지 루프

예전에는 통합 프로젝트 두 개가 필요했지만 이제 게이트웨이 하나로 끝나는 워크플로 몇 가지:

소셜 리스닝, 처음부터 끝까지. 워크플로가 UnifAPI를 통해 Reddit, TikTok, Twitter/X 전반의 브랜드 언급을 읽고, Python 블록에서 점수를 매긴 뒤, OAuth 연결을 통해 팀 Slack에 아침 다이제스트를 게시합니다 — 읽기는 공개, 쓰기는 비공개, 카탈로그는 하나, 감사 추적도 하나.

증빙이 따라다니는 인플루언서 마케팅. 워크플로가 공개 참여 데이터로 크리에이터를 추리고 KOL 단가를 산정한 뒤, 인용된 공개 근거와 함께 후보 목록을 검토용으로 팀의 Notion 워크스페이스에 기록합니다. 재무팀이 숫자의 출처를 물으면, 실행 로그가 대답합니다.

스스로 티켓을 등록하는 경쟁 인텔리전스. 예약된 워크플로가 경쟁사의 공개 출시, 스레드, 순위를 지켜보고, 실행 가능한 것은 무엇이든 팀 트래커에 티켓으로 만들며, 각 티켓은 공개 소스로 다시 링크됩니다.

모든 경우에 경계는 깨끗하게 유지됩니다: UnifAPI는 인용 가능한 공개 근거를 공급하고, OOMOL을 통해 인가된 사용자 자신의 계정이 행동을 수행합니다.

더 큰 그림

에이전트는 작년 어느 시점엔가 혼자 쓰는 도구이기를 멈췄습니다. 워크플로가 공유되는 순간 — 팀 Slack 다이제스트, 회사 리서치 파이프라인, 예약된 감사 — 질문은 "어떤 모델?"에서 "누가 무엇을, 누구의 자격 증명으로 호출할 수 있고, 그 사람이 떠나면 어떻게 되는가?"로 바뀝니다. 이것은 게이트웨이의 질문이고, 커넥터 게이트웨이가 에이전트 스택의 독립된 계층이 된 이유입니다.

우리의 답은 두 부분입니다. 공개 데이터 절반에서 UnifAPI는 지금 그대로를 유지합니다: 키 하나, 봉투 하나, 레코드당 가격, 설계상 읽기 전용. 팀 절반에서는, 게이트웨이의 그림자 복제본을 만들기보다 열려 있고 검사 가능한 게이트웨이와 통합하는 쪽을 택하겠습니다. OOMOL의 OpenConnector가 정확히 그것입니다 — 오픈소스이고, 셀프호스팅 가능하며, 우리 고객에게 자신 있게 가리킬 수 있는 보안 모델을 갖췄습니다.

한 번 연결하면, 회사 전체가 공개 웹을 읽습니다.

다음에 읽을 것

UnifAPI vs Composio - 이 파트너십의 토대가 된 두 절반 프레이밍.

UnifAPI MCP 연결하기 - 개인 운영자를 위한 직접 MCP 경로.

최소 기능 에이전트 스택 - 커넥터 게이트웨이와 공개 데이터 계층이 하나의 아키텍처 안에서 자리하는 위치.