Databricks에서 에이전트 기반 보안 리뷰를 구축한 방법

저희는 이미 보안 검토 프로세스의 일부를 자동화하여 사용하고 있었습니다. 유용하긴 했지만, 수작업을 충분히 줄여주지는 못했습니다.

대기열에서 계속 동일한 패턴이 관찰되었습니다. 익숙한 디자인을 사용하는 일상적인 통합 작업이 완전히 새롭고 위험도가 높은 아키텍처와 나란히 대기하며, 숙련된 검토자라는 동일한 부족한 리소스를 기다리고 있었습니다.

문제는 기존 자동화가 실패했다는 것이 아니었습니다. 단지 한계에 도달했을 뿐이었습니다. 저희는 여전히 예측 가능한 작업에 전문가의 시간을 소비하고 있었고, 이로 인해 진정으로 전문가의 판단이 필요한 결정에 집중할 여유가 줄어들었습니다.

그래서 기존 시스템을 확장하기 위해 에이전트 기반 레이어를 구축했습니다. 목표는 프로세스나 그 뒤에 있는 사람들을 대체하는 것이 아니었습니다. 시스템이 요청을 이해하고, 표준을 적용하며, 누락된 정보를 요청하고, 사람이 개입해야 하는 시점을 인식하도록 돕는 것이었습니다.

첫 번째 에이전트 기반 버전은 하나의 검토 경로에 집중했습니다. 저희 팀은 더 넓은 패턴을 파악하고 이를 여러 에이전트 세트로 확장하여, 현재는 보안 접수 및 검토 프로세스의 추가적인 부분들을 지원하고 있습니다. 저는 이 첫 번째 버전을 고객들이 사용하는 것과 동일한 플랫폼인 Databricks 상에 완전히 구축했습니다.

플랫폼이 중요했던 이유

핵심 요소들이 이미 하나의 환경에 준비되어 있었기 때문에 빠르게 움직일 수 있었습니다.

Unity Catalog은 보안 표준, 요청 데이터, 증빙 자료, 결정 사항 및 시스템 출력을 위한 거버넌스 공간을 제공했습니다. Databricks에서 호스팅하는 파운데이션 모델은 분류 및 추론을 위한 모델 레이어를 제공했습니다. Lakeflow Jobs는 서버리스 컴퓨팅에서 노트북 기반 워크플로우를 오케스트레이션했습니다. Databricks Apps는 접수 경험과 경영진 대시보드를 제공했습니다.

각 요소가 어떻게 결합되는지

대략적으로 설명하자면, 요청은 플랫폼을 통해 하나의 연속된 경로로 흐르며, 모든 단계에서 동일한 거버넌스 테이블을 읽고 씁니다.

1. 접수(Intake) - Databricks Apps로 구축된 대화형 앱이 자연어 설명을 구조화된 요청으로 변환하고 관련 설계 문서를 첨부합니다.
2. 추론(Reasoning) - Databricks에서 호스팅하는 파운데이션 모델(Claude Haiku, Sonnet, Opus)이 요청을 분류하고, 위험을 평가하며, 요구사항 초안을 작성합니다. 이 모든 과정은 항상 보안 표준을 기반으로 합니다. Haiku는 가벼운 분류를 처리하고, Sonnet은 대부분의 검토 작업을 처리하며, Opus는 가장 복잡한 추론을 위해 사용됩니다.
3. 오케스트레이션(Orchestration) - Lakeflow Jobs가 서버리스 컴퓨팅에서 검토 에이전트를 실행하여 일정에 따라 각 요청을 단계별로 이동시킵니다.
4. 기록 시스템(System of record) - Unity Catalog은 표준, 요청 데이터, 증빙 자료, 모델 출력 및 결정 사항을 거버넌스 테이블로 보유하며, 이 모든 것에 대해 단일 권한 및 리니지 모델을 적용합니다.
5. 관찰 가능성(Observability) - 두 번째 Databricks App이 동일한 테이블을 읽어 처리량, 위험 구성, 자동화 비율 및 절약된 시간을 보고합니다.

