FM 선택과 공급자 전환·복원력

앞 노트가 아키텍처의 큰 틀을 정했다면 이 노트는 그 안에 들어갈 모델을 고르고, 고른 모델이 언제든 바뀔 수 있다는 전제로 설계하는 일입니다. 시험 가이드의 태스크 1.2는 이 둘을 한데 묶습니다. FM을 평가해 고르는 일과, 모델이나 공급자를 바꾸거나 장애가 났을 때도 애플리케이션이 멈추지 않게 하는 일입니다. 둘이 한 태스크인 까닭은 단순합니다. 오늘 고른 모델이 석 달 뒤에도 최선이라는 보장이 없으니, 고르는 순간부터 바꿀 길을 같이 만들어 둬야 합니다.

FM 평가

성능 벤치마크

벤치마크는 정해진 문제 묶음으로 모델을 채점한 공개 점수입니다. 후보를 추리는 첫 거름망으로는 쓸모가 있지만 그대로 결정에 쓰면 안 됩니다. 공개 벤치마크는 우리 데이터가 아니고, 판(버전)마다 점수 체계가 달라 서로 다른 벤치마크의 숫자를 견줄 수 없으며, 모델이 학습 중에 문제를 봤을 가능성도 있습니다. 그래서 최종 판단은 우리 업무에서 뽑은 평가 질문 묶음으로 내립니다. Bedrock의 Model Evaluation은 이 일을 관리형으로 해 줍니다 — 자동 지표로 채점하는 방식, 사람이 채점하는 방식, 다른 모델이 채점자가 되는 LLM-as-a-Judge 방식을 고를 수 있습니다.

역량 분석

역량 분석은 모델이 할 수 있는 일의 경계를 확인하는 단계입니다. 점수보다 먼저 걸러지는 조건들이 여기 있습니다.

한계 평가

한계 평가는 모델이 어디서 틀리는지를 일부러 찾는 일입니다. 근거 없는 사실을 지어내는 환각, 긴 입력 가운데 정보를 놓치는 현상, 거절해야 할 요청을 받아들이는 경우, 특정 형식을 지키지 못하는 경우를 평가 묶음에 섞어 넣고 비율을 잽니다. 시험 문항이 「정확도는 높지만 근거 문서에 없는 내용을 덧붙인다」고 서술하면 모델 교체보다 먼저 그 한계를 다른 장치로 막을 수 있는지를 묻는 경우가 있습니다. 근거 검사나 출력 형식 강제는 도메인 3의 노트가 다룹니다.

동적 모델 전환

AppConfig로 바꾸는 모델 ID

모델 ID를 코드에 박아 두면 모델을 바꿀 때마다 배포가 필요합니다. 시험 가이드가 적은 방법은 AWS Lambda·Amazon API Gateway·AWS AppConfig 조합입니다. API Gateway가 요청을 받고, Lambda가 Bedrock을 부르되 어느 모델을 부를지는 AppConfig에 둔 설정에서 읽습니다. AWS AppConfig는 애플리케이션 설정을 코드와 따로 저장하고, 검증기와 단계적 배포 전략을 거쳐 내보내며, 문제가 생기면 이전 설정으로 되돌리는 서비스입니다.

import json, urllib.request, boto3

runtime = boto3.client("bedrock-runtime")
CONFIG_URL = ("http://localhost:2772/applications/chat-app"
              "/environments/prod/configurations/model-routing")

def handler(event, context):
    # AppConfig Lambda 확장이 설정을 캐시해 두고 이 로컬 주소로 내준다
    cfg = json.load(urllib.request.urlopen(CONFIG_URL))
    resp = runtime.converse(
        modelId=cfg["primaryModelId"],
        messages=[{"role": "user", "content": [{"text": event["body"]}]}],
    )
    return {"statusCode": 200,
            "body": resp["output"]["message"]["content"][0]["text"]}

설정 값 primaryModelId를 고쳐 AppConfig로 배포하면 Lambda 코드는 그대로인 채 다음 호출부터 새 모델이 쓰입니다. 앞 노트의 Converse API가 여기서 값을 합니다. 요청 형식이 공급자와 무관하므로 ID만 바꿔도 다른 공급자의 모델이 같은 코드로 돌아갑니다.

