The Operations Loop — 서버의 시작을 운영의 완성으로
AI_Manager
서버를 설치하는 일에서, 운영할 수 있는 상태를 증명하는 일까지. 자산 정보와 표준 구성, 모니터링을 하나의 흐름으로 연결하는 인프라 프로젝트다.
이 글의 순서설계·기본 VM 검증 기록 | 2026년 9월 20일 정리
Rocky Linux 10.2 기본 VM의 부팅·SSH·보안·시간 동기화를 확인했다. 여섯 VM의 서비스 배치와 운영 자동화는 설계 단계다. 아키텍처는 설계 설명용이며 실제 시스템의 상태를 표시하지 않는다. 서비스 통합, HA 전환, 폐쇄망 재현을 완료한 성과로 제시하지 않는다.
- 프로젝트 개요
- 1. 운영 과정에서 해결하려는 문제
- 2. VirtualBox에서 재현할 아키텍처
- 3. 서버 한 대가 운영에 합류하는 여섯 단계
- 4. 설계에서 중요하게 다룬 선택
- 5. 실제 확인한 결과와 증거
- 6. 다음 구현의 합격 기준
- 7. 온라인망과 폐쇄망을 같은 기준으로 구축하기
- 8. 함께 읽는 구축·검증 기록
프로젝트 개요
신규 서버를 만든 뒤 운영에 투입하려면 여러 질문에 답해야 한다. 승인된 IP와 역할이 맞는가. 관리 계정과 SSH 정책은 기준을 따르는가. 모니터링에 등록만 된 것은 아닌가. 실제 값이 수집되는가. 일부 작업이 실패했을 때 어디부터 다시 시작할 수 있는가.
The Operations Loop는 이 질문을 하나의 운영 편입 절차로 묶는다. NetBox에 승인된 기준을 두고, Ansible AWX로 표준 설정을 적용하며, Zabbix의 실제 데이터 수신으로 완료를 판정하는 구조를 설계했다. Oracle VirtualBox 실습망에서 온라인 환경과 외부 연결이 없는 환경을 같은 기준으로 비교한다.
| 항목 | 내용 |
|---|---|
| 분야 | Linux 시스템 운영, 서버 표준화, 자산·구성 관리, 모니터링 |
| 기반 | Oracle VirtualBox 7.2.18 / Rocky Linux 10.2 x86_64 Minimal |
| 설계 구성 | NetBox, AWX, Ansible, 연동 Worker, Zabbix Server·Proxy·Agent 2 |
| 네트워크 | 중앙 관리망과 원격 서버망, 승인된 SSH 중계 경로 |
| 직접 확인한 범위 | PC 자원, 설치 원본, 기본 VM, 보안 설정, 서비스와 시간 동기화 |
| 구현 전 범위 | 역할별 VM 배치, 서비스 연동, 장애 주입, 오프라인 재설치 |
| 산출물 | 설계도, 자원·통신 표, 구축 가이드, 검증 기록, VM 오류 분석 |
실제 PC 조건에서 출발한 설계
2026년 9월 19일 조사한 호스트는 ASUS Zenbook Duo, Intel Core Ultra 9 185H(16코어·22스레드), 32GB 메모리, Windows 11 Pro, 2TB NVMe SSD다. OS에서 확인한 사용 가능 메모리는 31.4GiB, 조사 시점의 여유 메모리는 17.8GiB였다. C 드라이브의 여유 공간은 1612.3GiB였다. 이 값은 측정 당시의 상태이며 VM을 모두 실행하기 전 다시 점검한다.
기본 VM에는 1 vCPU와 3GiB RAM, 동적 할당 64GiB 디스크를 사용했다. 역할별 VM은 합계 13.5GiB RAM으로 계획했지만, AWX와 NetBox를 함께 올리는 노드의 사용량은 아직 측정하지 않았다. 메모리 사용량·스왑·OOM·작업 지연을 확인한 뒤 배치를 확정하는 시작 예산이다. 스냅샷과 이미지 저장 공간도 별도로 관리한다.
1. 운영 과정에서 해결하려는 문제
기준 정보와 실제 상태가 달라지는 문제. 자산 대장과 서버의 IP·호스트명·역할이 다르면 변경 작업의 출발점부터 불확실해진다. 승인 정보와 관측 정보를 따로 보관하고, 차이가 있으면 운영 편입을 중단하도록 설계했다.
반복 설정이 사람마다 달라지는 문제. 운영 계정, SSH, 시간 동기화, 방화벽, 모니터링 Agent를 역할별 코드로 관리한다. 같은 기준을 다시 적용했을 때 불필요한 변경이 없어야 한다는 조건을 시험에 포함했다.
등록 성공을 운영 준비 완료로 오해하는 문제. API에서 호스트가 생성되어도 수집 경로나 Agent 설정이 잘못되면 데이터가 오지 않는다. 등록과 수집 확인을 별도 단계로 나누고 필수 항목의 최신 값까지 확인하도록 정했다.
실패 후 전체 작업을 반복하는 문제. 응답 유실과 중복 이벤트를 고려해 작업 식별자, 마지막 성공 단계, 실제 생성 여부를 기록한다. 재설치는 일반 설정 재적용과 다른 승인·재시도 절차를 갖는다.
2. VirtualBox에서 재현할 아키텍처
중앙 관리망은 fml-core(10.77.10.0/24), 원격 서버망은 fml-remote(10.77.20.0/24)라는 서로 다른 Internal Network로 구성한다. 라우팅과 ACL은 fml-router가 맡는다. 온라인 실습에서는 라우터만 외부 NAT 연결을 사용하고, 폐쇄망 실습에서는 그 연결을 제거한다. Oracle 공식 네트워크 문서
| VM / 계획 주소 | vCPU / RAM | 배치할 역할 |
|---|---|---|
| fml-router / 10.77.10.1 · 10.77.20.1 | 1 / 1GiB | 라우팅·접근 통제, 외부 연결, 내부 DNS·NTP 제공 검토 |
| fml-core01 / 10.77.10.11 | 4 / 6GiB | NetBox와 전용 DB·Redis, AWX/K3s, Zabbix Server 1 |
| fml-core02 / 10.77.10.12 | 2 / 2GiB | 연동 Worker와 작업 기록, Ansible CLI, Zabbix Server 2 |
| fml-monitor / 10.77.10.20 | 2 / 2GiB | Zabbix 공통 PostgreSQL·Web/API |
| fml-remote / 10.77.20.10 | 1 / 1.5GiB | SSH Bastion·Zabbix Proxy·Proxy 로컬 DB |
| fml-target01 / 10.77.20.101 | 2 / 1GiB | 관리 대상 Linux·Zabbix Agent 2 |
이 표는 구현할 배치다. 현재 확인한 VM은 별도의 fml-template-rocky10.2 한 대다. 다중 vCPU 부팅은 추가 확인이 필요하다. 관리용 Host-only를 쓸 때는 라우터의 관리 인터페이스로 제한하고 대상 서버에 우회 NIC를 붙이지 않는다.
경로마다 다른 목적을 갖는다
기준 정보: NetBox → 연동 Worker → AWX 작업 실행
표준 구성: AWX 실행 환경 → SSH Bastion → 대상 Linux
등록 요청: 연동 Worker → Zabbix Web/API
데이터 수집: 대상 Agent → 원격 Proxy → Zabbix Server → 공통 DB
Core 1 중단 → NetBox·AWX도 영향받음
Zabbix Server 역할 전환 → Core 2와 공통 DB가 정상일 때 별도 검증
원격 겸용 VM 중단 → SSH 중계와 Proxy 수집이 함께 중단NetBox의 DB·Redis·백그라운드 Worker, AWX의 Kubernetes·DB·영속 볼륨, Proxy의 로컬 저장소는 필수 의존성이다. Zabbix Web/API는 수집용 TCP 10051 서비스와 구분한다. SSH Bastion에서는 AWX 작업을 실행하지 않으며 중앙 실행 환경의 접속을 중계한다. NetBox 설치 구성, AWX Operator 설치
인터랙티브 아키텍처 — 경로와 장애 범위
3. 서버 한 대가 운영에 합류하는 여섯 단계
| 단계 | 수행 내용 | 다음 단계로 넘어가는 조건 |
|---|---|---|
| 1. 자산 등록·승인 | VM 식별자, 역할, IP, 구성 버전을 NetBox에 등록 | 필수 정보와 배포 승인 확인 |
| 2. 배포 준비 | OS와 초기 접속 준비, MAC·machine-id·SSH 호스트 키 구분 | 올바른 대상에 승인된 키로 접속 |
| 3. 표준 구성 | 계정·SSH·NTP·방화벽·Agent를 Ansible로 적용 | 작업 성공과 새 접속·서비스 정상 확인 |
| 4. 실제 상태 대조 | 관측한 OS·IP·호스트명을 승인 정보와 비교 | 불일치가 없거나 승인된 예외로 설명 가능 |
| 5. 모니터링 등록 | 기존 호스트 조회 후 그룹·템플릿·Proxy 연결 | 중복 없이 의도한 호스트가 존재 |
| 6. 수집 확인 | 필수 항목의 값과 시각, 오류 상태를 확인 | 신선한 데이터 수신 후 운영 전환 |
NetBox 이벤트는 작업의 시작 신호다. 이벤트 자체가 서버를 구성하는 것은 아니므로 승인 확인과 대상 검증은 별도 Worker의 책임이다. 같은 이벤트가 다시 오면 자산 ID와 구성 버전으로 기존 작업을 확인한다. API가 타임아웃 나더라도 생성 요청을 바로 반복하지 않고 서버 측 결과를 재조회한다. NetBox Webhook
작업 기록에는 작업 ID, 자산 ID, 코드 버전, 시작·종료 시각, 마지막 성공 단계, 실패 사유를 남긴다. 완료 상태는 프로젝트의 업무 상태이며 제품의 기본 상태값으로 가정하지 않는다. 플레이북, Worker 코드, 실제 작업 실행은 아직 구현·검증 전이다.
4. 설계에서 중요하게 다룬 선택
승인한 기준과 관측한 값을 분리했다
수집된 값으로 자산 정보를 자동 덮어쓰면 잘못된 설정이 새 기준이 될 수 있다. 따라서 둘을 비교하고 차이를 검토하는 방식을 선택했다. 대상 식별이 틀리면 자동화가 성공해도 잘못된 서버에 작업한 것이므로 설치 전·후의 식별 검증을 모두 둔다.
자원을 줄인 배치의 장애 범위도 함께 설명했다
원격 VM 하나에 Bastion과 Proxy를 함께 두면 자원을 줄일 수 있다. 대신 VM 장애 한 번으로 SSH 관리와 모니터링 전달이 동시에 멈춘다. 대상 서비스가 살아 있는지, 관리 경로가 살아 있는지, 수집이 진행되는지를 각각 확인하도록 시험을 나눴다.
Zabbix Server HA와 전체 서비스 가용성을 구분했다
두 Server는 동일 DB를 사용한다. 공통 DB를 Core 1과 다른 VM에 둬 Core 1 장애와 DB 장애를 분리했다. 다만 DB·Web/API 자체는 단일 구성이다. Native HA가 Server 역할을 전환하더라도 NetBox·AWX·DB·물리 호스트까지 이중화되는 것은 아니다. Zabbix Native HA
통신 단절과 Proxy 자체 장애를 따로 시험한다
통신 경로가 끊겨도 Proxy와 로컬 DB가 살아 있으면 설정된 보관 범위에서 데이터를 저장할 수 있다. Proxy VM이 중단되면 이 조건이 사라진다. 버퍼 설정, 단절 시간, 실제 수집 시각과 중앙 반영 시각을 함께 기록해야 복구를 설명할 수 있다. Zabbix Proxy
5. 실제 확인한 결과와 증거
기본 VM 검증은 2026년 9월 19일 23:24 KST에 실행했다. 근거는 base-validation.txt, VM 구성 기록과 스냅샷 기록이다. 단순 종료 코드만 읽지 않고 각 출력값을 기준과 대조했다.
| 확인 항목 | 기록된 결과 | 해석 |
|---|---|---|
| OS·커널 | Rocky 10.2 / 6.12.0-211.16.1.el10_2.0.1.x86_64 | 사용한 환경 식별 가능 |
| 원격 접속 | 실습 전용 공개키로 SSH, 종료 코드 0 | 현재 템플릿에 새 세션 접속 가능 |
| 보안 상태 | SELinux Enforcing / firewalld running | 기본 보호 기능 활성 |
| SSH 정책 | root 직접 로그인 금지, 암호·키보드 인증 금지 | 설정 출력으로 확인; 부정 접속 시험은 별도 |
| 서비스 | sshd·chronyd·firewalld active | 점검 시점 정상 |
| 시간 | Asia/Seoul / NTPSynchronized=yes | 동기화 상태 확인; 정밀 오차 측정은 별도 |
| 기반 저장 | 정상 종료 후 base-rocky10.2-20260919 스냅샷 | 기준점 보존; 복원 성공을 뜻하지 않음 |
설치 과정에서 VirtualBox 드라이버 설치, 이전 프로세스와의 충돌, UEFI·설치 미디어, vCPU, Kickstart 후처리 문제를 조사했다. 현재 VM은 복구 후 검증한 기준선이다. 수정한 Kickstart로 빈 디스크부터 다시 설치하는 시험은 남아 있다. 다중 vCPU 정체의 근본 원인도 확정하지 않았다. 상세 내용은 별도 VM 오류 아티클에 기록했다.
구축 전후 시간 단축률, 가용성, 무중단 전환, 데이터 무손실은 측정하지 않았으므로 성과 수치로 넣지 않았다. 현재 설명할 수 있는 성과는 조건에 맞춘 설계, 기본 VM 복구와 검증, 실패를 증거와 함께 남긴 운영 기록이다.
6. 다음 구현의 합격 기준
| 검증 | 합격 기준 | 현재 상태 |
|---|---|---|
| 기본 VM | 부팅·새 SSH 접속·필수 서비스·보안 기준 확인 | 확인 완료 |
| 신규 설치 재현 | 수정 Kickstart로 별도 빈 VM 설치 후 같은 기준 통과 | 미실행 |
| 접근 통제 | 중앙→대상 직접 SSH 실패, Bastion 경유 성공 | 미실행 |
| 신규 서버 편입 | 승인 정보 일치와 필수 모니터링 데이터 수신 | 미실행 |
| 재실행·중복 이벤트 | 불필요한 변경·중복 호스트 없이 같은 결과 | 미실행 |
| Server 장애 | 공통 DB 정상 조건에서 역할 전환·수집 복구 | 미실행 |
| 폐쇄망 재현 | 외부 연결·기존 캐시 없이 내부 공급원만으로 설치 | 미실행 |
| 복원 | 별도 VM에서 데이터·설정·비밀키 복구 후 기능 확인 | 미실행 |
상세 검증 글에는 시험의 전제, 수행 방법, 기대값, 판정과 증거를 묶었다. ‘계획’, ‘실행했지만 기준 미달’, ‘증거로 확인’ 상태를 섞지 않는다. 한 물리 PC에 모든 VM이 있으므로 이 시험을 물리 호스트 장애까지 견디는 운영 환경의 가용성으로 확대하지 않는다.
7. 온라인망과 폐쇄망을 같은 기준으로 구축하기
온라인망에서 구성 시
공식 공급원의 설치 파일과 저장소를 사용하되 OS·RPM·Python 패키지·이미지·Ansible Collection·Git commit을 기록한다. 외부 연결은 라우터를 통하고 대상 서버에 별도 NAT NIC를 붙이지 않는다. 등록과 수집을 모두 확인하고 사용한 자료를 재현 가능한 설치 묶음으로 보관한다.
폐쇄망에서 구성 시
같은 버전의 설치 묶음을 검증해 반입한다. RPM 외에도 NetBox의 Python 의존성, K3s와 AWX의 이미지, 실행 환경, Collection, 프로젝트 소스를 포함한다. 내부 DNS·NTP·CA·저장소를 준비하고 외부 NAT·브리지·프록시 경로가 없는 상태에서 새 VM으로 재현한다. K3s 실행 파일과 air-gap 이미지 묶음은 같은 버전을 사용한다. K3s 폐쇄망 설치
두 환경의 성공 기준은 같다. 승인된 설정이 적용되고 실제 데이터가 수신되어야 한다. 차이는 소프트웨어와 업데이트의 공급 경로다. 이 실습의 폐쇄망은 논리적 격리이며 인터넷에 연결된 호스트까지 물리적으로 분리한 환경을 뜻하지 않는다.
8. 함께 읽는 구축·검증 기록
| 글 | 읽는 목적 |
|---|---|
| Rocky Linux 운영 실습망 구축 가이드 — 온라인망과 폐쇄망을 같은 기준으로 | 준비물, VM·망 구성, 설치 순서, 의존성 반입과 복구 절차 |
| 설치 성공에서 운영 준비까지 — Rocky Linux 검증 기록과 통합 시험 기준 | 실제 기본 VM 결과와 통합·장애·폐쇄망 시험의 합격 기준 |
| Rocky Linux 10.2 VM 구축기 — 설치를 막은 다섯 가지 오류와 진단 기록 | VM 구성 과정의 실제 오류, 조치와 확인 결과 |
이 프로젝트에서 보여주려는 운영 역량은 어떤 상태를 정상이라고 판단했는지, 실패가 어느 범위에 영향을 주는지, 다시 실행하고 복구할 수 있는지를 설명하는 것이다. 현재 기준선과 미검증 범위를 함께 남겨 이후 구축 결과도 같은 기준으로 이어갈 수 있도록 했다.