마지막으로 켠 날짜가 없으면 갖고 있는 게 아니다

「이미 갖고 있다」는 세 번 확인해야 하는 문장이다 — 설치돼 있나, 눌러 보면 산출이 나오나, 마지막으로 켠 날짜가 있나. 마흔 편을 뜯는 동안 이 셋을 한 칸으로 뭉뚱그린 대가를 여러 번 치렀다. 컨텍스트 예산을 재려고 같이 집어온 스킬은 설치일부터 확인일까지 24일 동안 한 번도 실행되지 않았고, 그것을 부를 명령은 애초에 만들어지지도 않았다(커맨드 37개 전수 확인, 2026-08-22 시점). 그런데 이 글이 값을 하는 자리는 그 한 건이 아니다. 같은 두 도구를 세 편이 차례로 지목했고, 세 번 다 안 돌렸다. 첫 편은 그 둘을 「이 조사가 남긴 1순위」로 적고 닫았고, 두 번째 편은 그 첫 편을 인용하면서도 같은 공백을 메우겠다며 다른 저장소를 뜯었고, 세 번째 편에서 그중 하나가 「설치 24일 · 실행 0회」로 다시 나왔다. 우연히 겹친 게 아니라 알고도 반복한 것이고, 그러면 이건 신호가 아니라 절차 실패다. 2층(보유 ≠ 작동)은 네 번 다 숫자는 맞았다에서 이미 다뤘으니 여기서는 한 문단으로 넘긴다. 이 글이 무게를 싣는 곳은 3층이다 — 눌러 보면 멀쩡히 도는 도구가, 아무도 안 눌러서 값이 0인 상태. 증상이 침묵이라 장부에는 계속 「있음」으로 남고, 그 「있음」이 다음 도입 판정의 근거가 되어 창고에 있는 물건을 밖에서 사 오자는 결론을 만든다.

이 글이 답하는 질문

• 내 설정에 뭐가 깔려 있는지 확인했는데, 그걸 근거로 「이미 있음」이라 적어도 되나
• 설치만 하고 안 쓰게 되는 이유는 무엇인가
• 같은 조사를 반년 뒤에 또 하게 되는 이유는 무엇인가
• 이미 있는 기능인데 모르고 새로 도입하는 일을 어떻게 막나
• 도구를 들이기 전에 재고 확인을 어디까지 해야 하나
• 스킬이나 도구의 마지막 실행 날짜를 확인할 수 있나
• 설치만 하고 안 돌린 도구를 실제로 어떻게 세나
• 남의 프리셋·설정 묶음을 복사해 쓰면 무엇이 문제인가
• 안 돌린 도구에서 결함을 찾았다 — 지금 고쳐야 하나
• 안 돌린 도구를 지워야 하나 남겨야 하나

남의 도구를 들일지 판정하는 절차 전체는 마흔 번 기각했고, 사유는 대개 대상 밖에 있었다에 있다. 이 글은 그 절차의 0단계인 재고 확인을 다룬다.

「이미 갖고 있다」는 세 번 다른 질문이다

보유·작동·실행 이력은 서로 다른 질문이고, 층마다 증상도 처방도 다르다. 1층은 목록을 보면 답이 나오고, 2층은 눌러 봐야 나오고, 3층은 그 도구가 남긴 흔적을 찾아야 나온다.

1층은 값이 싸다. 스킬 99개가 등재돼 있고 전수 스캔이 가능하니 「깔려 있나」는 몇 초면 답이 나온다. 그래서 1층은 자동으로 채워지고, 자동으로 채워지는 칸이 곧 그 표의 기본값이 된다.

2층은 한 번 눌러 봐야 한다. 여기서 쓸 값은 항목 0 · 파일 0 · 관측기 훅 0 하나뿐이고, 왜 그렇게 됐는지와 그 표의 나머지 칸이 어떤 상태인지는 기준선 편이 소유한다. 이 글에서 2층은 여기서 끝난다.

