에이전트로 Figma의 내부 시스템을 보호하는 방법

내부 플랫폼 보호와 관련하여 Figma의 보안 엔지니어링 팀에서 방어하는 위협은 끊임없이 변화하고 있습니다. 클라우드 인프라는 자주 변경되고 개발자는 새로운 도구를 채택하며 사람들이 노트북에 설치하고 실행하는 내용은 분기마다 다릅니다(예: Designer Advocates 팀이 자체 앱 및 자동화 코딩을 시작하는 경우).

Figma의 SIEM인 Panther는 클라우드 인프라, 엔드포인트, SaaS 앱 및 ID 시스템 전반에 걸쳐 광범위한 검사를 실행하여 모든 위협에 선제적으로 대처하도록 도와줍니다. 잠재적인 문제를 감지하면, Slack에 알림을 게시하고 담당 엔지니어가 처리할 수 있도록 Asana 티켓을 생성합니다. 역사적으로 대기 중인 상태는 엄청난 양의 수작업이 수반되었습니다. 컨텍스트를 수집하는 것이 주요 과제였습니다. 알림이 우리가 지난주에 본 것과 유사한지, 문제를 해결할 수 있는 보류 중인 PR이 있는지, Slack 스레드에 관련된 내용이 언급되었는지를 파악해야 했습니다.

다른 많은 팀과 마찬가지로, 저희도 지난 한 해 동안 LLM 모델의 기능이 빠르게 발전하는 것을 목격했습니다. 최근에 저희는 코드베이스 내 에이전트를 활용하여 Figma가 어떻게 취약점을 사전에 차단하는지를 공유했습니다. 이 에이전트는 Okta, AWS 등의 민감한 도구의 구성 변경 시 발생하는 문제를 포착했으며, 이는 해당 도구의 구성을 코드로 저장하는 기존 방식 덕분입니다. 하지만 Figma 내부 시스템 보호 방식을 실질적으로 개선하고 업무 부담을 줄이기 위해서는 코드베이스를 넘어 SIEM이 발견하는 광범위한 문제를 처리할 수 있는 새로운 시스템을 구축해야 했습니다.

처음에는 새로운 경고가 발생했을 때 담당 엔지니어의 이전 추론 내용을 보여주는 검색 계층을 구축하는 좁은 목표로 시작했습니다. 하지만 그 프로젝트는 결국 경고를 조사하고, 감사 로그를 쿼리하고, 코드 변경 사항을 기록하고, PR을 생성하며, 자체 메모리를 통해 시간이 지남에 따라 성능이 향상되는 완전한 에이전트 시스템으로 발전했습니다. 이 시스템 덕분에 보안팀의 업무 방식이 완전히 바뀌었습니다.

RAG 계층: 알림 기록 유지

Figma가 구축한 첫 번째 작업은 AWS Bedrock Knowledge Bases 및 Amazon Kendra를 기반으로 검색이 강화된 분류 시스템이었습니다. 초기 목표는 동일한 알림이 마지막으로 발생했을 때 무슨 일이 일어났는지에 대한 기록 컨텍스트를 표시하고 중복된 알림을 억제하는 것이었습니다.

Panther 알림이 발생하면 Lambda 핸들러는 이를 표준화된 문서로 변환하고 Kendra로 인덱싱합니다. 원시 알림 페이로드에서 구조화된 필드(p_any_ip_addresses의 IP, p_any_usernames의 행위자, 다양한 공급자별 사용자 필드, ARN의 AWS 계정 ID)를 가져옵니다. 이들은 알림 제목, 심각도, 태그 및 타임스탬프와 함께 검색 가능한 Kendra 문서 속성이 됩니다.

const attrs: DocumentAttribute[] = [
  { Key: 'alert_id', Value: { StringValue: doc.alert_id } },
  { Key: 'alert_type', Value: { StringValue: doc.alert_type } },
  { Key: 'severity', Value: { StringValue: doc.severity } },
  { Key: 'status', Value: { StringValue: doc.status } },
  { Key: 'created_at', Value: { DateValue: doc.created_at } },
  { Key: 'has_investigation_context', Value: { LongValue: doc.has_investigation_context } },
]

다음에 유사한 알림이 발생하면 알림 제목(일반적으로 탐지 이름과 그 뒤의 행위자 사용자 이름)을 기본 벡터로 사용하여 Bedrock에 의미 체계가 일치하는지를 쿼리합니다.

