Natural language security queries at Orca Security using Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Orca Security는 Amazon Bedrock 기반 자연어 질의 에이전트 Discovery AI로 900개가 넘는 Sonar 모델의 검색을 지원하며, 초기 기준선 대비 질의 비용 90%, 입력 토큰 93%, 지연 시간 75% 감소를 보고했다.

📌 핵심 요약

• Sonar 질의는 900개가 넘는 모델의 정확한 이름, 18개 연산자, 중첩 관계를 지정해야 한다. 전체 스키마를 단일 프롬프트에 넣은 초기 개념 검증은 워크로드당 약 200만 입력 토큰과 약 60초가 필요했고, 복잡한 다중 모델 질의에는 추가 보정이 필요했다.
• Discovery AI는 Amazon Bedrock에서 RAG와 스키마 인식 질의 구성을 결합한 9단계 파이프라인이다. 운영 솔루션은 하루 수천 건의 질의를 15초 응답 시간으로 처리하며, 초기 기준선 대비 질의 비용 90%, 입력 토큰 93%, 지연 시간 75% 감소를 보고했다.
• 정형 입력은 규칙 기반 Quick Matcher로 처리하고, 정확하거나 신뢰도가 높은 기존 예제가 있으면 검증된 필터를 재사용한다. 예제 검색은 Amazon Titan 임베딩으로 상위 20개를 찾은 뒤 Cohere Rerank 3.5로 상위 5개를 선정한다.
• Anthropic Claude Haiku 4.5는 관련 Sonar 모델 선택과 필터 생성을, Amazon Nova 2 Lite는 Guardrail과 Validator를 담당한다. 생성기는 선택된 스키마와 재순위화된 예제로 범위를 제한하고, 정적 검증 및 Sonar API 검증의 오류를 받아 재시도한다.
• Orca는 운영의 질문 유형·모델군·복잡도를 반영한 평가 데이터, LLM-as-judge, 세부 구간별 측정으로 변경을 배포 전에 검증한다. 또한 도메인 전문가가 출력을 교정해 예제 저장소에 반영하며, 일치 예제의 신뢰도가 낮은 운영 질의는 매일 전문가 라벨링으로 연결한다.

🧩 주요 포인트

1. 결정적 매칭·검증된 예제 재사용·관련 스키마 선별 → 요청에 필요한 처리와 문맥만 사용하도록 구성해 생성 부담을 줄이는 구조.
2. Amazon Bedrock의 단일 API와 단계별 모델 배치 → 추론 품질·속도·비용 요구에 맞춰 모델을 나누고, IAM·VPC 엔드포인트·AWS CloudTrail을 통해 보안 요구를 충족하는 구조.
3. 배포 전 세부 구간별 평가와 운영 질의의 전문가 교정 → 변경에 따른 품질 회귀를 식별하고 새로운 질문 패턴을 예제에 반영하는 지속 개선 구조.

🧠 상세 정리

1. Sonar 질의의 복잡성과 초기 접근의 한계

보안 분석가는 도메인 전용 질의 언어에 깊이 익숙하지 않아도 클라우드 인프라에 관한 답을 빠르게 얻어야 하지만, Sonar는 900개가 넘는 클라우드 인프라·애플리케이션 모델과 복잡한 관계를 다룬다. 사용자는 JSON 질의에서 정확한 모델 이름과 18개 연산자를 선택하고 클라우드 제공자에 걸친 부모·자식 계층을 탐색해야 하므로, 스키마에 대한 상당한 이해가 필요했다. Orca Security의 초기 개념 검증은 당시 사용 가능한 가장 큰 모델의 단일 프롬프트에 전체 모델 정의, 모든 관계 유형, 많은 예제를 넣었으며 설계 파트너와 내부 사용자의 반응은 긍정적이었다. 그러나 워크로드당 약 200만 입력 토큰과 약 60초의 응답 시간이 필요했고, 중첩 관계나 여러 조건을 포함한 복잡한 질의는 추가 보정이 필요한 경우가 많았다. 이후 Amazon Bedrock 기반 운영 솔루션은 하루 수천 건의 질의를 15초 응답 시간으로 처리했으며, 원문은 초기 기준선 대비 질의 비용 90%, 입력 토큰 93%, 지연 시간 75% 감소를 보고한다.

2. Amazon Bedrock 기반 구성과 모델별 역할

