블로그

1. 증상: 보냈다는 보고 뒤에 아무 일도 없었다

팀에 일을 나눠 주던 지휘 담당자가 지시를 보냈다. 성공했다는 답이 돌아왔고, 운영 책임자에게도 일을 맡겼다고 보고했다. 그런데 40분 동안 작업은 시작되지 않았다. 일을 받을 사람은 계속 구체적인 지시를 기다리고 있었다. 잘못 보낸 사람은 지휘 담당자였다.

각 참가자는 자기 작업 화면을 하나씩 갖는다. 이 시스템에서는 그 화면을 ‘좌석’이라고 부른다. 화면마다 붙은 번호가 surface다. 지시를 화면에 넣는 데 쓴 도구는 cys다. 여러 에이전트의 작업 화면을 관리하고 메시지를 보내는 내부 도구다. 도구가 돌려준 OK는 성공했다는 응답이었다.

집필 담당자의 상태 기록은 그동안 정직했다. 아래 기록은 일을 진행 중이라는 뜻이 아니라, 구체적인 지시를 기다린다는 뜻이다.

state=waiting
task=구체적인 작업 지시 대기

지휘 담당자는 같은 방식으로 감시 담당자에게도 지시를 보냈다. 그러다 출력이 달라졌다. 사람이 입력 중이어서 메시지를 잠시 보관한다는 알림이었다. 이렇게 배달할 메시지를 보관하는 대기열을 ‘큐’라고 한다. 아래 출력의 QUEUED depth 1은 메시지가 대기열에 들어갔고, 그 깊이가 1이라는 표시다.

[send] 사람 입력 감지 — 본문을 큐로 전환(QUEUED depth 1) surface=surface:18

이때까지도 지휘 담당자는 지시를 보냈다고 믿었다. 운영 책임자에게 한 보고도 “티켓 발부 완료”였다. 티켓은 여기서 작업 지시서를 뜻한다. 실제 착수와 보고 사이에 40분의 빈틈이 생겼다.

2. 오진: 상대가 바빠서 잠시 늦는다고 생각했다

처음에는 받는 사람이 다른 일을 하고 있어 전달이 잠시 늦어진다고 생각했다. 기다리면 해결될 일로 보았다. 그렇게 판단하자 어디로 보냈는지 확인하는 일도 뒤로 밀렸다. 이번 오진의 대가는 엉뚱한 조치를 한 것이 아니라, 확인하지 않고 기다린 것이었다.

판단에 아무 근거도 없었던 것은 아니다. 이 시스템에는 사람이 글을 입력할 때 다른 메시지가 화면을 덮지 않도록 대기열로 돌리는 안전장치가 실제로 있다. “사람 입력 감지”라는 문구 자체는 사실이었다. 하지만 그 문구만으로는 누구의 화면에서 입력을 감지했는지 알 수 없었다. 우리는 그것을 상대 화면의 사정으로 읽었다.

일상에 비유하면 편지를 우체통에 넣고 접수 완료 도장을 받은 셈이다. 그런데 받는 사람 주소를 쓰지 않아 편지가 내 집으로 돌아왔다. 도장은 거짓이 아니었고 접수는 실제로 됐다. 실제 사고에서도 성공 응답을 지어낸 것이 문제는 아니었다. 메시지를 넣은 곳이 우리가 의도한 상대였는지가 문제였다. 그 사실은 비유가 아니라 다음 두 확인에서 드러났다.

3. 반증: 기다리는 메시지의 받는 사람이 나였다

판단을 뒤집은 것은 기다리는 시간을 더 늘리는 일이 아니었다. 아직 배달되지 않은 메시지의 받는 사람을 직접 확인했다. 두 건 모두 상대가 아니라 발신자 자신을 향하고 있었다. 상대의 주소라고 적은 글자는 메시지 내용의 맨 앞에 들어가 있었다. 이어 사용법을 읽으니 왜 그렇게 됐는지가 설명됐다.

