CJ올리브네트웍스 · Infra Service Engineer

SELECTED WORK / 2026.10

구축 이후까지 고려하는 인프라 엔지니어.

석원준 · 오픈마루 주식회사 클라우드 네이티브팀 · 2022.09 — 현재

고객의 4개 분리망·36노드 플랫폼을 제안부터 보안 검증·운영 인계까지 기술 전담했습니다. 개인 환경에서는 Proxmox VE·Ceph 기반 5노드 HCI를 설계·구축·운영합니다. 10노드 Kubernetes로 서비스를 운영하며, 디스크 정비부터 스토리지 성능·호스트 자원 경합까지 직접 분석하고 개선합니다.

대표 사례 보기 GitHub 기술 블로그

운영 노드 · 4개 분리망국방부 OpenShift 구축

Proxmox·Ceph HCI 호스트개인 환경 · 가상화와 분산 스토리지

Kubernetes 노드 운영개인 환경 · 온프레미스 6 + OCI 4

운영 중 마주한 세 가지 문제

ENGINEERING NOTES

01 / HCI · 운영

스냅샷을 지울 때마다
VM까지 느려졌습니다.

Ceph 정리 작업과 VM·서비스의 정체를 연결했습니다. 공유 자원을 어디까지 조정할지 판단한 과정입니다.

원인과 조정 이유 보기 02 / Kubernetes · 구현

기존 Ingress를 유지하며
Gateway API로 옮겼습니다.

앱의 입력은 그대로 두고 라우팅을 전환하는 Go 컨트롤러를 만들어 홈랩에 적용했습니다.

설계와 전환 기록 보기 03 / Data · 운영

2,220페이지를 검색하기 전,
원본을 지키는 일부터.

OneNote 보존·Markdown 변환·RAG 색인·권한 제어를 하나의 운영 흐름으로 연결했습니다.

데이터 처리 흐름 보기

경험 요약 / ROLE & EVIDENCE

이 경험을, CJ의 인프라 운영에.

실제로 맡은 범위와 확인한 결과를 먼저 정리했습니다.
각 사례에서의 판단을 지원 직무에 연결합니다.

핵심 경험과 검증 결과, CJ올리브네트웍스 업무에서의 활용
경험	확인한 결과와 범위	CJ 업무에 연결할 역량	사례
개인 운영Proxmox · HCI	5호스트 VM과 Ceph를 같은 호스트에서 운영 OSD 24개 · raw 약 26TB · 2026.10.07	가상화·스토리지·서비스의 영향을 함께 판단하는 정비와 자원 관리	보기
회사 프로젝트분리망 플랫폼	36노드 4개 분리망 구축 보안 점검 전 항목 PASS	접근 경계와 보안 제약을 구성에 반영하는 설계·검증·운영 인계	보기
개인 운영성능 장애 분석	SLOW_OPS 0 Ceph 스냅샷 정리 시간대 관찰 2026.10.07–14 · 별도 OSD 하강 사건 제외	스토리지 작업과 VM·서비스의 정체를 연결하는 원인 분석과 튜닝	보기
회사 프로젝트서비스 전환	4개 이전 · 2개 오픈 개발·운영 배포와 인증 분리 부하 시험 평균 응답시간 20ms 미만	개발 자율성과 운영 변경 통제를 함께 갖춘 단계별 전환	보기
회사·개인 사례운영 자동화	정비 순서 + 반복 점검 개인: DB 사전 역할 전환 기록 확인 회사: 보고서 약 20분 → 1분 미만	의존성을 확인한 계획 정비와 반복 작업의 자동화	보기

회사 경력과 개인 운영을 구분해 표기했습니다. 결과의 조건·시점은 각 사례에서 확인할 수 있습니다.

01 / Professional work

고객 환경에서 만든 변화

요구사항을 이해하는 미팅부터 설계·구축·장애 분석·운영 인계까지. 환경의 제약을 확인하고, 검증할 수 있는 결과로 연결했습니다.

오픈마루 주식회사 · 클라우드 네이티브팀 엔지니어2022.09 — 현재

01 / PLATFORM · SECURITY

국방부 온나라2.0

2024.08 — 2025.08구축 완료

4개 분리망·36노드 플랫폼,
설계부터 장애 검증·운영 인계까지 전담했습니다.

보조 인원 1명과 함께 제안·설계·구축·보안·운영의 핵심 기술 작업을 전담했습니다. 4개 망의 접근 요구를 IP 서브네팅과 Ingress Sharding으로 연결하고, OS 보안부터 JBoss 컨테이너화·Jenkins 배포·백업까지 구성했습니다.

내 책임

제안 → 설계 → 구축 → 보안 조치 → 시험·고객 교육

운영 36노드 · 보안감사 전 항목 PASS · 계약 전환 기여

