레드팀·블루팀·퍼플팀이 협업하는 멀티에이전트 SOC의 작동 방식

①편에서 "Agentic PurpleOps가 무엇이고 왜 만들었는가"를 다뤘다면, 이번 편은 "그래서 어떻게 작동하는가"를 자세히 살펴봅니다. 하나의 위협이 탐지되어 대응에 이르기까지, 그리고 공격 시뮬레이션 하나가 탐지 규칙 개선으로 이어지는 동안 레드팀·블루팀·퍼플팀 에이전트가 실제로 어떤 순서로 협업하는지 단계별 과정을 알아봅니다.

-> Agentic PurpleOps 개념 알아보기

1. 설계 원칙: 왜 멀티 에이전트인가

단 하나의 강력한 LLM에게 "우리 회사 보안을 지켜줘"라고 맡길 수는 없습니다. 보안 운영은 성격이 전혀 다른 복수 작업의 연속이기 때문입니다. 공격 표면을 정찰하는 일부터 로그를 상관 분석하고, 오탐을 가려내며, 대응 조치를 집행하는 일까지 저마다 필요한 전문성과 권한이 완전히 다릅니다.

이 때문에 PurpleOps는 역할을 명확히 분리한 20여 개의 에이전트로 구성됩니다. 각 에이전트는 자신의 임무에 특화된 프롬프트와 도구만 갖습니다. 정찰 에이전트는 스캐닝 도구를, 탐지 에이전트는 SIEM 조회 도구를 사용하는 방식입니다.

권한을 최소 단위로 나누면 시스템이 안전해질 뿐만 아니라 각 에이전트의 판단 품질도 높아집니다. 하나의 만능 에이전트는 모든 일을 조금씩 시도하다 판단을 그르치기 쉽지만, 명확하고 한정된 범위의 임무를 부여받은 에이전트는 자기 영역에서 훨씬 일관된 판단을 내립니다.

2. 아키텍처 구성: 레드팀·블루팀·퍼플팀 3개 진영의 역할

▲ 퍼플팀 산하에서 조율되는 레드팀·블루팀 하위 에이전트 팀 구성 (예시)

퍼플팀은 지휘자입니다. 직접 공격하거나 방어하기보다 누가, 무엇을, 언제 수행할지를 결정합니다. 레드팀이 찾아낸 공격 경로를 블루팀의 탐지 엔지니어에게 전달해 새로운 탐지 규칙을 수립하게 하고, 블루팀이 발견한 탐지 공백을 레드팀에 넘겨 실제 침투가 가능한지 검증하게 합니다. 이 양방향 순환 구조가 ①편에서 언급한 '닫힌 루프'의 실체입니다.

3. 격리 설계: 레드팀과 블루팀이 서로를 볼 수 없는 이유

이 순환 구조에서 의외로 중요한 요소는 '격리'입니다.

공격 에이전트와 방어 에이전트는 서로 다른 서버에서 운영되며, 두 서버 간 직접 통신은 네트워크 수준에서 차단되어 있습니다. 모든 정보 교환은 퍼플팀이 관리하는 통제된 채널만을 거칩니다.

이처럼 엄격한 격리 원칙을 세운 이유는 두 가지입니다.

1. 훈련의 공정성: 레드팀이 블루팀의 탐지 규칙을 미리 들여다볼 수 있다면 그 공격은 실효성 있는 검증이 아니라 형식적인 훈련에 그치고 맙니다. 실제 공격자는 조직의 방어 규칙을 모른 채 공격을 시도하기 때문입니다.

2. 안전성: 공격 도구를 보유한 에이전트가 방어 인프라 권한에 절대 접근할 수 없도록 차단해 자율 에이전트에 공격 임무를 맡기더라도 안전한 구조를 유지할 수 있습니다.

"협업은 설계로, 격리는 아키텍처로 강제한다" — 이것이 엘리스가 세운 원칙입니다.

4. 탐지-대응 파이프라인: 하나의 위협이 흐르는 경로 (블루팀 사이클)

신규 위협이 관측되었을 때 에이전트들이 협업하는 순서를 단계별로 살펴봅니다.

1. 트리아지(Triage): SIEM에 고위험 알림이 발생하면 로그 트리아지 에이전트가 자동으로 수집·분류하고, 노이즈와 유효 신호를 구분합니다