3층은 다르다. 도구가 껍데기라서 0인 게 아니라, 멀쩡히 도는 도구를 아무도 안 눌러서 0이다. 컨텍스트 예산 측정 스킬은 설치 07-29 부터 확인 시점 08-22 까지 24일간 실행이 0회였고 산출물도 0건이었다. 고장 난 것이 아니다 — 부를 일이 한 번도 없었을 뿐이다. 그래서 1층과 2층의 검사로는 이 층이 절대 안 걸린다. 목록에도 있고, 누르면 돌기 때문이다. 3층을 보려면 「이 도구가 돌았다면 무엇이 남았어야 하나」를 먼저 정하고 그것을 찾아야 하는데, 그 질문은 자동으로 떠오르지 않는다.

세 층은 처방도 다르다. 1층이 비면 설치하면 되고, 2층이 비면 고치면 되고, 3층이 비면 켜야 한다. 셋 중 마지막 하나만 도구를 손대지 않는 처방이라, 도구를 만지는 일에 익숙한 사람일수록 3층에서 헛수고를 한다 — 멀쩡한 것을 뜯어보게 된다.

여기서 값을 치른 교훈은 대조표의 칸 수다. 한 칸이 셋을 뭉갠다. 「있음」이라고 쓸 때 필요한 칸은 하나가 아니라 셋이고, 칸이 하나면 세 층의 차이가 아니라 세 층의 존재 자체가 사라진다.

실행 이력이 0인 이유는 게으름이 아니라 「실행형」이라는 형태다

3층 실패는 도구가 고장 나서 일어나지 않는다. 잘 도는 도구가 한 번도 호출되지 않은 상태이고, 그래서 에러도 경고도 안 난다. 실제로 0이 되는 형태는 셋이었고, 셋 다 의지로는 안 고쳐진다.

① 실행형. 사람이 돌려야만 도는 형태다. 점검 스킬이 이미 셋이나 있는데 왜 결함을 못 잡았나를 따져 보니 답이 그것이었다 — 셋 다 실행형이고, 결함이 생긴 시점부터 그 스캔까지 아무도 안 돌렸다. 그래서 순증은 새 도구가 아니라 「언제 도느냐」였다.

② 진입점 부재. 도구는 있는데 부를 방법이 없는 형태다. 컨텍스트 예산 측정 스킬을 받쳐 줄 슬래시 커맨드가 아예 만들어지지 않았다 — 커맨드 37개를 전수 확인해도 없었다. 스킬 문서는 멀쩡히 있고 내용도 맞는데, 그것을 세션에서 꺼낼 손잡이가 없었다. 이 형태가 특히 나쁜 것은 도구를 만든 사람과 진입점을 만들 사람이 같은데 순서가 갈린다는 점이다. 도구를 만들 때는 「나중에 부르면 되지」로 넘어가고, 부를 일이 생겼을 때는 그 도구가 있다는 것을 잊는다.

③ 대가 부재. 안 돌아도 아무 일도 안 나는 형태다. 내가 만든 증류 파이프라인이 그랬다 — 앞단은 몇 달치를 성실히 쌓았고 뒷단은 한 번도 돌지 않았는데, 몇 달 동안 아무도 몰랐다. 뒷단이 안 돌면 산출 파일이 안 생길 뿐이고 세션은 멀쩡히 돌기 때문이다. 에러가 안 났다는 것이 여기서는 나쁜 소식이다. 그리고 이 형태는 진단까지 틀리게 만든다. 그 편의 초기 진단은 「관찰이 안 쌓인다」였는데 관찰은 20.6MB 나 실재했고, 진짜 원인은 뒷단 미가동이었다. 진단대로 고쳤으면 훅을 손보느라 시간을 쓰고 증류기는 그대로 죽어 있었을 것이다 — 대가가 없는 실패는 증상이 없어서, 원인을 짚을 단서도 같이 없다.

