요구 분석과 GenAI 아키텍처 설계

도메인 1의 첫 태스크는 코드를 쓰기 전의 일입니다. 시험 가이드는 이 자리에 skill 셋을 둡니다 — 요구와 제약에 맞춰 아키텍처를 설계하기, Amazon Bedrock으로 기술 개념 증명을 만들어 검증하기, 여러 배포 시나리오에 쓸 표준 구성 요소를 만들고 AWS Well-Architected Framework로 점검하기. 문항은 대개 회사의 사정을 몇 줄 서술하고 「가장 알맞은 설계」를 묻습니다. 보기 넷이 모두 동작하는 설계이므로, 어느 줄의 요구가 어느 선택을 정하는지 읽어 내는 것이 이 노트의 목표입니다.

요구와 제약

비즈니스 요구

비즈니스 요구는 이 애플리케이션이 무엇을 바꾸려는가입니다. 상담원의 응대 시간을 줄인다, 계약서 검토를 하루에서 한 시간으로 줄인다처럼 결과로 적힙니다. 요구는 곧 성공 기준이 되므로 숫자로 바꿔 두어야 합니다. 「응대가 빨라진다」가 아니라 「첫 응답까지 p95 3초 이하」, 「정확해진다」가 아니라 「검수 표본에서 사실 오류 2% 이하」처럼 적어야 뒤의 PoC가 무엇을 재야 할지 정해집니다.

기술 제약

기술 제약은 그 요구를 어떤 조건 안에서 풀어야 하는가입니다. 이 시험의 문항이 설계를 가르는 데 쓰는 제약은 대략 다섯 갈래입니다.

이 표에서 기억할 관계는 하나입니다. 요구가 「무엇을」을 정하고 제약이 「어떻게」를 정합니다. 같은 요약 기능도 데이터 거주 제약이 붙으면 모델 선택지가 줄고, 처리량 제약이 붙으면 배포 방식이 바뀝니다.

아키텍처 선택

FM과 통합 패턴

FM을 고를 때 먼저 묻는 것은 모달리티(텍스트·이미지·음성), 컨텍스트 창, 언어, 도구 호출 지원이고, 그 뒤에 품질·지연·비용의 균형을 봅니다. 자세한 선택 기준은 다음 노트가 맡고, 여기서는 그 모델에 지식을 어떻게 붙이는가의 갈래를 정합니다.

갈래는 서로 배타적이지 않습니다. 파인튜닝한 모델에 RAG를 붙이고 그것을 에이전트의 도구로 쓰는 설계도 흔합니다. 문항이 묻는 것은 「최소한으로 무엇이 필요한가」이고, 요구에 없는 층을 더한 보기는 운영 부담을 늘린 오답입니다.

배포 전략

같은 모델도 띄우는 방식이 여럿입니다. Bedrock의 온디맨드 호출은 쓴 토큰만큼 내고 용량을 미리 잡지 않습니다. 프로비저닝된 처리량(Provisioned Throughput)은 모델 단위 용량을 기간 약정으로 사서 일정한 처리량을 보장받는 방식입니다. 배치 추론은 지연이 문제되지 않는 대량 작업을 한꺼번에 넣어 처리합니다. Bedrock에 없는 모델이나 직접 다듬은 모델이면 SageMaker AI 엔드포인트가 자리이고, 거기에도 실시간·서버리스·비동기·배치 변환이 갈립니다. 「트래픽이 들쭉날쭉하고 예측이 어렵다」면 온디맨드, 「꾸준히 높은 처리량을 보장해야 한다」면 프로비저닝된 처리량, 「밤사이 백만 건을 처리하면 된다」면 배치로 읽습니다.

개념 증명

Bedrock으로 만드는 PoC

개념 증명(PoC, proof of concept)은 전면 개발에 들어가기 전에 핵심 가정이 성립하는지 작게 만들어 확인하는 일입니다. Bedrock이 PoC에 맞는 이유는 인프라를 세우지 않고 모델을 바꿔 가며 같은 질문을 던져 볼 수 있어서입니다. 콘솔의 플레이그라운드에서 후보 모델을 견주고, Knowledge Bases에 대표 문서 몇백 건을 넣어 검색을 붙이고, 같은 평가용 질문 묶음으로 Model Evaluation을 돌려 점수를 남깁니다. 이 평가용 질문 묶음은 PoC가 끝나도 버리지 않습니다. 운영 중 모델을 바꿀 때 회귀 테스트의 기준이 됩니다.

