AWS가 10월 13일 Orca Security의 Discovery AI 최적화 사례를 공개했습니다. 자연어 질문을 Sonar 쿼리로 바꿔주는 보안 질의 에이전트 이야기인데, 숫자가 먼저 눈에 들어옵니다.

입력 토큰: 약 200만 개 → 약 14만 개 (93% 감소)
비용: 90% 절감 (초기 방식 대비, Orca 자체 보고)
지연시간: 약 60초 → 약 15초 (75% 단축)
운영: 2026년 3월부터 하루 수천 건 프로덕션 처리

다만 이 숫자를 남의 성공담으로만 읽으면 절반만 보는 겁니다. 진짜 내용은 구조에 있습니다.

처음 방식: 900개를 통째로 넣었다

Sonar는 900개가 넘는 클라우드 데이터 모델(EC2·S3 같은 리소스 타입)과 18개 연산자를 가진 도메인 쿼리 체계입니다. 정확한 모델명, 부모-자식 관계, 연산자를 알아야 쿼리가 됩니다.

첫 프로토타입은 가장 단순한 길을 택했습니다.

전체 스키마 900+ 정의
+ 모든 관계 타입
+ 예제 쿼리 다수
→ 가장 큰 모델에 한 프롬프트로 전달

품질은 좋았고 디자인 파트너 반응도 괜찮았습니다. 문제는 규모였습니다. 작업당 입력 토큰 약 200만 개, 60초. 여러 모델에 걸친 복잡한 쿼리는 다듬기를 반복해야 했습니다.

이건 많은 팀이 밟는 함정입니다.

“일단 다 넣으면 모델이 알아서 고르겠지”
→ 매 요청마다 900개 중 890개는 쓰레기 토큰
→ 비싼 모델 × 긴 입력 × 매번 = 요금 폭탄

바꾼 방식: 9단계로 쪼개고 모델을 나눠 맡겼다

프로덕션 구조는 RAG와 스키마 인식 쿼리 생성을 섞은 9단계 파이프라인입니다. 흐름을 단순화하면 이렇습니다.

① 컨텍스트 준비 (질문 + 조직·클라우드 메타데이터)
② 패턴 매칭 (IP·CVE·ARN은 정규식으로, LLM 없이 즉시 반환)
③ 가드레일 검사 (Nova 2 Lite)
④ 임베딩 검색 (Titan, 후보 예제 20개)
⑤ 리랭크 (Cohere Rerank 3.5, 5개로 압축)
⑥ 모델 범위 선택 (Haiku 4.5, 900개→필요한 몇 개)
⑦ 필터 생성 (Haiku 4.5, 좁혀진 스키마만 보고 작성)
⑧ 검증·재시도 (정적 검사 + Sonar API, Nova 2 Lite)
⑨ 응답 출력

핵심은 두 가지입니다.

첫째, 생성기는 전체가 아니라 고른 것만 본다.
  → 입력 토큰 200만 → 14만

둘째, 단계마다 맞는 모델을 쓴다.
  → 추론은 Haiku 4.5, 가드·검증은 Nova 2 Lite
  → 전부 최대 모델이 아니라 일에 맞는 모델

비용이 토큰보다 3%p 덜 줄었다는 대목(90% vs 93%)도 힌트입니다. 단계가 늘면 호출 수와 출력 토큰이 늘어 그만큼은 상쇄된다는 뜻입니다. 그래도 남는 게 90%라는 게 요점입니다.

사람도 루프에 있습니다. 도메인 전문가가 틀린 출력을 고쳐 예제셋에 먹이는 라벨링 워크플로가 배포 없이 정확도를 끌어올립니다.

이 사례를 읽을 때 빠뜨리기 쉬운 것

숫자를 그대로 믿기 전에 출처를 확인해야 합니다.

- Orca 자체 보고를 AWS가 전달한 고객 사례 (벤더 자료)
- 비교 기준은 통짜 프롬프트 초기 버전 (일부러 무거운 기준선)
- 달러 금액·에러율·분포는 공개 안 됨
- 이미 스키마 검색을 하던 팀은 절감폭이 작을 수 있음

즉 90%는 “우리도 90%”라는 보장이 아니라 “통짜로 넣던 팀은 이만큼 남는다”는 메시지입니다. 그래도 방향은 분명합니다. 모델을 바꾸지 않고 컨텍스트 엔지니어링과 검색·검증 구조만으로 운영 효율을 크게 올렸다는 점입니다.

CodeBridge Mini Lab: 우리 프롬프트 다이어트 30분 점검

오늘 30분만 내서 다음을 확인해 보세요.

[ ] 매 요청에 항상 붙는 문서·스키마가 있는가 (전수 조사)
[ ] 요청별로 필요한 것만 검색하는 단계가 있는가
[ ] 쉬운 요청을 규칙·정규식으로 먼저 거르는가
[ ] 단계마다 모델을 나눠 쓰고 있는가 (전부 최대 모델 금지)
[ ] 출력 검증·재시도 루프가 있는가
[ ] 입력 토큰·비용·지연을 작업당으로 재고 있는가

특히 첫 항목이 출발점입니다. 프롬프트에 “혹시 모르니” 붙인 스키마가 있다면 그게 200만 토큰의 시작입니다.

결론: 비싼 모델보다 먼저 볼 것은 컨텍스트다

이 사례가 주는 한 문장은 이렇습니다.

모델을 올리기 전에, 매번 보내는 토큰을 먼저 깎아라.

필요한 스키마만 고르고, 일에 맞는 모델을 쓰고, 검증을 붙이는 것. 이 세 가지가 90%를 만들었습니다. 이번 주에 우리 팀 프롬프트에서 가장 큰 고정 덩어리 하나를 찾아 검색 단계로 바꿔보세요. 그게 가장 싼 성능 개선입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

검색 품질·토큰 비용·지연 시간을 함께 설계하는 연습이 이 글의 9단계 이야기와 바로 이어집니다. 검색과 생성을 잇는 구조부터 손에 익혀보세요.