이를 통해 데이터, 모델, 워크플로우 및 애플리케이션 전반에 걸쳐 일관된 거버넌스 및 운영 모델을 확보할 수 있었습니다. 서로 다른 권한, 로그 및 데이터 경로를 가진 개별 서비스를 조립하는 대신, 검토 로직과 사용자 경험에 집중할 수 있었습니다.

실질적인 차이는 속도였습니다. 2시간 만에 작동하는 시스템을 만들 수 있었습니다. 개별 서비스를 연결하여 동일한 작업을 수행했다면 몇 주가 걸렸을 것입니다.

모든 검토에 동일한 경로가 필요한 것은 아닙니다

대부분의 보안 대기열에는 예측 가능한 요청과 실제 예외 상황이 모두 포함되어 있습니다.

승인된 인증 패턴을 사용하고 민감한 데이터를 처리하지 않는 통합 작업은 광범위한 관리자 권한으로 민감한 정보를 처리하는 인터넷 연결 서비스와 동일한 결정이 아닙니다. 하지만 기존의 대기열은 이 두 가지를 모두 동일한 수동 경로로 보낼 수 있습니다.

모든 검토를 자동화하는 것이 목표는 아니었습니다. 반복 가능한 부분을 자동화하고, 위험이나 불확실성이 더 높은 부분에는 사람의 판단을 남겨두었습니다.

그 결과 명확한 기준 내에서 잘 이해된 케이스에는 자동화를 적용하고, 새롭거나 위험도가 높거나 모호한 결정에는 사람을 개입시키는 간단한 규칙이 만들어졌습니다.

더 나은 진입 창구

검토의 품질은 시작 단계에서 제공되는 정보에 따라 달라집니다.

정적 양식은 요청자가 자신에게 어떤 검토가 필요한지 알고 있고, 보안 용어를 이해하며, 검토자가 요청할 증빙 자료를 예측할 수 있다고 가정합니다. 그렇지 못한 경우 요청이 불완전한 상태로 접수되어 검토가 또 다른 질문 공세로 시작하게 됩니다.

저는 Databricks Apps를 사용하여 대화형 접수 애플리케이션을 구축했습니다. 요청자가 수행하려는 작업을 자연어로 설명하면, 애플리케이션이 예상되는 검토 경로를 식별하고, 맥락에 맞는 후속 질문을 던지며, 내장된 설계 문서를 지원 컨텍스트로 사용할 수 있습니다. 또한 누락된 정보를 강조하고 공식 요청이 생성되기 전에 예비 위험 표시를 제공합니다.

충분한 컨텍스트가 확보되면 보안 팀을 위한 구조화된 요청을 생성합니다.

이 애플리케이션에는 보안 표준을 기반으로 하는 상담 모드도 있습니다. 모든 질문이 티켓으로 생성될 필요는 없습니다. 팀은 설계를 구체화하는 동안 가이드를 받을 수 있으며, 필요한 경우에만 공식 검토를 시작할 수 있습니다.

이 기능은 시스템에서 가장 유용한 부분 중 하나가 되었습니다. 대기열을 보안 팀과 소통하는 유일한 방법으로 여기는 대신, 사람들이 더 빨리 업무를 진행할 수 있도록 도와줍니다.

에이전트 작동 방식

접수 애플리케이션의 이면에는 Databricks Notebooks로 구현되고 Lakeflow Jobs로 오케스트레이션되는 집중형 에이전트 모음이 있습니다.

저는 보안 검토자 역할을 수행하는 광범위한 권한을 가진 단일 에이전트를 구축하는 것을 의도적으로 피했습니다. 각 에이전트는 컨텍스트 수집, 위험 평가, 관련 표준에 요청 매핑, 요구사항 초안 작성, 후속 조치 관리, 사람에게 인계 준비 등 제한된 책임을 집니다.

각각 하나의 작업을 수행하는 7개의 집중형 에이전트

이는 하나의 범용 에이전트나 단일 스크립트가 아니라, 각각 좁은 범위의 작업을 수행하며 접수 애플리케이션 뒤에서 예약된 작업으로 오케스트레이션되는 집중형 에이전트 세트입니다.