function buildQueryFromAlert(alert: Alert): string {
  return `${alert.data.title}\n\nhas_investigation_context=1`
}

investigation_context(Slack에서 담당 엔지니어가 발견한 내용에 대해 남긴 댓글)가 있는 알림을 검색하는 쪽으로 편향됩니다. (의견이 없는 종결된 알림은 거의 아무런 정보도 주지 않습니다.) 엔지니어의 기존 업무 흐름을 변경하지 않고 조사 컨텍스트를 캡처합니다. 누군가 Slack 알림 스레드에 메모를 남기면(Asana 티켓에 대해 유사한 절차가 있음) 원래 알림에 대한 조사 컨텍스트로 해당 댓글을 Kendra에 다시 인덱싱합니다.

export async function addInvestigationContext(
  alertId: string, contextText: string
): Promise<void> {
  const existingDoc = await findAlertDocument(alertId)
  if (!existingDoc) return

  let updatedContext: string[]
  updatedContext = [...existingDoc.investigation_context, contextText]

  const updatedDoc: AlertDocument = {
    ...existingDoc,
    investigation_context: updatedContext,
    has_investigation_context: 1,
  }
  await reindexDocument(updatedDoc)
}

알림 스레드에 유용한 댓글이 달릴 때마다 향후 유사한 알림의 분류 비용이 절감됩니다. 기존 작업 흐름 자체가 학습 파이프라인 역할을 하므로 특별한 주석 도구나 학습 파이프라인이 필요하지 않았습니다.

검색 기능의 가능성과 한계점

검색 시스템은 각 알림에 대한 요약(사람이 읽기 쉬운 형식)을 생성하여 Slack/Asana에 게시합니다. 이 기능은 담당 업무 부담을 거의 즉시 줄여주었습니다. 알림 분류 시간이 단축되었고 알림 피로도를 줄이기 위한 몇 가지 프로그래밍 방식을 변경할 수 있었다는 경험담을 들었습니다. 유사한 알림을 찾았을 때 해당 알림이 양성이거나 중복될 가능성이 높다고 판단될 경우, 심각도를 자동으로 낮추도록 했습니다.

if (autoResolutionConfidence >= 7) {
  if (updatedSeverity === 'high' || updatedSeverity === 'critical') {
    await alertsDb.updateAlertSeverity(alert.alertId, 'medium')
  }
}

이러한 변경만으로 담당 호출 횟수가 20% 감소했습니다.

RAG 시스템을 구축한 후, 다음 단계는 무엇일지 고민하기 시작했습니다. 그 답은 명확해 보였습니다. 바로 알림 조사를 지원하고 문제를 자동으로 해결하는 에이전틱 계층을 구축하는 것이었습니다.

에이전틱 계층 추가

Tines를 사용하여 RAG 위에 에이전트 계층을 구축했습니다. Panther에서 이벤트가 감지되면 Lambda 스트림 핸들러가 1차 LLM 요약 정보와 RAG 계층의 유사 알림 참조 정보를 함께 Slack에 게시하고, 해당 스레드에 @Tines Security Slackbot을 자동으로 태그합니다. 담당 엔지니어는 필요에 따라 스레드에서 봇을 수동으로 태그하여 후속 질문을 하거나 특정 상황에 대한 추가적인 정보를 얻을 수 있습니다.

봇에 태그가 지정되면 웹훅이 Tines로 전송되고, 가장 먼저 의도 라우팅이 실행됩니다. 보다 가벼운 모델(예: Claude Sonnet)은 전체 Slack 스레드를 읽고 요청을 분류합니다. 이 요청이 알림 분류, 플랫폼 보안 질문, 앱 승인 문의 또는 기타 요청인지 판단합니다. 각 분류는 자체 범위가 지정된 도구 목록, 권한 계층 및 시스템 프롬프트를 갖춘 전문 에이전트로 라우팅됩니다. 알림 분류 에이전트가 대부분의 작업을 처리하지만, 서로 다른 의도에 대해 별도의 에이전트를 사용하면 모든 것에 접근 권한을 가진 방대한 에이전트를 사용하는 위험을 피하면서 각 의도에 특화된 도구 세트를 제공할 수 있습니다.

