게이트웨이가 프롬프트와 completion을 로깅하는 순간, 게이트웨이는 고객 서비스 에이전트의 사용자가 채팅창에 입력한 모든 것을 보유하게 된다. 거기에는 주소, 계좌번호, 자신의 건강에 대한 불만이 들어 있을 수 있다. 이 시리즈의 다른 모든 결정은 비용과 지연 시간을, 또는 통제와 편의를 맞바꿨다. 이 결정은 디버깅 가능성과 데이터 보호 의무를 맞바꾸며, 다른 모든 것이 먼저 자리 잡아야 하는 결정이기에 마지막에 온다. 9부는 플랫폼이 출시되게 만들었다. 이번 편은 시리즈를 닫는다. 무엇을 기록할지, 무엇을 지켜볼지, 규제가 무엇을 묻는지, 그리고 1부의 숫자들이 실제로 움직였는지다.

세 개의 레이어, 그리고 직접 만들어야 하는 하나

플랫폼은 이제 세 곳에서 데이터를 내보내며, 이 셋을 뒤섞는 것이 팀들이 서로 다른 말을 하는 대시보드 세 개를 갖게 되는 경위다.

  • Gateway telemetry. 5부의 tenant, 모델 alias, 환경 차원이 붙은 token 메트릭이 Application Insights로, 요청 로그가 Azure Monitor로 들어간다. 누가 무엇을 호출했고 비용이 얼마였는지에 대한 권위 있는 뷰이고, 모든 동기 요청을 보는 유일한 레이어다.
  • 애플리케이션 telemetry. orchestration 레이어 자체의 trace다. 어떤 도구가 실행됐는지, 루프가 몇 번 돌았는지, 검색된 문서 중 무엇이 프롬프트에 들어갔는지. LangSmith나 Openlayer 같은 LLM 특화 도구가 여기에 살고, 이미 Dataiku를 쓰는 데이터 사이언스 팀은 같은 데이터에 대한 자기만의 뷰를 원할 것이다. 이들 중 어느 것도 자신을 내보내는 애플리케이션을 거치지 않는 트래픽은 보지 못하며, 누군가 이 중 하나를 플랫폼의 단일 진실 원천으로 제안할 때마다 소리 내어 말할 가치가 있는 사실이다.
  • 모델과 안전 신호. content safety 차단, 거부 응답, 발동된 필터 카테고리. 이것들은 게이트웨이 정책에서 나오고 애플리케이션 레이어가 아니라 게이트웨이 레이어에 속하는데, 애플리케이션이 오작동할 때도 유지된다는 것이 핵심이기 때문이다.

플랫폼 팀이 소유하고 다른 누구도 만들지 않을 레이어는 조인이다. correlation ID 하나가 사용자 상호작용을 세 레이어 전부에 걸쳐 따라가게 해서, 도구 호출 네 번과 content safety 차단 한 번을 유발한 질문 하나가 쿼리에서 무관한 레코드 여섯 개가 아니라 하나로 보이게 하는 것이다. 8부가 그 ID를 로그 레코드에 넣었다. 이것이 그 이유였다.

무엇을 로깅하고, 무엇을 로깅하지 않을 것인가

프롬프트와 completion을 로깅하는 것은 진짜로 유용하다. 나쁜 답을 디버깅하고, 실제 트래픽으로 golden set을 만들고, 누군가 이의를 제기할 때 시스템이 무슨 말을 했는지 증명하는 방법이 이것이다. 동시에 로그 저장소를 민감도를 알 수 없는 사용자 생성 콘텐츠의 저장소로 만들고, 그 콘텐츠는 로그가 가는 모든 곳에 복제된다.

현실적인 입장은 전역이 아니라 제품별이고, 플랫폼이 모두를 대신해 내리는 결정이 아니라 소비 팀이 플랫폼과 함께 내리는 결정이다:

  • 메타데이터는 항상 로깅한다. tenant, alias, 해석된 배포와 버전, token 수, 지연 시간, 상태, 캐시 히트, content safety 결과, correlation ID. 어느 것도 사용자 콘텐츠가 아니고, 전부가 운영 질문에 답한다.
  • 콘텐츠는 예외적으로만 로깅한다. 메타데이터보다 짧은 retention으로, 옵트인한 제품에 한정해서, 그리고 5부가 요구한 대로 subscription key를 요청에서 제거한 채로.
  • 콘텐츠 로깅이 켜진 곳에서는 전량 캡처 대신 sampling한다. 대표성 있는 샘플은 대부분의 목적에 전량 캡처만큼 디버깅에 쓸모 있고, 노출을 그만큼 비례해서 줄인다.

retention 기간과 법적 근거를 chargeback 모델과 같은 문서에 적어라. 무엇을, 얼마 동안, 왜 보관하는지 정확히 말할 수 있는 플랫폼은 데이터 보호 심사에서 살아남는다. 그러지 못하는 플랫폼은 로깅을 통째로 끄라는 말을 듣게 되고, 그 비용이 훨씬 크다.

pipeline만이 아니라 프로덕션에서의 eval

9부의 eval gate는 "이 변경은 내보내도 안전한가"에 답한다. "시스템이 여전히 좋은가"에는 답하지 못하는데, 프로덕션 트래픽은 golden set이 아니고 거기서 계속 멀어지기 때문이다.

메커니즘은 두 가지이고, 서로 다른 질문에 답한다. 예약된 eval은 golden set을 프로덕션 설정에 대해 타이머로 실행하는데, 아무도 배포하지 않은 것들의 drift를 잡는다. 고정에도 불구하고 움직인 모델 버전, 다르게 재색인된 인덱스, 느려진 retrieval 경로 같은 것들이다. 샘플링된 온라인 평가는 실제 트래픽의 작은 몫을 보통 model-as-judge로 채점하며, golden set에 한 번도 담긴 적 없는 실패 유형을 알아챌 유일한 방법이다. golden set은 정의상 이미 알고 있던 실패들로 만들어지기 때문이다.

