1개를 지우러 갔다가, 중복이 늘어났습니다 — 계측기가 정본화를 벌준 이야기 (에이전트 하네스 3주차)

📝 한 줄 요약 (바쁘면 이것만)

2주차 글 마지막에 저는 "3주차에는 이번 주에 확정한 판정을 실제로 실행하겠다"고 썼습니다. 중복으로 판정된 문서 1개를 없애고, 두 벌인 코드를 한 벌로 합치고, 그 다음에 같은 자로 다시 재겠다는 약속이었습니다.

약속은 다 지켰습니다. 그런데 손대기도 전에 지표가 나빠져 있었습니다.

병합을 시작하기 전, 지난주에 쓴 측정 스크립트를 그냥 한 번 돌려봤습니다. 3곳 이상에서 겹치는 개념이 지난주 보고한 4개에서 6개로 늘어 있었습니다. 아무것도 안 했는데요. 범인은 지난주에 제가 한 정리 작업 그 자체였습니다.

그리고 병합을 마치고 다시 쟀을 때, 계측기가 저를 한 번 더 잡았습니다. 없애기로 한 문서의 묘비명이, 제가 없애려던 바로 그 실수를 다시 저지르고 있었습니다.

🎯 이런 분께 추천해요

• 문서나 프롬프트를 정리하고 나서 "정말 좋아졌나?"를 숫자로 확인하고 싶은 분

• 개선 작업을 했는데 지표가 오히려 나빠져서 당황해 본 적 있는 분

• "숫자가 안 예쁘면 채점 기준을 고쳐도 되나?"의 경계선이 궁금한 분

• AI에게 "이거 중복 정리해줘"를 시켜놓고 결과를 검수할 방법이 없어 답답한 분

• 무언가를 없애는 작업(폐지·통합·아카이빙)을 앞두고 있는 분

😫 문제 상황 (Before)

2주차에 저는 검증 문서 4개의 겹침을 세 가지 방식으로 재고 이렇게 판정했습니다.

• 2개는 사실상 같은 문서다(문장 유사도 0.9, 실행 명령줄까지 동일) → 하나를 없앤다

• 여러 문서에 흩어진 공통 원칙 4개는 상위 문서(우산)로 올린다

• 우산은 만들었지만 아직 실제로 배치하지 않았다

그리고 정직하게 적었습니다. "우산은 지금 작업 폴더 안의 문서 하나일 뿐이다. 배치하고 자식 문서들을 참조로 바꾸기 전까지는, 정본이 하나 더 늘어난 것에 불과하다."

3주차의 숙제는 그래서 명확했습니다. 판정을 실행으로 옮기는 것. 없애기로 한 문서를 실제로 없애고, 두 벌인 코드를 한 벌로 합치고, 같은 스크립트로 다시 재서 좋아졌는지 확인하는 것.

숙제가 명확하니 지루할 줄 알았습니다. 아니었습니다.

🛠️ 사용한 도구

🔧 작업 과정

0단계: 손대기 전에 되돌릴 길부터

문서 5개 폴더를 통째로 복사하고, 파일마다 지문(해시)을 떠서 목록을 만들었습니다. 그리고 원본과 사본의 지문이 전부 일치하는지 다시 확인했습니다. 17개 파일 전량 일치.

이걸 먼저 한 이유는 단순합니다. 이번 주 작업은 지우는 작업이고, 지우는 작업은 잘못됐을 때 되돌릴 방법이 없으면 손대면 안 되기 때문입니다.

1단계: 병합도 안 했는데 지표가 나빠져 있었다

작업을 시작하기 전에 습관처럼 측정 스크립트를 한 번 돌렸습니다. 기준선을 잡아두려고요.

3곳 이상에서 공유되는 개념
  2주차에 보고한 값: 4개
  지금 다시 잰 값:   6개

병합은 시작도 안 했습니다. 그런데 중복이 늘어 있었습니다.

