Deep Hat Sift: 에이전트 실행을 생략하는 데도 승인이 필요하다

운영 에이전트는 경보를 훌륭히 검토하면서도 하루 대부분을 아무 조치가 필요 없다는 결론을 내리는 데 쓸 수 있습니다. 처리량이 커지면 정확하지만 별일 없이 끝나는 이런 실행도 시스템 설계 문제가 됩니다.

Kindo는 2026년 10월 28일 Deep Hat Sift를 발표했습니다. 에이전트의 판정에서 학습해 어떤 유입 이벤트에 실행이 필요한지 점수를 매기는 System One 결정 모델입니다. 처음에는 모든 이벤트를 통과시키는 섀도 모드로 시작하며, 사람이 임계값을 승인한 뒤에만 전달을 보류합니다. Kindo의 공지.

흥미로운 부분은 일어나지 않을 일, 즉 시작하지 않는 실행을 승인한다는 점입니다. 이 글에서는 그 결정을 설명하고 더 단순한 비용 관리 방식과 비교한 뒤, 줄인 호출과 함께 중요한 누락도 측정하는 파일럿을 제안합니다.

2008년 공개된 메릴랜드 대학교 물리 보안 모니터링 센터 사진입니다. 과거의 경보 감시 환경을 설명하며 Kindo·Sift 화면이나 사이버 보안 대시보드가 아닙니다. 사진: UMD-Eskin, 퍼블릭 도메인. 여백을 추가하고 크기를 조정했습니다. 이미지 출처 · 라이선스·이미지 설명. 공식 제품 참고 자료.

실행을 줄이면 시스템이 관찰할 수 있는 것도 달라진다

모든 이벤트가 에이전트에 도달하면 모든 판정을 검사할 수 있습니다. 필터가 전달을 보류하기 시작하면 그 단순한 피드백 경로가 바뀝니다. 관심이 가장 적게 필요하다고 판단한 이벤트가 에이전트의 전체 검토를 더는 받지 않는 이벤트가 됩니다.

그래서 필터링은 같은 요청에 더 저렴한 모델을 쓰는 것과 다릅니다. 저렴한 모델은 여전히 각 이벤트의 결과를 만듭니다. 전달 보류는 일반 경로에서 실행 자체를 없앱니다. 측정 계획은 그 빠진 결과를 다뤄야 합니다.

저희가 보기에 실행을 생략하는 것은 책임자가 필요한 제품 동작입니다. 어떤 증거가 있어야 허용할지, 어떤 이벤트는 반드시 통과시킬지, 원천 데이터가 달라지면 어떻게 할지 누군가 정해야 합니다. 보이지 않는 최적화로 취급하면 이런 결정을 검토하기 어렵습니다.

필터를 업무 배분 창구로 생각해 보세요. 넘기지 않은 업무의 기록을 남기면서 적절한 일을 다음 담당자에게 보내는 역할입니다. 뒤의 전문 에이전트는 받지 못한 일을 조사할 수 없으므로 이 배분의 품질이 중요합니다.

파일럿에서는 필터의 성공 기준보다 에이전트의 업무부터 정하세요. 사고를 식별하나요, 맥락을 더 요청하나요, 티켓을 분류하거나 조사를 준비하나요? “실행이 필요하다”는 판정은 그 업무에 대응해야 합니다. 그렇지 않으면 일관되게 판단해도 팀의 운영 목적에 맞지 않는 모델이 될 수 있습니다.

Kindo의 발표의 섀도 모드·승인 흐름을 바탕으로 자체 제작한 설명 도표입니다. 실제 배포 구조가 아니라 단순화한 운영 흐름입니다.

섀도 모드는 전달 방식을 바꾸기 전에 비교 근거를 만든다

Kindo의 10월 28일 발표에 따르면 초기 관찰 기간에는 Sift가 점수를 매겨도 모든 이벤트가 대상 에이전트에 전달됩니다. 그 원천의 실제 결과를 바탕으로 무엇을 보류할지 미리 보여주며, 승인할 때는 이유를 서면으로 남깁니다. 활성화 후에도 무작위 표본을 계속 통과시켜 누락을 드러냅니다. 공개된 작동 방식.

