밤 시간대에도 잠들지 않는 방법: Switch 기반으로 구축된 SOC의 감시를 유지하는 AI 에이전트

Flip the Switch를 위해 제작됨 (WeMakeDevs, DevTools Academy, Switch AI), 트랙 01: 최고의 비즈니스 워크플로우. 코드: github.com/manoj1698/soc-shift-relay.

문제점: 인수인계
보안 운영팀은 교대 근무를 하며, 매일 밤 두 가지 문제가 발생합니다. 새벽 2시에 잠든 사람을 기다리는 경고가 있거나, 지난주 팀이 승인한 스캔 때문에 누군가를 깨웁니다. 아침 9시에는 다음 분석가가 어떤 세 가지 알림이 중요한지 전혀 모르는 수많은 경고의 벽에 직면합니다. 매번 인수인계 과정에서 맥락(Context)이 손실됩니다.

저는 챗봇처럼 작동하는 것이 아니라, 교대 근무 동료처럼 행동하는 에이전트들을 원했습니다. 이들은 감시를 유지하고, 안전한 것들을 수정하며, 위험한 일이 있기 전에 사람에게 물어보고, 다음 근무조가 정확히 어디서 시작해야 하는지 알려주는 것입니다.

아이디어: 다섯 개의 에이전트, 하나의 공간
SOC Shift Relay는 Switch를 통해 팀의 Discord에 다섯 개의 Claude Code 에이전트를 배치합니다:

@triage는 모든 경고를 runbook과 대조하여 확인하고, 알려진 오탐(false positives)을 닫으며, #security-help에서 문제를 보고하는 직원들에게 답변합니다.
@responder는 무언가를 변경할 수 있는 유일한 에이전트입니다: IP를 차단하거나, 계정을 비활성화하거나, 호스트를 격리할 수 있습니다. 이 에이전트는 먼저 제안하고, 실제 조치는 온콜(on-call) 분석가가 채팅에서 'Allow'를 한 번 누른 후에만 실행됩니다.
@scribe는 근무 기록(shift log)과 온콜 명단(roster)을 유지하고, 다음 분석가에게 브리핑하며, 요청 시 근무 보고서 또는 사고 보고서를 작성합니다.
@appsec는 모든 코드 푸시(code push)를 스캔합니다: 유출된 비밀 정보(leaked secrets), 위험한 코드, 취약한 의존성(vulnerable dependencies), 악성코드 패턴을 확인합니다. 이 에이전트는 해당 푸시에 플래그를 지정하고, 공격자 주소를 @responder에게 전달하며, 스스로 재스캔하여 깨끗하게 만든 수정 사항을 작성합니다. 절대 병합(merge)하지 않습니다.
SIEM 에이전트는 샘플 경고와 코드 푸시가 이루어진 밤을 재현합니다.

안전 설계: 세 가지 계층(tier)을 가진 runbook
runbook은 모든 에이전트가 읽는 문서이며, 그 계층들이 모든 것을 결정합니다:

티어 0(Tier 0), 에이전트 단독 수행: 조회(lookups), 알려진 노이즈 차단(closing known noise), 직원을 위한 안전 조치, 푸시 스캔(scanning a push), 제안된 변경 사항으로 수정 준비, 로그 작성.
티어 1(Tier 1), 온콜 승인 필요: IP 차단 또는 해제, 계정 비활성화 또는 재활성화, 호스트 격리 또는 방출.
티어 2(Tier 2), 사람만 수행 가능: 데이터 삭제, 보호 대상(protected targets) 접근/수정, 코드 병합(merge code), 유출된 키 순환(rotate a leaked key).
"승인 대기(wait for approval)"라고 적힌 간략한 메모는 단지 요청일 뿐입니다. 따라서 모든 규칙은 프롬프트 외부의 무언가에 의해 유지됩니다. @responder는 Auto 모드를 비활성화하여 실행되며, 그 Claude Code 설정은 모든 액션 스크립트 요청을 표시하므로, Switch의 승인 요청이 답변되기 전까지 해당 스크립트는 시작할 수 없습니다. 이 스크립트들은 승인이 이루어져도 보호 대상(protected targets)을 거부합니다. Deny rules는 실험실 상태(lab state)와 모든 네트워크 도구에 대한 편집을 차단합니다. @appsec는 자신이 스캔하는 코드를 작성, 실행 또는 설치할 수 없습니다. 모든 액션은 감사 로그(audit log)에 JSON 라인을 기록하며, 보고서는 이 로그를 인용하므로, 보고서가 승인을 임의로 만들어낼 수는 없습니다.

Switch 기반으로 구축하기
Switch는 다섯 개의 챗봇을 팀으로 전환시키는 역할을 합니다:

역할(Roles/jobs). 직무는 에이전트가 아닌 사람이 맡습니다 (@scribe). 만약 에이전트가 오프라인 상태가 되면, 다른 에이전트가 그 역할을 대신할 수 있습니다. 이는 에이전트에 적용된 '교대 근무(shift)' 개념입니다.

t리아지(triage)는 공유되지만, 응답자(responder), 기록 담당자(scribe), 앱 보안(appsec)은 개별적입니다. 따라서 두 번째 에이전트가 병렬로 작동하는 일은 없습니다.