알림 분류 에이전트의 툴킷

(Claude Opus와 같은 모델을 사용하는) 알림 분류 에이전트는 대부분의 조사가 이루어지는 곳입니다. 이 시스템은 컨텍스트로 전체 Slack 스레드 기록, 자체 관리 메모리(뒤에서 자세히 설명), 그리고 담당 보안 엔지니어가 일반적으로 문제 해결 과정에서 필요로 하는 도구를 제공하며 이러한 도구에는 다음이 포함됩니다.

• Okta: 사용자의 프로필을 가져오고, 그룹을 표시하고, 로그인 기록을 확인하고, 필터로 사용자를 검색합니다. 특정 공격자의 의심스러운 활동에 대한 알림이 발생하면, 에이전트는 일반적으로 가장 먼저 해당 공격자의 Okta 프로필을 가져와 신원과 접근 권한을 파악합니다.
• North Pole Security Workshop(엔드포인트 보안 도구인 Santa 관리): 규칙 검색, 이벤트 검색, 호스트 동기화 상태 확인, 호스트에 규칙 적용. 알림이 차단된 바이너리 또는 엔드포인트 정책 위반과 관련된 경우, 에이전트는 서명 ID를 조회하고 해당 바이너리의 이벤트 기록을 확인하여 다른 사용자도 동일한 차단을 겪고 있는지 확인할 수 있습니다.
• Wiz: 감사 로그, 클라우드 리소스 목록, 취약점 발견 사항, 미해결 문제, 노출된 리소스를 가져옵니다. 클라우드 인프라 알림의 경우, 에이전트는 플래그가 지정된 리소스에 알려진 취약점이나 잘못된 구성이 있는지 확인할 수 있습니다.
• Slack: 스레드 답변을 읽고, 사용자 프로필을 조회하고, 진행 상황 업데이트를 보냅니다. 에이전트는 유사한 알림에서 연결된 이전 스레드를 읽어 과거 담당 엔지니어의 추론 및 관련 논의 내용을 가져옵니다.
• Panther: 알림 세부 정보를 가져오고, 알림을 트리거한 원시 이벤트를 가져오며, 관련된 알림을 나열합니다. 이로 인해 에이전트는 Slack에 게시된 내용 외에도 구조화된 알림 페이로드에 접근할 수 있습니다.
• 코드 수정: Panther 탐지 리포지토리 또는 모노리포지토리에 PR을 생성합니다. 자세한 내용은 뒤에서 확인하세요.
• Panther 조사 하위 에이전트: LLM 기반의 별도 에이전트로, 전체 보안 데이터 레이크에 대해 Snowflake SQL을 작성하고 실행할 수 있습니다. 이는 가장 강력한 도구이며, 뒤에서 자세히 설명하겠습니다.

보안 데이터 레이크 쿼리

분류 에이전트는 직접적인 도구를 사용하여 'Okta에서 이 사용자는 누구인가?', '이 바이너리에 적용되는 Santa 규칙은 무엇인가?', '이 클라우드 리소스가 Wiz에 있는가?'와 같은 많은 질문에 답할 수 있습니다. 하지만 더 심층적인 조사가 필요한 경우도 많습니다. 이 사용자는 알림 발생 2시간 전에 AWS에서 무엇을 하고 있었는가? 엔드포인트에서 실행 중인 프로세스는 무엇이며, 해당 프로세스가 비정상적인 작업을 수행하고 있었는가? 해당 시간 동안 다른 앱에 액세스했거나 구성을 변경했는가?

이러한 질문에 대해 분류 에이전트는 별도의 조사 하위 에이전트에 위임합니다. 이 하위 에이전트(Claude Opus와 같은 모델)는 상위 에이전트에서 자연어 쿼리를 받아 Snowflake SQL로 변환합니다. 이 시스템은 회사 전체의 감사 로그를 수집하는 Panther 데이터 웨어하우스를 대상으로 실행되며, 여기에는 AWS CloudTrail, Okta 시스템 로그, GitHub 감사 이벤트, GCP 감사 로그, osquery 엔드포인트 텔레메트리, Workshop/Santa 이벤트, Wiz 발견 사항 등 약 100개의 테이블이 포함됩니다.