둘 다 결과를 둘 곳이 필요하고, 그곳은 다른 모든 것과 같은 자리다. tenant와 alias 차원을 가진 점수로, 지출과 지연 시간이 있는 같은 대시보드에 둔다. 별도의 도구에 사는 품질 숫자는 인시던트 때만 들여다보고 나머지 시간에는 무시된다.

거버넌스, 그리고 규제가 실제로 묻는 것

EU AI Act 아래에서 이 회사가 운영하는 것 대부분은 고위험이 아니라 제한적 위험이고, 그에 따르는 의무는 인증보다는 투명성과 추적 가능성에 관한 것이다. 그렇다고 거버넌스를 문서 작성 연습으로 취급할 이유는 되지 않는데, 감사인이 묻는 질문들이 플랫폼이 기록하거나 기록하지 않는 것들에 거의 그대로 대응되기 때문이다.

  • 어떤 모델이 어떤 애플리케이션에서 어떤 버전으로 쓰이고 있는가? model catalog와 alias 맵이 답한다. 이것들이 없으면 설문조사가 된다.
  • 어떤 데이터가 어느 공급자에게 갔고, 어디서 처리되었는가? backend pool 설정과 요청 로그가 요청 단위로 답하며, 특정 리전에 대한 데이터 레지던시 질문의 답이기도 하다.
  • 어떤 안전 통제가 적용 중이었고, 발동했는가? content safety 정책은 저장소에서 버전 관리되고 그 결과는 요청마다 로깅된다.
  • 누가 무엇을 호출할 수 있었고, 그것은 언제 바뀌었는가? tenant 설정은 Terraform이므로 답은 기억이 아니라 git 히스토리다.
  • 특정 상호작용을 재구성할 수 있는가? 그 제품에 콘텐츠 로깅이 켜져 있었을 때만 가능하고, 그 결정이 암묵적으로 두지 않고 제품별로 문서화하는 이유가 정확히 이것이다.

가져갈 요점은 이것이다. 이 질문들을 답할 수 있게 만드는 것 자체가 게이트웨이다. 다섯 애플리케이션이 다섯 모델 엔드포인트를 직접 호출하면 각 질문에 다섯 개의 다른 답이 나올 수 있고, 그것을 맞춰 보는 노력이 플랫폼 투자가 제거한 컴플라이언스 비용이다.

스코어카드

1부는 다섯 개의 목표를 세웠다. 깔끔하게 달성되지 못한 것까지 포함해 정직하게 채점한다.

  • 모든 제품 오너가 하루 안에 자기 token 지출을 본다. 달성. 3부의 정확도 등급을 보고서에 명시한 채로다. 비스트리밍과 batch는 정확, 스트리밍은 추정이며, 잔차를 공개한다.
  • 어떤 애플리케이션도 수명이 긴 모델 자격 증명을 갖지 않는다. 달성. 애플리케이션은 Entra ID 클라이언트 자격 증명과 제품 subscription key를 갖는다. 어느 쪽도 모델 엔드포인트에 닿지 않고, 폐기는 설정 변경이다.
  • 은퇴 공지는 조사가 아니라 쿼리를 낳는다. 달성. 도구 하나가 아니라 앞선 결정 세 가지가 필요했다. 고정된 버전, alias, 그리고 해석된 배포의 요청별 로깅이다.
  • 한 tenant가 다른 tenant의 quota를 소진할 수 없다. 동기 트래픽에서는 subscription별 카운터 키로 달성. batch는 컨트롤 플레인이 유일한 제출자라는 사실로 묶여 있는데, 이는 강제된 통제가 아니라 프로세스 통제이고, 그 틈은 얼버무리기보다 이름을 붙여 두어야 한다.
  • 비캐시 호출의 95 백분위 게이트웨이 지연 시간 60 ms 미만. 가정하지 말고 측정해야 하는 항목이 이것이고, 다른 이유로 내린 선택들에 가장 민감한 숫자다. content safety 검사는 모델 앞에 호출 하나를 더하고, semantic cache 조회는 embedding 호출을 더하는데, 둘 다 밀리초를 지불하는 좋은 이유로 도입되었다. 이 모두를 더하고 다시 측정하지 않은 플랫폼은 자기 SLO를 조용히 바꾼 것이다.

이것의 비용, 그리고 가치가 없어지는 지점

이 섹션이 없으면 이 시리즈는 정직하지 않을 것이다. 중앙 게이트웨이는 플랫폼 팀 하나, 부하가 아니라 스키마 때문에 고른 티어의 API Management 인스턴스, 나중에는 추가할 수 없는 모듈을 가진 Redis 캐시, 두 가지 용도를 겸하는 embeddings 배포, 그리고 실제 on-call이 있는 실제 서비스인 컨트롤 플레인이다. 이것은 상시 비용이고, 그 대가로 귀속, 거버넌스, 수명주기 스토리를 산다.

소비 애플리케이션이 대략 세 개 아래면 가치가 없다. 게이트웨이가 제거하는 조정 비용이 아직 존재하지 않고, 같은 규율은 공유 Terraform 모듈과 컨벤션으로도 얻을 수 있다. 문턱은 token 수가 아니라 모델 접근 방식의 변경에 한 팀 이상이 움직여야 하는 시점이다. 그때가 두 번째 문이 첫 번째 문보다 비싸지기 시작하는 순간이다.

다음으로 읽을 글

이것을 대규모로 운영할 때의 인프라와 플랫폼 쪽 이야기는 ercan.cloud에, 허브는 ercanermis.com에 있다.

참고 자료