OpenShift
RHEL
Jenkins
Ingress Sharding
TOTP

설계와 검증 자세히 보기

망 경계를 플랫폼에 반영: master 3·infra 3·route 6·worker 24로 운영 클러스터를 구성했습니다. 콘솔이 허용된 망에서만 열리도록 Ingress Sharding을 적용하고, RHEL·SELinux·TOTP 요구를 함께 반영했습니다.
검증과 인계: JBoss 이미지 3종·36개 Pod, etcd·kubedump 백업과 Jenkins 배포 흐름을 구성했습니다. OpenShift CIS 약 60항목·Linux 약 36항목의 보안 점검을 모두 통과했습니다.
장애 검증: NIC 분리·Pod 삭제·노드 중지 시나리오에서 서비스 상태를 확인했습니다. XFF를 포함한 L4 분산 문제와 LACP 협상 문제도 분석·조치했습니다.
인계: 고객 대상 APM·OpenShift 교육과 운영 문서를 제공했습니다.

02 / MIGRATION · DELIVERY

서울디지털대학교

2025.03 — 현재진행 중

개발 자율성과 운영 통제를 함께 구현한
RKE2 전환과 통합 인증

고객 초기 미팅에서 전환 목표와 범위를 정렬하고, 개발자가 자유롭게 배포할 수 있는 환경과 운영자가 통제하는 환경을 분리했습니다. 개발·운영 RKE2, GitLab·Jenkins 배포, Keycloak·LiteLDAP 인증을 연결해 누가 어디까지 변경할 수 있는지 정했습니다.

부하 시험 평균 응답시간 20ms 미만 · 목표 200ms
6개 시스템 중 4개 이전·2개 오픈 (2026.10 기준)

개발자push → 빌드·개발 배포Jenkins · S2I 자동화

소스·이미지
hash 확인 →

운영자운영 Jenkins에서 반영별도 클러스터 · 권한 분리

RKE2
GitLab + Jenkins
Harbor
Keycloak
OIDC

배포와 권한 분리 자세히 보기

GitLab pushJenkins · S2I 빌드개발 자동 배포운영 확인·배포

개발 환경 2대와 운영 환경 9대를 구성하고, WebIDE·GitLab·Jenkins·Kubeconsole의 로그인을 통합했습니다. 개발 소스·이미지의 hash를 확인한 뒤 운영용 Jenkins에서 kubectl patch로 배포하도록 구성했습니다.

2025년 3월 미팅·설계에 참여해 12월 설치를 시작했습니다. 첫 대상인 주간 이용자 약 3,000명 규모의 퀴즈 서비스는 2026년 6월 오픈했습니다. 시간당 최대 3,000명 접속을 가정한 부하 시험에서 목표 200ms 대비 평균 응답시간 20ms 미만을 확인했습니다. 네 개 도구의 인증과 개발·운영 접근을 함께 정리했습니다.

03 / ROOT CAUSE ANALYSIS

SK C&C / 현대백화점

2023.06PoC 검증

빌드할 때마다 오프라인이 되던 노드,
메모리 사용 경로에서 원인을 찾았습니다.

Build Pod에 메모리 제한이 없어 OOM이 발생하고 노드 전체가 불안정해지는 경로를 특정했습니다. 기술 분석과 개선안 검증을 맡아, PoC 환경에서 2주 내 해결을 증명했습니다.

리소스 제한 누락 → OOM → 노드 불안정의 원인 규명

OpenShift
Build Pod
Resource Limits
OOM

내 역할과 결과 자세히 보기

장기간 해결되지 않았던 문제의 기술 분석을 주도했습니다. 개선 결과를 바탕으로 OpenShift 전환 추진에 합의했으며, 이 사례의 성과는 PoC 해결 검증까지입니다. 실제 구축 계약으로 이어진 사례와 구분합니다.

04 / GPU · AI INFRASTRUCTURE

서울신용보증재단

2026.04 — 현재진행 중

베어메탈부터 4종 모델 서빙까지,
약 1주 만에 GPU 운영 환경을 구성했습니다.

H200 4장(서버 2대)을 포함한 4대 구성의 RKE2 환경에서 OS·GPU 드라이버·클러스터 구축을 지원했습니다. LLM·리랭커·이미지 생성 모델 4종을 서빙하고, GPU 사용과 추론 지표를 함께 관측하도록 구성했습니다.

약 1주 · H200 4장 · 모델 4종
OS → Kubernetes → 서빙 → 관측

RKE2
vLLM · vLLM-Omni
OpenTelemetry
Prometheus

구축·운영 지원 범위

10G×2 LACP Bond 구성을 지원하고, OpenTelemetry·Prometheus로 수집한 GPU·추론 지표를 사내 시각화 솔루션에 연결했습니다. 기존 Affine·Mattermost의 VM(Docker) 환경에서 Kubernetes로의 이전도 지원했습니다.

