트레이스 감사와 에이전트 거버넌스

앞 노트의 마지막 문단이 「그 기록을 어떻게 남기고 누가 승인하는가」로 끝났습니다. 이 노트가 그 자리입니다. 한 번 부르고 한 번 답하는 구성에서는 요청과 응답만 남기면 충분했는데, 에이전트는 한 번의 요청에 도구를 여러 번 부르고 그중 몇은 바깥 세계를 바꿉니다. 그래서 물어야 할 것이 「무엇을 답했나」에서 무엇을 근거로 무엇을 했나로 바뀝니다. 시험은 이 절을 「사고가 났는데 무엇을 봐야 하는가」와 「사고가 나기 전에 무엇을 막아야 하는가」 둘로 나눠 묻습니다.

트레이스

트레이스와 스팬

트레이스는 요청 하나가 처리되는 동안 일어난 일을 시간 순서로 이어 붙인 기록이고, 그 안의 한 단계를 스팬이라 부릅니다. 에이전트 한 번의 실행이 트레이스 하나이고, 모델 호출·검색·함수 실행이 각각 스팬입니다. 스팬은 겹쳐 쌓이므로 어느 모델 호출이 어느 도구 호출을 불렀는지가 부모 자식 관계로 남습니다.

이 구조가 중요한 이유는 에이전트의 실패가 대개 중간 단계에서 나기 때문입니다. 최종 답만 로그에 남기면 「왜 이 답이 나왔는지」를 물었을 때 댈 것이 없습니다. 검색이 엉뚱한 문서를 가져왔는지, 모델이 좋은 문서를 받고도 무시했는지, 도구가 실패했는데 그냥 넘어갔는지는 스팬을 열어야 갈립니다.

스팬의 기록 항목

스팬마다 남길 것이 정해져 있습니다 — 어느 모델의 어느 배포를 불렀는지, 토큰을 얼마나 썼는지, 얼마나 걸렸는지, 어느 도구를 어떤 인자로 불렀는지, 결과가 성공인지 실패인지입니다. 여기에 프롬프트와 응답 본문을 남길지는 따로 정합니다. 본문에는 사용자가 친 말이 그대로 들어 있어 개인정보가 섞이므로 기본은 꺼져 있고, 켜려면 명시적으로 켜야 합니다.

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.monitor.opentelemetry import configure_azure_monitor

project = AIProjectClient(
    endpoint="https://contoso-foundry.services.ai.azure.com/api/projects/rag",
    credential=DefaultAzureCredential(),
)

configure_azure_monitor(   # 프로젝트에 연결해 둔 Application Insights로 보낸다
    connection_string=project.telemetry.get_application_insights_connection_string())

os.environ["AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED"] = "true"   # 본문 기록은 기본이 꺼짐

마지막 줄이 시험이 좋아하는 자리입니다. 「트레이스를 켰는데 프롬프트 내용이 안 보인다」는 고장이 아니라 그 스위치가 꺼져 있는 것이고, 반대로 규제가 걸린 환경에서는 켜면 안 되는 스위치입니다.

저장소와 보존

트레이스는 프로젝트에 연결한 Application Insights로 흘러갑니다. 그래서 이 기능을 쓰려면 프로젝트에 그 연결이 서 있어야 하고, 연결이 없으면 화면의 트레이스 탭이 비어 있습니다. 쌓인 뒤에는 보존 기간이 곧 되짚을 수 있는 기간이 되므로, 감사 요구가 있는 환경에서는 기본 보존 기간이 요구 기간을 덮는지를 먼저 봅니다.

여기서 한 가지가 더 갈립니다. 같은 저장소에 모델 호출의 지표도 함께 쌓이는데, 지표는 「분당 몇 건이 몇 밀리초 걸렸나」처럼 묶어서 세는 값이고 트레이스는 실행 하나하나입니다. 대시보드에 세울 것은 지표이고 사고를 파고들 때 여는 것은 트레이스라, 둘 중 하나만 두면 반쪽이 됩니다 — 지표만 있으면 이상한 실행을 못 찾고, 트레이스만 있으면 무엇이 이상한지를 알 길이 없습니다.

프로버넌스

답의 출처