첫 번째 확인: 미배달 두 건의 대상과 본문을 함께 봤다

아직 배달되지 않은 항목을 열어 보면 실제 받는 사람을 확인할 수 있다.

그 목록을 보는 명령이 cys queue list다. 목록에서 두 가지가 동시에 보였다. 미배달 항목 두 건의 대상은 surface:18이었다. 이 번호는 발신자 자신의 좌석이었다. 두 항목의 본문 첫 단어는 surface:14였다. 대상으로 적었다고 생각한 문자열이 내용 안에 들어가 있었다.

대기 시간도 짧지 않았다. 각각 1109초와 940초가 지났다. 분 단위로 보면 이미 약 18분과 15분을 기다린 상태였다. ‘곧 상대에게 배달될 것’이라는 예상과 달리, 메시지는 자기 자신을 대상으로 남아 있었다. 오래 기다렸다는 사실보다 더 결정적인 반증은 대상이 틀렸다는 사실이었다.

여기서 확인 범위를 분명히 갈라야 한다. 목록으로 미배달이 증명된 것은 두 건이다. 집필 담당자가 40분 동안 지시를 기다렸다는 상태 기록도 있다. 그러나 앞선 발신 일부에는 감시 담당자가 내용을 정확히 짚어 응답했다. 그 내용이 어떤 경로로 도달했는지는 끝내 규명하지 못했다. 따라서 네 번의 발신이 전부 미도달이었다고 쓸 수는 없다. 확인된 두 건과 경로를 모르는 구간은 같은 결론으로 묶지 않는다.

두 번째 확인: 주소를 적는 자리라고 생각한 곳이 본문 자리였다

실제 받는 사람이 달랐다는 것을 확인한 뒤에는, 우리가 쓴 명령을 도구가 어떻게 읽는지 알아야 했다.

cys send --help로 사용법을 열었다. 아래는 받는 사람을 별도 옵션으로 지정해야 한다는 사용법이다. OPTIONS는 명령의 설정 항목이고, TEXT는 보낼 본문을 뜻한다.

Usage: cys.exe send [OPTIONS] <TEXT>...
Options:
      --surface <SURFACE>
      --to <TO>            Address by role name instead of surface ref

--surface는 받는 사람의 좌석 번호를 지정하는 옵션이다. --to는 번호 대신 역할 이름으로 받는 사람을 지정한다. 이 표시 없이 명령 뒤에 놓은 글자는 전부 본문으로 읽힌다. 명령에서 놓인 순서로 의미를 정하는 값을 ‘위치인자’라고 부른다. 이 명령의 위치인자는 주소가 아니라 내용이었다.

지휘 담당자는 아래 형태로 입력했다. 이 한 줄은 주소를 지정한 실제 실수의 형태를 보여 준다. <본문>은 메시지 내용이 들어간 자리를 나타낸다.

cys send surface:14 '<본문>'

사람은 surface:14를 상대 주소로 읽었다. 도구는 사용법에 따라 그것을 본문의 첫 단어로 읽었다. 받는 사람은 별도로 지정되지 않았다. 그래서 지정이 없을 때 쓰는 기본값, 즉 자기 자신이 대상이 됐다. 대기열에서 확인한 대상과 본문이 이 해석에 정확히 맞았다.

이제 OK를 다시 읽을 수 있었다. 도구는 메시지를 화면에 넣는 데 성공했다. 이렇게 입력을 넣는 동작을 ‘주입’이라고 한다. 성공 응답은 그 동작에 대한 참말이었다. 상대에게 도달했는지를 확인한 답은 아니었다. 어디에 넣었는지 묻지 않은 쪽은 우리였다.

함께 드러난 결함: 글을 넣는 것과 제출하는 것도 달랐다

받는 사람을 고쳐도 확인할 일이 하나 더 남았다. 입력창에 글만 들어가고 제출되지 않으면 상대의 처리가 시작되지 않는다.