Discovery AI는 자연어 질문을 유효한 Discovery 필터로 바꾸기 위해 RAG와 스키마 인식 질의 구성을 결합한 9단계 파이프라인을 사용한다. Orca는 Amazon Bedrock의 단일 API로 여러 기반 모델에 접근할 수 있어 각 단계에 서로 다른 모델을 배치하면서 별도 통합을 관리할 필요가 없다는 점을 선택 이유로 설명한다. 또한 IAM, VPC 엔드포인트, AWS CloudTrail을 통한 AWS 거버넌스 통제가 Orca의 보안 요구를 충족하며, 모델에 종속되지 않는 구성은 파이프라인을 재설계하지 않고 새 모델 버전으로 교체할 수 있게 한다. 강한 추론이 필요한 모델 선택기와 생성기에는 Anthropic Claude Haiku 4.5를, 빠르고 저렴한 추론을 우선하는 Guardrail과 Validator에는 Amazon Nova 2 Lite를 배치했다. 예제 검색에는 Amazon Titan 임베딩을, 검색 후보의 관련성 재평가에는 Cohere Rerank 3.5를 사용해 단계별 역할을 나눴다.

3. 요청 문맥 설정과 결정적 매칭, 입력 선별

파이프라인은 사용자의 자연어 요청에 소속 조직, 연결된 클라우드 제공자, 요청 메타데이터를 결합하는 것으로 시작하며, 이 문맥은 고객 환경에 맞는 필터를 만드는 데 쓰인다. 이어 Quick Matcher가 정규식과 규칙으로 IP 주소, CVE, ARN, 파일 해시, Amazon Machine Image ID, Oracle Cloud Identifier, EC2 ID, URL, 알림 ID 같은 정형 입력을 탐지한다. 신뢰도 높은 패턴이 발견되면 LLM 추론 없이 미리 정의된 Discovery 필터를 반환하는 빠른 경로를 사용할 수 있고, 일치하지 않으면 다음 단계로 넘어간다. 이후 LLM Guardrail은 요청이 안전하고 관련성이 있으며 기술적이고 지원 가능한 입력인지 확인하고, 프롬프트 주입 시도나 주제에서 벗어난 요청, 지원하지 않는 입력을 차단한다. 검사를 통과하지 못한 요청에는 적절한 오류를 반환하며, 승인된 요청만 예제 검색으로 진행하므로 이후 검색·생성 단계에 전달되는 입력을 먼저 선별한다.

4. 예제 검색의 관련성과 다양성 확보

Orca는 좋은 예제가 스키마만 제공하는 것보다 자연어를 Sonar 질의로 바꾸는 방법을 생성기에 더 효율적으로 알려준다며, 예제 검색을 정확도에 가장 큰 영향을 주는 요소로 설명한다. Amazon Titan 임베딩을 이용한 단순 상위 K개 의미 검색은 빨랐지만 서로 거의 같은 예제가 반환되어 생성기가 참고할 예제의 다양성이 부족해지는 경향이 있었다. Maximal Marginal Relevance는 다양성을 높였으나 최상위 후보가 실제 정답인 경우에도 관련성을 희생하는 문제가 있어, 더 큰 후보군을 먼저 검색한 뒤 재순위화하는 방식과 비교했다. 최종 선택은 Amazon Titan 임베딩으로 가장 가까운 20개 예제를 검색하고 Cohere Rerank 3.5로 상위 5개를 추리는 방식으로, 생성기에 작고 다양하면서 관련성이 높은 예제 집합을 제공한다. 정확하거나 신뢰도가 높은 일치가 있으면 이미 검증된 필터를 바로 재사용하고, 그렇지 않으면 선정된 예제를 생성 단계로 전달한다.

5. 900개가 넘는 모델에서 필요한 스키마 선별

전체 Sonar 모델 스키마를 매 요청의 프롬프트에 넣는 것은 핵심 제약이었으며, 원문은 긴 문맥을 지원하는 모델을 사용하더라도 900개가 넘는 스키마를 모두 넣으면 비용과 정확도 모두에 악영향이 있다고 설명한다. 이를 해결하는 Model Selector는 Anthropic Claude Haiku 4.5에서 동작하며, 각 모델의 이름·목적·핵심 필드·주요 관계를 담은 간결하지만 의미 정보가 풍부한 표현을 활용한다. 선택기는 사용자 질문뿐 아니라 연결된 클라우드 제공자와 검색된 예제도 고려해, 해당 요청에 필요한 소수의 Sonar 모델을 고른다. 선택한 모델은 간결한 micro schema부터 더 상세한 mini schema까지 적절한 수준의 스키마로 생성기에 전달되며, 필요한 모델의 상세 정의와 이를 잇는 관계만 제공한다. 이 방식은 전체 데이터 구조를 매번 문맥에 싣는 부담을 줄이면서도, 실제 필터 구성에 필요한 모델과 관계 정보를 생성 단계에 공급하도록 설계됐다.

6. 도구 기반 필터 생성과 오류를 통한 재검증

