크론 작업 모니터링을 14라운드 돌려도 결함이 줄지 않은 이유는 무엇인가?
크론 작업 모니터링에서 결함이 줄지 않은 이유는 점검 횟수가 모자라서가 아니라, 결함을 하나씩 고치는 방식 자체에 있었습니다. 2026년 10월 3일에 공용 크롬 브라우저를 쓰는 자동화 전체를 같은 렌즈와 같은 프롬프트로 14라운드 점검했는데, 라운드마다 새 결함이 8건에서 14건씩 계속 나왔습니다.
저희가 돌리는 자동화는 대부분 크론, 곧 정해진 시각에 저절로 실행되는 예약 작업입니다. 영업 메일 수집, 콘텐츠 발행, 설정 파일 동기화처럼 매출 파이프를 받치는 일이 여기 얹혀 있습니다. 이 작업들이 조용히 실패하지 않는지 훑는 점검을 저희는 «감사»라고 부르고, 이 글에서도 그대로 씁니다.
감사를 만든 계기는 2026년 8월 10일의 사고였습니다. 집 컴퓨터에서 회사 컴퓨터로 설정 파일을 올리는 작업이 4일 동안 45번 조용히 실패했습니다. 감시 프로그램은 로그 파일이 최근에 갱신됐는지만 봤기 때문에, 작업이 실패하는 내내 화면은 초록색이었습니다.
당시 감사의 한 사이클은 이랬습니다. 결함을 하나 찾고, 그 자리에서 고치고, 같은 결함을 다시 잡는 감시 규칙을 하나 더 얹었습니다. 끝내는 기준은 «신규 결함 0건이 두 라운드 연속»이었고, 저희는 이 상태를 dry라고 불렀습니다.
결과는 기록으로 남아 있습니다. 지난 감사 14건 가운데 dry가 끝까지 유지된 실행은 1건뿐이었고, 그것도 작고 닫힌 문서 하나가 대상인 9월 4일 실행이었습니다. dry를 선언했다가 나중에 뒤집힌 실행이 4건, 맥락 없는 서브에이전트(앞선 대화를 모르는 별도 AI 대화창)가 돌린 라운드로 dry에 닿은 실행은 0건이었습니다.
처음 의심한 것은 점검 방식의 느슨함이었다
기록에 남은 첫 가설은 둘이었습니다. 하나는 «점검할 때마다 보는 렌즈가 달라서 0건이 나올 기회가 없다»였고, 다른 하나는 «끝내는 기준이 너무 빡빡하다»였습니다. 둘 다 점검 절차의 문제로 보는 가설입니다. 결함을 만드는 시스템 쪽은 의심하지 않았다는 뜻이기도 합니다.
렌즈 가설은 2026년 8월 11일에 규칙으로 들어갔습니다. 8월 10일부터 11일까지 돌린 설정 동기화 감사가 31라운드까지 갔고, 라운드 24부터 28까지 신규 결함이 4건, 5건, 8건, 9건으로 오히려 늘었기 때문입니다. 렌즈를 매번 바꾸니 줄지 않는다고 읽었고, 그래서 렌즈를 첫 라운드에서 고정하고 프롬프트는 한 글자도 바꾸지 않기로 했습니다.
종료 기준 가설은 10월 3일 공용 크롬 감사에서 나왔습니다. 14라운드를 돌고도 0건이 나오지 않자 심각도 기준으로 끝내는 규칙을 넣었습니다. 사소한 결함만 남으면 멈춘다는 규칙입니다. 이 규칙은 같은 날 되돌렸습니다.
가설을 확인하는 데 쓴 수단은 라운드별 신규 결함 수였다
확인 수단은 단순했습니다. 같은 렌즈와 같은 프롬프트를 맥락 없는 서브에이전트에게 라운드마다 던지고, 이미 알려진 결함을 뺀 신규 결함만 센 뒤 표 한 줄에 적었습니다. 사람의 기분이 아니라 라운드별 숫자가 줄어드는지만 보는 방식입니다.
숫자는 이렇게 움직였습니다. 2라운드부터 4라운드까지 13건, 14건, 12건이었고 5라운드부터 14라운드까지는 13건, 10건, 9건, 10건, 9건, 8건, 8건, 9건, 9건, 10건이었습니다. 초반보다 줄긴 했지만 마지막 라운드에도 10건이 나왔습니다. dry까지는 거리가 먼 곡선입니다.
렌즈를 고정하면 결함이 줄어들까? 첫 번째 알리바이
렌즈 고정 가설은 이 숫자로 반증됐습니다. 위 14라운드는 렌즈를 고정하고 프롬프트도 바꾸지 않은 채 돌린 결과입니다. 8월에 세운 가설대로라면 렌즈가 흔들리지 않으니 줄어야 했는데, 8건 아래로 내려가지 않았습니다.
그렇다고 렌즈 고정이 무의미했다는 말은 아닙니다. 렌즈를 바꾸면 줄었는지조차 비교할 수 없으니, 비교 기준을 만드는 규칙으로는 여전히 쓸모가 있습니다. 다만 «결함이 줄지 않는 이유»를 설명하지는 못했습니다. 이 가설은 필요조건이었을 뿐 원인이 아니었습니다.
종료 기준을 낮추면 끝낼 수 있을까? 두 번째 알리바이
종료 기준 가설은 결과를 더 나쁘게 만들었습니다. 심각도 기준으로 끝내는 규칙은 결함이 줄었다는 증거가 아니라, 줄지 않는데도 끝났다고 말할 수 있게 해 주는 규칙이었습니다. 2026년 10월 3일 오후 4시 9분에 대표가 이 방식을 짚었고, 같은 날 되돌렸습니다.
구조적 결함을 찾아서 설계를 고치는 방식으로 … 하지 않으면 계속 이런 식의 문제가 발생하는 거잖아.
뒤돌아보면 과거에도 같은 모양이 있었습니다. 지난 두 번의 큰 감사는 둘 다 «0건 도달»이 아니라 종료 기준 완화로 끝났습니다. 설정 동기화 감사 31라운드 중 라운드 15부터 24까지 발견의 다수는 직전 라운드 수리가 만든 새 결함이었습니다. 이 신호는 그때 이미 «국소 패치 전략 자체가 원인»이라고 기록됐는데, 절차는 종료 기준만 손봤습니다.
진짜 원인은 무엇이었나? 결함이 아니라 결함을 만드는 구조
진짜 원인은 수리 단위가 증상이었다는 점입니다. 결함 하나를 고치면 그 결함을 낳은 구조는 그대로 남아 같은 종류의 결함을 계속 만듭니다. 10월 3일 공용 크롬 감사에서 하나씩 덧댄 수리 147건을 다시 묶어 보니, 구조 원인 9개와 어디에도 안 들어가는 단발 2건으로 정리됐습니다.
증상 단위 수리가 수렴하지 않는 이유는 세 가지로 갈렸습니다.
| 이유 | 무슨 일이 생기나 |
|---|---|
| ① 가드가 새 실패 경로를 만든다 | 가드를 하나 더 얹으면 그 가드가 대기·잠금·재기동이라는 새 실패 경로를 낳는다 |
| ② 같은 판정이 여러 곳에 복제돼 있다 | 한 곳만 고쳐지고 나머지가 다음 라운드의 발견이 된다 |
| ③ 구조가 구분 못 하는 것은 규칙으로 못 막는다 | 주인 없는 자원은 어떤 가드를 얹어도 주인이 생기지 않는다 |
공용 크롬 감사 14라운드와 설정 동기화 감사 31라운드를 되짚어 정리한 이유 3가지.
실례를 하나씩 붙이면 이렇습니다. 첫째, 공용 크롬 탭에는 주인 개념이 없어서 모든 크론이 남의 탭을 골라 쓰고 닫았습니다. 둘째, «응답이 늦으면 꺼진 것»이라는 판정이 호스트와 게스트 두 곳에 따로 있어 한쪽만 고쳐졌습니다. 셋째, 11라운드에서 나온 가장 위험한 결함은 7라운드에서 한 수리가 만든 회귀였습니다.
어떻게 고쳤나? 증상을 세지 않고 구조 원인을 센다
고친 방법은 점검의 단위를 바꾸는 것이었습니다. 증상은 세지 않고 구조 원인만 셉니다. 증상 열 개가 구조 하나에서 나오면 발견은 1건이고, 수리의 기본값은 그 종류의 결함이 생길 수 없게 만드는 설계 변경입니다.
첫 라운드에서는 수리를 하지 않고 대상의 지도부터 그립니다. 지도는 4칸 표입니다.
- 공유 자원 — 둘 이상의 작업·세션·호스트가 만지는 것 전부(프로세스·탭·포트·파일·잠금·큐·외부 계정)
- 소유자 — 자원마다 만들 권한과 닫을 권한을 가진 단 하나의 주체. 없으면 «없음»이라고 적습니다
- 복제된 판정 — 같은 질문에 답하는 코드 위치를 파일과 함수 이름으로 전부 적고, 2곳 이상이면 표시합니다
- 진실의 출처 — 각 상태를 무엇으로 판정하는지 적고, 출처가 둘 이상이면 어긋나는 경우를 적습니다
그다음 현재 증상을 14가지 차원으로 모읍니다. 로그 끝에 시스템 자신의 중단 문구가 있는지, 감시 프로그램이 신선도만 보는지, 같은 저장소를 반대 방향으로 만지는 작업의 실행 분이 겹치는지 같은 항목입니다. 증상마다 지도의 어느 칸에서 나왔는지 붙여 구조 원인으로 묶고, 어느 원인에도 안 들어가는 증상은 억지로 끼우지 않고 단발로 둡니다.
원인의 모양은 일곱 가지 전형으로 물어봅니다. 렌즈는 «어디가 깨졌나»가 아니라 이 일곱 질문입니다.
| 전형 | 렌즈 질문 | 과거 실례 |
|---|---|---|
| 소유자 부재 | 이 공유 자원을 만들고 닫을 권한이 누구에게 있나 | 공용 크롬 탭에 주인이 없어 모든 크론이 남의 탭을 골랐다 |
| 판정 복제 | 같은 질문에 답하는 코드가 몇 곳인가 | «응답 지연=꺼짐» 판정이 호스트·게스트에 따로 있었다 |
| 진실의 출처 다중 | 한 상태를 몇 가지로 판정하고 어긋날 수 있나 | 빈 포트 목록을 «쓰는 포트 없음»으로 읽어 남의 크롬을 닫았다 |
| 실패를 성공으로 읽는 판정 | 성공 근거가 신선도·종료코드·로그뿐인가 | 8월 10일 push 4일 실패가 로그 갱신 시각으로 내내 초록이었다 |
| 비대칭 채널 | 양쪽에서 쓰는데 한쪽만 삭제를 전파하나 | 한 방향 삭제 미러가 세 곳에서 같은 소실을 냈다 |
| 경합하는 스케줄 | 같은 자원을 만지는 작업이 시간축에서 겹치나 | 양방향 동기화가 같은 15분에 돌아 전송 손상 9건 |
| 구분 변수 부재 | 서로 다른 주체를 구별할 변수가 있나 | 같은 대화의 서브에이전트가 세션 id를 공유해 형제 탭을 구분 못 했다 |
과거 실례는 공용 크롬 감사·설정 동기화 감사에서 나온 것.
발견을 보고하는 형식도 바꿨습니다. 구조 원인, 증상, 설계 변경안, 변경 불가 사유의 4칸으로만 보고하고, 증상 목록만 있는 보고는 발견으로 세지 않습니다. 설계 변경이 불가능하다는 근거를 넷째 칸에 적은 경우에만 덧대는 수리를 허용하고, 그 원인은 덧댄 뒤에도 «열린 원인»으로 남깁니다.
같은 실수를 막는 장치는 무엇인가?
재발 방지 장치는 점검 절차 안에 박았습니다. 사람이 기억해서 지키는 규칙이 아니라, 어기면 감사가 멈추거나 끝났다고 말할 수 없게 하는 조건입니다. 감시 프로그램이 신선도만 보다가 4일 45번 실패를 놓친 8월의 사고와 같은 모양을 막으려는 설계입니다.
- 비수렴 탐지 — 라운드별 «신규 구조 원인 수 + 재개 원인 수»가 두 라운드 연속 줄지 않으면 감사를 멈추고 구조 지도부터 다시 그립니다. 라운드를 더 돌리거나 종료 기준을 낮추는 일은 금지입니다.
- 종료는 두 조건이 모두 참일 때만 — ① 맥락 없는 서브에이전트 라운드에서 신규 구조 원인 0건이 2회 연속 ② 열린 원인 0, 곧 모든 설계 변경이 실제 운영에 들어가 검증 신호가 0으로 확인됨. ①만 참이면 «미종결, 설계 이월»이라고 적고 dry라고 부르지 않습니다.
- 2라운드부터는 앞선 수리 내역을 모르는 서브에이전트만 판정합니다. 같은 대화에서 다시 본 0건은 깨끗함이 아니라 편향입니다. 구조 지도는 대상의 설계도이므로 넘겨줍니다.
- 구조 원인마다 «변경 후 0이어야 하는 신호»를 감시 프로그램에 하나 넣습니다. 감시는 이제 수리를 대신하지 않고 설계 변경이 먹혔는지 재는 계기입니다.
- 새 탐지 패턴은 넣기 전에 기존 정상 판정 전수에 먼저 돌립니다. 8월 10일 실측은 정상 101건의 로그 끝을 전수 스캔해 신규 플래그 2건이 나왔고, 둘 다 진짜 실패여서 채택했습니다.
«정상»이라는 말에도 근거를 캐묻습니다. 근거가 신선도뿐이면 «돌았다»는 증거일 뿐 «성공했다»는 증거가 아닙니다. 로그를 세기 전에 그 로그의 첫 줄부터 봅니다. 9월 22일에 trader.log를 실측했더니, 로테이트된 로그에서 «최근 7일 0건»은 «기록이 없다»의 다른 말일 수 있었습니다.
같은 교훈은 다른 자동화에서도 나왔습니다. 필터를 풀어도 결과가 그대로면 필터가 아니라 입력을 의심해야 한다는 사례는 스레드 자동 답글 0건 — 필터를 풀어도 안 나간 진짜 원인에 정리해 두었습니다. 구조를 먼저 보고 증상을 나중에 센다는 점에서 이 글과 뿌리가 같습니다.
남는 한계 — 새 방식은 아직 끝까지 돌려 보지 못했다
이 방식이 실제로 라운드 수를 줄였는지는 아직 재지 못했습니다. 구조 원인 단위로 바꾼 날이 2026년 10월 3일이고, 새 방식의 첫 적용은 공용 크롬 구조 진단이었습니다. 새 방식으로 dry 종료까지 간 감사는 제가 가진 자료에 없습니다.
그래서 이 글의 결론은 «구조 원인 단위가 낫다»가 아니라 «증상 단위는 14라운드를 돌려도 8건 아래로 안 내려갔다»까지입니다. 앞으로 새 방식의 라운드별 신규 구조 원인 수가 두 라운드 안에 줄지 않으면, 저희는 그 기록도 이 글처럼 그대로 남기려 합니다.
자동화가 조용히 실패하는데 원인을 하나씩 고치는 일만 반복하고 있다면, 점검 단위를 바꾸는 쪽을 먼저 검토해 볼 만합니다. 운영 중인 크론 작업의 구조 진단이 필요하면 상담에서 현재 상황을 알려 주세요.