GitHub 추천: ThinkWatchProject/ThinkWatch AI MCP gateway로 AI API와 MCP 서버 접근 통제하기

 

GitHub 추천: ThinkWatch로 AI API와 MCP 서버 접근을 통제하는 법

여러 AI provider와 MCP 서버를 팀에서 쓸 때 확인할 게이트웨이형 통제 도구

 

ThinkWatch는 어떤 문제를 푸는 GitHub 프로젝트인가

 

ThinkWatch는 OpenAI, Anthropic, Gemini, 자체 호스팅 LLM, MCP 서버 접근을 한 게이트웨이에서 통제하려는 Rust 기반 프로젝트입니다. 개인용 API 래퍼라기보다 팀 단위 RBAC, 감사 로그, rate limit, 비용 추적을 묶어 보려는 인프라 도구로 읽어야 합니다.

AI API를 처음 붙일 때는 키 하나와 SDK 하나면 충분해 보입니다. 문제는 팀원이 늘고, OpenAI와 Anthropic을 같이 쓰고, 사내 MCP 서버까지 연결하기 시작할 때 생깁니다. 누가 어떤 모델과 도구를 호출했는지, 비용이 어느 프로젝트에서 발생했는지, 특정 사용자의 권한을 어디까지 열어야 하는지가 금방 흩어집니다.

ThinkWatchProject/ThinkWatch AI MCP gateway GitHub 저장소는 이 지점을 겨냥합니다. 저장소와 공식 사이트는 ThinkWatch를 AI API와 MCP 서버 앞단의 보안 게이트웨이로 설명하며, RBAC, 감사 로그, rate limiting, 예산과 비용 가시성을 앞에 둡니다.

제가 보기에는 이 프로젝트의 추천 포인트가 “새 모델을 더 똑똑하게 쓰는 법”은 아닙니다. 여러 AI 도구를 팀에서 쓰기 시작한 뒤 뒤늦게 생기는 키 관리, 접근 통제, 감사 추적, 비용 책임 문제를 한 프록시 계층에서 정리하려는 시도에 가깝습니다.

 

 

2026년 4월부터 5월까지의 주요 변화

 

ThinkWatch는 2026년 4월 공개 프리뷰 성격으로 등장했고, 5월에는 MCP Gateway와 Responses API 관련 문서화, lifecycle pipeline 및 rate-limit 점검 구조가 이어졌습니다. 타임라인은 프로젝트가 움직이고 있음을 보여주지만, 곧바로 안정 릴리스를 의미하지는 않습니다.

GitHub API 기준 ThinkWatch 저장소는 2026년 4월 2일 생성됐고, 2026년 5월 21일에도 push 기록이 확인됩니다. 브리프의 기준 시점에서는 약 959개 스타, 19개 포크, 0개 오픈 이슈가 확인됐습니다. 다만 스타 수와 이슈 수는 금방 바뀌는 숫자입니다. 저는 이 값을 “성숙도 증명”보다 “관심과 활동의 스냅샷”으로 읽는 편이 맞다고 봅니다.

공식 changelog 흐름도 짧게 보면 방향이 보입니다. 4월에는 OpenAI 호환 프록시, 멀티테넌트 API 키, 기본 관측성, Docker Compose 개발 배포가 언급됐고, 이후 팀 초대, RBAC 조정, 사용자별 예산, provider failover, audit-log streaming이 이어졌습니다. 5월에는 MCP Gateway, 사용자별 MCP credential, token rotation, session-aware lifecycle 관리, Responses 호환 endpoint가 문서화됐습니다.

여기서 볼 부분은 GitHub Releases와 tags입니다. 확인된 API 응답 기준으로 별도 Releases와 tags가 없었기 때문에, ThinkWatchProject/ThinkWatch AI MCP gateway GitHub 저장소는 “패키지화된 안정 릴리스 제품”보다 “빠르게 움직이는 초기 인프라 프로젝트”에 가깝게 다루는 편이 안전합니다.

 

