하드웨어운용법 — 헌법 제9조 시행법

근거: CONSTITUTION.cst.md 제9조(상시 감시와 즉각 대응 의무) 소관: 물리 하드웨어 설치·전원제어·장애 대응 실무 절차 관계: 14_하드웨어경제성법.law.md(무엇을 살지)와 짝을 이루는 조항 — 이 법은 산 하드웨어를 어떻게 다루는지를 다룬다.

제1조 (전원 제어 — IPMI 우선 원칙)

① WoL(Wake-on-LAN)이 구조적으로 안 되는 기기(USB 동글 등 하드웨어 한계)는 IPMI를 표준 전원 제어 수단으로 삼는다(linux2 실증 사례, linux2_하드웨어_온오프와_구성.md §7-5).

② 원격 전원 제어 결과는 명령 전송 직후 곧바로 상태를 단정하지 않는다 — chassis power status로 실제 상태 변화를 재확인할 때까지 몇 초의 지연이 있을 수 있다(2026-09-10 실증: 명령 직후 조회에선 이전 상태로 보였다가, 수 초 뒤 재조회 시 반영 확인).

③ 정상 종료가 가능하면(SSH 응답) graceful shutdown을 우선하고, SSH가 죽어있으면 IPMI chassis power soft(ACPI 신호)를 먼저 시도, 그래도 안 꺼지면 chassis power off(강제)를 쓴다.

제2조 (쿨러 장착 — 균등 압력 원칙)

① CPU 쿨러는 대각선 순서로 나사를 조금씩 번갈아 조여서 4면이 고르게 눌리도록 장착한다(자동차 바퀴너트 조임과 동일 원리). 한쪽만 먼저 다 조이면 CPU가 소켓에 비스듬히 눌려 완전히 접촉하지 못한다.

② 쿨러 불균등 장착은 POST 완전 실패(모니터 무신호, USB 무반응)의 흔한 원인이다 — CPU가 인식조차 안 되는 증상이 나오면, 전원/RAM보다 먼저 쿨러 장착 상태(서멀구리스 자국이 한쪽만 눌렸는지)부터 확인한다 (2026-09-10 lin2 실증 사례).

제3조 (장기 미사용 부품 검증 절차)

① 오래 방치된 PSU는 전해캐패시터 열화 위험이 있어, 보드에 바로 연결하지 않고 단독 기동 테스트(24핀 커넥터 PS_ON~GND 점퍼)부터 거친다. 가능하면 PSU 테스터기로 전압 레일(+12V/+5V/+3.3V)을 확인한다.

①-1 🔴 노후 PSU 화재 위험 격리 원칙(2026-09-19 확정): 연식이 오래된 PSU(대략 10년 이상)는 실내가 아닌 화재 위험이 없는 외부 공간(테라스 등) 에서만 기동·테스트한다. 실증 계기: 15년 된 삼성/FSP OEM PSU(ATX-350SEC) 테스트 중 실제로 타는 냄새("신발 타는 냄새") 발생 — 먼지 발화든 내부 부품 손상이든 원인 불문, 오래된 PSU는 정상 가동 여부를 확인하기 전까지 발화 가능성이 있는 물건으로 취급한다. 타는 냄새·연기·비정상 소음 발생 시 즉시 콘센트에서 전원 코드를 뽑고, 재시도 없이 즉시 폐기한다 (전자폐기물로 처리, 일반쓰레기 금지). 이 원칙은 제14_하드웨어경제성법 제11조(PSU 연식 상한 원칙)의 구매 단계 예방 조치와 짝을 이루는 사용(테스트) 단계 안전 조치다.

② 오래 방치된 시스템을 재부팅할 때 CMOS 초기화(점퍼 또는 배터리 재장착)를 1순위 점검 항목으로 삼는다 — 방전된 배터리·깨진 설정값이 부팅 실패의 흔한 원인이다.

제4조 (POST 실패 진단 순서)

전원은 들어오는데(팬 회전 등) 화면·USB 반응이 없을 때, 다음 순서로 원인을 좁힌다:

1. CMOS 초기화
2. 모니터 케이블이 올바른 출력 포트(온보드 VGA 등)에 꽂혀있는지 확인
3. CPU 소켓 핀 육안 점검(휘거나 눌린 핀)
4. 쿨러 장착 균등성 확인(제2조)
5. 🔴 CPU_FAN 헤더에 팬 케이블이 실제로 꽂혀있는지 육안 확인(2026-09-17 실증 신설) — CPU+쿨러가 이미 조립된 채로 다른 보드에 옮겨진 경우 특히 놓치기 쉽다. 안 꽂혀있으면 화면·랜선·USB 인식이 전부 안 되는, 이 조 ①~④와 동일한 증상으로 나타나 "보드 고장"으로 오판하기 쉬움(cpu_fan_케이블_재연결_누락이_보드고장으로_오판되는_함정.md 참고)
6. 최소구성(CPU1+RAM 1개)으로 축소 테스트

제5조 (원격 네트워크 상태 판단 원칙)

① 링크(연결) LED가 켜져 있어도 깜빡이지 않으면(활동 없음) OS가 아직 네트워크 스택을 못 띄운 것으로 본다 — 케이블·스위치 문제가 아니라 부팅 단계 문제일 가능성이 높다.