채팅에서의 승인(Approvals in chat). 승인 요청에는 정확한 명령어가 표시됩니다. 온콜(On-call) 응답은 'Allow once' 또는 'Decline'으로 답변하며, Switch는 누가 답변했는지 기록합니다.

방 문서가 메모리 역할을 합니다. 문서를 생성한 에이전트만이 수정할 수 있으므로, 교대 근무 로그(shift log)에는 정확히 한 명의 저자가 있습니다. 로스터도 여기에 존재합니다: @scribe에게 "Asha가 월요일까지 휴가이니 Spider가 대신한다"고 말하면, 그녀의 후속 조치(follow-ups)는 Spider에게 전달됩니다. 부재는 결코 승인으로 간주되지 않습니다.

에이전트와 대화할 수 있는 주체. 직원들은 @triage에만 접근할 수 있으며, 절대로 @responder에는 할 수 없습니다. 제 두 번째 계정이 응답자에게 사용자 비활성화를 지시했을 때, Switch는 채널에서 이를 거부했습니다.

연결된 방(Linked rooms). #security-help가 #soc-shift로 에스컬레이션됩니다.

템플릿. 하나의 YAML 파일이 다섯 개의 모든 에이전트, 두 개의 방, 연결(link), 역할, 실행 매뉴얼(runbook), 그리고 시작점(kickoff)을 재현합니다. 심사위원(judge)이 이를 가져와서 제가 기록한 것과 동일한 방을 얻게 됩니다.

02:40의 코드 푸시

제가 가장 자랑스러운 새로운 부분은 다음과 같습니다. 02:40에 계약자 계정이 payments-api에 "핫픽스(hotfix)"를 푸시합니다. @appsec는 푸시가 추가한 라인만 스캔하고 다섯 가지 발견 사항과 함께 'BLOCK'을 반환합니다:

• 배포 스크립트에 포함된 알 수 없는 호스트에서의 curl | sh
• 모든 출력에서 마스킹 처리된 실제 결제 API 키(live payment API key)
• f-string 형태의 SQL 쿼리
• PyYAML 5.3과 requests 2.19.1 사이에는 다섯 개의 공개된 CVE가 있습니다.

@responder는 'Allow once' 이후 해당 호스트를 차단합니다. @appsec는 결제 재시도(payment retries)를 유지하는 제안된 변경 사항으로 수정 내용을 작성하고, 이를 다시 스캔하여 PASS로 만들며, 병합(merging)과 키 로테이션(key rotation)은 사람에게 맡깁니다. 이 스캐너는 표준 라이브러리이며 오프라인에서 작동하며, Gitleaks, Semgrep, OSV-Scanner 및 YARA를 모델로 한 규칙을 가지고 있어 어떤 기기에서도 데모가 실행됩니다.

무엇이 잘못되었고, 내가 배운 것
Windows는 얼리 액세스(early access) 버전입니다. Switch 콘솔을 Windows에서 사용했을 때 템플릿의 제공자 필드(provider field)를 채울 수 없었기 때문에, 이 템플릿은 모든 에이전트에 대해 Claude Code를 고정합니다. 어쨌든 이것이 정직한 선택지이며, 가드레일(guardrails) 자체가 Claude Code 설정입니다.

신뢰는 모든 것을 바꿉니다. Claude Code는 폴더가 신뢰되지 않으면 해당 폴더의 허용 규칙(allow rules)을 무시하며, Switch는 신뢰 대화 상자 없이 에이전트를 시작합니다. 제가 설정 스크립트에 --trust 단계를 추가하기 전까지, 사소한 상태 확인 요청조차 온콜(on-call) 승인을 요구했습니다.

에이전트는 볼 수 없는 것을 의심합니다. 응답자는 승인 자체를 본 적이 없었기 때문에, 한 리허설(rehearsal)에서 승인된 블록을 '미확인(unconfirmed)'으로 호출했고, 아침 브리핑 내용이 잘못되었습니다. 그가 작성한 문장 하나가 이를 바로잡았습니다: 만약 당신의 명령어가 실행되었다면, 온콜이 그것을 승인했다는 것입니다.

정확한 명령어가 중요합니다. cd folder && python actions/status.py는 python actions/status.py에 대한 허용 규칙과 일치하지 않았습니다. 이제 브리핑에서는 작성된 대로 정확하게 명령어를 실행하라고 말합니다.

에이전트는 @만 듣습니다. 에이전트를 언급하지 않은 메시지는 그에게 도달하지 않기 때문에, 근무 교대 시점은 "@scribe end of shift"이며 직원실에는 트리아지(triage)가 주요 에이전트로 배치되어 있습니다.

직접 실행해보기
레포지토리를 클론하고, 설정 가이드(Windows 및 Discord, 처음에는 약 한 시간 소요)를 따르고, 템플릿을 가져와서, python tools/reset_demo.py를 실행한 다음, @soc-siem start night shift를 입력하세요.

보안을 넘어
런북(runbook)과 실험실(lab)만이 보안에 특화되어 있습니다. 이 둘을 교체하면 동일한 공간이 IT 헬프데스크, 고객 지원 근무조, 또는 네트워크 운영팀의 역할을 수행할 수 있습니다: 트리아지, 승인 게이트가 설정된 응답자, 다음 근무조에게 브리핑하는 스크라이브(scribe), 그리고 배포되기 전에 모든 변경 사항을 확인하는 에이전트입니다.

#HowISwitch