← gw

23_골든이미지(원본)위생법

"골든이미지"란 여러 기기에 그대로 복제해서 뿌릴 "원본" 디스크 이미지를 말한다 — 원본이 지저분하면 복제되는 모든 기기가 똑같이 지저분해지므로, 복제하기 전에 원본부터 깨끗하게 청소해두자는 법.

제정: 2026-09-15 (대표 지시: "부팅 전 찌꺼기를 모두 삭제 후 부팅하는 프로세스를 법제화")

제정 배경

lin1용 신규 SSD(20G 부팅 / 150G 임시저장소 / 62.9G 프로그램) 설계 도중, 실제 골든이미지 소스(lin2, "Xubuntu minimal") 루트 파티션을 실측한 결과 30G 중 24G(85%) 이미 사용, 여유 4.3G뿐임이 드러남. 내역:

이 상태 그대로 복제하면 신규 20G 부팅 파티션에 아예 안 들어가는(24G>20G) 사고로 직결됨. 향후 저가 노트북 10대 등 대량 배치([[project_cheap_laptop_collector_fleet]]) 템플릿이 될 이미지이므로, 지금 이 오염을 방치하면 배치되는 모든 기기에 그대로 복제된다.

원칙

골든이미지를 신규 기기에 클론/배포하기 전, 반드시 아래 정리를 소스에서 먼저 수행한 뒤에만 클론한다. ("부팅 전 정리 후 부팅" = 클론 전 정리 후 클론)

1. 불필요 snap 패키지 제거

헤드리스 수집기 역할에 GUI/데스크톱 앱(메신저, 데스크톱 환경 스냅 등)은 불필요 — snap list로 확인 후 역할과 무관한 것 전부 snap remove.

2. 개인 개발 캐시 제거

.cache, .npm, .npm-global, .vscode, Downloads, .codex 등 개발자 개인 홈 디렉토리 잔여물은 골든이미지 계정에 남기지 않는다. 골든이미지 계정에는 순수 OS + raker 실행환경(venv, 스크립트)만 남긴다.

3. 시스템 캐시/로그 정리

4. 정리 후 실측 확인

정리 직후 df -h / + sudo du -h --max-depth=1 /로 실제 축소 확인 — 목표치(정리 후 순수 OS 8~9G대) 도달 확인 없이 "정리했다"고 간주하지 않는다.

5. 골든이미지 승격 조건

위 1~4를 통과한 이미지만 신규 기기 배치용 골든이미지로 승격한다. 대량 배치 착수 전 이 절차가 선행되어야 한다.

적용 범위

다음 조사 과제

제2장 — 4구획 표준 및 명명법 (2026-09-22 제정)

제정 배경: 위 "다음 조사 과제"의 lin2 사후정리를 실제 집행하면서(disk4/120GB USB 대상), 수집결과물(code_staging 13G)이 원인이 되어 부팅파티션을 압박하는 문제와, 수동 설치 프로그램(크롬 등)이 부팅파티션에 누적되는 문제를 동시에 확인 — 이를 표준 절차로 법제화한다.

제8조 (4구획 표준)

① 골든이미지(및 그 클론 대상 디스크)는 반드시 4개 구획으로 나눈다:

구획 풀네임(약어 유래) 용도 원칙
efi Extensible Firmware Interface — UEFI 부팅 표준 규격명 그대로 부팅로더 FAT32, 1GB 내외
boot Boot(부팅) — 줄임 없는 원어 그대로 순수 OS + raker 실행환경 ext4, 최소 크기(제1장 정리 원칙 적용 대상) — 수집결과물·수동설치 프로그램 절대 배치 금지
stn Station(정거장/역) — 모음 생략형 축약. raker 수집물이 잠시 머무르는 "정거장" 개념 수집결과물·임시데이터 ext4, 넉넉한 크기 — code_staging류는 반드시 여기
pro Programs(프로그램들) — 앞 3글자 축약 수동 설치 프로그램 전용 ext4 — /opt 전체를 이 구획으로 심볼릭 링크(제9조)