• 접수 에이전트(Intake agent) - 대화형 진입 창구를 운영합니다. 검토 경로를 식별하고, 맥락에 맞는 질문을 던지며, 구조화된 요청을 구성합니다.
• 위험 평가 에이전트(Risk assessment agent) - 증빙 자료를 바탕으로 위험 등급을 할당하며, 정보가 불완전한 경우 기본적으로 더 높은 등급을 지정합니다.
• 요구사항 에이전트(Requirements agent) - 요청을 관련 표준에 매핑하고, 잘 이해된 케이스에 대해 구현별 요구사항 초안을 작성합니다.
• 특화 검토 에이전트(Specialized review agents) - 브라우저 확장 프로그램 위협 모델링 및 제3자 벤더 평가와 같이 전용 로직이 필요한 요청 유형을 처리합니다.
• 검증 에이전트(Validation agent) - 요청이 종결되기 전에 위험도가 높은 요청에 대한 항목별 검증 체크리스트를 작성합니다.
• 워크플로우 에이전트(Workflow agent) - 설명 요청, 알림, 확인 추적, 사람에게 에스컬레이션 등 후속 작업을 처리합니다.
• 학습 에이전트(Learning agent) - 주기적으로 검토자의 수정 사항을 원래 출력과 비교하여 프롬프트 및 표준의 개선 사항을 도출합니다.

각 에이전트는 제한된 책임을 가지므로 동작을 검사하고 테스트할 수 있으며, 하나의 변경 사항이 다른 에이전트에 인지하지 못하는 영향을 미치지 않습니다.

시스템은 먼저 요청의 위험을 평가하고 해당 평가를 뒷받침하는 증빙 자료를 기록합니다. 위험 레이블 자체만으로는 충분하지 않습니다.

정보가 누락되었거나 모순되는 경우, 시스템은 설명을 요청하거나 요청을 검토자에게 라우팅합니다. 임의로 추론하여 승인하지 않습니다.

일상적인 요청의 경우, 에이전트는 일반적인 템플릿 문구를 반환하는 대신 실제 아키텍처와 적용 가능한 표준을 기반으로 요구사항을 생성합니다. 요청자는 이러한 요구사항을 확인하고 필요한 증빙 자료를 제공합니다. 자격 요건을 갖춘 저위험 및 중위험 요청은 정의된 기준과 검증이 충족되면 자동화된 경로를 통해 완료될 수 있습니다.

예시

승인된 싱글 사인온(SSO) 패턴을 사용하고 민감한 데이터를 처리하지 않는 내부 통합이라는 흔한 사례를 예로 들어 보겠습니다. 일반적인 템플릿 대신 요구사항 에이전트는 해당 아키텍처와 관련된 구체적이고 확인 가능한 항목을 생성합니다. 예를 들면 다음과 같습니다.

• 승인된 ID 제공업체(IdP)를 통해 인증하고 로컬 또는 공유 자격 증명을 비활성화합니다.
• 통합을 최소한으로 필요한 액세스 범위로 제한하고 이를 문서화합니다.
• 애플리케이션 및 액세스 로그를 중앙 로깅 파이프라인으로 전송합니다.
• 데이터 분류 수준을 확인하고 민감한 데이터가 도입되기 전에 재검토를 수행합니다.

요청자는 이러한 항목을 확인하고 증빙 자료를 첨부합니다. 모든 사항이 확인되고 케이스가 자격 기준을 충족하면 자동화된 경로를 통해 완료될 수 있습니다.

위험성이 높거나 중요하고, 특이하거나 모호한 요청은 담당자에게 전달됩니다. 이 시점에서 검토자는 구조화된 요약, 뒷받침하는 증거, 적용 가능한 표준 및 남아 있는 미결 질문을 받게 됩니다.

에이전트는 누락된 세부 정보 수집, 알림 전송, 승인 추적, 지원 요청 시 에스컬레이션 등 검토와 관련된 대부분의 행정 업무도 처리합니다. 요청이 모호해지거나 판단이 필요한 경우에 검토자가 개입합니다.

자동화는 우리가 정의한 규칙 내에서 작동합니다. 예외 사항과 중대한 결정에 대한 통제권은 사람이 계속 유지합니다.

