새 모델 발표를 읽다가 성능표보다 각주에서 멈췄다.
9월 28일 Anthropic이 공개한 Claude Sonnet 5.5는 FrontierCode 평가에서 추론 강도를 Max로 올렸을 때 Xhigh보다 낮은 점수를 받았다. 공개된 점수는 각각 46.2%, 52.1%다. 가장 높은 설정을 골랐는데 결과는 더 나빴다. 공식 발표와 평가 각주
이 수치만 보고 “AI는 많이 생각하면 멍청해진다”고 결론 내리면 중요한 부분을 놓친다. 이번 사례에서 들여다볼 것은 생각의 양보다 에이전트가 일을 어디까지 벌였는가다.
정답을 더 잘 만드는 것과 요청을 더 잘 지키는 것
Anthropic의 설명에 따르면 FrontierCode는 코드 변경을 사람이 추가 수정하지 않고 병합할 수 있는지 평가한다. 요청 범위를 벗어난 수정은 그 자체로 품질이 좋아도 감점 대상이다.
Max 설정에서는 Sonnet 5.5가 여러 하위 에이전트로 검토를 나누는 Claude Code의 코드 리뷰 스킬을 더 자주 실행했다. Cognition이 살펴본 두 사례에서는 이것이 시간 초과 또는 범위 밖 추가 수정으로 이어졌다고 한다. 평가 각주 2
원인을 모든 작업에 일반화할 만큼 큰 근거는 아니다. Max가 언제나 나쁘다는 뜻도 아니다. 다만 “더 철저하게 검토하면 결과도 반드시 좋아진다”는 직관에 구체적인 예외가 생긴 셈이다.
예를 들어, 다음은 실제 벤치마크 문제가 아니라 이 차이를 설명하기 위해 만든 요청이다.
비밀번호 재설정 메일에서 링크가 두 번 인코딩되는 버그를 고쳐줘.
좋은 수정은 인코딩이 중복되는 경로를 찾아 바로잡고, 같은 문제가 다시 생기지 않도록 테스트하는 것일 수 있다.
그런데 에이전트가 작업 중 메일 템플릿 구조가 마음에 들지 않아 공통 모듈을 만들고, 관련 함수 이름까지 바꾸고, 다른 메일의 레이아웃도 정리했다면 어떨까? 각각은 합리적인 개선일 수 있다. 하지만 리뷰어는 작은 버그 하나를 확인하려다 여러 종류의 변경을 검토해야 한다.
변경이 늘어난 만큼 확인해야 할 영향 범위도 넓어진다. 버그 수정만 먼저 배포하기도 번거로워진다. 잘 작성된 코드가 추가됐다는 이유만으로 좋은 패치가 되는 것은 아니다.
이 구분은 AI 이전에도 있었지만, 에이전트가 수정과 검토를 스스로 확장할 수 있게 되면서 더 중요해진다. 작업을 열심히 한 흔적과 우리가 승인할 수 있는 결과물이 항상 일치하지는 않는다.
추론 강도를 올리기 전에, 종료 조건을 적는다
Sonnet 5.5의 기본 추론 설정도 사용 경로에 따라 다르다. 발표 기준 Claude 앱과 Claude Code는 Medium, Claude Platform은 High다. 따라서 기본값끼리 비교한 사용 경험도 동일한 조건이라고 볼 수 없다. 기본 effort 설정
여기서 개발자가 시도해볼 만한 변화는 모든 요청에 “최대한 깊게 생각해”를 붙이는 대신, 완료의 의미를 구체적으로 쓰는 것이다.
앞의 가상 버그 요청을 다시 써보면 이렇다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15비밀번호 재설정 링크의 중복 인코딩 버그를 수정해줘. 성공 조건: - 중복 인코딩이 발생하는 원인을 설명할 수 있다. - 수정 전 실패하고 수정 후 통과하는 회귀 테스트가 있다. - 정상적인 기존 링크 생성 동작은 유지된다. 작업 범위: - 버그와 테스트에 필요한 변경만 한다. - 메일 템플릿 전체 개편이나 무관한 이름 변경은 하지 않는다. - 별도 개선점은 코드에 반영하지 말고 마지막에 제안한다. 완료할 때: - 변경 이유와 실행한 테스트 결과를 남긴다. - 테스트를 실행하지 못했다면 그 사실과 이유를 적는다.
이 예시는 Sonnet 5.5의 성능을 검증한 공식 프롬프트가 아니다. 평가에서 드러난 범위 문제를 실제 요청에 적용해본 작성 예시다.
핵심은 모델의 생각을 억지로 짧게 만드는 데 있지 않다. 필요한 만큼 조사하고 검증하되, 발견한 모든 문제를 이번 변경에 담지는 말라는 것이다. 발견할 자유와 수정할 권한을 분리하는 방식이다.
물론 범위를 너무 좁게 적으면 근본 원인을 놓칠 수 있다. 여러 모듈에 걸친 문제가 의심된다면 “지정한 파일만 고쳐”보다 “추가 변경이 필요하면 먼저 이유를 설명해”가 낫다. 경계는 조사 자체를 막는 벽이 아니라, 작업을 확대할 때 다시 판단하는 지점이어야 한다.
그다음에 추론 강도를 비교하면 된다. 범위가 명확한 버그 수정과, 원인부터 찾아야 하는 설계 문제를 분리해 같은 조건으로 실행해보는 것이다. 테스트 통과 여부뿐 아니라 요청 밖 변경, 리뷰에 걸린 시간, 최종 채택 여부도 함께 기록하고 싶다.
높은 설정이 어려운 문제의 원인을 더 잘 찾아낸다면 기다릴 가치가 있다. 반면 이미 해결된 작은 문제를 오래 검토하며 변경만 늘린다면 다른 설정이 더 적합할 수 있다. 어느 쪽인지는 작업별로 확인해야 한다. 여기서는 직접 비교 실험을 하지 않았으므로 특정 설정을 만능 정답으로 권하지 않는다.
Sonnet 5.5 발표에서 가져갈 가장 실용적인 질문은 “이제 무엇을 더 할 수 있나?”와 함께 있다.
“우리가 요청한 일을 끝낸 다음, 멈출 줄도 아는가?”
코딩 에이전트를 선택할 때 그 질문을 빼놓으면, 가장 부지런한 모델을 고르고도 가장 바쁜 리뷰어가 될 수 있다.