② 각 구획 크기는 기기 목적에 따라 조정 가능하나, 순서와 역할 분리 원칙은 고정이다.

③ 용량 구간별 표준 사이즈(2026-09-22 확정) — 디스크 전체 용량에 따라 아래 표를 기본값으로 적용하고, 특수 사정이 있을 때만 예외적으로 조정한다:

디스크 전체용량 구간 efi boot stn pro(나머지)
128GB 이하 1GB 16GB 60GB 나머지 전부
275GB 이하(128GB 초과) 1GB 32GB 100GB 나머지 전부

pro는 항상 "efi+boot+stn을 뺀 나머지 전부"로 자동 계산한다 — 별도로 고정치를 정하지 않는다. 275GB를 초과하는 대용량 디스크의 기준은 추후 실사례가 생기면 이 표에 행을 추가한다.

제9조 (/opt 리다이렉트 의무)

① boot 구획에는 OS 패키지(/usr)만 허용하고, 수동 설치 프로그램(크롬, 텔레그램 등 /opt 경유 설치물)은 boot 구획에 실물로 존재해서는 안 된다.

② 이를 위해 /opt 디렉터리 전체를 pro 구획으로 이동 후 심볼릭 링크로 대체한다(mv /opt {pro구획}/opt && ln -s {pro구획}/opt /opt). 이후 설치되는 모든 프로그램은 앱 설정 변경 없이 자동으로 pro 구획에 쌓인다.

③ 동일 원리로, 개별 프로그램의 데이터/캐시 디렉터리(~/.config/xxx 등)가 비대해질 우려가 있으면 해당 디렉터리도 같은 방식(실이동+심볼릭링크)으로 pro 구획으로 리다이렉트할 수 있다.

제10조 (명명 규칙)

① 4개 구획의 파일시스템 라벨은 {호스트명}efi / {호스트명}boot / {호스트명}stn / {호스트명}pro 형식을 따른다 — 예: lin2 기준 lin2efi/lin2boot/lin2stn/lin2pro.

② 라벨 부여는 fatlabel(FAT32 구획)·e2label(ext4 구획)로 실행한다.

③ 이 명명법은 [[24_저장장치명명법]]의 "슬롯 이름"(기계+자리 기준)과는 별개 층위다 — 저장장치명명법은 물리 디스크/베이 식별용, 본 조는 한 디스크 내부의 논리 구획 식별용으로 병행 적용한다.

제11조 (루프마운트 방식의 지위)

기존에 일부 기기(lin2 등)에서 쓰인 "루프마운트 파일로 임시저장소 구현" 방식은 이미 가동 중인 시스템에서 재파티셔닝이 불가능할 때의 부득이한 우회책일 뿐, 신규 구성의 표준이 아니다. 신규 디스크/신규 클론 대상에는 반드시 제8조의 실제 구획 분리를 적용한다.

제12조 (투입 전 파티션 계획 원칙)

① 제8조의 4구획 구성은 반드시 기기 투입(=첫 부팅) 전에 완료한다. OS를 설치하고 한 번이라도 그 디스크로 부팅시킨 뒤에는, 루트파티션이 사용 중 상태가 되어 축소(shrink)가 커널 레벨에서 원천적으로 불가능해진다(ext4는 마운트된 상태에서 확장만 가능하고 축소는 언마운트 상태에서만 가능).

② 따라서 신규 기기(노트북·SSD·USB 등)를 함대에 편입하는 작업을 시작할 때는, OS 설치나 골든이미지 클론 단계로 들어가기 전에 반드시 파티션 계획(제8조 용량구간표 기준)부터 먼저 확정한다 — 사용자가 별도로 요청하지 않아도 먼저 제안한다.

③ 이미 부팅되어 단일 파티션 등 구표준으로 가동 중인 기존 기기는, 라이브 USB로 재부팅한 뒤에만 사후 재구획이 가능하다 — 이 경우 재부팅에 따르는 다운타임·리스크와 재구획의 실익을 비교해, 다음 재설치 시점까지 미루는 것도 유효한 선택지다(강제 사항 아님).