이 순서는 운영팀이 실제로 바꾸기 전에 가상의 결과를 비교하게 해줍니다. 전달 방식을 바꾸기 전, 제안한 운영 설정이었다면 과거 어떤 실행이 사라졌을지 물을 수 있습니다. 원천 데이터와 에이전트의 책임자가 함께 검토할 만큼 구체적인 질문입니다.

미리보기에는 집계뿐 아니라 사례도 있어야 합니다. 일상 이벤트가 많으면 전체 비율을 지배하는 반면 작지만 중요한 범주에서는 성능이 나쁠 수 있습니다. 놓쳤을 때 비용이 큰 이벤트와 제안한 경계 근처의 이벤트를 승인자가 살펴보도록 하세요.

관찰 기간은 필요한 조건을 포괄해야 합니다. 바쁜 평일은 주말·출시일·특이 사고와 다를 수 있습니다. 달력상 기간은 결정에 중요한 조건을 포함할 때만 유용합니다. 조용한 날이 일정 수 지났다고 어디서나 준비가 됐다고 볼 수는 없습니다.

승인에는 예정된 운영 조건을 적어야 합니다. 단순한 ‘예’보다 ‘이 원천과 에이전트에 대해 이 제외 조건·검토 주기로 승인’이라는 기록이 유용합니다. 원천 스키마, 에이전트 프롬프트, 운영 우선순위가 바뀔 때 다시 검토할 근거가 됩니다.

세 가지 예시 대기열은 서로 다른 주의가 필요하다

반복되는 인프라 경보는 범위를 좁힌 출발점이 될 수 있다

정기 유지보수 중 알려진 알림이 반복되는 SRE 대기열을 생각해 보세요. 팀은 원천을 이해하고 긴급 예외 경로도 문서화했습니다. 에이전트가 같은 무조치 결론에 이르는 데 반복해서 시간을 쓰는지 파일럿으로 살필 수 있습니다.

기존 중복 처리와 새 판단을 구분하는 데서 시작하세요. 단순 상관 규칙으로 동일 이벤트를 이미 합치고 있다면 그것을 기준선에 포함합니다. 모델 평가는 그 뒤에 남은 변형 중 에이전트 전체 실행이 비싸거나 불필요한 부분을 살펴보는 데 쓰세요.

섀도 관찰 중에는 생략 제안과 실제 에이전트 행동을 비교하세요. 겉으로 비슷한 이벤트도 심각도, 영향받는 서비스, 상황 변화 때문에 다를 수 있습니다. 필터가 업무에서 이미 중요하게 여기는 차이를 지키는지가 유용한 질문입니다.

성공 기준의 예로 정한 검토 비율을 충족하고 평가 중 보호 범주의 이벤트를 놓치지 않을 것을 요구할 수 있습니다. 팀이 고르는 조건이며 보편적인 Sift 보장은 아닙니다. 이 시험은 즉시 전사 도입하기보다 원천 하나에 대한 명확한 결정을 남겨야 합니다.

피싱 신고 대기열은 놓쳤을 때의 비용이 더 뚜렷하다

직원들이 의심스러운 메시지를 신고하는 보안팀을 예로 들어보겠습니다. 추가 조치가 필요 없는 신고가 많아도, 드물게 등장하는 조치 대상 메시지의 중요도는 매우 클 수 있습니다. 필터의 경제성은 이 비대칭에 달려 있습니다.

이 원천에서는 평범한 서신처럼 보이지만 팀이 주목하는 징후를 포함한 사례를 살펴보세요. 뒤쪽 보안 도구와 사고 처리 과정은 유지해야 합니다. AI 에이전트 앞의 필터는 그 전달 판단을 평가해야 하며, 탐지 체계 전체로 취급해서는 안 됩니다.

평가에는 조사 누락의 결과를 이해하는 분석가가 참여해야 합니다. 재무 담당자는 실행 비용을 수치화할 수 있지만 허용할 사고 누락 범위를 혼자 정할 수는 없습니다. 임계값은 적절한 전문성을 갖춘 사람들이 승인할 공동 운영 선택입니다.

에이전트 자체의 오류도 검토하세요. 에이전트가 어떤 일을 무조치로 끝낼지 예측하도록 학습하면 같은 사각지대가 재현될 수 있습니다. 분석가가 별도로 검토한 평가 세트를 두면 필터와 에이전트가 서로 동의하면서도 팀이 원하는 결과와는 둘 다 어긋나는 사례를 찾을 수 있습니다.

