사내 AI 코딩 에이전트 관리 플랫폼 — 기기 정책 가드와 사용량 수집 서버

기기 상주 데몬이 정책에 어긋나는 외부 공개·공유 요청을 차단하고, 사용자에게 안내 창을 띄우며 시도를 감사 기록으로 남기게 했습니다. 이어 가드 서버를 붙여 회사 계정 OAuth(PKCE)로 기기를 등록하고 하트비트와 차단 이벤트를 모았습니다. 서버는 규칙의 위치와 버전만 내려주고 데몬은 서명을 검증한 규칙만 적용하며, 등록이나 전송이 실패해도 로컬 차단은 멈추지 않습니다. 이 정책 배포 경로로 사용량 보고 스위치를 카나리 두 대에서 확인한 뒤 전역으로 켰습니다.

활성 명단 92명에게 보고 스위치를 배정했고, 보고 중인 온라인 기기 87대가 모두 집행했습니다. macOS·Windows 보호 상태 보고를 확인하고 설치 안내·운영 가이드·복구 절차를 인계했으며, 전사 순차 설치는 다른 팀이 맡습니다.

끊기기 직전 sar 표본에서 메모리 사용률 62.90%→81.66%, 페이지 스캔 153.77→332.58/s로 메모리 압박을 확인하고, 디스크·하이퍼바이저 경합·CPU 크레딧(장애 38시간 뒤 소진된 결과)을 근거와 함께 배제했습니다. 인스턴스 설정에서 ClickHouse가 기본값으로 RAM의 90%를 자기 예산으로 잡는 것을 찾았는데, 이 호스트는 RAM을 다른 컨테이너와 나눠 쓰고 swap이 없어 OOM kill 대신 스래싱에 갇힐 수 있는 구조였습니다. ClickHouse 예산을 호스트에 맞게 명시하고 큰 두 컨테이너에 mem_limit을 걸었습니다.

공유 호스트에서 기본 예산이 메모리를 독점하는 축을 막았습니다. 같은 증상의 다음 장애를 분석하며 이 장애의 실제 방아쇠도 재파싱 루프였을 가능성이 높다고 판단했고, 인스턴스 상향은 관측 전에는 잘못된 설정을 비용으로 덮는 일이라 보류했습니다.

처음엔 재시작을 Node 힙 설정 문제로 보고 힙 상한을 명시하려 했지만, 넣기 전에 실측해 보니 Node 22는 cgroup 한도의 약 51%로 힙을 스스로 잡고 있어 그 안을 버렸습니다. 한도의 근거로 쓴 241MiB도 유휴 상태 값이었습니다. 재시작과 17시간 40분 정지는 같은 원인, 미처리 청크가 하나라도 있는 파일을 통째로 다시 읽는 무한 재파싱이었고, 512m에서는 이 루프에 컨테이너만 죽고 호스트가 버텼습니다. 176MB 파일에 미처리 청크 9개가 생긴 뒤로 이 파일을 포함해 매 사이클 45청크 254.3MB를 문자열 배열로 다시 올렸습니다. 512MB 파일 상한은 176MB 파일에 걸리지 않았고, 워커 힙 2,048MB는 호스트 RAM보다 커 의미가 없었으며, 유일하게 발화한 768m 컨테이너 한도는 죽을 때마다 페이지 캐시를 밀어내 호스트를 스래싱으로 끌고 갔습니다. 512m에서 768m으로 올린 제 변경이 컨테이너 재시작을 호스트 정지로 키운 것입니다. 파일 상한 64MB·워커 힙 256MB·컨테이너 640m으로 낮춰 루프를 끊고, 파싱을 청크 단위 스트리밍으로 바꾼 뒤 파일 상한을 256MB로 다시 올렸습니다.

최대 파일의 파싱 피크가 427.8MiB로 640MiB 한도의 67% 안에 머뭅니다. 미처리 청크 하나가 파일 전체를 다시 읽는 O(n²) 구조는 후속 과제로 분리했습니다.

알람 채널의 최근 3일 메시지 104건 중 98건이 봇이고 사람이 쓴 메시지는 0건이었으며, 47회 발화한 알람에 멘션이 하나도 없어 모바일 푸시가 가지 않았습니다. 라우팅과 연락처는 전사 공유 설정이라 건드리지 않고, 직접 관리하는 알람 규칙 5종의 요약 문구 앞에 멘션을 붙였습니다.

공유 설정을 바꾸지 않고 알람 5종의 요약 문구에 멘션을 추가했습니다.