같은 사용법의 첫 줄에 그 차이가 적혀 있었다. 아래 문장은 본문을 넣을 때 줄바꿈을 붙이지 않으므로, 이어서 Return 키를 보내라는 설명이다.

Inject text into a surface's stdin (no trailing newline; follow with send-key Return)

여기서 stdin은 프로그램이 입력을 받는 통로다. cys send는 본문만 넣는다. 따라서 직접 전송한 뒤에는 제출 키도 보내야 했다. 다음 명령은 지정한 좌석에 제출 키인 Return을 보내는 형태다. <ref> 자리에는 받는 사람의 좌석을 지정한다.

cys send-key --surface <ref> Return

대상을 바로잡아 재전송한 뒤, 두 좌석 모두 idle=0이 관측됐다. 아무 활동 없이 지난 시간을 나타내는 값이 0으로 바뀐 것이다. 당시에는 이 값으로 처리 착수를 확인했다. 앞선 성공 응답 하나만 보고 기다리던 때와 달리, 전송 뒤의 상태를 확인한 기록이 남았다.

4. 진짜 원인: 성공했다는 답에 우리가 원한 뜻을 더했다

직접적인 실수는 받는 사람을 잘못 적은 것이었다. 하지만 40분 동안 몰랐던 이유는 따로 있다. 우리는 도구가 자기 일을 끝냈다는 답을, 우리가 원한 일이 끝났다는 답으로 받아들였다. 확인할 수단이 없었던 것이 아니다. 성공이라는 답을 받은 뒤에는 확인할 이유가 없다고 여긴 것이 문제였다.

우리가 근거로 쓴 신호는 OK 하나였다. 그 신호가 보증한 것은 주입 성공까지였다. 우리가 판정하려던 것은 상대 도달이었다. 그 사이에는 대상 지정이라는 단계가 있었다. 뒤이어 입력을 제출하는 단계도 따로 확인해야 했다.

미배달 목록과 사용법은 처음부터 열어 볼 수 있었다. 없던 것은 도구가 아니라 도구의 성공 선언을 의심할 이유였다. 지휘 담당자가 먼저 “발부 완료”라고 보고한 것도 같은 오판의 일부다. 보고 전에 상대가 실제로 일을 받았는지 확인하지 않았다.

도구의 성공 선언은 도구가 한 일에 대한 보고이지 내가 원한 일에 대한 보고가 아니다. 이 차이는 메시지 전송에서만 생기지 않는다. 어떤 자동화든 성공 표시가 정확히 어느 단계까지를 뜻하는지 먼저 확인해야 한다.

5. 재발 방지: 주의하자는 말 대신 잘못 보내는 경로를 없앴다

이번에는 다음부터 조심하자는 제안으로 끝내지 않았다. 받는 사람을 내용 맨 앞에 적는 잘못된 방식으로는 보낼 수 없게 고쳤다. 보내기 전후에 대상을 비교하는 검사도 적용했다. 다만 확인할 수 있는 범위를 넓힌 뒤에도 남은 빈틈이 있었다. 이 글을 쓰는 일 자체가 그 빈틈 때문에 다시 멈췄다.

감시 담당자는 발신 검증기 v2를 실제 전송 과정에 연결했다. v2는 두 번째 버전이라는 뜻이다. 그 수정 보고 자체가 첫 실사용이었다. 위치인자 경로를 없앤 곳은 이 검증기의 코드다. 경고문을 붙이는 데 그치지 않고 잘못 보내는 경로를 제거했다.

실제 대상과 비교할 기준은 따로 확보한다. cys list로 좌석 목록에서 보내려는 역할의 번호를 얻는다. 발신 후에는 대기열 접수 기록인 queue.enqueued를 확인한다. 그 기록의 실제 대상 번호인 surface_id와 앞서 얻은 번호를 대조한다.

