2주가 걸렸습니다. SSD가 시스템을 얼리는 것부터 시작해서 DHCP가 클러스터를 죽이고, CPU가 1291%까지 치솟고, Python 프로세스가 커널에 갇혀버리는 일들을 겪으며 결국 Slack에 Failover 알람이 세 단계로 날아오는 것을 확인했습니다. 이 포스팅은 그 2주를 돌아보는 회고입니다.
🔗 프로젝트 전체: GitHub Repository | GitHub Wiki | 칸반보드 | Docker Hub
1️⃣ 왜 이 프로젝트를 시작했는가
대전 국가정보자원관리원 화재 사고를 보면서 이런 생각을 했습니다.
“현장의 CCTV는 어떻게 됐을까. 사고 원인을 밝혀야 할 데이터가 사고와 함께 타버린다면, 그 데이터는 처음부터 없었던 것과 다름없지 않을까.”
항공기 블랙박스가 떠올랐습니다. 기체가 추락해도 블랙박스는 살아남습니다. 같은 원리를 공장 현장에 적용하면 어떨까. 처음엔 단순히 카메라 영상을 저장하는 수준을 생각했지만 설계를 거듭하면서 Control Plane 격리 / HA 스토리지 / 자동 Failover / 데이터 티어링 이 네 가지가 모두 맞물려야 한다는 걸 깨달았습니다. 그렇게 프로젝트 범위가 점점 커졌습니다.
2️⃣ 잘 된 것들
✅ Failover가 실제로 동작했다
Worker 2의 랜선을 뽑는 그 순간이 가장 긴장됐습니다. 아무 명령도 입력하지 않은 채로 화면을 바라보며 기다렸고, 1분여 후 파드가 Worker 1으로 이동하고 Slack에 알람이 오고 감시가 재개됐습니다. 그 장면을 눈으로 확인했을 때 프로젝트가 성공했음에 안도했습니다.
tolerationSeconds: 30으로 튜닝한 것도 의미 있었습니다. 단순한 숫자 하나지만 “실제 현장에서 5분의 공백이 얼마나 치명적인가”를 생각하고 내린 결정이었습니다.
✅ 폐쇄망에서 GitOps를 완결했다
인터넷 없이 온프레미스의 GitLab + ArgoCD만으로 GitOps 파이프라인을 완성한 것이 개인적으로 가장 성취감을 느낀 부분입니다. git push 한 번으로 3개 노드에 배포가 완료되고 현장에 직접 접근할 필요가 없는 구조가 됐습니다. Helm Chart까지 도입하면서 values.yaml 하나로 이미지 태그, replicas, 노드 설정을 모두 관리하게 됐습니다.
✅ Ansible로 인프라를 코드로 남겼다
프로젝트 초반에 SSH로 직접 설정한 것들이 어디에도 기록되지 않는다는 걸 중간에 깨달았습니다. 그때부터 Ansible Playbook으로 전부 코드화했습니다. 5개 Playbook으로 운영 자동화를 할 수 있는 상태가 됐고, 이 과정을 통해 Ansible의 역할과 IaC의 중요성을 실감했습니다.
✅ 데이터 티어링이 안정적으로 동작했다
NFS STALE 처리, KUBECONFIG 권한 처리, Python D-State 블로킹 처리까지. 겉보기엔 단순한 crontab 스크립트 하나이지만 그 안에 수많은 트러블슈팅의 결과가 녹아 있습니다.
3️⃣ 가장 어려웠던 것들
🔴 사내망 DHCP 충돌 → K3s 전면 재구축
MetalLB 설치가 클러스터를 무너뜨렸을 때, 원인이 사내망 DHCP와 노드 IP의 충돌이라는 걸 발견했습니다. 이전까지는 어플리케이션 단의 문제만 다뤘는데, DHCP IP 대역 충돌은 “내가 이제 진짜 인프라 설계를 하는 중이구나”를 깨닫게 해준 경험이었습니다. 비록 처음부터 다시 시작이라는 허망한 해결 방식이었지만, 이후 프로젝트 전반에서 인프라 레이어를 먼저 생각하는 습관이 생겼습니다.
🔴 K3s CronJob CPU 폭주 → crontab 전환
InfluxDB 티어링을 K3s CronJob으로 구현했더니 CPU가 1291%까지 치솟아 클러스터가 마비됐습니다. 처음엔 스크립트 로직 문제라고 생각했는데, 알고 보니 NFS hostPath 마운트 타임아웃으로 시작된 containerd 유령 레코드 문제였습니다. 작업의 중요도를 생각하고 시스템의 부하를 고려해서 적절한 도구를 선택해야 한다는 것을 배운 경험이었습니다.
🔴 NFS STALE + Python D-State 좀비 프로세스
재부팅 후 tiering 스크립트가 아무 응답 없이 멈추는 현상이 반복됐습니다. Python 코드 버그라고 생각하고 반복해서 수정했는데, 실제 원인은 커널 레벨의 NFS 블로킹이었습니다. 애플리케이션 레이어만 봐서는 해결이 안 되는 문제가 있다는 것을, 커널 레벨의 동작 방식을 이해해야 원인을 찾을 수 있다는 것을 배웠습니다.
4️⃣ 아쉬운 것들
잘 된 것만큼 못 다 한 것을 인정하는 것도 중요합니다.
실제 환경이 아닌 시뮬레이션 — Worker 2 파괴를 랜선 제거로 시뮬레이션했습니다. 실제 산업 현장의 전원 차단, 발열, 물리적 충격 환경에서는 다른 문제가 생길 수 있습니다.
Helm 범위 제한 — ai-apps만 Helm으로 전환했고 Longhorn, Prometheus, Grafana는 기존 방식을 유지했습니다. 안정성을 위한 선택이었지만 전체 통일성이 아쉽습니다.
AI 모델 직접 학습 미완 — 인프라 구성 위주로 진행하다 보니 YOLOv8 모델을 직접 학습시키지 못했습니다. 사전 학습된 모델을 사용해서 성능이 시스템 수준에 완전히 맞춰지지 않았습니다.
5️⃣ 이 프로젝트 전후의 기술적 변화
| 영역 | 프로젝트 전 | 프로젝트 후 |
|---|---|---|
| K8s 스케줄링 | NodeSelector 정도만 알았음 | Node Affinity / Toleration / tolerationSeconds 튜닝까지 |
| GitOps | ArgoCD 개념만 알고 있었음 | 폐쇄망 GitLab 연동 + Helm Chart 자동 배포까지 |
| 스토리지 | 로컬 볼륨(hostPath)밖에 몰랐음 | Longhorn HA 복제 + NFS Store-and-Forward 구조까지 |
| 운영 자동화 | 수동 SSH 접속해서 설정 | Ansible IaC로 운영 코드화 |
| 디버깅 방법론 | 에러 메시지 구글링 수준 | 커널 레벨(D-State) / 재부팅 재현 추적까지 |
| 패키지 관리 | raw YAML 파일 직접 수정 | Helm Chart + values.yaml 변수화 |
| 모니터링 | Grafana 대시보드 보는 수준 | PromQL / InfluxQL 직접 작성 + 3단계 알람 설계 |
6️⃣ 이 프로젝트가 증명한 것
라즈베리파이 3대와 오픈소스 스택으로 엔터프라이즈 수준의 HA 아키텍처를 구현할 수 있습니다.
클라우드 없이도 GitOps + IaC + 자동 Failover가 완전히 동작합니다. K3s + Longhorn + ArgoCD + Helm + Ansible 조합은 고가 산업용 서버 대비 90% 이상 비용을 절감하면서도 핵심 기능을 모두 충족합니다. 엣지 환경의 물리적 제약(RAM 4GB, ARM64, 폐쇄망)은 설계로 극복할 수 있습니다.
하지만 무엇보다 “이 시스템이 실제 현장에서 쓰인다면” 이라는 질문을 끊임없이 던지면서 설계한 것이 이 프로젝트의 가장 큰 가치라고 생각합니다.
7️⃣ 다음에 한다면
기술적으로 더 발전시키고 싶은 방향들입니다.
ArgoCD ApplicationSet 도입 — 멀티 환경(dev/staging/prod) 배포 자동화로 확장합니다.
Longhorn 백업 S3 연동 — 오프사이트 백업으로 클라우드 환경에서 Cold Storage를 이중화합니다.
Helm 전체 통일 — Longhorn, Prometheus, Grafana도 Helm Chart로 전환해서 전체 인프라를 일관성 있게 관리합니다.
실제 현장 환경 검증 — 전원 차단, 발열, 물리 충격 시나리오에서의 동작을 검증합니다.
🗓️ 2주 타임라인
2026.02 Phase 1~2 K3s 클러스터 + Longhorn + ArgoCD GitOps 파이프라인
2026.03 Phase 3 AI 파드 (YOLOv8/YAMNet/BME280) + InfluxDB + Grafana 대시보드
2026.03 Phase 4 Prometheus + Grafana 3단계 Slack 알람
2026.03 Phase 5 데이터 티어링 + Failover/Failback 자동화 + Ansible IaC + Helm
2026.03 완료 전체 시스템 통합 검증 및 문서화
이 프로젝트를 통해 인프라 엔지니어로서 필요한 감각 — 설계, 자동화, 디버깅, 문서화 — 을 처음으로 하나의 흐름으로 경험했습니다. 인프라 레이어를 설계하는 것, 커널 레벨까지 내려가서 문제를 추적하는 것, 그리고 시스템이 스스로 살아남는 것을 직접 눈으로 확인하는 것. 앞으로의 모든 프로젝트에서 이 경험이 기준점이 될 것 같습니다.
🔗 전체 시리즈: 1편 — 프로젝트 개요 & 아키텍처 | 2편 — K3s 클러스터 구축 Part 1 | 3편 — DHCP 전쟁 & GitOps | 4편 — Edge AI | 5편 — 데이터 티어링 | 6편 — Failover 실증
🔗 GitHub: Repository | Wiki | 칸반보드 | Docker Hub