2. 헌팅: 위협 헌팅 에이전트가 관련 로그를 교차 조회해 가설을 수립하고, 실제 데이터로 검증(Confirmed/Refuted)합니다. 근거가 없는 가설은 자동 폐기됩니다.

3. 인텔리전스 보강: 위협 인텔리전스 에이전트가 해당 IP·해시·도메인의 평판 및 위협 정보를 결합해 맥락 데이터를 채웁니다.

4. 오탐 재검증: 보고 직전, 별도의 검증 에이전트가 "이것이 정말 위협인가?"를 능동적으로 되짚어 검증합니다. 확신이 없는 상태에서 임의로 자동 종결 처리하지 않습니다.

5. 대응 제안 + 사람 승인(HITL): 차단이나 격리가 필요하면 명확한 근거와 함께 승인 카드를 생성해 담당자에게 전달합니다. 복구가 어려운 조치는 반드시 사람이 직접 승인합니다.

6. 피드백 순환: 이 과정에서 드러난 탐지 공백은 퍼플팀을 거쳐 레드팀의 검증 시나리오와 블루팀의 규칙 개선 과제로 이어집니다.

같은 시간, 레드팀 사이클 역시 독립적으로 동작합니다. 퍼플팀이 배분한 검증 시나리오를 레드팀이 정해진 자산 범위 내에서 실행하고, 그 공격이 블루팀의 탐지망에 걸리는지 여부가 곧 탐지 성적표가 됩니다. 실제로 레드팀의 공격 체인이 블루팀에 탐지·차단당하는 사례가 반복해서 관측되었습니다. 이는 두 사이클이 인위적 각본 없이 실제처럼 맞물려 돌아가고 있음을 입증합니다.

5. 실제 운영 사례: 오케스트레이션이 만드는 차이

1) "검증되었지만 차단되지 않은" 위협 공백 방지

헌팅 에이전트가 정탐(True Positive)으로 판정한 위협 중 아직 조치되지 않은 건이 있다면, 오케스트레이션 훅(Orchestration Hook)이 이를 자동으로 대응 단계로 승격시킵니다. 동일한 공격 소스를 기준으로 사건을 그룹화하고, 대응·포렌식 에이전트를 호출해 조치 제안을 생성합니다. 사람은 해당 제안을 검토·승인만 하면 됩니다. '탐지는 되었으나 조치되지 않은 위협'이라는 전형적인 방치 공백을 구조적으로 차단합니다.

2) 애매한 신규 이벤트를 자동으로 되짚기

처음 관측된 유형의 알림은 즉시 위협으로 단정하기 어렵습니다. PurpleOps는 이러한 이벤트를 기술 검증 에이전트 및 다수 관점 교차 검증(Council) 체계로 라우팅하여 정탐 확정 또는 판단 보류(Deadlock)로 분류합니다. 애매하다고 해서 자동 삭제하지 않고 사람의 검토 대상으로 남겨, 미탐(False Negative)과 과잉 대응을 동시에 최소화합니다.

3) AI가 작성한 탐지 규칙의 단계적 검증 및 배포

탐지 엔지니어 에이전트가 생성한 규칙 초안은 즉시 전역 배포되지 않습니다. 제한된 범위의 *카나리(Canary) 환경에 먼저 적용하여 24시간 동안 오탐(False Positive) 여부를 모니터링하고, 그 결과를 바탕으로 사람이 승인해야 전체 환경으로 승격됩니다. 규칙 생성은 자동, 신뢰는 검증, 배포는 승인이라는 소프트웨어 CI/CD 원리를 탐지 규칙 운영에도 동일하게 적용했습니다.

*카나리(Canary): 새로운 소프트웨어 버전을 전체 사용자에게 일괄 적용하기 전, 소수의 사용자나 일부 트래픽에만 먼저 적용해 오류나 성능 저하를 감지하는 안전한 무중단 배포 전략

6. 자동화와 HITL(Human-In-The-Loop)의 경계

이 명확한 경계 설정이 PurpleOps 설계의 핵심입니다.

반복적이고 안전하게 복구 가능한 작업은 에이전트에 자율성을 부여하고, 영향도가 크고 되돌리기 어려운 조치는 사람의 판단을 거치도록 통제합니다. 그 사이를 퍼플팀 오케스트레이터가 매끄럽게 이어줍니다.

또한 이 과정에서 이루어지는 모든 판단은 트레이싱 계층에 상세히 기록되어, 어떤 에이전트가 어떤 근거로 무슨 조치를 취했는지 언제든 재구성할 수 있습니다.