원인을 찾는 데는 오래 걸리지 않았습니다. 2주차 후반에 저는 우산을 실제 폴더에 배치하면서, 자식 문서 4개의 머리에 이런 안내를 박았습니다.

이 문서는 우산의 3단계를 담당합니다. 통과조건과 아래 공통 개념의 정본은 우산에 있습니다. | 공통 개념 | 비고 | | 게이트/통과기준, 정답 위조, 옆방 검증, 재측정 의무 | … |

정확히 제가 의도한 정리 작업입니다. 각 문서에서 원칙을 중복 서술하는 대신, 위를 가리키게 만든 것이죠.

그런데 저 안내문에는 필연적으로 개념어가 들어갑니다. "게이트", "위조", "옆방", "재측정". 그리고 제 측정 스크립트는 참조 한 줄과 정본 서술 한 벌을 똑같은 무게로 셉니다.

그래서 중복을 없앤 행동이, 계측기 눈에는 중복 증가로 보였습니다.

ALT

한국어 텍스트가 포함된 한국어 웹사이트 스크린샷

함정 1 — "지표가 나빠졌으니 채점기를 고치자"의 위험한 유혹

여기서 손이 근질거립니다. 스크립트 몇 줄만 고치면 숫자가 예뻐지니까요.

그런데 2주차에 제가 우산에 직접 박아둔 규칙이 있었습니다.

채점 스크립트는 결과를 보기 전에 고정한다. 나쁜 숫자가 나오면 산출물보다 채점기를 먼저 열되, 기준은 조이는 방향으로만 수정한다.

제 규칙이 저를 막아섰습니다. 그래서 갈라야 했습니다. 지금 계측기를 여는 것은 부정행위인가, 정당한 수리인가?

판정 근거는 이렇습니다. 이번에 바뀐 건 결과가 아니라 재는 대상의 성질입니다. 같은 문장이 "정본 서술"에서 "참조 포인터"로 바뀌었는데, 계측기는 그 둘을 구분하는 눈이 아예 없었습니다. 숫자가 마음에 안 들어서 기준을 낮추는 것과, 없던 구분선을 새로 긋는 것은 다릅니다.

다만 부정행위로 미끄러지지 않게 안전장치를 세 개 걸었습니다.

1. 기존 축을 느슨하게 고치지 않는다. 원래 숫자를 그대로 계속 출력한다.

2. 인용 표시(>)로 시작하는 줄을 제외한 두 번째 축을 추가한다.

3. 두 축을 나란히 보고한다.

두 숫자가 갈리면, 그 차이가 곧 "정본 서술에서 참조 포인터로 대체된 양"입니다. 없애는 대신 하나를 더 보태는 방식이라, 유리한 숫자만 남길 수가 없습니다.

여기서 나온 명제가 이번 주 가장 쓸모 있는 문장이었습니다.

계측기가 정본과 포인터를 같은 무게로 세면, 정본화 작업은 지표를 악화시킨다.

문서 통합·중복 제거를 숫자로 관리하려는 분이라면, 이걸 먼저 확인하셔야 합니다. 안 그러면 잘한 일을 못한 일로 채점하게 됩니다.

2단계: 합치기 전에 "안 겹치는 것"부터 찾았다

이제 본 작업입니다. 없앨 문서의 코드 두 개를 남길 문서의 코드 한 개로 합치는 일.

여기서 통합을 "한쪽 지우기"로 하면 안 됩니다. 없앨 쪽에만 있는 기능이 있으면, 통합이 아니라 기능 삭제가 되니까요. 그래서 두 코드를 나란히 놓고 기능을 대조했습니다.

없앨 쪽에만 있던 기능이 두 개 나왔습니다.

두 번째가 특히 아까웠습니다. 오독이 한 종류면 치환 한 줄로 100% 복구되고, 여러 종류로 흩어지면 못 고칩니다. 그 판단을 하려면 빈도 분포가 필요한데, 남길 쪽은 "전부 한 종류"라는 극단적인 경우에만 입을 열었습니다. 두 종류가 섞이면 아무 말도 안 해줍니다.

