우아한형제들은 여러 Provider의 LLM을 같은 방식으로 호출할 수 있도록 AI Gateway를 운영해 왔습니다. 처음에는 대체 모델, Langfuse(LLM 호출의 트레이스를 기록하고 보는 도구) 연동, 비용 집계가 필요한 과제나, PoC(proof of concept, 개념 검증)를 위해 공용 크레덴셜을 사용하는 과제가 주로 이용했습니다. 그런데 AI를 사용하는 과제가 늘고 Agent가 LLM과 도구를 반복해서 호출하기 시작하면서, 모델 호출을 지원하는 것만으로는 부족해졌습니다. 누가 어떤 목적으로 AI를 사용하고, 얼마를 사용하며, 어디까지 허용할지를 함께 관리해야 했습니다.

이 글에서는 AI Gateway를 전사 공통 호출 경로로 넓히고, 사용을 신청하고 검토하고 승인하는 과정을 직접 만든 AI Studio에 담은 경험을 공유합니다. AI Gateway와 AI Studio로 비용과 보안을 어떻게 관리하는지, 이 구조를 Agent에 어떻게 적용했는지, 플랫폼 자체는 어떻게 보호했는지도 함께 다룹니다.

들어가며

사용이 늘면 비용과 보안 위험도 함께 늘어난다

처음 LLM을 도입했을 때부터 사내 AI 사용량은 꾸준히 늘었고, Agent가 늘어나면서 프로젝트와 호출 수가 더 빠르게 늘었습니다. 사용이 늘면 같이 늘어나는 것이 있습니다.

하나는 비용입니다. 전체 비용은 확인할 수 있었지만, 프로젝트별로 얼마를 사용하는지, 왜 늘었는지는 설명하기 어려웠습니다. 다른 하나는 보안 위험입니다. 민감정보가 외부 Provider로 나갈 수 있고, 하나의 키를 여러 곳이 같이 사용하는 일도 생겼습니다. 더 많은 팀이 Agent를 만들어 사내 도구와 데이터에 연결하면, 문제가 생긴 뒤에 어떤 Agent를 누가 맡는지 찾아서는 늦습니다.

그렇다고 AI 사용을 막을 수는 없습니다. 사용을 막으면 비용과 보안 위험은 줄지만, AI로 얻을 성과도 같이 사라집니다. 그래서 택한 방향은 사용은 계속 늘리고, 비용과 보안은 정한 범위 안에 두는 것이었습니다.

왼쪽 그림은 사용을 막았을 때입니다. 비용과 보안 위험은 낮게 유지되지만 사용도 늘지 않습니다. 오른쪽 그림은 사용을 늘리면서 함께 관리할 때입니다. 사용은 계속 늘어나지만 비용과 보안은 정한 범위 안에 있습니다. 흐린 선은 관리하지 않았을 때 비용과 보안이 얼마나 커지는지를 보여 줍니다.

AI 거버넌스는 사용을 막지 않는다

이 글에서 AI 거버넌스는 조직이 AI를 어떤 범위에서 사용하고, 누가 판단하고 책임지며, 실제 사용 결과를 어떻게 확인하고 개선할지 정하는 체계를 말합니다. 정책을 정하는 일뿐 아니라, 그 정책을 시스템에 적용하고 운영하면서 다시 조정하는 과정까지 포함합니다.

보통 거버넌스라고 하면 보안과 비용 때문에 승인과 절차를 늘려 사용을 막는 것을 떠올립니다. AI플랫폼은 반대로 접근했습니다. 보안과 비용 정책을 지키는 부담은 플랫폼이 줄이고, 구성원은 AI로 성과를 내는 데 집중하게 하는 것입니다. 각 팀은 정해진 정책과 자원 범위 안에서 매번 승인을 기다리지 않고 실험하고, 과제의 비용과 호출 기록을 보며 개선하고, 사용 범위를 넓혀야 할 때만 검토를 받습니다.

플랫폼이 이 부담을 줄이려면 먼저 해야 할 일이 있었습니다. LLM과 Agent 호출은 여러 서비스에서 따로 일어나고 있었습니다. 이 호출을 AI Gateway라는 공통 호출 경로로 모았습니다. 한 경로로 모으면 누가, 어떤 모델을, 얼마나 사용하는지 확인할 수 있고, 허용 모델과 예산, 호출 한도 같은 공통 정책을 한곳에서 적용할 수 있습니다. 앞으로 Agent가 더 늘어나도 Agent의 LLM과 도구 호출은 같은 경로로 들어옵니다.

경로부터 모은 이유도 있습니다. 민감정보 유출 같은 사고는 되돌리기 어렵고, 사용이 크게 늘어난 뒤에는 경로를 정리하기도 어렵습니다. 그래서 사용이 더 늘기 전에 경로부터 모으기로 했습니다.

전체 구조를 신청, 호출, 기록으로 나눈다

AI플랫폼이 맡는 영역은 넓습니다. 이 글은 그중 AI Studio와 AI Gateway, 즉 LLM과 Agent의 사용과 운영, 기록을 관리하는 부분을 다룹니다. Feature Store나 ML Serving, Pipeline 같은 MLOps 영역은 다루지 않습니다.

전체 흐름은 세 부분으로 나뉩니다. 위쪽은 Control Plane입니다. 신청자가 목적과 모델, 예산을 적어 AI Studio에 신청하고, 정책에 따라 필요한 항목만 검토를 받습니다. 검토가 끝나면 승인된 설정이 AI Gateway에 반영됩니다.

아래쪽은 Data Plane입니다. AI 서비스와 Agent는 Virtual Key로 AI Gateway를 호출하고, AI Gateway는 허용 모델과 예산, 호출 한도를 확인한 뒤 LLM Provider나 MCP 서버로 요청을 전달합니다. LLM Provider에는 Bedrock, Azure, GCP와 함께 사내 데이터 센터 GPU에서 직접 서빙하는 AI플랫폼이 있습니다.

