토요일 멘토링을 통해 실제 보안 관제 시스템이 어떤 구조로 동작하는지에 대해 들을 수 있었다.
이전까지는 단순히 “이상 탐지 → 알림” 정도로만 생각했는데, 실제 구조는 생각보다 훨씬 복잡했고 대규모 데이터를 처리하기 위한 다양한 기술들이 사용되고 있었다.
- 보안 관제 시스템의 기본 흐름
보안 관제 시스템은 기본적으로 아래 흐름으로 동작한다.
이벤트 발생
→ 데이터 수집
→ 정규화(Normalization)
→ Enrichment
→ Kafka Queue 저장
→ 탐지 엔진 분석
→ Alarm 발생
→ DB / ElasticSearch 저장처음에는 단순히 로그를 저장만 하는 줄 알았는데, 실제로는 로그를 “분석 가능한 형태”로 바꾸는 과정이 핵심이었다.
- 왜 로그를 정규화(Normalization) 해야 할까?
현실에서는 장비마다 로그 포맷이 모두 다르다.
예를 들어:
방화벽 로그
서버 로그
스위치 로그
인증 로그
NAC 장비 로그
등은 모두 구조가 다르다.
그래서 관제 시스템에서는 우선 로그를 우리가 분석 가능한 공통 포맷으로 변환하는 과정이 필요하다.
이 과정에서 사용되는 것이 StreamSets 같은 데이터 파이프라인 도구였다.
특히 StreamSets를 사용하면:
다양한 포맷 처리
데이터 변환
이벤트 가공
Enrichment과정을 비교적 수월하게 구성할 수 있다고 한다.
- Enrichment란 무엇인가?
이번에 가장 흥미로웠던 개념 중 하나였다.
단순 로그만 보면:
192.168.x.x 에서 이벤트 발생
정도만 보인다.
하지만 실제 관제에서는:
- 어떤 장비인지
- 어떤 부서 소속인지
- 중요 자산인지
- 서버인지 PC인지
- 위험 등급이 어떤지
같은 정보가 함께 있어야 분석이 쉬워진다.
그래서 장비 Address(IP/MAC)를 기반으로 자산 정보를 추가 결합하는 과정을 거친다.
이 과정을 Enrichment라고 한다.
단순 로그
= 의미 있는 보안 이벤트
로 바꾸는 단계라고 이해했다.
- Redis가 필요한 이유
Enrichment 과정에서는 DB 조회가 굉장히 많이 발생한다.
문제는 보안 이벤트가 초당 엄청난 양으로 들어온다는 점이다.
만약 이벤트마다 직접 DB를 조회하면 DB가 버티기 어렵다.
그래서 Redis 같은 분산 캐시를 사용한다.
이벤트
→ Redis에서 빠르게 조회
→ 필요한 자산 정보 결합
구조로 동작한다.
이걸 보면서 Redis가 단순 “빠른 저장소” 가 아니라, 대규모 실시간 시스템에서 DB 부하를 줄이기 위한 핵심 기술이라는 걸 조금 이해하게 되었다.
- Kafka는 왜 사용하는가?
정규화 + Enrichment를 거친 이벤트는 Kafka Queue로 전달된다.
여기서 중요한 점은 이미 “분석 가능한 상태”라는 것이다.
Kafka를 사용하는 이유는:
초당 대량 이벤트 처리
비동기 처리
서비스 간 결합도 감소
대규모 확장성
때문이라고 한다.
또한 이벤트를:
짧게는 3일
길게는 1주일
정도 Kafka에 저장하면서 분석에 활용한다고 한다.
실제로 MSA 환경에서는 Kafka가 서비스 간 통신 문제를 해결하는 핵심 역할도 수행한다고 들었다.
- 이벤트 탐지 엔진들
보안 관제 시스템은 단순히 로그를 저장하지 않고 다양한 엔진을 통해 분석한다.
Simple 엔진
가장 기본적인 분석 엔진.
특정 컬럼 값이나 조건을 기반으로 이벤트를 탐지한다.
Threshold 엔진
갑작스럽게 로그가 폭증하는 상황을 탐지한다.
예:
초당 로그인 시도 급증
트래픽 급증
장애 이벤트 급증
Unique 엔진
기존에 들어오지 않던 특이한 이벤트 탐지.
즉 “평소와 다른 행동”을 찾는 역할이다.
Correlation 엔진
개인적으로 가장 흥미로웠다.
단일 이벤트가 아니라:
이벤트 A
→ 이벤트 B
→ 이벤트 C
처럼 순차적으로 연결된 이벤트 흐름을 기반으로 탐지한다.
예를 들어:
비정상 로그인
→ 권한 상승
→ 내부 서버 접근
같은 흐름을 연관 분석하는 것이다.
Anomaly 엔진
기존 규칙 기반 엔진으로 찾지 못한 비정상 로그를 탐지한다.
여기서 AI / 머신러닝 기반 이상 탐지와 연결될 수 있다는 점이 굉장히 흥미로웠다.
- MSA 구조도 결국 핵심이었다
이번 멘토링에서 느낀 건:
“보안 관제도 결국 대규모 백엔드 시스템이다”
라는 점이었다.
기본적으로 프론트 / 백엔드 모두 MSA 구조로 동작하며:
Eureka
Zuul Gateway
Zipkin
Hystrix
Ribbon
Feign같은 기술들을 사용한다고 한다.
- Eureka / Zuul / Zipkin / Hystrix 역할 정리
Eureka
서비스 레지스트리.
어떤 마이크로서비스가 살아있는지 관리한다.
Zuul Gateway
외부 요청이 어떤 서비스로 이동할지 결정하는 API Gateway 역할.
Zipkin
MSA 환경에서는 서비스 호출 경로가 매우 복잡해진다.
Zipkin은:
어떤 요청이
어떤 서비스를 거쳐
어디서 장애가 발생했는지
를 추적할 수 있게 도와준다.
Hystrix
장애 전파 방지(Circuit Breaker).
특정 서비스가 죽더라도 전체 시스템이 무너지는 것을 방지한다.
- MSA의 장점과 단점
장점
독립 개발 가능
독립 배포 가능
독립 확장 가능
기능별 책임 분리단점
서비스 간 통신 복잡성 증가
데이터 일관성 유지 어려움
운영 난이도 증가그래서 Kafka 같은 메시지 큐 기술이 중요하다는 점도 같이 이해할 수 있었다.
- MSA가 커질수록 생기는 문제
마이크로서비스 구조는 기능별로 서비스를 분리할 수 있다는 장점이 있지만, 서비스가 많아질수록 새로운 문제가 생긴다.
예를 들어 각 서비스마다:
통신 설정
보안 처리
Retry 로직
로깅
Metrics 수집
Tracing같은 코드가 계속 반복된다.
즉 원래는 비즈니스 로직만 구현하면 되는데, 서비스 간 통신을 위한 부가 기능들이 점점 많아지는 것이다.
결국 MSA 규모가 커질수록 운영 복잡도가 급격히 증가하게 된다.
- Service Mesh란?
이 문제를 해결하기 위해 등장한 개념이 Service Mesh이다.
Service Mesh는:
마이크로서비스 간 통신을 인프라 레벨에서 관리하는 아키텍처 개념
이라고 볼 수 있다.
즉 서비스 내부 코드에서 직접 처리하던:
통신 제어
보안
로드 밸런싱
트래픽 관리
모니터링
Retry등을 서비스 외부에서 공통으로 처리하는 구조다.
- Istio는 Service Mesh의 대표 구현체
이번에 처음 알게 된 부분인데:
Istio = Service Mesh 구현체
라고 이해하면 된다.
Kubernetes 환경에서 가장 대표적으로 사용되는 Service Mesh 기술 중 하나라고 한다.
Istio를 사용하면 마이크로서비스 간 통신을 훨씬 체계적으로 관리할 수 있다.
AWS EKS 기반 Kubernetes 환경 구성 실습
이번에는 단순 로컬 개발 환경이 아니라 AWS EKS(Elastic Kubernetes Service)를 기반으로 실제 Kubernetes 운영 환경을 구성하는 실습도 진행했다.
전체 흐름은 대략 아래와 같았다.
AWS CLI 설정
→ EKS Cluster 생성
→ NodeGroup 구성
→ Rancher 설치
→ EBS / EFS 스토리지 연결
→ Docker Image를 ECR에 Push
→ Kubernetes 환경에서 서비스 운영
- EKS Cluster 구성
우선 AWS CLI, kubectl, eksctl 등을 설치한 뒤 EKS Cluster를 생성했다.
eksctl create cluster --name demo-cluster --region region-name이 과정을 통해 AWS 상에서 Kubernetes Control Plane 환경이 구성된다.
- Node Group 구성
Cluster만으로는 실제 컨테이너가 실행되지 않기 때문에 Worker Node(NodeGroup)도 함께 구성했다.
여기서 IAM Role과 각종 정책(EKSWorkerNodePolicy 등)을 연결하면서:
Kubernetes Node 권한
ECR 접근 권한
네트워크 권한
등을 설정하게 되었다.
- Rancher 설치
추가로 Rancher도 설치해보았다.
Rancher는 Kubernetes 환경을 GUI 기반으로 관리할 수 있게 해주는 플랫폼이다.
Kubernetes 운영을 훨씬 직관적으로 관리 가능
특히 Namespace, Pod, Deployment 상태를 한눈에 볼 수 있다는 점이 인상적이었다.
- EBS / EFS CSI Driver 구성
이번 실습에서는 Kubernetes 환경에서 스토리지도 연결했다.
EBS
단일 노드 기반 저장소
ReadWriteOnce 방식
EFS
여러 Pod에서 공유 가능한 네트워크 파일 시스템(NFS)
실제로 CSI Driver를 설치하면서 Kubernetes와 AWS 스토리지가 어떻게 연결되는지 조금 이해할 수 있었다.
- Docker Image → ECR Push
로컬에서 만든 Docker 이미지를 AWS ECR(Elastic Container Registry)에 업로드하는 과정도 진행했다.
Docker Build
→ ECR Login
→ Docker Tag
→ Docker Push
이후 Kubernetes Deployment에서 해당 이미지를 가져와 실행할 수 있었다.
첫 멘토링 후 느낀 점
이번 내용을 정리하면서 느낀 점은,
보안 관제 시스템은 단순히 로그를 보는 수준이 아니라 대규모 데이터를 실시간으로 처리하는 분산 시스템이라는 것이었다.
특히 Kafka, Redis, ElasticSearch 같은 데이터 처리 기술과 Kubernetes, EKS, Istio 같은 클라우드/인프라 기술들이 서로 유기적으로 연결되어 동작한다는 점이 인상 깊었다.
또한 실제 MSA 환경에서는 단순한 서비스 개발보다도:
- 서비스 간 통신
- 장애 대응
- 트래픽 제어
- 스토리지 관리
- 확장성
- 운영 자동화같은 요소들이 훨씬 중요하다는 것도 느낄 수 있었다.
이번 실습과 멘토링을 통해 단순히 기능 구현만이 아니라,
“실제 현업 시스템은 어떤 구조로 운영되는가” 를 조금 더 큰 관점에서 이해할 수 있었던 시간이었다.
