CLAWPOD ENGINEERING

만능 에이전트보다 안전한 SOC를 설계하는 법

분석·실행·종료 권한을 분리하고 canonical case history, 정확히 한 번의 효과, HumanDecision, fail-closed 복구로 에이전트 SOC를 감사 가능하게 만드는 운영 설계를 살펴봅니다.

ClawPod Engineering · 8분 읽기
검토Editorial Review · Security Architecture Review
현대적인 보안관제센터에서 여러 분석가가 중앙 사고 증거를 검토하며 제한된 대응 조치를 협의하는 모습

**SOC(Security Operations Center, 보안관제센터)**는 보안 신호를 지속적으로 수집하고, 위협을 탐지하고, 증거를 조사하고, 승인된 억제 조치를 조율하고, 그 효과를 검증한 뒤 사고를 종료하는 조직이자 운영 기능입니다. 단순한 대시보드나 경보 처리 팀이 아니라, 탐지부터 실제 대응과 종료까지 책임 있게 이어 주는 사람·절차·기술의 결합입니다.

사람 SOC와 Agent SOC의 보안 임무와 권한 경계는 같습니다. 사람은 교대 근무, 회의, 티켓, 전문가 판단으로 맥락을 넘깁니다. Agent는 canonical case history를 계속 다시 읽고 범위가 제한된 반복 인계를 연속 실행할 수 있습니다. 그러나 Agent는 사람의 권한을 없애지 않습니다. 증거, 승인 범위, 실행 결과를 확인할 수 없으면 추정해서 진행하지 않고 fail closed, 즉 안전하게 멈춰야 합니다.

예를 들어 SIEM이 의심스러운 출발지를 탐지했다고 해보겠습니다. 안전한 SOC는 “경보가 왔으니 차단했다”로 건너뛰지 않습니다. 누가 증거를 해석하고, 누가 차단 범위를 결정하며, 어떤 시스템이 실제 네트워크를 바꾸고, 누가 결과를 확인해 사건을 닫는지를 분리합니다. 아래 세 부분은 SOC의 구성, 운영 순서, 실제 공격 대응 여정을 차례로 설명합니다.

1. SOC 구성: 역할과 기술 시스템을 분리한다

이 SOC 설계는 역할을 이름이 아니라 금지된 권한으로 구분합니다.

구성 요소 맡는 일 맡지 않는 일
SIEM 탐지, 증거, canonical case history 네트워크 상태 변경
Service Desk 새 사건 등록 확인, 분류, 적격 담당자에게 인계 악성 판정, 차단 승인
Analyst 증거 해석, 가설과 범위 작성, 필요한 조치 제안 외부 효과 실행, 자기 분석의 최종 인증
Action Executor 승인 범위를 검증하고 안정적 실행 identity로 요청 새로운 악성 판정, 승인 범위 확대
Action Provider / Enforcement Point 승인된 효과를 실제 통제면에 적용하고 결과 제공 사건 의미 해석, 사건 종료
Reporter 기록을 다시 읽고 증거·권한·효과를 대조해 종료 또는 Correction 요청 누락된 증거 추정, 실행 결과 자가 생성
Leader 조직 라우팅, 역할 적격성, HumanDecision 연결의 유효성 확인 그림자 Analyst, Executor, 종료자 역할
Operator worker, queue, 연결 등 플랫폼 건강 복구 사건 의미 판단, 차단 승인, 사건 종료

HumanDecision은 단순한 사람의 답장이 아닙니다. 원래 요청 identity, 사건 revision, 대상과 범위의 digest, 허용하거나 거절한 응답이 함께 기록되고 read-back된 승인 객체입니다. Correction은 과거를 덮어쓰는 되감기가 아니라 잘못된 분석이나 기록을 바로잡는 새롭고 제한된 전이입니다. Correction 자체는 재실행 권한을 주지 않습니다.

다음은 의심스러운 출발지 하나를 격리하는 일반화된 흐름입니다. 실제 주소, 탐지 규칙, 공급자, 임계값은 의도적으로 제외했습니다.

flowchart TD
  S[SIEM 탐지와<br/>증거] --> D[Service Desk<br/>등록과 라우팅]
  D --> C[Canonical case<br/>history]
  C --> A[Analyst<br/>해석과 범위]
  A --> H{권한 경로}
  H -->|사람 판단 필요| L[HumanDecision<br/>Leader가 연결 검증]
  H -->|사전 승인 범위| X[Action Executor<br/>범위와 identity 검증]
  L --> X
  X --> P[Action Provider와<br/>Enforcement Point]
  P --> R[결과 기록과<br/>read-back]
  R --> Q[Reporter<br/>독립 대조]
  Q -->|충족| Z[종료]
  Q -->|불일치| K[Correction 또는<br/>제한된 복구]
  O[Operator<br/>플랫폼 건강 지원] -. 사건 판단 불가 .-> C
  linkStyle default fill:none,stroke:#64748b,stroke-width:1.5px