② ping/SSH 무응답이 오래 지속되면, blind로 재시도만 반복하지 말고 모니터를 직접 연결해 화면을 확인하는 단계로 전환한다 — 원격 진단에는 한계가 있다.

③ "고정 IP"도 재할당될 수 있음을 전제한다 — 대장·SSH config상 정적으로 기록돼 있어도, 재설치·리셋 등을 거치며 실제 임대 IP가 바뀌는 사례가 있다 (2026-09-11 linux2 실증: 대장상 172.30.1.152 고정이었으나 실제로는 다른 IP로 재할당됨). ping/SSH 무응답을 곧바로 "전원 꺼짐"으로 단정하지 않는다 — 먼저 IP 변경 여부부터 의심한다.

④ IP 변경이 의심되면, 서브넷 전체 ping sweep으로 살아있는 미확인 IP를 모두 뽑은 뒤, SSH 배너(nc -w2 $ip 22 → OpenSSH 버전으로 OS·재설치 여부 유추)와 MAC OUI(arp -a)로 교차 식별한다. 식별되면 즉시 ~/.ssh/config와 해당 기기 프로필(_gw/_machines/*.md)의 IP를 갱신한다.

⑤ IPMI/BMC는 호스트 OS와 별도의 독립 IP·NIC를 가지며, 호스트 전원 상태와 무관하게(PSU 대기전원만 있으면) 항상 응답한다 — 대개 경량 SSH 서버(dropbear) 배너로 식별 가능하다. 호스트 IP가 불명확할 때는 BMC IP를 먼저 찾아 전원 상태부터 확인하는 쪽이 더 빠르다. BMC IP는 호스트 IP와 인접한 값으로 할당되는 경우가 많다(2026-09-11 linux2 실증: 호스트 구 IP .152 옆 .151이 BMC로 확인됨).

⑥ "고정 IP"로 배정하려는 주소가 이미 다른 기기에 점거돼 있을 수 있다 — 신규 기기에 고정 IP를 배정하기 전, 먼저 그 주소가 비어있는지 ping/ARP로 확인한다. 이미 점거돼 있다면(우리 기기가 아닌 미상의 기기가 응답) 억지로 그 주소를 쓰지 말고 다른 빈 주소로 대신 배정한다 — 충돌 시 두 기기가 번갈아 응답하며 간헐적 접속 실패·SSH 호스트키 경고(제5조③)처럼 원인 파악이 매우 어려운 증상으로 나타난다. 실증 사례(2026-09-11): lin1을 .51로 배정하려 했으나 이미 미상 기기(MAC c0:cb:38:25:e7:31, 우리 키로 인증 불가 — 우리 기기가 아님)가 점거 중이어서 .50으로 대신 배정했다. 같은 세션 중 ".51은 lin1"이라는 착오가 한때 있었는데, 이 점거 사실이 뒤늦게 확인되며 정정됐다 — _gw/_machines/lin1.md 참조.

제6조 (하드웨어 고유명·이력 관리 — 전 부품 필수) 🔴

① 모든 물리 하드웨어(디스크·CPU·RAM·보드·쿨러·PSU 등 개별 식별 가능한 부품 전부)는 고유명을 부여받는다. 명명 규칙은 기존 DISK_LEDGER.md의 원칙을 전 부품 종류로 확장한다:

{제조사약어 2글자}{용량/규격 표시}{일련번호}

예: sa250g2(Samsung 250G #2), to16t3(Toshiba 16T #3). 제조사약어는 DISK_LEDGER.md의 약어표를 그대로 따르며, 새 제조사는 그 표에 먼저 등록한다.

①-1 부팅 SSD 슬롯명 특칙: 부팅용 슬롯은 {기계}{종류기호}{번호} 일반 규칙(예: l1p1, l1s1)의 번호·약어 축약을 따르지 않고, {서버명 약어}boot로 전체 단어를 명시한다(예: l1boot, l2boot2). 여기서 서버명 약어 자체는 "약어 한 글자(계열명) + 일련번호"를 결합해 만든다 — 예: l(linux 계열)+1(1호기)=l1, l+2=l2, w(win 계열)+1=w1, mb(맥북)+1=mb1, m(맥미니)+1=m1. 이 기계 축약 원칙은 DISK_LEDGER.md의 "기계 축약 표"를 그대로 따른다. 목적은 축약형 b1이 다른 슬롯과 혼동돼 실수로 부팅 드라이브를 포맷·초기화하는 사고를 막기 위함이다(2026-09-10, l1b1/l2b1 → l1boot/l2boot2 전면 개명 확정 — 대표 지시: "그렇게 해놓아야 부팅 SSD를 포맷하지 않을 듯함").

② 고유명은 영구불변이다 — 역할이 바뀌거나 다른 기계로 옮겨져도 고유명은 그 물건을 평생 따라간다. 배치될 때 부여되는 역할명(슬롯명, 예: l2boot2, l1p1)은 별도로 병기하되, 고유명을 절대 지우거나 대체하지 않는다. 역할은 바뀌지만 물건의 정체성은 안 바뀌기 때문이다.

③ 고유명 등록 시 다음을 함께 기록한다: - 제조사·모델명·시리얼 - 구입일·구입가격 - SMART 분석 결과 + 그 외 가용한 건강성 진단 기법(배드섹터, 전원사이클 수, 온도 이력 등) — 정기적으로 재검사해 품질 등급을 갱신 기록한다.

④ 배치 원칙: 어떤 기계에 실제로 장착·배치하기 전에, 먼저 전체 배치표(storage_map.tsv 또는 동급 문서)에 고유명·배치 예정 위치를 등록한 뒤에 물리 배치한다 — 등록 없이 먼저 꽂고 나중에 기록하는 순서를 금지한다.

⑤ 이동 이력 기록 의무 — 하드웨어가 배치되거나, 역할이 바뀌거나, 다른 기계로 이전될 때마다, 그 시점·이전 위치·이후 위치·사유를 이력으로 누적 기록한다. 이력은 지우지 않고 계속 쌓는다.

⑥ 역할 적합성 평가 기록 — 각 하드웨어가 특정 역할에서 실제로 어땠는지 (안정성, 속도, 사용 연한 대비 상태)를 평가해 기록지로 남긴다. 이는 향후 재배치·교체 판단의 근거 자산이 된다 — 예: "이 SSD는 정거장(s) 역할보다 프로그래밍(p) 역할에서 더 안정적이었다"는 식의 실전 데이터를 축적한다.

⑦ 시행 문서: 이 조항의 실무 구현은 _wiki/_knowhow/_format/DISK_LEDGER.md (및 저장장치 외 부품으로 확장 시 동급 대장 문서)를 따른다. 위 ③⑤⑥에서 요구하는 필드(구입가격·SMART이력·이동이력·적합성평가)가 현재 대장 문서에 없으면, 문서 갱신을 통해 필드를 추가한다 — 이 조항 자체가 소급 적용된다.

제7조 (서버(기계) 네이밍 원칙) 🔴

① 모든 서버·기계는 자신의 특성(OS·브랜드·규모 등)에 맞춘 약어를 하달받고, 그 뒤에 일련번호를 하달받는다 — {특성약어}{일련번호}. 같은 특성이라도 규모(대형/소형)가 다르면 약어 자체를 다르게 부여해 혼동을 막는다(대형 linux 서버 l과 소형 linux 수집기 lin을 의도적으로 다른 길이로 분리한 사례가 대표적).

①-2 칩셋 등급별 데스크톱 계열 배정 원칙(2026-09-17 확정) 🔴: 노트북을 제외한 데스크톱 기계는, 탑재된 메인보드 칩셋 등급에 따라 아래 4개 계열 중 하나로 배정된다. 같은 물리 기계라도 보드/CPU 교체로 등급이 바뀌면 계열도 재배정된다(제6조②의 "부품 고유명 영구불변" 원칙과는 별개 — 여기서 배정 대상은 부품이 아니라 기계 전체의 등급이다):

승격/강등은 실제 하드웨어 변경(CPU·보드 교체 등)이 확인된 시점에만 적용한다 — 계획 단계에서 미리 개명하지 않는다.

칩셋 4계열 비교표(2026-09-17 확정 근거) 🔴:

계열 배정 판단 근거 3가지: 1. 소켓이 세대를 가른다 — H61/H77은 LGA1155 한 묶음(h계열), H81은 LGA1150로 한 세대 위(lin계열), H110은 LGA1151로 또 한 세대 위(linux계열) — 계열 경계가 소켓 경계와 정확히 일치한다. 2. DDR3→DDR4 전환점이 H110이다 — H81까지는 전부 DDR3(가격 안정, 8GB 약 18,000원대), H110부터 DDR4(2025-2026 품귀로 8GB도 80,000원대) — ComFit이 "DDR3 라인 우선, H110/CF40은 후순위 보류"로 결정한 근거와 동일. 3. 🔴 H110은 Xeon 공식지원이 아예 없다 — H81(v1~v3는 공식목록에 있음)과 달리, H110/B150은 6~7세대 Xeon이 제조사 공식 CPU 리스트에서 완전히 빠져있어 BIOS 모딩 없이는 부팅이 불확실하다(xeon_e3_v5v6_h110_official_unsupported_needs_bios_mod.md, 검증 미완료). 새 linux2(구 lin1, ECS H110M4-C3V 보드)에 계획된 E3-1245v6 장착도 이 리스크를 그대로 안고 있다 — 현재 장착 보류 상태(정거장 안정화 대기)인 것과 별개로, 실제 장착 전 이 리스크부터 검증 필요. 4. 🔴 B75 편입 확정(2026-09-17) — "대량 중고공급" 기준: 같은 LGA1155 세대 안에서도 H77은 개인 DIY용 중급 소비자 칩셋이라 소량 유통됐고, B75는 기업/관공서 대량조달용(Intel Small Business Advantage 탑재가 그 증거)이라 H81처럼 10년 뒤 지금 중고시장에 대량으로 풀린다 — 실제 알리익스프레스 시세로도 H77 정품(Gigabyte GA-H77M-D3H) $60·누적 235건 vs B75 무명보드 $24.64·132건 판매로 공급량·가격 차이 실증됨. h계열의 "저가 대량조달" 취지엔 H61+B75 조합이 H77보다 더 부합 — H77도 계열엔 유지하되(소켓 동일), 실제 대량 확보 타겟은 H61/B75 우선.

② 현재 확정된 전 함대 명명표(2026-09-17 재편성 반영):

③ 신규 기계 편입 시 이 표에 먼저 등록한 뒤 약어를 확정한다 — 등록 없이 임의 약어를 쓰면 시행령 경미한 위반 대상(01_위반처리시행령.dec.md 제1조 준용).

④ 노트북 계열 명명 원칙(2026-09-17 확정) 🔴: 노트북은 ①-2의 칩셋 등급 축에 편입되지 않고, 제조사/모델 기반 고유 계열명을 쓴다 (기기코드=약어 동일, {계열약어}{일련번호}):

노트북은 브랜드가 바뀌지 않는 한 계열도 영구적이다(데스크톱처럼 칩셋 교체로 계열이 바뀌는 ①-2 원칙은 적용되지 않음 — 노트북은 통상 보드 교체가 불가능하므로).

제8조 (하드웨어 분류 체계 — 2개 축) 🔴

모든 하드웨어는 이동성 패턴과 역할 두 축으로 동시에 분류된다.

8-1. 이동성 패턴 분류 (기존 02_보안기밀법.law.md 분류를 전 하드웨어로 승격)

🔴 이동형 백업 원칙(2026-09-10 신설): 이동형 기기는 분실 위험이 상존한다는 전제를 항상 깔고 운영한다. - 완전 백업을 원칙으로 한다(전체 데이터의 별도 사본 보유). - 매일 증분 백업을 수행한다(그날그날의 변경분만 추가로 누적). - 이 원칙은 02_보안기밀법.law.md의 "이동형=secret 절대 보관 금지" 원칙과 별개로, secret 여부와 무관하게 이동형 전체에 적용된다.

8-2. 역할 분류 (2026-09-10 확정)

🟡 03_함대동기화법.law.md 제5조와의 관계 — 여전히 확인 필요: 기존 역할형 4종(프로그램형·수집형·연산형·데이터서비스형) 중 수집형·연산형은 명칭이 겹치는데 정의가 동일한지, 그리고 프로그램형·데이터서비스형이 이번 분류에서 빠진 이유(폐지? 별도 축으로 유지?)를 확정해야 한다. 확정되는 대로 두 조항을 정합화한다.

8-3. 함대 서사적 별칭(2026-09-11 확정) 🔴

공식 역할형 분류(8-2)와 별개로, 조직 내부 사기·직관적 이해를 위해 각 기기에 함대(해군) 은유 별칭을 부여한다 — 헌법 제5조 "무기 창고" 은유(_ 접두 폴더 = 코드/도구)를 기기 단위로 확장한 것이다. 공식 역할형을 대체하지 않고 병기한다.

①-2 이 별칭은 _gw/_machines/{기기코드}.md "역할명" 항목에 공식 역할형과 함께 병기한다(제9조②2호와 연동) — 예: "역할명: 프로그램형(거점형) — 별칭 거점형 본부 겸 무기개발기".

①-3 별칭이 실제 운영상 새 의무를 만드는지는 별도 확인 대상이다 — 예: "w1이 본부 백업장치"라는 별칭이 실제 백업 파이프라인 구축을 요구하는지는 이 조항만으로 자동 확정되지 않으며, 대표의 별도 지시가 있을 때 구체

①-4 🔴 본부/부본부/개발기도 수집에 참여함(2026-09-13 확정): 위 표의 "대응 공식 역할형"은 각 기기의 주(主) 기능을 나타낼 뿐, m1(본부)· w1(부본부)·mb1(개발기) 전부 부수적으로 raker 수집 업무에도 참여한다 — 본부·부본부·개발기 지정이 "수집 업무 면제"를 뜻하지 않는다. 절차를 정한다.

①-5 🔴 "H61 부대"(저가 특수팀, 대표 창설, 2026-09-15) — "의병" 성격: lin1/lin2(소형함) 편제 안의 하위 서브 별칭 — 여기저기 구매하다 남은 유휴 CPU·결함 보드(VGA 출력 불량 등, 헤드리스라 무관)로 대당 3만원대에 조립하는 H61 저가 수집기 묶음([[구매기록]] "H61 저가 수집기 라인" 참조, 4대 편성). 대표 표현: "일종의 의병 같은 역할" — 정규 편성(lin1/lin2 표준 구매·배치)과 달리, 흩어져 있던 잡다한 유휴 자원을 그러모아 즉석 편성한 비정규 전력. 정규 소형함 대비 부품 출처가 잡다하고 개별 스펙이 들쭉날쭉하다는 점이 특징 — 성능보다 "유휴자원 재활용을 통한 최저원가 편성"이 존재 이유인 특수 편제.

①-6 H61 부대 개별 기체 명명(대표, 2026-09-15; 2026-09-17 H77 편입 확정): lin*/linux*와 구분되는 전용 접두사 h1/h2/h3/h4 사용(현재 4대 편성, [[구매기록]] "H61 저가 수집기 라인" 원가표 참조). 향후 증편 시 h5, h6…으로 이어감. 🔴 2026-09-17 확정: 이 h 접두사는 H61뿐 아니라 H77 칩셋 기체도 함께 포함한다(제7조①-2 참조 — H77이 H61과 동일한 LGA1155 소켓· CPU세대 풀을 공유하므로 같은 계열로 묶는 것이 타당). "H61 부대"라는 호칭은 최초 창설 계기(H61 유휴 부품)를 남긴 역사적 이름으로 유지하되, 편성 대상 칩셋 범위는 H61+H77로 확장됐다.

제9조 (기기별 프로필 페이지 의무) 🔴

① 함대에 편입된 모든 기계(구축 중·미구축이라도 제7조②의 명명표에 등재된 기계 포함)는 그룹웨어(_gw)에 도메인형 프로필 페이지를 가진다 — 경로는 _gw/_machines/{기기코드}.html(원본은 동일 위치의 .md), 기기코드는 제7조② 명명표의 약어를 그대로 쓴다(예: mb1, m1, linux1, linux2, win1, del1, lin1, lin2, linux3).

② 프로필 페이지는 다음 항목을 반드시 포함한다: 1. 시스템 구성(보드·이동성 분류 등) 2. 역할명·역할 상세 — 03_함대동기화법.law.md 제5조의 표현을 그대로 인용, 임의로 새 역할 설명을 창작하지 않는다 3. 고정 IP — 확인되지 않은 값은 "확인 필요"로 표기하고, 실측치와 대장상 기재가 다르면 둘 다 병기한다 4. 하드웨어 사양(CPU·RAM·OS 등) 5. 소프트웨어 구성(핵심 런타임·raker 환경 등, 경량 요약으로 충분) 6. 내부 저장장치 — 슬롯명(DISK_LEDGER.md/storage_map.tsv 기준) | 모델 | 용량 | 용도의 표. 슬롯명이 아직 대장에 없는 장치는 "(미부여)"로 표기하고 등록을 촉구한다(제6조④ 배치 전 등록 원칙과 연동) 7. 향후 업글 계획 — 문서 근거가 있는 계획만 기재, 근거 없으면 "명시된 계획 없음"이라 쓴다. 추측으로 계획을 채워 넣는 것을 금지한다 8. 업글 이력 — 이미 완료된 하드웨어 교체·증설·정비 이력을 일자 | 항목 | 내용 | 출처/조달처의 표로 기록한다. 7호(향후 업글 계획)와 혼동하지 않는다 — 7호는 아직 실행 전인 계획, 8호는 이미 끝난 사실의 기록이다. 출처/조달처는 실제 문서에 남아있는 값만 쓴다(마켓플레이스명·중고구매·자가교체 등) — 확인되지 않으면 "미상"이라 쓰고 그럴듯한 값을 추측해 채우지 않는다. 완료된 이력이 없으면 "확인된 업글 이력 없음"이라 쓴다

③ 최신성 유지 의무: 하드웨어 구성이 바뀌거나(CPU/RAM/디스크 교체·증설), 역할이 재배정되거나, 고정 IP가 변경되면 그 시점에 해당 기기 프로필 페이지를 갱신한다 — DISK_LEDGER.md 배치 이력 기록과 동일한 시점에 함께 처리하는 것을 원칙으로 한다.

④ 원격 기기 정보 수집은 읽기 전용을 원칙으로 한다. 접속 불가(다운·재설치 중 등)인 기기는 삭제·추측 기재 없이 "접속 불가" 상태와 마지막 확인 시점을 그대로 남긴다.

⑤ 시행 도구: 마크다운 → HTML 변환은 기존 _gw/_md_to_html.py의 convert() 함수를 그대로 재사용한다(새 템플릿 설계 금지) — 그룹웨어 전체의 시각적 일관성을 위함.

제10조 (탈부착 부속품 대장 — USB 메모리·예비 CPU 등) 🔴

① 기기에 고정 장착되지 않고 탈부착·재배치되는 부속품(USB 메모리, 예비 CPU 등)도 제9조와 같은 원칙으로 개별 대장을 둔다 — 경로는 _gw/_infra/{품목}.html(원본 .md), 접근 경로는 gw/{품목}/ 형태로 안내한다(예: usb/, cpu/).

② 각 대장은 다음 항목을 반드시 포함한다: 1. 이름 — 물건에 붙는 고유 식별자. 명명 규칙은 품목별로 다음을 따른다: - 디스크·USB 메모리: DISK_LEDGER.md의 {제조사약어2글자}{용량}{일련번호} - CPU: {모델명(하이픈 유지)}-{순번}(예: e3-1240v5-1) — 순번은 1부터, 동일 모델 추가 입고 시 -2, -3…으로 늘어난다 2. 역할명·역할 상세 3. 이력 — 날짜순 누적 기록. 실수(예: 잘못된 이미지 플래시)도 숨기지 않고 기록한다(04_세션운영법.law.md 제2조와 같은 취지) 4. 구입일·구입가격 — 신규 구매분은 필수 기재. 기존 기기에서 캐스케이드로 빠져나와 예비가 된 경우처럼 별도 구매기록이 없는 물건은 "해당 없음"으로 명시한다. 가격 미상은 "확인 필요", 추정치는 "약 XX원(추정)"으로 확정값과 구분한다 5. 판매일·판매가격 — 처분(매각) 시 즉시 기재한다. 매각 전까지는 빈 칸으로 둔다

③ 제조사 약어는 DISK_LEDGER.md와 _naming_registry.tech.py(하드웨어 제조사 약어 섹션)를 단일 출처로 공유한다 — 디스크·USB·CPU가 각자 다른 약어 체계를 쓰지 않도록, 새 제조사가 필요하면 두 문서를 함께 갱신한다.

④ 제9조④⑤(읽기 전용 원칙, convert() 함수 재사용)를 그대로 준용한다.

제11조 (부팅 SSD 용량 표준 — 규모별 기준) 🔴

① 신규 부팅 SSD를 도입할 때는 기계 규모에 따라 용량을 표준화한다(2026-09-11 확정):

② 이 표준은 신규 도입·교체 시점에 적용한다 — 이미 이 기준보다 큰 용량의 부팅 드라이브가 정상 가동 중인 기계(예: 기존 NVMe 부팅 드라이브)를 소급해서 축소 교체할 필요는 없다. 근거: [project_collector_min_storage_spec]와 정합.

③ 인터페이스는 SATA로 통일한다(NVMe 대비 저렴·범용적이며, 순수 OS 부팅 용도엔 NVMe급 속도가 불필요) — 기존 NVMe 부팅 드라이브를 교체할 때도 이 표준을 따른다.

④ 단일 디스크 통합형 표준(2026-09-15 확정): ①~③은 부팅/프로그램/임시저장을 별도 물리 디스크로 나누는 모델이다. 디스크 하나로 전부(부팅+임시정거장+ 프로그램)를 구성하는 경우, 원본 디스크 용량 규모에 따라 아래처럼 3분할한다 ([[23_골든이미지위생법]]과 연계 — 부팅 파티션에 올릴 이미지는 반드시 정리된 상태여야 함):

🔴 부팅 32G로 통일(대표, 2026-09-15, 최종): 최초 20G안은 실측(Chrome· VSCode·Claude Desktop·ChatGPT·Telegram 등 트러블슈팅용 GUI/AI 도구 포함 시 13~24G까지 사용됨) 결과 여유가 부족해 32G로 상향 — 기존 물리 부팅 SSD 표준(제11조①, 32GB)과도 맞춰 "이게 부팅엔진"임을 직관적으로 알아보기 쉽게 규모 무관 32G로 통일.

파티션 크기는 GiB 단위로 정확히 지정한다(percent 분할 금지, lin2ts1 사례와 동일 원칙). 실제 디스크는 표기 용량보다 작으므로(blockdev --getsize64로 정확한 바이트 수 실측 후) "나머지" 파티션 크기를 확정한다. lin1 신규 SSD(Samsung 860 EVO 250GB, 실측 232.9GiB)가 중형급 표준의 최초 적용 사례, H61 부대(h1~h4, 128GB급)가 소형급 표준의 최초 적용 사례.

제12조 (OS 설치미디어 라이브러리 — 베이스캠프 원칙) 🔴

① OS 계열별로 설치 ISO를 한 곳(베이스캠프)에 모아두고, 필요할 때 복사해서 쓴다 — 매번 인터넷에서 재다운로드하거나, 버전을 헷갈려 잘못된 이미지를 굽는 사고(2026-09-10 xubuntu 24.04.4/26.04.1 혼동 사례)를 막기 위함이다.

② 베이스캠프 배정(2026-09-11 확정) — 대형/소형 계열별로 제작소(보관+ 굽기 겸용)를 둔다. 공통 근거: 두 기기 다 ①수집량이 적어 잠깐 멈춰도 부담이 없고 ②자체 디스플레이가 있어 외부 모니터 없이 단독으로 작업 가능하며(이번 세션 내내 linux1/2/lin1 같은 헤드리스 서버는 모니터 확보부터 난항이었던 것과 대조적) ③고정된 거점형/고정형 기기라 상시 접근 가능하다.

• 대형(64G) 계열 — w1(win1): Windows + Ubuntu Desktop 26 보관·굽기. 추가 근거: 함대 별칭 "거점형 부본부"로 상시대기 성격이 이미 있고, 이번 세션 ISO 오굽기 사고가 macOS(dd/Etcher)에서 났던 만큼 검증된 GUI 도구(Rufus 등)가 있는 Windows 쪽이 실수 위험이 낮다.
• 소형(32G) 계열 — d1(del1): Xubuntu minimal 보관·굽기. del1은 리눅스 계열이라 Xubuntu 쪽을 다루기에 win1보다 자연스럽다.
• l1(linux1)의 /l1s2/iso_library/: win1/del1이 다루지 않는 그 외 배포판(서버용 등)의 저장소. linux1은 절대 정지 불가(실전형)이므로 저장 전용이며 굽기 등 부수 작업은 하지 않는다.

③ 새 기기를 설치할 때는 해당 베이스캠프에서 scp/rsync로 필요한 ISO를 받아 USB(제10조 usb/ 대장 참조)에 구워 쓴다 — 대형/Windows 계열은 win1, 소형/Xubuntu 계열은 del1에서 보관과 굽기를 한 번에 처리하고, 그 외 배포판은 linux1에서 받아온 뒤 다른 기기에서 굽는다. 베이스캠프에 원하는 버전이 없으면 새로 받은 뒤 베이스캠프에도 함께 보관해 다음 사용자가 재다운로드하지 않게 한다.

④ 베이스캠프 폴더 자체는 설치 이미지 전용이다 — 실 수집 데이터나 코드를 섞어 두지 않는다(DISK_LEDGER.md의 슬롯 용도 분리 원칙과 같은 취지).

⑤ 골든 이미지 방식(2026-09-11 확정, linux2/lin2 이번 설치부터 적용): ISO 복사·설치 마법사 반복 대신, 이미 설정 완료된 기준 기계를 통째로 이미지 떠서 새 기기에 그대로 이식한다 — 대형(64G)은 l2(linux2) 기준 (당초 win1에 별도 Ubuntu Desktop 26이 있는 것으로 논의됐으나 2026-09-11 실측 결과 없는 것으로 확인되어, 대형은 linux2 자체 설치 기준으로 원복), 소형(32G)은 lin1 기준.

소형(32G) 최초 시딩(2026-09-11, 1회성 예외): del1엔 아직 Xubuntu 26 이미지가 없어, lin1(이미 Xubuntu 26 가동 중)에서 딱 한 번 복사해와야 한다. lin1은 이미 서비스 투입된 상태라 원칙상 가동중단 금지 대상이지만, 대표 직접 지시로 이번 1회에 한해 lin1 수집을 잠시 멈추고 복사한다 — 이후 del1이 자체 보유하게 되면 다시는 lin1을 이 목적으로 건드리지 않는다(del1이 이후 복제 담당 전담).

2차 복제소 이중화 원칙(🔴 필수): 같은 계열 기기가 추가되면(예: w1에 이어 w2가 생기면, d1에 이어 d2가 생기면) 그 신규 기기는 반드시 동일 계열의 2차 복제소로도 운영한다 — w2는 win1과 함께 Windows/ Ubuntu Desktop 26의 2차 보관·배포처, d2는 del1과 함께 Xubuntu minimal의 2차 보관·배포처가 된다. 목적은 단일 복제소 장애 시 전체가 막히는 걸 막는 이중화다. (현재 상태: 예정 — w2/d2가 아직 존재하지 않아 세부 동기화 절차는 미확정. 그 기기가 실제로 생기는 시점에 즉시 이 원칙에 따라 이중화를 시행한다.)

일반 원칙 — "서비스 투입 전"에 뜬다: l2/lin1은 일단 서비스에 투입되면 실전형이 되어 가동 중단이 원천 금지되지만(제1조·이 조 ⑤ 취지), 설치 직후·아직 실전 투입 전(서비스 개시 전) 상태에서는 이 제약이 적용되지 않는다 — 이 시점에 딱 한 번 이미지를 떠서 확보해두면 된다. 따라서 절차는: 설치 마법사로 정상 설치 → 기본 설정(raker 환경 등) 완료 → 서비스 투입 직전 디스크 이미지 캡처(정지 후 이미징 가능, 아직 실전이 아니므로 문제없음) → 그 이미지를 w1(대형)/d1(소형)에 보관 → 이후 서비스 개시. 일단 서비스가 개시된 뒤에는 재이미징을 위해 멈추지 않는다 — 필요하면 무중단 라이브 스냅샷(ZFS/LVM)만 쓴다.

⑥ 캡처 전 체크리스트 — SSH 키 선등록(2026-09-11 확정): 골든이미지를 캡처하기 직전, 기준 기계(w1/d1/l1/l2 등)의 ~/.ssh/authorized_keys에 랩 SSH 공개키가 이미 들어있는지 반드시 확인한다. 여기서 확인해두면 그 이미지로 만들어지는 모든 후속 기기가 태어날 때부터 비밀번호 없이 SSH 접속 가능한 상태가 된다 — 배치 이후 기기마다 일일이 키를 다시 등록하는 수작업이 사라진다. 반대로 이 확인을 건너뛰면, 이미 배포된 모든 클론 기기에 개별적으로 키를 재등록해야 하는 비효율이 반복된다 (2026-09-11 lin2 사례 — 사후에 수동으로 authorized_keys를 추가해야 했던 것이 이 체크리스트 부재 때문일 가능성이 높음, 원인 미확정이나 예방 차원에서 항목화).

⑦ 캡처 전 체크리스트 — 고정 IP 확인(2026-09-11 실증 확정) 🔴: 기준 기계의 네트워크 설정(/etc/netplan/*.yaml 등)에 고정(정적) IP가 박혀있으면, 그 골든이미지로 만든 모든 후속 기기가 원본과 똑같은 IP로 네트워크에 나타나 충돌한다 — 두 기기가 같은 주소를 번갈아 주장하면서 SSH 연결이 간헐적으로 끊기고 호스트키 경고가 떴다 사라졌다 하는, 원인 특정이 매우 어려운 증상으로 나타난다. 실증 사례: lin1을 복제해 만든 lin2가 lin1과 동일한 고정 IP(172.30.1.50)를 그대로 물려받아 실제 충돌을 일으켰고, 이 세션 내내 lin1 쪽 연결 불안정의 진짜 원인이었던 것으로 뒤늦게 확인됨. 소프트웨어(골든이미지)를 복사한 직후에는 반드시 이 항목부터 확인·수정한다 — 캡처 전 정적 IP를 DHCP나 플레이스홀더로 되돌려두거나, 배치 시점마다 새 고유 IP를 즉시 지정한다.

제13조 (신규 서버 SSH 키 등록 — GitHub 배포 방식 표준화) 🔴

2026-09-12 확정("결국 줄여야 일이 됨" — 대표). 신규 설치한 서버에 비밀번호 없이 SSH 키로 접속 가능하게 만드는 첫 등록 작업은, 물리 콘솔·KVM·시리얼 콘솔처럼 클립보드 공유가 안 되는 환경에서 특히 고역이다 — 80자 넘는 공개키 문자열을 손으로 한 글자씩 타이핑해야 해서 오타 위험이 크고 시간이 오래 걸린다. 대표가 직접 손으로 타이핑을 시도한 실증 사례(2026-09-12): "아무리 집중력을 높여도 오타가 있을 수 있어서 아주 괴롭고 피곤한 상황"이었다고 확인됨 — 이론이 아니라 실제로 겪은 고통이므로, 이 조는 "편한 길을 열어주는" 것을 원칙으로 삼는다.

① GitHub의 .keys 공개 엔드포인트를 표준 배포 경로로 쓴다. 세션의 랩 공개키를 GitHub 계정(SSH and GPG keys)에 미리 등록해두고, 신규 서버 콘솔에서는 아래처럼 짧은 사용자명만 타이핑해서 끝낸다 — 긴 키 문자열을 직접 입력할 필요가 없어진다.

curl https://github.com/<사용자명>.keys >> ~/.ssh/authorized_keys

② 상세 등록 절차·주의사항(SSH 키 vs GPG 키 혼동 금지 등)은 _makefund/_Solfit/라이브러리창고/개발툴/github_ssh_key_다중서버_등록.md 참조 — 화면 캡처를 포함한 전체 단계가 정리돼 있다.

③ 이 방식은 제12조 베이스캠프 원칙(골든이미지에 랩 키를 미리 심어두는 것)과 상호 보완적이다 — 골든이미지 클론이면 애초에 키가 이미 있어 이 절차 자체가 필요 없고, 처음부터 새로 설치하는 서버(이번 linux2 Ubuntu Server 재설치처럼)에만 이 조가 적용된다.

이 조의 모토(대표, 2026-09-12): "삽질 그만, 편안한 길로 인도" — 어렵고 고통스러운 수작업 경로가 있다면, 그걸 그냥 감내하지 말고 항상 더 쉬운 대안을 찾아 표준 절차로 만든다.

제14조 (원격 sudo NOPASSWD 표준화) 🔴

2026-09-19 확정. 새 서버 셋업 직후 원격 세션(SSH)에서 sudo 명령을 쓸 때마다 매번 비밀번호를 요구하면, 콘솔 없이 원격으로 작업하는 세션 입장에서 매번 사람이 직접 붙어 비밀번호를 입력해줘야 하는 병목이 된다. linux4 신규 편입 사례(2026-09-19)에서 이 문제로 계정명 정정 작업이 크게 지연됐다.

① 표준 명령: 계정 생성 직후, 콘솔에서 한 번만 비밀번호를 입력해 아래 두 줄을 실행해두면 이후 그 계정은 영구적으로 비밀번호 없이 sudo 가능해진다.

echo "<계정명> ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/<계정명>-nopasswd
sudo chmod 440 /etc/sudoers.d/<계정명>-nopasswd

② 이미 x1·linux3 등 일부 기존 기체는 이 설정이 되어 있어 원격 sudo가 즉시 됐던 반면(대표가 과거에 개별 설정한 것으로 추정), linux4처럼 이 설정이 안 된 기체는 원격 세션이 sudo -n 시도마다 매번 sudo: interactive authentication is required로 막혔다 — 앞으로 신규 설치하는 모든 기체는 제13조(GitHub SSH 키 배포)와 함께 이 조도 초기 셋업 표준 체크리스트에 포함한다.

②-1 적용 범위 확정(2026-09-19, 대표 확정): 수집기(lin/linux 등 raker 실행용 소형·중형 기체)는 전부 이 방식(NOPASSWD)을 기본 표준으로 적용한다. 단, 중요 운영 서버(고객 대면 서비스, 결제·인증 관련, 공인 IP 직결 서버 등)는 이 표준에서 제외 — ③항의 보안 트레이드오프가 실제로 문제되는 쪽은 이런 고위험 서버이지, 내부 폐쇄망의 수집기가 아니다.

③ 보안 트레이드오프 인지: NOPASSWD는 해당 계정이 탈취되면 즉시 root 권한까지 뚫리는 리스크가 있다 — 다만 이 함대는 SSH 키 인증만 허용하고 비밀번호 로그인 자체를 막아두는 방향과 병행하면(별도 조 검토 필요) 실질 리스크는 낮게 유지 가능하다. 외부 노출 서버(공인 IP 직결)에는 신중히 적용할 것.

실행 사례 자료

이 법의 원칙이 실제로 적용된 사례: