어도비 보안 가이드 RAG 사례: 중앙 벡터 스토어와 MCP 서버로 개발자에게 전달하기

핵심 메시지

• 보안 인력 대비 개발자 수가 압도적으로 많은 조직에서 일대일 보안 가이드는 확장되지 않는다. 어도비 팀은 이를 대역폭 문제로 규정하고 자동화에 나섰다.
• 범용 AI에게 보안을 물으면 일반론만 돌아온다. 조직의 표준과 승인된 방식을 답하게 하려면 검증된 사내 문서를 담은 중앙 벡터 스토어가 필요했다.
• 문서 수집은 깃 저장소의 메타데이터 파일을 진실의 원천으로 삼아, PR 병합을 신호로 다운로더와 인제스터가 자동으로 임베딩까지 만들어 넣는 파이프라인으로 구성했다.
• 같은 가이드가 지라 티켓, 슬랙, 위협 모델링 플랫폼, 그리고 MCP 서버를 통한 IDE 안에서 동일하게 제공된다. 개발자가 어디에 있든 답이 따라간다.
• 발표자들이 꼽은 가장 중요한 교훈은 평가(evals)다. 지루하고 손이 많이 가지만, AI 실험을 프로덕션으로 넘기게 해 주는 것은 결국 평가 체계였다고 말한다.

쉽게 이해하기

AI 보안 콘퍼런스 [un]prompted 2026에서 어도비의 제품보안 엔지니어 찬드라니 무커지와 슈루티 다타 굽타가 사내 프로젝트 '서비스형 보안 가이드'를 발표했다. 문제의식은 현장의 익숙한 풍경에서 출발한다. 대부분의 조직에서 보안 담당자 대비 개발자 비율은 매우 낮아 일대일 안내는 불가능하고, 설계 리뷰와 위협 모델링, 코드 스캐너, 취약점 스캔까지 보안 절차는 여러 갈래로 나뉘어 있으며, 보안 챔피언들이 만든 문서는 흩어져 있어 정작 필요한 사람에게 제때 닿지 않는다. 정보가 낡아 가는 것도 문제였다.

AI가 자연어를 이해한다는 점은 분명한 기회였지만, 그대로 쓰면 답이 일반론에 그친다. 인증을 어떻게 처리해야 하느냐고 물으면 교과서적인 답은 나와도 우리 조직이 쓰는 플랫폼 표준이나 승인된 함수는 나오지 않는다. 여기에 환각의 위험까지 겹친다. 팀이 잡은 방향은 플랫폼에 종속되지 않는 보안 봇이었다. 슬랙이든 지라 티켓이든 자동 위협 모델링이든, 입력이 어디서 오든 검증된 정보를 담은 하나의 중앙 저장소에서 같은 답이 나오게 하는 것이다.

약 1년 반에 걸친 과정은 단계적이었다. 처음에는 엄선한 문서를 벡터 스토어에 넣은 RAG로 시작해 지라 취약점 티켓 흐름에 붙였고, 곧이어 슬랙 워크플로에도 연결했다. 그러다 보안 절차마다 별도의 RAG를 만들 수는 없다는 결론에 이르러 공통 벡터 스토어로 통합했다. 초기에는 PDF 내용을 다듬어 넣는 수작업과 일회성 스크립트가 섞여 있었는데, 이를 자동 문서 수집 파이프라인으로 대체했다. URL만 주면 내용을 가져와 벡터 스토어에 넣고, 크론 작업이 주기적으로 원문 변경을 확인해 갱신한다.

수집 워크플로의 출발점은 깃 저장소다. 보안 챔피언이나 전문가가 문서 메타데이터 파일을 올리면 검증 후 PR을 병합하고, 깃 변경분을 구독하는 다운로더 서비스가 이를 감지해 내용을 가져온다. 인제스터가 임베딩을 만들어 벡터 스토어에 넣으면 슬랙 채널에 수집 완료 메시지가 올라가고, 곧바로 평가 워크플로가 실행된다. 메타데이터를 받을 때 함께 요구하는 참조 질문·답변 세트가 여기서 정답지 역할을 해, 답변의 정확성과 관련성을 측정한다. 서비스 쪽에서는 입력 유형에 따라 시스템 프롬프트를 조금씩 바꾸고, 벡터 스토어에서 받은 내용을 LLM으로 정해진 JSON 형식에 맞춘 뒤 랭스미스에 전 과정을 기록해 추적성을 확보한다.

실제 쓰임새는 네 갈래다. 사내 정책을 묻는 보안 지원 챗봇, 자동 위협 모델링 엔진이 위협을 찾아낸 뒤 받아 가는 완화 방안, 취약점 티켓 처리 과정에서 제공되는 수정 가이드, 그리고 MCP 서버를 통해 IDE 안에서 코드를 쓰는 중에 받아 보는 가이드다. 취약점 수정에서는 눈앞의 한 건을 막는 단기 처방만이 아니라 같은 유형의 취약점이 반복될 때 쓸 장기 개선안까지 함께 제시한다. 발표 중 커서에서 시연하려던 MCP 데모는 네트워크 문제로 실패했지만, 발표자들은 어떤 코딩 에이전트든 같은 방식으로 연결된다고 설명했다.

주요 인사이트

• 이 사례의 핵심 설계는 모델이 아니라 데이터의 단일 출처다. 창구가 넷이든 다섯이든 답의 근거를 하나의 검증된 저장소로 모아 두는 것이 일관성을 만드는 장치였다.
• 문서 신선도는 기술이 아니라 운영의 문제로 남았다. 평가 워크플로가 갱신 필요를 알려 주면 팀이 문서 소유자에게 연락하고, 반대로 소유자가 먼저 알려 오기도 하는 공동 책임 모델로 굴린다.
• PR 리뷰 단계는 대량 수집의 병목이지만 품질을 지키는 장치이기도 하다. 발표자들은 이를 제거할 문제가 아니라 감수할 트레이드오프로 설명했다.
• 도구를 만드는 것과 쓰게 만드는 것은 다른 일이다. 팀은 커서용 확장 프로그램을 배포해 로그인만 하면 MCP 설정과 규칙이 기본으로 깔리게 했고, 사내 로드쇼로 인지도를 넓혔다.
• 1년 반 사이 기술 스택 자체가 바뀌었다는 회고도 눈에 띈다. 초기에는 문서 청킹과 벡터화를 직접 했지만 이제는 파일을 올리면 벤더가 처리해 주고, 멀티모달 입력도 가능해졌다.

자주 묻는 질문

관련 AI 소식