함께 쌓아 온 실무 경험

2025.12 — 현재사내 Agentic AI R&D · 보고서 자동화와 LLM 서빙

Flowise·MCP·vLLM으로 정보 수집·추출·생성·검수 흐름을 설계·구현하고 사내 R&D팀에 발표했습니다. 수작업 약 20분이 걸리던 보고서 생성 과정을 1분 이내로 자동화한 내부 사례가 있습니다.

2023.12 — 2024.02아시아나 IDT · 분리망 OpenShift 운영 환경

4개 분리망에 Loki·Harbor·TOTP를 구성했습니다. 외부 이미지 pull 제약을 Harbor 프록시로 해소하고 사람·서비스 계정의 인증 정책을 분리했습니다. 3개월 안에 운영 환경을 구축했으며 계약 전환에 기여했습니다.

2023.07 — 2024.08섹타나인 / LG U+ · 베어메탈 OpenShift PoC와 구축 지원

Java 애플리케이션 전환 PoC 환경 구성과 시연 지원을 맡았습니다. 물리 서버 5대의 랙 설치·네트워크 구성에 참여하고 서버·스위치 간 LACP 협상 불일치를 조치했습니다. PoC는 계약으로 이어졌습니다. 본 구축에는 보조로 참여했습니다.

2023.09한국전력공사 · OpenShift Build 기반 배포 시연

OpenShift Build·Tekton·S2I를 사용한 이미지 빌드·배포 흐름을 구성·시연했습니다. 기술 설계와 환경 구성, 데모 발표를 담당하고 고객의 CI/CD 도입 논의를 지원했습니다.

02 / Personal HCI · Hybrid Kubernetes

5노드 HCI,
구성부터 정비까지 직접.

2012년 개인 서버 운영을 시작했습니다. 현재는 같은 물리 호스트 5대에서 Proxmox VE 가상화와 Ceph 스토리지를 함께 운영합니다. 이 위의 워커 VM 5대에 AMD 물리 워커 1대와 OCI 4대를 연결해 총 10노드 Kubernetes로 서비스를 운영합니다.

24 Ceph OSD

약 26TB raw 용량

238 Pod

830 GitOps 리소스

2026.10.07 기준

HCI 5대와 Hybrid Kubernetes 10노드CONFIGURATION / 2026.10.18

ON-PREMISE / KUBERNETES WORKERS 6

Proxmox VE + Ceph HCI

물리 호스트 5대

각 호스트가 VM 실행과 분산 스토리지를 함께 담당

HOST 01worker VMProxmox
+ Ceph

HOST 02worker VMProxmox
+ Ceph

HOST 03worker VMProxmox
+ Ceph

HOST 04worker VMProxmox
+ Ceph

HOST 05worker VMProxmox
+ Ceph

Ceph 분산 스토리지RBD → VM 디스크CephFS → 서비스 파일

Proxmox HA · Intel iGPU SR-IOV · Cilium

worker

AMD 물리 워커 1대

MicroOS · Radeon 680M / ROCm
HCI 밖에서 Kubernetes에 직접 참여

NetBirdOVERLAY

PERSONAL OCI / KUBERNETES NODES 4

제어 영역과 클라우드 워커

OCI A1 · ARM · RKE2

Control plane × 3

controlcontrolcontrol

worker

Cloud worker × 1

Ceph PVC가 필요 없는 워크로드

NLB · Remote Peering · IAM · DRG

Kubernetes 총 10노드워커 VM 5 + AMD 물리 워커 1 + OCI control plane 3 + OCI worker 1

외부 요청OCI NLB → OCI A1의 NetBird 앱 → 홈랩 서비스홈랩 외부 포트 비공개

설계와 운영의 기준

VM과 공유 스토리지를 같은 5대에 구성했습니다. 따라서 호스트 한 대를 정비할 때도 VM의 이동·종료, Ceph의 상태, 상위 서비스의 가용성을 함께 확인합니다. 운영 중 겪은 문제를 바탕으로 배치와 정비 절차를 구체화했습니다.

01 / STORAGE

VM 디스크와 서비스 파일의 역할 구분

VM 디스크는 Ceph RBD, 파일을 다루는 서비스는 CephFS를 사용합니다. 가상화와 저장소를 함께 운영하므로, 서비스가 느려질 때 앱·VM·Ceph의 증상을 연결해 원인을 좁힙니다.

주기적 I/O 정체를 해결한 과정 ↘

02 / PLACEMENT

데이터와 장치의 위치에 맞춘 배치