후보 모델의 지연과 토큰 수는 Converse 응답이 함께 돌려주므로 PoC 단계에서 따로 계측 도구를 붙이지 않아도 됩니다.

import boto3, statistics

runtime = boto3.client("bedrock-runtime", region_name="us-east-1")
questions = ["반품 기한은?", "배송비는 누가 내나?", "교환은 몇 번까지?"]

for model_id in ["amazon.nova-lite-v1:0", "amazon.nova-pro-v1:0"]:
    latencies, tokens = [], 0
    for q in questions:
        r = runtime.converse(modelId=model_id,
                             messages=[{"role": "user", "content": [{"text": q}]}])
        latencies.append(r["metrics"]["latencyMs"])
        tokens += r["usage"]["inputTokens"] + r["usage"]["outputTokens"]
    print(model_id, statistics.median(latencies), "ms", tokens, "tokens")

같은 질문 묶음을 모델만 바꿔 돌리고 지연·토큰을 나란히 남기면, 뒤의 비용 계산과 성능 판단이 같은 숫자에서 출발합니다.

검증의 세 축

시험 가이드는 PoC로 확인할 것을 셋으로 적습니다 — 실현 가능성, 성능 특성, 비즈니스 가치.

세 축은 차례로 걸러집니다. 정답률이 모자라면 지연을 잴 까닭이 없고, 지연이 요구를 넘으면 가치를 계산해도 쓸 수 없습니다. 전면 배포로 넘어가는 판단은 세 축이 모두 앞서 숫자로 적어 둔 성공 기준을 넘었을 때입니다. 하나라도 못 넘으면 모델·패턴·배포 방식 중 어디를 바꿀지 정하고 PoC를 다시 돕니다.

비즈니스 가치 계산의 꼴은 단순합니다. 입력 토큰 단가가 100만 토큰당 $a$ 달러, 출력이 $b$ 달러이고 요청 하나가 입력 $x$ 토큰, 출력 $y$ 토큰을 쓰면 요청당 비용은 아래와 같습니다.

표준화와 Well-Architected

표준 구성 요소

PoC가 하나에서 열로 늘면 팀마다 프롬프트 형식, 가드레일, 로깅 방식이 갈라집니다. 시험 가이드가 말하는 표준화된 기술 구성 요소는 이 갈라짐을 막는 재사용 부품입니다. 예를 들어 모델 호출을 감싸 인증·재시도·로깅을 한 번에 처리하는 공용 게이트웨이, 회사 공통 정책을 담은 가드레일 하나, Prompt Management에 올린 승인된 프롬프트 템플릿, 그리고 이것들을 한 번에 세우는 IaC 모듈(AWS CloudFormation 템플릿이나 AWS CDK 구문)입니다. 새 배포 시나리오는 이 부품을 조립해 만들고, 정책이 바뀌면 부품 하나를 고쳐 모든 시나리오에 반영합니다.

Well-Architected Framework

AWS Well-Architected Framework는 클라우드 워크로드를 점검하는 기준 묶음이고 기둥 여섯으로 나뉩니다 — 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성. 이를 실제로 적용하는 콘솔 도구가 AWS Well-Architected Tool(WA Tool)입니다. 워크로드를 정의하고 렌즈를 적용해 질문에 답하면 높은 위험(HRI)과 중간 위험(MRI)이 표시되고, 마일스톤으로 그 시점의 상태를 남겨 개선 계획을 추적합니다.

Generative AI Lens

렌즈는 Framework의 질문을 특정 기술이나 업종에 맞춰 넓힌 추가 질문 묶음이고, 그 가운데 생성형 AI 워크로드를 위한 것이 Generative AI Lens입니다. 같은 여섯 기둥을 쓰되 질문이 생성형 AI의 위험을 겨눕니다 — 프롬프트 인젝션과 출력 필터링(보안), 모델 장애에 대비한 대체 경로(안정성), 토큰 사용량과 모델 크기의 균형(비용), 환각과 응답 품질의 지속 평가(운영 우수성) 같은 것입니다. 문항에 「생성형 AI 워크로드를 모범 사례에 비추어 정기 점검하고 위험 항목을 추적하라」가 나오면 WA Tool에서 Generative AI Lens를 적용하는 것이 답의 모양입니다. 사람이 체크리스트 문서를 따로 만드는 보기는 추적과 마일스톤이 없어 밀립니다.

