7장 문제: 배포·보안·운영

설계상 모든 고객 데이터가 승인 지역 R1에 남아야 합니다. 기록에서 먼저 검토할 위반은?

app: R1 / model_processing: R1
search: R1 / storage: R1
trace_export: R2 / payload=full_prompt_and_documents
access: private / identity=managed_identity
R2: 승인되지 않은 지역

1. 추적 로그의 전송 지역과 본문 포함 설정을 검토한다
2. 모델 처리 지역과 검색 리소스의 배치를 검토한다
3. 사설 접근 경로와 관리 ID의 역할 범위를 검토한다
4. 원문 저장 지역과 문서 보존 기간부터 검토한다

풀이 기록 기능을 불러오는 중…

모델 추론을 지정한 Azure geography 안에서 처리해야 합니다. 실시간 요청량이 변하며 토큰 사용량에 따라 지불하려고 합니다. 지원되는 유형 중 가장 적절한 것은?

1. Global Standard
2. Standard
3. Data Zone Standard
4. Global Batch

풀이 기록 기능을 불러오는 중…

모델 호출은 성공하지만 에이전트의 사내 도구만 실패합니다. 다음 조치는?

model_call: HTTP 200 / identity=app-id
agent_run: started / identity=agent-id
tool_call inventory: DNS resolution failed
agent_runtime: private network N1
inventory.internal: private DNS zone linked to N2 only

1. app-id의 모델 권한을 넓힌 뒤 추론 호출을 재검증한다
2. agent-id의 도구 권한을 넓힌 뒤 인가 결과를 재검증한다
3. N1의 이름 해석 연결을 고친 뒤 도구 호출을 재검증한다
4. 도구 응답 스키마를 고친 뒤 에이전트 지침을 재검증한다

풀이 기록 기능을 불러오는 중…

동일 평가셋과 고정된 출시 기준을 사용했습니다. 릴리스 게이트의 결과는?

기준: answer_pass_rate ≥ 0.90 AND unauthorized_actions == 0
이전: code=c7 / prompt=p2 / index=i4 / rate=0.93 / actions=0
후보: code=c7 / prompt=p3 / index=i4 / rate=0.95 / actions=1
smoke_test: passed

1. 후보를 출시하고 안전 기준을 1건까지 완화한다
2. 코드를 c6로 되돌리고 p3의 평가 결과를 유지한다
3. 평가셋을 교체하고 기존 두 비율을 다시 비교한다
4. 후보를 차단하고 p2 조합으로 회귀 여부를 확인한다

풀이 기록 기능을 불러오는 중…

프로젝트 호출은 성공하지만 문서 저장소 읽기는 403입니다. 최소 권한을 유지하며 확인할 항목 두 가지는?

app-id → project API: HTTP 200
agent-id → storage/documents: HTTP 403 AuthorizationPermissionMismatch
storage network: connection allowed
agent-id roles: project_scope=[agent_run] / storage_scope=[]
도구가 읽어야 할 대상: storage/documents

1. 앱 사용자의 프로젝트 역할을 구독 전체 소유자로 확대한다
2. 저장소를 실제로 호출한 agent-id에 데이터 읽기 역할이 있는지 확인한다
3. 네트워크가 허용되어 있으므로 도구가 반환한 403을 무시한다
4. 데이터 읽기 역할의 할당 범위에 대상 저장소·컨테이너가 포함되는지 확인한다

풀이 기록 기능을 불러오는 중…

동일 배포의 429 기록입니다. 현재 조정의 우선순위는?

할당: 60,000 TPM / 분당 요청 수 제한은 여유
정상 시: 20 requests/min × 예상 2,000 tokens = 40,000
변경 후: 20 requests/min × 예상 4,000 tokens = 80,000
응답: 429 / Retry-After=10
현재 재시도: 즉시 3회

1. 토큰·동시성을 낮추고 대기 시간을 반영해 재시도한다
2. 요청당 토큰을 유지하고 즉시 재시도를 분산 실행한다
3. 요청 수 제한을 늘리고 입력·출력 크기는 유지한다
4. 웹 서버 수를 늘리고 배포의 할당량은 그대로 둔다

풀이 기록 기능을 불러오는 중…

동일 질의 집합에서 지연과 오답이 함께 증가했습니다. 기록이 지지하는 조사는?

                     이전       후보
검색 p95              180ms     190ms
도구 p95              300ms    1900ms
모델 p95              900ms     910ms
답변의 근거 불일치율      3%        12%
불일치 답변별 trace: 아직 연결하지 않음

1. 모델 지연을 추적하고 불일치 답변의 모델 크기를 늘린다
2. 도구 지연을 추적하고 불일치 답변의 근거 경로를 대조한다
3. 검색 지연을 추적하고 불일치 답변의 검색 시간을 늘린다
4. 도구 지연을 줄이면 근거 불일치도 해결된 것으로 판정한다

풀이 기록 기능을 불러오는 중…

아래 구간은 겹치지 않고 순서대로 실행됐습니다. 첫 병목 개선 대상은?

trace T9 / total=12.0s
retrieval:    0.0–0.4s
tool attempt: 0.4–1.4s / timeout
retry wait:   1.4–9.4s
tool retry:   9.4–10.0s / success
model:       10.0–12.0s

1. 모델 생성 2초의 출력 길이와 배포 크기를 조정한다
2. 검색 처리 0.4초의 결과 수와 인덱스 크기를 조정한다
3. 도구 재시도 대기 8초의 정책과 실패 원인을 조사한다
4. 도구 재호출 0.6초의 응답 스키마와 파서를 조정한다

풀이 기록 기능을 불러오는 중…