부모 에이전트는 동료에게 쿼리를 실행해 달라고 요청하는 방식과 유사하게 요청을 호출합니다. 예를 들어, '지난 48시간 동안 사용자 X의 최근 Okta 로그인 기록을 찾아줘', '지난 2일 동안 사용자 Y가 엔드포인트에서 실행한 프로세스를 확인해 줘', 또는 'UTC 기준, 3월 10일 10시 21분부터 20시 21분 사이에 사용자 Z가 AWS EKS에서 무엇을 했는지 확인해 줘'와 같은 요청입니다. 하위 에이전트는 어떤 테이블을 조회하고, 어떤 열을 사용하며, 시간별로 어떻게 필터링할지 결정합니다.

이 방식은 작동하지만 테이블 스키마가 다소 복잡합니다. 로그 소스마다 열 이름이 일관되지 않고, 조인 키에 대한 문서화가 미흡하며, 시간 분할 함수가 테이블마다 다릅니다. 도움 없이 하위 에이전트는 실제 질문에 답하기 전에 스키마를 찾는 데만 네, 다섯 번의 쿼리를 수행해야 합니다. 상황이 더 나쁜 경우, 잘못되거나 불완전한 결과를 반환하는 방식으로 쿼리를 수행할 수도 있었습니다. 아래 메모리 섹션에서 이 문제를 어떻게 해결했는지 살펴보겠습니다.

에이전트 메모리 개발 및 세분화

메모리는 시간이 지남에 따라 시스템의 유용성에 가장 큰 영향을 미치는 요소가 되었습니다. 여러 종류의 메모리가 있으며, 이를 분리하는 것이 중요했습니다.

RAG 코퍼스는 사례 메모리라고 합니다. 이는 앞서 설명한 시스템으로, 과거 알림과 Slack 및 Asana의 조사 컨텍스트를 포함합니다. 에이전트가 유사한 상황이 어떻게 발생했는지 또는 담당 엔지니어가 과거 사건에 대해 어떤 결론을 내렸는지 알아야 할 때 이 코퍼스를 참조합니다.

또한 스티어링 메모리라는 메모리가 있습니다. 이는 에이전트에 대한 행동 지침으로, 매번 실행 시작 시 에이전트의 컨텍스트에 로드되는 마크다운 문서로 저장됩니다. AGENTS.md 파일이나 에이전트가 코드베이스의 취약점을 검사할 때 필요한 위협 모델과 같은 것을 생각해 보세요. 이 파일에는 '오래된 Okta 동기화 알림이 보이면 시스템적인 문제라고 단정하기 전에 resource-sync 및 group-sync 작업을 모두 확인한다' 또는 '사용자 X가 이번 주에 시스템 Y에서 유지 보수 작업을 수행 중이므로 해당 알림을 예상대로 처리한다'와 같은 규칙이 포함됩니다.

에이전트는 보안 엔지니어가 오류를 수정하면 자체 스티어링 메모리를 업데이트할 수 있습니다. 누군가 '잘못 처리했으니 이렇게 해야 한다'고 알려주면, 해당 수정 사항은 향후 실행에도 유지됩니다. 하지만 스티어링 메모리에 저장하는 내용과 RAG 계층에 유지하는 내용을 구분하는 것이 중요하다는 것을 알게 되었습니다. 특정 알림 유형에 대한 일회성 학습 내용은 조사 컨텍스트에 저장하여 향후 유사한 경고에 대한 선례로 활용해야 합니다. 에이전트가 모든 알림에 접근하는 방식을 변경해야 하는 동작 규칙은 스티어링 메모리에 저장해야 합니다. 초기에 저지른 실수 중 하나는 모든 내용을 스티어링 메모리에 저장하는 것이었는데, 이로 인해 에이전트의 동작이 원치 않는 방식으로 재정의되기 시작했습니다. 선례와 정책은 서로 다른 개념이며, 각각 다른 위치에 저장해야 합니다.

또한 Tines에서는 상태를 저장하는 개체에 데이터베이스 기반 레코드를 사용합니다. 예를 들어 에이전트가 생성한 미해결 PR, Panther 조사 상태, 자연어 검색보다는 안정적인 키와 상태 추적이 필요한 항목 등이 있습니다. 이러한 개체는 다소 평범하지만 필수적인 것입니다.

