AI 앱·에이전트 인프라와 배포 구성

앞 두 노트가 「무엇으로 만드는가」였다면 이 노트는 「어디에 어떻게 올리는가」입니다. 시험은 이 자리를 아키텍처 그림으로 묻습니다 — 구성 요소를 늘어놓고 어느 것이 빠졌는지, 또는 요구사항 셋을 주고 어느 배포 옵션이 맞는지 고르게 합니다. 옵션 이름을 외우는 것만으로는 안 되고 각 옵션이 무엇을 보장하고 무엇을 보장하지 않는지를 알아야 갈립니다.

리전, 용량, 데이터가 놓이는 자리

셋을 이 순서로 정합니다.

1. 리전 — 쓰려는 모델이 그 리전에 있는지부터 봅니다. 모델은 리전마다 제공 여부가 다르고, 새 모델일수록 처음에는 몇 개 리전에만 있습니다.
2. 데이터 상주 — 규제로 「데이터가 국경을 넘지 않아야 한다」가 걸리면 리전 선택이 먼저이고 모델은 그 안에서 고릅니다. 순서가 뒤집히면 나중에 못 물립니다.
3. 용량 — 그 리전의 그 모델에 우리 구독이 받은 할당량이 필요한 처리량을 감당하는지 봅니다.

여기서 시험이 즐겨 내는 함정이 지연과 데이터 상주의 충돌입니다. 사용자는 한국에 있는데 쓰려는 모델이 한국 리전에 없으면, 가까운 리전을 골라 지연을 줄일지 규제를 지킬지 정해야 합니다. 규제가 명시된 문항이면 언제나 규제가 이깁니다.

에이전트 솔루션에 반드시 서는 구성 요소

에이전트 하나를 운영에 올리면 최소한 이만큼이 함께 섭니다.

프로젝트가 이 자원들을 부르는 통로가 연결(connection)입니다. 아키텍처 문항에서 「Search는 만들었는데 에이전트가 인덱스를 못 본다」가 나오면 연결이 없거나 관리 ID에 역할이 안 붙은 것입니다.

배포 옵션 — 무엇을 사는 것인가

표준과 프로비저닝드를 가르는 물음은 「지연이 튀어도 되는가」입니다. 표준은 공용 용량이라 이웃의 부하가 우리 응답 시간에 비칠 수 있고, 프로비저닝드는 처리량을 미리 떼어 두므로 그 흔들림이 줄어드는 대신 안 써도 요금이 나갑니다. 평균 부하가 아니라 최대 부하를 기준으로 재는 것이 요령이고, 낮에만 몰리는 워크로드라면 프로비저닝드를 기본 용량으로 깔고 넘치는 분을 표준 배포로 흘리는 구성이 답이 됩니다.

컨테이너와 엣지는 다른 축입니다. 「인터넷이 끊긴 환경」·「데이터가 시설 밖으로 나가면 안 된다」가 나오면 클라우드 엔드포인트로는 못 풀고, 컨테이너로 내려보낼 수 있는 작은 모델과 도구를 골라야 합니다. 가용성은 리전 하나 안에서 얻는 것이 아니라 배포를 둘 이상 두고 앞에서 나눠 보내는 것으로 얻습니다. 재해 복구 요구가 나오면 두 번째 리전에 같은 배포 이름으로 배포를 하나 더 만들어 두는 답을 찾습니다 — 이름을 같게 두면 장애 때 엔드포인트만 바꿔도 코드가 그대로 돕니다.

에이전트 자체에도 배포 설정이 붙습니다. 에이전트는 어떤 모델 배포를 쓸지, 어떤 도구를 갖는지, 어떤 지시문으로 도는지를 묶은 정의이므로 이것도 환경마다 따로 서야 합니다. 개발에서 손으로 만든 에이전트를 운영에서 다시 손으로 만들면 지시문 한 줄이 어긋나도 알 길이 없으니, 에이전트 정의도 파일에 적어 두고 배포 단계에서 만들게 합니다.

배포 이름과 버전 업데이트 정책

모델을 올릴 때 정하는 값이 셋입니다. 어떤 모델인지, 어떤 버전인지, 그리고 코드가 부를 배포 이름입니다.

az cognitiveservices account deployment create \
  --name my-foundry-resource \
  --resource-group rg-ailab \
  --deployment-name support-chat \
  --model-name gpt-4o \
  --model-version 2024-11-20 \
  --model-format OpenAI \
  --sku-name GlobalStandard \
  --sku-capacity 60

--deployment-name이 코드가 쓰는 이름입니다. 여기에 support-chat처럼 역할을 적어 두면 나중에 모델을 바꿔도 앱 코드를 안 고칩니다. 반대로 gpt-4o라고 모델 이름을 그대로 배포 이름에 쓰면 모델을 갈아 끼우는 순간 이름이 거짓말이 되고, 앱마다 흩어진 문자열을 다 고쳐야 합니다.

버전을 자동으로 올릴지도 배포에 붙는 설정입니다.

운영 배포에는 자동 승격을 켜지 않는 것이 정석입니다. 모델이 바뀌면 같은 프롬프트가 다른 답을 낼 수 있어 평가를 다시 돌려야 하기 때문입니다. 다만 NoAutoUpgrade를 골랐다면 은퇴 날짜를 달력에 두는 일이 함께 따라옵니다 — 그러지 않으면 어느 날 배포가 그대로 멈춥니다.

환경을 가르고 파이프라인으로 잇는다

개발·스테이징·운영을 프로젝트가 아니라 리소스로 가릅니다. 앞 노트에서 봤듯 할당량과 배포가 리소스에 붙으므로, 프로젝트만 갈라 두면 개발의 부하 시험이 운영의 토큰 예산을 먹습니다.

