반증 라운드가 있는 결함 감사 — 후보 45개에서 재현 가능한 14개까지

파일 생명주기와 그래프 생명주기, 그리고 앱 사용성에 어떤 결함이 있는지 감사했습니다. 감사 보고서가 흔히 하는 일은 의심 목록을 만드는 것입니다. 이 감사는 그것을 하지 않기 위해 규칙을 먼저 정했습니다.

규칙

의심은 결함이 아닙니다. 각 후보는 실행 가능한 재현으로 바뀌어야 결함으로 인정됩니다.

통제군이 없으면 아무것도 증명하지 못한 것으로 칩니다. 모든 프로브가 버그 조건과 정상 조건을 쌍으로 갖습니다. 버그 조건만 있는 프로브는 그 코드가 원래 그렇게 동작하는 것인지 결함인지 구별하지 못합니다.

기준선을 먼저 녹색으로 만듭니다. 감사 시작 시점에 두 테스트 스위트가 모두 통과 상태였습니다. 프런트엔드 85파일 982테스트, 백엔드 1,010테스트, 실패 0. 그래야 새로 실패하는 단언만이 결함을 가리킵니다.

증거 등급을 결론마다 명시합니다.

등급	뜻
실행 UI	실제 앱을 브라우저에서 부팅하고 사용자 동작을 재현
실행 로직	출하 중인 함수를 테스트에서 직접 호출, 또는 비공개 로직을 축자 이식해 실행
연역 추적	호출 그래프 전수 조사와, 대조되는 “가드가 있는 형제 경로” 제시
라이브 포렌식	실제 설치본과 실제 볼트를 읽기 전용으로 측정

같은 결론이라도 어느 등급으로 얻었는지에 따라 신뢰도가 다르고, 등급을 적지 않으면 그 차이가 사라집니다.

반증 라운드

후보 45개를 트리아지해 14개로 좁히고, 그 14개를 전부 실험으로 검증했습니다. 그 다음에 독립 회의론자 14명이 각각 하나씩 맡아 반증을 시도했습니다.

14개 전부 살아남았습니다. 다만 다수가 심각도 하향됐습니다. 반증 라운드가 결함을 지운 것이 아니라 크기를 깎았고, 그것이 이 라운드가 하는 일입니다. 반증 시도 없이 정리한 감사는 확인 편향이 걸러지지 않은 목록이고, 그 목록의 우선순위는 믿을 수 없습니다.

감사가 남긴 것은 문서가 아니라 실행물이다

산출물	성격
백엔드 프로브 11개	통과 = 재현 성공. 버그의 존재를 단언하므로, 결함이 고쳐지면 실패한다
프런트엔드 단언 10건	실패 = 결함 존재. 올바른 동작을 단언하므로, 결함이 고쳐지면 통과한다
e2e 스펙 2종	탭 생명주기. 수정 후 3개 조건이 통과로 반전됐고, 미해결 소관 2개는 버그를 단언한 채 남아 있다
영구 회귀 스펙 6조건	수정과 함께 신설. 수정 전에는 6조건 전부 실패한다는 것을 개별 실행으로 확인

단언 방향이 파일마다 다릅니다. 어떤 프로브는 버그를 단언하고 어떤 프로브는 정답을 단언합니다. 회귀 테스트로 승격할 때 방향을 뒤집지 않으면, 고쳐진 뒤에도 통과하는 무의미한 테스트가 남습니다. 각 항목에 어느 쪽인지 명시했습니다.

가장 큰 발견은 계획에 없던 것이었다

감사 계획서에 되감기 기능은 들어 있지 않았습니다. 그런데 실제 설치본의 데이터베이스를 읽는 과정에서, 되감기 한 번이 그 되감기가 건드리지도 않은 문서 1,057개에서 102,020개의 사실을 영구 삭제했다는 것이 나왔습니다.

메커니즘은 이렇습니다. 되감기는 파일을 되돌리기 위해 각 문서의 그래프를 스냅샷과 대조하는데, 대조 대상 목록에는 있고 스냅샷에는 없는 문서를 삭제해야 할 것으로 읽습니다. 되감기 범위 안의 뒤쪽 턴이 처음 건드린 문서는 앵커 시점 스냅샷에 존재하지 않으므로, 롤백이 아니라 삭제로 처리됩니다.

되돌릴 수 없었습니다. 삭제 자체가 해시 게이트를 통과했기 때문입니다.

이 결함은 픽스처로는 나오지 않습니다. 한두 개 문서로 만든 시나리오에서는 범위 안 문서와 스냅샷 문서가 일치하기 때문입니다. 실제 설치본을 읽었기 때문에 나왔고, 그것이 라이브 포렌식을 증거 등급에 넣은 이유입니다.

수정과 함께 되돌리면 실패하는 회귀 테스트를 등록했습니다. 되감기 범위 안의 뒤쪽 턴이 처음 건드린 문서가 살아남는지를 직접 단언합니다.