Service Desk는 경보 identity와 기록 상태를 확인해 Analyst에게 넘깁니다. Analyst는 SIEM 증거를 읽고 “이 출발지가 악성이다”라는 결론뿐 아니라 관찰, 대안 가설, 대상 범위, 제안 조치를 기록합니다. 애매하거나 보호 대상 여부를 확인할 수 없거나 권한 범위를 벗어나면 실행으로 가지 않습니다.

조치가 사전 승인된 좁은 범위 안에 있으면 Action Executor가 revision, 대상, 동작, 만료, effect identity를 확인합니다. 그렇지 않으면 scope-bound HumanDecision이 필요합니다. Leader는 적격한 사람과 원 요청의 연결이 유효한지 확인할 수 있지만 판단 내용을 대신 만들지는 않습니다.

Executor는 승인된 Action Provider에 요청하고, Enforcement Point가 상태를 바꿉니다. 응답을 받았다는 사실만으로 성공 처리하지 않습니다. 공급자의 operation identity와 적용 상태를 read-back해 사건에 append합니다. Reporter는 SIEM 이력을 처음부터 다시 읽고 분석 근거, 승인 범위, provider 결과, enforcement 확인이 서로 맞는지 대조합니다. 모두 맞을 때만 종료하며, 불일치는 Correction이나 제한된 복구로 보냅니다.

Operator는 이 흐름 바깥에서 queue 정체나 worker 장애, 연결 문제를 복구할 수 있습니다. 하지만 플랫폼이 다시 건강해졌다는 사실은 차단이 옳았거나 성공했다는 뜻이 아닙니다. Operator가 사건 소유권을 가져가 의미를 판단하면 권한 분리가 무너집니다.

이 역할 분리가 실제 인프라에서 어떻게 닫힌 대응 루프를 만드는지는 아래 그림처럼 볼 수 있습니다. 경계 장비와 서버 보호 솔루션의 로그가 SIEM으로 모이고, AI SOC는 탐지와 분석 뒤 승인된 범위의 초기방어만 Action Provider에 요청합니다. 실제 상태는 FW, WAF, IPS, EDR 같은 Enforcement Point가 바꾸며, 적용 결과는 반드시 read-back해 확인합니다.

인터넷에서 방화벽, 라우터, IPS와 IDS, 스위치, 웹 방화벽, DMZ와 내부 서버팜으로 이어지는 방어 계층의 로그가 SIEM에 모이고, AI SOC가 승인된 초기방어를 Action Provider와 실제 Enforcement Point에 적용한 뒤 상태를 다시 확인하는 흐름
AI SOC 인프라의 로그 수집, 승인된 정책 적용, 실제 통제와 read-back 폐루프

2. SOC 운영 순서: 경보 접수에서 종료 또는 Correction까지

전체 운영 순서는 경보 접수 → Canonical Case 생성과 이력 축적 → 분석 → 권한 기록 → 조건부 인계 → 실행 → read-back → 종료 또는 Correction입니다. 이 설계의 제어면은 채팅방이 아니라 SIEM의 canonical case history, 즉 사건의 기준 기록입니다. SIEM은 탐지와 증거, 사건 상태와 이력을 보존합니다. 실제 네트워크나 보안 상태를 바꾸는 주체는 별도로 승인된 Action Provider와 Enforcement Point입니다. 기록 시스템과 효과 시스템을 분리해야 “무엇을 안다”와 “무엇을 바꿨다”를 혼동하지 않습니다.

최소한의 사건 기록에는 다음이 필요합니다.

  • 경보와 사건의 안정적인 식별자
  • 원본 증거와 분석 결과를 가리키는 참조
  • 현재 단계, 소유 역할, revision 또는 version
  • 허용된 대상, 동작, 범위, 만료 조건
  • 이전 상태를 지우지 않는 전이 이력
  • 실행 의도, effect identity, 공급자 결과와 read-back

여기서 work evidence는 기준 기록에 append되고 다시 읽어 확인된 분석, 승인, 실행 결과입니다. transport evidence는 채팅 메시지, 이메일, webhook delivery처럼 “어딘가를 보라”고 깨우는 전달 흔적입니다. 메시지 도착은 작업 완료가 아니며, webhook 한 번은 효과 한 번을 뜻하지 않습니다.

인계도 하나의 검증 가능한 transaction으로 취급합니다. 담당자는 현재 version을 읽고 결과나 의도를 append한 뒤 독립적으로 read-back합니다. 그 다음 예상 version과 소유자를 조건으로 다음 역할에 넘기고, 전이가 실제 반영됐는지 다시 확인합니다. 충돌하면 현재 상태를 보존하고 멈춥니다. 마지막 locator 신호는 편의를 위한 알림일 뿐 권한이 아닙니다.

