보안 AI 에이전트 실전 운영기: 스트라이프가 만든 위협 모델링 에이전트와 LLM 평가 파이프라인

핵심 메시지

• 스트라이프는 보안 검토 적체를 줄이려고 위협 모델링 에이전트와 보안 문의 라우팅 에이전트를 따로 만들었고, 두 에이전트의 구조를 서로 다르게 설계했다.
• 잘못된 팀으로 문의를 넘기는 환각은 사람을 다시 끌어들여 원래 해결하려던 문제를 그대로 되살리기 때문에, 정확도가 가장 큰 과제였다.
• 정답이 하나로 정해지지 않는 위협 모델을 채점하려고 사람이 만든 기준 사례와 LLM의 의미 비교를 결합한 평가 파이프라인을 만들었다.
• 프롬프트에 JSON 형식 지시를 넣자 형식은 좋아졌지만 보안 조언 정확도가 10% 떨어졌고, 평가 파이프라인이 없었다면 이 손실을 몰랐을 것이라고 했다.
• 발표자들은 에이전트가 80% 수준까지 끌어주고 마지막 확인은 보안 엔지니어가 하는 구조를 선택했다.

쉽게 이해하기

결제 회사 스트라이프의 보안·소프트웨어 엔지니어인 제프리 장과 시드 샤가 사내에서 운영 중인 두 개의 보안 AI 에이전트를 공개했다. 하나는 보안 검토 티켓이 들어오면 위협 모델을 만들어 주는 위협 모델링 에이전트고, 다른 하나는 사내 개발자의 보안 질문을 담당 팀으로 연결해 주는 라우팅 에이전트다. 두 에이전트 모두 보안 검토는 밀려 있는데 사람 시간은 부족하다는 같은 문제에서 출발했다.

두 에이전트의 설계는 정반대였다. 위협 모델링은 티켓 큐에서 시간을 들여 처리해도 되는 비동기 작업이라, 오케스트레이터가 입력 수집 에이전트와 분야별 보안 에이전트, 출력 에이전트를 정해진 순서로 돌리는 다단계 구조를 택했다. 오케스트레이터에 재량을 많이 주자 필요한 전문 에이전트를 건너뛰는 일이 생겨 순차 실행으로 고정했다는 설명이다.

반대로 라우팅 에이전트는 대화형이라 속도가 중요했다. 처음에는 팀 소개를 프롬프트에 넣은 한 번의 호출로 만들었지만 사내 용어와 문서를 몰라 환각이 잦았고, 도구를 잔뜩 붙여 직접 조사하게 하자 정확도는 올랐지만 응답에 10분이 걸렸다. 답을 아는 기준 질문으로 도구를 하나씩 빼며 정확도를 재는 작업을 반복해 도구 두 개, 30초 수준까지 줄였다.

가장 공들인 부분은 평가였다. 위협 모델은 정답이 하나가 아니어서 문자열이나 키워드 대조로는 채점되지 않았고, 같은 위험을 실행마다 다른 범주로 이름 붙이는 문제도 있었다. 그래서 과거 보안 검토를 바탕으로 사람이 기준 사례를 만들고, 그 기대 출력과 에이전트 실제 출력의 의미가 같은지를 LLM이 판정하게 했다. 이 파이프라인으로 프롬프트를 다듬어 정확도를 약 10% 올렸고, 같은 테스트를 여러 벌 복제한 대형 데이터셋으로 모델을 비교해 다시 약 10%를 더 얻었다.

발표는 실패담도 함께 내놨다. 구글 딥마인드의 알파이볼브 방식으로 프롬프트를 진화시켜 보려 했지만, 변형이 단어 두 개를 더하거나 문장을 바꿔 쓰는 데 그쳐 의미 있는 개선이 없었다고 했다. 입력이 부실한 티켓에서는 모델이 암호화나 키 교체처럼 티켓에 없는 내용을 지어냈고, 결국 '정보가 부족하다'고 말하도록 가르치는 편이 나았다는 것이 이들의 결론이다.

주요 인사이트

• 에이전트 구조에 정답은 없고 작업 성격이 정한다. 같은 팀이 만든 두 에이전트도 하나는 다단계 순차 구조, 다른 하나는 도구를 최소화한 단순 구조로 갈렸다.
• 속도를 위해 도구를 줄이는 작업은 감이 아니라 측정으로 해야 한다. 답을 아는 기준 질문 세트를 두고 도구를 하나씩 빼며 정확도 변화를 확인하는 방식이 실용적이다.
• 평가 파이프라인은 나중이 아니라 먼저 만들어야 한다. 없으면 눈앞의 예외 사례만 좇다가 특정 상황에서만 잘 도는 프롬프트가 쌓인다.
• LLM이 LLM을 채점하는 순환 문제는 사람이 기준 사례를 만들고 LLM은 의미 비교만 맡는 역할 분담으로 완화할 수 있다.
• 목표 정확도는 절대 기준이 아니라 배포 방식이 정한다. 사람이 마지막에 확인하는 구조라면 더 낮은 정확도로도 실전 투입이 가능하다.

자주 묻는 질문

관련 AI 소식