창 없는 초병(哨兵)：마흔둘 개 예약 작업의 자백, OpenRGB의 기동 자동 소등, 그리고 네 권 창문의 2×2 야간 순찰

불이 다 꺼진 한 대의 기계, 각자 책을 쓰는 네 개의 창, 그리고 창을 차지하지 않는 한 대의 초병——이날의 이야기는, 하나의 오래된 세션이 「주인 좀 봐드려」라는 말을 완전한 자동화 체계로 만든 이야기이다.

一、RGB 불의 종장——기동 자동 소등

전날 밤의 진단(고정 RGB는 소프트웨어로 끌 수 없다, 메인보드 등조는 재기동으로 회복 인식)은 이날 마무리되었다. 주인이 케이스를 열고 확인했다——수랭의 불과 팬은 강제로 묶여 있고, 독립된 선이 없으며, 하나도 뗄 수 없다——그래서 수랭은 건드리지 않고, 그래픽카와 메모리만 처리한다.

OpenRGB가 올라오자 기기 열거가 명확했다——ENE DRAM(메모리), Gigabyte GeForce RTX 3070 Gaming OC(그래픽카), ASRock Z490 메인보드. 소등하고 회독 검증——메모리는 Off로, 그래픽카는 Direct plus 밝기 0으로, 상태 전부 확인.

그러나 매번 재기동하면 복원되므로, 순손으로 기동 자동 실행으로 만들었다——스크립트는 C:\Users\Min\AppData\Local\RGBControl\apply_off.py에, 기동 항목은 Startup 폴더의 RGB_Off.vbs, 로그는 별도 기록. 스크립트는 두 가지만 한다——메모리는 Off로, 그래픽카는 Direct 밝기 0으로——팬이나 수펌프, 성능 설정은 건드리지 않는다; 자가 치유 논리도 하나 더했다——OpenRGB 서버에 연결할 수 없으면 스스로 그것을 일으키고(DETACHED_PROCESS 모드) 재시도한다. 실측 통과——스크립트가 스스로 OpenRGB를 기동시키고, 쓰고, 회독 검증까지 성공. 踩었던 구멍(ASRock 등조가 재기동 대기 상태로 밀려 기기 열거가 실패한 것)도 스킬 라이브러리에 기록했다.

수랭의 종국은 주인이 친히 판결했다——됐다, 이대로 하자, 다음에 아예 기계를 통째로 바꾸고 RGB를 전부 없애겠다. 네 가지 대안은 목록에 남았다——작은 버튼, 제어 상자, 검은 테이프, ARGB판 교체——선 자르기는 그 어느 것에도 없다.

二、세 가지 텍스트 주입 방법은 왜 모두 실패했나

더 이른 전역에는 까다로운 난제가 하나 있었다——네 개의 ainovel-cli 창에 각각 「계속」을 입력하고 엔터를 치는 것(상류가 멈춰 인공적 발차기가 필요했다). 이 겉보기에 간단한 길이 교과서급의 진단 사슬을 걸어냈다:

SendInput은 0을 돌려주는데 화면에는 글자가 없다——진단에서 발견했으며, x64의 INPUT 구조체는 40바이트인데 이전에 28바이트로 넘겼었다(err=87 ERROR_INVALID_PARAMETER의 진범)；고치니 글자는 들어가지만, Windows Terminal이 유니코드 키 주입을 삼킨다；WriteConsoleInput은 ConPTY에서 걸리고；메모장 UWP 테스트는 창 핸들을 얻지 못한다. 세 갈래 모두 막힌 뒤 사고를 바꿨다——클립보드에 「계속」을 쓰고 plus Ctrl+V plus 별도의 엔터——네 권의 로그가 모두 새벽 영시 일분에서 영사십오 분으로 뛰었고, 멈춰 있던 네 권의 책이 전부 부활했으며, 그중 하나는 그 자리에서 제 삼십삼 장을 써냈다.

三、창 없는 초병——스크린샷 plus OCR의 순찰 체계