같은 편에 반대 사례가 나란히 있다. 손으로 쓰는 단순한 메모리 파일은 매 세션 자동 주입되어 지금도 돈다. 죽은 쪽이 훨씬 정교했다 — 훅으로 전부 자동이었고 설계도 촘촘했다. 두 채널의 차이는 품질이 아니라 주입 지점이 있느냐였다. 단순한 쪽은 세션이 시작될 때마다 강제로 읽히고, 정교한 쪽은 사람이 부를 때만 돌게 돼 있었다.

셋을 나란히 놓으면 공통점이 보인다. 어느 것도 의지 문제가 아니다. 실행형은 사람의 기억에 의존하고, 진입점 부재는 손잡이가 없고, 대가 부재는 안 해도 벌이 없다. 「다음엔 꼭 돌리자」로 고쳐지는 항목이 하나도 없다.

여기서 값을 치른 교훈은 관리 목록의 모양이다. 3층이 0인 도구는 「고장」 목록에 안 올라온다. 고장 목록으로만 관리하는 한 이 층은 영영 안 보인다. 그리고 3층을 채우는 방법은 도구를 고치는 것이 아니라 트리거를 붙이는 것이다 — 품질과 실행 이력 사이에는 상관이 없었다.

세 번 지목했고 세 번 다 안 돌렸다

3층 공백은 우연한 게으름이 아니라 재발하는 구조다. 뒤 편이 앞 편을 명시적으로 인용하면서도, 같은 두 도구를 안 돌린 채 다음 조사를 열었다.

1차. 스킬 285개짜리 상류 저장소를 뜯은 편이 마지막 줄에 이렇게 적고 닫았다 — 「컨텍스트를 깎는 도구 둘을 반년 전에 깔아 두고 한 번도 안 돌렸다. 그걸 돌리는 게 이 조사가 남긴 1순위다」. 그 조사에서 실제 도입은 285개 중 1개였다.

2차. 모델 제작사가 낸 코딩 에이전트 하네스를 뜯은 편에서 수확 후보 다섯 중 셋이 정확히 그 두 스킬에 부딪혀 무너졌다. 최종 수확은 0종. 그 편은 앞 편을 인용하며 「같은 두 도구입니다. 1순위라고 적어 놓고 안 돌린 채, 같은 공백을 메우겠다며 다른 레포를 뜯었습니다」라고 스스로 적었다.

3차. 프롬프트 조립 프리셋 일곱 벌을 뜯은 편에서 그중 하나가 「설치 24일 · 실행 0회」로 다시 나왔다. 최종 수확 4종 → 0종. 그 편도 「이번이 세 번째 라운드였습니다」라고 적었다.

두 도구가 어떤 상태였는지는 2차에서 확정됐다 — 한쪽은 도입 메모 한 줄이 유일한 흔적이었고, 다른 한쪽은 자기가 남기기로 한 것을 하나도 안 남겼다(어떻게 확정했는지는 아래 「산출물의 부재로 센다」 절에 있다). 셋을 죽인 것이 바로 그 둘이었으니, 2차의 수확 0은 대상이 부실해서 나온 값이 아니다 — 내 쪽 서랍이 비어 있어서 나온 값이다. 대상을 아무리 잘 골라도 이 값은 안 바뀐다.

세 대상은 서로 아무 관계가 없다. 스킬 모음집, 코딩 에이전트 하네스, 프롬프트 조립 프리셋 — 만든 곳도 하는 일도 다르다. 공통점은 대상이 아니라 내 서랍이었다. 그래서 한 분류만 지켜보는 감시로는 이 반복이 안 잡힌다. 세 편은 원장에서 각각 다른 칸에 들어가 있고, 셋을 잇는 것은 「같은 두 도구를 지목했다」는 사실 하나뿐이다.

왜 반복됐는지도 분명하다. 기록은 남았는데 그 기록을 읽는 계기가 없었다. 1차의 마지막 줄은 발행됐고 검색도 되고 2차가 실제로 인용까지 했다. 그런데 인용한 것과 실행한 것은 다르다 — 2차는 그 문장을 근거로 「내 쪽 공백」을 확인하는 데 썼지, 「그럼 지금 돌리자」로 쓰지 않았다. 조사를 여는 동력과 서랍을 여는 동력이 다르고, 앞의 것만 매번 작동했다.