가장 흥미로운 메모리 계층은 절차적 메모리 계층으로, 앞서 설명한 스키마 검색 문제를 직접적으로 해결합니다. 조사 하위 에이전트에게 태그(aws, okta, osquery, workshop 등)별로 정리된 자체 메모리 저장소를 제공했습니다. 에이전트는 쿼리를 시작하기 전에 접근할 데이터 소스와 관련된 메모리를 로드합니다. 스키마 검색이 필요한 조사를 완료한 후에는 학습한 내용을 저장합니다.

Title: Job Description Fields in Workiva Logs (2026-03-12T16:25:21 UTC)
Memory: Job descriptions for each user within the system can be found within the field 'jd' in the table 'WORKIVA_USERS'.

두 번째 LLM(더 가벼운 모델 사용)은 실제 메모리 형식을 처리합니다. 원시 결과를 가져와 UTC 타임스탬프가 포함된 제목을 생성하고 태그를 지정한 다음 메모리에 기록합니다. 조사 에이전트에게 Zoom 활동에 대해 처음 질문했을 때는 여러 검색 쿼리가 필요했습니다. 메모리를 저장한 후에는 동일한 질문에 대해 단일 쿼리 비용만 발생합니다. 에이전트가 시행착오를 통해 자체 운영 매뉴얼을 구축함에 따라 이러한 패턴은 데이터 소스 전체에서 반복되었습니다.

에이전트 조사 사례

에이전트가 실제로 어떻게 작동하는지 설명하기 위해 최근 사례 세 가지를 소개합니다.

첫 번째는 Figma에서 사용 승인을 받지 않은 macOS 오디오 전사 앱을 누군가 설치하여 알림이 발생한 경우입니다. 분류 에이전트는 알림 스레드를 읽고 RAG 계층에서 유사한 과거 알림을 가져온 다음 Okta 및 Workshop 도구를 사용하여 정보를 종합했습니다. 그 결과, 행위자는 탐지 규칙을 작성한 엔지니어인 바로 저 Matthew였습니다! Workshop에서는 테스트를 위해 당일 생성된 개별 범위 규칙이 표시되었습니다. 결론: 규칙 작성자가 자신의 탐지 기능을 테스트하고 있었습니다. 별도의 조치는 필요하지 않았습니다. 에이전트는 제 Slack 상태를 기반으로 제가 업무 중이므로 제 활동을 확인하는 데 시간이 좀 걸릴 수 있겠다는 메모까지 남겼습니다.

다른 사례로는 동일한 서비스 계정에 대해 Snowflake 알림 페이지가 반복적으로 발생하는 경우가 있었습니다. 에이전트는 현재 상황을 설명하고, 조사 담당 하위 에이전트에게 관련 감사 로그를 쿼리하도록 위임했습니다. 그 결과 알림이 반복되는 이유를 파악하고, 알림을 억제하기 위한 PR 초안이 이미 생성되어 있음을 확인했으며, 다른 스레드에서 논의 중인 장기적인 해결 방안을 설명했습니다. 담당 엔지니어는 탭을 하나도 열지 않고도 전체적인 상황을 파악할 수 있었는데, 불과 몇 달 전만 해도 상상할 수 없었던 일입니다.

마지막으로, 악성 코드와 관련될 수 있는 상황에 대해서도 알림이 발생하는 경우가 있습니다. 하지만 대부분은 정상적인 동작(예: Figma MacBook에 알 수 없는 시작 서비스가 설치되는 경우)입니다. 과거에는 이런 상황을 상상조차 할 수 없었습니다. 저희 팀은 수천 명의 Figmate 사용자를 지원하고 있기 때문에 알림량이 폭증하여 업무 부담이 커졌을 것입니다. 하지만 이 새로운 모델에서는 에이전트가 신뢰할 수 있는 기관에서 서명한 바이너리인지 확인하고, Panther 쿼리 기능을 사용하여 설치 경로(brew, App Store 등)를 파악한 다음, 향후 안전한 환경에서 알림을 억제하는 데 필요한 코드 변경 사항을 자동으로 작성할 수 있습니다. 이 모든 과정은 사람의 개입 없이 이루어집니다.

조사에서 코드 변경까지의 과정

시간 절약 측면에서 가장 놀라웠던 단계는 에이전트가 '문제를 파악했습니다'에서 '이 문제를 해결하는 PR입니다'로 넘어가는 과정입니다.

