Web UI

Web UI 는 Gateway가 어떤 Provider를 사용할지, 어떤 key를 어떤 모델에 연결할지, 요청 로그와 사용량을 어떻게 볼지, Virtual Key와 budget을 어떻게 관리할지 다루는 운영 콘솔입니다.

Web UI 기능	의미	운영 관점
Visual provider setup	코드 없이 Provider와 API key를 등록	OpenAI, Anthropic 등 Provider 연결을 빠르게 검증
Real-time configuration	변경 사항을 즉시 반영	config 파일 재시작 없이 routing/key 설정 조정
Live monitoring	request logs, metrics, analytics 확인	장애 원인, latency, token, cost 추적
Governance management	Virtual keys, usage budgets 등 관리	고객/팀/서비스별 접근 제어와 비용 통제

Python 백엔드 개발자는 Web UI를 통해 “내 FastAPI/LangGraph 앱이 어떤 Provider로 실제 요청을 보내고 있는지”를 확인할 수 있습니다.

즉 앱 코드는 단순히 Bifrost endpoint를 호출하지만, 실제 운영 결정은 Web UI와 Config Store에 남습니다.

Web UI 접속 흐름과 기본 점검 #

Ch 2.1에서 Gateway를 실행했다면 기본적으로 브라우저에서 Gateway 주소로 접속합니다. 공식 Quickstart 기준 기본 주소는 http://localhost:8080입니다.

초기 실습에서는 UI가 비어 있는 것이 실패가 아닙니다.

Provider 등록 전에는 Provider 목록과 요청 로그가 비어 있을 수 있습니다.

중요한 것은 UI가 열리고, 설정을 만들 수 있으며, 재시작 후에도 설정이 유지되는지입니다.

Web UI Configuration 모드와 File-based Configuration 모드 #

Bifrost는 크게 두 가지 설정 방식을 지원합니다.

모드	설명	적합한 경우
Web UI Configuration	UI/API에서 설정을 만들고 Config Store에 저장	로컬 실습, 빠른 PoC, 운영자가 화면에서 변경하는 환경
File-based Configuration	config.json으로 Provider/key/plugin 등을 선언	GitOps, 재현 가능한 배포, UI 없이 운영하는 환경

공식 문서에 따르면 UI가 사용 가능한 경우는 대표적으로 두 가지입니다.

• config.json이 없고 Bifrost가 SQLite database를 자동 생성하는 경우
• config.json이 있으면서 config_store가 구성된 경우

반대로 config_store 없이 config.json만 사용하는 경우에는 UI 기반 실시간 설정이 불가능하고, 설정은 read-only에 가까운 형태로 메모리에 로드됩니다.

이 경우 변경 사항은 재시작 후 반영되며, UI를 통한 동적 변경은 기대하면 안 됩니다.

이 차이는 운영에서 매우 중요합니다.

UI에서 Provider key를 추가했는데 재시작 후 사라진다면 대부분 volume, app-dir, config_store 설정 문제입니다.

Config Store와 UI 변경 사항의 관계 #

Web UI에서 설정을 바꾸면 그 변경 사항은 Config Store에 저장됩니다.

공식 문서는 config.json에 정의된 entity가 첫 로드 시 content-based hash와 함께 저장되고, 이후 UI/API 변경 사항은 database에 저장되어 pod restart, scale-up, redeploy 이후에도 유지된다고 설명합니다.

이 동작을 이해하지 못하면 운영 중에 “파일을 다시 배포했는데 UI 변경이 왜 덮어써지지 않지?” 또는 “UI에서 바꾼 설정이 왜 사라졌지?” 같은 혼란이 생깁니다.

상황	결과
config.json 없음	Bifrost가 기본 SQLite DB를 만들고 UI 설정을 저장합니다.
config.json • config_store 있음	파일 설정을 DB와 reconcile하고, UI/API 변경은 DB에 유지합니다.
같은 config.json 재적용	content hash가 같으면 DB 변경 사항을 보존합니다.
config.json entity 내용 변경	해당 entity의 hash가 바뀌어 파일 정의가 DB copy를 덮어쓸 수 있습니다.
UI/API로만 추가한 entity	파일에 없더라도 DB에 보존됩니다.
config_store 없음	UI real-time config가 비활성화되고, 재시작 기반 file mode가 됩니다.

운영 권장 패턴은 다음과 같습니다.

• 개발 초기: UI로 Provider와 key를 빠르게 등록해 호출을 검증합니다.
• 팀 개발: SQLite 또는 PostgreSQL Config Store를 명시하고 volume을 연결합니다.
• 운영 전환: 핵심 provider/routing은 GitOps 파일로 선언하고, runtime 조정은 UI/API로 제한적으로 허용합니다.
• 규제 환경: UI 변경 권한과 config 변경 이력을 별도 감사 체계와 연결합니다.

Admin UI는 반드시 접근 제어 대상 #

Web UI는 편리하지만 위험한 관리면입니다. Provider key, routing rule, Virtual Key, budget, MCP tool, plugin 설정을 바꿀 수 있다면 사실상 LLM 플랫폼 전체를 제어할 수 있기 때문입니다.

개발 환경에서는 localhost:8080으로 접속하면 충분하지만, staging/prod에서는 Admin UI와 Gateway API를 같은 방식으로 노출하면 안 됩니다.

경계	권장 정책
Local dev	localhost 접근만 허용
Team dev	VPN 또는 사내망 접근, 공용 test key 사용
Staging	SSO proxy, IP allowlist, 운영자 그룹 제한
Production	Admin UI는 private network/VPN/SSO 뒤에 배치, API endpoint와 분리

특히 MCP Tool Execution과 Plugin 설정을 UI에서 바꿀 수 있는 경우, 잘못된 설정이 외부 API 호출, 데이터 유출, 비용 폭증으로 이어질 수 있습니다.

Web UI는 “편의 기능”이 아니라 “운영 권한을 가진 control plane”으로 취급해야 합니다.