Ceph PVC가 필요한 워크로드는 온프레미스에, 필요 없는 워크로드는 OCI에도 배치합니다. GPU 추론은 Intel OpenVINO와 AMD ROCm을 별도 Deployment로 두고 공통 Service로 연결했습니다.

장치별 실행 환경을 유지하면서 연결 단위로 분산합니다. 별도 요청 프록시를 관리하는 부담을 고려해 작업별 라우팅은 도입하지 않았습니다.

03 / CAPACITY

평시보다 정비 뒤의 메모리를 기준으로

VM과 Ceph가 같은 호스트의 RAM을 사용합니다. VFIO VM의 고정 메모리와 MDS가 active로 승격한 뒤의 메모리를 구분해 확인했습니다. 무거운 두 파일시스템의 active·replay를 네 호스트로 분산해 단일 호스트 정비 시 부하를 고려했습니다.

MDS 배치 판단과 측정 기록 ↗

재부팅과 네트워크 변경까지 운영 절차에 연결

계획 정비: Fleet·Helm으로 서비스를 배포하고 RKE2의 API 상태 확인·cordon·drain을 systemd에 연결했습니다. DB primary의 PDB가 drain을 막는 경우에는 사전 역할 전환을 추가했습니다.

변경 후 확인: RKE2 minor 버전 순차 업그레이드와 MicroOS LTS 커널 전환 후 GPU 드라이버 상태를 점검했습니다. Cilium 전환에서는 VXLAN·MTU·라우팅을 확인하고, 인터넷 도달성과 NetBird overlay 장애를 나눠 재기동 조건을 정했습니다.

자원 판단의 범위: MDS 캐시 목표는 메모리의 절대 상한이 아닙니다. 단일 계획 정비에서의 승격과 메모리를 고려한 배치이며, 모든 다중 장애에서 동일한 여유를 보장하는 구성으로 설명하지 않습니다.

NAS에서 다중 노드 운영으로 확장한 과정

2012 —

개인 서버·NAS

직접 쓰는 서비스를 올리고 저장소와 운영체제를 관리하는 데서 시작했습니다.

2023 기록

Docker Swarm

노드 등급 라벨, 서비스 배치, IPv4·IPv6 overlay를 구성했습니다. firewalld와 docker_gwbridge의 충돌을 조치한 기록을 남겼습니다.

현재 구성

Hybrid Kubernetes

CNI·분산 스토리지·GitOps를 함께 다루며 RKE2로 확장했습니다. Ceph PVC가 필요한 서비스는 온프레미스에 배치합니다.

웹 인증 통합 적용

그룹별 접근과 장애 복구 경로까지
설계한 웹 통합 인증

인증 서버 장애가 복구 도구의 접속까지 막지 않도록 서비스별 연동 방식을 정했습니다. authentik과 그룹 정책으로 주요 웹 서비스의 접근을 통합하되, Rancher는 장애별 접속 경로를 유지하고 Gitea는 기존 비밀번호 로그인과 GitOps 인증 경로를 유지했습니다.

연동 문제와 재구축 절차 자세히 보기

도메인·캐시: 서비스 외부 주소와 인증 콜백을 정리하고 Cloudflare에서 인증 도메인의 캐시를 우회했습니다. 실제 사용하는 인증 도메인별로 패스키 등록과 로그인을 검증했습니다.

프록시 세션: SilverBullet을 authentik outpost로 보호하면서 복수 프록시의 세션 문제를 확인하고, 단일 애플리케이션 인스턴스의 특성에 맞춰 배치를 조정했습니다.

재구축 준비: Fleet 적용 의존성과 Rancher 재설치 전후 작업을 문서화했습니다. 보존할 영속 데이터와 다시 생성할 모니터링 지표·세션·캐시를 구분했습니다.

웹 인증비밀번호·패스키 · 관리/공동/개인 그룹
Nextcloud · Immich · SilverBullet · Grafana · Rancher
Homarr · WordPress는 기존 계정을 활용해 SSO 연동

접근·복구두 Immich 인스턴스의 허용 사용자 분리
Rancher 장애별 접속 경로 유지 · Gitea 기존 로그인·GitOps 인증 유지

SMB 판단인증 동기화는 복제 VM에서 검증 후 실험 종료
운영은 Samba · OpenLDAP · SSSD 유지

SMB는 동기화 지연·계정 변경 경로·추가 코드 유지 비용을 고려해 기존 구성을 유지했습니다. 웹 SSO와 별도로 판단한 결과입니다.

03 / HCI operations · Personal

공유 자원의 문제를
서비스의 관점에서 풀었습니다.

같은 호스트에서 VM과 Ceph를 운영하면 물리 정비와 스토리지 작업이 서비스까지 영향을 줄 수 있습니다. 어떤 제약을 확인했고, 왜 그 조치를 골랐으며, 어디까지 검증했는지 정리했습니다.