마지막으로 모든 호출은 Observability에 기록으로 남습니다. 프로젝트별 Langfuse 트레이스와 Grafana 지표, Slack 경보로 실제 사용을 다시 검토하고 개선합니다. 정리하면 신청은 AI Studio에서, 호출은 AI Gateway에서, 확인은 기록으로 합니다.

1. AI Gateway, 거버넌스의 기반이 되다

1.1 호출이 늘자 비용도 책임도 보이지 않았다

LLM을 사용해 온 시간만큼 크레덴셜을 발급하고 사용하는 방식도 쌓여 있었습니다. 과제가 생길 때마다 새로 발급하기도 했고, 하나의 크레덴셜을 여러 과제가 함께 사용하기도 했습니다. Provider마다 발급 방식이 달랐고, 방식이 변경된 뒤에도 예전 키는 남아 있었습니다.

이 구조에서는 전체 비용은 확인할 수 있어도, 비용이 늘어난 이유를 과제별로 설명하기 어려웠습니다. Bedrock은 AIP(Application Inference Profile)로 비용을 나눌 수 있었지만, 이전에 만든 리소스에는 AIP나 태그가 없었습니다. 다른 Provider의 비용은 각 콘솔에서 확인해 따로 모아야 했습니다. 담당자조차 맡은 과제가 얼마를 사용하는지 바로 알기 어려웠습니다.

여기에 Agent가 늘면서 문제가 커졌습니다. Agent는 요청 하나에도 LLM과 도구를 여러 번 반복해서 호출합니다. 호출은 길어지고 많아졌는데, 어떤 과제가 비용을 늘렸는지 모르면 그 사용이 필요한지, 줄일 수 있는지도 판단할 수 없습니다.

결국 다음 질문에 같은 기준으로 답할 수 있어야 했습니다. 회사에서 LLM을 사용하는 과제와 Agent는 무엇인가, 누가 만들었고 누가 책임지는가, 얼마를 사용하고 있으며 사용량이 갑자기 늘지는 않았는가, 허용한 범위 안에서 사용하고 있는가. 이 질문에 답하려면 호출을 한곳에서 관리하는 기반부터 필요했습니다.

1.2 LiteLLM으로 공통 호출 경로를 만들다

그래서 오픈소스인 LiteLLM을 AI Gateway로 도입했습니다. 시작은 LLM Gateway였습니다. 여러 Provider를 같은 방식으로 부를 수 있는 공통 호출 인터페이스입니다. 외부 Provider뿐 아니라 사내 AI플랫폼의 모델도 같은 경로로 제공하며, 자체 서빙 모델에는 LLM 외에 임베딩, OCR 같은 모델도 있습니다.

LiteLLM을 선택한 이유가 여러 Provider를 같은 방식으로 호출할 수 있어서만은 아니었습니다. 접근 권한과 예산, 사용 기록을 관리하고, 그 범위를 MCP(Model Context Protocol, LLM이 외부 도구와 데이터에 연결하는 표준 프로토콜) 도구와 Agent 호출까지 넓혀 가는 방향이 AI플랫폼이 가려던 방향과 맞았습니다. 호출, 접근 제어, 예산 관리, 관측 연동은 LiteLLM의 기능을 사용하고, 조직의 정책과 업무 흐름에 맞춘 과제 등록, 정책 평가, 사내 승인 시스템 연결은 뒤에서 설명할 AI Studio에 구현했습니다.

관리의 단위는 프로젝트입니다. 프로젝트는 AI를 사용하는 과제 하나를 플랫폼에 등록한 단위로, 담당자와 예산, 크레덴셜, 정책을 여기에 연결합니다. AI Gateway에서는 Team으로 관리하지만, 이 글에서는 프로젝트로 부르겠습니다.

1.3 호출을 모으자 관측과 통제가 가능해졌다

AI Gateway는 호출 하나를 네 단계로 처리합니다. 첫 단계는 키 확인입니다. Virtual Key로 어느 프로젝트의 호출인지 확인합니다. 두 번째는 허용 확인입니다. 이 프로젝트가 사용할 수 있는 모델과 도구인지 확인합니다. 세 번째는 한도 확인입니다. 예산과 RPM(requests per minute, 분당 요청 수), TPM(tokens per minute, 분당 토큰 수)을 넘지 않았는지 확인합니다. 네 번째는 전달입니다. 세 단계를 통과하면 LLM Provider나 MCP 서버로 전달하고, 실패하면 재시도하거나 대체 모델로 넘깁니다. 이 모든 단계에서 프로젝트별 비용과 트레이스가 기록됩니다.

호출 한도는 공용 자원을 보호하는 수단입니다. 사내 GPU와 Provider 할당량은 여러 프로젝트가 함께 사용합니다. 한 프로젝트의 급격한 사용 증가나 반복 호출이 다른 서비스에 영향을 주지 않도록, 이 한도는 프로젝트마다 필요할 때 적용할 수 있습니다.

이 기능들은 하나씩 보면 게이트웨이의 운영 기능입니다. 하지만 프로젝트를 기준으로 묶으면, 누가 무엇을 얼마만큼 사용할 수 있는지 정하고 실제 사용을 확인하는 거버넌스의 기반이 됩니다. AI Gateway는 승인된 설정을 모든 호출에 적용하는 실행 단계입니다.

