확신을 실측 앞에 세워봤다 8편 — 격리할수록 좋아진다는 것도 절반만 맞았다

지난 글에서 후보로 나온 수정 두 개를 실제 API로 따로 검증한 끝에 같이 넣어야만 통한다는 걸 확인했다. 이번엔 또 다른 이슈다 — /refactor가 두 개의 concept 노트를 병합해서 헤딩 13개짜리 문서 하나를 만들었다. 그 뒤로 /refactor를 몇 번을 다시 돌려도, 이 노트를 도로 쪼개야 한다는 제안은 한 번도 안 나왔다. 이슈에는 이미 이 증상이 잘 정리돼 있었다 — 문제는 고치는 쪽이었다.

이미 통한 방식을 그대로 가져다 쓰려 했다

/refactor에는 _dupN이라는 파일명 접미사로 병합 후보를 사전에 찾아서 프롬프트 맨 위에 “이것부터 1순위로 검증하라”고 못 박아두는 장치가 있다. 이 장치는 실전에서 꽤 안정적으로 작동해왔다. 그러니 “헤딩이 비정상적으로 많은 concept 노트”도 같은 방식으로 — 파일 내용을 LLM에게 안 물어보고 그냥 classification과 헤딩 개수만 세서 — 사전에 찾아 우선순위 목록에 올리면 되지 않을까 싶었다.

과잉분할 걱정이 먼저 나왔다

이 아이디어를 꺼내자마자 “이러면 과잉분할 나오는 거 아니냐”는 지적이 들어왔다. 맞는 지적이었다. 그래서 실측부터 하기로 했다 — 문제 노트 하나만 담은 카탈로그로 새 프롬프트를 돌려보고, 동시에 헤딩이 3~4개인 멀쩡한 노트를 일부러 “우선 검토 대상”으로 강제로 태깅한 채로도 돌려서, 과잉분할이 실제로 나오는지 같이 쟀다.

결과는 좋았다. 목표 노트는 24번 중 22번(92%) 정확히 분할 제안이 나왔고, 서로 다른 도메인의 정상 노트 세 개를 억지로 태깅한 42번의 시도에서는 단 한 번도 잘못 분할되지 않았다. 이 정도면 됐다고 생각했다.

API를 쓰기 전에 헤더 크기부터 세봤다

프로덕션에 넣기 전에, 실제 vault라면 이 헤더에 몇 개가 걸릴지 미리 세보기로 했다. “concept이고 헤딩 3개 이상”이라는 조건을 실제 vault 145개 노트에 적용해봤더니 — 95개가 걸렸다. 전체의 65%. “우선순위 후보 목록”이라는 이름이 무색하게, 사실상 노트 대부분이 여기 올라가는 셈이었다. API를 한 번도 안 부르고 이 문제를 먼저 잡았다는 게 그나마 다행이었다.

짐작이 아니라 실제 분포로 임계값을 다시 잡았다

vault의 concept 노트 210개 전체를 대상으로 헤딩 개수 분포를 직접 뽑아봤다. 3개 이상이 86.7%, 4개 이상도 47.6% — 낮은 임계값은 전부 무의미했다. 10개 이상으로 올리니 3.3%(7개)로 떨어졌고, 실제 문제 노트(13개)는 여유 있게 포함됐다. 이 숫자를 근거로 임계값을 10으로 확정했다.

실전 규모에 넣었더니 92%가 25%로 꺾였다

같은 vault의 실제 노트 145개를 그대로 카탈로그에 넣고 다시 돌렸다. 원본 프롬프트는 8번 중 0번 — 이건 오히려 반가운 결과였다. 실제로 사용자가 “이 노트가 생긴 뒤로 몇 번을 다시 돌려도 분할 제안이 한 번도 안 나왔다”고 관측했던 것과 정확히 일치했기 때문이다. 노트 하나만 있던 고립 조건의 33%가 사실은 지나치게 낙관적인 숫자였다는 뜻이었다.