연습 문제

1. 다음 요구 가운데 PoC의 성공 기준으로 그대로 쓸 수 있는 것은?
   ① 상담원이 더 편하게 일한다
   ② 첫 응답까지의 p95 지연이 3초 이하다
   ③ 최신 모델을 쓴다
   ④ 고객 만족이 좋아진다

   ②. 성공 기준은 잴 수 있는 숫자여야 PoC가 넘었는지 판단할 수 있습니다. 나머지는 방향일 뿐 넘었는지 가를 선이 없습니다.
2. 사내 규정 문서가 매일 고쳐지고, 직원 질문에 최신 규정으로 답해야 합니다. ML 인력은 없습니다. 가장 알맞은 통합 패턴은?
   ① 매일 규정 문서로 FM을 파인튜닝한다
   ② Bedrock Knowledge Bases로 RAG를 구성한다
   ③ 프롬프트에 규정 전문을 붙여 넣는 템플릿을 쓴다
   ④ SageMaker AI에 오픈 모델을 띄우고 직접 학습한다

   ②. 지식이 매일 바뀌면 재학습이 아니라 검색으로 붙이는 편이 맞고, 관리형이라 인력 제약에도 맞습니다. ③은 문서가 늘면 컨텍스트 창을 넘고 매 호출 비용이 커집니다.
3. 요청 하나가 입력 1,500토큰·출력 500토큰을 쓰고, 단가가 100만 토큰당 입력 0.8달러·출력 3.2달러라 가정합니다. 하루 4만 건이면 하루 모델 비용은?

   112달러. 요청당 비용은 $(0.8 \times 1500 + 3.2 \times 500) / 10^6 = (1200 + 1600) / 10^6 = 0.0028$ 달러이고, $0.0028 \times 40000 = 112$ 달러입니다. 출력 단가를 입력·출력 합계 2,000토큰에 모두 곱하면 256달러가 나오는데, 단가는 입력과 출력에 따로 곱해야 합니다.
4. Well-Architected Framework의 기둥이 아닌 것을 둘 고르시오.
   ① 지속 가능성
   ② 확장성
   ③ 비용 최적화
   ④ 안정성
   ⑤ 사용성

   ②와 ⑤. 여섯 기둥은 운영 우수성·보안·안정성·성능 효율성·비용 최적화·지속 가능성입니다. 확장성은 안정성과 성능 효율성 안에서 다뤄질 뿐 기둥이 아닙니다.
5. 생성형 AI 워크로드 열두 개를 모범 사례에 비춰 분기마다 점검하고, 위험 항목이 줄어드는지 추적하려 합니다. 가장 알맞은 방법은?
   ① 팀마다 점검표 문서를 만들어 위키에 올린다
   ② WA Tool에 워크로드를 등록하고 Generative AI Lens를 적용해 마일스톤을 남긴다
   ③ CloudWatch 대시보드에 지연 지표를 띄운다
   ④ Bedrock Model Evaluation을 분기마다 돌린다

   ②. 렌즈 질문으로 HRI·MRI를 내고 마일스톤으로 시점별 상태를 남기는 것이 점검과 추적을 함께 하는 방법입니다. ③④는 성능과 품질 한 면만 봅니다.
6. 다섯 팀이 각자 생성형 AI 기능을 만들면서 가드레일 정책과 로깅 방식이 팀마다 다릅니다. 회사 정책이 바뀌면 다섯 곳을 따로 고쳐야 합니다. 가장 알맞은 개선은?
   ① 팀마다 정책 문서를 다시 배포한다
   ② 공용 가드레일과 호출 게이트웨이를 IaC 모듈로 만들어 모든 팀이 조립해 쓰게 한다
   ③ 팀마다 다른 FM을 쓰게 해 정책 충돌을 피한다
   ④ 모든 호출을 배치 추론으로 바꾼다

   ②. 표준화된 구성 요소를 한 곳에 두면 정책 변경이 부품 하나의 수정으로 끝납니다.