기존 과제를 AI Gateway로 옮기는 일은 호출 경로만 변경하는 작업이 아니었습니다. 기존 과제는 크레덴셜 이름과 사내 위키, 요청 기록을 단서로 사용 과제와 담당자를 찾아야 했습니다. 모델을 사용할 수 있다는 것과 기존 서비스에 바로 적용할 수 있다는 것도 달랐습니다. 모델별 지원 범위와 버전 차이 때문에 임베딩처럼 바로 옮기기 어려운 경우가 있었고, 서비스별 품질 검증 시간도 필요했습니다. 그리고 키를 발급해 전달하고 검토 결과를 과제와 손으로 맞추는 일을 사람이 계속 맡을 수는 없었습니다.

남은 질문은 두 가지였습니다. 프로젝트별 모델과 예산, 한도는 누가 어디서 정하는가, 그리고 새 과제가 처음부터 서비스와 담당자, 정책이 연결된 채로 들어오게 하려면 어떻게 해야 하는가. 이 질문에 대한 답이 AI Studio입니다.

2. AI Studio로 신청과 검토를 연결하다

2.1 설정할 수 있다고 관리되는 것은 아니었다

AI Gateway로 예산, 호출 한도, 허용 모델을 설정할 수 있게 됐지만, 프로젝트마다 어떤 값을 넣을지는 Gateway가 정해 주지 않습니다. 예산을 정하려면 과제와 비용을 검토해야 하고, 허용 모델을 정하려면 데이터와 보안 기준을 확인해야 합니다. 운영 중에 값을 변경할 때도 누가 무엇을 승인했는지 남겨야 합니다.

판단에 필요한 정책과 검토는 이미 있었습니다. 개인정보보호 가이드라인, 생성형 AI 보안성 검토 가이드, MCP 안전성 점검 가이드 같은 정책이 마련돼 있었고, 비용과 보안 검토도 각 조직이 하고 있었습니다.

문제는 신청 창구가 셋으로 나뉘어 있었다는 점입니다. Bedrock은 신청 창구에서 AWS 키를 직접 받았고, 외부 Provider는 따로 검토를 거쳐 키를 발급받았고, AI Gateway는 필요한 프로젝트만 따로 연동했습니다. 창구가 셋이니 과제 목록도 셋으로 나뉘었고, 어느 목록도 전체를 보여 주지 못했습니다.

그래서 세 창구를 AI Studio 하나로 합쳤습니다. AI Studio에서 과제 등록, 검토, 승인을 한곳에서 하고, 승인되면 프로젝트 설정과 키 발급까지 이어지는 기능을 더했습니다. 사용자가 AI를 사용하려면 반드시 거치는 키 발급 과정에 과제 등록과 정책 평가를 붙인 것입니다.

AI Studio는 세 가지 원칙으로 설계했습니다. 첫째, 기본 범위는 바로 발급하고 범위 밖 항목만 검토합니다. 둘째, 원본 데이터는 각 시스템에 두고, AI Studio는 필요한 것만 불러옵니다. 셋째, 신청과 호출을 프로젝트로 연결해서, 발급한 뒤에도 다시 검토할 수 있게 합니다.

2.2 정책을 플랫폼에 담을수록 사람의 검토는 줄어든다

첫 번째 원칙은 검토 방식이 변경되어 온 과정에서 나왔습니다. 처음에는 위키 문서를 보고 모든 항목을 사람이 확인하고 검토했습니다. 그다음에는 기준을 정리해 항목을 나눠 검토했습니다. 기준이 구체적인 항목으로 정리되자, 일부 항목은 사람이 아니라 플랫폼이 확인할 수 있게 됐습니다. 지금은 그 기준을 정책 파일로 플랫폼에 담았습니다. 기본 범위는 플랫폼이 확인하고 바로 발급하고, 사람은 예외 항목만 검토합니다.

정책을 파일로 관리하면 같은 신청값은 항상 같은 기준으로 평가되고, 어떤 정책 버전으로 판단했는지도 승인 기록에 남길 수 있습니다.

2.3 기본 범위는 바로 발급하고, 예외만 검토한다

AI Studio에 과제를 등록하면 신청값을 정책으로 평가합니다. 기본 허용 범위 안이면, 예를 들어 사내 AI플랫폼 모델이면, 플랫폼 정책만 통과하고 별도 승인 대기 없이 바로 키를 발급합니다. 범위 밖 항목은 사내 승인 시스템과 연동해 비용 검토와 보안 검토를 받고, 승인된 설정으로 프로젝트 키를 발급합니다. 외부 전송이 금지된 정보나 사용이 금지된 모델처럼 허용할 수 없는 항목은 발급 전에 막습니다.

검토는 필요한 만큼만 붙습니다. 비용이 큰 모델을 선택하면 비용 검토가, 일정 예산을 넘으면 예산 검토가 추가되고, 데이터와 보안 항목은 해당 기준에 따라 검토합니다. 서로 독립적인 검토는 병렬로 진행하고, 일부 모델이 검토 중이어도 이미 허용된 모델은 기다리지 않고 먼저 사용할 수 있게 했습니다.

평가 결과는 신청 화면에 바로 보입니다. 항목별로 통과했는지, 검토가 필요한지와 그 이유를 안내하고, 예산을 기본 허용 범위로 조정하면 승인 절차에서 빠질 수 있다는 점도 보여 줍니다. 사용자는 이를 보고 허용 범위 안으로 신청을 조정하거나, 필요한 범위를 유지한 채 검토를 요청합니다. 필요한 승인은 사내 승인 시스템으로 자동으로 올라가므로, 신청자가 별도 문서를 쓰거나 요청할 조직을 찾지 않아도 됩니다.

2.4 원본은 각 시스템에 두고 불러온다

AI Studio가 모든 정보를 직접 가지면 시스템마다 값이 어긋나기 쉽습니다. 그래서 원본은 각 정보를 담당하는 시스템에 두었습니다. 프로젝트 정보, 즉 서비스와 담당자, 용도는 서비스 카탈로그가 원본입니다. AI Studio는 이것을 불러오기만 합니다. 사용자가 대상 서비스를 선택하면 카탈로그에 등록된 기획과 설계 문서도 함께 볼 수 있어서, 같은 내용을 따로 제출받는 대신 이미 관리하던 서비스 정보를 검토의 맥락으로 사용합니다.