프로버넌스 메타데이터는 답이 어디에서 왔는지를 답과 함께 들고 다니는 정보입니다. 트레이스가 운영자를 위한 기록이라면 프로버넌스는 답을 받는 사람과 나중에 감사하는 사람을 위한 기록입니다. 둘은 남는 자리도 다릅니다 — 트레이스는 텔레메트리 저장소에, 프로버넌스는 응답 자체에 붙습니다. 그래서 트레이스를 볼 권한이 없는 사람도 프로버넌스는 봅니다. 채팅 화면 아래에 근거 문서 이름이 달려 나오는 것이 이 정보이고, 사용자가 그 자리에서 답을 확인할 수 있게 하는 것이 목적입니다.

메타데이터 항목

마지막 줄이 두 기록을 잇는 고리입니다. 응답에 붙은 요청 식별자로 트레이스를 찾을 수 있어야 「이 답이 이상하다」는 신고 하나에서 그 실행의 모든 스팬까지 거슬러 갈 수 있습니다. 이 고리가 없으면 기록이 둘 다 있어도 둘을 못 맞춥니다.

감독 모드

세 단

에이전트에게 어디까지 맡기는지가 세 단으로 갈립니다.

가르는 기준은 에이전트가 얼마나 똑똑한가가 아니라 그 동작이 되돌릴 수 있는가입니다. 같은 에이전트 안에서도 조회는 자율로 두고 전송은 승인을 받게 하는 구성이 정상이므로, 모드는 에이전트 하나에 하나가 아니라 동작마다 붙습니다.

고르는 기준

문항은 요구사항 문장에 이 기준을 심어 둡니다 — 「고객에게 메일이 나간다」·「환불이 처리된다」·「티켓 상태가 바뀐다」가 나오면 바깥 세계가 바뀌는 동작이고, 「조회한다」·「요약한다」·「초안을 만든다」는 아닙니다. 초안을 만드는 것까지는 자율로 두고 보내는 순간만 승인을 받는 구성이 실무에서 가장 흔하고 시험의 정답도 대개 그쪽입니다.

행동 제약

도구 접근 제어

에이전트가 부를 수 있는 도구를 정하는 것이 가장 강한 제약입니다. 목록에 없는 도구는 모델이 아무리 부르려 해도 부를 수 없으므로, 프롬프트로 「하지 마라」고 적는 것과 급이 다릅니다.

제약은 두 층으로 겁니다. 하나는 도구 목록 — 이 에이전트에 붙인 함수와 지식 원본이 무엇인가입니다. 다른 하나는 앞 노트에서 다룬 역할 배정 — 그 도구가 실제로 부르는 자원에 대해 에이전트의 신원이 무슨 권한을 갖는가입니다. 둘을 함께 걸어야 뜻이 있습니다. 읽기 도구만 붙여 두고 그 신원에 쓰기 권한이 남아 있으면 도구가 하나 늘어나는 순간 쓰기가 열리고, 반대로 권한만 조이고 도구를 다 붙여 두면 실패한 호출이 트레이스에 잔뜩 쌓입니다.

예산과 상한

동작을 막는 것 말고 얼마나 할 수 있는지를 막는 제약도 있습니다. 한 실행에서 도구를 부를 수 있는 횟수, 쓸 수 있는 토큰, 전체 실행 시간에 상한을 겁니다. 에이전트의 고장 중 가장 비싼 것이 같은 도구를 계속 부르며 도는 것이고, 이 상한이 없으면 그 실행이 끝나기를 기다리는 동안 비용이 계속 올라갑니다. 상한에 걸려 멈춘 실행은 실패로 기록하고 사람에게 넘깁니다.

승인 워크플로

승인 지점

승인 워크플로는 에이전트가 특정 동작 앞에서 멈추고 사람의 결정을 기다렸다가 이어 가는 구조입니다. 중요한 것은 멈추는 자리가 실행 도중이라는 점입니다. 다 끝난 뒤에 결과를 보여 주는 것은 승인이 아니라 통보이고, 되돌릴 수 없는 동작에는 소용이 없습니다.

승인을 걸 자리는 앞의 기준을 그대로 씁니다 — 바깥 세계를 바꾸는 도구, 돈이 오가는 도구, 개인정보를 내보내는 도구입니다. 여기에 하나가 더 붙습니다. 근거 점수가 낮은 답이나 프롬프트 실드에 걸린 요청은 동작의 종류와 상관없이 사람에게 넘깁니다.

승인 기록