시스템을 신뢰할 수 있게 만들기

가장 어려웠던 점은 모델이 답변을 생성하도록 만드는 것이 아니었습니다. 그 답변이 제한되고, 검토 가능하며, 조치를 취하기에 적절하도록 만드는 것이었습니다.

에이전트는 당사의 보안 표준을 기반으로 합니다. 위험 평가에는 반드시 이를 뒷받침하는 증거가 포함되어야 합니다. 컨텍스트가 누락되면 낙관적인 가정을 하는 대신 후속 조치나 에스컬레이션을 트리거합니다. 자동 완료는 사전 정의된 요청 클래스 및 기준에만 제한됩니다. 워크플로는 각 요청과 관련된 입력, 출력, 증거 및 결정을 기록합니다.

실제 적용 모습

자동화된 결정에 따라 안전하게 조치를 취할 수 있도록 만드는 세 가지 요소는 다음과 같습니다.

• 사전 정의된 요청 클래스. 충분히 파악되고 위험도가 낮은 카테고리만 자동 완료 대상이 됩니다. 예를 들어 민감한 데이터를 처리하지 않고 승인된 패턴에 따라 진행되는 일상적인 내부 통합 작업이 이에 해당합니다. 이러한 클래스를 벗어나는 모든 요청은 기본적으로 담당자에게 전달됩니다.
• 허용 가능한 증거. 결정의 신뢰성은 이를 뒷받침하는 근거에 달려 있습니다. 증거란 링크된 설계 문서, 명시된 데이터 분류 수준, 또는 승인된 제어 조치가 마련되어 있음을 보여주는 구성 및 참조와 같이 구체적이고 검증 가능한 결과물을 의미합니다. 증거가 없는 주장은 누락된 정보로 처리됩니다.
• 거부되거나 불확실한 평가. 증거가 누락되었거나 모순되는 경우 시스템은 임의로 추측하지 않습니다. 기본적으로 더 보수적인 위험 등급으로 설정하거나, 구체적인 설명 요청을 게시하거나, 미결 질문을 첨부하여 검토자에게 요청을 전달합니다. 임의로 승인 단계로 넘어가지 않습니다.

검토자의 피드백은 공백을 식별하고 시간이 지남에 따라 시스템을 개선하는 데 도움이 됩니다. 에이전트가 프로덕션 동작을 스스로 변경하도록 허용하는 대신, 이러한 수정 사항을 반영하여 표준, 프롬프트 및 워크플로 로직을 개선합니다.

이러한 제어 장치는 모델 자체보다 더 중요합니다. 강력한 모델은 추론 능력을 향상시킬 수 있지만, 신뢰는 모델을 둘러싼 시스템(명확한 범위, 명시적인 증거, 보수적인 에스컬레이션, 위험에 실제 무게감을 부여하는 사람의 권한)에서 나옵니다.

저희 팀이 발전시킨 방향

저는 하나의 검토 경로를 개선하기 위해 첫 번째 에이전트 기반 버전을 구축했습니다. 저희 팀은 동일한 패턴이 훨씬 더 많은 작업을 지원할 수 있음을 알아차렸습니다.

팀원들은 아키텍처를 추가적인 요청 유형으로 확장하고, 워크플로를 강화했으며, 에이전트가 당사의 표준을 적용하는 방식을 개선하고, 일상적인 사용에 필요한 제어 기능을 추가했습니다. 단일 에이전트 기반 워크플로로 시작된 것이 이제는 팀이 계속해서 개발해 나가는 공유 시스템이 되었습니다.

시작은 제가 했지만, 팀이 이를 실제로 운영하고 자신들의 것으로 만들었기 때문에 시스템이 진정한 가치를 갖게 되었습니다.

개발자로서 첫 번째 버전이 제대로 작동했다는 점이 자랑스럽습니다. 리더로서는 팀이 확장할 만한 가치가 있는 기반을 발견했다는 점이 더욱 자랑스럽습니다.

결과 측정

효율성에 대한 주장은 제기하기는 쉽지만 증거 없이는 신뢰하기 어렵습니다.