제정 배경(2026-09-22): h61-1을 CPU교체·부팅검증·고정IP 설정까지 마친 뒤에야 4구획 표준이 정립되어, 이미 부팅 중인 h61-1엔 소급 적용이 기술적으로 막힌 사례가 계기. "법이 그때 없었다"는 것과 별개로, OS 설치 전 파티션 계획을 먼저 챙기는 것은 표준 제정 여부와 무관한 기본 절차였어야 한다는 지적에 따름.

제13조 (가동 중 기기의 stn 부분적용 원칙 — 2026-09-23 신설)

① 제12조③에 따라 전체 재구획이 보류된 기존 가동 기기라도, stn(정거장) 역할만큼은 즉시 적용한다 — 루프마운트 파일({호스트명}stn.img)이나 빈 디렉토리를 /stn에 구성해 수집물 저장 경로로 지정하면 되고, efi/boot/pro 전체를 갖출 필요는 없다. 이는 제11조의 "루프마운트=부득이한 우회책" 지위를 유지하는 선에서, 최소 침습으로 표준 명명을 즉시 적용하는 절충안이다.

② 부분적용이라도 명명은 반드시 표준(제10조, {호스트명}stn)을 따른다. 과거 일부 기기(lin2, linux4 등)가 표준 정립 전 /transfer라는 임시 이름을 썼던 것은 레거시 유산으로만 인정하고, 이후 발견되는 모든 기기는 즉시 /stn으로 통일한다.

③ 적용 절차(가동 중 기기 필수 순서): (a) 대상 디렉토리/파일에 활성 프로세스가 물려있는지 확인(lsof +D, ps aux) → (b) 자체 raker 스크립트의 하드코딩된 구경로 검색(grep -rl — 단 수집된 제3자 코드(code_staging 등)는 오탐이므로 자체 스크립트 디렉토리만 대상) → (c) 언마운트·파일명 변경·재마운트· fstab 갱신 → (d) 하드코딩 경로 일괄 치환 → (e) 검증(df -h, 파일 개수/용량 비교로 데이터 유실 없음 확인). 이 순서를 건너뛰면 운영 중 데이터 유실 사고로 이어질 수 있다.

제14조 (완전분할 기기의 라벨-역할 일치 검증 의무 — 2026-09-23 신설)

① 물리적으로 4개 파티션이 모두 분리되어 있고 제10조 명명({호스트명}efi/ boot/pro/stn)까지 적용된 기기라도, 라벨 존재 자체를 표준 준수의 증거로 간주하지 않는다 — 각 파티션의 실제 마운트 지점과 내용물이 제8조가 정의한 역할과 실제로 일치하는지 별도로 검증한다.

② 확인 항목: boot 라벨 파티션이 실제로 OS 전체(+raker 실행환경)를 담고 있는지, 아니면 커널·grub만 담은 전통적 리눅스 /boot에 불과한지 구분한다. pro 라벨 파티션이 실제로 /opt 리다이렉트(제9조) 대상인지, 아니면 그냥 루트(/)가 우연히 그 파티션에 얹혀있을 뿐인지 구분한다.

③ 불일치 발견 시 즉시 대표에게 보고한다. 재설치 없이 교정 가능한 항목(누락된 라벨 보완, 미적용된 /opt 리다이렉트 실행 등)은 바로 처리하되, 이미 가동 중인 루트 파티션 자체를 다른 파티션으로 옮기는 작업은 사실상 재설치급 고위험 작업이므로 제12조③과 동일하게 다음 재설치 시점까지 보류하는 것도 유효한 선택지로 남긴다.

제정 배경(2026-09-23): h61-1·lin2·linux4에 /transfer(레거시)→/stn (표준) 일괄 전환을 실행하며 제13조가 확립됐다. 동시에 sam1을 점검하는 과정에서 sam1boot/sam1pro 라벨이 실제로는 각각 "커널만 담은 전통적 /boot"와 "OS 전체가 얹힌 루트"로 뒤바뀌어 있음을 발견 — "라벨이 표준 형식이면 역할도 표준대로일 것"이라고 오판할 뻔한 사례가 제14조 제정 계기.

적용 사례