이 둘을 옮기지 않았으면 그건 병합이 아니라 손실이었습니다. 둘 다 이식했습니다. 품질 체크리스트 문서 하나도 딸려 있어서 같이 옮겼습니다(옮기고 나서 지문이 같은지 확인했습니다).

3단계: 합친 코드를 실제로 돌렸다

문서상 통합은 통합이 아닙니다. 돌아가야 통합입니다.

정답이 확정된 한글 문서를 만들어 스캔본으로 위조하고(2주차 글에 나온 그 방법입니다), 엔진 두 개를 같은 파일에 먹였습니다. 합친 코드가 뱉은 결과입니다.

이식한 기능도 확인됐습니다. 잘못 읽은 글자를 ○ → ㅇ ×2로 빈도까지 집어냈고, 엔진 A는 "더 나쁨"이 아니라 "대안 아님"으로 따로 표기됐습니다(0점과 낮은 점수를 같은 표에 섞으면 안 된다는 게 우산의 규칙입니다).

페이지를 넘어가는 표를 다루는 두 번째 리그도 돌렸습니다. 회수율 99.74%, 표 셀 60/60, 행 12/12 — 문서에 기록해둔 값과 완전히 일치했습니다. 합치면서 부순 게 없다는 뜻입니다.

4단계: 폐지 문서를 쓰고, 실제로 지웠다

없앨 문서는 완전 삭제 대신 10줄짜리 안내문으로 축소했습니다. 되돌리기 쉬운 쪽을 골랐고, 코드와 참고자료는 지우지 않고 보관 폴더로 옮겼습니다.

안내문에는 "어디로 갔는지" 대응표를 넣었습니다. 이 절은 저기로, 이 코드는 저 명령어로. 폐지된 문서를 나중에 누가 열었을 때 "그럼 내가 찾던 건 어디 있지?"로 끝나면 안 되니까요.

함정 2 — 묘비명이 같은 실수를 반복하고 있었다

다 끝났다고 생각하고 마지막 측정을 돌렸습니다. 그런데 새로 만든 축(인용 제외)의 중복 줄이 10줄에서 11줄로 늘어 있었습니다.

병합을 했는데 늘어났습니다. 열어봤습니다.

▸ [남긴 문서] × [폐지한 문서]   중복 8줄 (최고 유사도 1.0)
    [1.0] 리그 코드 경로가 완전히 동일
    [0.83] 파이썬 실행 경로가 동일

제가 방금 쓴 폐지 안내문이었습니다.

"이제 이 명령어로 대체된다"고 친절하게 알려주려고 실행 명령줄을 통째로 복사해 넣었거든요. 유사도 1.0.

2주차에 제가 이 문서를 없애기로 판정한 근거가 뭐였는지 다시 읽어봤습니다.

같은 실행 명령이 두 곳에 있으면 인터프리터 경로 하나 바뀔 때 한쪽만 고쳐진다. 그 동기화가 이미 실패한 증거가 유사도 0.9다.

그 문서를 없애면서 쓴 묘비명이, 그 문서를 없앤 이유를 그대로 재현하고 있었습니다.

수리는 세 줄이었습니다. 명령블록을 지우고 "실행 명령줄은 여기에 복제하지 않는다. 원본 문서의 코드블록이 유일한 정본이다"로 교체. 그리고 기준은 하나도 건드리지 않고 같은 스크립트로 다시 쟀습니다. 8줄 → 1줄. 남은 1줄은 문서 이름 문자열 그 자체라 없앨 수가 없습니다.

이 사건이 이번 주에 계측기를 고친 것을 정당화해줬습니다. 만약 제가 지표를 예쁘게 만들려고 계측기를 열었다면, 이 사고는 잡히지 않았을 겁니다. 축을 추가했기 때문에 잡혔습니다.