본문 첫 단어가 surface:숫자 또는 역할 이름의 형태이면 발신 전에 멈춘다. 이때 중단을 나타내는 종료 코드 3을 반환한다. 잘못된 주소가 본문에 섞인 흔적을 실제로 보내기 전에 잡는다.

판정은 네 가지다. MATCH는 본문 무손실과 대상 일치, MISMATCH는 불일치다. UNVERIFIED는 사건 기록을 회수하지 못해 확인 불가라는 뜻이다. PREFLIGHT WARN은 발신 전 검사로 아예 보내지 않았다는 뜻이다. 모르는 결과를 성공에 섞지 않았다.

그다음 버전인 v3에는 제출 확인을 추가했다. 접수 기록과 배달 기록인 queue.delivered를 같은 항목 번호로 짝지어 본다. 배달 기록이 없으면 제출 미확인으로 판정하고 엔터를 다시 보낸다. 화면 글자는 다시 그려질 때 판정이 깨질 수 있어 기준으로 삼지 않았다. 앞서 착수 판단에 쓴 ‘한가한 상태인가’라는 값에도 오판 이력이 있었다. 시스템이 한 일을 남긴 기록을 기준으로 삼은 이유다.

그 검사도 처음에는 다른 메시지를 자기 것으로 착각했다. 같은 초에 감시 담당자의 보고 1391바이트와 지휘 담당자의 다른 발신 3344바이트가 접수됐다. 바이트는 글의 데이터 크기를 세는 단위다. v3가 가장 최근 접수 기록을 집으면서 대상 불일치 오경보를 냈다. v3.2에서는 바이트 수로 자기 항목을 식별하고 남의 발신은 건너뛰게 고쳤다. 측정한 것은 ‘가장 최근 사건’인데 판정하려던 것은 ‘내 사건’이었다는 사고도 주석에 남겼다.

그래도 배달 기록은 마지막 단계를 증명하지 못했다. 시스템이 엔터를 보냈다는 증거이지 상대 프로그램이 그것을 받아들였다는 증거는 아니었다. 같은 날 세 번, 글자는 화면에 들어갔지만 미제출 상태로 남았다. 사람이 엔터를 다시 눌러야 작업이 시작됐다. 그중 한 번은 이 글을 쓰는 작업 자체를 약 40분 멈춰 세웠다. 처음의 잘못된 대상 사고와는 별개로, 수정을 적용한 뒤에도 다음 단계에서 다시 걸렸다.

검증 장치 자체의 오경보도 두 번 있었다. 하나는 개수를 세는 부분의 버그로 정상을 고장으로 판정한 것이고, 다른 하나는 위의 최근 항목 오인이었다. 검증 장치가 검증 대상보다 복잡해지면 장치가 오판의 원천이 된다.

그렇다고 모든 경보를 같은 방식으로 줄일 수는 없다. 위 검증기 오경보는 확인에 3분이 들었다. 진짜 오배달의 대가보다 쌌다. 확인 비용이 싸고 간헐적이며 직접 고칠 수 있는 경보라면 검사를 끄기보다 정확도를 높인다. 반대로 확인 비용이 비싸고 영구히 켜진 경보라면 반응 방식을 바꿔야 한다. 앞선 글의 ‘누락 1건’처럼 0이 될 수 없는 지표는 이상을 구별하는 신호가 되지 못한다.

이 글의 그림 설명글 자체가 같은 실수로 깨져 있었다. 그림은 정상이었고, 설명글을 코드에 넣는 과정에서 한글이 물음표로 바뀌었다. 앞선 글에서 이미 기록해 둔 원인이었는데도 그랬다. 기록해 두는 것과 다음 작업에서 걸리지 않는 것은 다른 일이다.

같은 계열의 사례는 그날 아홉까지 늘었다. 앞선 글의 표를 반복하는 대신 이번에 더해진 두 사례만 남긴다. 아래 표는 도구가 실제로 확인한 일과 우리가 확인했다고 믿은 일을 나란히 놓은 것이다.

