오푸스 4.8 코드 자가검사는 AI가 자기가 쓴 코드에서 불안한 부분을 스스로 다시 살피는 기능이다. 엔트로픽에 따르면 4.8은 코드 결함을 경고 없이 넘길 확률이 4.7보다 약 4배 낮다. 다만 숫자만 보고 판단하기는 어려워서 직접 돌려봤다.
처음 출시 소식을 봤을 때 가장 먼저 든 생각은 의심이었다. AI가 자기 버그를 찾는다는 말은 전에도 많았지만, 실제로 써보면 기대만큼 믿음직스럽지 않은 경우도 많았다. 그래서 이번에는 경계 처리가 헷갈리는 코드에 일부러 버그를 심고, 오푸스 4.8 코드 자가검사가 어디까지 잡아내는지 확인해봤다.
이번 오푸스 4.8의 핵심은 점수가 아니다
오푸스 4.8의 한 줄 요약
오푸스 4.8은 현지 시간 5월 28일, 한국 시간 5월 29일에 나왔다. 4.7을 기반으로 코딩과 추론 성능을 다듬었고, 가격은 그대로 유지됐다. 입력 100만 토큰에 5달러, 출력 100만 토큰에 25달러다. API 모델 이름은 claude-opus-4-8이고, 컨텍스트 창은 100만 토큰이다. 출처
이번 업데이트에서 엔트로픽이 특히 강조한 부분은 단순한 성능 향상이 아니다. 핵심은 모델이 자기 답에 확신이 없을 때 그 불확실성을 숨기지 않는다는 점이다. 엔트로픽은 이 방향을 ‘정직성’이라고 표현했다. 출처
같이 나온 변화도 있다. claude.ai와 코워크에는 노력 수준 조절 기능이 추가됐고, 클로드 코드에는 여러 작업을 병렬로 돌리는 다이나믹 워크플로우가 리서치 프리뷰로 들어왔다. 다만 일반 사용자가 가장 먼저 체감할 만한 변화는 역시 코드 검토 방식에 가깝다.
벤치마크 차이는 작다
숫자만 보면 변화가 아주 크지는 않다. 코딩 지표인 SWE-Bench Pro에서는 69.2%를 기록했고, 4.7보다 약 4.9%포인트 올랐다. 출처 다른 항목도 1%에서 9% 사이로 오른 정도라, 표만 보면 대단한 변화처럼 느껴지지는 않는다.
실제로 같은 작업을 줬을 때 결과물이 갑자기 완전히 달라졌다고 보기는 어렵다. 오히려 눈에 띄는 건 답을 내놓는 방식이다. 4.7과 4.8의 차이는 점수표보다, 코드에서 불안한 지점을 먼저 드러내는 태도에 있다. 그래서 이번에는 벤치마크보다 오푸스 4.8 코드 자가검사가 실제 코드에서 어떻게 반응하는지를 중심으로 봤다.
코드 자가검사, 버그를 심어 직접 돌려봤다
테스트 설계, 페이지네이션 경계
자가검사가 말뿐인지 보려면, 사람이 자주 놓치는 버그를 넣어보는 게 가장 빠르다. 그래서 이번에는 페이지네이션 코드를 골랐다.
페이지네이션은 전체 항목 수와 한 페이지 크기로 전체 페이지 수를 구하는 흔한 코드다. 문제는 이런 코드가 단순해 보일수록 경계 조건을 놓치기 쉽다는 점이다. 예를 들어 전체 페이지 수를 total // page_size + 1로 계산하면, 100개를 10개씩 나누는 경우처럼 딱 나누어떨어질 때 페이지가 하나 더 생긴다. 이 경우에는 올림 계산을 해야 맞다.
일부러 이 문제를 그대로 둔 뒤, 오푸스 4.8에게 검토를 맡겼다.
def paginate(total, page_size, page):
total_pages = total // page_size + 1 # 의심 지점
start = (page - 1) * page_size
end = start + page_size
items = list(range(total))[start:end]
return {"total_pages": total_pages, "items": items}실행하기도 전에 문제를 짚었다
4.8은 코드를 바로 고치기보다, 먼저 문제 가능성이 있는 지점을 심각도 순으로 여섯 가지 짚었다. 그중 세 번째가 우리가 일부러 심어둔 오프바이원 버그였다. total // page_size + 1은 딱 나누어떨어질 때 빈 페이지를 하나 더 만들 수 있다고 지적했고, total이 10이고 page_size가 5라면 실제로는 2페이지인데 3페이지로 계산된다는 예까지 들었다.
흥미로운 점은 심어둔 버그만 찾은 게 아니라는 점이다. list(range(total))로 전체 데이터를 메모리에 올리는 비효율, page_size가 0일 때 발생하는 ZeroDivisionError, 음수 page가 들어왔을 때 생길 수 있는 잘못된 슬라이싱도 함께 짚었다. 예제 코드라서 대충 넘어간다기보다, 실제 코드 리뷰처럼 위험한 부분을 하나씩 꺼내는 쪽에 가까웠다.
지적이 맞는지 직접 돌려봤다.
total=95: 10 페이지 (맞음)
total=100: 11 페이지 (틀림, 정답은 10)
11페이지 내용: [] (비어 있는데 있다고 답함)100개를 10개씩 나누면 전체 페이지는 10페이지여야 한다. 하지만 결과는 11페이지였고, 실제로 11페이지를 열어보면 항목이 하나도 없었다. 존재하지 않는 페이지를 있다고 계산한 셈이다. 결국 오푸스 4.8 코드 자가검사가 의심한 바로 그 줄이 원인이었다.
이런 버그가 까다로운 이유는 평소에는 잘 드러나지 않기 때문이다. 95개처럼 애매하게 남는 경우에는 우연히 맞아 보이지만, 100이나 1000처럼 깔끔하게 떨어지는 숫자에서 오히려 문제가 터진다. 개발할 때 이런 입력은 당연히 맞겠거니 하고 지나치기 쉬운데, 실제 서비스에서는 바로 이런 경계값이 장애로 이어질 수 있다.
이 테스트의 한계
물론 이 테스트만으로 오푸스 4.8 코드 자가검사 전체를 판단하기는 어렵다. 먼저 엔트로픽이 말한 ‘4배’는 4.8이 직접 생성한 코드를 대상으로 측정한 수치다. 여기서는 사람이 작성한 코드에 버그를 심은 뒤 검토를 맡겼기 때문에 조건이 다르다.
또 테스트도 페이지네이션 하나뿐이다. 같은 코드를 4.7에도 넣어 비교했다면 차이를 더 분명하게 볼 수 있었겠지만, 이번에는 그 비교까지는 하지 못했다. 그래서 이 결과를 “4.8이 모든 버그를 잘 잡는다”로 받아들이면 안 된다.
다만 확인하고 싶었던 성질은 분명히 보였다. 돌아가는 것처럼 보이는 코드라도 무조건 괜찮다고 단정하지 않고, 먼저 의심스러운 줄을 꺼내준다는 점이다. 이 정도만 해도 코드 리뷰 보조 도구로는 꽤 의미가 있다.
그래서 코드를 맡겨도 되나
쓸 만한 것, 경계할 것
여기까지 보면 오푸스 4.8 코드 자가검사는 꽤 쓸 만해 보인다. 다만 그렇다고 코드를 통째로 맡겨도 된다는 뜻은 아니다.
쓸 만한 부분은 검토의 시작점을 알려준다는 점이다. 모델이 확신이 없을 때 괜찮은 척하지 않고, 의심스러운 줄을 먼저 짚어주면 사람이 어디부터 봐야 할지 훨씬 빨리 정할 수 있다. 특히 페이지네이션, 날짜 계산, 권한 처리, 예외 처리처럼 경계 조건이 많은 코드는 이런 방식이 도움이 된다.
반대로 경계해야 할 부분도 분명하다. 자가검사가 좋아졌다고 해서 모든 버그를 찾아주는 것은 아니다. 지적하지 않은 곳에도 문제가 있을 수 있고, 아무 말 없이 넘어간 코드가 전부 맞는 것도 아니다. AI 할루시네이션이 사라진 것도 아니기 때문에 최종 판단은 여전히 사람이 해야 한다.
실무에 적용하는 법
실무에서는 오푸스 4.8 코드 자가검사를 코드 리뷰를 대신하는 도구로 보기보다, 사람이 먼저 확인해야 할 부분을 좁혀주는 도구로 보는 편이 맞다. 모델이 의심스럽다고 표시한 줄을 먼저 보고, 그다음 사람이 테스트와 실제 요구사항을 기준으로 다시 확인하는 방식이 현실적이다.
작업 성격에 따라 노력 수준을 조절하는 것도 방법이다. 4.8은 claude.ai에서도 effort control로 추론 깊이를 바꿀 수 있다. 중요한 코드 리뷰나 장애 가능성이 있는 수정은 노력을 높이고, 단순한 코드 정리는 낮춰서 속도와 비용의 균형을 맞출 수 있다.
속도가 더 중요하다면 Fast Mode도 선택지가 될 수 있다. 4.8부터 Fast Mode 가격이 기존의 6배에서 3배로 내려갔다. 검토 보조 용도로 자주 돌려야 하는 경우라면 부담이 조금 줄어든 셈이다. 출처
점수보다 솔직함이 남는 업데이트
오푸스 4.8 코드 자가검사를 한마디로 정리하면, 코드를 무조건 맞다고 밀어붙이기보다 불안한 부분을 먼저 드러내는 기능에 가깝다.
벤치마크 점수는 소폭 올랐고, 실제 코딩 체감도 완전히 달라졌다고 보기는 어렵다. 하지만 코드를 받았을 때 “이 부분은 위험할 수 있다”고 먼저 말해주는 태도는 확실히 눈에 띈다. 이번 테스트에서도 모델은 실행 전에 문제 가능성이 있는 줄을 짚었고, 실제로 그 줄에서 오류가 재현됐다.
물론 이것만으로 4.8을 전적으로 믿기는 어렵다. 테스트는 하나뿐이고, 4.7과 같은 조건으로 비교하지도 않았다. 그래도 방향성은 분명하다. 앞으로 AI 코드 리뷰의 쓸모는 단순히 정답을 맞히는 능력뿐 아니라, 어디가 불안한지 얼마나 잘 드러내느냐에서 갈릴 가능성이 크다.
맞는 것처럼 보이지만 확인이 어려운 모델보다, 틀릴 수 있는 지점을 먼저 알려주는 모델이 실무에서는 더 쓸모 있다. 그런 점에서 오푸스 4.8 코드 자가검사는 성능 점수보다 신뢰 방식이 더 기억에 남는 업데이트라고 생각한다.