새 헤더를 붙인 프롬프트는 8번 중 2번(25%) — 확실히 나아지긴 했지만, 고립 조건의 92%에 비하면 초라했다. 144개의 다른 노트와 같은 프롬프트 안에서 경쟁하는 순간, 우선순위 헤더 하나로는 “이 노트 내용을 깊이 읽고 내부에 독립된 서브 개념이 있는지” 같은 무거운 판단을 끌어내기엔 부족했다.

reasoning effort를 올렸더니 더 나빠졌다

가장 싸게 시도해볼 수 있는 손잡이부터 당겨봤다. medium에서 high로 추론 강도를 올리면 이런 무거운 판단에 유리할 거라 예상했다. 결과는 반대였다 — 8번 중 1번(12.5%)으로 오히려 떨어졌고, 호출 하나에 평균 85초가 걸려 medium보다 몇 배 느려졌다. 정밀도도 못 얻고 시간만 잃는 조합이었다.

헤더를 끝에 한 번 더 반복해도 안 통했다

145개 노트 분량을 다 읽고 나면 맨 위에 있던 지시가 희석될 수 있겠다 싶어서, 같은 우선순위 안내를 카탈로그 끝에도 한 번 더 넣어봤다 — 시작과 끝에서 같은 말을 반복하는 “샌드위치” 방식이다. 결과는 8번 중 0번, 원본과 똑같이 돌아갔다. 반복은 도움이 안 됐다.

6개만 따로 떼어 불러봤다 — 격리(isolation) 카탈로그 재호출

남은 손잡이는 격리였다. 헤딩 10개 이상으로 걸린 노트가 실제로는 6개뿐이니, 이 6개만 담은 작은 카탈로그로 완전히 별도의 후속 호출을 하나 더 만들어 보냈다. 145개와 섞이지 않은 만큼 결과도 나아졌다 — 8번 중 3번(37.5%), 그리고 나머지 5개 노트에 대한 오탐은 0건이었다.

지금까지 나온 것 중 가장 나은 숫자였다. 그런데 딱 6개로 줄였을 뿐인데도 92%에서 37.5%까지 떨어졌다는 게 눈에 띄었다 — 완전히 혼자 있을 때와, 겨우 5개와 같이 있을 때 사이에서도 이렇게 큰 차이가 났다. “격리하면 좋아진다”는 방향 자체는 맞았지만, 효과가 예상보다 훨씬 약했다.

이 6개짜리 격리 호출에도 다시 한번 high effort를 시도해봤다. 이번엔 성공률이 12.5%로 떨어졌을 뿐 아니라, 그동안 한 번도 없었던 다른 노트 오탐까지 5건 나왔다. high는 이 판단 유형에서 한 번도 이긴 적이 없었다.

남는 생각

노트 하나만 놓고 잰 92%는 진짜 숫자였다. 거짓말을 한 게 아니라, 그 숫자가 설명하는 조건 자체가 실전과 달랐을 뿐이다. 격리된 조건에서 잰 성공률을 실전 규모의 성공률로 착각하지 않으려면, 결국 실전 규모로 한 번 더 재보는 수밖에 없었다.

그리고 “몇 번 손잡이를 당겨보면 나아지겠지”라는 감도 이번엔 맞지 않았다. effort를 올리는 것, 지시를 반복하는 것 — 둘 다 그럴듯한 가설이었지만 실측에서는 하나도 안 통했고, 하나(effort)는 오히려 대놓고 역효과를 냈다. 결국 남은 최선의 숫자(37.5%)조차 “이 정도면 됐다”고 부르기엔 부족했고, 그 판단을 실측 없이 감으로 내렸다면 25%나 12.5%짜리를 “개선됐다”고 그대로 릴리스했을 수도 있었다. 사후에 찾아서 쪼개는 방향은 여기서 일단 보류했다 — 이야기는 여기서 끝나지 않았다.