Claude Opus 5 effort 설정(xhigh, max)이 같은 버그 앞에서 어떻게 다르게 반응하는지 궁금해서 직접 테스트해봤어요.
파일명을 서로 다르게 만들어서 두 세션이 같은 파일을 건드릴 여지를 아예 없앴고, 버그 내용과 요청 문구는 완전히 동일하게 맞췄어요.
xhigh는 신고 안 된 경우까지 스스로 만들어 방어했어요
눈으로는 멀쩡해 보이는데 가끔 틀린 답을 내는 함수를 만들어서, 두 세션 모두에게 “원인을 찾아 고쳐달라”고 똑같이 요청했어요.
신고한 원인은 하나였어요. 자모가 분리된 형태로 저장된 글자와 완성형으로 저장된 글자를, 코드가 서로 다른 문자로 취급하는 문제였죠. 이런 처리를 유니코드 정규화라고 불러요.
xhigh와 max 둘 다 이 원인을 정확히 짚어서 고쳤어요.
여기까지는 같았는데, xhigh는 멈추지 않고 한 걸음 더 나갔어요. 신고하지 않은 비슷한 상황들, 그러니까 호환용 자모(ㅍㅗㅋㅓㅅㅡ처럼 낱자로 들어오는 경우)와 안 보이는 공백 문자 두 종류까지 스스로 만들어서 미리 확인해본 거예요.
이런 문자는 복사·붙여넣기나 PDF, 메신저를 거치면서 평소엔 티 안 나게 섞여 들어올 수 있거든요. xhigh는 이 상황들도 각각 재현해서 테스트를 만들었고, 실제로 돌려보니 전부 정상으로 처리됐어요.
max는 실제 프로젝트에 있을 수 있는 영향도 언급했어요
반면 max는 신고된 원인 하나만 고쳤어요. xhigh가 스스로 만들어 확인한 나머지 상황들은 다루지 않았고요.
대신 max는 물어보지도 않은 걸 하나 먼저 짚었어요. 같은 원인이 실제 발행 전 검증 스크립트의 글자수 계산도 망가뜨릴 수 있다는 거였는데, 확인해보니 맞는 말이었어요.
neulbai가 쓰는 검증 스크립트는 파이썬 len() 함수로 그냥 글자수를 세는데, 같은 문장이 정규화 전엔 86자, 정규화하면 41자로 세어졌어요. 두 배 넘게 차이가 난거죠.
화면에는 똑같은 글자로 보이지만, 자모가 분리된 형태로 저장되면 컴퓨터는 그걸 여러 글자로 나눠서 세거든요. 그래서 눈에 보이는 글자 수보다 더 많이 잡히는 거예요.
한 번 해본 테스트라 “항상 이렇다”고는 못 해요. 다만 이번 결과에서는 xhigh가 신고되지 않은 경우까지 미리 방어했고, max는 같은 원인이 실제 프로젝트에도 영향을 줄 수 있다는 가능성을 짚었어요.
effort 차이가 항상 이런 결과를 만든다고 말할 수도 없고, 어느 쪽이 더 낫다고 단순히 결론 내리기도 어려웠어요. AI 도구를 직접 써보고 예상과 다른 지점을 확인하는 일은 이번이 처음도 아니고요.
AI에게 버그 수정을 맡길 때, 신고된 문제를 넘어서 어디까지 확인해주길 바라나요?