여기서 값을 치른 교훈은 반복 자체가 신호라는 것이다. 같은 도구가 서로 다른 조사에서 두 번 이상 「이미 있음」의 근거로 등장하면 그건 자산 신호가 아니라 부채 신호다. 자산이면 산출물이 쌓여 있어야 하는데 세 번 다 0이었다. 그리고 기록해 두는 것만으로는 아무것도 발동하지 않는다 — 두 번째 편은 앞 편을 읽고 인용까지 하고서도 그 1순위를 안 돌렸다. 읽히는 기록과 발동하는 기록은 다른 물건이고, 이 셋은 전부 앞쪽이었다.

1층만 보고 판정하면 창고에 있는 물건을 밖에서 사 온다

재고를 1층으로만 읽으면 두 방향으로 다 틀린다. 없는 것을 있다고 적어 도입을 기각하고, 있는 것을 모른 채 같은 것을 밖에서 찾는다.

착수 전에 세 줄만 확인하면 대부분이 걸린다. ① 설치돼 있나 ② 산출물이 있나 ③ 부를 진입점이 있나. ①만 보면 안 도는 것을 「있음」이라 적게 되고, ②가 3층을 잡고, ③이 왜 0인지를 알려 준다.

이 셋을 안 돌려서 실제로 난 일이 셋 있고, 셋 다 내 쪽 문서 어딘가에 답이 이미 있었다. 코딩 에이전트 하네스에서 수확 후보 다섯이 0종이 됐는데 셋은 이미 서랍에 있던 것이었고 — 그러나 안 돌던 것이었고 — 나머지 둘은 「기법 수입」이 아니라 두 줄 수정으로 접혔다. 어떤 에이전트를 코드까지 읽고 기법 넷을 건졌는데 그중 1등이 재발견이었다 — 닷새 전 같은 대상을 분석한 내 리포트에 적용처와 재개 조건까지 붙어 이미 있었다. 링크를 전부 모아 검색되게 만들어 둔 게 있는데도 안 열어 봤다. 기법 0종으로 끝난 어떤 조사는 기각 사유가 내 프로젝트 문서에 이미 적혀 있었다 — 그 대상이 파는 기능이 내 화면 구조에서는 애초에 성립하지 않는다는 사실이었다.

밖에서 오는 추천도 같은 문제를 겪는다. 44초짜리 추천 릴 하나에 도구 네 개가 들어 있었고, 그중 둘은 내가 이미 뜯어서 기각한 것이었다.

세 사고에 공통점이 있다. 셋 다 대상 쪽 자료를 더 읽어서는 안 잡힌다. 내 설정 파일을 열거나, 내가 닷새 전에 쓴 글을 열거나, 내 프로젝트 문서를 열어야만 잡힌다. 그런데 조사를 시작할 때 자연스럽게 여는 것은 대상 쪽이다 — 그쪽이 새롭고 재미있기 때문이고, 내 서랍은 이미 안다고 믿기 때문이다. 「이미 안다」가 정확히 1층의 착각이다.

여기서 값을 치른 교훈은 검색 가능성이 열람을 만들지 않는다는 것이다. 링크를 전부 모아 검색되게 만들어 둔 창고가 실제로 있는데, 세 번 다 안 열었다. 찾을 수 있게 만드는 일과 실제로 찾아보는 일은 다른 일이고, 앞의 것을 아무리 잘해도 뒤의 것은 안 따라온다. 그래서 이 세 줄은 「기억해 두자」가 아니라 착수 문서의 첫 세 줄로 박혀야 한다 — 어디에 적어 둘지를 정하지 않으면 이 절도 열람 안 되는 기록 하나가 더 늘 뿐이다.

3층은 로그가 아니라 산출물의 부재로 센다