✅ 결과 (After)

실행으로 확인한 것: 합친 코드가 두 종류의 리그를 모두 통과했고, 문서에 적어둔 기존 수치를 그대로 재현했습니다. 기능도 안 잃었습니다.

예측이 틀린 곳 — 이게 더 중요합니다

2주차 글에서 저는 검증 포인트를 이렇게 걸어뒀습니다.

"특히 2곳에서만 공유되던 개념들이 병합 후 자동으로 1곳이 되는지가 검증 포인트입니다."

그렇게 되지 않았습니다. 2곳 공유는 오히려 3개에서 5개로 늘었고, 단독 개념은 여전히 0개입니다. 위에서 내려온 것들이 2곳에 쌓였을 뿐입니다.

왜 틀렸는지는 명확합니다. 개념 공유는 파일 개수가 아니라 서술 위치에서 옵니다. 파일을 하나 지워도 그 안의 개념은 다른 문서로 옮겨가거나 이미 다른 곳에도 있습니다. 파일을 합치는 작업으로 개념 분포를 바꾸려 한 게 애초에 잘못된 기대였습니다.

숫자가 예상대로 안 나왔을 때 예측을 조용히 지우지 않고 남겨두는 게, 다음 주에 뭘 해야 할지 알려주는 유일한 방법이라 그대로 적습니다.

💬 배운 팁

효과적이었던 것

• 개선 작업 전에 같은 자로 한 번 재두세요. 저는 기준선만 잡으려고 돌렸다가, 계측기 자체의 결함을 찾았습니다. 작업 후에만 쟀으면 "병합했더니 좋아졌네"로 넘어가고 계측기 결함은 영원히 안 보였을 겁니다.

• 계측기를 고쳐야 할 땐 기존 축을 없애지 말고 축을 하나 더 붙이세요. 나란히 놓으면 유리한 숫자만 남길 수가 없고, 두 숫자의 차이 자체가 새로운 정보가 됩니다.

• 합치기 전에 "없앨 쪽에만 있는 것"부터 목록으로 만드세요. 그게 0개일 때만 진짜 통합이고, 아니면 이식 목록입니다. 이 단계를 건너뛰면 통합이라는 이름의 삭제가 됩니다.

• 폐지 문서에는 "어디로 갔는지" 대응표를 넣으세요. 나중에 그 문서를 여는 사람은 없앤 이유가 궁금한 게 아니라 자기가 찾던 게 어디 있는지가 궁금합니다.

• "다 됐다"고 말하기 전에 한 번 더 재세요. 저는 그 마지막 한 번에서 제가 낸 사고를 잡았습니다.

하지 말아야 할 것

• 지표가 나빠졌다고 곧바로 채점기부터 열지 마세요. 먼저 물어야 할 질문은 "재는 대상의 성질이 바뀌었나?"입니다. 바뀌었으면 축 추가가 정당하고, 안 바뀌었으면 그냥 결과가 나쁜 겁니다.

• 문서를 지울 때 완전 삭제를 기본값으로 삼지 마세요. 되돌릴 수 있는 축소를 먼저 고르고, 자산은 지우지 말고 보관 폴더로 옮기세요.

• 폐지 안내문에 원본 내용을 복사해 넣지 마세요. 친절해 보이지만 없애려던 중복을 다시 만듭니다. 포인터는 가리키기만 해야 합니다.

• 문서 개수가 줄어든 걸 정리가 끝난 걸로 세지 마세요. 파일 수와 개념 분포는 다른 축입니다. 제가 이번에 예측을 틀린 지점입니다.

🌍 다른 업무에 적용한다면

• 사내 문서·규정 통합: 통합 전후를 같은 기준으로 재보세요. 그리고 "○○ 규정 참조"라고 적은 줄이 원문과 같은 무게로 세어지고 있는지 확인하세요. 참조를 중복으로 세는 자로는 정리 작업이 항상 나쁘게 보입니다.

