정거장모니터링법 — 헌법 제9조·제10조 시행법

근거: CONSTITUTION.cst.md 제9조(상시 감시와 즉각 대응 의무)·제10조(정거장 3단계 임계치 원칙) 소관: 정거장(디스크 기반 임시 저장소) 사용률 감시 및 자동 대응

제1조의2 (정거장의 두 유형 — 임시정거장 vs 데이터정거장) 🔴

2026-09-12 확정. "정거장"은 성격이 다른 두 유형으로 나뉜다 — 이후 모든 법률·문서에서 이 구분을 따른다.

영문 표기 원칙 — "station"이지 "stage"가 아니다: 정거장의 영문 번역은 station을 쓴다. "stage"도 IT 업계에서 스테이징 서버 등으로 쓰이지만, 일반적으로는 연극 "무대"라는 이미지가 먼저 떠올라 이 개념(데이터가 잠깐 머물다 가는 중간 지점)엔 어색하다 — "station"이 기차역처럼 "경유지"라는 의미를 훨씬 직관적으로 전달한다(대표 확정). 그래서 약어도 ts(Temporary Station)·ds(Data Station)로 정한다.

① 임시정거장(Temporary Station, 슬롯 기호 ts): 수집기 자신이 갖는 임시 저장소다(예: lin2ts1(구 lin2s1), d1ts1(구 d1s1)). 수집기가 막 발굴한 데이터가 잠깐 머물다가 빠져나가는 곳으로, 수집기 한 대에 종속된다.