마지막 실행 날짜를 직접 기록하는 도구는 거의 없다. 대신 그 도구가 만들기로 한 파일·폴더·항목이 있는지를 보면 된다. 이게 제일 싸고 대개 결정적이다.

두 가지를 먼저 갈라 둔다. 첫째, 이건 사전 게이트가 아니라 사후 감사다. 종료 코드 0으로 끝난 「빈 성공」을 잡는 게이트는 실행 직후 산출물을 보고 그 실행을 통과시킬지 정하는 장치이고, 이 절은 실행이 있었는지 자체를 나중에 추정하는 일이다. 같은 관찰(파일이 있나)에서 서로 다른 것을 읽는다. 둘째, 이건 새 축이 아니라 증거 2등급을 실행 이력 감사에 쓴 것이다 — 결정론 코드가 확인하는 크기·개수·해시. 그러면 「1층(설치돼 있다)은 몇 등급인가」에도 답이 붙는다. 훨씬 아래다.

실제로는 이렇게 걸렸다. 어떤 정리 스킬은 자기 문서에 「이 파일과 이 폴더를 만든다」고 적어 두고 둘 다 안 만들어 놨다 — 로그를 한 줄도 안 보고 실행 0이 확정된다. 도구가 스스로 약속한 산출물이 그 도구를 감사하는 자가 된 셈이다. 관찰 파이프라인은 127파일 20.6MB 는 있는데 산출된 본능이 0개였다. 채널의 앞쪽은 살아 있고 뒤쪽만 죽어 있다는 것까지 이 방법으로 갈렸다 — 로그를 뒤졌으면 「훅이 실패한다」는 오진에서 못 벗어났을 것이다. 4단계 사다리의 마지막 칸은 항목 0 · 파일 0 · 훅 0이었다. 측정 스킬은 산출물이 0건이었고, 부를 커맨드가 없다는 사실을 커맨드 37개 전수 확인으로 확정했다.

이 방법이 로그보다 나은 이유는 셋이다. 첫째, 값이 싸다 — 파일이 있는지 보는 데 몇 초면 되고 판단이 안 들어간다. 둘째, 거짓 통과가 잘 안 난다 — 도구가 만들기로 한 산출물이 없으면 그 도구가 돌았다고 말할 방법이 없다. 셋째, 어디까지 돌았는지가 갈린다 — 관찰 파이프라인에서 앞쪽 20.6MB 는 있고 뒤쪽 산출은 0이었다는 사실이 채널의 어느 마디가 끊겼는지를 그대로 알려 줬다. 로그를 뒤졌다면 「훅이 실패한다」는 오진을 확인해 주는 로그만 찾았을 것이다.

한계도 분명하다. 산출물을 아예 안 만드는 도구에는 안 통한다. 그런 도구는 이 방법으로 세면 「안 돌았다」와 「돌았는데 흔적이 없다」가 구분되지 않는다.

여기서 값을 치른 교훈은 설계 책임의 소재다. 산출물을 안 남기는 도구는 자기가 돌았는지 증명할 수 없다. 그건 감사의 어려움이 아니라 그 도구의 설계 결함이다 — 3층을 셀 수 없게 만든 것도 도구 쪽이다. 그래서 새로 만드는 것에는 「돌면 흔적이 남는가」를 요구사항으로 넣는다. 한 줄짜리 실행 로그 하나면 충분하고, 그게 없으면 반년 뒤에 그 도구의 값을 아무도 못 센다.

남의 프리셋을 복사해 들이면 3층이 처음부터 비어 있다

복사로 들어온 것은 「내가 쓰려고 넣은 것」이 아니라 「묶음에 딸려 온 것」이라 실행 이력이 처음부터 0이다. 그런데 1층에는 멀쩡히 올라 있어 다음 판정의 근거가 되고, 비용은 매 턴 상시 로드로 청구된다.