HCI / PHYSICAL MAINTENANCE2026.10

물리 디스크 정비 중에도
Kubernetes 서비스 연속성 유지

5개 노드 중 디스크 수와 용량이 가장 적은 노드에서 Ceph 디스크가 고장 났습니다. 핫스왑이 불가능해 물리 정비에는 호스트와 일부 VM의 종료가 필요했습니다.

판단디스크 수·용량이 작은 노드의 여유를 고려해, 다른 두 노드에서 NVMe를 하나씩 옮기는 정비 순서를 계획했습니다.
조치이동 대상 OSD를 먼저 제거한 뒤 NVMe 2개를 옮겼습니다. 핫스왑이 불가능한 호스트와 일부 VM은 정비를 위해 종료했습니다.
결과Kubernetes 서비스 이중화로 정비 중에도 서비스를 유지했습니다.

서비스 중단·데이터 손실 없음

호스트·일부 VM의 종료와 서비스 가용성을 구분해 대응

운영 관점에서 남긴 것

장치 정비와 서비스 영향은 서로 다른 층위의 문제였습니다. 물리 작업에 필요한 종료를 허용하면서도, Kubernetes의 이중화된 서비스가 계속 동작하도록 운영했습니다.

LINUX / HARDWARE DIAGNOSIS2026.10

CPU 레지스터 분석과 대조 시험으로
노드 성능 저하의 원인을 규명했습니다.

5개 노드 중 한 대만 전력을 19–20W밖에 쓰지 못한 채 85–105°C, 약 0.4GHz로 동작했습니다. 28W 한도에 닿기도 전에 느려진다는 관찰에서, 전력 설정보다 열 전달 문제를 먼저 의심했습니다.

진단정상 노드를 대조군으로 삼고 MSR 0x1A2의 TCC offset을 읽었습니다. 도구의 105°C 표시와 실제 85°C 스로틀 기준이 달랐고, MSR 0x64F로 전력·열 제한 사유를 구분했습니다.
조치물리 점검에서 CPU 팬 고장을 확인했습니다. 임시 전력·클럭 제한과 냉각 조정 후 Noctua 팬으로 교체했습니다.
검증Ceph 상태를 확인한 뒤 한 노드씩 지속·버스트·Immich 실서비스 부하를 시험했습니다. 과열 중단과 원래 설정 복원을 스크립트에 넣어 반복 검증했습니다.

도구 표시105°CTCC offset20°C실제 기준85°C

7,633 → 0

조치 전 10분간 core 스로틀 카운터 증가 → 조치 후 부하 시험 증가 없음

측정 조건과 후속 조치

같은 전력 한도에서 다른 노드보다 적은 전력을 쓰면서도 더 뜨겁다는 관찰을 물리 점검으로 연결했고, 분해 후 정지한 CPU 팬을 확인했습니다. 10월 4일의 PL1 23W / PL2 35W / 최대 3GHz 설정에서 CPU·GPU·Immich 부하를 검증했습니다. CPU 지속 부하 안정 온도는 77.5°C였고, 버스트 최고 온도는 81°C였습니다.

팬 교체 뒤 10월 10일에는 팬 100% 조건에서 28W 지속 부하를 10분간 시험해 최고 약 62°C를 확인했습니다. 이후 운영값은 28W / 55W로 조정했습니다. PWM 적용 후 최종 설정의 반복 검증은 남아 있습니다.

CEPH / VM I O CONTENTION2026.10 확인

매시 15분, 스냅샷 정리가
VM과 파일 서비스를 멈칫하게 했습니다.

CephFS 메타데이터와 RBD가 30–60초 함께 정체했습니다. Nextcloud의 not ready와 VM iowait를 정리 작업 시각·Ceph slow-op 로그에 맞춰 snaptrim 경합으로 좁혔습니다.

판단mClock에서는 sleep 계열 설정이 적용되지 않았습니다. 공통 QoS를 제한하면 다른 작업에도 영향을 줄 수 있어 snaptrim 자체의 동시성과 비용을 조정했습니다.
조치동시성을 1로 낮추고 비용을 단계적으로 높였습니다. 정리가 느려져도 다음 시간 주기까지 쌓이지 않는지 함께 확인했습니다.
검증250MiB 시험에서 정리는 60–165초로 늘었지만 서비스 정체가 사라졌습니다. 이후 500MiB로 운영하며 해당 시간대의 로그를 확인했습니다.

SLOW_OPS 0

10월 7–14일 스냅샷 정리 시간대 · 별도 OSD 하강 사건 제외

원인 분석과 후속 관찰 기록 ↗

PROXMOX / DATABASE MAINTENANCE2026.10

재부팅 전에,
DB primary가 먼저 자리를 옮기도록.