flowchart TD
  A[경보 접수] --> B[Canonical Case<br/>생성과 이력 축적]
  B --> C[증거 분석과<br/>대응 범위 제안]
  C --> D{권한 기록이<br/>유효한가?}
  D -->|예| E[revision과 소유자 기준<br/>조건부 인계]
  D -->|아니요| F[Fail closed<br/>사람 판단 대기]
  E --> G[승인 범위 안에서<br/>실행]
  G --> H[결과 append와<br/>독립 read-back]
  H --> I{증거·권한·효과가<br/>일치하는가?}
  I -->|예| J[사건 종료]
  I -->|아니요| K[Correction 또는<br/>제한된 복구]
  K --> B
  linkStyle default fill:none,stroke:#64748b,stroke-width:1.5px

3. 공격 대응 순서: 탐지 신호가 실제 차단이 되는 여정

구체적인 공격 대응은 센서·로그 수집 → SIEM 탐지 → 증거 상관분석 → 차단 범위 결정 → 실제 네트워크 통제 계층 차단 → 결과 검증 → 사고 종료로 진행됩니다. “차단 요청을 보냈다”와 “네트워크에서 차단이 적용됐다”는 같지 않습니다.

flowchart TD
  S[센서와 로그<br/>보안 신호 수집] --> I[SIEM 탐지와<br/>사건 연결]
  I --> E[증거 상관분석<br/>오탐과 영향 확인]
  E --> B{차단 대상·범위·만료<br/>결정과 승인}
  B -->|승인됨| P[Action Provider<br/>통제 요청 변환]
  B -->|불명확| F[Fail closed<br/>사람 검토]
  P --> N[Enforcement Point<br/>네트워크 계층 실제 차단]
  N --> R[적용 상태와<br/>operation identity 확인]
  R --> Q{탐지·승인·효과가<br/>일치하는가?}
  Q -->|예| Z[사고 종료]
  Q -->|아니요| C[Correction 또는<br/>효과 상태 조정]
  linkStyle default fill:none,stroke:#64748b,stroke-width:1.5px

엔드포인트 센서와 게이트웨이 로그가 같은 의심스러운 출발지를 가리키면 SIEM은 경보와 원본 증거를 Canonical Case에 연결합니다. Analyst는 시간대, 대상 자산, 다른 신호, 오탐 가능성을 상관분석하고 어느 출발지를 어느 통제 지점에서 얼마 동안 차단할지 제안합니다. 승인 범위가 확정되면 Executor가 stable effect identity와 함께 Action Provider를 호출하고, 방화벽이나 게이트웨이 같은 Enforcement Point가 실제 데이터·네트워크 통제 계층에 차단을 적용합니다.

응답 timeout은 실패가 아닙니다. 첫 요청이 이미 적용됐을 수 있으므로 자동 반복하지 않습니다. provider와 Enforcement Point 상태를 read-back해 성공, 확정 실패, Possible Effect를 구분합니다. Reporter는 탐지 근거, 승인 범위, operation identity, 실제 적용 상태를 대조해 모두 일치할 때만 종료합니다. 불명확하면 자동 재시도와 종료를 막고 상태를 조정하거나 새 권한을 받습니다.

정확히 한 번의 전달이 아니라, 정확히 한 번의 효과 discipline

분산 시스템에서 delivery는 재시도될 수 있습니다. 따라서 이 설계가 목표로 하는 것은 “webhook이 정확히 한 번 왔다”는 보장이 아니라, 중복 전달 속에서도 같은 승인된 효과를 식별하고 deduplicate하거나 reconcile하는 exactly-once effect discipline입니다.

안정적 execution identity는 대략 다음 요소를 묶습니다.

case identity + transition identity + action + target
+ authorized revision/scope + idempotency or provider operation identity

Executor는 실행 전에 같은 identity가 이미 확정됐는지 읽습니다. 요청 후에는 세 결과를 구분합니다.

flowchart TD
  A[승인된 효과] --> B[Provider 실행 결과]
  B -->|확정 성공| C[effect identity 기록<br/>read-back 후 진행]
  B -->|확정 실패| D[제한된 복구<br/>재시도 조건 평가]
  B -->|timeout 또는 불명| E[Possible Effect<br/>자동 재시도 차단]
  E --> F[Provider 상태 조정<br/>또는 새 권한]
  D --> G{재시도 권한과<br/>안전 조건 충족?}
  G -->|예| A
  G -->|아니요| H[보존하고 중단]
  linkStyle default fill:none,stroke:#64748b,stroke-width:1.5px