비용 검토와 보안 검토의 상태는 사내 승인 시스템이 원본입니다. AI Studio는 검토를 요청하고 승인 결과를 받아 옵니다. 비용 검토는 비용 담당 조직이, 보안 검토는 보안 담당 조직이 맡습니다. 예산과 사용 모델, RPM과 TPM은 AI Gateway가 원본입니다. AI Studio는 승인된 설정을 Gateway의 프로젝트 설정에 등록하고, 키는 그 설정으로 발급됩니다.

필요한 승인이 끝났는지와 예산, 허용 모델 같은 필수 설정이 갖춰졌는지를 함께 확인한 뒤 발급합니다. Virtual Key에는 별도 설정을 넣지 않고, 허용 모델과 예산은 소속 프로젝트의 설정을 상속합니다. 프로젝트 정책을 변경하면 그 프로젝트의 키가 모두 같은 기준을 따르고, Provider 원본 키는 요청자에게 전달하지 않습니다. 키에 설정값을 복사해 두지 않으니 시스템끼리 값이 어긋나지 않습니다.

2.5 신청과 호출을 한 프로젝트로 연결해, 발급 뒤에도 다시 검토한다

발급할 때 AI Studio 프로젝트에 맞춰 Gateway의 프로젝트와 Virtual Key, Langfuse 프로젝트를 함께 만들고, 세 시스템에 같은 프로젝트 이름을 사용합니다. 사람이 시스템마다 다른 이름을 대조하지 않아도 검토 이력과 비용, 호출 기록이 한 프로젝트로 연결됩니다.

신청과 검토 쪽에서는 서비스 카탈로그의 담당자와 서비스, 기획과 설계 문서, 검토 결과, 승인된 모델과 예산을 프로젝트에서 확인할 수 있습니다. 발급 이후 운영 쪽에서는 Virtual Key의 사용 현황, Langfuse의 호출 로그와 트레이스, Grafana와 Slack의 비용과 운영 경보를 같은 프로젝트에서 확인할 수 있습니다. 무엇을 만들려고 신청했는지와 실제로 어떻게 사용하는지를 이어서 볼 수 있기 때문에, 발급한 뒤에도 신청한 내용대로 사용하고 있는지 다시 검토할 수 있습니다.

사용자도 과제를 직접 관리합니다. 범위를 넓혀야 할 때는 같은 프로젝트에서 모델이나 예산 변경을 신청하고, 키도 AI Studio에서 직접 생성하고 폐기합니다.

이렇게 신청과 검토로 정한 설정은 AI Gateway에 반영되고, Virtual Key로 들어온 호출은 모두 프로젝트 단위의 기록으로 남습니다. 이 기록이 발급 이후 비용과 보안을 관리하는 근거가 됩니다.

3. 사용 현황과 비용, 보안을 관리하다

호출이 프로젝트 단위로 기록되면서 비용과 보안을 같은 단위로 관리할 수 있게 됐습니다. 비용은 확인하고, 줄이고, 예산을 조정하는 일로, 보안은 민감정보를 나누고, 가드레일을 걸고, 사고를 추적하는 일로 나뉩니다.

3.1 같은 기록을 보는 사람마다 다르게 보여 준다

기록이 쌓이는 곳은 AI Gateway와 Langfuse입니다. AI Gateway에는 비용과 토큰, 예산 사용량이, Langfuse에는 호출 트레이스와 프롬프트, 응답이 남습니다. 같은 기록이라도 보는 사람마다 필요한 것이 다르기 때문에 화면을 나눴습니다.

프로젝트 담당자는 사용자 대시보드에서 담당 프로젝트의 비용과 예산, 모델과 키별 사용량, 프롬프트 캐싱 현황을 봅니다. AI플랫폼은 플랫폼 대시보드에서 Gateway와 Provider의 상태, 지연, 오류를 봅니다. 장애, 예산 소진, 비용 급증처럼 바로 확인이 필요한 신호는 Slack 경보로 비용 검토 담당, 운영 담당, 프로젝트 담당자에게 갑니다.

비용을 AI Gateway에서 보는 이유가 있습니다. LLM 비용은 호출할 때마다 발생합니다. 그런데 기존에 사용하던 Bedrock 청구 데이터는 사용 이틀 뒤에야 반영됐고, 그때까지는 비용을 알 수 없었습니다. AI Gateway는 호출할 때 토큰 수와 단가로 비용을 바로 계산합니다. 그래서 비용이 늘어난 뒤에 원인을 찾는 대신, 예산이 소진되거나 평소보다 사용량이 급증하는 프로젝트를 먼저 알릴 수 있게 됐습니다.

다만 두 숫자의 용도는 다릅니다. Gateway의 비용은 급증 감지와 예산 관리 같은 빠른 운영 판단에 사용하고, 정확한 청구 금액과 정산은 Provider의 비용 데이터로 확인합니다.

3.2 프롬프트 캐싱으로 비용을 줄이다

사용 현황이 프로젝트 단위로 연결되면 차단과 경보 외에 개선도 할 수 있습니다. 플랫폼은 비용이 늘어난 곳을 찾아 각 팀에 보여 주고, 적용할 방법은 서비스 팀이 품질을 확인한 뒤 선택합니다. 아래 그림은 그 과정을 설명하려고 만든 예시로, 프로젝트 이름과 비용, 비율 모두 실제 값이 아닙니다.