단계적 설정 배포

AppConfig의 배포 전략은 설정을 한 번에 모두에게 내보내지 않고 비율을 늘려 가며 내보내게 합니다. 그 사이 CloudWatch 경보가 울리면 배포가 멈추고 이전 설정으로 돌아갑니다. 모델 교체가 곧 설정 변경이므로, 새 모델을 일부 트래픽에만 먼저 보내 오류율과 지연을 보는 일도 코드 배포 없이 됩니다. 「코드를 다시 배포하지 않고」·「운영 중에」라는 말이 문항에 있으면 이 구성을 떠올립니다.

서킷 브레이커

패턴의 세 상태

서킷 브레이커는 계속 실패하는 대상을 잠시 부르지 않게 막아 장애가 번지는 것을 끊는 패턴입니다. 상태가 셋입니다. 닫힘(closed)에서는 평소처럼 호출합니다. 실패가 정해 둔 횟수를 넘으면 열림(open)으로 바뀌어 일정 시간 동안 호출을 아예 하지 않고 곧장 대체 경로로 갑니다. 그 시간이 지나면 반열림(half-open)에서 시험 호출 하나를 보내 성공하면 닫힘으로, 실패하면 다시 열림으로 돌아갑니다. 재시도와 다른 점은 이것입니다. 재시도는 한 요청 안에서 다시 부르는 것이고, 서킷 브레이커는 여러 요청에 걸쳐 「지금 그 대상은 부르지 말자」를 기억합니다.

Step Functions로 구현

AWS Step Functions로 만들 때는 회로 상태를 DynamoDB 같은 저장소에 두고 워크플로 첫 단계에서 읽습니다. 상태가 열림이면 Choice 상태가 주 모델 호출을 건너뛰고 대체 모델이나 캐시된 답으로 갑니다. 닫힘이면 주 모델을 부르되 Task 상태의 Retry로 짧은 재시도를 하고, 그래도 실패하면 Catch가 실패 횟수를 올리고 문턱을 넘었을 때 상태를 열림으로 기록합니다. 열림 기록에 만료 시각을 함께 남기면 그 시각이 지난 첫 요청이 반열림의 시험 호출이 됩니다. Step Functions가 맞는 까닭은 분기·재시도·오류 처리가 상태 머신 정의에 그대로 드러나 코드 안에 숨지 않기 때문입니다.

리전과 장애 대응

교차 리전 추론

교차 리전 추론(Cross-Region Inference)은 Bedrock이 요청을 같은 지역권 안의 여러 리전으로 나눠 보내 처리량을 늘리는 기능입니다. 모델 ID 대신 추론 프로파일 ID(예: us.로 시작하는 ID)로 호출하면, 출발 리전이 바쁠 때 Bedrock이 프로파일에 묶인 다른 리전으로 요청을 보냅니다. 요금은 출발 리전 기준이고 라우팅을 위한 별도 설정이 필요 없습니다. 「피크 시간에 스로틀링 오류가 난다」는 서술에 맞는 첫 답이 이것입니다.

다만 데이터 거주 제약과는 함께 봐야 합니다. 요청이 출발 리전 밖에서 처리될 수 있으므로, 데이터가 특정 리전을 떠나면 안 된다는 조건이 붙으면 그 지역권의 프로파일이 허용 범위 안인지 확인해야 합니다.

리전 가용성이 제한된 모델

새 모델은 몇몇 리전에서만 먼저 열리기도 합니다. 우리 워크로드가 그 모델이 없는 리전에 있으면 선택지는 둘입니다. 그 모델을 제공하는 리전의 Bedrock 엔드포인트를 직접 부르거나, 그 모델을 포함하는 교차 리전 추론 프로파일을 쓰는 것입니다. 어느 쪽이든 리전 사이로 데이터가 오가므로 지연과 규정을 함께 따집니다.

단계적 기능 저하

단계적 기능 저하(graceful degradation)는 일부가 고장 나도 전체가 멈추지 않고, 덜 좋은 형태로라도 계속 서비스하는 설계입니다. 생성형 앱에서 단계는 대개 이렇게 내려갑니다 — 주 모델 → 더 작은 대체 모델 → 비슷한 질문의 캐시된 답 → 생성 없이 검색 결과만 보여 주기 → 요청을 큐에 넣고 나중에 알림. 어디까지 내려갈지는 요구가 정합니다. 「답이 늦어도 정확해야 한다」면 큐로, 「즉시 무언가를 보여 줘야 한다」면 검색 결과로 갑니다. 이때 사용자에게 지금 축소된 응답이라는 사실을 알리는 것도 설계의 일부입니다.

