엔터프라이즈 도구를 도입할 준비가 되지 않은 팀을 위한 거버넌스 우선 AI 게이트웨이

규제 대상 조직에서 근무한다면 아마 이런 상황을 본 적이 있을 것입니다: 경영진은 AI를 실무(production)에 도입하고 싶어 하고, 보안 팀은 감사 추적(audit trail)을 원하며, 그 사이에 낀 팀은 두 가지 선택지 중 하나를 택해야 합니다. 거버넌스 없이(섀도우 툴, DLP 없음, 감사 로그 없음) 빠르게 무언가를 출시하거나, 엔터프라이즈 플랫폼이 조달되고 승인될 때까지 12개월에서 18개월을 기다리는 것입니다. 둘 다 좋은 방법은 아닙니다.

그 간극을 메우기 위해 사용 가능한 대부분의 도구는 다음 세 가지 부류 중 하나에 속합니다:

너무 복잡함. LiteLLM, Kong, Azure APIM. 좋은 도구들이지만, 이미 DevOps 역량을 갖추고 AI 인프라 예산이 있는 팀을 위해 구축되었습니다.
너무 비쌈. 6자리 숫자(억 단위)의 계약금이 필요한 엔터프라이즈 AI 거버넌스 플랫폼들.
클라우드 의존도가 너무 높음. 데이터를 제3자에게 전송해야 하며, 이는 금융, 의료 및 공공 부문의 데이터 거주성(data residency) 규칙 하에서는 시작조차 할 수 없는 문제입니다.

저는 이러한 옵션들 사이의 공간을 목표로 하는 Synapse AI Gateway라는 작은 Apache-2.0 프로젝트를 작업해 왔습니다. docker compose up을 실행하면 전체 스택(postgres, 백엔드, 관리 콘솔)이 구동되며, 5분 이내에 실행할 수 있습니다. 거버넌스 제어(Governance controls)는 모든 추론(inference) 요청이 모델에 도달하기 전에 실행됩니다.

GitHub: synapse-ai-gateway/synapse-ai-gateway

핵심 아이디어: 자격 증명에 결합된 거버넌스

이 설계는 한 가지 결정에 달려 있습니다: 모든 API 키는 생성 시 시스템 프롬프트(system prompt), 모델 허용 목록(model allowlist), 팀 식별 정보(team identity), 그리고 속도 제한(rate limits)에 결합됩니다. 승인된 HR 어시스턴트 용도로 키를 받은 팀은 해당 키를 다른 용도로 몰래 재사용할 수 없습니다. 새로운 용도를 위해서는 새로운 키가 필요하며, 이는 곧 새로운 승인을 의미합니다.

이것이 정책으로서의 거버넌스(아무도 읽지 않는 위키 페이지)와 인프라로서의 거버넌스(게이트웨이가 요청을 거부함)의 차이입니다. 정책은 스스로를 강제하지 못합니다. 요청 경로(request path)에 있는 제어 장치가 강제합니다.

모든 요청이 통과하는 5가지 계층

client app
   │
   ▼
...

Layer 1은 키(key)를 검증하고, 바인딩된 시스템 프롬프트(system prompt)를 주입하며, 모델 허용 목록(allowlist)을 확인합니다. 유효하지 않은 키나 승인되지 않은 모델은 즉시 403 오류를 반환합니다.

Layer 2는 내장된 정규 표현식(regex) DLP(데이터 유출 방지) 엔진입니다. 카테고리당 세 가지 결과가 발생합니다: block (HTTP 400, 차단), redact (정화 후 전달), alert (로그 기록 후 전달). 패턴은 핫 리로드(hot-reload)가 가능한 설정 파일에 저장됩니다. 외부 서비스가 필요하지 않다는 점이 중요한데, 이는 데이터 주권(data sovereignty) 규칙에 따라 개인정보(PII)가 스캔을 위해서라도 경계(perimeter)를 벗어날 수 없는 경우에 매우 중요합니다.

Layer 3은 데이터 분류(data classification)에 따라 라우팅합니다. sensitive(민감) 태그가 붙은 키는 온프레미스(on-premises) 백엔드(Ollama, vLLM)로만 전송이 허용됩니다. non_sensitive(비민감) 태그가 붙은 키는 더 높은 성능을 위해 클라우드 제공업체로 전송될 수 있습니다. 사용하는 애플리케이션은 변경되지 않습니다. 애플리케이션은 항상 OpenAI API 방식으로 통신합니다.

Layer 4는 요청당 하나의 행을 PostgreSQL에 기록합니다: 타임스탬프, 팀, 모델, 토큰 수(token count), 지연 시간(latency), DLP 결과, HTTP 상태 코드. 프롬프트와 응답은 SHA-256 해시로 저장되며, 절대 평문(plaintext)으로 저장되지 않습니다. 이를 통해 직원의 프라이버시를 보호하면서도 포렌식 해시 매칭(forensic hash-matching)이 가능하도록 유지합니다.

Layer 5는 응답이 나가는 경로를 스캔하여 이상 징후(사용량 급증, 반복적인 DLP 차단, 업무 시간 외 폭증 등)를 웹훅(webhook)을 통해 알립니다.

빠른 시작 (Quick start)

git clone https://github.com/synapse-ai-gateway/synapse-ai-gateway
cd synapse-ai-gateway
docker compose up -d