환경 셋이 같은 모양이어야 하니 손으로 만들지 않고 IaC(코드로 쓰는 인프라 정의)로 찍어 냅니다. ARM 템플릿·Bicep·Terraform 중 무엇을 쓰든 원리는 같습니다 — 리소스·배포·역할 배정을 파일에 적어 두고 환경마다 매개변수만 바꿔 같은 정의를 세 번 찍습니다. 아래는 배포 하나를 ARM 템플릿으로 적은 것입니다.

{
  "type": "Microsoft.CognitiveServices/accounts/deployments",
  "apiVersion": "2024-10-01",
  "name": "[concat(parameters('foundryAccount'), '/support-chat')]",
  "sku": { "name": "GlobalStandard", "capacity": "[parameters('modelCapacity')]" },
  "properties": {
    "model": { "format": "OpenAI", "name": "gpt-4o", "version": "2024-11-20" },
    "versionUpgradeOption": "NoAutoUpgrade"
  }
}

환경마다 달라지는 것은 foundryAccount와 modelCapacity 두 매개변수뿐이고 배포 이름 support-chat은 세 환경에서 같습니다. 이름을 같게 두어야 앱의 설정에서 엔드포인트만 바꿔 환경을 옮길 수 있습니다.

CI/CD에서 잊기 쉬운 것이 프롬프트와 평가 자산도 배포물이라는 점입니다. 프롬프트 템플릿, 평가 데이터셋, 평가 기준을 코드와 같은 저장소에 두고 같은 커밋으로 묶어야 「어제 답이 왜 달라졌는가」에 답할 수 있습니다. 파이프라인의 최소 순서는 정해져 있습니다 — 인프라를 찍고, 프롬프트와 앱을 배포하고, 평가를 돌려 기준을 넘겨야 다음 환경으로 승격합니다. 평가가 게이트에 없으면 CI/CD가 있어도 품질 회귀는 그냥 통과합니다.

연습 문제

1. 사용자는 전원 국내에 있고 규제로 데이터가 국외로 나갈 수 없습니다. 그런데 쓰려던 모델이 국내 리전에 없습니다. 가장 알맞은 대응은?
   ① 지연을 감수하고 가까운 해외 리전에 배포한다
   ② 국내 리전에서 쓸 수 있는 다른 모델로 요구사항을 다시 검토한다
   ③ 해외 리전에 배포하고 로그만 국내에 남긴다
   ④ 관리형 컴퓨트로 올리면 상주 요건이 사라진다

   ②. 규제가 명시되면 규제가 리전을 정하고 모델은 그 안에서 고릅니다. ③은 데이터가 이미 국경을 넘고, ④는 컴퓨트도 어느 리전엔가 서므로 요건이 사라지지 않습니다.
2. 「낮 시간대에 요청이 몰리고 응답 시간이 일정해야 하지만, 밤에는 거의 요청이 없다」에 가장 알맞은 구성은?
   ① 표준 배포 하나
   ② 프로비저닝드 배포 하나만 최대 부하에 맞춰
   ③ 프로비저닝드로 기본 용량을 깔고 넘치는 분을 표준 배포로 흘린다
   ④ 관리형 컴퓨트

   ③. ①은 지연이 흔들리고, ②는 밤새 안 쓰는 용량에 요금이 나갑니다.
3. 위 az 명령에서 앱 코드가 model= 인자로 넘겨야 하는 값은?
   ① gpt-4o
   ② 2024-11-20
   ③ support-chat
   ④ my-foundry-resource

   ③. 호출에 쓰는 것은 배포 이름입니다.
4. 운영 배포의 versionUpgradeOption으로 OnceNewDefaultVersionAvailable을 골랐을 때 생길 수 있는 문제는?
   ① 배포가 은퇴 날짜에 멈춘다
   ② 평가를 다시 돌리지 않은 채 모델이 바뀌어 응답 품질이 조용히 달라진다
   ③ 할당량이 자동으로 줄어든다
   ④ 배포 이름이 바뀐다

   ②. ①은 NoAutoUpgrade를 고른 쪽이 감수하는 위험입니다.
5. 개발·스테이징·운영을 한 Foundry 리소스 안의 프로젝트 셋으로 가른 설계의 문제는?
   ① 프로젝트마다 에이전트를 따로 못 만든다
   ② 셋이 같은 리소스의 할당량을 나눠 써서 개발 부하가 운영에 번진다
   ③ 연결을 만들 수 없다
   ④ IaC로 정의할 수 없다

   ②. 할당량과 배포는 리소스·리전에 붙습니다.
6. 다음 중 CI/CD 파이프라인에서 프롬프트·평가 자산을 앱 코드와 같은 커밋으로 묶어야 하는 이유로 가장 알맞은 것은?
   ① 저장소 용량을 아끼려고
   ② 어느 버전의 프롬프트가 어떤 응답을 냈는지 되짚을 수 있어야 하므로
   ③ 프롬프트는 컴파일 대상이므로
   ④ 평가를 돌리지 않아도 되므로

   ②. 프롬프트가 바뀌면 응답이 바뀌므로 프롬프트도 배포물입니다. 그리고 평가는 승격 게이트에 두어야 품질 회귀가 걸립니다.

이 절의 문항은 요구사항 문장에 답이 들어 있습니다. 「일정한 응답 시간」은 프로비저닝드, 「인터넷이 끊긴」은 컨테이너·엣지, 「데이터가 국경을」은 리전, 「환경을 갈라」는 리소스 분리입니다. 아키텍처 그림을 볼 때는 연결과 관리 ID가 그려져 있는지를 마지막에 한 번 더 봅니다 — 빠진 것을 고르는 문항에서 가장 자주 비어 있는 자리입니다.