왜 클라우드가 아니라 온프레미스였나

클라우드 매니지드 K8s(EKS, GKE 등)를 쓰면 인프라 설계 고민의 상당 부분이 사라진다. 반대로 말하면, 그만큼 "인프라를 직접 설계하고 책임지는 경험"도 사라진다는 뜻이다. 방산 SW 영역은 네트워크가 폐쇄망이거나 반(半)폐쇄망인 경우가 많고, 클라우드 종속적인 설계보다 온프레미스에서 스스로 클러스터를 구성·운영할 수 있는 역량이 더 의미 있다고 판단했다. 그래서 별도 서버 임대 없이, 가지고 있는 MacBook 2대와 VMware로 띄운 Ubuntu Server VM 3대만으로 실제 분산 환경을 구성하기로 했다.

인프라 아키텍처

[MacBook A] ── VMware Fusion
   ├── VM 1 (Ubuntu Server) : K3s Master
   ├── VM 2 (Ubuntu Server) : K3s Worker 1
   └── VM 3 (Ubuntu Server) : K3s Worker 2

[MacBook B] ── 보조 호스트 / 클라이언트·모니터링 역할

상시 가동을 위한 전원 관리 — 생각보다 까다로움던 부분

노트북으로 클러스터를 운영하려면 "떨개를 닫아도 안 죽는 서버"를 만들어야 했다. macOS의 기본 클램쉬 모드는 외장 디스플레이·전원·외부 입력장치가 모두 연결되어야만 동작하는데, 이건 럭 서버처럼 상시 무인 운영하려는 목적과는 맞지 않았다.

해결책은 Amphetamine의 Closed-Display Mode 옵션이었다:

이 설정으로 외장 모니터나 키보드 없이도 떨개를 닫은 상태에서 VM과 K3s 클러스터가 중단 없이 계속 동작하도록 만들었다. 다만 MacBook Air는 팬리스 구조라 떨개를 닫으면 주 방열 경로(키보드면)가 막힌다는 트레이드오프가 있어, 수직 거치대로 세워 측면 방열을 확보하고 전원 어댑터를 상시 연결하는 방식으로 보완했다.

애플리케이션 레이어 — C4I 표적추적 시뮬레이션

인프라 위에는 방산 C4I(지휘·통제·통신·정보) 체계의 핵심 기능 중 하나인 실시간 표적 추적을 단순화해 재현한 파이프라인을 올렸다.

구성 요소

  1. Spring Boot 마이크로서비스 — 표적 정보 수집, 추적 상태 관리, 분석 요청 처리를 도메인별로 분리한 서비스 구조. K3s 위에 각각 별도 Deployment로 배포.
  2. Kafka — 표적의 위치·상태 변화를 이벤트로 발행하고, 다운스트림 서비스(추적 로직, 분석 파이프라인)가 이를 구독하는 구조. 실제 C4I 환경에서 다수의 센서/플랫폼으로부터 들어오는 데이터 스트림을 모사.
  3. PostgreSQL + pgvector — 표적 패턴이나 위협 시그니짐를 임베딩으로 저장하고, 벡터 유사도 검색을 통해 과거 패턴과의 유사도를 기반으로 한 AI 위협 분석을 구현.