먼저 이번 달 전체 비용과 캐시 비율(입력 토큰 중 캐시에서 읽은 비율), 예산 사용률을 보고, 그다음 프로젝트별로 나눠 봅니다. 이 예시에서 프로젝트 A는 전체 비용의 45%를 사용하고 예산 사용률도 92%인데, 캐시를 전혀 사용하지 않고 있었습니다. 다른 프로젝트들은 입력 토큰의 60~80% 정도를 캐시에서 읽고 있었습니다.

그래서 프롬프트 캐싱 최적화부터 시작했습니다. 반복되는 시스템 프롬프트, 도구 설명, 참고 문서가 캐싱되는지 프로젝트별로 확인하고, 캐시 비율이 낮은 프로젝트에 적용 방법을 안내한 뒤, 같은 대시보드에서 캐싱과 비용 변화를 다시 확인합니다.

여기부터는 실제 측정값이고, 프로젝트 이름만 변경했습니다. 요청마다 달라지는 내용을 system 프롬프트에서 user 메시지로 옮기고, system 프롬프트에 cache_control을 붙였습니다. 프로젝트 A에 프롬프트 캐싱을 적용하고 전후를 비교했더니, 캐시 비율이 5%에서 97%가 됐습니다. 요청 1건당 비용은 84% 줄었습니다. 대신 평균 응답 시간은 0.79초에서 1.33초로 늘었습니다. 게이트웨이(LiteLLM)가 요청마다 Gemini 캐시를 한 번 더 조회하는 처리가 더해졌기 때문입니다.

모델과 프롬프트가 변경되면 캐싱 상태도 달라지므로, 대시보드에서 찾고, 적용하고, 다시 확인하는 과정을 다른 프로젝트에도 반복하고 있습니다.

플랫폼의 모델 제공 정책으로 비용을 줄일 수도 있습니다. 예를 들어 Amazon Bedrock의 Global 교차 리전 추론은 Geographic 교차 리전 추론보다 입력과 출력 토큰 단가가 약 10% 낮습니다. 데이터 처리 지역 요건을 충족하는 과제라면, Gateway에 Global 추론 경로의 모델만 등록하고 허용 모델을 그 범위로 제한할 수 있습니다.

3.3 예산은 넘기 전에 알린다

예산은 프로젝트마다 정합니다. AI Studio에서 예산과 한도를 신청하고, 사용률이 오르면 Slack으로 담당자에게 경보를 보내고, 예산을 다 사용하면 AI Gateway가 호출을 제한합니다. 더 필요하면 AI Studio에서 예산 변경을 요청하고, 조정한 예산은 다시 AI Gateway에 반영됩니다.

이 흐름이 가능한 것은 AI Gateway가 호출마다 비용을 계산하기 때문입니다. 청구 데이터가 반영될 때까지 기다리지 않고, 예산을 넘기 전에 알릴 수 있습니다.

3.4 민감정보는 처리 환경부터 나눈다

보안은 민감정보를 어디서 처리할지 정하는 것부터 시작합니다. 민감정보가 담긴 요청은 AI Gateway를 거쳐 사내 자체 서빙인 AI Platform으로 보냅니다. 외부로 나가지 않기 때문에 검토 범위도 줄어듭니다. 일반 업무 정보는 Bedrock, Azure, GCP 같은 외부 Provider로 보낼 수 있습니다.

Provider마다 보안 기준이 다르기 때문에, 어떤 정보를 어디로 보낼지는 처리 환경 기준으로 나눕니다. AI Studio는 신청 단계에서 데이터 특성에 맞는 사용 범위를 연결하고, AI Gateway는 승인된 모델과 호출 경로를 적용합니다.

3.5 가드레일은 실험으로 기준을 만든다

모든 정책을 설정값 하나로 바로 적용할 수는 없습니다. 민감정보 가드레일처럼 탐지 범위와 정확도, 지연을 실험하며 기준을 정해야 하는 영역도 있습니다. AI Gateway에는 이런 가드레일 모듈을 추가할 수 있습니다. 예를 들어 PII(personally identifiable information, 이름이나 전화번호처럼 개인을 알아볼 수 있는 정보)를 탐지하고 마스킹하는 모듈을 Gateway 설정으로 추가하면, 서비스 코드는 그대로 두고 모든 호출에 같은 기준으로 검사가 적용됩니다.

가드레일은 AI Gateway를 지나는 호출의 세 단계에 적용할 수 있습니다. LLM에 보내기 전인 pre_call 단계에서는 민감정보를 탐지해 마스킹하거나 차단합니다. 호출 중인 during_call 단계에서는 LLM 호출과 동시에 입력을 검사합니다. 응답을 받은 뒤인 post_call 단계에서는 응답을 검사하고, 마스킹한 값을 복원합니다.

여기서 플랫폼과 전문 조직은 역할을 나눕니다. AI플랫폼은 적용할 수 있는 모듈을 조사하고 첫 실험을 해서 탐지 결과와 지연 같은 정보를 공유하고, 보안 담당 조직이 같은 실험을 직접 해 볼 환경도 제공합니다. 무엇을 탐지하고 어느 조건에서 막을지는 보안 담당 조직이 정합니다. 실험 결과를 정책 담당자가 판단할 수 있게 정리해 전달하는 데까지를 플랫폼의 역할로 봅니다.

pre_call 가드레일은 항목마다 MASK나 BLOCK을 정합니다. MASK는 서비스가 전화번호가 담긴 요청을 보내면, LLM은 전화번호 자리가 가려진 요청을 받고, 서비스가 받는 응답에는 원래 값이 되돌아가는 방식입니다. LLM은 실제 값을 보지 않고도 답을 만들 수 있습니다.

BLOCK은 카드 번호처럼 보내서는 안 되는 정보가 들어오면 LLM을 호출하지 않고 바로 오류로 응답합니다. 민감정보가 외부로 나갈 일이 처음부터 생기지 않습니다.