최근 커밋에서 실제로 달라진 점

 

2026-05-20 커밋의 핵심은 요청 lifecycle 단계와 rate limit 점검을 공통 파이프라인으로 옮기는 기반 작업입니다. 다만 해당 커밋만으로 MCP/OpenAI 등 모든 surface가 완전히 연결됐다고 쓰면 과장입니다.

이번 추천의 계기는 2026년 5월 20일 커밋입니다. 커밋은 요청 처리 lifecycle을 공통 모듈로 정리하고, rate limit을 확인하는 단계를 pipeline에 넣는 방향을 보여줍니다. AI gateway에서 이 구조가 중요한 이유는 단순합니다. provider별 handler마다 권한 확인, rate limit, 감사 로그, 비용 기록을 따로 넣으면 정책이 금방 어긋납니다.

> 게이트웨이의 품질은 모델 호출 코드보다 “모든 요청이 같은 검문소를 지나가느냐”에서 갈립니다.

다만 여기서 조심할 점은 범위입니다. 해당 커밋 자체는 shared lifecycle과 check_limits pilot에 가까우며, 커밋 메모 기준으로 concrete gateway surface 전체가 연결된 작업은 아닙니다. “완성된 통합 제어면”이라기보다, 앞으로 OpenAI, MCP, 기타 surface가 같은 정책 경로를 타게 만들기 위한 토대에 가깝습니다.

한국 사용자 입장에서는 이 뉘앙스가 꽤 중요합니다. 팀에서 AI API gateway를 고를 때는 기능 목록보다 “정책이 어디서 강제되는지”를 봐야 합니다. ThinkWatchProject/ThinkWatch AI MCP gateway GitHub 저장소를 테스트한다면, rate limit과 audit 이벤트가 특정 provider adapter에만 붙어 있는지, 공통 lifecycle에서 일관되게 처리되는지 먼저 확인하겠습니다.

 

 

AI API와 MCP 서버를 팀에서 쓸 때 왜 게이트웨이가 필요한가

 

팀이 여러 AI API와 MCP 서버를 직접 연결하면 키 관리, 권한 범위, 누가 어떤 도구를 호출했는지, 비용이 어디서 발생했는지가 흩어집니다. ThinkWatch의 의미는 모델 성능 향상이 아니라 접근 통제와 운영 가시성을 한 지점에 모으려는 데 있습니다.

MCP 서버는 AI 에이전트가 파일, 데이터베이스, 사내 도구, 외부 API에 접근하는 통로가 될 수 있습니다. 그래서 “연결이 된다”보다 “누가, 어떤 권한으로, 어떤 도구를, 얼마만큼 호출했는가”가 더 중요해집니다. 개인 개발 환경에서는 단순 토큰 관리로 버티지만, 팀 환경에서는 감사 로그와 권한 분리가 필요합니다.

ThinkWatch 문서의 아키텍처는 OpenAI 호환 chat completions, Anthropic Messages, OpenAI Responses, MCP streamable HTTP, console API 같은 여러 surface를 언급합니다. 저장 계층에는 PostgreSQL, Redis, ClickHouse, 선택적 S3-compatible blob storage가 등장합니다. 이 구성은 단순 reverse proxy보다 무겁습니다. 대신 감사와 비용 추적을 제대로 하려면 왜 이런 계층이 필요한지도 드러납니다.

비교하면 이렇습니다.

현재 방식	생기는 문제	ThinkWatch로 확인할 지점
앱마다 provider API key를 직접 저장	키 회수와 교체가 어려움	tenant/user key 모델과 token rotation
MCP 서버를 개별 에이전트에 직접 연결	도구 호출 추적이 흩어짐	per-user MCP credential과 audit trail
팀 비용을 provider 청구서로만 확인	프로젝트별 원인 분석이 느림	budget, cost visibility, ClickHouse 기반 이벤트 기록