코드 변경 경로로는 두 가지가 있습니다. 탐지 규칙, 허용 목록 및 알림 억제 변경의 경우, 에이전트는 Panther 탐지 리포지토리에 PR을 생성합니다. 일반적인 경우는 다음과 같습니다. 알려진 무해한 패턴에 대해 알림이 계속 발생하고, 담당 엔지니어가 Slack 스레드에서 오탐임을 확인하면, 에이전트는 허용 목록 항목을 생성하거나 탐지 규칙을 조정합니다. 인프라 변경, 서비스 구성, Terraform, RBAC 및 IdP 구성과 같은 기타 모든 작업은 에이전트가 리포지토리를 대상으로 수행합니다.

검토자가 PR에 댓글을 남기면 에이전트는 GitHub 웹훅을 통해 해당 댓글을 감지하고 추가 변경을 하거나 답변할 수 있습니다. 또한 PR이 오랫동안 미해결 상태로 있는 경우 오래된 브랜치를 최신 마스터 브랜치로 리베이스할 수도 있습니다.

안전장치

모든 도구 호출에는 에이전트가 의도하지 않은 작업을 시도하지 않도록 하는 결정론적 안전장치가 포함되어 있습니다. 예를 들어, 에이전트가 생성하는 모든 PR은 자동으로 초안 상태로 설정됩니다. 이 작업은 Tines 작업 흐름의 결정론적 사후 단계로 수행되며, 프롬프트 지시로 제공되지 않습니다. LLM이 '항상 초안으로 생성'을 기억하도록 하는 방식이 충분히 신뢰할 수 없다는 것을 초기 단계에서 발견했기 때문입니다.

이러한 유형의 도구 호출 계약을 사용하여 모든 종류의 제어를 결정론적으로 시행합니다. 예를 들어, 에이전트가 Okta 데이터를 검색할 때 민감한 직원 정보를 수신하거나 처리하지 않도록 보장하고, 자신이 작성하지 않은 풀 요청을 종결하거나 수정하지 않도록 합니다. 모든 시스템의 보안은 계층화된 제어를 기반하므로, 에이전트가 사용할 수 있는 도구의 범위, 권한 및 모니터링이 적절하게 설정되어 있는지, 그리고 에이전트가 권한 있는 팀 멤버를 대신하여 작업하는지 여부에도 세심한 주의를 기울입니다.

또한 잘못된 컨텍스트로 인한 결과를 최소화하기 위해 노력했습니다. 에이전트는 전체 Slack 채널에 대한 접근 권한을 갖지 않으며, DM을 제외하고는 최신 메시지에 명시적으로 태그가 지정된 경우에만 스레드를 읽을 수 있습니다.

마지막으로, 행동이 제한적이고, 되돌릴 수 있으며, 명확한 증거로 뒷받침될 때 자율성을 훨씬 더 편안하게 받아들이지만 행동이 광범위하고, 파괴적이며, 감사가 어려울 때는 그렇지 않습니다. 실제로 이는 읽기 중심의 조사, 중복 탐지, 선례 검색, 초안 수정 등이 일반적인 고성능 쓰기 작업보다는 에이전트 실행에 더 적합하다는 것을 의미합니다.

시간이 지남에 따라 더 많은 알림이 자동으로 처리될 것으로 예상하지만, 이는 더 엄격한 가이드라인, 즉 더 좁은 작업 범위, 더 나은 평가(이 예처럼 지표를 통해 AI 에이전트에 대한 신뢰를 구축하는 방식), 그리고 시스템이 결론에 도달한 이유에 대한 명확한 출처 제시가 뒷받침될 때만 가능합니다.

회고

처음부터 다시 시작한다면 다르게 했을 몇 가지 사항은 다음과 같습니다.

