Project The Nexus 최종 보고서 및 인사이트 정리


1. 서론
본 문서는 2026년 2월 8일부터 3월 12일까지 진행된 ‘Project The Nexus’의 구축 과정과 기술적 의사결정, 그리고 이를 통해 도출된 인사이트를 정리한 글이다.
기존에 진행했던 ‘Protostar’ 프로젝트는 Docker(도커) 기반으로 성공적인 서비스를 구현했다. 여러 현실적인 문제들로 쿠버네티스에서 바로 시작하지 못했던 해당 프로젝트는 실제 서비스로서 구현은 성공하였지만, 그럼에도 데몬 종속성으로 인한 단일 장애점(SPOF), 보안 취약성, 파편화된 스크립트 관리 등 고가용성 측면에서 명백한 한계가 있단 생각이 들었다.
이를 극복하고 처음부터 생각하고 있던 3년 차 수준의 엔터프라이즈급 인프라 역량을 증명하기 위해, Docker-free 환경과 Kubernetes(쿠버네티스, 이하 k8s) 기반의 GitOps(깃옵스) 서버 클러스터 구축을 목표로 본 프로젝트를 시작하였다.
2. 본론: 핵심 아키텍처 및 구현 과정
2.1. 인프라 아키텍처 및 환경 구성
온프레미스(On-premise) 서버 2대를 활용하여 멀티 노드 단일 클러스터(Multi-node Single Cluster) 구조를 채택했다. 이렇게 한 이유는 다음과 같다.
- 역할 분리: 안정성이 최우선인 마스터 노드는 Centre 서버에, 고성능 처리가 필요한 워커 노드는 A5 서버에 배치하여 물리적 자원의 효율성을 극대화했다. 기존에도 분명 이렇게 되어 있긴 했지만, 각 서버는 제어가 단일화는 아니었기에 역할만 분리하고 싶었다.
- 논리적 격리:
infra와service로 Namespace(네임스페이스)를 분리하고,env및tier라벨을 통해 리소스의 역할을 명확히 정의했다. 이렇게 함으로써 마스터 노드에서 적절하게 논리적 표현만으로 자원을 분리할 수 있었다. - 선언적 관리: Kustomize(커스터마이즈)를 도입하여
base와overlays구조로 Dev/Prod 환경의 YAML 스크립트를 중복 없이 관리할 수 있는 기반을 마련했다. Dev 서버에서의 테스트와 Production 서버의 적용을 용이하게 만들어냈다.

연결된 노드와 그 역할, Master노드의 경우 최초엔 아무것도 하질 못해, 이 역시 옵션을 수정했다
2.2. 네트워크 라우팅 및 로드밸런싱 고도화
k3s에 기본 탑재된 Traefik(트래픽) 대신, 차세대 공식 스펙인 Gateway API 기반의 NGF(NGINX Gateway Fabric)를 도입하여 L7 라우팅을 구현했다. 이렇게 한 것은 기본은 쉽지만 k3s 에 묶여 있고, 간단한 프로젝트가 아닌 실무적 차원에서의 관리를 목표로 하였기에 트래픽은 적절하지 않다고 판단하였다. 뿐만 아니라 공인 IP가 한개 뿐인 상황에서 여러 서비스 운용을 위해선, 관리 차원의 포트와 서비스 차원의 포트를 분리할 필요가 있었는데, 이를 구현하기 위해선 트래픽은 다소 부족한 스펙이었다고 판단되었다.
- MetalLB 도입 (2026-02-23): 트래픽 선택과 유사하게 온프레미스 환경에서 k3s 내장 ServiceLB(Klipper)가 두개의 물리적으로 구분된 노드들 사이에서 80/443 포트 충돌을 제어하지 못하는 구조적 한계를 발견했다. 이를 해결하기 위해 ServiceLB를 비활성화하고 MetalLB를 L2 모드로 도입하여, IPAddressPool을 통해 노드별로 명확한 트래픽 제어와 로드밸런싱을 구현했고, 이로써 각 장치(Centre, A5)는 독립적으로 80/443 포트를 점유할 수 있게 되었다.
- HTTPS 및 보안: cert-manager와 PROXY Protocol을 연동하여 클라이언트 IP를 보존하면서도 완벽한 HTTPS 통신을 구현했다. 또한, 컨테이너 보안 컨텍스트(
allowPrivilegeEscalation: false,runAsNonRoot)를 적용하여 기본 root 권한 실행을 차단했다.