생성기는 도구를 사용하는 에이전트로서 선택된 모델 스키마, 검색 예제, 사용자 문맥과 사용 가능한 도구를 바탕으로 최종 Discovery 필터를 구성하며, 요청을 유효하게 표현할 때까지 반복적으로 필터를 다듬을 수 있다. 생성 결과에는 먼저 정적 검증을 적용하고 이어 Orca의 Sonar API로 확인해 문법과 의미의 정확성을 검사한다. 생성기는 재순위화된 예제와 선택된 스키마로 범위가 제한되며, 정적 검증은 모든 모델·필드·연산자가 해당 스키마 정의에 대응하는지 확인한다. 검증에 실패하면 문제가 된 요소를 명시한 오류를 생성기에 돌려주므로 재시도는 오류 위치와 스키마에 다시 근거해 수정하는 과정이 된다. 최대 재시도 횟수까지 유효한 필터를 만들지 못하면 유효하지 않은 필터 응답을 반환하고, Quick Matcher·기존 예제 재사용·에이전트 생성 중 어느 경로든 유효한 필터를 얻으면 후처리를 거쳐 최종 응답을 준비한다.

7. 배포 전 평가와 품질 회귀 식별

Orca는 변경을 자신 있게 반복하기 위해 프로젝트 초기에 지속 평가 체계를 구축했으며, 이를 선별된 데이터셋·자동 점수화·세부 구간별 측정의 조합으로 설명한다. 평가 데이터셋은 운영에서 관찰되는 질문 유형, 모델군, 복잡도 수준을 포괄하도록 구성해 실제 사용을 반영한다. LLM-as-judge 계층은 생성된 질의의 정확성, 완전성, 기준 질의와의 의미적 동등성을 평가해 변경마다 비교할 수 있는 일관된 품질 신호를 제공한다. 측정 결과는 세부 구간별로 나누어 살펴보므로, 전체 결과만으로는 드러나기 어려운 품질 회귀의 위치와 수정 대상을 식별할 수 있다. 프롬프트·모델·검색 매개변수·예제에 대한 모든 변경은 운영 배포 전에 이 평가를 거치며, 원문은 이러한 구성을 통해 평가를 사후 작업이 아닌 일상적인 개발 단계로 만들었다고 설명한다.

8. 도메인 전문가의 교정과 예제 저장소 개선

고객 환경이 변하고 새로운 질문 패턴이 등장하는 상황에서 정확도를 유지하려면 초기 배포의 품질만으로는 충분하지 않다는 문제의식에 따라, Orca는 도메인 전문가가 참여하는 내부 라벨링 도구를 구축했다. 이 도구는 제품 관리자, 지원 엔지니어, 보안 연구자가 사용할 수 있으며, 질의에 표시를 남기고 출력을 교정한 뒤 수정 내용을 한 번의 작업으로 예제 저장소에 반영하도록 지원한다. 또한 시스템은 일치하는 예제의 신뢰도가 낮은 운영 질의를 자동 수집하고 적절한 도메인 전문가에게 전달해 매일 라벨링하도록 연결한다. 이는 실제 운영에서 발견되는 질문과 교정 결과를 이후 검색에 쓰이는 예제에 반영하는 흐름이지만, 제공된 원문은 이 설명 도중 끝나므로 이후 절차나 라벨링의 정량적 개선 효과까지는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 보고된 효율 개선은 단일 모델 교체보다 처리 경로와 입력 문맥을 재구성한 접근과 연결된다. 결정적 매칭, 기존 필터 재사용, 관련 스키마 선별이 각각 불필요한 생성을 줄이는 역할을 한다.
• 예제 검색에서는 의미적 유사성만으로 충분하지 않았다. 유사한 후보의 중복과 관련성 손실을 함께 고려한 상위 20개 검색·상위 5개 재순위화 조합이 Orca의 비교에서 선택됐다.
• 유효한 스키마와 API 검증은 필터 구성의 오류를 다루고, 기준 질의와의 의미적 동등성 평가와 전문가 교정은 사용자 의도 및 변화하는 질문 패턴에 대한 품질 관리를 보완한다.

✅ 액션 아이템

• Amazon Titan 상위 20개 검색과 Cohere Rerank 3.5 상위 5개 선정의 관련성·다양성 효과 검증.
• 선택된 스키마를 기준으로 정적 검증 및 Sonar API 검증 오류에 따른 생성기 재시도 동작 확인.
• 질문 유형·모델군·복잡도별 배포 전 평가와 신뢰도가 낮은 운영 질의의 전문가 교정 지속.

❓ 열린 질문

• 질의 비용 90%, 입력 토큰 93%, 지연 시간 75% 감소를 측정한 초기 기준선과 운영 솔루션의 비교 조건은 무엇인가?
• 상위 20개 검색과 상위 5개 재순위화의 효과는 질문 유형·모델군·복잡도별로 어떻게 달라지는가?
• 신뢰도가 낮은 운영 질의에 대한 전문가 교정은 이후 평가에서 정확성과 의미적 동등성을 얼마나 개선하는가?