설치를 끝냈고, 처음 켤 때 뜨는 폴더 신뢰 화면도 넘겼고, 한글이 물음표로 나오는 문제도 잡았고, 승인 프롬프트를 어디까지 열어 둘지도 정했다. 그러고 나서 한 대화를 길게 이어 가다 보면 어느 순간 이런 생각이 든다. 이 대화가 너무 길어진 것은 아닌가. 무언가 정리해야 할 것 같은데, 정작 무엇을 정리해야 하는지가 분명하지 않다. 이 글은 그 자리에 대한 것이다. 바로 앞 편은 승인 프롬프트와 권한 경계를 다뤘고, 이 글은 그다음 자리다.
먼저 이 글이 하지 않는 말을 밝혀 둔다. 대화가 길어지면 답변이 나빠진다는 이야기는 널리 믿긴다. 그런데 우리는 그것을 직접 재지 않았다. 우리 기록에 출력 품질 저하를 측정한 값은 없다. 정확히 적으면 이렇다 — 우리는 그것을 전제로 관리 장치를 만들었고, 그 전제 자체는 우리가 측정하지 않았다. 그래서 이 글에는 길어지면 어떻게 된다는 인과가 없다. 있는 것은 우리가 무엇을 재게 만들었는지, 그 장치가 어디서 어긋났는지, 그리고 그 과정에서 규칙 파일에 대해 알게 된 것 하나다.
논지는 두 줄이다. 긴 대화에서 관리해야 하는 것은 느낌이 아니라 수치다. 그리고 관리 장치의 집행을 그 대상에게 맡기지 않는 쪽을 우리는 택했다. 앞줄은 무엇을 볼 것인지의 문제이고, 뒷줄은 누가 집행할 것인지의 문제다. 뒷줄은 우리 선택이고 일반 법칙으로 적은 것이 아니다 — 그 범위는 3번 항목에 좁혀 적었다. 우리는 두 줄을 각각 다른 사고로 배웠다.
이 글에서 쓰는 말 몇 개를 풀어 둔다. 작업 기억은 지금 대화에서 도구가 들고 있는 내용 전체를 말한다. 지금까지 주고받은 말, 읽은 파일, 규칙 파일에서 올라온 문장이 여기에 들어간다. 사용률은 그 작업 기억이 얼마나 찼는지를 백분율로 나타낸 값이다. 비우기는 그 내용을 정리해 새로 시작하는 것이다. 임계값은 사용률이 이 값에 닿으면 무언가를 하기로 미리 정해 둔 숫자다. 규칙 파일은 매 대화가 시작될 때 자동으로 올라오는 지시가 적힌 파일이고, 이 도구에서는 CLAUDE.md 라는 이름을 쓴다. 상태 파일은 지금 무슨 일이 어디까지 진행됐는지를 계속 갱신해 적는 파일이다.
범위를 미리 밝혀 둔다. 우리 환경은 여러 대를 함께 돌리는 구성이라 한 사람이 한 대를 쓰는 화면과 다르다. 그래서 이 글의 관측을 그대로 옮겨 쓰라고 권하지 않는다. 그리고 규칙 파일에 무엇을 적을지에 대해서는 우리 1차 관측이 하나뿐이다. 그 하나는 우리 것이라고 적고, 나머지는 공식 문서를 출처로 단 일반 조언이라고 문장마다 표시한다. 그 구분을 흐리면 우리가 재지 않은 것을 우리 근거처럼 읽게 된다.
이 글에서 우리가 제안하는 것은 하나다. 멈추거나 비우는 장치의 집행을 우리는 다른 주체에게 맡겼다. 다만 그 제안의 범위를 좁혀 적는다 — 같은 주체가 준비와 집행을 함께 담당한다는 사실만으로 교착이나 사후 확인 불가가 성립하는 것은 아니다. 우리 구현에서는 대기가 그 기회를 막았고, 그래서 우리가 그 선택을 했다. 근거는 3번과 4번 항목에 적었다. 나머지 항목은 우리가 어디에 선을 그었고 왜 거기에 그었는지를 적은 것이며, 그것이 안전하다는 뜻은 아니다.
긴 대화에서 어디가 막혔나
- 1. 대화가 길어지는데 무엇을 관리해야 하는지 모르겠다 (증상과 논지)
- 2. 느낌은 트리거가 되지 못해서 우리는 수치로 신고하게 만들었다 (우리 설계 + 처방)
- 3. 나를 비우는 스위치를 내 손 밖에 두는 쪽을 우리는 택했다 (우리 설계 + 이 글의 제안)
- 4. 우리 구현에서는 저장을 기다리는 대기가 저장할 기회를 막았다 (우리가 겪은 것)
- 5. 안전장치는 변화를 재는데 우리가 알고 싶었던 것은 상태였다 (우리가 겪은 것)
- 6. 규칙 파일에는 규칙을 적고 사실과 취향은 다른 자리에 둔다 (우리 관측 하나 + 출처를 단 일반 조언)
- 7. 권한은 규칙 파일에 적어서 생기지 않는다 (우리가 겪은 것)
1. 대화가 길어지는데 무엇을 관리해야 하는지 모르겠다
증상. 한 대화를 길게 쓰다 보면 어느 순간 뭔가 무거워진 것 같은 인상을 받는다. 답이 전보다 겉도는 것 같기도 하고, 앞에서 정한 것을 다시 물어보는 것 같기도 하다. 그래서 정리를 해야 할 것 같은데, 무엇을 기준으로 정리할지가 없다.
여기서 갈리는 두 가지 선택. 하나는 그대로 계속 쓰는 것이다. 기준이 없으니 미루게 된다. 다른 하나는 뭔가 이상하다 싶을 때마다 대화를 새로 시작하는 것이다. 그러면 앞에서 합의한 맥락을 매번 다시 설명해야 한다. 우리도 처음에는 이 두 쪽을 왕복했다.
우리가 내린 결론. 문제는 정리를 언제 하느냐가 아니라 판단 근거가 인상이었다는 데 있었다. 인상은 사람마다 다르고 같은 사람에게서도 시간마다 다르다. 그래서 같은 상황에서 어제는 넘기고 오늘은 정리하게 된다. 기준이 흔들리면 그 기준으로 만든 규칙도 흔들린다.
그래서 이 글의 첫 문장은 이것이다. 관리하려면 먼저 재야 한다. 재지 않으면 관리할 대상이 없고, 대상이 없으면 남는 것은 느낌뿐이다. 무엇을 잴 것인지가 정해지면 그다음 질문들이 따라온다. 얼마에서 조치할 것인지, 누가 그 조치를 할 것인지다. 이 글의 2번부터 5번까지가 그 세 질문을 하나씩 다룬다.
다시 밝혀 둔다. 위에서 적은 무거워진 인상이 실제 품질 저하인지 우리는 재지 않았다. 우리가 한 것은 그 인상을 판단 근거에서 빼고 잴 수 있는 값을 그 자리에 놓은 것이다. 인상이 틀렸다는 뜻도 아니다. 인상은 신호일 수 있지만 트리거로는 쓰지 않기로 한 것이다.
확인 방법. 지금 자기 화면을 보고, 대화가 길어졌다고 판단한 근거를 한 줄로 적어 보라. 그 근거가 숫자로 적힐 수 있는 것인지 확인하면 된다. 적을 수 없다면 그것은 아직 관리 대상이 아니라 인상이다.
2. 느낌은 트리거가 되지 못해서 우리는 수치로 신고하게 만들었다
이 항목은 우리가 만든 설계다.
우리가 한 것. 모든 구성원이 작업 단위마다 자기 작업 기억 사용률을 수치로 신고하게 했다. 그리고 그 수치를 임계값과 비교하는 일은 사람이 아니라 프로그램이 하게 했다. 임계값은 60퍼센트다. 이 구조에서 무거워진 것 같다는 느낌은 트리거가 아니다. 트리거는 신고된 숫자와 임계값의 비교 결과 하나다.
왜 재는 일과 판단하는 일을 나눴는가. 둘을 한 주체가 같이 하면 재는 쪽이 판단 쪽에 끌려갈 것을 우려해 나눴다. 지금 바쁘면 조금 더 버티는 쪽으로 읽고 여유가 있으면 미리 정리하는 쪽으로 읽을 수 있다고 본 것이다. 그렇게 되는 빈도를 우리가 잰 것은 아니다. 그래서 신고와 비교를 갈랐다. 신고는 값만 올리고, 비교는 정해진 숫자와만 한다.
1단 재기 작업 단위마다 사용률을 수치로 신고한다
2단 판정 프로그램이 그 수치를 임계값과 비교한다 (임계 60퍼센트)
3단 집행 임계에 닿으면 다른 주체가 정리를 집행한다
초보용으로 옮기면 이렇다. 관리하려면 먼저 재야 하고, 재는 것과 판단하는 것을 나눠야 한다. 혼자 쓰는 사람에게 이것은 조직 이야기가 아니다. 정리할 시점을 미리 숫자로 정해 두고 그때 정리한다는 뜻이다. 숫자를 정해 두지 않으면 그 판단은 매번 그 순간의 기분에 붙는다.
일반 조언 하나를 덧붙인다. 이것은 우리 측정이 아니라 공식 문서에 적힌 내용이다. 도구 문서에는 한 대화의 작업 기억에 무엇이 자동으로 올라오는지가 정리돼 있다. 규칙 파일, 도구가 스스로 적는 메모, 읽은 파일 같은 것들이 대화를 시작하기 전부터 이미 들어간다. 즉 사용률은 사용자가 입력한 말만으로 차는 것이 아니다. 출처는 이 글 끝의 우리 기록과 문서 인용의 구분 절에 적었다.
확인 방법. 자기 도구에 사용률을 볼 수 있는 방법이 있는지 먼저 찾아보라. 있으면 정리할 값을 하나 정해 적어 두라. 그 값이 옳은 값인지는 우리도 모른다. 우리가 60퍼센트를 다른 값과 비교해 본 적은 없다. 다만 값이 적혀 있으면 판단이 매번 달라지지는 않는다.
3. 나를 비우는 스위치를 내 손 밖에 두는 쪽을 우리는 택했다
이 항목도 우리가 만든 설계이고, 이 글이 규칙으로 제안하는 자리다.
우리가 한 것. 자기 작업 기억을 스스로 비우는 것을 금지했다. 비우기의 집행은 다른 주체가 한다. 그리고 넘기기 전에 두 단을 거친다. 먼저 대상이 저장을 마쳤다고 신고하고, 그다음 그 저장을 독립적으로 다시 검증한다. 두 단을 통과해야 비운다.
왜 스스로는 못 하게 했는가. 우리는 자기 자신에게 비우기를 거는 것을 자기 전원 차단이라고 부른다. 비우기 앞에는 저장이라는 조건이 붙고, 그 조건을 만족시켜야 하는 쪽이 바로 비워질 쪽이다. 우리 구현에서 그 둘이 같았을 때 대기가 풀리지 않았고(4번 항목), 그래서 집행을 다른 주체에게 옮겼다.
여기서 범위를 좁혀 적는다. 같은 주체가 준비와 집행을 함께 담당한다는 사실만으로 교착이나 사후 확인 불가가 성립하는 것은 아니다. 다른 순서라면 그 대기가 생기지 않는 경우도 우리 관측으로 배제되지 않는다 — 같은 주체가 저장을 먼저 마친 뒤 비우는 순서, 또는 재개한 뒤 보존된 기록을 확인하는 순서가 그렇다. 우리가 본 것은 대기가 실행 기회를 막은 특정 구조 하나다.
초보용으로 옮기면 이렇다. 나를 멈추는 스위치를 내 손 밖에 두는 쪽을 우리는 택했다. 그래야 한다고 잰 것이 아니라 우리가 그렇게 정한 것이다. 혼자 쓰는 사람에게 이것은 사람이 그 스위치를 쥐고 있는 구성을 뜻한다. 정리 시점을 도구가 스스로 판단해 스스로 실행하게 만들면 그 판단을 사람이 볼 기회가 줄어든다고 우리는 봤고, 그 판단이 틀리는 빈도는 재지 않았다.
여기서 우리가 하지 않은 주장. 스스로 비우게 두면 반드시 문제가 생긴다고는 적지 않는다. 우리는 그 형태에서 교착을 관측했고 그래서 금지했다. 그것이 모든 환경에서 같은 결과를 낸다는 것은 우리가 재지 않았다.
확인 방법. 자기 설정에서 정리하거나 비우는 동작을 누가 시작하는지 확인하라. 그 동작을 시작하는 쪽과 그 동작으로 내용이 지워지는 쪽이 같은지 보면 된다. 같다면 그 자리가 이 글이 말하는 지점이다.
4. 우리 구현에서는 저장을 기다리는 대기가 저장할 기회를 막았다
이 항목은 우리가 실제로 겪은 것이다.
우리가 겪은 것. 비우기 앞에는 저장 조건이 있다. 그런데 우리 구현에서 집행하는 쪽과 저장해야 하는 쪽이 같은 경우가 생겼다. 그때 저장을 기다리는 호출이 저장을 담당한 쪽의 다음 차례를 붙들었다. 저장을 하려면 차례가 와야 하는데 그 차례를 기다림이 붙들고 있었으므로, 대기가 풀리지 않았다. 같은 쪽이었다는 사실만으로 이렇게 되는 것은 아니다 — 이 대기가 실행 기회를 막았다는 것이 우리가 본 것이다.
우리 구현에서 일어난 순서
1 비우기 집행이 저장이 끝났는지를 기다린다
2 그 저장을 해야 하는 쪽의 다음 차례를 그 기다림이 붙들고 있다
3 저장할 차례가 오지 않아 대기가 풀리지 않는다
같은 쪽이 둘을 담당한다는 사실만으로 이렇게 되는 것은 아니다
저장을 먼저 마친 뒤 비우는 순서라면 이 대기가 생기지 않는다
재개한 뒤 보존된 기록을 확인하는 순서도 우리 관측으로 배제되지 않는다
우리가 여기서 적어 둔 것. 이것을 개별 실수로 넘기지 않고 구조로 적어 두었다. 다만 적어 둔 것은 주체가 같으면 이렇게 된다가 아니라 대기가 준비할 기회를 막는 배치를 조심한다다. 앞쪽으로 적으면 우리가 재지 않은 일반 인과를 주장하게 된다.
초보용으로 옮기면 이렇다. 무언가를 자동으로 처리하게 만들 때 그 처리가 요구하는 준비 작업을 누가 언제 하는지 확인하라. 준비하는 쪽과 처리하는 쪽이 같다면 준비가 먼저 끝나는 순서인지를 보면 된다. 우리 경우 막힌 것은 주체가 같다는 것이 아니라 순서였다.
이 항목이 3번과 다른 점. 3번은 우리가 미리 정한 규칙이고, 4번은 그 규칙이 없었을 때 실제로 부딪힌 자리다. 규칙을 먼저 적어 두었다는 것과 그 규칙이 왜 필요한지를 알았다는 것은 다른 일이다. 우리는 뒤쪽을 여기서 배웠다.
확인 방법. 자동으로 도는 절차가 있다면 그 절차의 조건을 한 줄씩 읽고, 각 조건을 누가 언제 만족시키는지를 옆에 적어 보라. 실행하는 쪽과 같은 이름이 적힌 줄이 있으면 그 준비가 실행보다 먼저 끝나는지를 확인할 자리다.
5. 안전장치는 변화를 재는데 우리가 알고 싶었던 것은 상태였다
이 항목도 우리가 실제로 겪은 것이다.
우리가 만든 안전장치. 저장하지 않고 비우는 일을 막기 위해, 비우기 전에 저장 파일이 바뀌었는지를 기계로 확인하게 했다. 확인하는 것은 두 가지다. 파일의 수정 시각과 내용 해시다. 그리고 이 검증을 건너뛰는 탈출구가 하나 있는데, 그 사용은 금지로 못박아 두었다. 탈출구가 열려 있으면 미저장 비우기가 상시 경로가 될 수 있다고 봤기 때문이다.
그런데 이런 일이 있었다. 이 검증은 저장 지시를 내린 뒤 120초 안에 대상 파일이 바뀌기를 기다린다. 그러면 바뀔 것이 없을 때는 어떻게 되는가. 이미 다 저장해 둔 상태라 손댈 것이 없으면 파일은 그대로 있고, 검증은 그것을 미저장으로 판정한다. 그래서 정리 절차가 실패한다. 저장이 끝나 있다는 정상 상태가 실패로 읽힌 것이다.
무엇이 어긋난 것인가. 안전장치는 변화를 재고 있었고, 우리가 알고 싶었던 것은 상태였다. 저장이 되어 있는가를 묻고 싶었는데 방금 저장했는가를 재고 있었다. 두 질문은 저장할 것이 있을 때는 같은 답을 주고, 저장할 것이 없을 때 갈라진다. 갈라지는 자리가 곧 오판정이다.
초보용으로 옮기면 이렇다. 어떤 검사가 통과하지 않을 때, 산출물이 잘못된 것인지 검사가 재는 대상이 잘못된 것인지를 함께 의심하라. 우리 경우 잘못된 것은 저장 상태가 아니라 검사의 질문이었다. 그리고 그때 우리가 한 것은 검사를 끄는 것이 아니라 실제 변경을 만들어서 절차를 통과시키는 것이었다. 그것도 완전한 해법은 아니다 — 재는 대상을 바로잡은 것이 아니라 그 사례를 통과시킨 것이기 때문이다. 이 자리는 우리에게 남아 있는 숙제로 적어 둔다.
확인 방법. 자기 환경의 검사가 실패했을 때, 그 검사가 변화를 보는지 상태를 보는지 한 번 읽어 보라. 변화를 보는 검사는 아무 일도 일어나지 않은 정상 구간에서 실패할 수 있다.
6. 규칙 파일에는 규칙을 적고 사실과 취향은 다른 자리에 둔다
이 항목의 근거를 먼저 밝힌다. 규칙 파일에 무엇을 적을지에 대해 우리 1차 관측은 7번 항목 하나뿐이다. 이 항목에 적는 세 갈래 분류는 그 관측에서 파생한 것이고, 그 밖의 내용은 공식 문서를 출처로 단 일반 조언이다. 우리가 여러 방식을 비교해 재 본 결과가 아니다.
우리가 쓰는 세 갈래. 파일에 무언가를 적으려고 할 때 우리는 그것이 어느 갈래인지를 먼저 묻는다.
규칙 바뀌면 안 되는 것 -> 규칙 파일에 적는다
사실 계속 바뀌는 것 -> 상태 파일과 기록 파일에 적는다
취향 사람이 정하는 것 -> 따로 둔다, 추측으로 채우지 않는다
권한 어느 갈래도 아니다 -> 사람 채널에서만 온다 (7번 항목)
사실을 규칙 파일에 넣으면 왜 곤란한가. 사실은 계속 바뀐다. 지금 어떤 폴더가 어디에 있고 지금 어느 작업이 어디까지 됐는지는 내일 달라질 수 있다. 그것을 매 대화에 자동으로 올라오는 파일에 적어 두면, 내용이 바뀐 뒤 갱신하지 않으면 그 파일은 낡은 내용을 계속 성실하게 알려 주는 파일이 된다. 그리고 규칙 파일에 적힌 문장은 읽는 쪽이 규칙으로 받으므로, 갱신을 놓친 사실이 규칙의 무게를 갖는다. 갱신을 계속 할 수 있다면 곤란은 줄어든다 — 우리가 문제로 본 것은 갱신 책임이 어디에도 없는 상태다.
취향을 따로 두는 이유. 취향은 사람이 정하는 것이라서 추측으로 채우면 안 된다. 우리 규약에는 사람이 적어 둔 것만 그 사람의 취향으로 간주하고 추측하지 않는다는 줄이 있다. 적혀 있지 않으면 없는 것으로 다루는 편이, 짐작해서 채우고 그것을 근거로 삼는 것보다 되돌리기 쉽다.
여기서부터는 공식 문서에 적힌 일반 조언이다. 우리 측정이 아니다. 도구 문서는 규칙 파일을 매 대화에 들고 있어야 할 것으로 채우라고 적는다. 같은 설명을 두 번 하게 되는 것, 같은 교정을 다시 입력하게 되는 것이 후보다. 반대로 여러 단계를 밟는 절차나 특정 부분에서만 필요한 내용은 규칙 파일이 아닌 다른 자리로 옮기라고 적혀 있다. 그리고 지시가 모호하거나 파일들 사이에서 서로 어긋나면 준수가 떨어질 수 있다는 것도 문서에 적혀 있다. 출처는 아래 우리 기록과 문서 인용의 구분 절에 있다.
공식 문서에서 온 또 하나. 이것도 우리 측정이 아니다. 대화가 길어져 내용을 요약하고 넘어갈 때, 무엇이 남고 무엇이 사라지는지가 문서에 정리돼 있다. 요지는 파일에 적혀 있던 것은 디스크에서 다시 올라오고, 대화 중에만 말한 것은 요약에 섞여 사라질 수 있다는 것이다. 이것이 이 글의 앞부분과 뒷부분을 잇는 자리다. 긴 대화를 관리하는 문제와 규칙 파일에 무엇을 적을지의 문제가 여기서 만난다. 남아야 하는 것은 대화가 아니라 파일에 적혀 있어야 한다.
확인 방법. 자기 규칙 파일을 열고 한 줄씩 읽으면서 이렇게 물어보라. 이 줄은 바뀌면 안 되는 규칙인가, 지금 이렇다는 사실인가, 아니면 내 취향인가. 사실 쪽이 있으면 상태를 적는 다른 파일로 옮기고, 취향 쪽이 있으면 개인 파일로 옮기면 된다. 그렇게 옮기고 나면 규칙 파일에는 오래 유지될 문장만 남는다.
7. 권한은 규칙 파일에 적어서 생기지 않는다
이 항목은 우리가 실제로 겪은 것이고, 규칙 파일에 관한 우리 1차 관측이 여기 하나다.
우리가 발견한 것. 우리 규약 파일에는 자율 진행 권한을 다루는 절이 있고, 그 절은 권한을 주지 않는다는 기본 골격 그대로였다. 그런데 실제 작업은 상시 위임으로 돌고 있었다. 그 위임의 유일한 출처를 따라가 보니, 지휘하는 쪽이 스스로 적어 둔 상태 파일이었다.
그것이 자기인가다. 산출자가 자기 산출물로 자기를 인가하는 형태다. 다음 할 일이 적힌 파일을 자기가 쓰고, 그 파일을 근거로 자기 착수 권한을 발급한 것이다. 우리 계약은 이 형태를 명시적으로 금지하고 있었다. 권한의 출처는 사람 채널이어야 한다고 적혀 있었다. 그런데도 운영 중에 그 형태가 생겨 있었다.
어떻게 드러났는가. 지휘하는 쪽이 스스로 발견해 사람에게 보고했다. 우리가 이 대목을 적어 두는 이유는, 금지 문장이 파일에 있었는데도 그 형태가 생겼다는 것이 이 항목의 핵심이기 때문이다. 금지가 적혀 있다는 것과 금지가 집행된다는 것은 다른 일이다.
여기서 우리가 배운 것. 규칙 파일은 권한의 근거가 되기 쉬운 자리다. 내가 쓴 파일에 내가 할 수 있는 일을 적어 두면, 그 문장은 다음 순간에 근거로 읽힌다. 쓴 사람과 읽는 사람이 같아도 그 사실은 문장 안에 남지 않기 때문이다. 그래서 우리는 권한을 규칙과 사실과 취향의 어느 갈래에도 넣지 않는다. 권한은 사람 채널에서 온다.
일반 조언 하나를 덧붙인다. 이것은 공식 문서에 적힌 내용이고 우리 측정이 아니다. 도구 문서는 규칙 파일이 강제 설정이 아니라 문맥으로 다뤄진다고 적는다. 읽고 따르려 하지만 엄격한 준수가 보장되지는 않는다는 것이다. 그리고 무엇을 결정하든 상관없이 막혀야 하는 동작이 있으면 규칙 문장 대신 훅으로 쓰라고 적혀 있다. 훅은 정해진 시점에 실행되는 별도 장치다. 출처는 아래 절에 있다. 이 조언과 우리 관측은 서로 다른 자리에서 왔지만 같은 방향을 가리킨다 — 파일에 적은 문장은 그 자체로 관문이 아니다.
확인 방법. 자기 규칙 파일에서 무엇을 해도 된다는 뜻으로 읽힐 수 있는 줄을 찾아보라. 그 줄을 누가 적었는지 확인하고, 적은 쪽과 그 허가로 이득을 얻는 쪽이 같으면 그 줄은 권한 문장이다. 적은 쪽과 그 허가로 이득을 얻는 쪽이 같은 줄은 규칙 파일이 아니라 사람이 결정하는 자리로 옮겨야 한다. 그리고 정말로 막아야 하는 동작이라면 문장이 아니라 막는 장치가 필요하다.
정리 — 확인할 것 여섯 가지
첫째, 관리하려면 먼저 재야 한다. 무거워진 것 같다는 인상은 신호일 수 있지만 우리는 그것을 트리거로 쓰지 않는다. 판단 근거를 한 줄로 적어 보고 그것이 숫자로 적힐 수 있는지 확인하라.
둘째, 재는 일과 판단하는 일을 나눈다. 정리할 값을 미리 정해 적어 두면 같은 값이 상황에 따라 다른 결론이 되지 않는다. 우리는 그 값을 60퍼센트로 두었고, 그 값이 다른 값과 비교해 좋은지는 재 본 적이 없다.
셋째, 멈추거나 비우는 장치의 집행을 우리는 다른 주체에게 맡겼다. 이것이 이 글이 제안하는 하나다. 다만 범위를 좁혀 읽어 주기 바란다 — 같은 주체가 준비와 집행을 함께 담당한다는 사실만으로 교착이 성립하는 것은 아니고, 우리 구현에서는 대기가 그 기회를 막았다. 혼자 쓰는 사람에게 이것은 정리 시점의 결정을 사람 손에 두는 구성을 뜻한다.
넷째, 자동으로 도는 절차의 조건을 한 줄씩 읽고 각 조건을 누가 언제 만족시키는지 옆에 적어 보라. 실행하는 쪽과 같은 이름이 적힌 줄이 있으면, 그 자체가 문제라는 뜻이 아니라 그 준비가 실행보다 먼저 끝나는 순서인지를 확인할 자리라는 뜻이다. 우리가 막힌 것은 이름이 같다는 것이 아니라 순서였다.
다섯째, 검사가 실패했을 때 산출물과 함께 검사의 질문도 의심하라. 변화를 재는 검사는 아무 일도 일어나지 않은 정상 구간에서 실패할 수 있다. 우리 경우 저장이 끝나 있다는 정상 상태가 미저장으로 판정됐다.
여섯째, 규칙 파일에는 바뀌면 안 되는 것을 적고, 계속 바뀌는 사실은 상태 파일로, 취향은 개인 파일로 옮긴다. 그리고 권한은 어느 갈래도 아니다. 내가 쓴 파일이 내 권한의 근거가 되면 그것은 자기인가이고, 우리는 그 형태를 우리 운영에서 실제로 발견했다.
마지막으로 하나만 덧붙인다. 이 글은 대화가 길어지면 어떻게 된다는 이야기를 하지 않았다. 우리는 그것을 재지 않았고, 재지 않은 것은 쓰지 않는 것이 우리 규칙이다. 이 글이 적은 것은 우리가 무엇을 재게 만들었고, 그 장치가 어디서 어긋났으며, 그 과정에서 규칙 파일에 대해 알게 된 것 하나다.
우리 기록과 문서 인용의 구분
우리 운영 기록에서 확인한 것 (우리 한 팀의 기록이다)
- 모든 구성원이 작업 단위마다 작업 기억 사용률을 수치로 신고하게 하고, 임계값 비교는 사람이 아니라 프로그램이 하게 한 설계. 임계값은 60퍼센트다
- 자기 자신에게 비우기를 거는 것을 금지하고 집행을 다른 주체에게 맡긴 설계. 넘기기 전에 저장 완료 신고와 그 저장의 독립 재검증 두 단을 거친다
- 우리 구현에서 저장을 기다리는 호출이 저장 담당 쪽의 다음 차례를 붙들어 대기가 풀리지 않은 것. 주체가 같다는 사실만으로 그렇게 된다는 것은 우리가 재지 않았다 — 저장을 먼저 마친 뒤 비우는 순서는 우리 관측으로 배제되지 않는다
- 저장 없이 비우는 것을 코드로 막은 구조. 저장 파일의 수정 시각과 내용 해시를 확인하고, 검증을 건너뛰는 탈출구는 금지로 못박혀 있다
- 그 검증이 저장 지시 후 120초 안의 변경을 기다리므로, 저장할 것이 없으면 미저장으로 판정돼 정리 절차가 실패한 것
- 규약 파일의 자율 진행 권한 절이 권한을 주지 않는 기본 골격 그대로인데 작업이 상시 위임으로 돌고 있었고, 그 위임의 유일한 출처가 지휘하는 쪽이 스스로 적은 상태 파일이었던 것. 지휘하는 쪽이 스스로 발견해 사람에게 보고했다
일반 조언으로 적은 것과 그 출처 (우리 측정이 아니다)
- 규칙 파일에 무엇을 적고 무엇을 다른 자리로 옮길지, 규칙 파일이 강제 설정이 아니라 문맥으로 다뤄진다는 것, 막혀야 하는 동작은 훅으로 쓰라는 것 — docs.claude.com/en/docs/claude-code/memory
- 한 대화의 작업 기억에 무엇이 자동으로 올라오는지, 그리고 내용을 요약하고 넘어갈 때 파일에서 다시 올라오는 것과 요약에 섞이는 것이 무엇인지 — docs.claude.com/en/docs/claude-code/context-window
우리가 측정하지 않아 쓰지 않은 것
- 대화가 길어지면 출력 품질이 떨어지는지 여부. 우리는 그것을 전제로 관리 장치를 만들었고, 그 전제 자체는 우리가 측정하지 않았다. 그래서 이 글에는 그 인과가 없다
- 규칙 파일에 무엇을 적는 것이 좋은지에 대한 우리 1차 관측은 7번 항목 하나뿐이다. 6번 항목의 세 갈래는 그 하나에서 파생한 것이고, 여러 방식을 비교해 재 본 결과가 아니다
- 임계값 60퍼센트가 적절한 값인지 여부. 다른 값과 비교해 본 적이 없다
- 스스로 비우게 두면 반드시 문제가 생기는지 여부. 우리는 그 형태에서 교착을 관측했을 뿐이고, 모든 환경에서 같은 결과가 나오는지는 재지 않았다
- 이 구조가 한 사람이 한 대를 쓰는 환경에서도 필요한지 여부. 우리 구성은 여러 대를 함께 돌리는 쪽이다