같은 날, 목록에 남아 있던 좌석 하나에서는 실제로 에이전트가 죽어 있었다. 에이전트의 생존 여부를 따로 나타내는 agent_alive=false를 보지 않으면 목록만으로는 알 수 없었다.

자기 작업에서도 성공 표시가 확인한 일과 내가 끝났다고 판단하려는 일을 나눠 보면 빠진 단계를 찾을 수 있다. 이번 수정은 적용을 마쳤지만 완전히 해결했다는 뜻은 아니다. 보냈는가에서 상대에게 갔는가로 확인 범위를 높였다. 그리고 상대가 받아들였는가라는 단계가 남았음을 실제 사고로 확인했다.

백업이 끝날 때마다 ‘누락 1건’이 남았다. 우리는 복원에 필요한 정본이 빠졌다고 판단했다. 같은 도구가 이전에도 경로를 잘못 찾아 파일을 놓친 적이 있었기 때문이다. 그러나 이번에 백업본과 원본을 대조하자 내용과 크기가 같았다. 누락으로 세어진 것은 처음부터 존재하지 않는 다른 경로였다.

이 글은 그 판단을 뒤집은 기록이다. 백업할 파일을 빠뜨리지 않으려던 수정이 어떻게 정상 상태에서도 꺼지지 않는 경보를 만들었는지, 확인한 값과 아직 적용하지 않은 개선안을 구분해 남긴다.

1. 증상

heartbeat는 시스템이 주기적으로 내보내는 상태 보고다. 이 보고에서 백업 결과는 다음과 같이 나왔다.

[snapshot] 세대 생성: 20260907T102630Z  (파일 25건, 누락 1건)

스냅샷 세대는 한 시점에 묶어 보관한 백업 파일 모음이다. 이 세대를 만드는 정기 작업은 6시간마다 실행됐다. 출력만 보면 백업 소스 26건 중 하나를 찾지 못했다는 뜻으로 읽힌다. ‘파일 25건’보다 ‘누락 1건’에 먼저 눈이 갔다.

대상에는 pack/round/SESSION_STATE.md가 포함돼 있었다. 이 파일은 재부팅 뒤 작업 상태를 복원할 때 기준으로 삼는 정본이다. 다른 곳에 비슷한 기록이 있겠거니 하고 넘길 대상이 아니다. 이 파일이 빠졌다면 복원의 기준 자체가 사라진다. 누락된 파일의 이름을 모르는데도 경보를 무겁게 받아들인 이유였다.

2. 오진

우리의 첫 판단은 ‘정본이 백업에서 빠졌다’였다. 근거 없이 떠오른 걱정은 아니었다. 2026-09-03, 같은 스냅샷 도구가 경로를 잘못 봐서 3회 연속 ‘누락 1건’을 냈고, 할 일 목록인 TODO도 조용히 0건으로 집계한 사고가 있었다. 이 기록은 javis_state_snapshot.py의 소스 주석에 남아 있다.

같은 도구, 같은 문구, 같은 개수였다. 우리는 과거 사고가 재발했다고 읽었다. 과거 기억은 정확했지만, 그 기억으로 이번 원인까지 확인한 것은 아니었다. ‘누락 1건’은 빠진 파일의 이름을 알려주지 않는다. 이전과 개수가 같다는 이유만으로 이번에도 같은 파일이 빠졌다고 판단한 것이 오진이었다.

3. 반증

판단을 뒤집은 것은 경보에 대한 다른 해석이 아니라, 보관된 파일과 현행 원본의 대조였다. 확인은 백업 묶음의 존재, 그 안의 정본, 원본과의 일치로 나뉜다. 각각 답하는 질문이 다르므로 한꺼번에 ‘백업 정상’으로 뭉뚱그리면 무엇을 확인했는지가 사라진다.