• 절차적 메모리는 처음부터 있었어야 했습니다. 조사 에이전트의 자체 구축 스키마 메모리는 나중에 추가된 기능인데, 그 개선 효과가 너무 커서 돌이켜보면 그 이전의 모든 작업은 거의 헛수고처럼 느껴집니다.
• 에이전트 계층이 파편화되는 것을 방지하려면 코드형 구성이 필수적입니다.팀 멤버들이 빠르게 반복 작업을 하려고 하다 보니, 결국 같은 핵심 에이전트를 약간씩 다른 도구 구성으로 여러 번 복제하고 사용하는 상황이 발생합니다. 예상하시겠지만, 이러한 에이전트에서 사용할 수 있는 모든 도구가 일관성을 유지하고 동일하게 작동하는지 확인하기가 매우 어려워집니다. 현재는 핵심 도구 세트를 개별 에이전트 외부의 코드형 구성에서 구성 및 관리하고 있으며, 이를 통해 모든 에이전트가 잘 관리되고 표준화된 작업의 이점을 누릴 수 있도록 하고 있습니다.
• Slack과 통합할 에이전트를 구축하는 경우, 공개 채널에 대한 신뢰 모델을 사전에 고려해야 합니다. 저희 에이전트는 보안 팀 멤버만 명령을 내릴 수 있도록 권한 제어 기능을 갖추고 있지만, 에이전트가 사용자 활동의 상세 로그를 살펴보려고 하면 온갖 종류의 민감한 데이터가 노출될 수 있습니다. 사용자의 당일 활동에 대한 데이터는 개인 보안 스레드에서는 전혀 문제가 없지만, 수백 명이 모인 공간에서는 심각한 문제가 됩니다. 저희는 채널 인식 프롬프트 설계 및 기타 결정론적 제어 기능을 통해 이러한 문제를 해결하고 있지만, 이는 나중에 추가하는 것보다 처음부터 설계해야 하는 부분입니다.

현재 상황 및 향후 계획

시스템은 팀의 모든 초기 보안 대응 작업을 처리합니다. 담당 엔지니어의 업무는 '처음부터 조사'하는 것에서 '에이전트가 발견한 내용을 검토하고, 확인 또는 수정하며, 사람의 판단이 필요한 사례를 처리'하는 것으로 바뀌었습니다.

복잡한 알림 해결 시간은 약 70% 단축되었고, AI 기반 심각도 하향 조정을 통해 대기 중인 호출 횟수는 20% 감소했으며, 엔드포인트 소프트웨어 승인 요청은 25% 줄었습니다(사용자가 도구에 대해 문의할 때 에이전트가 이를 감지하여 유사한 승인된 대안을 안내함). 또한 에이전트의 증거 체인이 명확하고 검토 가능하기 때문에 담당 엔지니어의 해결 품질에 대한 신뢰도가 크게 높아졌습니다.

1년 후에는 시스템이 수천 건의 분류 결정, 스키마 매핑, 행동 수정 사항을 내재화하게 될 것이며, 이는 팀 멤버 한 명이 모두 기억할 수 있는 양이 아닙니다. 가장 낙관적으로 생각하는 부분이 바로 이것입니다. 특정 에이전트의 실행 결과가 아니라, 모든 실행이 다음 실행을 더욱 효율적이고 정확하게 만들어준다는 점입니다.

다음 단계의 주요 목표는 모델을 중심으로 더 나은 제어 체계를 구축하는 것입니다. 선례, 정책, 상태에 대한 메모리 계층 간의 구분을 더욱 명확히 하고, 모델이 확신을 보이더라도 알림을 자동 종료해야 할지 아니면 에스컬레이션해야 할지를 더 정확하게 판단하는 방법을 모색할 것입니다. 또한 가장 신뢰하는 업무 흐름이 즉각적인 반응 단계를 넘어, 예측 가능하고 검증 가능한 자동화 단계로 발전하기를 바랍니다.

마지막으로 한 가지 덧붙이자면, AI가 완벽하지 않기 때문에 문제 조사에 AI를 사용하는 것이 과연 가치가 있는지에 대한 논의가 많습니다. 하지만 인간 역시 완벽하지 않습니다. 우리는 인간과 AI 중 하나를 선택해야 하는 것이 아니라, 이 두 극단 사이에서 위험을 줄이고 효율성을 높일 수 있는 다양한 방법이 있다고 생각합니다. 그리고 그 방법을 아직도 계속해서 만들어 나가고 있습니다.

우리는 지금까지 구축해온 것에 대해 자부심을 느끼지만, 이는 굉장한 가능성으로 향하는 동시에 여러 어려움이 예상되는 긴 여정의 시작일 뿐이라는 점을 알고 있습니다. 다른 팀이 유사한 시스템을 구축하고 있다면 연락해 주세요! 함께 경험을 공유하고 싶습니다.