금융권 폐쇄망 환경에서 Kafka·Logstash·OpenSearch 기반 로그 수집·분석 파이프라인, 정합성 검증/백필 구조, ML/LLM 기반 운영 지원 기능 구축에 참여한 데이터 엔지니어링 프로젝트
| 항목 | 내용 |
|---|---|
| 문제 상황 | 한국증권금융의 대내외 10개 시스템 로그가 통합 관제되지 않고, 단순 임계치 기반 수동 모니터링에 의존하고 있었습니다. |
| 핵심 제약 | 금융권 폐쇄망 환경으로 외부 SaaS·외부 LLM API 사용이 제한되었고, 개발계·이관계·운영계가 분리되어 있어 설치·배포·검증 절차를 내부망 기준으로 설계해야 했습니다. |
| 원인 가설 | 로그 포맷과 전문 헤더가 시스템별로 달라 파싱 기준이 통일되지 않았고, Kafka Topic별 처리량 차이와 실시간 데이터·통계 데이터 생성 시점 차이로 지연과 정합성 문제가 발생할 수 있다고 판단했습니다. |
| 검토한 선택지 | 직접 수집 방식, Kafka 기반 버퍼링, OpenSearch 집계, Python Batch Scheduler 기반 Cross-Check, OpenSearch k-NN 기반 RAG 구성을 비교했습니다. |
| 최종 선택 | Kafka·Logstash·OpenSearch 기반 로그 파이프라인을 중심으로 구축했으며, 저는 Logstash 전처리, OpenSearch 적재·조회 구조, Python Batch Scheduler와 OpenSearch Python Client 기반 정합성 검증/백필, OpenSearch k-NN 기반 RAG API 연동 영역을 담당했습니다. |
| 선택 이유 | 폐쇄망에서도 운영 가능한 내부 구성만으로 수집·정제·저장·조회·보정·검색을 연결할 수 있고, 이미 OpenSearch를 사용하고 있어 k-NN 및 ML Detector를 추가 인프라 없이 활용할 수 있었기 때문입니다. |
| 검증 방법 | Kafka Consumer Lag, Topic별 처리량, Logstash 파싱 오류, OpenSearch 적재 문서 수, 마스터 데이터와 통계 데이터 Cross-Check, 대시보드 조회 성능을 기준으로 검증했습니다. |
| 결과 | Topic 단위 병목 분석과 파티션 확장/Consumer Group 처리 구조 개선으로 Consumer Lag 30% 감소, OpenSearch 인덱스·샤드 설정 개선으로 조회 속도 40% 향상, 일 32GB 로그 처리 기준 ILM 적용 지원, 통계 데이터 정합성 보정 구조와 운영 매뉴얼 검색형 RAG API 구축에 기여했습니다. |
| 판단 지점 | 검토한 선택지 | 최종 선택 | 선택 이유 |
|---|---|---|---|
| 로그 수집 구조 | 직접 수집 / Kafka 버퍼링 | Kafka KRaft 3 Nodes | 10개 시스템 로그를 직접 수집하면 유실과 처리 지연 위험이 커서 Kafka 기반 버퍼링 구조를 사용했고, 저는 Topic별 처리량·Consumer Lag 관측 및 병목 개선에 참여했습니다. |
| 로그 전처리 | 애플리케이션 코드 전처리 / Logstash 파이프라인 | Logstash | 전문 헤더 파싱, 필드 타입 변환, 데이터 정제 규칙을 파이프라인 단위로 관리하기 위해 선택했습니다. |
| 검색·저장 엔진 | Elasticsearch / OpenSearch | OpenSearch 2.18.0 | 금융권 라이선스 제약을 피하면서 k-NN, ML Detector, Dashboard를 한 시스템에서 활용할 수 있었고, 저는 OpenSearch 인덱스 매핑·샤드 설정 개선과 조회 성능 검증에 참여했습니다. |
| 정합성 검증 | 수동 확인 / 배치 검증 자동화 | Python Batch Scheduler | 폐쇄망에서 별도 오케스트레이션 도구 도입이 어려워, 경량 스케줄러와 OpenSearch Python Client로 Cross-Check와 백필을 구현했습니다. |
| RAG 구현 | 외부 LLM API / 별도 벡터 DB / OpenSearch k-NN | Kanana LLM + OpenSearch k-NN | 외부 API 호출이 불가능한 폐쇄망 환경에서 사내 LLM과 기존 OpenSearch를 활용하는 구성이 가장 현실적이었습니다. |
| API 역할 분리 | Node.js 단일 구성 / Python 단일 구성 / 역할 분리 | Node.js + Python Flask | 대시보드 API는 Node.js의 비동기 I/O로 처리하고, Prophet·OpenSearch Client 기반 ML 기능은 Python 생태계를 활용하도록 분리했습니다. |
| 항목 | 내용 |
|---|---|
| 프로젝트명 | 머신러닝 적용 수집 로그 모니터링 솔루션 도입 (CPM) |
| 고객사 | 한국증권금융 |
| 기간 | 2024.12.19 ~ 2025.08.31 (약 8개월) |
| 역할 | Data Engineer (로그 파이프라인 구현·검증 / OpenSearch 적재·조회 구조 개선 / 백엔드 API 개발) |
| 기여도 | 전체 시스템 中 약 30% |
| 환경 | 폐쇄망 (Closed Network), 개발계·이관계·운영계 3단계 구분 |
| 협업 도구 | GitLab (코드 관리), 한국증권금융 내부 NEP (이슈 관리·산출물 등록) |
한국증권금융의 대내외 10개 시스템에서 발생하는 로그 데이터를 통합 수집·관제하는 시스템이 부재하거나, 단순 임계치 기반의 수동 모니터링에 의존하고 있었습니다.
이를 개선하기 위해 프로젝트 차원에서 실시간 로그 파이프라인과 머신러닝(시계열 예측), LLM(RAG 챗봇)을 결합한 지능형 이상징후 탐지 및 운영 지원 시스템을 구축했으며, 저는 로그 전처리·적재, 정합성 검증/백필, OpenSearch 조회 성능 개선, 관련 API 구현 영역을 담당했습니다.
| 영역 | 기술 | 선택 이유 |
|---|---|---|
| 메시지 큐 | Apache Kafka 3.8.1 (KRaft) | 10개 이기종 시스템의 로그를 버퍼 없이 직접 수집 시 유실 위험 → 내구성 있는 큐 필요. ZooKeeper 의존성 제거를 위해 KRaft 모드 선택 |
| 데이터 처리 | Logstash 8.9.0 | OpenSearch와 동일 벤더(OpenSearch 포함 빌드)로 호환성 확보. Ruby 플러그인으로 복잡한 전문 헤더 파싱 구현 가능 |
| 저장 / 검색 | OpenSearch 2.18.0 | 금융권 라이선스 이슈 회피(Elasticsearch SSPL 대안). k-NN, ML Detector 기능이 오픈소스로 내장되어 있어 추가 솔루션 도입 불필요 |
| 시계열 예측 | Python Prophet | 거래량의 요일·시간대별 계절성 패턴이 뚜렷하여 ARIMA보다 Prophet의 분해 모델이 적합. 파라미터 해석이 직관적이어서 운영팀 설명 용이 |
| LLM / RAG | Kanana LLM + OpenSearch k-NN | 폐쇄망 환경으로 외부 LLM API 호출 불가 → 사내 구축형 Kanana 모델 사용. 이미 OpenSearch를 사용 중이므로 별도 벡터 DB 없이 k-NN으로 RAG 구현 |
| 백엔드 | Node.js 14 (Express.js), Python (Flask) | 대시보드 API는 Node.js(비동기 I/O 처리에 유리), ML 모델 서빙은 Python(Prophet·OpenSearch Client 생태계 활용)으로 역할 분리 |
| 모니터링 | Metricbeat, OpenSearch ML Detector | 서버 메트릭 수집은 Metricbeat(ELK 표준 에이전트), 거래 이상징후는 OpenSearch 내장 ML로 추가 인프라 없이 구현 |
| 협업 | GitLab, 한국증권금융 내부 NEP | 폐쇄망 내부 GitLab으로 코드 버전 관리, NEP(내부 이슈 트래커)로 작업 단위 등록·산출물 관리 |
코드 공개: 본 프로젝트는 금융기관 폐쇄망 환경에서 수행되었으며, 보안 정책상 소스코드 외부 반출이 불가합니다. 코드 관리는 내부 GitLab을 통해 이루어졌으며, 상세 구현 내용은 하단 기술 리포트를 통해 확인할 수 있습니다.