AI와 검증한 '효과 없음'은, 올바른 코드를 버리게 하고 사람과 AI 모두에게 '검증 완료'가 되어 있었다

Illustrator의 커닝(kerning)을 ExtendScript에서 변경할 수 없다는 이야기를 할 때, 제가 Claude Code에게 했던 한 마디입니다. 실제로 검증에는 노력을 기울였던 기억이 있습니다.

그런데 그 검증 세션 기록을 세어보니, 올바른 속성(property)에는 단 한 번도 대입하지 않았습니다. 게다가 처음부터 올바른 속성을 사용했던 스크립트가 있었습니다. 그것은 '효과가 없을 것'이라는 한 줄이었고, 쓸모없는 것으로 취급되었습니다.

기술적인 내용(예: autoKernType라는 프로퍼티는 존재하지 않고, 정확하게는 kerningMethod였습니다)은 다른 글에 썼습니다. 이 글에서 다룰 내용은 AI와 함께 도출한 결론이 어떻게 사람과 AI 양쪽의 기억 속에서 '검증 완료'로 자라났는지입니다.

무슨 일이 있었나

시간 순서대로 나열합니다. 날짜는 모두 Claude Code 세션 기록에서 가져왔습니다.

검증량은 많았다. 하지만 다른 것을 측정하고 있었다

09-10~12의 검증 세션에서, Claude가 실행한 명령어와 스크립트 내용을 세어보았습니다.

| 세션 | autoKernType = |
kerningMethod = |
|---|---|
| 09-10~12 (검증) | 24회 (10회 호출) | 0회 |
| 08-28 (대체 스크립트 작성) | 0회 | 6회 |

검증에서는 네 가지 종류의 값을 순서대로 넣어 폭을 측정하고, 문자 단위/단락 단위/스타일 경유 등 경로를 바꿔가며 시도했습니다. 대조군으로 tracking도 움직여 보면서 폭이 변하는 것을 보고 '측정계는 정상'임을 확인했습니다. 절차적으로는 꼼꼼했다고 생각합니다.

그럼에도 불구하고, 대입되는 곳은 계속 같은 autoKernType였습니다. 존재하지 않는 프로퍼티입니다. 경로를 바꿔도 같은 이름으로 작성했기 때문에, 어떤 경로에서든 결과가 같아지는 것은 당연했습니다.

여기서 알게 된 것은, 대조 실험이 확인하는 것은 측정계뿐이라는 것입니다. tracking으로 폭이 움직이면, '폭으로 측정한다'는 방법이 옳다는 것은 알 수 있습니다. 하지만 자신이 작성한 대입처가 올바른지 여부는 아무것도 모릅니다.

'할 것 같다(はず)'는 메모리에 쓰이는 순간 단정된다

09-11의 Claude의 판단은, 근원을 거슬러 올라가 보면 추론이었습니다. 'autoKernType가 효과가 없으니, 대체 스크립트 지정도 효과가 없을 것이다'. 문장 끝에는 '할 것 같다(はず)'가 붙어 있었습니다.

그런데 이 한 줄이 메모리에 들어가면 성질이 바뀝니다. 다음 세션의 Claude는 메모리를 전제로 읽습니다. 본인이 붙인 '할 것 같다'의 무게는 전달되지 않고, 그저 사실로 취급됩니다.

사람 쪽에서도 같은 일이 벌어지고 있었습니다. 제가 기억하는 것은 'AI와 함께 시간을 들여 검증했다'라는 것만이고, 무엇을 측정했는지는 기억하지 못했습니다. 단정에서 18일 후인 09-29에는, 그것이 '엄청나게 검증한 결과'가 되어 있었습니다.

AI의 메모리도 사람의 기억도, 당시 결론은 기억합니다. 하지만 그 결론을 내리기 위해 실제로 무엇을 실행했는지는 기억하지 못합니다. 두 개의 기억이 서로를 뒷받침하면서, 한 번도 측정하지 않은 결론이 '검증 완료'로 자라난 것입니다.

기억이 아니라, 실행 기록을 세었다

'엄청나게 검증했다'라는 결론을 의심하기로 했을 때, 가장 먼저 한 것은 기억 확인이 아니었습니다.

Claude Code의 세션 기록(jsonl)을 grep하여, 당시 세션에서 실제로 무엇에 대입했는지를 건수로 낸 것입니다. 본문을 덤프해서 다시 읽는 것이 아니라, 숫자만 낸 것입니다. 그것이 위의 표의 24회와 0회입니다.

세어보니 바로 알았습니다. '검증한' 것은 사실이지만, 검증했던 것은 autoKernType뿐이었다는 것을.

측정하는 검증을 구성했다. 치환 스크립트를 수정하지 않고 2024년과 2026년에 실행해 보고, 국문과 영역 내 문자에서도 확인했다. 결과는 어느 버전에서든 효과가 있었다 (수치는 기술 측 기사에 게재했다).

이 건으로 추가한 규칙

나의 환경에서는 Claude Code에 읽히는 CLAUDE.md에 '단정의 기준'을 두고 있다.

수치나 인과관계를 단정할 수 있는 것은, 이 세션의 툴 출력에 그 값이 그대로 나와 있을 때뿐이다. 그 외에는 문두에 추측:을 붙인다.

내가 '그거 측정했어?'라고 물으면, Claude는 명령어와 출력을 보여주거나, '추측입니다'라고 다시 말하는 두 가지 중 하나로 답한다. 변명이나 나중에 다른 근거를 제시하도록 하지 않는다.

이 기준이 생긴 것은 이번 건보다 전이며, 같은 세션에서 숫자 오류가 3번 연속된 것이 계기였다. 그때까지의 규칙은 '확인한 후에 말해라'였다. 하지만 이것은 본인 내부의 기준이라, 스스로 믿는 사람에게는 항상 '확인 완료'로 보인다. 실제로 그 당시 3건 중 2건은 명령어를 실행한 후에 실수했던 것이다. 그래서, 본인의 납득도가 아니라 '출력에 나와 있는지'라는 외부에서 보이는 기준으로 바꿨다.

이번 건은 이 기준이 아직 없던 때의 일이다. 09-11의 '해야 한다(はず)'에 추측:이 붙어 메모리에 들어가 있었다면, 다음에 읽을 때 다루는 방식이 달랐을지도 모른다.

이번 건을 계기로, 메모리에 두 줄을 추가했다.

대조 실험이 확인하는 것은 측정 시스템일 뿐이며, 대입처가 올바른지는 확인하지 못한다. '효과가 없다'고 말하기 전에, 객체를 다시 가져와 읽어보고 값이 남아있는지 보는 '전에 충분히 검증했다'는 결론을 의심할 때는, 기억이 아니라 세션 기록에서 실제로 무엇을 실행했는지 수를 센다

요약

• 대조 실험이 확인하는 것은 측정 시스템뿐이다. 대입처가 올바른지는 별도로 확인할 필요가 있다.
• '해야 한다(はず)'는 메모리에 쓰이는 순간 단정이 된다. 쓴 본인의 망설임은 다음에 읽는 사람에게 전달되지 않는다.
• 사람의 기억도 AI의 메모도, 결론은 기억해도 무엇을 측정했는지는 기억하지 못한다. 과거의 결론을 의심할 때는 실행 기록을 센다.

관련 기사

세션 기록을 셀 때도, 본문은 덤프하지 않는다.

토론