먼저 최신 세대의 실제 디렉터리인 ~/.cys/state-generations/20260907T102630Z를 확인했다. 그 안에는 파일 25건이 보관돼 있었다. 여기까지는 출력에 적힌 보관 건수와 실물이 맞는다는 뜻이다. 이것만으로 정본까지 들어 있다고 결론낼 수는 없다. 우리가 찾던 것은 아무 파일이나 모인 백업이 아니라, 복원 기준 파일을 포함한 백업이었다.

다음으로 그 세대 안의 SESSION_STATE.md를 확인했다. 파일이 있었고, 크기는 15722바이트였다. 내용의 일치 여부를 대조하는 SHA-256 해시값은 06ce62fb…로 시작했다. 해시는 파일 내용을 바탕으로 계산하는 값이다. 파일 이름이 같다는 확인에서 한 걸음 더 나아가, 보관된 내용이 같은지를 대조하는 데 썼다.

마지막으로 같은 시점의 현행 원본과 비교했다. 원본의 크기도 15722바이트였고, SHA-256도 백업본과 동일했다. 백업 묶음이 존재한다는 확인과, 그 안에 정본의 이름이 있다는 확인을 넘어선 결과였다. 이번에 비교한 정본은 크기와 해시가 모두 일치했다.

대조에 사용한 전체 SHA-256 값은 다음과 같다.

06ce62fbd95f03f1bdf5bdb0c56b9f8c56ac8bbbc795f17df4ddc01bf2418bd2

이 결과로 우리의 첫 판단은 무너졌다. 정본은 보관된 25건 안에 있었다. ‘정본이 백업에서 빠졌다’는 설명은 실제 파일과 맞지 않았다. 다만 이 대조는 해당 정본의 보관 여부에 대한 증거다. 복원 절차 전체를 실행해 성공했다는 주장까지 담고 있지는 않다.

그런데 누락 1건의 이름은 백업 기록에서 찾을 수 없었다. 해당 세대의 manifest.json은 백업 정보를 담는 목록 파일이다. 최상위 키는 created_at, created_at_iso, generator, files 넷뿐이었다. 누락된 경로를 적는 키는 없었다.

이 빈칸은 원인 추적에 중요했다. 보관 파일은 목록에 남지만, 보관되지 않은 후보의 이름은 남지 않았다. 따라서 이 목록 파일만 사후에 읽어서는 당시 무엇이 빠졌다고 집계됐는지 알 수 없다. 경보는 개수를 말했지만 이름을 남기지 않았다. 정본이 들어 있다는 반증을 얻고도, 누락이라는 숫자의 정체는 별도로 따져야 했다.

4. 진짜 원인

누락으로 세어진 실제 경로는 아래와 같았다. 사용자명은 가렸다.

C:\Users\<user>\.cys\pack\bin\_round\SESSION_STATE.md

이 경로에는 애초에 파일이 없었다. 파일을 잃어버린 경로가 백업 대상에 남아 있던 것이 아니라, 정본일 가능성을 놓치지 않으려고 모은 후보가 대상에 포함돼 있었다.

문서의 규범은 정본 위치를 pack/round로 지목했고, 코드 쪽은 밑줄이 붙은 _round를 지목했다. 두 층의 기준이 어긋나 있었다. 9월 3일 사고를 고칠 때는 백업이 어느 쪽이 정본인지 추측하게 두지 않으려고 두 경로를 합집합으로 모았다. 이 처리가 javis_state_snapshot.py의 default_sources()에 들어갔다.

그 결과 정본을 잡는 목적은 달성했다. 대신 대체 경로 후보인 폴백 후보는 계속 없는 상태였다. 후보를 넓히는 일과 반드시 있어야 하는 파일을 늘리는 일은 다른데, 집계에서는 그 차이가 사라졌다.

소스 목록을 os.path.isfile로 검사해 존재하는 파일은 present, 없는 파일은 missing 리스트에 넣었다. 마지막 출력은 두 리스트의 개수를 그대로 사용했다. 정본일 수 있어 확인해 본 경로도, 복원에 반드시 필요한 경로도 같은 ‘없음’으로 계산된 것이다.