MetalLB를 도입한 후의 네트워크 구성도
2.3. Stateful 서비스의 안정적 관리
PostgreSQL과 Redis 같은 상태 저장 서비스는 Deployment가 아닌 StatefulSet과 Headless Service(clusterIP: None) 조합으로 배포했다.
-
고정 식별자 부여: 중간 프록시 없이 Pod IP를 직접 반환하는 Headless Service를 통해 각 Pod에 고유한 DNS를 부여하고, 개별 PVC(PersistentVolumeClaim)를 매핑하여 데이터의 영속성을 보장했다.
-
백업 및 복구: ConfigMap을 활용해 초기화 스크립트를 파일로 마운트하고, 커스텀 포맷(
-F c) 기반의pg_dump및pg_restore파이프라인을 검증하여 실무 수준의 데이터 복구 전략을 수립해, 기존의 서비스 운용 시 있었던 데이터들을 유실 없이 마이그레이션이 가능했다. 향후에는 무중단으로 마이그레이션이 가능한 방법도 구비해두고자 생각했다.
2.4. GitOps 기반 CI/CD 및 관찰성(Observability) 확보
수동 배포의 파편화를 막기 위해 소스코드 변경부터 클러스터 반영까지 이어지는 자동화 파이프라인을 구축했다.
- CI/CD 파이프라인 (2026-03-11): Jenkins(젠킨스)의 Kaniko(카니코) 에이전트를 통해 이미지를 빌드 방법을 적용하여 빌드를 진행하고 GHCR에 푸시한 뒤, GitOps 전용 레포지토리의 태그를 업데이트하면 ArgoCD가 이를 감지하여 클러스터에 자동 동기화하는 무중단 배포 흐름을 완성했다.
- 운영 원칙 수립: “인프라 툴은 인프라 툴로 관리하지 않는다”는 원칙 하에 ArgoCD의 관리 범위를
service네임스페이스로 한정하여, 장애 발생 시 진단 도구 자체가 다운되는 리스크를 원천 차단하고, 오로지 서비스 영역에 대해서만 ArgoCD가 관리할 수 있도록 설정하였다. - 모니터링 스택: kube-prometheus-stack과 Loki(Monolithic 모드)를 도입하여 메트릭과 로그를 중앙 집중화하고 시스템 가시성을 확보했다. 또한 기존의 MinIO 등의 스토리지 역시 추가함으로써 모니터링 스펙이 S3에 의존하지 않도록 구현하였고, 반대로 호환성 역시 유지시켰다.

적용된 ArgoCD

적용된 모니터링 스택의 설정된 대시보드들
2.5. AI 워크로드를 위한 GPU 자원 통합
차세대 AI 서비스 연동을 위해 k3s 클러스터에 GPU 자원을 도입 테스트를 진행했다.
- GPU Operator 도입: 초기 수동 배포 시 발생한 라이브러리 경로 및 CDI 설정 충돌 문제를 분석한 후, 공식 권장 방식인 NVIDIA GPU Operator(Helm)를 도입했다. 이를 통해 RTX 4080 SUPER 자원을 k8s 스케줄러가 인식할 수 있는 리소스로 성공적으로 노출시키고, 이를 기반으로 LLM 추론 워크로드를 서비스에 연결시키는 것을 실행해보았다. 실질 서비스 차원에서 사용은 불가능한 수준이었기에, 테스트 정도만 진행했으며, 향후 AI 서비스의 온프레미스 도입을 테스트 해본 정도로 의의를 가졌다.
3. 결론 및 후기
Project The Nexus는 단순한 기술 스택의 전환을 넘어, “할 줄 안다”에서 “제대로 한다”로 도약하기 위한 검증의 시간이었다. 그리고 처음엔 이직을 위한 완성 단계로 생각했다. Docker Compose로 컨테이너를 띄우는 수준을 벗어나, 네트워크, 스토리지, 권한(RBAC), 그리고 배포 파이프라인까지 아우르는 진정한 의미의 오케스트레이션 역량을 내재화하는 것이다.
과정 속에서 마주한 시행착오들은 시스템 엔지니어링의 본질을 깨닫게 해주었다. MetalLB로의 교체 과정이나 GPU Operator 도입 시 겪었던 의존성 충돌 문제들은, 개별 컴포넌트 단독으로 볼 때는 완벽해 보여도 전체 시스템으로 통합될 때는 예상치 못한 비극을 초래할 수 있다는 사실을 가르쳐 주었다. 하지만 이러한 부족함을 투명하게 마주하고, 공식 문서와 아키텍처의 원리를 파고들어 근본적인 원인을 분석해 낸 시간은 자신감과 확신, 그리고 여전히 벽이 높고 두텁다는 사실을 이해할 수 있었다.
이제 불완전 연소되었던 Protostar는 엔터프라이즈급 인프라 위에서 온전하게 동작하는 서비스로 재탄생했다.
그리고 처음엔 이직을 위한, 성공적인 결과물을 만드는게 내 목적이었다.
하지만 삶은 참 희안하다. 암이 찾아왔고, 깃헙을 처음 개설하고 7년, 개발을 배운다고 뜬 눈으로 지샌 시간들이 나에게 쉼을 요구해왔다. 간도 망가졌다는 소식은 생각보다 여러 생각을 들게 했다.
하지만 반대로 생각해보니 좋은 기회일지도 모른다고 생각했다. 기회를 스스로 만들지 않고 회사에 붙어 있을 수 만은 없고, 휴식도, 건강도, 삶의 패턴도 바꾸고 변화를 도모해야할 때라는 생각이 결론이 되었다. 많은 일들은 있었지만. 그러니 걸어 가려고 한다. 새롭게, 서비스도 개발해보고, 노마드 코더로 살아보자. 방법이 뭐든 있겠지.
다행인건, 이젠 진짜 어디 가서 최소한 풀스택이라고 이야기 할 만큼은 되고, 버그 못찾고 AI 에게 쫓아가야만 하는 에겐남도 아니지 않겠는가? 산전 수전에 AI까지 갖춘 개발자이자, 경험가이다. 그리고 안되고 망하면, 망하더라도 해본게 있는데 굶어 죽진 않겠지.
앞으로는 서비스를 만들어낼 것이다. 그저 개발 도구 리뷰하고 AI쩔어욧! 하고 어그로를 끄는게 아닌, 진짜 제대로 개발한 걸로 서비스로 취급받고, 돈 만들어내는, 앞으로 할 일이 참 많다.