확정 성공은 effect identity와 read-back 증거를 기록하고 다음 단계로 갑니다. 확정 실패는 원인을 기록하고, 기존 승인에 재시도 범위가 포함됐는지 평가합니다. unknown 또는 Possible Effect는 가장 조심해야 할 상태입니다. timeout은 실패가 아닙니다. 첫 요청이 적용됐을 수 있으므로 자동 재시도를 막고 provider 상태를 reconcile하거나 새로운 권한을 받아야 합니다.

이 discipline은 네트워크가 정확히 한 번 전달된다고 보장하지 않습니다. duplicate request, worker 재시작, 늦은 응답이 있어도 실제 효과의 identity와 상태를 기준으로 안전하게 판단하려는 운영 규칙입니다.

Correction은 되감기가 아니고, 이메일은 승인이 아니다

Analyst가 대상을 잘못 분류했다면 이전 기록을 수정하거나 삭제하지 않습니다. 새 Correction이 어느 결론이 왜 바뀌었는지, 어떤 downstream 상태를 다시 검토해야 하는지 기록합니다. 이미 효과가 발생했다면 “분석 정정”과 “효과 되돌리기 승인”은 별개입니다. 자동으로 반대 동작을 실행하면 두 번째 사고를 만들 수 있습니다.

사람의 판단도 전달 수단과 분리합니다. 이메일 전송 성공, 메일 열람, 회신 도착, 채팅의 “좋아요”, 응답 없음은 어느 것도 그 자체로 승인되지 않습니다. 유효한 HumanDecision은 원 요청 identity와 revision, 정확한 scope, 응답 주체와 결정, 기록된 시각을 결합하고 canonical case에서 다시 읽혀야 합니다. 범위가 바뀌거나 revision이 진행됐다면 이전 응답을 재사용하지 않습니다.

멈춘 뒤, 증거로 복구한다

안전한 SOC는 모든 상황에서 계속 움직이는 시스템이 아닙니다. 다음 조건에서는 fail closed가 기본이어야 합니다.

  • 사건 version이나 소유권이 예상과 다르다.
  • 증거가 누락되었거나 대상 범위가 모호하다.
  • 보호 대상 여부나 승인 scope를 확인할 수 없다.
  • HumanDecision을 원 요청과 신뢰성 있게 연결할 수 없다.
  • 공급자 결과가 unknown이며 Possible Effect를 배제할 수 없다.
  • 실행 결과나 소유권 전이를 read-back하지 못했다.

정지는 끝이 아니라 명시적인 복구 상태입니다. 복구 기록은 현재 알려진 상태, 이미 발생했을 수 있는 효과, 정지 원인, 안전하게 재개할 정확한 조건을 포함해야 합니다. 빠른 대응 경로도 이 경계를 없애지 않습니다. 우선순위나 사전 승인 scope는 바꿀 수 있지만 effect identity, read-back, 독립 종료 검증을 생략해서는 안 됩니다.

ClawPod의 공개 Guide는 Agent를 역할, 자격 증명, skill과 도구, 조직 정책 경계로 구성하는 개념을 설명합니다. 이는 이런 역할 분리를 구현할 수 있는 일반적 맥락일 뿐입니다. 이 글의 SIEM, Action Provider, CAS 방식 소유권, HumanDecision binding, exactly-once effect 처리, Reporter 흐름이 모두 ClawPod의 일반 제공 기능이라는 뜻은 아닙니다. runtime에 보이는 기능도 곧 지원되는 고객 제품 경로를 의미하지 않으므로 실제 배포와 권한을 별도로 확인해야 합니다.

아키텍처 검토를 위한 여섯 질문

  • 모든 역할이 대화가 아니라 하나의 canonical case history를 다시 읽어 일을 재구성할 수 있는가?
  • 증거 해석, 효과 승인, 실행, 성공 인증이 서로 다른 권한 경계에 있는가?
  • append, read-back, 조건부 소유권 전이와 최종 확인 없이는 인계가 완료되지 않는가?
  • 안정적 effect identity로 중복을 감지하며 unknown 결과에서 자동 재시도를 막는가?
  • Correction과 HumanDecision이 identity, revision, scope에 묶이고 재실행 권한과 분리되는가?
  • 충돌이나 불확실성에서 fail closed하고, 알려진 상태·가능한 효과·재개 조건을 기록하는가?

여섯 질문 중 하나라도 “아니요”라면 Agent를 더 추가하기 전에 그 경계를 먼저 설계해야 합니다. Agent 수는 처리량을 늘릴 수 있지만 통제 가능성을 자동으로 만들지는 않습니다. 더 많은 Agent가 가치 있는 순간은 각자가 할 수 없는 일을 명확히 하고, 모든 결정과 효과를 기준 기록에서 다시 구성할 수 있을 때입니다.

Sources