② 데이터정거장(Data Station, 슬롯 기호 ds): 실전서버(실제 서비스에 투입되는 서버)의 데이터 빠른 이전을 돕는 정거장이다. linux1·linux2의 정거장은 전부 데이터정거장이다(2026-09-12 확정) — 예: l1ds1(구 l1s1), l1ds2(구 l1s2, /l1s2/stage/*·/l1s2/histoai/* 등 포함). 목적은 수집기에서 올라온 데이터를 실전 서비스로 빠르게 넘기는 중계다. 슬롯 기호 상세는 DISK_LEDGER.md의 "종류 기호" 표 참조 — 재라벨링은 문서상 슬롯 이름에만 적용, 실제 마운트 경로는 그대로 유지한다.

③ 두 유형 모두 제1조의 3단계 임계치·제2조의 센서 배치 의무를 동일하게 적용받는다 — 유형 구분은 역할·명명의 문제이지, 감시 수준을 다르게 두는 게 아니다.

④-2 🔴 데이터정거장 내 전용 공간 원칙(대표 확정, 2026-09-12): 데이터정거장에 붙는 각 수집기는 자기 비중(수집량·중요도)에 맞는 전용 공간을 보장받는다 — 그 공간은 다른 누구에게도 침범당하지 않는다. 기술적으로는 ZFS quota(또는 동등한 강제 할당 수단)로 구획한다 — 이미 linux1 l1s2/histoai/*에서 del1=100G·linux2=750G·mb1=250G·win1=250G처럼 실제로 적용 중인 방식이 이 원칙의 실증 사례다. 예외: 아주 단기적인 프로젝트 목적이면, 한 수집기가 자기 전용 공간의 일부를 다른 수집기에게 단기 임대할 수 있다 — 단, 임대는 명시적이고 기간이 한정되어야 하며, 영구적 잠식으로 이어지면 안 된다.

④-3 🔴 제3의 비상 데이터정거장(대표 확정, 2026-09-12, "The Show must go on"): 14_하드웨어경제성법.law.md 제8조④(비상 데이터 저장소·제3의 공간 원칙)의 구체 적용이다 — linux1·linux2 둘 다에 장애가 생기더라도 수집이 끊기지 않도록, 이 둘과 완전히 독립된 제3의 비상 데이터정거장을 상시 확보해둔다. linux1이나 linux2 중 하나를 서로의 비상처로 겸용하지 않는다 (같은 두 축 안에서만 돌면, 그 둘이 동시에 문제가 생기는 상황에 무방비 하기 때문). 어느 자원(소형 수집기의 여유 공간, VPS, 혹은 별도 신규 확보 자원)을 이 제3의 비상 정거장으로 지정할지는 아직 미확정 — 실행 전 대표 확인 필요, 확정되는 즉시 이 조에 구체 명시한다.

④-4 🔴 평상시 상호보완 원칙(2026-09-13 신설) — ④-3과 구분할 것: ④-3의 "제3의 비상 데이터정거장"은 linux1·linux2가 동시에 예기치 못한 장애를 겪는 최악의 시나리오를 막기 위한 조항이다. 이와 별개로, linux1·linux2 중 하나가 계획된 단일 유지보수(예: CPU 교체 등 예정된 다운타임)에 들어갈 때는, 서로가 서로의 임시 보완 역할을 하는 것을 원칙으로 한다 — 이건 ④-3이 금지하는 "동시 장애 무방비" 상황이 아니라, 한쪽이 알고 계획한 단일 다운타임이므로 다른 한쪽이 받아주는 게 합리적이다. 실증 사례: 2026-09-13, linux1 CPU 교체 예정 시 raker를 linux2로 이관하기로 확정 (hy1t1 1TB를 linux1로 먼저 이전해 스테이징 용량 보강도 병행).

요약: 계획된 단일 유지보수 = linux1↔linux2 상호보완(④-4). 예기치 못한 동시 장애 대비 = 완전 독립된 제3의 공간(④-3). 둘을 혼동하지 않는다.

④ 🔴 데이터정거장은 반드시 NVMe 중에서도 가장 빠른 도구를 사용한다 (대표 확정, 2026-09-12) — 선택·우선이 아니라 필수 요건이다. SATA SSD나 저속 NVMe로는 데이터정거장을 구성하지 않는다. 예: hy1t1(SK Hynix Gold P31 NVMe)을 맥미니의 프로그래밍 보조 용도에서 회수해 데이터정거장 역할(linux2 이전 예정, 16_예정사항관리법.law.md 항목 추가 검토)로 재배정하는 방향과 일치.

제1조의3 (대용량 회수는 30~40G 폴더 단위 청크로 — 검증 후 삭제) 🔴

2026-09-12 확정. 정거장에서 최종 저장소로 대량 데이터를 옮길 때, 한 번에 전체를 통째로 옮기지 않는다 — 250G 같은 대용량을 한 번에 복사하면 그 시간 동안 정거장에 새 데이터가 계속 쌓여 넘치는 사태가 반복된다 (대표 실증: "총 250G를 한참 복사하느라 물이 넘치는 사태가 자주 발생함").

① 30~40G 단위(가능하면 폴더 경계 기준)로 쪼개서 복사한다 — 파일을 임의로 잘라 묶기보다, 기존 폴더 구조(예: 기관별·수집원별 폴더)가 30~40G 근처면 그 폴더 단위를 우선한다.

② 한 청크 복사가 끝나면 그 청크만 검증(크기·개수 비교 등)한 뒤, 검증을 통과한 것만 원본에서 삭제한다 — 이러면 공간이 즉시즉시 빠져서 넘침을 막는다.

③ 검증에 실패한 청크가 있으면 그 자리에서 멈추고 삭제하지 않는다 — 다음 주기에 재시도한다. 대량 삭제 사고를 막기 위해, 실패를 무시하고 넘어가지 않는다.

④ 이 원칙은 회수 스크립트(l1s2_recovery.sh 등)뿐 아니라, 정거장에서 정본으로 옮기는 모든 대용량 이전 작업에 공통 적용한다.

제1조 (3단계 임계치, 확정)

①-0 🔴 책임 분담 원칙(2026-09-13 명문화): 정거장 관련 업무는 계층별로 명확히 나뉜다 — 혼동하지 않는다. - 각 실장·팀장(수집 담당): 기본적으로 수집(발굴) 업무에 집중하고, 정거장 임계치 판단·회수·강제이전을 스스로 실행할 책임은 없다 — 계속 발굴한다. 단, 예외 하나: 정거장 사용률이 50%를 넘는 순간, 판단 없이 곧바로 (1) 상위 이사에게 보고하고 (2) _gw/index.html 메인에 경고를 띄운다. 이건 "대응"이 아니라 "통지" 의무라 수집 업무와 병행 가능하다 — 발굴을 멈추지 않은 채로 알리기만 하면 된다. - 상위 이사(그 실장·팀장을 관리하는 이사): 정거장 모니터링과 회수의 책임을 진다 — 실장·팀장의 50% 통지를 받은 뒤 임계치 감시, 70%/90% 단계별 대응, 강제 이전 실행까지 전부 이사의 책무다. 실장·팀장이 통지만 하고 회수를 안 했다고 질책하지 않는다 — 회수는 애초에 그들의 역할이 아니다.

이 분담 원칙은 ①-2(발굴 주체의 상시 확인 의무)와 상충하지 않는다 — ①-2는 발굴 주체도 "이상 징후를 알아챘으면 경보를 울릴 의무"까지는 지되, 그 경보를 받고 실제로 대응(회수·강제이전)하는 책임은 여전히 상위 이사에게 있다.

①-1 🔴 제정 목적(2026-09-13 명문화): 이 3단계 임계치를 두는 이유는 향후 단 한 건도 정거장 용량 문제로 수집이 중단되는 일이 발생하지 않도록 하는 것이다 — 50%에서 이미 선제적으로 회수하므로, 정거장이 꽉 차서 raker가 멈추는 상황 자체가 애초에 일어나지 않아야 한다. 90% 강제종료는 "이미 실패한 상황을 막는" 최후 수단일 뿐, 정상 운영에서는 50%·70% 단계에서 전부 해소되어 90%에 도달하는 일 자체가 없어야 한다. 정거장 종류(임시정거장/데이터정거장) 구분 없이 동일하게 적용한다(제3조).

①-2 🔴 발굴 주체의 상시 확인 의무(2026-09-13 신설): raker 등 발굴 주체는 정거장 센서(제2조)에만 기대지 않고, 발굴 작업 중 정거장 여유분을 스스로도 계속 확인하며 진행한다. 정거장 사용률이 50%를 넘었는데도 회수·발굴 측 대응(속도 조절, 회수 트리거 등)이 감지되지 않으면 — 즉 임계치는 넘었는데 정상적으로 기대되는 반응이 없는 상태이면 — 즉시 경보를 울린다. 센서(수동적 관찰)와 발굴 주체(능동적 자기점검)가 이중으로 감시해야 ①-1의 "정거장으로 인한 수집 중단 0건" 목표가 실제로 지켜진다.

①-3 🔴 경보 전파 방식(2026-09-13 신설): ①-2의 경보는 다음 두 채널로 동시에 전파한다. 1. 그룹웨어 메인(_gw/index.html) 최상단에 경보창 게시 — 누구든 메인 페이지만 봐도 즉시 인지 가능하게 한다. 2. 상위 부서(담당 이사·실장)에게 보고 — 자동 알림(PushNotification 등) 또는 세션 등록부 기준 담당 라인으로 직접 통지.

경보창은 문제가 해소(정거장이 다시 안전 구간으로 복귀)되면 제거한다 — 해소되지 않은 경보를 방치해 메인 페이지에 계속 남겨두지 않는다.

①-4 🔴 상위 부서의 즉시 강제이전 권한(2026-09-13 신설): ①-3으로 보고받은 상위 부서(담당 이사·실장)는 보고를 확인하는 즉시 자신의 권한으로 해당 정거장의 데이터를 다른 여유 정거장으로 강제 이전시킨다 — 발굴 주체나 정거장 담당자의 별도 승인·조율을 기다리지 않는다. 이는 ①-1의 "수집 중단 0건" 목표 달성을 위한 최종 실행 권한이며, 사후에 이전 사유와 결과를 위반기록(01_위반처리시행령.dec.md 체계)이 아닌 이 법의 정상 운영 이력으로 기록한다.

①-5 🔴 강제이전 시 이중화 등급 적용(2026-09-13 신설): 강제이전 대상 데이터는 01_데이터구조법.law.md의 재수집 난이도 기준([[feedback_recollectible_single_copy_policy]])을 그대로 적용한다. - 1중화(단일 사본): 위키백과 등 언제든 다시 쉽게 받을 수 있는 소스 - 2중화(원본+복제본): Europeana 등 재수집이 어렵거나 오래 걸리는 소스

삭제 순서 엄수: 이전이 완료되면 원본을 즉시 지우지 않는다 — 원본과 이전된 사본(2중화의 경우 두 사본 모두)을 100% 완결 검증(파일 수·크기· 체크섬 등으로 누락·손상 없음 확인)한 이후에만 원본을 삭제한다. 검증 전 원본 삭제는 이 법 위반이다.

실행 매뉴얼: 위 절차의 단계별 명령어·체크리스트는 정거장_강제이전_절차와_방법론 (원본 .md: _infra/정거장_강제이전_절차와_방법론.md) 참조 — 신임 이사·실장도 이 문서만으로 강제이전을 처음부터 끝까지 수행할 수 있도록 작성됨.

제2조 (센서 배치 의무)

① 모든 정거장에는 5분 주기 크론으로 사용률 감시 센서를 배치한다.

② 센서는 다음을 남긴다. 1. ~/station_sensor/<라벨>.status — 최신 상태 1줄 2. ~/station_sensor/<라벨>.log — 이력(최근 2000줄 유지) 3. 임계치 초과 시 .WARN/.STOP 플래그 파일

③ 모니터링 세션은 매 점검 사이클마다 df를 직접 두드리기보다, 이 상태/플래그 파일을 먼저 확인하는 것을 우선한다 — 크론(5분)이 세션 점검 주기(15~30분)보다 빠르게 반응하기 때문이다.

④ 🔴 민감·재수집난이도 높은 발굴 세션의 단축 점검 주기(2026-09-13 신설): 일반 점검 주기(15~30분)는 표준 발굴에 적용되는 기본값이다. 재수집이 어렵거나 오래 걸리는 소스(제1조①-5의 2중화 대상, 예: Europeana)를 다루는 세션, 또는 디스크 용량이 작아 임계치를 빨리 넘길 수 있는 정거장(예: VPS 1코어급, 20GB대 디스크)에서 작업하는 세션은 일반 주기보다 짧게(권장 5~10분) 그룹웨어를 확인한다. 오늘(2026-09-13) vps-in이 88%에서 91%까지 30분 내로 올라간 사례가 이 조의 신설 근거다 — 일반 주기(15~30분)로는 이런 급격한 변화를 놓칠 수 있다.

④-1 🔴 vps-in 특정 사유(2026-09-13 실측 확인): 실측 결과 vps-in은 디스크 23GB로, vps-us·vps-jp(각 52GB)의 절반도 안 되는 용량이다 — 구조적으로 같은 양의 raker 활동에도 사용률이 훨씬 빨리 임계치에 도달한다. vps-in은 이 조의 단축 주기(5~10분) 적용을 명시적으로 우선 대상으로 지정한다. 근본 해결은 디스크 증설이나 vps-in 배정 raker 수 하향 조정이며, 16_예정사항관리법.law.md에 검토 항목으로 등록한다.

제3조 (배치 현황 — 신규 정거장 추가 시 갱신)

2026-09-10 기준 배치 완료: vps-jp, vps-us, linux1(/, /l1s2 — STOP 없음, 경고만), lin1(/, /mnt/l1s2_stage). linux2는 당시 SSH 다운으로 미배포 — 복구 확인 후 반드시 배포할 것. 새 정거장이 함대에 추가되면 이 조를 갱신하고 즉시 센서를 배치한다(제2조 위반 방치는 경미한 위반에 해당).

제4조 (linux1 예외 처리)

linux1은 여러 워크로드가 섞여 있어 자동 STOP 명령을 아직 걸지 않는다 — 경고·로그만 남기고, 실제 프로세스 종료는 담당 운용실장(linux1_운용실장_인수인계.md)이 상황을 보고 판단한다. 이 예외는 상황이 안정되면 재검토한다.

제5조 (회수 액션 스크립트 — 상시 자동가동 금지, linux3 완성 전) 🔴

① 감시(센서)는 상시 자동으로 돌지만, 회수 액션(실제 데이터 이동)은 l3(linux3, 함대 별칭 "항공모함")이 완성되기 전까지 상시 백그라운드 데몬으로 돌리지 않는다. 회수 스크립트는 언제든 실행 가능한 상태로 준비만 해두고(정확성 검증 완료), 실행은 모니터링 플래그(제1조 임계치 경고)를 본 세션이 그때그때 수동으로 트리거한다.

② 배경(2026-09-11): win1의 push_l1s2_win1_wsl.sh가 while true 무한 루프로 상시 가동되도록 설계됐으나, ①원격 목적지 디렉토리 생성 누락 버그로 최초 1회부터 실패했고 ②WSL2가 유휴 시 자동 종료되며 프로세스째 같이 죽어, 하루 넘게 아무도 모르게 완전히 멈춰 있었던 사고가 있었다. "일단 상시 자동화해두면 안심"이라는 전제가 실제로는 조용한 실패를 아무도 못 알아채는 더 큰 위험을 만든다는 게 확인된 사례다.

③ linux3 완성 이후: 함대 전체를 중앙에서 지휘할 수 있는 항공모함이 갖춰지면, 그때는 회수 액션도 linux3 주도로 정식 자동화한다(13_하드웨어운용법.law.md 8-3 참조). 그 전까지는 이 조 ①을 원칙으로 한다.

④ 이미 상시 루프로 짜여 있는 기존 회수 스크립트는 이 조에 맞춰 단발 실행형으로 전환한다(2026-09-11 push_l1s2_win1_wsl.sh 최초 개선 사례).

⑤ "자동가동 금지"가 "방치 허용"은 아니다 — 항공모함(linux3)을 손보는 동안에도 각 정거장은 자기 역할(회수를 통해 사용률을 낮게 유지하는 것)을 계속 수행하고 있어야 한다. 상시 무인 데몬을 안 쓴다는 것은 실행 방식을 "자동 루프"에서 "세션이 직접 트리거"로 바꾼다는 뜻이지, 회수 자체를 뜸하게 해도 된다는 뜻이 아니다.

⑤-2 점검 주기 — 2단계(2026-09-11 확정): 신규 정거장을 셋팅하거나 정거장 구성을 새로 변경한 직후에는, 새 설정이 자리잡는 데 통상 15분 정도 걸리는 점을 감안해 첫 30분 이내에 1차 확인한다. 그 이후에는 10분 단위로 반복 확인한다 — 정거장 상태(제2조 상태 파일)를 점검하고 필요하면 그 자리에서 회수 스크립트를 트리거한다. "가끔 생각날 때"가 아니라 이 2단계 주기가 최소 기준이다.

실행 사례 자료

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