제가 보기에는 ThinkWatch는 “AI 도구가 많아진 뒤의 운영 부채”를 겨냥합니다. 아직 작은 팀이라면 과할 수 있지만, 내부 AI 도구가 늘고 외부 provider를 섞어 쓰는 조직에는 평가할 만한 주제입니다.

 

도입 시뮬레이션: 설치부터 첫 검증까지

 

첫 검증은 프로덕션 트래픽을 바로 붙이는 방식이 아니라 로컬 인프라를 띄우고 health check, 테스트 provider credential, audit/cost 기록 생성 여부를 확인하는 방식이 적절합니다.

ThinkWatch 설치 경로는 “npm 패키지 하나 설치”처럼 가볍지 않습니다. 배포 문서는 Rust stable, Node.js 20 이상, pnpm 9 이상, Docker 24 이상, Docker Compose v2, curl, jq, openssl을 전제합니다. 이 전제만 봐도 ThinkWatch가 CLI 편의 도구가 아니라 gateway service와 web console을 함께 가진 인프라 프로젝트라는 점이 드러납니다.

작게 검증한다면 순서는 이렇습니다.

1. `git clone https://github.com/ThinkWatchProject/ThinkWatch.git`로 저장소를 받고 `.env.example`을 `.env`로 복사합니다.
2. `.env`에서 `DB_PASSWORD`, `REDIS_PASSWORD`, `JWT_SECRET`, `ENCRYPTION_KEY`, `CLICKHOUSE_PASSWORD`, `ZITADEL_MASTERKEY`를 개발용으로 생성합니다.
3. `make infra`로 Postgres, Redis, ClickHouse, Zitadel 같은 로컬 의존성을 띄웁니다.
4. 백엔드는 `cargo run -p think-watch-server`, 콘솔은 `web` 디렉터리에서 `pnpm dev`로 띄우는 흐름을 확인합니다.
5. 로컬 gateway 포트 `3000`, console API 포트 `3001`, Vite frontend 포트 `5173` 중 어떤 화면과 API가 살아 있는지 health check로 검증합니다.

실제로 확인할 부분은 “화면이 뜬다”에서 끝나지 않습니다. 테스트용 OpenAI 또는 Anthropic credential을 연결한 뒤, 요청이 gateway를 통과했는지, audit event가 남는지, rate limit 정책이 거부 응답을 만드는지, 비용 추적 데이터가 저장되는지까지 봐야 합니다. ThinkWatchProject/ThinkWatch AI MCP gateway GitHub 저장소의 도입 가치는 이 네 가지가 같은 흐름에서 보일 때 생깁니다.

 

 

 

운영 모델: 어떤 구성요소를 책임져야 하나

 

ThinkWatch를 도입한다는 것은 게이트웨이 하나만 실행하는 일이 아니라 Postgres, Redis, ClickHouse, S3-compatible storage, OIDC, metrics, audit retention을 함께 운영한다는 뜻입니다. 따라서 플랫폼팀이나 보안팀이 소유권을 갖는 시나리오에 더 잘 맞습니다.

운영 관점에서 ThinkWatch는 “AI API 앞단의 bastion host”처럼 봐야 합니다. gateway가 provider 요청을 대신 받고, console이 정책과 관측을 제공하며, persistence 계층이 사용자·키·감사·비용 데이터를 맡습니다. 이 구조에서는 장애 지점도 늘어납니다. Redis 장애는 rate limit이나 session 성격의 기능에 영향을 주고, ClickHouse 장애는 비용·감사 분석 품질을 떨어뜨립니다.

production compose 기준으로 gateway는 외부에 `3000` 포트를 노출하고, console API 포트 `3001`은 Docker network 내부에 두는 형태로 설명됩니다. 이는 운영자가 public ingress, TLS, identity provider, metrics endpoint, 로그 보관 정책을 별도로 설계해야 한다는 뜻입니다.

도입 전에 저는 다음 질문을 먼저 던지겠습니다.

• `METRICS_BEARER_TOKEN` 없이 `/metrics`가 외부에 노출될 가능성은 없는가?
• MCP server credential이 사용자별로 분리되고, 퇴사자나 권한 변경 시 회수되는가?
• audit log에 prompt나 tool input 같은 민감 데이터가 들어갈 때 보관 기간과 redaction 정책은 정해졌는가?
• provider failover가 비용 폭증이나 데이터 지역 이동 문제를 만들지 않는가?
• gateway 장애 시 애플리케이션이 직접 provider로 우회하지 않도록 네트워크 정책을 세웠는가?

이런 질문에 답할 수 있는 팀이라면 ThinkWatch 검토가 현실적입니다. 반대로 “일단 띄워 보고 나중에 정책을 정하자”는 흐름이면, AI gateway가 오히려 또 하나의 미관리 보안 계층이 됩니다.

 

 

 

어떤 팀에게 맞고 어떤 팀은 건너뛰어야 하나

 

여러 AI provider와 MCP 서버를 팀 단위로 관리해야 하는 조직에는 평가 가치가 있지만, 단순 API 호출 래퍼가 필요한 개인 개발자에게는 과합니다. BSL 1.1 라이선스, 운영 의존성, 민감 데이터 로그 정책을 검토할 수 없다면 도입을 미루는 편이 낫습니다.

ThinkWatch가 잘 맞는 곳은 비교적 명확합니다. 사내 에이전트가 여러 MCP 서버를 호출하고, 팀별 예산과 사용자별 권한을 나눠야 하며, OpenAI·Anthropic·Gemini·자체 호스팅 LLM을 함께 평가하는 조직입니다. 특히 AI 플랫폼팀, 내부 개발자 플랫폼팀, 보안팀이 함께 보는 구조라면 “게이트웨이에서 정책을 강제한다”는 방향이 설득력을 갖습니다.

반대로 개인 프로젝트나 단일 백엔드 서비스가 provider SDK 하나만 쓰는 상황이라면 ThinkWatch는 무겁습니다. Postgres, Redis, ClickHouse, OIDC, secret rotation, metrics, audit retention까지 운영할 준비가 없다면 도입 비용이 이득보다 커질 수 있습니다.

라이선스도 그냥 넘기면 안 됩니다. 저장소의 라이선스 파일은 Business Source License 1.1을 사용하며, 문서는 현재 OSI 오픈소스가 아니라 source-available 성격이라고 설명합니다. 비프로덕션 사용과 일정 범위 이하의 프로덕션 사용은 가능하더라도, 회사 규모나 사용량이 커질 때 상업 라이선스 조건을 확인해야 합니다.

마지막으로 0개 오픈 이슈는 “문제가 없다”는 뜻이 아닙니다. 2026년 4월에 만들어진 초기 저장소에서 이슈가 적다는 것은 사용자 기반이 아직 작거나 공개 리포팅이 적을 수도 있다는 뜻입니다. ThinkWatchProject/ThinkWatch AI MCP gateway GitHub 검토는 기능 데모보다 라이선스, 장애 시나리오, 로그 데이터 정책 검토를 먼저 포함해야 합니다.

 

자주 묻는 질문

 

Q. ThinkWatch는 일반 API gateway와 무엇이 다른가요?
A. 일반 API gateway가 라우팅, 인증, rate limit에 초점을 두는 경우가 많다면, ThinkWatch는 AI provider 요청과 MCP 서버 접근을 함께 다루며 RBAC, 감사 로그, 예산, 비용 추적을 AI 운영 흐름에 맞춰 묶으려는 프로젝트입니다.

Q. 로컬에서 가장 작게 검증하려면 무엇을 보면 되나요?
A. `make infra`로 Postgres, Redis, ClickHouse, Zitadel 의존성을 띄운 뒤 `cargo run -p think-watch-server`와 `pnpm dev`로 gateway와 web console을 실행하고, 테스트 provider credential로 요청 1건이 audit/cost 기록까지 남는지 확인하는 것이 좋습니다.