고칠 수 있는데 고치지 않기로 한 것

같은 감사에서 체크포인트 스냅샷이 과대 캡처된다는 것도 나왔습니다. 실측입니다.

항목	값
스냅샷 저장소 총량	145 MiB
그중 되감기가 실제로 읽을 수 있는 바이트	0 B (체크포인트 5개 전부)
노트 본문 대비	노트 전체의 18.7배
일반 편집에 실제로 필요한 양	문서당 중앙값 7,649 B
증가율	하루 11.2 MB. 상한 없음

“0바이트를 읽는다”는 것은 우연이 아니라 구조적입니다. 기록된 체크포인트가 전부 신규 생성이라, 복원이 할 일은 해당 그래프를 떼어내는 것뿐이고 그건 식별자만 있으면 됩니다.

그럼에도 캡처를 좁히는 패치를 전부 보류했습니다. 이유는 두 가지입니다. 첫째, 캡처를 그 턴 자신의 경로로 좁히면 위에서 방금 고친 데이터 손실이 반대편에서 되살아납니다. 좁히려면 스냅샷 해시를 경로별로 운반하는 선행 작업이 필요하고, 그건 방금 한 수정보다 큰 변경입니다. 둘째, 오늘 실패하는 테스트를 쓸 수 없습니다. 해당 함수가 앱 핸들을 받는데 그 테스트 하니스가 저장소에 없습니다.

대신 두 가지를 남겼습니다. 하나는 가드 테스트입니다. 오늘 통과하고, 캡처를 경로별 귀속 없이 좁히는 순간 실패합니다. 시뮬레이션으로 확인했습니다. 앵커 스냅샷에서 한 줄을 빼자 그 문서가 출력 그래프에서 통째로 사라졌습니다. 다른 하나는 보류를 뒤집는 방아쇠 목록입니다. 저장소가 1GB를 넘거나, 한 대화가 체크포인트 상한에 도달하거나, 쓰기 턴 빈도가 특정 수준을 넘거나, 클라우드 동기화 폴더 아래에 볼트가 놓이면 재개합니다. 재개 순서도 비협상으로 못 박았습니다.

용량 문제를 먼저 재보니 순위가 바뀌었습니다. 같은 폴더 안의 다른 파일이 319 MB로 더 크고, 쓰기 턴이 아니라 매일 자라며, 증가 속도가 두 배입니다. 그쪽이 먼저입니다. 그리고 초판 보고서가 적었던 “사용자 백업과 동기화를 탄다”는 프레이밍은 이 머신에서 거짓이었습니다. 백업 대상 미설정이고 볼트가 클라우드 경로가 아닙니다. 초판에 적었던 것을 확인 후 정정해 남겼습니다.

이 감사가 보여주지 않는 것

결함의 존재를 증명하지, 빈도를 증명하지 않습니다. 프로브는 결함이 재현된다는 것을 보이며, 실사용에서 얼마나 자주 발생하는지는 별도 계측이 필요합니다.
한 대의 머신, 한 명의 사용자입니다. 라이브 포렌식 수치는 그 설치본의 것입니다.
트리아지에서 떨어진 31개는 재검토되지 않았습니다. 심각도 판단으로 걸렀고, 그 판단 자체는 검증하지 않았습니다.
반증 라운드는 사람이 했습니다. 14명이 각각 하나씩 맡았고, 무엇을 놓쳤는지는 알 수 없습니다.

측정 기록

항목	값
실행 시점	2026년 7월 31일, 스냅샷 실측은 8월 1일
기준 커밋	`96aaf8e6`
기준선 스위트	프런트엔드 85파일 982테스트 / 백엔드 1,010테스트, 둘 다 실패 0
라이브 포렌식 대상	실제 설치본의 1.2 GB 데이터베이스와 실제 볼트, 읽기 전용
프로브	`src-tauri/src/audit_probe.rs` (11개), `tests/unit/audit_.test.ts`, `tests/e2e/audit_.spec.ts`
수정 커밋	되감기 데이터 손실은 `1cd80797`

프로브 출력은 결정론적이며, 각 줄이 버그 조건과 통제 조건의 쌍으로 나옵니다. 예를 들어 파일 이동 후 쿼드가 사라지는 프로브는 버그 조건에서 새 그래프와 옛 그래프가 모두 0인 것을, 통제 조건에서 새 그래프가 6인 것을 함께 출력합니다. 두 줄을 나란히 보지 않으면 어느 쪽이 정상인지 알 수 없습니다.

측정 기록 원본은 Consilience 저장소의 docs/details/lifecycle-usability-audit-2026-07-31.md에 있습니다. 이 문서에는 반증으로 기각된 항목 목록도 함께 있으며, 같은 제안을 두 번 검토하지 않기 위한 것입니다.