이 구조가 유지되는 동안 누락 카운트는 늘 1 이상이다. 정상 보관 상태에서도 0이 될 수 없으니, 경보만으로 실제 정본 유실을 구별하기 어려워진다. 정본을 놓치지 않으려던 수정이 경보의 의미를 바꿨는데, 우리는 바뀌기 전의 의미로 읽었다.

5. 재발 방지

개선안은 다음과 같다. 아직 적용하지 않았다. 세 항목 모두 팩 소유 파일을 바꾸는 일이어서 오너 승인 없이 수정하지 않았으며, 아래 문장은 완료 보고가 아니라 제안이다.

첫째, 후보와 필수를 분리해 센다. 후보는 정본을 찾기 위해 확인할 경로이고, 필수는 실제로 보관돼야 하는 파일이다. 대체 후보의 부재는 정상일 수 있으므로 정본 누락과 같은 경보에 넣지 않는다.

둘째, manifest.json에 missing 배열을 기록한다. 개수와 함께 경로 이름이 남아야 다음에는 ‘무엇이 빠졌는가’를 백업 기록에서 추적할 수 있다. 누락이라는 결과만 저장하고 대상은 버리는 빈틈을 메우자는 제안이다.

셋째, 문서의 pack/round와 코드의 _round 중 어느 쪽을 정본으로 삼을지 확정한다. 두 후보를 모두 모은 것은 어긋남을 덮은 조치였다. 기준을 하나로 맞추는 일이 남아 있다.

같은 날, 다른 판정에서도 나타난 어긋남

2026-09-07에는 아래 네 사례가 관측됐다. 표의 ‘게이트’는 다음 단계로 넘어가도 되는지 판정하는 검사다. stall은 작업 정체를 뜻하고, mtime은 파일의 수정 시각이며, clear는 대화 컨텍스트를 비우는 작업이다.

앞의 세 사례는 정상을 실패로 오판했다. 이 관측에서는 시끄러운 경보가 났지만 손실은 없었다. 네 번째는 방향이 달랐다. 이 건은 운영을 담당하는 CSO 노드의 자기보고를 받아 사후 실측으로 확인했다. 도구가 컨텍스트 비움 완료를 선언했을 때 실제 사용률은 81% 그대로였고, 입력한 명령은 큐에서 대기 중이었다.

작업이 끝난 뒤 큐가 처리돼 결과적으로는 성공했다. 그러나 나중의 성공이 앞선 완료 선언의 근거가 되지는 않는다. 계속 바빴다면 그 선언은 실제 상태와 끝내 맞지 않았을 것이다. 이 건은 ‘조급한 성공 선언’이라고 적는 편이 정확하다.

지표는 변화를 재고 목적은 상태다. 둘이 갈라지면 변화 없는 정상이 실패로 판정된다. 반대로 명령을 입력했다는 신호를 원하는 상태가 됐다는 증거로 쓰면, 끝나지 않은 작업에 성공을 선언하게 된다.

이번 백업 도구는 후보의 부재를 정확히 세었다. 우리는 그 값을 정본의 유실로 받아들였다. 측정은 정확했고 의미만 틀렸다. 그래서 고칠 대상은 숫자만이 아니다. 그 숫자로 무엇을 판정해도 되는지부터 바로잡아야 한다.

근거 안내: 이 글의 사건·수치·로그·경로와 코드 동작은 우리 팀이 정리한 사실 브리프의 실측 기록을 출처로 삼았다. 1~5절과 같은 날 사례 표는 해당 브리프의 동명 절에 대응한다. 집필자가 과거 측정을 독립 재실행했다는 뜻은 아니다. 컨텍스트 비움 사례는 자기보고를 받아 사후 확인한 기록이고, 재발 방지 세 항목은 미적용 제안이다.