Proxmox 정기 재부팅에 연결한 게스트 drain이 15분 타임아웃에 걸렸습니다. 저널을 확인해 CNPG primary의 PDB가 퇴거를 거부하는 상황과 replica 종료 지연을 구분했습니다.

판단노드 순번만으로 이동 대상을 정하면 다음 정비가 가까운 노드를 고를 수 있습니다. 실제 재부팅 달력을 계산해 다음 정비까지 가장 여유 있는 노드를 선택했습니다.
조치부팅 후 사전 switchover와 종료 전 primary 이동을 구성했습니다. 이동 실패가 drain 자체를 막지 않도록 하고, 종료 시간 예산을 함께 조정했습니다.
검증10월 6일 사전 전환과 9일 종료 전 전환 기록을 확인했습니다. 정비 대상 노드의 primary가 0개가 되는 것을 완료 조건으로 삼았습니다.

호스트 정비에 DB 역할 전환 연결

실제 전환 기록 확인 · 전체 서비스 무중단을 측정한 결과는 아님

PDB 진단과 정비 자동화 기록 ↗

같은 시기의 무응답 장애에 대비해 iTCO 하드웨어 워치독과 패닉 후 재부팅 정책도 구성했습니다.

04 / Engineering decisions

운영의 조건이
구현의 기준이 됩니다.

기존 설정을 유지해야 하는 전환, 개인 기록을 다루는 검색, 권한을 지켜야 하는 포털. 각 도구에서 무엇을 지키려고 했고, 그 때문에 어떤 구조를 선택했는지 정리했습니다.

4 PROJECTS

개인 프로젝트 · 홈랩 운영 적용01 / CONTROL PLANE

기존 Ingress를 유지한
Gateway API 운영 전환

ingress-gateway-bridge

애플리케이션 설정을 유지하면서 라우팅을 Gateway API로 전환하는 Go 컨트롤러를 개발했습니다. 선택한 클래스만 변환하고 기존 Route와 동작을 비교해 운영에 적용했습니다. 전환 후 HTTPRoute 18개를 자동 관리하며 수동 Route를 없앴습니다.

리소스 관리 흐름 컨트롤러는 Route를 관리하며 요청 트래픽을 중계하지 않습니다.

애플리케이션 입력기존 Ingress전환할 Class를 명시

Go controller변환·소유권 확인모호한 의미는 거부

Gateway API소유한 HTTPRoute기존 Gateway에 연결

전환 범위를 명시

선택한 클래스만 변환합니다. 기본 클래스를 암묵적으로 인수하지 않아, 같은 클러스터의 다른 Ingress 컨트롤러와 역할이 겹치지 않게 했습니다.

모르는 설정은 거부

지원하지 않는 필드를 조용히 생략하면 라우팅 의미가 달라질 수 있습니다. 변환할 수 없는 입력은 거부하고, TLS 설정은 기존 Gateway의 책임으로 남겼습니다.

변경 권한을 제한

기본값은 쓰기 없는 dry-run입니다. writer 권한과 실행 옵션을 모두 바꿔야 쓰기가 가능하며, 다른 관리자가 만든 Route는 인수하지 않습니다.

18전환 후 Ingress 소유 HTTPRoute

35전후 GET 요청 비교

기존 Ingress 63개의 UID를 유지했습니다. 선택한 서비스의 Route를 전환하고 상태 코드·리다이렉트·보안 헤더 보존을 확인했습니다.운영 전환 기록 · 2026.10.08

전환 순서와 배포 중 502 대응

작게 시작: 별도 IngressClass와 echo 앱으로 HTTPS 9개 경로를 먼저 검증했습니다. 이후 DBtools·WordPress 파일럿을 거쳐 공유 Gateway 구성을 적용했습니다.

서비스별로 비교: Portfolio·Grafana·Nextcloud·Immich 등은 한 번에 바꾸지 않고, 이전 Route와 규칙·백엔드·필터가 같은지 비교한 뒤 수동 Route를 제거했습니다. 전환 후 수동 관리 Route는 0개가 됐습니다.

배포 실패에서 바꾼 것: 새 Gateway Bundle이 컨트롤러의 Helm release 이름을 재사용해 WordPress에 일시적인 502가 발생했습니다. Bundle·release 이름을 분리했습니다. 그 여파로 삭제 대기 상태가 된 GatewayClass는 운영 영향을 확인하기 전까지 finalizer를 강제로 제거하지 않았습니다.

검증 범위: 운영 전환은 AMD64 환경과 HTTP GET 중심입니다. 인증된 업로드·WebDAV 쓰기 검증은 별도로 남아 있으며, ARM64는 이미지 빌드까지 확인했습니다.

Go · controller-runtime
Gateway API
Cilium
Fleet
envtest · race

구현과 설계 문서