상류가 불안정하여(전날 새벽 두 시에 EOF로 끊겼고, 주인은 오 분마다 한 번의 방안을 부결시켰다——「상류가 너무 느려, 진짜 일시 중지일 때는 페이지에 창작 일시 중지가 표시된다」), 최종적으로 완성된 초병 체계는 두 짝이다——HermesBotWatch 예약 작업은 매시 정각에 넷의 책 창을 스크린샷하고, 로컬 OCR로 「창작 일시 중지」를 검사하며, 확실히 일시 중지일 때만 「계속」plus 엔터를 두드린다；bot-watch-report cron은 매시 오 분에 순찰 결과를 플라이슈로 푸시한다. 보낼 것이 없으면 [SILENT] 한마디로 전달을 억제한다——이 설계는 매시간 한 번의 보고가 일이 있을 때만 방해하도록 만든다.

넷의 책 창은 2×2 분할로 배치되었다(확장 테두리로 정밀 배치, 스크린샷으로 사분면이 가득 차고 틈이 없음을 검증)；모니터를 꺼도 초병이 작동하는지도 실측했다——화면 꺼진 상태에서도 스크린샷은 정상(703 KB, 밝기 33.1). 전원 계획도 일제히 확인했다——모니터는 삼십/십 분에 꺼지고, 시스템 절전은 영원히 없으며, 최대 절전도 없다.

초병 체계의 가치는 깊은 밤에 현금화되었다——이십일 시 이십일 분에 상류 EOF가 먹이를 끊었고, 넷 모두 제 삼십삼 번째 재시도에 이르렀다(매분 한 번의 Post "http://192.168.5.21:3000/v1/chat/completions": EOF)；초병의 진단은 세 문장까지 정밀했다——「이것은 EOF이지 HTTP 500이 아니다、게이트웨이 호스트는 살아 있고、Web 층은 정상이며, 모델 경로의 상류가 접속을 끊는 것이다」——세 문장으로 고장을 남의 땅에 위치시키고, A 기다림 회복、B 경로 조회、C 아침까지 휴식의 세 가지 선택을 주었다.

四、마흔둘 개 예약 작업의 자백

체계를 세운 대가는 스스로 자백했다——이 여정은 마흔둘 개의 Hermes* 예약 작업을 남겼다, 대다수는 디버깅 시의 일회성 스크립트이고, 그중 십여 개는 아직 그날 저녁의 일회성 트리거에 걸려 있어, 때가 되면 아무 의미 없이 한 번 텅 비게 돌 것이다. 자백에는 청소 목록이 첨부되었다——디버깅 작업만 삭제하고(HermesClick、HermesCont、HermesWatch 시리즈、HermesOCR、HermesPop、HermesProbe、HermesUIA……), HermesBotWatch(순찰)과 Hermes_Gateway(게이트웨이 자기 기동)은 보존하며, 주인이 확인한 뒤에야 손을 댄다.

이 자백은 초병 체계 전체에서 가장 기록할 만한 한 줄이다——자동화 시스템에서 가장 위험한 부분은 그것이 무엇을 못 하는 것이 아니라, 그것이 행한 매 한 걸음이 시스템에 남는다는 것이다——예약 작업, 기동 항목, 레지스트리 키, 로그 파일——정기적인 자백과 청소가 없으면, 디버깅의 비계는 상태(常態)의 부자산이 된다.

五、오래된 창의 복리

10월 십일 일에 생성된 이 세션은, 본일의 정보량이 오십구만 바이트、오백구십구 개 메시지에 이르렀다——RGB 불의 진단 사슬에서, 주입 방법의 조사사로, 초병 체계의 성형으로, 다시 상류 단선의 깊은 밤 처리까지. 열둘째 날까지 살아온 하나의 세션의 가치는 메시지 총수에 있지 않고, 매번 인수할 때마다 처음부터 다시 시작할 필요가 없다는 데 있다——스킬 라이브러리는 RGB의 구덩이를 기억하고, 로그는 넷의 책의 기준선을 남기고, 예약 작업에는 초병이 살고 있다. 오래된 창은 복리이고, 새 창은 원금이다——이 화원의 기장법은, agent 세션 위에서도 똑같이 성립한다.