티켓 대기열에는 유용한 조치가 무엇인지 정의해야 한다

서비스 데스크 예시에서 평범해 보이는 티켓도 접수 확인이나 서비스 수준 측정 타이머, 분류 단계가 필요할 수 있습니다. 따라서 “조사가 필요 없다”와 “에이전트 실행이 필요 없다”는 다른 판정일 수 있습니다. 실행을 보류할 때 무엇을 생략해도 되는지 정확히 정하세요.

필요하다면 의무적인 절차는 모호한 판단 밖에서 수행하도록 유지하세요. 예를 들어 필수 접수 확인은 티켓 시스템이 맡고, 모델은 특정 조사 에이전트를 실행할지 판단하게 할 수 있습니다. 그러면 책임의 경계를 설명하기 쉬워집니다.

여러 팀·언어·요청 유형의 문의로 시험하세요. 한 부서의 일상 요청을 주로 학습한 필터는 다른 부서의 이관 패턴에 맞지 않을 수 있습니다. 양이 비슷하다고 두 대기열이 같다고 보기보다 원천별로 평가해야 합니다.

이 파일럿의 결과는 티켓 수 감소가 아니라 더 정돈된 조사 대기열일 수 있습니다. 사람에게 넘기는 과정과 다음으로 의미 있는 조치까지 걸리는 시간을 측정하세요. 그래야 평가가 모델 호출 수에만 매이지 않고 서비스 품질과 연결됩니다.

네 가지 비용 관리 방식은 서로 다른 질문에 답한다

다음 표는 팀이 평가할 설계 선택을 설명합니다. 특정 업체가 모든 범주에서 낫다는 주장은 아닙니다. 작동 지점이 다르므로 여러 통제를 같은 시스템에 함께 둘 수 있습니다.

결정 단위로 비교하면 중복 계산을 막기 쉽습니다. 상관 규칙이 반복 이벤트를 이미 제거했다면 필터도 같은 후속 실행을 줄였다고 계산해서는 안 됩니다. 기존 통제 이후의 기준선을 정하고 추가 효과를 계산하세요.

필터 자체의 운영 비용도 포함하세요. 호스팅, 감시, 표본 실행, 사람의 검토가 모두 파일럿 계산에 들어갑니다. 특정 제공자 엔드포인트의 요금 감소는 유용하지만 전체 업무 비용의 한 부분입니다.

품질은 비용과 함께 논의해야 합니다. 호출을 많이 줄여도 유용한 업무를 숨기는 임계값이라면 서비스 자체를 바꾼 것입니다. 하나의 일반적인 정확도 비율이 아니라 실제 대기열에서 어떤 일이 일어나는지 설명할 수 있어야 합니다.

표본에서 발견한 누락으로 더 나은 질문을 한다

11월 2일 확인한 Kindo의 FAQ에는 전달 보류 대상 중 기본 3%를 통과시키는 표본 설정이 나옵니다. 범위는 1%에서 5%이며, 초기 판정 라벨의 기본 하한은 400개입니다. 분포 변화나 실행 유발 건수 상한 초과가 발생하면 섀도 동작으로 돌아간다고 설명합니다. 공개된 운영 기본값이지 모든 작업에 충분한 근거를 보장하는 수치는 아닙니다.

가상 계산으로 표본 범위의 중요성을 볼 수 있습니다. 이벤트 10,000건을 보류하고 3%를 표본으로 통과시키면 약 300건입니다. 중요한 사례가 드물더라도 놓치면 문제가 되는 범주를 이 표본이 대표하는지 계속 살펴야 합니다. 표본에 관한 질문을 설명하는 계산이며 Sift의 실제 오류율 추정은 아닙니다.

자체 평가에서는 최소 두 가지 분모를 구분해 보고하세요. 하나는 전체 조치 대상 이벤트 중 필터가 놓치는 정도이고, 다른 하나는 보류한 이벤트 중 나중에 조치 대상으로 판정된 비율입니다. 중요한 업무를 얼마나 포괄하는지와 생략한 집합에 조치 대상이 얼마나 섞였는지라는 서로 다른 운영 질문에 답합니다.

필요에 따라 원천 유형, 심각도, 팀, 변경된 입력 형식별로 나눠 살펴보세요. 종합 수치는 좋아져도 작은 범주의 품질은 나빠질 수 있습니다. 분류 기준은 그리기 쉬운 차트가 아니라 운영의 위험과 업무량을 반영해야 합니다.