개인 서비스 운영 · RAG 소스 비공개02 / KNOWLEDGE PIPELINE

원본 보존부터 접근 제어까지 설계한
2,220페이지 지식 검색 플랫폼

onenote-md-exporter + Notes RAG

OneNote 이관 도구와 Notes RAG를 연결해 개인 기록을 검색 가능한 운영 플랫폼으로 구성했습니다. 원본 보존·증분 색인·문서 권한·삭제 보호에 알림과 복원 검증을 더했습니다. 2026년 9월 24일 기준 17개 노트북·2,220페이지를 색인했습니다.

원본에서 검색까지 보존본과 활용본을 분리한 흐름

01 / PRESERVEOneNote 원본 보존

Graph 읽기 전용
HTML·첨부·SHA-256

02 / VERIFYMarkdown 변환

허용한 노트북만
누락 시 변환 중단

03 / INDEX변경분 색인

Qwen · pgvector
15분 주기 · 삭제 제한

04 / RETRIEVE권한에 맞는 검색

MCP · 웹 · Open WebUI
공개 허용 목록 · OIDC

원본을 다시 확인할 수 있게

Graph HTML·이미지·첨부와 manifest를 먼저 보존합니다. 로컬 완전성 검사와 불완전 페이지만 재수집하는 repair를 두고, 검증된 원본에서 Markdown을 만듭니다.

일시적인 누락이 삭제가 되지 않게

문서가 두 번 이상 유효한 검사에서 사라지고 15분 이상 지나야 삭제합니다. 누락이 20페이지 또는 2%를 넘으면 임베딩·삭제 전에 실행 전체를 중단합니다.

로그인과 열람 권한을 구분

모르는 노트북 ID는 비공개로 처리합니다. 소유자는 고정된 OIDC 사용자 식별자로 확인하고, 검색뿐 아니라 원문·청크 조회에도 같은 권한을 적용했습니다.

2,220색인한 페이지 · 2026.09.24

15분증분 색인 주기

변경이 없으면 임베딩 API를 호출하지 않습니다. 갱신은 한 트랜잭션으로 반영하고, 검증·임베딩·SQL 실패 시 이전 색인을 유지합니다.

검색 우선순위와 운영·복원 설계

현재 문서를 먼저: 지난 문서는 삭제하지 않고 fallback으로 분리했습니다. 현재 문서에서 먼저 찾고, 부족할 때 지난 문서를 검색하도록 규칙을 정했습니다.

세대 전환을 작게: 청킹 방식이 바뀔 때는 전체 미리보기 후 변경 페이지 수를 제한한 마이그레이션으로 확인하고 검색 서버를 교체합니다. 모르는 세대나 정책이 섞이면 허용하지 않습니다.

접근과 복원: MCP 검색 DB role은 SELECT 전용이고 TLS를 검증합니다. 같은 Ceph 내 RBD 스냅샷을 새 PVC에 격리 복원해 상태 무결성과 세션·캐시 정리를 확인했습니다.

실패와 정지를 감시: 6시간 주기 스냅샷과 15분 모니터로 색인·스냅샷 실패, 정지 상태와 마지막 성공 시각을 확인합니다. DNS-L7 문제로 보류했던 모니터는 9월 25일 전용 정책 제거 후 재활성화하고, 일회성 Job 성공과 Discord 전송을 확인했습니다.

검증 범위: 색인·권한·알림·격리 복원 동작을 확인했습니다. 같은 Ceph 안의 복원이며, 검색 품질 평가는 별도 과제로 남아 있습니다.

PowerShell · Python
Microsoft Graph
PostgreSQL · pgvector
MCP · OIDC
Fleet

공개 이관 도구 보기

공개 저장소03

KubeShelf

서비스가 많아지면 주소뿐 아니라 누구에게 어떤 주소를 보여줄지도 관리해야 합니다. Ingress·NodePort를 탐색하는 포털에 OIDC 사용자·그룹별 서버 측 필터링을 적용했습니다.

Kubernetes API는 읽기 전용이고 Secret 조회 권한이 없습니다. 상태는 Pod Ready·EndpointSlice로 판단하되 확인할 수 없는 값은 unknown으로 둡니다. 리소스 상태를 서비스 정상 동작 보장으로 표시하지 않습니다.

설정 저장에도 GitOps를 사용한 방식

DB·PV 없이 설정을 Git에 커밋하고 Fleet이 ConfigMap으로 반영합니다. 요청한 설정과 실제 반영 상태를 구분하고, 충돌 시 강제 push 대신 conflict를 반환합니다. 새 설정이 유효하지 않으면 마지막 정상 설정을 유지합니다.

표시 옵션과 접근 권한은 분리합니다. 카드를 보이게 설정해도 권한 없는 주소를 반환하지 않으며, NodePort는 별도 정책이 없으면 관리자 전용입니다.