내 설정 자체가 그렇게 만들어졌다. 스킬 55/98 · 룰 14 · 훅 10/12 가 남의 프리셋 묶음에서 왔고 자작 훅은 둘뿐이다. 절반이 넘게 남의 것인데, 그 절반이 언제 마지막으로 돌았는지는 어디에도 안 적혀 있다. 복사할 때 실행 이력이 같이 오지 않기 때문이고, 그래서 이 묶음의 3층은 처음부터 빈칸이 아니라 아예 칸이 없다.

들어온 것들의 상태는 남의 자를 두 번 대 보고 알았다 — 한 번은 강의의 자가채점 6항목으로, 한 번은 다른 레포의 교리 문서로. 둘 다 결과가 같은 방향이었다. 자동 호출이 아예 안 되는 스킬이 나왔고, 호출 축이 걸린 것은 96개 중 하나였다. 세션 첫 요청에 상시 주입되는 총량은 69,871자 — 전역 룰 24,407 · 자동 메모리 색인 19,124 · 작업지침 2,669 · 스킬 설명 23,671.

비용의 방향이 중요하다. 1층은 공짜로 늘고 비용은 매 턴 청구된다. 스킬을 하나 복사해 넣는 데는 몇 초가 들지만, 그 설명은 그 뒤 모든 세션의 첫 요청에 얹힌다. 그래서 복사 도입은 처음에 이득처럼 보이고 시간이 지날수록 손해가 된다 — 그리고 그 손해는 어느 한 순간에 드러나지 않아서 아무도 되돌리지 않는다.

500줄을 넘긴 16종은 알고만 있기로 했다. 상류에서 온 것이라 쪼개면 다음 동기화 때 충돌한다. 고칠 수 있는 것과 알고 있어야 하는 것은 다르고, 후자를 전자인 척하면 목록만 늘어난다. 스킬 분모가 글마다 다른 것도 적어 둔다 — 폴더 102 · 문서 96 · 등재 98~99이고, 측정 시점이 다르기 때문이다. 분모가 흔들린다는 사실 자체가 1층조차 한 번에 안 세어진다는 증거다.

여기서 값을 치른 교훈은 장부와 자산의 차이다. 복사 도입은 1층을 아주 빠르게 채우고 3층은 전혀 채우지 않는다. 그래서 서랍이 커질수록 「이미 있음」이라 적을 근거는 늘고 실제 값은 줄어든다 — 자산이 늘어난 게 아니라 장부만 늘어난 것이다. 남의 프리셋을 통째로 들일 때 실제로 사는 것은 도구가 아니라 장부 항목이고, 그 항목들은 다음 판정에서 「이미 있음」으로 되돌아온다.

안 돌린 도구는 고치기 전에 켠다 — 처분은 셋이고 기본값은 삭제가 아니다

3층이 0인 도구에서 결함을 찾았을 때, 그 결함의 실제 손해는 0이다. 손해는 결함 크기 × 실행 횟수인데 뒤가 0이기 때문이다. 그래서 순서는 고치기가 아니라 켜기다.

실제로 그렇게 처리한 것들이다. ① 측정 스킬의 산식이 오버헤드를 37.6배 과대계상했다. 눈금이 37배 틀린 자다. 그런데 그 산식이 잘못 유도한 판단은 0건이었다 — 한 번도 안 돌았기 때문이다. 그래서 이 정정은 「수리」가 아니라 「흡수」로 강등됐다. 눈금이 얼마나 틀렸느냐보다 그 자를 몇 번 댔느냐가 손해를 정한다. ② 대조군 arm 을 붙이려던 도구 둘이 실제 실행 0회였다 — 한 번도 안 돌린 도구에 계측을 붙이는 것은 부채라, 보류하고 재개 조건을 「처음 돌릴 때 같이」로 적었다. 수확 3종이 1종이 된 자리다. ③ 죽은 훅 두 개를 끄고 20.6MB 와 빈 껍데기 127개를 지웠다. 지울 때도 무엇을 지웠는지와 시크릿 스캔 0건을 같이 남겼다 — 다만 그 0건은 운이지 설계가 아니었다.