3.6 기록으로 검토 결과를 다시 확인한다

모든 호출이 프로젝트 이름으로 남기 때문에, 검토에서 정한 대로 지키고 있는지 기록으로 확인할 수 있습니다. 예를 들어 개인정보를 보내지 않기로 했는데 트레이스에서 개인정보가 발견되면 바로 찾을 수 있습니다. 승인한 목적에만 사용하기로 했는데 승인하지 않은 다른 서비스에서 같은 키로 호출이 들어오는 것도 기록으로 확인할 수 있습니다.

개선 대상에는 정책 자체도 들어갑니다. 특정 항목에서 예외 신청이 반복되거나 기본 허용 범위가 실제 사용과 맞지 않으면, 검토 기록을 근거로 담당 조직과 기준을 다시 논의합니다. 초기에는 넓게 검토하고, 기록을 보며 정말 판단이 필요한 항목만 남겨 가는 방식입니다.

결과적으로 비용 쪽은 비용 확인, 비용 최적화, 예산 조정으로 FinOps(비용 운영)를, 보안 쪽은 민감정보 분리, 가드레일 적용, 사고 추적으로 SecOps(보안 운영)를 합니다. AI Gateway를 지나는 LLM 호출은 이제 FinOps와 SecOps로 운영할 수 있습니다. FinOps는 비용 담당 조직과, SecOps는 보안 담당 조직과 함께 운영합니다.

4. LLM 호출에서 Agent로 확장하다

4.1 Agent는 세 가지를 더 확인해야 한다

LLM 호출과 프로젝트 단위의 거버넌스를 먼저 정리한 이유는 Agent 호출도 AI Gateway와 프로젝트 설정을 그대로 거치기 때문입니다. Agent도 LLM을 호출하기 때문에 예산, 허용 모델, 트레이스, 가드레일 같은 LLM 거버넌스가 그대로 적용됩니다. Agent마다 모델 접근, 예산, 프로젝트별 기록을 새로 구현하지 않아도 됩니다.

다만 Agent는 답을 만드는 데서 그치지 않고 도구를 실행합니다. 그래서 세 가지를 더 확인해야 합니다.

첫째, 누가 부르는가입니다. 여러 사람이 Agent를 호출하기 때문에 허용한 채널과 사용자만 부를 수 있어야 합니다. 둘째, 어떤 도구를 사용하는가입니다. Agent는 MCP 도구를 호출하기 때문에 허용한 도구만 사용할 수 있어야 합니다. 셋째, 누구 권한으로 조회하는가입니다. Agent가 사내 데이터를 조회할 때는 요청자 정보를 함께 전달해야 합니다.

이 세 가지를 호출 경로의 각 단계에 적용하면 단계마다 허용 목록과 기본값이 생깁니다. Slack 사용자가 요청하면 먼저 Agent에서 허용한 채널과 사용자만 통과합니다. 새 Agent는 허용한 채널과 사용자가 없는 상태로 시작합니다. Agent가 도구를 부르면 AI Gateway의 MCP Servers에서 허용한 도구만 통과하고, 새 도구는 허용하기 전에는 사용할 수 없습니다. 마지막으로 보안 검토를 마친 사내 MCP 서버에 요청자 정보가 전달되고, 조회 권한은 각 시스템이 판단합니다.

4.2 누가 부를 수 있는가

AI Studio의 Agent 설정에서 허용 채널과 허용 사용자를 정합니다. 목록에 있는 채널과 사용자가 부르면 Agent가 요청을 받고, 목록 밖의 채널이나 사용자가 부르면 Agent는 응답하지 않습니다. 새 Agent는 목록에 넣은 대상만 허용합니다. 처음부터 누구나 부를 수 있는 Agent는 만들지 않는다는 원칙입니다. 이미 운영 중인 Agent에도 이 제한을 넓혀 적용해 가고 있습니다. 아래 그림은 예시 화면입니다.

4.3 어떤 도구를 사용할 수 있는가

MCP 서버는 연동 전에 보안 검토를 거칩니다. 플랫폼은 보안 검토를 마친 MCP 서버만 목록에 올리고, Agent를 만드는 사람은 이 목록에서만 연결할 서버를 선택합니다. 검토 전이거나 목록에 없는 외부 MCP 서버는 선택할 수 없습니다. 한 번 검토한 서버는 목록으로 관리하기 때문에, 다른 Agent가 같은 서버를 사용할 때 같은 검토를 반복하지 않아도 됩니다. 아래 그림은 예시 화면입니다.

MCP 서버를 연결해도 끝이 아닙니다. AI Gateway에서 도구마다 허용 여부를 정합니다. 예시의 Text-to-SQL MCP에는 테이블을 조회하는 도구, 쿼리를 실행하는 도구, 테이블을 만들고 지우는 도구까지 네 개가 있습니다. 이 Agent에는 읽기 도구 두 개만 켜고, 쓰기와 삭제 도구는 꺼 둡니다. 켜진 도구만 목록에 보이고 호출할 수 있습니다. MCP 서버에 새 도구가 추가되면 꺼진 채로 들어오기 때문에, 서버 쪽이 변경돼도 허용하기 전까지는 Agent의 동작 범위가 넓어지지 않습니다. 아래 그림은 예시 화면입니다.

4.4 누구의 권한으로 조회하는가

Agent에게 넓은 권한을 따로 주면, Agent를 거치는 순간 요청자가 원래 볼 수 없던 데이터까지 조회될 수 있습니다. 그래서 Agent에게 권한을 따로 주지 않고, 묻는 사람의 권한으로 실행합니다. Text-to-SQL Agent가 대표적인 예입니다.