연습 문제

1. 운영 중인 챗봇의 모델을 다른 공급자의 모델로 교체하려 합니다. 코드를 다시 배포하지 않고 일부 트래픽부터 바꾸려면?
   ① Lambda 환경 변수의 모델 ID를 고치고 함수를 다시 배포한다
   ② 모델 ID를 AppConfig 설정에 두고 단계적 배포 전략으로 내보낸다
   ③ API Gateway 스테이지를 모델마다 하나씩 만든다
   ④ 모델마다 SageMaker AI 엔드포인트를 띄운다

   ②. 설정을 코드와 떼어 두고 비율을 늘려 가며 배포하면, 경보가 울릴 때 자동으로 이전 설정으로 돌아가는 것까지 코드 배포 없이 됩니다. ①은 함수 재배포가 필요합니다.
2. 서킷 브레이커가 열림 상태일 때의 동작으로 옳은 것은?
   ① 실패한 요청을 지수 백오프로 세 번 다시 보낸다
   ② 주 모델을 부르지 않고 곧장 대체 경로로 보낸다
   ③ 시험 요청 하나를 주 모델로 보내 회복 여부를 본다
   ④ 모든 요청을 큐에 넣고 처리를 멈춘다

   ②. 열림은 일정 시간 호출 자체를 막는 상태입니다. ③은 반열림, ①은 재시도의 동작입니다.
3. 피크 시간에 Bedrock 호출에서 스로틀링 오류가 늘었습니다. 다른 리전으로 데이터가 나가도 같은 지역권 안이면 허용됩니다. 가장 적은 노력으로 처리량을 늘리는 방법은?
   ① 프로비저닝된 처리량을 1년 약정으로 산다
   ② 교차 리전 추론 프로파일 ID로 호출한다
   ③ 리전마다 계정을 따로 만들고 직접 분산한다
   ④ 모델을 더 큰 것으로 바꾼다

   ②. 호출 ID만 바꾸면 같은 지역권의 다른 리전으로 요청이 나뉘고 요금은 출발 리전 기준입니다. ①도 처리량은 늘지만 약정 비용과 노력이 큽니다.
4. Task 상태의 재시도를 첫 대기 2초, 배수 2로 세 번 하도록 두었습니다. 첫 호출이 실패한 뒤 세 번째 재시도를 보내기까지 기다린 시간의 합은?

   14초. 대기는 $2$, $2 \times 2 = 4$, $4 \times 2 = 8$ 초이고 합은 $2 + 4 + 8 = 14$ 초입니다.
5. 다음 중 단계적 기능 저하에 해당하는 설계를 둘 고르시오.
   ① 주 모델 장애 시 더 작은 모델로 답한다
   ② 주 모델 장애 시 오류 페이지를 보여 준다
   ③ 모델 장애 시 생성 없이 검색된 문서 목록만 보여 준다
   ④ 장애가 끝날 때까지 API Gateway를 닫는다
   ⑤ 모든 요청에 가장 큰 모델을 쓴다

   ①과 ③. 둘 다 덜 좋은 형태로라도 계속 서비스합니다. ②④는 기능을 통째로 멈추고, ⑤는 장애 대응과 무관합니다.
6. 공개 벤치마크에서 1위인 모델을 바로 채택하자는 의견이 있습니다. 이 결정 전에 먼저 할 일로 가장 알맞은 것은?
   ① 다른 벤치마크 점수와 평균을 낸다
   ② 우리 업무에서 뽑은 평가 질문 묶음으로 Bedrock Model Evaluation을 돌린다
   ③ 가장 큰 컨텍스트 창을 가진 모델을 고른다
   ④ 모델 출시일이 가장 최근인 것을 고른다

   ②. 공개 벤치마크는 우리 데이터가 아니고 판마다 체계가 달라 평균을 낼 수도 없습니다. 최종 판단은 우리 업무의 질문으로 냅니다.