이미 같은 판단을 한 자리도 있다. 어떤 정렬 도구를 기각한 사유가 「같은 일 하는 도구가 이미 둘 있고 둘 다 안 돌렸다. 세 번째는 해결이 아니라 미룸이다」였다. 3층이 0인 상태에서 네 번째를 들이는 것은 도입이 아니라 회피다. 그런데 그렇게 적어 놓고도 같은 공백에 대한 조사가 두 번 더 열렸다 — 판단을 내리는 것과 그 판단대로 사는 것은 다른 일이다.

처분 ③(삭제)에는 조건이 하나 붙는다. 지울 때 무엇을 왜 지웠는지를 같이 남긴다. 삭제는 3층뿐 아니라 1층까지 지우는 일이라, 기록이 없으면 반년 뒤에 그 자리가 「원래 없던 것」으로 보인다. 그러면 같은 것을 밖에서 다시 사 오게 되고, 그건 이 글이 처음부터 막으려던 바로 그 경로다.

여기서 값을 치른 교훈은 순서와 판정의 구분 둘이다. 「고칠 필요 없다」가 아니라 「고치기 전에 켜야 한다」다 — 안 돌린 도구를 개선하는 작업은 산출이 0인 채로 유지비만 늘리고, 켜기 전에는 무엇을 고쳐야 하는지도 알 수 없다. 그리고 기각과 삭제는 다른 판정이다. 삭제는 3층뿐 아니라 1층까지 지우는 것이라, 재개 조건이 없으면 다음번에 같은 것을 밖에서 다시 사 오게 된다.

못 한 것

• 「마지막으로 켠 날짜」를 실제로 기록하는 장치는 아직 없다. 산출물 존재 여부라는 대리 지표를 썼는데, 이건 날짜가 아니라 「한 번이라도 돌았나」만 답한다. 여섯 달 전에 한 번 돌고 그 뒤로 안 돈 도구는 이 방법으로 통과한다. 그리고 산출물을 안 남기는 도구는 아예 못 센다 — 그런 도구가 내 서랍에 몇 개인지도 안 세어 봤다.
• 스킬 99개 전수의 3층을 세지 않았다. 세 편에서 걸린 네 개뿐이고, 4단계 사다리의 「동등」 네 칸 중 눌러본 것도 한 칸이라 나머지는 지금도 장부다. 이 글은 「세는 법」을 말하면서 정작 전수를 안 셌다 — 표본이 「어쩌다 걸린 것」이라 3층이 0인 비율도 못 낸다.
• 3층을 채운 뒤의 이득을 못 쟀다. 상시 주입 69,871자를 빼는 훅이 없어 대조군 제작 자체가 불가능하다 — 「문제 없음」이 아니라 측정 불가다. 「3층을 채우면 N% 좋아진다」는 문장은 이 글에 하나도 없고, 없는 게 맞다. 대조군이 생기기 전까지는 이 글의 권고도 근거가 「반복을 세 번 관측했다」까지다.
• 모든 실측이 개인 설정 하나에서 나온 값이다. 윈도우 PC 한 대의 에이전트 설정이고, 팀이나 조직 규모에서 같은 3층이 성립하는지는 안 재봤다. 여럿이 쓰는 도구는 「누군가는 돌렸다」가 성립해서 3층 공백이 훨씬 늦게 드러날 수도 있고, 반대로 아무도 자기 것이라 여기지 않아 더 빨리 죽을 수도 있다. 둘 중 어느 쪽인지 모른다.
• 처분 ③(삭제)의 사후 손실을 추적하지 않는다. 지운 것 중 나중에 필요해진 게 있었는지 모른다. 삭제를 권하면서 그 비용을 못 재고 있고, 이 글의 권고 중 되돌리기가 제일 비싼 것이 하필 그것이다.
• 이 글이 권하는 감사는 「몇 개가 안 돌고 있나」까지만 답한다. 「그래서 무엇을 잃고 있었나」는 대조군이 없어 답이 없다. 안 돈 도구 넷을 찾았지만 그것들이 돌았다면 무엇이 달라졌을지는 못 말하고, 그 상태로 발행한다.