Q. MCP 서버를 팀에서 쓸 때 ThinkWatch가 특히 의미 있는 지점은 무엇인가요?
A. 사용자별 MCP credential, token rotation, session-aware lifecycle, audit trail 같은 통제 지점을 한 gateway 경로에 모으려는 점입니다. 다만 upstream MCP 서버의 권한 모델과 데이터 보관 정책까지 자동으로 해결한다고 보면 안 됩니다.

Q. BSL 1.1이면 회사에서 바로 프로덕션에 써도 되나요?
A. 바로 단정하면 안 됩니다. ThinkWatch 라이선스 문서는 source-available 성격과 사용 규모에 따른 상업 라이선스 조건을 설명하므로, 프로덕션 도입 전 회사의 사용량, 고객 노출 범위, 상업 라이선스 필요 여부를 확인해야 합니다.

Q. GitHub open issues가 0개면 안정적이라고 봐도 되나요?
A. 아닙니다. 0개 오픈 이슈는 확인 시점의 GitHub 상태일 뿐입니다. 저장소 생성일, Releases/tags 부재, 최근 커밋의 범위, 자체 테스트 결과를 함께 놓고 판단해야 합니다.

함께 읽으면 좋은 글

 

• GitHub Agentic Workflows(gh-aw) 추천: GitHub Actions로 AI 에이전트 자동화하기 — GITHUB 추천
• Qwen Code GitHub 추천: Qwen 생태계의 터미널 AI 코딩 에이전트 살펴보기 — GITHUB 추천
• CodeGraph GitHub 추천: Claude Code·Codex·Cursor용 로컬 코드 지식 그래프 — GITHUB 추천
• Google ADK Python 추천: Gemini 에이전트를 코드로 만들고 평가하는 공식 프레임워크 — GITHUB 추천
• Beads GitHub 추천: 코딩 에이전트에게 지속 메모리와 이슈 그래프를 붙이는 법 — GITHUB 추천

참조 링크

 

• GitHub - ThinkWatchProject/ThinkWatch — 공식 owner/repo, README, 코드, Makefile, 라이선스와 저장소 구조 확인에 사용했습니다.
• GitHub API repository metadata for ThinkWatchProject/ThinkWatch — 생성일, push 시점, stars, forks, open issues, license spdx_id 같은 시점 의존 메타데이터 확인에 사용했습니다.
• feat(common): lifecycle pipeline phase 1 — 2026-05-20 lifecycle pipeline과 rate-limit 점검 단계 작업의 범위를 확인했습니다.
• ThinkWatch - The enterprise-grade secure gateway for AI — AI API Gateway, MCP Gateway, RBAC, audit logging, rate limiting, cost visibility 포지셔닝 확인에 사용했습니다.
• ThinkWatch Architecture — 지원 surface와 Postgres, Redis, ClickHouse, S3-compatible storage 등 운영 구성요소를 확인했습니다.
• ThinkWatch Deployment Guide — Rust, Node.js, pnpm, Docker, Docker Compose, make infra, cargo run, pnpm dev 기반 설치와 첫 실행 흐름을 확인했습니다.
• ThinkWatch Changelog — 2026년 4월 public preview부터 5월 MCP Gateway와 Responses API 흐름까지의 타임라인 확인에 사용했습니다.
• ThinkWatch Licensing — source-available 성격, OSI open source가 아니라는 설명, rolling GPL 전환 조건을 확인했습니다.
• ThinkWatch LICENSE — Business Source License 1.1 조건과 프로덕션 사용 전 검토 필요성을 확인했습니다.
• ThinkWatch .env.example — DB_PASSWORD, REDIS_PASSWORD, JWT_SECRET, ENCRYPTION_KEY, CLICKHOUSE_PASSWORD, ZITADEL_MASTERKEY, METRICS_BEARER_TOKEN 같은 운영 secret 항목을 확인했습니다.
• ThinkWatch production docker-compose.yml — gateway 3000 포트와 console 3001 포트의 배포 노출 방식을 확인했습니다.