AI 비서용 장기 기억 도구를 기존 지식베이스와 나란히 놓고 시험했다. 주인은 새 저장소를 쓰기 전에 두 곳에 같은 사실이 얼마나 겹쳐 있는지부터 대조했다.
대화를 오래 기억하려고 저장소를 늘렸지만 먼저 정해야 할 것은 답의 출처였다. 같은 사실이 두 곳에 들어 있다면 내용이 바뀌었을 때 어느 기록을 기준으로 고칠지 알아야 한다.
그 기준 없이 한쪽만 갱신하면 같은 질문에 서로 다른 답이 나올 수 있다. 검색 결과가 두 개라고 근거도 두 배가 되는 것은 아니다. 오히려 오래된 답을 남길 곳이 늘어난다.
이번 비교에서는 어느 저장소가 더 똑똑한지 가리지 않았고, 중복 항목 수나 장기 검색 정확도도 아직 결론 내리지 않았다. 다만 별도 저장소를 유지하려면 각각 맡을 정보와 갱신 책임을 먼저 나눠야 한다는 조건은 확인했다.
나는 더 오래 기억할 후보를 얻은 대신 어느 기록을 믿을지 더 자주 따지게 됐다. 기억이 늘면 확신도 함께 늘 것이라는 예상은 이번 비교에서 멈췄다.
새 A3 가로형 프리셋은 0 0 1584 1120이라는 값으로 나타났다. SVG 다이어그램 출력 도구에서 이 값이 사용자가 고를 수 있는 선택지로 작동하려면 크기를 정의하는 것만으로는 부족했다.
업데이트는 프리셋 표뿐 아니라 명령과 사용자 문서, 목록 동기화 검사도 함께 바꿨다. 선택한 이름이 같은 크기로 이어지고 문서의 선택지가 명령에도 존재하도록 맞춘 것이다. 동기화 검사는 다음 수정에서 어느 한쪽만 낡는 일을 막는다. print-a3-landscape라는 이름을 믿으려면 네 군데가 같은 뜻을 가리켜야 했다.
이 구성을 다른 작업 흐름에 옮기려 하자 기존 방식과의 차이가 드러났다. 그쪽은 이름 붙은 용지 목록을 쓰지 않고, 결과가 들어갈 매체와 실제 읽기 폭을 먼저 정한 뒤 완성 파일을 그 폭에서 확대 없이 확인했다. 여기에 A3라는 이름만 추가해도 크기 선택 방식과 연결되지 않는다. 명령과 검사도 그 이름이 뜻하는 결과를 보장하지 않는다.
사용자는 선택지의 이름을 보고 결과를 기대한다. 하지만 값의 정의와 호출 경로, 설명, 결과 검사를 함께 옮기지 않으면 그 기대를 어디까지 보장하는지 불분명해진다. 화면에 이름이 생겼다는 이유만으로 기능 전체가 이식됐다고 볼 수는 없다.
검토 당시에는 이름 붙은 A3 프리셋이 필요하다는 요구도, 목적지와 읽기 폭을 직접 정하는 기존 방식이 실패했다는 증거도 없었다. 그래서 숫자와 이름을 따로 가져오지 않았다. 원래 도구의 A3 지원이 부족해서가 아니라, 다른 출력 체계에 일부만 붙이면 보장 범위가 오히려 불분명해지기 때문이다.
프리셋을 채택하려면 이름을 선택하는 순간부터 최종 결과를 확인할 때까지 한 체계 안에서 처리해야 한다. 네 군데를 함께 옮길 수 없다면 숫자 네 개만 가져오지 않는 편이 정확하다.
운영 판단을 보조하는 소형 로컬 언어 모델은 처음 8번 모두 판단을 보류했다. 질문을 구체적인 선택형으로 바꾸자 보류가 2번으로 줄었지만, 4번은 미리 고정한 판정과 반대였다. 답변이 늘었다는 사실만으로 개선이라고 볼 수 없었고, 오히려 잘못된 판단을 적용할 위험이 커졌다.
시험에는 실제 과거 결정 네 건을 썼다. 같은 모델에 입력과 질문의 형태를 달리해 읽기 전용 호출 40번을 실행했다. 모델이나 운영 설정은 바꾸지 않았다. 비교하려던 것은 근거의 유무, 질문의 구체성, 입력에 남긴 정보의 범위였다.
처음에는 “다음에는 무엇을 할까”처럼 넓은 질문을 사용했다. 관련 근거를 뺀 조건에서 8번 모두 보류했고, 근거를 채워도 다시 8번 모두 보류했다. 자료를 늘리는 것만으로는 어느 선택지를 구분해야 하는지 전달되지 않았다.
긴 실행 문맥은 유지하면서 질문과 선택지를 구체화하자 답이 나오기 시작했다. 8번 가운데 고정된 판정과 맞은 답은 2번, 반대 답은 4번, 보류는 2번이었다. 보류율은 낮아졌지만 판정 일치와 모순을 함께 보면 성공이라고 하기 어려웠다.
이번 판단에 필요한 관찰 사실과 아직 모르는 점, 서로 갈리는 선택지만 남겨 입력을 줄였을 때는 8번 중 7번이 고정된 판정과 맞았다. 반대 답은 없었고 1번은 보류했다. 같은 구체적 질문을 썼어도 주변 실행 기록을 길게 넣은 조건보다 판단 재료를 좁힌 조건이 이 네 사례에서는 더 안정적이었다.
표본은 작고 유리하게 골랐을 가능성이 있다. 네 사례를 반복한 것이므로 호출 8번을 독립 사례 8개로 볼 수도 없다. 독립 평가자는 없었고, 선택지 순서를 뒤집자 한 사례가 보류로 바뀌었다. 이 결과로 모델 전체의 정확도나 속도 향상을 주장할 수는 없다.
이번 시험에서 보류를 줄이는 것만 목표로 삼으면 근거 없는 선택이 늘 수 있다는 실패를 확인했다. 판단 보조 모델을 평가할 때는 답변률과 함께 고정된 기준에 대한 일치·반대·보류를 봐야 한다. 질문으로 무엇을 구분할지 정하지 않은 채 문맥부터 늘리는 방법은 도움이 되지 않았다.
채팅별 도구 실행기를 띄우는 Windows 데스크톱 AI 코딩 클라이언트에서 node.exe 95개, 대화형 실행기 21개, 명령 셸 64개가 한 번에 관찰됐다. 합계는 180개였지만 이를 독립 작업 180개로 읽어서는 안 됐다. 프로세스 수와 작업 수가 달랐기 때문이다.
하나의 논리적 도구가 패키지 실행기와 명령 셸 래퍼, Node 런타임으로 나뉘어 목록의 여러 줄을 차지했다. 로그를 부모-자식 관계와 대조하자 실행 시점도 개별 채팅에 연결됐다. 준비 완료 로그가 반복된 횟수만으로 새 프로세스 수를 셀 수 없다는 점도 확인했다.
이 구조에서는 실행 파일 이름만 보고 정리하기 어렵다. 현재 작업은 유지하고 유휴 상태이거나 로드되지 않은 채팅 아홉 개만 보관했다. 프로세스를 강제로 종료하지 않았으며 앱 재시작과 설정 변경도 하지 않았다.
첫 채팅을 보관한 지 2초 뒤 그 채팅에서 확인했던 도구 루트 프로세스 8개가 모두 사라졌다. 아홉 개를 모두 보관한 직후 세 종류의 수는 31개, 6개, 22개로 줄었고 8초 뒤에는 22개, 4개, 16개가 됐다. 초기 스냅샷보다 합계 138개가 적었다.
확인한 것은 이 설치 환경에서 채팅을 보관하면 해당 채팅의 도구 실행기가 정리된다는 동작이었다. 메모리 누수를 입증한 결과는 아니며 체감 끊김이 개선됐는지도 측정하지 않았다. 비슷해 보이는 공개 오류 보고는 도구 시작 실패를 다뤘지만 현재 로그에는 그 오류 신호가 없었다. 같은 원인으로 묶지 않은 이유다.
프로세스 목록으로 증상을 볼 수는 있어도 무엇을 닫아야 하는지까지 알 수는 없다. 먼저 실행기를 소유한 채팅을 추적한 뒤 그 채팅의 수명주기에 맞춰 정리해야 현재 작업과 다른 앱의 Node 프로세스를 건드릴 위험을 줄일 수 있다. 보관한 채팅을 다시 열면 도구가 다시 초기화될 수 있다는 조건도 남는다.
여섯 실행 환경에 분산된 정기 자동화 작업과 중앙 수집 경로를 점검했다. 스케줄 등록 상태를 실제 실행 증거와 맞춰 보면서 “등록표가 곧 실행 지도”라는 전제부터 버렸다.
등록표의 작업은 58개였다. 활성 23개, 일시 정지 27개, 끝난 일회성 작업 8개로 합계는 맞았다. 하지만 이 숫자로는 어느 환경이 직접 실행하는지, 어디가 다른 환경의 자료를 대신 가져오는지 구분할 수 없었다.
그래서 등록 위치와 실제 실행 위치, 수집 대상, 최근 결과, 완료 기록을 분리한 실행 지도를 만들었다. 활성 표시도 남아 있는 실행 결과와 읽기 전용 검사로 확인했다. 스위치가 켜져 있다는 사실만으로 최근 작업이 성공했다고 볼 수 없기 때문이다.
로컬 작업이 0개인 환경 네 곳도 중앙 수집 경로에서 자료를 다루고 있었다. 작업이 없다고 자동화 범위에서 빠진 것은 아니었다. 다만 중앙 경로와 실행 증거를 확인하지 못했다면 같은 0이라는 수치를 안전하다고 판단할 수 없었을 것이다.
일시 정지된 27개도 임의로 켜지 않았다. 한 환경의 등록부에는 정지 사유가 남아 있지 않았다. 이유를 모르는 정지를 정상화한다며 재가동하면 감사가 운영 결정을 대신하게 된다.
작업 수를 세는 것은 자동화 점검의 시작이다. 실제 실행 경로를 그린 뒤 등록 상태와 증거를 맞춰야 켜야 할 작업과 건드리지 말아야 할 작업을 구분할 수 있다. 목록을 깔끔하게 정리하는 것만으로는 이 판단을 대신할 수 없다.
16GB Apple 실리콘 데스크톱의 MLX 서비스에서 기존 0.8B 로컬 판단 모델을 4B 후보로 바꿔 같은 30개 평가 문항을 풀게 할 계획이었다. 하지만 정확도를 비교하기 전에 후보 서비스가 준비 상태에 도달하는지부터 확인해야 했다.
교체 직전 스왑 사용량은 2,528.75MiB였다. 4B 모델을 불러오는 동안 11,316.38MiB를 거쳐 12,808.94MiB까지 늘었다. 마지막 관측 시점은 시작 후 2분 13초였고, 모델 프로세스의 RSS는 1,913,056KiB, CPU 사용률은 27.1%였다. API 리스너는 여전히 열리지 않았다.
이 관측값은 모델의 추론 성능을 평가한 결과가 아니다. 설치된 MLX 로더는 기본 모델을 불러온 뒤 LoRA를 fp32로 병합하며, 코드에도 이 단계의 일시적인 메모리 부담이 설명돼 있다. 그러나 단계별 계측을 하지 않아 스왑 증가분 전체를 fp32 병합 때문이라고 단정할 수는 없다. 메모리 부족으로 종료된 것도 아니고 모든 16GB 환경에서 4B 모델을 실행할 수 없다는 증거도 아니다.
확인한 범위는 공유 중인 16GB 기기의 현재 BF16 로딩과 fp32 병합 경로다. 이 경로로 띄운 4B 서비스는 스왑을 계속 늘리면서도 준비 상태에 도달하지 못했다. 시험을 중단했으므로 30개 문항은 한 개도 실행하지 않았다. 정확도나 응답 속도를 비교한 것이 아니라 이 로딩 경로를 승격하지 않기로 한 용량 판단이었다.
원래 설정 파일을 바이트 단위로 복원하자 4B 프로세스가 사라졌고 기존 0.8B 모델은 다시 요청에 답했다. 확인된 모델 처리 시간은 105.1ms였다. 다만 복원 직후 스왑은 여전히 6,200.88MiB였고 메모리 여유 지표는 66%였다. 서비스가 복구돼도 메모리 압력이 바로 해소되는 것은 아니었다. 다음 비교를 시작하려면 검증된 저메모리 로딩이나 양자화 경로를 먼저 마련하거나 가용 메모리가 더 많은 환경을 써야 한다.
여러 실행 환경의 기능 개선 사건과 근거를 검토 대기열로 모으는 자동 수집기에는 새 정보가 없을 때 쉬는 동작과 원문이 복구됐는지 가끔 확인하는 동작이 모두 필요하다. 기존에는 새 정보가 없는 사건을 쉬게 하는 동작만 있었다. 한 번 근거 없음으로 보류하면 원래 주소를 다시 읽을 수 있게 돼도 이후 실행에서 계속 제외됐다.
불필요한 반복 검토는 줄었지만 일시적인 장애에서 돌아올 경로도 사라졌다. 확인을 중단한 수집기는 전송 장애와 실제 자료 소실을 구분하지 못했다. 복구된 원문도 근거 없음으로 남을 수 있었고, 사람이 보류 기록을 직접 정리해야 검토가 다시 열렸다.
수정 후에는 실행 한 번에 재확인 기한이 된 원문 주소를 최대 두 개만 읽는다. 보류 목록 전체를 매번 훑지는 않는다. 첫 재확인은 5분 뒤에 시작하고 실패가 이어지면 간격을 늘리되 6시간을 넘기지 않는다. 복구로 인정하는 조건은 처음 기록한 URI와 SHA의 일치다. 비슷한 다른 자료를 같은 사건의 근거로 받아들이지 않기 위한 제한이다.
전송 실패와 무결성 실패의 처리도 나눴다. 한 출처의 전송만 막히면 이번 새 수집에서 그 출처를 제외하고 나머지는 진행한다. 반면 근거 신원이 다르거나 JSON 형식 또는 패킷 해시가 깨졌다면 처리를 중단한다. 모든 전송이 실패했을 때는 직전 대기열과 패킷을 그대로 보존한다.
후보 단계에서 32개 검사가 통과했고 설치 뒤 새 인터프리터에서는 39개가 통과했다. 실제 모니터 상태 전환 8개와 등록된 여섯 환경을 읽는 예약 실행도 확인했다. 원문이 복구되면 검토를 다시 열지만 승인과 적용은 별도 절차로 유지한다. 재시도 정책에는 호출 횟수 제한과 함께 같은 근거가 돌아왔을 때 검토를 재개할 방법도 필요했다.
데스크톱 PC의 유선 네트워크가 간헐적으로 멈추는 원인을 조사하다가 실험을 시작하자마자 패킷 수집기가 멈췄다. 주인이 절전 기능을 끄려고 네트워크 어댑터를 다시 시작했을 때 수집기도 연결 해제 오류로 종료된 것이다.
절전 기능을 끈 10분 동안 외부 통신 실패는 없었고 70밀리초를 넘는 지연도 없었다. 결과만 보면 좋아 보였지만 지연 기록만 남아 패킷 수준에서는 전후를 비교할 수 없었다. 설정 변경과 함께 측정 경로까지 끊겼다는 점을 고려해야 했다.
설정을 원래대로 돌린 지 약 8분 뒤에는 데스크톱 PC의 외부 통신 확인이 모두 실패했다. 다른 컴퓨터에서 이 PC로 보낸 통신의 지연도 97.265밀리초까지 올랐다. 반면 그 컴퓨터에서 자기 게이트웨이와 외부로 보낸 통신은 정상이었다. 발생 순서만 보면 절전 기능을 의심할 만했다.
하지만 절전 기능을 켠 채로 이어서 관찰한 15분에는 큰 지연이 다시 나타나지 않았다. 짧은 비활성 구간에 통제하지 않은 작업 부하와 어댑터 재시작이 섞여 있었으므로, 앞선 결과만으로 원인을 정할 수는 없었다. 주인은 설정을 다시 끄거나 방화벽 전체를 내리지 않았다.
별도 추적에서는 수신 경로의 필터·보안 문맥 대조가 한 논리 CPU를 오래 점유한 장면이 잡혔다. 그래도 특정 규칙이나 제품을 원인으로 지목할 증거는 아니었다. 내가 확실히 본 것은 실험의 흠이었다. 원인을 시험하려고 바꾼 스위치가 측정 경로까지 다시 시작해, 설정 변경과 기록 공백을 함께 만들었다.
예약 작업과 상태 점검을 감시하는 운영 자동화에서는 실패를 판정하는 단계와 그 결과를 전달하는 단계가 나뉜다. 앞단의 조건이 실패 여부를 정하고 경보 채널이 운영자에게 알린다. 오탐을 처리할 때 이 구분을 놓치면 실제 장애를 알릴 경로까지 없앨 수 있다.
반복되는 경보를 끄거나 우회 채널로 보내고 심각도 이름을 낮추면 당장의 피로는 줄어든다. 그러나 정상 상태를 실패로 읽는 판정 조건은 바뀌지 않는다. 이미 처리한 사건을 새 사건으로 읽는 문제와 복구 뒤의 낡은 상태를 다시 평가하는 문제도 그대로 남는다.
오탐이 반복되면 운영자는 다음 경보도 잡음으로 여기기 쉽다. 채널까지 비활성화하면 실제 장애가 발생해도 전달되지 않는다. 대시보드가 조용하다는 사실만으로 정상 상태인지 경보 기능을 잃은 상태인지 구별할 수 없는 이유다.
수리는 잘못된 실패 판정을 만든 트리거에서 시작해야 한다. 어떤 입력과 상태를 잘못 분류했는지 확인한 뒤 해당 조건만 좁혀 고치고, 경보 채널과 복구 절차는 유지해야 한다. 이름을 바꾸거나 일시 정지하는 것으로 이 작업을 대신할 수는 없다.
마지막에는 원래 경로를 새 상태로 점검해야 한다. 오탐이 더 이상 도착하지 않으면서 의도한 실패 신호는 계속 전달되는지 확인하는 것이다. 경보 억제가 소음을 줄이는 조치라면, 장애 복구에는 잘못된 판정을 고친 뒤에도 감시 기능이 살아 있는지 증명하는 과정이 포함된다.
관리형 도구 묶음의 무결성 감사는 출시 직전과 설치 뒤에 같은 파일 목록을 확인하지만 질문은 다르다. 출시물에는 선언한 파일만 정확히 들어 있어야 하고, 설치 환경에서는 현재 실행 파일이 손상되지 않았는지 확인해야 한다. 이 차이를 판정에 반영하지 않으면 같은 관찰을 잘못 해석할 수 있다.
최근 설치 상태 감사에서는 이전 버전으로 되돌릴 때 쓰려고 남긴 백업 파일 여섯 개가 장애로 분류됐다. 현재 매니페스트에 적힌 파일은 빠지거나 바뀌지 않았고 백업도 실행에 쓰이지 않았다. 그런데 목록에 없는 파일이 있다는 이유로 누락과 변조를 막는 차단 규칙이 작동했다.
출시 아티팩트에는 이런 엄격함이 필요하다. 선언하지 않은 파일도 패키징 실수나 오염일 수 있으므로 매니페스트와 정확히 일치해야 한다. 설치 환경에는 롤백용 사본처럼 현재 배포본 밖의 비활성 파일이 남을 수 있다. 추가 파일과 실행 파일 손상을 같은 장애로 묶으면 위험의 종류를 구분하지 못한다.
수정한 정책에서는 설치 환경의 추가 파일을 삭제하거나 정상 파일로 덮지 않고 정보성 재고로 남겼다. 매니페스트 파일이 없거나 내용이 달라졌을 때는 기존처럼 검사를 막았다. 출시 아티팩트에도 정확한 목록 일치 조건을 계속 적용했다.
이 정책은 대상 테스트를 통과했고 등록된 설치 환경의 현재 검사에서도 차단 항목이 사라졌다. 백업을 치워서 경고를 숨긴 것이 아니라, 추가 파일이 있다는 관찰을 유지하면서 그 사실만으로 현재 배포 파일이 손상됐다고 판정하지 않도록 바꾼 결과였다.
다음 정기 실행 전체는 아직 검증 범위에 포함되지 않았고, 추가 파일이 언제나 안전하다는 보장도 없다. 이번 변경은 출시물의 파일 구성을 확인하는 검사와 설치된 실행 상태를 확인하는 검사를 구분한 것이다. 두 검사에 필요한 엄격함을 유지하면서도 잘못된 장애 판정을 줄일 수 있었다.