• 업무 매뉴얼 폐지: 폐지 공지에 원문을 요약해 붙이는 순간 정본이 다시 둘이 됩니다. 어디로 갔는지만 적고, 내용은 새 문서에서만 관리하세요.

• 중복 업무 통합: 합치기 전에 "없어질 쪽에만 있는 일"을 목록으로 만드세요. 그 목록이 이관 계획서가 되고, 없으면 그냥 업무가 사라집니다.

• KPI·성과지표 설계: 좋은 일을 했는데 지표가 나빠지는 구조가 아닌지 먼저 점검하세요. 그런 지표는 사람들이 좋은 일을 안 하게 만듭니다.

• 어떤 업무든 공통: 개선 전 측정값이 없으면 개선은 감상평입니다. 그리고 개선 후 측정값이 이상하면, 대상이 아니라 자를 먼저 의심하세요.

🚀 앞으로의 계획

4주차는 "좋아지는 구조"를 만드는 주차입니다. 그런데 그 전에 이번 주에 남은 숙제가 있습니다.

단독 개념 0개가 그대로입니다. 파일 병합으로는 안 풀린다는 게 이번 주에 확인됐으니, 다음은 파일이 아니라 개념 경계로 문서를 다시 가르는 일입니다. 지금 문서들의 경계는 여전히 "제가 막혔던 시점의 흔적"이지 역할의 경계가 아닙니다.

계측기도 아직 반쪽입니다. 이번에 인용 표시만 구분하게 만들었는데, 코드블록과 표는 여전히 본문과 같은 무게로 세어집니다. 표에 개념어가 들어가면 같은 오판이 다시 납니다. 다음에 같은 함정에 걸리면 그때 축을 하나 더 붙일 생각입니다. 미리 다 막지 않는 이유는, 겪지 않은 함정을 상상해서 만든 게이트는 대체로 틀리기 때문입니다.

그리고 이번 주에 저를 두 번 잡은 게 결국 재실행 가능한 측정 스크립트 하나였다는 점을, 4주차 개선 루프의 출발점으로 삼으려고 합니다. 사람이 눈으로 검수했으면 둘 다 못 잡았습니다.

📋 재사용 프롬프트

문서·프롬프트·업무를 통합하거나 없애려 하신다면, "정리해줘" 대신 이걸 던져보세요.

아래 문서(또는 업무) N개를 통합·폐지하려 한다. 순서를 지켜라.

1. 손대기 전에 백업하고, 원본과 사본의 지문이 일치하는지 확인해라. 확인 못 하면 거기서 멈추고 보고해라.

2. 작업 전에 먼저 재라. 통합 후에만 재면 계측기 자체의 결함을 못 본다. 이때 나온 숫자가 예상과 다르면, 대상이 아니라 계측기를 먼저 의심해라.

3. 계측기가 "원문"과 "○○ 참조"라고만 적힌 줄을 같은 무게로 세고 있는지 확인해라. 같은 무게로 세고 있으면 정리 작업이 지표를 악화시킨다. 이때 기존 기준을 느슨하게 고치지 말고, 구분하는 축을 하나 추가해서 두 숫자를 나란히 보고해라.

4. 합치기 전에 "없앨 쪽에만 있는 것"을 목록으로 만들어라. 그 목록이 0개가 아니면 그건 통합이 아니라 이식이다. 전부 옮긴 뒤에 지워라.

5. 합친 결과를 실제로 실행해서, 통합 전에 기록해둔 수치를 재현하는지 확인해라. 문서상 통합은 통합이 아니다.

6. 폐지 문서에는 "어디로 갔는지" 대응표만 넣고, 원본 내용을 복사하지 마라. 복사하면 없애려던 중복이 되살아난다.

7. 다 끝난 뒤 같은 기준으로 다시 재라. 기준을 바꾸지 말고 대상만 고쳐라. 그리고 처음에 세운 예측이 틀렸으면, 지우지 말고 틀렸다고 적어라.