위협 인텔리전스 데이터 플랫폼 — 수집부터 서빙까지

문제

대학원에서는 모델까지만 만들면 끝이었다. 데이터는 누가 준비해뒀고, 결과는 논문에 쓰면 됐다.

시큐레터에서 마주친 건 그 앞뒤가 전부 비어 있는 상황이었다. 위협 정보를 어디서 긁어와서, 어떻게 정제하고, 어디에 쌓고, 어떻게 찾고, 무엇으로 내보내고, 화면에 어떻게 그릴지가 전부 정해져 있지 않았다. 3인 팀이라 나눠 맡을 사람도 없었다.

한 일

수집 · 적재 — TI 서비스용 크롤링 서비스를 구현하고 운영했다(BeautifulSoup · Lambda · ECR). AI 도입을 위한 Data Lake를 S3 + OpenSearch로 세웠고, 클라우드 모니터링용 Fluent-bit 로그 저장소를 붙였다.

ETL · 대시보드 (2023.08 – 2024.07) — 크롤러가 쌓아둔 raw data를 OpenSearch에서 조회해 시각화에 필요한 형태로 추출·변환했다. 핵심은 메일·URL·파일 사이의 연관관계를 조회 가능한 구조로 만드는 것이었다 — 위협은 단일 객체가 아니라 관계로 드러난다. 모니터링 화면은 Svelte로 만들었다.

모델과 서빙 (2023.01 – 2023.07 · 기여도 70%) — 악성 메일 분류 모델을 BERT-CNN 기반으로 구현했다. 메일 헤더에서 특징을 뽑아 악성 여부를 판별한다. 모델보다 서빙 쪽이 어려웠다 — FastAPI를 AWS Lambda·ECS·ECR과 엮는 구간에서 대부분의 시간을 썼다.

플랫폼 연계 (2023.08 – 2024.03 · 기여도 60%) — FastAPI ↔ Lambda를 VPC로 연결하고 API Gateway를 구성했다. TI 플랫폼과 Lambda·ECS·ECR·OpenSearch 사이의 연계를 정리했다.

사내 도구 (2022.08 – 2022.12) — 학습 데이터 수집 크롤러(기여도 50%)와 사내 데이터 확인 플랫폼 ConTI(기여도 80%)를 만들었다. Svelte/Tailwind + Lambda/OpenSearch/FastAPI, Bitbucket → ECR 배포.

결과

수집부터 화면까지 전 구간을 소규모 팀으로 굴려 본 경험이 남았다. 지금 시스템 하나를 혼자 설계·배포·운영할 수 있는 건 이 구간을 지나왔기 때문이다.

당시 운영 지표는 남아 있지 않다. 일일 수집량·Data Lake 규모·모델 성능 수치를 복원할 수 없어, 지어내는 대신 수치 없이 서술한다. 다른 프로젝트에 붙은 숫자들은 전부 재현 가능한 측정값이다.