이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
수천 대 엔드포인트에서 보안 이벤트를 수집하는 시스템 설계는 보안 아키텍처 스터디에서 케이스 스터디로 다뤄봤습니다. 이 규모에서는 이벤트가 초당 수만 건씩 발생할 수 있어, 중앙 저장소에 바로 쓰는 구조는 병목이 생기기 쉽습니다. 에이전트에서 수집한 이벤트를 먼저 메시지 큐에 넣고, 소비자가 배치로 처리해 저장하는 구조를 설계했습니다.
이벤트 필터링도 수집 단에서 적용하는 것이 유리한데, 모든 원시 로그를 중앙으로 올리면 저장 비용과 처리 부하가 급격히 늘어납니다. 에이전트 수준에서 심각도나 이벤트 유형으로 사전 필터링한 뒤 전송하는 방식을 제안했습니다. 실시간 탐지를 위한 스트리밍 파이프라인과 장기 보관을 위한 배치 파이프라인을 분리하는 구조가 유지보수에도 유리합니다. 보안 이벤트 시스템은 수집·처리·저장을 분리해 독립적으로 확장할 수 있는 것이 결임을 배웠습니다.
보안 이벤트 수집 시스템을 설계하면서 성능 지표를 먼저 정의해야 한다는 것을 배웠습니다. 케이스 스터디 수준이었지만 처리량과 지연 시간을 구체적으로 상정하지 않으면 설계가 막연해지는 경험을 했습니다.
시간당 처리해야 하는 이벤트 수를 기준으로 메시지 큐의 파티션 수와 소비자 수를 설계했습니다. 수집 단에서 중요도가 낮은 이벤트를 사전 필터링하면 네트워크 전송량과 저장 비용을 상당히 줄일 수 있다는 것이 계산에서 나왔습니다.
실제 환경에서 검증한 수치는 아니지만, 설계를 수치 기준으로 시작하니 어느 계층을 먼저 확장해야 하는지 판단 근거가 생겼습니다. 보안 시스템 설계는 '얼마나 많은 이벤트를 어느 지연 시간 안에 처리할 것인가'를 먼저 정의하는 것이 나머지 설계 결정의 출발점이 된다는 생각이 남아 있습니다.
보안 이벤트 처리 시스템을 설계하다가 오탐 처리 전략을 어떻게 잡아야 하는지 판단이 서지 않는 자리가 있었습니다. 오탐이 많으면 운영 팀이 알람을 무시하게 되고, 오탐을 줄이면 실제 위협을 놓칠 수 있는 트레이드오프였습니다.
보안 전공 교수님께 이 질문을 드렸더니 오탐 허용 수준은 운영 팀의 대응 여력과 탐지 규칙의 정밀도 사이에서 결정해야 한다는 조언을 받았습니다. 경보 피로가 실질적인 위험이라는 것을 그때 처음 배웠습니다.
이 조언을 바탕으로 케이스 스터디에서 심각도별로 알람 채널을 분리하는 설계를 추가했습니다. 높은 심각도는 즉각 대응 채널로, 낮은 심각도는 일별 리포트로 분류하는 방식이었습니다. 시스템 설계에서 기술 성능만큼 운영자의 실제 대응 방식을 고려하는 것이 중요하다는 생각이 이 대화에서 자리 잡혔습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.