요청자가 Slack에서 질문하면 Agent는 이 질문을 전달하고, Text-to-SQL MCP가 SQL을 만듭니다. 쿼리는 Agent 계정이 아니라 요청자 계정으로 실행됩니다. 요청자의 사내 계정이 처음부터 끝까지 함께 전달되기 때문에, 같은 질문을 해도 사람마다 결과가 다릅니다. 권한이 있는 사용자는 볼 수 있는 데이터로 결과를 받고, 권한이 없는 사용자에게는 그 데이터가 조회되지 않습니다.

4.5 정책은 플랫폼이 맡고, 만드는 사람은 Agent에 집중한다

앞에서 본 세 가지, 즉 누가 부를 수 있는지, 어떤 도구를 사용할 수 있는지, 누구 권한으로 조회하는지를 Agent를 만드는 팀이 각자 구현하면 Agent마다 하나씩 빠지는 항목이 생깁니다. 어떤 Agent는 요청자 정보를 전달하지 않고, 어떤 Agent는 도구 권한을 제한하지 않습니다. 이렇게 빠진 항목은 점검할 때 Agent마다 하나씩 확인해야 하고, Agent가 늘수록 찾기 어려워집니다. 반면 AI Studio에서 Agent를 만들면 세 가지가 기본 설정으로 들어가기 때문에, 만들 때부터 공통 정책이 모두 적용됩니다.

Agent는 AI Studio에서 채널과 사용자, 도구를 선택해 만들고, 공용 Helm 차트로 배포합니다. 공용 차트에는 개발자가 덮어쓸 수 없는 공통 설정이 들어 있습니다. 모델과 MCP의 호출 경로를 고정하고, 터미널, 파일, 코드 실행, 브라우저 같은 위험한 도구 묶음을 제한합니다. 필요한 설정이 없거나 시크릿을 복호화하지 못하면 Agent는 실행되지 않습니다. 공용 차트는 Agent 취약점 검토를 마쳤습니다.

이렇게 배포된 Agent가 Slack에서 사용자와 대화합니다. Agent의 모델 호출은 AI Gateway를, 도구 호출은 MCP Servers를 거치고, 트레이스는 Langfuse에 남고, 사용자 피드백 점수는 Slack에서 수집합니다. 어떤 Agent 프레임워크를 사용하더라도 추적과 보안 기준을 같게 유지하는 것이 목표입니다.

그 결과 플랫폼과 Agent를 만드는 사람의 역할이 나뉩니다. 플랫폼은 AI 거버넌스를 맡습니다. LLM 호출에는 예산, 허용 모델, 트레이스, 가드레일, 서비스 카탈로그 연동을 적용하고, Agent 호출에는 채널과 사용자 허용, 보안 검토를 마친 MCP, 요청자 정보 전달, 사용자 피드백 수집을 적용합니다. Agent를 만드는 사람은 채널과 사용자, 모델, 도구를 선택하고, 스킬과 프롬프트를 개발하고, 기록을 보고 개선하는 일에 집중합니다.

5. 거버넌스를 맡는 플랫폼도 보호해야 한다

호출과 정책을 한곳에 모으면 권한과 데이터도 한곳에 모입니다. 거버넌스를 맡는 플랫폼이 뚫리면 그 영향은 여러 과제로 번집니다. 이 장의 작업은 보안 담당 조직, 인프라 담당 조직과 함께 진행했습니다. 위협 시나리오 점검과 계정, 네트워크 분리 설계는 보안 담당 조직이 맡았고, AI플랫폼은 그 설계를 플랫폼에 적용했습니다.

5.1 키와 호출이 모이는 곳은 분리해야 했다

AI플랫폼에는 Provider 호출 권한과 크레덴셜이 모이고, 프롬프트와 응답, 도구 호출 결과가 이 경로를 지납니다. 그래서 다른 서비스와 같은 네트워크에 두는 것이 위험했습니다.

첫 번째 위험은 일반 서비스의 취약점 하나입니다. 같은 네트워크 정책 안에 있으면, 일반 서비스 하나의 취약점이 네트워크를 따라 플랫폼까지 그대로 닿을 수 있습니다.

두 번째 위험은 플랫폼을 직접 노리는 공격입니다. 정상 권한으로 의도하지 않은 행동을 하게 만드는 프롬프트 인젝션, 관리 권한을 빼앗는 인증 우회, 서버에서 임의 명령을 실행하는 원격 코드 실행, 악성 코드가 들어간 배포판을 사용하게 되는 공급망 공격이 있습니다.

어느 쪽이든 AI플랫폼이 뚫리면 Provider 호출 권한과 크레덴셜, 프롬프트와 응답이 노출되고, 연결된 시스템까지 영향이 퍼집니다.

그래서 분리 대상을 다섯 가지 기준으로 판정했습니다. 크레덴셜을 발급하거나 중개하는지, 여러 시스템의 권한을 한곳에 가지는지, 외부 AI와 통신하는지, 여러 서비스의 정책을 집행하는 지점인지, 둘 이상의 환경을 상대하는지입니다. 하나라도 해당하면 분리 대상으로 보았고, AI Gateway(MCP 서버 포함)와 AI Studio가 여기에 해당했습니다. AI를 호출만 하는 서비스는 분리하지 않고 원래 계정에서 운영합니다.

5.2 별도 계정과 VPC로 옮기다

그래서 AI플랫폼을 별도 AWS 계정과 분리된 VPC(virtual private cloud, 클라우드 안에서 분리한 사설 네트워크)로 옮겼습니다. 들어오는 길은 AI Gateway 하나입니다. 서비스 계정의 AI 호출 서비스는 AI Gateway로만 들어오고, 기존 Gateway 주소를 그대로 사용합니다. AI Studio와 Agent도 이 계정 안에 있고, 원본 크레덴셜은 AI Gateway가 관리합니다. 계정을 옮기면서 beta와 prod 환경을 나누고, 서비스별 IAM Role과 통신 경로도 다시 정리했습니다.