Go · React
OIDC
Helm · Fleet
amd64 / arm64

코드와 배포 문서

PR 제출 · 미병합04

Prefix의 의미를 지키는 수정

Cloudflare Tunnel Ingress Controller가 Prefix 경로를 앵커 없는 정규식으로 넘겨 의도하지 않은 요청도 관리자 백엔드로 보내는 문제를 수정했습니다.

Prefix /wp-admin의 경계 예시

/wp-admin/edit.php포함

/foo/wp-admin제외

/wp-admin-tools제외

기존 정규식을 사용하는 ImplementationSpecific 동작은 유지했습니다. 같은 Ingress에서 컨트롤러 이미지만 바꿔 실제 Tunnel의 HTTP 20개 사례를 비교했고, 회귀 검증 기록과 함께 PR #368을 제출했습니다.

Go
Ingress
Cloudflare Tunnel
PR #368

수정 PR과 검증 기록

개인 프로젝트입니다. 운영·색인 수치는 각 기록 시점 기준이며, PR 상태 확인일은 2026.10.13입니다.

More operating decisions

다음 변경에도
다시 쓸 수 있는 절차

한 번 조치한 내용을 다음 업데이트와 장애 때 활용할 수 있도록 빌드·점검·복구 순서로 남깁니다.

Linux · Packaging

커널 모듈을 반복해서 설치해야 할 때

MicroOS에서 사용하는 공개 i915 SR-IOV 모듈을 openSUSE KMP 패키지로 구성하고 OBS 빌드 파이프라인을 만들었습니다. 커널 모듈 패키징을 다시 실행할 수 있는 배포 작업으로 정리했습니다.

빌드 자동화 기록

Storage · Recovery

복구 명령의 순서도 판단의 일부

Btrfs 마운트 실패에서 log tree 오류를 확인하고, zero-log와 상태 점검을 먼저 수행해 문제를 해결했습니다. repair·superblock 복구 계열은 최후 수단으로 구분했습니다.

개인 운영 기록 · 파일시스템 상태와 조치 위험도를 구분

Cloud · Network

계정이 다르면 연결 권한도 나눠서

OCI의 서로 다른 tenancy·region을 연결하면서 요청자·수락자 IAM 권한, DRG 라우팅, 구간별 Security Rules를 나눠 구성했습니다. 연결 생성부터 패킷이 지나갈 경로까지 각각 확인했습니다.

OCI 연결 구성 기록

구축 이후까지 고려하는 기술 범위

Professional experience

실무에서 다룬 기술

플랫폼OpenShift · RKE2 · RHEL · Linux · Harbor · Helm

배포·보안Jenkins · GitLab · S2I · Tekton · Keycloak · OIDC · TOTP

관측·AIOpenTelemetry · Prometheus · Loki · vLLM · Flowise · MCP

Personal practice

개인 운영에서 확장한 기술

인프라Proxmox VE · HCI · Ceph RBD/CephFS · ZFS · OCI · NetBird · Cilium

운영·인증Fleet · GitOps · authentik · LDAP · systemd · RAPL · MSR

구현·자동화Go · Python · Fish · GitHub Actions · PostgreSQL · pgvector

같이 운영할 수 있도록 남깁니다

기술을 선택한 이유와 검증 결과를 설명하고 다음 담당자가 이어서 판단할 수 있는 자료와 절차로 정리합니다.

상대가 판단할 수 있게 설명

서울디지털대 초기 미팅에서 전환 목표와 범위를 협의했습니다. 국방부 프로젝트에서는 구축·시험 결과서와 운영자 매뉴얼을 작성하고 고객 교육까지 맡았습니다.

반복 문제를 찾아 개선

사내 점검 보고서의 약 20분 수작업을 1분 미만 자동 생성으로 바꿨습니다. 개인 HCI에서는 정비 때 반복되던 DB 역할 전환을 재부팅 일정과 연결했습니다.

운영 이후의 부담까지 비교

SMB 인증 동기화를 복제 VM에서 검증한 뒤에도 계정 변경 경로와 추가 코드의 유지보수 부담을 비교했습니다. 실제 운영은 기존 Samba·OpenLDAP·SSSD 구성을 유지했습니다.

한성대학교 전자정보공학 학사 · 2022.02리눅스마스터 2급 · 네트워크관리사 2급고객 교육·운영 문서·기술 시연 경험

LET’S WORK TOGETHER

함께 풀 문제를 기다립니다.

플랫폼 전환, Linux·Kubernetes 운영, 장애 분석과 자동화.
제가 다뤄 온 문제와 구현은 아래 채널에서 더 보실 수 있습니다.

[email protected]

블로그 ↗GitHub ↗pf.cola16.app ↗