모든 설정에는 작동 가능한 기본값이 설정되어 있으므로, 로컬 테스트를 위한 빠른 시작 절차는 이것이 전부라고 해도 과언이 아닙니다. 스택을 localhost 너머로 노출하기 전에, .env.example을 .env로 복사하고 JWT_SECRET, ADMIN_PASSWORD, POSTGRES_PASSWORD에 실제 값을 설정하십시오.

관리 콘솔은 http://localhost:5173에서 접속 가능합니다. 로그인하여 UI에서 팀을 생성하고, API 키(한 번만 표시됨)를 복사하면 준비가 완료됩니다:

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Authorization: Bearer <YOUR_TEAM_API_KEY>" \
  -H "Content-Type: application/json" \
...

OpenAI-API-compatible(OpenAI API 호환)하므로, 어떤 OpenAI SDK라도 작동합니다. base_url을 http://localhost:8080/v1로 지정하고 팀 키(team key)를 전달하면 됩니다. 백엔드는 클라이언트에게 완전히 투명하게 동작합니다.

LiteLLM과의 솔직한 비교

LiteLLM은 훌륭합니다. 하지만 LiteLLM은 다른 문제에 적합한 도구입니다. 즉, 이미 DevOps 역량을 갖춘 팀이 대규모 환경에서 최대의 유연성을 가지고 100개 이상의 제공업체(provider) 간에 라우팅(routing)을 수행할 때 적합합니다. 그에 따라 워커(worker)당 점유하는 리소스(footprint)도 더 크며, 이는 LiteLLM이 설계된 고처리량(high-throughput) 케이스에 적절합니다.

Synapse AI Gateway의 전체 스택은 유휴 상태(idle)에서 약 113 MB로 실행됩니다 (백엔드 73 MB + postgres 32 MB + 프론트엔드 8 MB). 전체 스택은 postgres, 백엔드, 관리 콘솔(admin console)의 세 가지 컨테이너로 구성되며, 단 한 번의 docker compose up으로 실행됩니다. 시작하는 데 Redis, 메시지 브로커(message broker), Kubernetes가 필요하지 않습니다. 이제 막 시작하는 단계이고 오후 한나절 만에 배포할 수 있는 거버넌스 계층(governance layer)이 필요하다면, 이러한 리소스 점유율은 매우 중요합니다. 만약 하루에 수백만 건의 요청을 처리하고 있다면 이는 중요하지 않으며, LiteLLM이 더 나은 선택입니다.

또 다른 의미 있는 차이점은 DLP(데이터 유출 방지, Data Loss Prevention)입니다. LiteLLM의 DLP는 PromptGuard, Pangea 또는 Azure Content Safety와 통합됩니다. 이는 각각 별도의 가격 체계, 계정 및 데이터 흐름을 가진 외부 서비스들입니다. 반면 Synapse의 DLP는 내장(built-in)되어 있습니다. 데이터 거주성(data residency) 규칙에 따라 개인정보(PII)가 경계(perimeter)를 벗어나면 안 되는 조직에게 있어, "내장형"은 단순한 기능 선호의 문제가 아니라 필수 요구 사항(hard requirement)입니다.

이것이 아닌 것

명확히 말해둘 가치가 있습니다:

대규모 팀을 위한 것이 아닙니다. 하루에 수백만 건의 요청을 라우팅하고 있다면, LiteLLM이나 Kong을 사용하십시오.
엔터프라이즈 거버넌스 플랫폼의 대체제가 아닙니다. SOC 2 인증, SLA(서비스 수준 협약), 상업적 지원이 제공되지 않습니다.
마법이 아닙니다. 이 도구 자체가 잘못 설계된 AI 도입 과정을 저절로 안전하게 만들어주지는 않습니다. 이 도구는 제어 권한(controls)을 제공할 뿐이며, 이를 어떻게 사용할지에 대한 합리적인 정책은 여전히 필요합니다.

프로덕션 강화 (Production hardening)

리포지토리(repo)에서 모두 검증된 구체적인 사실들은 다음과 같습니다:

유휴 상태(idle) 시 총 약 113 MB의 컨테이너 3개 (backend 73 MB + postgres 32 MB + frontend 8 MB)
97개의 테스트, 약 88%의 라인 커버리지 (line coverage)
Bandit (정적 보안) 및 Trivy (CVE 스캐닝 + GitHub Security로의 이미지 스캐닝)를 포함한 GitHub Actions CI
GDPR, HIPAA 및 PCI-DSS 정책 팩 — 사전 구성된 DLP (데이터 유출 방지) 패턴으로 클릭 한 번으로 적용 가능
예산 알림 기능이 포함된 팀별, 모델별 비용 귀속 (spend attribution)
추가 전용 (Append-only) PostgreSQL 감사 스키마 (audit schema)
/v1/chat/completions 경로의 OpenAI 호환 REST API

README.md에는 프로덕션(production)을 위한 배포 체크리스트가 포함되어 있습니다: 모든 기본 비밀값(secret) 순환, 리버스 프록시(reverse proxy)에서 TLS 종료, 관리형 PostgreSQL 사용, CORS 제한, 해당 관할 구역에 맞는 DLP 패턴 검토.

기여하기 (Contributing)

이 리포지토리(repo)는 Apache-2.0 라이선스를 따릅니다. DCO 서명 및 'good first issues' 목록이 포함된 CONTRIBUTING.md가 있습니다 — 추가 관할 구역을 위한 DLP 패턴, 추가 백엔드 어댑터(backend adapters), Helm 차트 등이 해당됩니다. 현재 설계가 다루지 못하는 유스케이스(use case)가 있다면 이슈(issue)를 생성해 주세요.