나가는 길도 정했습니다. Bedrock은 IRSA(IAM Roles for Service Accounts, 쿠버네티스 파드에 AWS 권한을 주는 방식)로 인증하고, GCP는 플랫폼의 고정 IP만 허용합니다. 그래서 서비스가 AI Gateway를 거치지 않고 Provider를 직접 호출하는 길은 전사 기준으로 막혀 있습니다.

Gateway가 외부에 드러나는 범위도 줄였습니다. 메트릭과 API 문서 경로는 인증을 거쳐야만 열리고, 관리 화면에는 관리자 SSO 그룹에 속한 사용자만 로그인할 수 있습니다.

5.3 모든 호출이 지나는 경로는 멈추면 안 된다

막는 것만큼 멈추지 않는 것도 중요합니다. AI Gateway는 모든 호출이 지나는 경로이기 때문입니다.

첫째, 배포할 때 요청이 끊기지 않게 했습니다. 새 파드가 준비된 뒤에 교체하고, 종료하는 파드는 로드밸런서에서 빠진 뒤 30초를 기다려 진행 중인 요청과 스트리밍을 마칩니다. 이 시간은 타깃을 뺀 뒤에도 요청이 들어오는 시간과 요청 처리 시간을 실측해 정했습니다.

둘째, 점검이나 장애가 있어도 일부만 빠지게 했습니다. 파드를 가용 영역마다 나눠 배치하고, 동시에 중단되는 수를 제한하고, 자동으로 확장합니다.

셋째, Provider에서 오류가 나면 AI Gateway가 재시도하거나 대체 모델로 응답합니다. 서비스 쪽은 아무것도 변경하지 않아도 됩니다.

마치며

처음부터 거버넌스 플랫폼 전체를 설계한 것은 아니었습니다. AI Gateway로 호출을 연결하고 운영하던 기반이 있었고, AI 활용이 늘면서 AI Gateway에서 비용과 사용 범위를 관리할 필요가 생겼습니다.

모든 LLM과 MCP 호출은 AI Gateway 한곳을 지나고, 정책은 AI Studio에서 신청과 검토로 정합니다. 비용과 보안은 기록으로 확인하고, Agent도 같은 정책 안에서 동작합니다. 그리고 분리된 계정과 경로 통제, 무중단 운영으로 거버넌스를 맡는 플랫폼을 지킵니다.

이 일은 AI플랫폼 혼자 한 것이 아닙니다. 비용 담당 조직, 보안 담당 조직과 함께 만들었습니다.

들어가며의 그래프에 비춰 보면, 사용은 더 많은 프로젝트와 Agent로 계속 늘고 있습니다. 비용은 프로젝트별 비용과 예산 경보로, 보안은 정책과 가드레일, 분리된 계정으로 관리합니다. 관리로 줄인 만큼 사용을 더 늘릴 수 있습니다.

이전과 비교하면 각 팀이 AI를 사용하는 과정도 달라졌습니다. 예전에는 플랫폼 엔지니어가 크레덴셜을 손으로 발급해 위키로 전달했고, 프로젝트별 비용은 Provider 콘솔마다 따로 확인해야 했습니다.

지금은 AI Studio에서 신청과 발급이 이어지고 기본 조건이면 바로 발급되며, 프로젝트별 비용은 Gateway에서 바로 집계됩니다. 하나의 Gateway 크레덴셜로 여러 Provider의 허용된 모델을 공통 API로 실험할 수 있고, Provider 장애는 Gateway의 재시도와 대체 모델이 맡습니다. Provider가 모델 지원 종료를 알리면 플랫폼이 확인해 해당 모델을 사용하는 프로젝트에 안내합니다. 검토와 비용, 로그는 프로젝트 하나에 함께 남습니다.

지금까지는 LLM 호출 관리, Agent 도구별 허용, 요청자 정보 전달까지 적용했습니다. Agent가 늘면 프로젝트나 키 단위만으로는 부족해집니다. 같은 프로젝트 안에서도 Agent마다 하는 일과 위험도가 다르고, 요청 하나가 여러 번의 도구 호출로 이어지기 때문입니다. 그래서 앞으로는 Agent 단위까지 거버넌스를 더 세밀하게 만듭니다.

앞으로 할 일은 다섯 가지입니다.

1. Agent Registry: 사내에 어떤 Agent가 있고 누가 책임지는지 등록하고 관리합니다.
2. 세션 비용: 반복 호출이 끝나지 않을 때 요청 하나의 비용과 실행 횟수를 제한합니다.
3. Agent 인증과 인가: Agent 자체의 인증과 인가를 다룹니다.
4. 가드레일 확대: 가드레일을 적용하는 범위를 넓힙니다.
5. 자동 승인 확대: 자동 승인 범위를 넓혀 사람이 검토할 항목을 줄입니다.

품질 평가도 남은 과제입니다. 사용량과 비용만으로는 과제가 실제로 도움이 되는지 판단할 수 없기 때문입니다. 지금은 Agent의 Slack 피드백을 Langfuse 점수로 모으고 있고, 낮은 평가를 받은 대화에서 평가 대상을 모으는 것부터 시작합니다. 비용을 줄이거나 모델을 변경했을 때도 같은 기준으로 품질을 비교하는 것이 목표입니다.

이 글에서 말하는 AI 거버넌스는 AI 사용을 막는 장치가 아니라, AI를 안전하고 빠르게 늘리기 위한 엔지니어링입니다. 플랫폼은 공통으로 맡을 일을 제공하고, 각 팀은 허용 범위와 과제 상태를 확인하며 실험하고 개선합니다. 새로운 사용 방식이 나오면 AI Gateway와 AI Studio에 필요한 관리와 통제를 더해 가겠습니다.