저는 또 다른 Databricks App으로 임원용 대시보드를 구축했습니다. 이 대시보드는 검토 워크플로에서 생성된 것과 동일한 Unity Catalog 데이터를 읽어와 요청 볼륨, 위험 분포, 자동 완료, 사람으로의 에스컬레이션, 사이클 타임 및 검토자가 절약한 예상 시간을 추적합니다.

지표가 운영 기록에서 제공되므로, 서로 다른 시스템에서 내보낸 데이터를 수동으로 대조할 필요 없이 지표를 생성한 요청 및 결정으로 역추적할 수 있습니다.

덕분에 경영진과의 대화 방식이 바뀌었습니다. 자동화가 수동 노력을 줄인 부분, 검토자가 계속 개입한 부분, 그리고 시간이 지남에 따라 이 둘의 조합이 어떻게 변화했는지를 보여줄 수 있었습니다.

수치로 보는 성과

대시보드는 모두 동일한 운영 기록에서 파생된 일관된 측정 지표 세트를 추적합니다.

변화된 점

이전에는 대기열에서 며칠 동안 대기해야 했던 대상 일상 요청을 이제 몇 분 만에 완료할 수 있습니다. 팀은 티켓을 열기 전에 안내를 받을 수 있으며, 검토자에게 도달하는 요청은 더 나은 컨텍스트와 함께 전달됩니다.

보안 엔지니어는 새로운 설계, 의미 있는 위험, 경험이 필요한 결정에 더 많은 시간을 할애할 수 있습니다. 또한 동일한 표준 및 증거 요구 사항에 따라 요청을 평가하므로 첫 번째 검토 단계가 더 일관되게 유지됩니다. 시스템이 불확실한 경우에는 에스컬레이션합니다.

이것은 사람 없는 보안이 아닙니다. 전문가의 주의가 가장 큰 가치를 발휘하는 곳에 집중되도록 설계된 시스템입니다.

이번 경험을 통해 얻은 교훈

검토자를 추가하면 처리 용량은 늘어날 수 있지만 반복적인 작업이 사라지지는 않습니다.

첫 번째 단계는 프로세스와 판단을 분리하는 것입니다. 기준이 명확하고, 시스템이 실제 표준을 기반으로 하며, 증거가 요구되고, 불확실성이 에스컬레이션되며, 결과를 측정할 수 있는 경우에만 반복 가능한 단계를 자동화하십시오.

단순히 모델이 답변을 생성할 수 있다고 해서 결정을 자동화하지 마십시오. 허용 가능한 답변의 형태, 이를 뒷받침하는 증거, 시스템이 불확실할 때 발생하는 상황이 프로세스에 정의되어 있는 경우에만 자동화하십시오.

중대한 결정과 예외 사항에 대한 통제권은 사람이 계속 유지하도록 하십시오.

제 의도는 보안 검토에서 사람을 배제하는 것이 아니었습니다. 통제된 시스템이 일관되게 처리할 수 있는 작업에 사람들이 소비하는 시간을 줄이고자 했습니다. Databricks를 기반으로 구축함으로써 이를 수행할 수 있는 플랫폼 기반을 마련할 수 있었습니다. 저희 팀이 첫 번째 버전을 가져가서 강화하고 자신들의 것으로 만드는 과정을 지켜보는 것이 가장 보람찬 부분이었습니다.

Databricks 멀티 에이전트 가이드로 시작한 다음, 이 게시물의 패턴(Unity Catalog의 거버넌스가 적용된 데이터, Lakeflow Jobs에 집중된 에이전트, 프런트 도어 역할을 하는 Databricks App)을 여러분만의 반복 가능하고 증거 기반의 검토 워크플로에 맞게 조정해 보세요.

Databricks Apps에서 멀티 에이전트 시스템 구축하기

Databricks 멀티 에이전트 가이드로 시작한 다음, 이 게시물의 패턴(Unity Catalog의 거버넌스가 적용된 데이터, Lakeflow Jobs에 집중된 에이전트, 프런트 도어 역할을 하는 Databricks App)을 여러분만의 반복 가능하고 증거 기반의 검토 워크플로에 맞게 조정해 보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)