마지막으로 에이전트의 판정과 독립적으로 검토한 결과를 구분하세요. 에이전트와의 일치도는 Sift가 그 에이전트를 얼마나 잘 예측하는지 측정합니다. 그것만으로 에이전트의 판단이 옳았다고 입증되지는 않습니다. 의미를 명확하게 유지하면 두 측정치 모두 유용합니다.

운영자가 비교할 대상을 보여 주는 자체 제작 판단 검토 도표입니다. 측정한 절감·정확도 수치는 없습니다. 표본 추출과 승인은 Kindo 제품 페이지에 설명되어 있습니다.

현재 배포의 한계도 파일럿에 포함해야 한다

11월 2일 기준 Kindo는 Sift를 Kindo 에이전트용 자체 호스팅 서비스로 설명합니다. FAQ에는 단일 호스트 Docker Compose 배포, 클러스터링·장애조치 미지원, SSO·MFA 없는 로컬 계정이 명시돼 있습니다. 별도의 Sift 무료 체험이나 사용 등급은 없습니다. 현재 릴리스 FAQ.

이 조건은 파일럿을 어디에 적용할 수 있을지에 영향을 줍니다. 인증·가용성·사고 대응 담당자와 배포 경계를 검토하세요. 점수화 시연이 성공해도 서비스가 조직의 운영 요건에 맞는지는 별도로 판단해야 합니다.

1. 원천 하나와 에이전트, 결정 책임자를 정하세요. 에이전트가 하는 일과 실행을 건너뛰면 생략되는 일을 적습니다. 기존 탐지·티켓 처리 책임은 유지하세요.
2. Kindo와 현재 배포 요건을 검토하세요. 가능한 호스팅 구성과 팀이 맡을 운영 지원을 확인합니다.
3. 승인된 기준선을 정의하세요. 기존 규칙과 상관 처리, 모델 라우팅을 포함해 추가로 얻는 가치를 측정하게 합니다.
4. 섀도 모드에서 시작하세요. 대표성 있는 판정을 모으고, 전달을 바꾸기 전에 중요 범주의 보류 예상 결과를 살펴봅니다.
5. 오류를 독립적으로 검토하세요. 대상 에이전트와의 일치도만 믿지 말고 분석가가 검토한 예시와 반드시 보호할 사례를 포함합니다.
6. 구체적인 운영 설정과 이유를 승인하세요. 범위, 검토자, 표본 계획, 재검토가 필요한 조건을 기록합니다.
7. 섀도 모드 복귀 경로를 시험하세요. 운영자에게 무엇이 보이고 전체 이벤트가 어떻게 다시 에이전트에 전달되는지 확인합니다. 최종 평가에 비용·품질·가용성을 모두 포함하세요.

결과는 책임자와 범위가 명확한 운영 결정이어야 합니다. 불확실한 범주를 발견해 전체 분석 경로에 남겨두는 것도 유용한 파일럿 결과입니다. 첫 기회에 생략을 최대화하기보다 어디서 보류가 정당한지 배우는 것이 목적입니다.

줄인 호출이 어떤 업무도 숨기지 않았는지 설명할 수 있어야 한다

Sift는 에이전트 워크플로에 중요한 질문을 던집니다. 어떤 이벤트에 전체 실행이 필요하고 그 경계를 누가 책임지나요? 섀도 모드부터 시작하면 전달 방식을 바꾸기 전에 이 결정을 검토할 수 있습니다.

오래 쓸 수 있는 평가 기준은 운영팀이 줄인 실행과 관찰된 누락, 현재 임계값이 계속 적절한 이유를 제시할 수 있는지입니다. 그래야 활동이 없다는 사실이 책임지고 뒷받침할 수 있는 결정으로 바뀝니다.

출처

• PR Newswire를 통해 배포된 Kindo의 Deep Hat Sift 발표, 2026년 10월 28일, 09:00 ET.
• Kindo: Deep Hat Sift 제품 세부 정보 및 현재 출시 FAQ, 2026년 11월 2일 확인.

결정의 근거 자료를 보관한다

Telli.sh는 검토한 메모와 이용 권한이 있는 원자료를 함께 보관할 수 있는 선택지입니다. 노트 작업 공간 만들기.