로그도 출근 확인이 필요했다

자료 기준: Google Cloud 공식 문서, 최종 갱신 2026년 7월 26일

나는 한동안 보안 대시보드에 경고가 없으면 별일이 없다고 생각했다. 문제는 로그 수집기가 조용히 멈춰도 대시보드는 아주 침착할 수 있다는 점이다. 아무도 출근하지 않은 사무실에서 회의가 평화롭게 진행됐다고 보고한 셈이었다.

Google SecOps의 최근 문서는 이 빈틈을 이해하기 좋은 사례다. 핵심은 AI 탐지 모델보다 앞에 있는 로그 수집 과정도 상태를 남겨야 한다는 것이다.

1. 데이터가 오는 길을 나눠 본다

보안 로그는 대략 이런 길을 지난다.

원본 시스템 → Collector 또는 Feed → 수집 파이프라인 → SIEM 저장 → 탐지 규칙

끝에서 경고가 없을 때 원인은 여러 가지다.

• 정말 이상 행동이 없었다.
• 원본이 로그를 만들지 못했다.
• Collector가 멈췄다.
• 전송이 늦거나 실패했다.
• SIEM에는 들어왔지만 탐지 규칙이 놓쳤다.

따라서 ‘검색 결과 0건’만으로 정상 판정을 내리면 앞단 장애와 평화를 구분할 수 없다.

2. Google SecOps에서 무엇을 볼 수 있나

Google의 공개 미리보기 기능은 SecOps의 수집과 Feed 활동 로그를 Cloud Logging으로 보낸다. 공식 문서에 따르면 push와 pull 방식 모두를 다루며, 누락·지연·실패한 로그를 조사할 수 있다.

feed_id나 collector_id로 범위를 좁힐 수 있고, Feed 화면의 Debug with logs에서 미리 필터된 Logs Explorer를 열 수 있다. Gemini Cloud Assist를 같은 텔레메트리 분석에 연결할 수도 있다.

여기서 AI는 조수다. 수집 설정과 네트워크 권한이 잘못됐는데 멋진 설명문만 받으면 장애 보고서의 문장력만 좋아진다. 파이프는 여전히 막혀 있다.

출처: Google Cloud의 SecOps 수집 활동 분석 문서, Google SecOps 출시 정보

3. 내가 기본으로 남길 지표

이 원칙은 보안 제품이 아닌 일반 애플리케이션 로그에도 그대로 적용된다. 나는 다음 다섯 가지를 수집 데이터와 별도로 남긴다.

1. Heartbeat: 수집기가 살아 있다는 주기 신호
2. 마지막 정상 수신 시각: 언제부터 끊겼는지 확인
3. 전송 지연: 생성 시각과 도착 시각의 차이
4. 실패·재시도 수: 조용한 유실을 발견
5. 원본 대비 수집량: 평소 기준선에서 급감했는지 확인

알림도 두 층으로 나눈다. 보안 사건 알림과 수집 파이프라인 장애 알림이다. 화재경보기와 화재경보기 배터리 경고가 따로 필요한 것과 같다. 배터리 경고를 무시하면 다음 알림은 이웃이 문을 두드리는 방식으로 온다.

4. 공개 미리보기라는 경계

이 기능은 Pre-GA, 즉 공개 미리보기 단계다. 정식 출시 기능처럼 변경 가능성이 낮다고 가정하지 않는다. 운영에 적용한다면 다음을 남긴다.

• 지원 범위와 알려진 제한
• 로그 보관 기간과 비용
• Feed·Collector 식별자 관리 방식
• 미리보기 기능이 바뀔 때의 대체 조회 절차
• Gemini가 제안한 내용과 사람이 실제로 적용한 조치의 구분

새 기능을 켰다는 사실보다, 그 기능이 사라져도 장애를 찾을 수 있는지가 더 중요하다.

내가 얻은 결론

로그가 없다는 것도 관측해야 할 상태다. 모델이 아무리 똑똑해도 입력이 끊기면 답을 만들 재료가 없다. 나는 앞으로 탐지 정확도를 묻기 전에 “오늘 로그는 전부 출근했나?”부터 확인하려 한다. 출석부가 보안 전략이 될 줄은 몰랐지만, 운영은 종종 가장 평범한 질문에서 살아남았다.