기존 시스템은 DB를 일정 주기로 폴링해 작업을 가져갔습니다. 워커를 늘려도 같은 DB에 더 많은 폴링 쿼리가 몰려 락 경합으로 수평 확장 효과가 거의 없었고, 완료 콜백 구조라 노드 재시작 시 콜백이 유실되면 작업이 RUNNING 상태로 고착됐습니다. Kafka는 처리량이 높지만 운영 오버헤드가 컸고, 위성 처리 작업은 단위가 명확해 ack/nack 기반의 확실한 전달 보장이 되는 메시지 큐 모델이 더 적합했습니다.

MSA로 9개 서비스를 분리하면서 네트워킹·시크릿·배포·관측성 각각에서 감당하기 어려운 문제가 함께 드러났습니다. kube-proxy(iptables)는 서비스 수가 늘수록 규칙 매칭이 느려졌고, control-plane은 단일 노드라 장애 시 API 서버 전체가 멈췄고, 시크릿은 서비스마다 개별 관리돼 로테이션 부담이 늘었고, Jenkins 명령형 배포는 실제 상태와 스크립트가 분리돼 드리프트 추적이 안 됐고, 통합 관측 스택 자체가 없어 장애 구간을 특정하기 어려웠습니다. 각 문제가 네트워킹·시크릿·배포·관측성이라는 서로 다른 영역에서 동시에 터졌기 때문에, 팀원과 영역을 나눠 각각 해결해야 했습니다.

위성영상을 받아 AI 추론까지 흘려보내는 플랫폼을 만들어야 했는데, 컨테이너 하나가 죽으면 작업이 그냥 사라지는 구조로는 운영이 불가능했습니다. 게다가 노드당 GPU 하나를 컨테이너 하나가 점유하는 방식이라 대부분의 시간 동안 GPU가 유휴 상태였습니다. 워크로드가 여러 노드에 걸쳐 자동 복구돼야 하는데 Docker Compose·스크립트 관리로는 노드가 늘수록 관리 포인트가 선형으로 늘었고, 여러 모델을 동시에 띄워야 하는 요건과 1파드=1GPU 구조도 맞지 않았습니다(당시 GPU는 NVIDIA MIG 미지원).

Debezium CDC의 replication slot이 반복 파손돼 전체 스냅샷을 재수행해야 했고, 외부망·폐쇄망 DB 동기화도 필요했지만 망연계 솔루션이 파일 기반 전송만 지원했습니다. CDC 방식은 DB 로그 기반이라 slot 파손 시 외부 인프라 의존도가 높아 안정성을 보장하기 어려웠고, API 폴링은 망 구조상 불가능했으며 DB 덤프 주기 전송은 실시간성이 너무 떨어졌습니다. 망연계용으로 유지한 CDC 구간에서도 상태 판정 우선순위 오류로 WAL 완전 유실 상황을 '비활성'으로 오판해 필요한 slot 재생성을 건너뛰는 버그가 있었습니다.

레거시 Tomcat 기반 프론트엔드를 외부에 HTTPS로 노출해야 했는데 서비스마다 보안 헤더 설정이 제각각이었고, 각 서비스가 개별적으로 외부에 노출되다 보니 라우팅·보안 처리도 분산돼 응답에 노출 금지 정보가 실리는지 확인할 방법도 없었습니다. Tomcat 단독으로는 와일드카드 인증서 갱신·보안 헤더 통합 관리가 번거로웠고, 단일 게이트웨이 없이 서비스가 각자 노출되다 보니 보안 정책을 한 곳에서 적용·검증할 수 없었습니다.

위성영상 타일 요청이 트래픽 대부분을 차지하는데, 매 요청마다 TCP 핸드셰이크가 반복되는 오버헤드가 있었습니다. Nginx Ingress의 기본 설정은 백엔드로의 커넥션을 요청마다 새로 맺어, 핸드셰이크 비용이 그대로 응답 지연에 더해졌습니다.

배포 파이프라인에 자동화된 테스트가 없어, 부하 상황에서만 드러나는 문제나 트랜잭션 경계 결함이 배포 이후에나 발견됐습니다. 부하테스트는 문제가 생길 때마다 추가되는 사후적 sh 스크립트뿐이었고, 유닛테스트도 없어 CI 단계에서 걸러낼 방법이 없었습니다.

어느 날 가시화 작업이 전부 실패 처리되기 시작했습니다. 로그에는 No space left on device가 찍혀 단순 디스크 부족처럼 보였지만, 마운트된 스토리지 용량을 확인하니 여유가 충분히 남아 있었습니다. 명령어로 본 용량과 실제 동작이 어긋나 있어, 컨테이너가 아니라 마운트된 스토리지 자체의 문제로 의심됐습니다. 팀원과 함께 스토리지 장비에 원격 접속해 NVMe 상태를 확인한 결과 실제 여유 용량이 0이었고, 업체 운영 코드를 검토한 결과 펌웨어 업그레이드 과정에서 NVMe→system pool 데이터 이동 로직이 누락된 것이 근본 원인이었습니다.

이어서 주도한 다종위성 수집·처리 플랫폼 신규 구축 프로젝트에서, 기존 프로젝트들은 각 서비스(카탈로깅, 작업 관리, 가시화 등)가 ORM으로 DB에 직접 접근하는 구조였습니다. DB 접근 로직과 자격증명이 모든 서비스에 흩어져 있어 스키마가 바뀌면 여러 서비스를 동시에 수정해야 했고, Python ORM과 Go가 같은 DB를 다룰 때 접근 패턴도 서로 어긋났습니다. 언어별로 각자의 ORM 계층을 개선하는 방법도 있었지만, 스키마가 바뀔 때마다 여러 서비스를 동시에 고쳐야 하는 근본 문제 자체는 해결되지 않는 미봉책이었습니다.

관리형 인프라가 없는 신규 구축 프로젝트로, 물리 서버 설치부터 시작해야 했습니다. 검증된 패턴을 그대로 가져올 수 없는 영역(물리 서버 구성, DB 스키마, 수집기 통합)이 많아 운영 시나리오에 맞게 새로 설계해야 했습니다.