승인 자체가 감사 대상입니다. 누가 언제 무엇을 승인했는지, 승인할 때 화면에 무엇이 보였는지가 남아야 나중에 책임을 가릴 수 있습니다. 그래서 승인 기록은 트레이스의 스팬으로 함께 남기고 프로버넌스에도 승인자를 적습니다. 승인 화면에 도구 이름만 보이고 인자가 안 보이면 그 승인은 형식이 됩니다 — 무엇에 동의했는지 모르는 채 누른 것이기 때문입니다.

연습 문제

1. 에이전트가 이상한 답을 냈다는 신고를 받았습니다. 검색이 잘못 가져온 것인지 모델이 무시한 것인지 가리려 합니다. 봐야 할 것은?
   ① 최종 응답 로그
   ② 해당 실행의 트레이스에서 검색 스팬과 모델 스팬
   ③ 배포의 TPM 사용량
   ④ 콘텐츠 필터의 차단 이벤트

   ②. 검색 스팬에 무엇을 가져왔는지가, 모델 스팬에 그것을 받고 무엇을 냈는지가 남습니다. ①만으로는 중간을 못 봅니다.
2. 본문의 코드에서 마지막 줄을 지우면 무엇이 달라집니까?
   ① 트레이스가 아예 수집되지 않는다
   ② 스팬은 남지만 프롬프트와 응답 본문이 남지 않는다
   ③ Application Insights 연결이 끊긴다
   ④ 토큰 사용량이 기록되지 않는다

   ②. 그 환경 변수는 본문 기록만 켜고 끕니다. 수집 자체는 configure_azure_monitor 호출이 맡으므로 ①과 ③은 아닙니다.
3. 개인정보 보호 요구가 엄격한 환경에서 트레이스를 구성합니다. 알맞은 선택은?
   ① 본문 기록을 켜고 보존 기간을 늘린다
   ② 본문 기록은 끄고 스팬의 메타데이터만 남긴다
   ③ 트레이스를 아예 끈다
   ④ 본문을 켜되 로그를 로컬 파일로 내린다

   ②. 도구 호출과 지연·토큰 같은 메타데이터만으로도 대부분의 진단이 되고, 사용자가 친 말은 안 남습니다. ③은 감사 자체를 포기하는 것이고 ④는 저장 위치만 바꿀 뿐 내용은 그대로입니다.
4. 에이전트가 고객 문의를 읽고 환불을 처리합니다. 가장 알맞은 감독 모드는?
   ① 자율 — 기록만 남긴다
   ② 반자율 — 조회는 자율, 환불 실행은 승인
   ③ 사람 개입 — 조회까지 건건이 승인
   ④ 자율로 두고 매일 야간에 일괄 검토

   ②. 되돌릴 수 없는 것은 환불뿐이므로 거기만 멈춥니다. ③은 모든 조회까지 막아 에이전트를 쓰는 뜻이 없어지고, ④는 이미 나간 돈을 뒤에 보는 것이라 승인이 아닙니다.
5. 에이전트에 읽기 전용 도구만 붙였지만 그 관리 ID에는 Storage Blob Data Contributor가 배정되어 있습니다. 이 구성의 위험은?
   ① 도구 호출이 403으로 실패한다
   ② 도구를 하나 추가하는 순간 쓰기가 열린다
   ③ 트레이스가 수집되지 않는다
   ④ 토큰 비용이 늘어난다

   ②. 도구 목록과 역할 배정은 서로 다른 층의 제약이라 둘 다 조여야 합니다. 지금은 한쪽만 좁혀 둔 상태입니다.
6. 도구를 부를 수 있는 횟수에 상한을 두는 가장 큰 이유는?
   ① 트레이스 용량을 줄이려고
   ② 같은 도구를 반복해 부르며 도는 실행이 비용을 계속 올리므로
   ③ 모델 버전을 고정하려고
   ④ 승인 화면을 줄이려고

   ②. 상한은 고장난 실행을 유한한 시간 안에 끝내는 장치이고, 걸려 멈춘 실행은 실패로 기록해 사람에게 넘깁니다.

정리하면 기록은 뒤를 보는 장치이고 제약은 앞을 막는 장치입니다. 시험에서 「이미 일어난 일」이 나오면 트레이스와 프로버넌스를, 「일어나면 안 되는 일」이 나오면 도구 접근 제어와 승인 워크플로를 고릅니다.