Claude Opus 4.7 코딩 SWE-bench 87점 — 멀티시간 PR 자동화 후기

지난주에 4.6 → 4.7 마이그레이션을 마쳤는데, 사람이 손대지 않고 그대로 머지되는 PR 비율이 눈에 띄게 늘었어요. 코딩 벤치마크 점수가 올랐다는 발표가 마케팅 문구로만 그치지 않고 실제 작업에서도 느껴지는 편이에요.

특히 변화 큰 건 멀티시간 작업 처리. 4.6 시절엔 30분~1시간 넘는 PR은 도중에 컨텍스트 잃거나 잘못된 길로 빠지는 경우가 많았어요. 4.7은 4시간짜리 리팩터링도 한 번에 마무리. 이 글은 직접 1M 컨텍스트·Task Budget·xhigh effort 다 써보고 정리한 실전 후기예요.

SWE-bench 점수가 의미하는 것 — 4.6 대비 차이

SWE-bench는 GitHub의 실제 이슈를 모델에게 던지고 PR을 만들게 해서, 머지 가능한 비율을 측정하는 벤치마크예요. 점수가 올랐다는 건 사람이 손대지 않아도 되는 PR의 비율이 늘었다는 뜻이죠. 모델별 정확한 점수는 발표 시점마다 갱신되니 공식 발표 자료에서 확인하는 편이 정확해요.

4.6 대비 실제 체감 차이 5가지

1. 멀티 파일 리팩터링 안정성

4.6은 파일 수가 대여섯 개를 넘어가면 import를 빠뜨리거나 함수 시그니처가 어긋나는 일이 종종 있었는데, 4.7은 파일이 열 개 넘어가는 PR도 1차 시도에서 통과하는 경우가 많아요.

저는 React 프로젝트에서 Context API → Zustand 마이그레이션을 12 파일에 걸쳐 시켰는데, 한 번에 빌드 통과하고 모든 테스트 그린.

2. 디버깅 끈기 — 같은 버그 3번 시도 후 해결

복잡한 race condition 디버깅 시 4.6은 보통 1~2번 시도하고 "근본 원인 모르겠음" 으로 포기하는데, 4.7은 5~7번 시도하며 다른 가설 검증. xhigh effort 켜면 더 길게 추적.

3. 1M 컨텍스트로 모놀리스 한 번에 분석

50만 라인 모노리포 통째로 던져서 "이 코드베이스의 잠재적 보안 취약점 5가지" 같은 분석 가능. 4.6 시절엔 청크 나눠서 5번 호출해야 했는데, 4.7은 1번에 끝.

4. 한국어 주석·문서 자연스러움

이건 SWE-bench엔 안 잡히는 부분인데, 한국어 README·주석 작성이 4.6 보다 명확히 좋아졌어요. "~합니다" 톤이 줄고, 자연스러운 구어체 + 기술 용어 정확.

5. Vision 입력 — 작은 텍스트 인식

비전 입력 처리 능력이 좋아져서 스크린샷 안의 작은 에러 메시지·diff도 알아봐요. 4.6은 화면 해상도가 떨어지면 텍스트를 잘 못 읽었어요. 지원 해상도 상한 같은 세부 스펙은 공식 문서에서 확인하세요.

1M 컨텍스트 표준 가격 — 진짜 의미

이전 모델은 200K를 넘는 long-context 호출에 별도 요금이 붙는 구조였어요. 4.7부터는 컨텍스트 길이와 무관하게 표준 단가가 적용됩니다.

1M 컨텍스트 실전 활용 5가지

1. 모노리포 통째 분석: 50만 라인 한 번에 → 보안·성능·데드 코드 진단
2. 장기 대화 메모리: 한 세션에 200~300턴 대화 그대로 유지
3. 대용량 로그 디버깅: 100MB 로그 던지고 패턴 추출
4. PDF 책 요약: 800 페이지 한 번에 (이전엔 청크 분할 필수)
5. 다중 문서 비교: 계약서 10개 한 번에 띄우고 차이 분석

Prompt Caching 안 쓰면 비용 폭증 — 필수 설정

1M 컨텍스트 한 번 호출 = 인풋 $15. 캐싱 없이 10번 호출하면 $150. 5분 캐시 활성화하면 첫 호출 $15 + 9번 $1.5씩 = $28.5 (81% 절감).

import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model=MODEL_ID,  # 공식 문서의 최신 모델 ID로 지정
    max_tokens=4096,
    system=[
        {
            "type": "text",
            "text": codebase_content,  # 1M 컨텍스트
            "cache_control": {"type": "ephemeral"}  # 5분 캐시
        }
    ],
    messages=[{"role": "user", "content": user_prompt}]
)

이 한 줄(cache_control) 빠뜨리면 비용 3~5배 차이. 같은 ai-blog의 Claude Projects 활용법 7가지 — 1M 컨텍스트 200% 활용 도 함께 보면 활용 시나리오 더 깊이 이해할 수 있어요.

Task Budget — 토큰 예산으로 무한 루프 막기

Task Budget은 특정 파라미터 이름이라기보다 에이전트 작업에 토큰 총량 상한을 두는 설계 방식으로 이해하는 게 좋아요. 한정된 자원 안에서 가장 가치 있는 일에 집중하게 만드는 게 목적이죠. 요청 단위로 지원되는 옵션은 SDK·모델 버전마다 다르니 공식 API 문서에서 현재 지원 항목을 확인하세요.

토큰 예산 관리 작동 원리

한 작업에 쓸 토큰 총량을 미리 정해두고, thinking·tool calls·tool results·최종 출력의 누적 사용량을 애플리케이션에서 세는 구조예요. 상한에 가까워지면 다음 도구 호출을 막고 "지금까지 확인한 내용으로 결론을 내라"는 지시를 보내면 됩니다.

response = client.messages.create(
    model=MODEL_ID,  # 공식 문서의 최신 모델 ID로 지정
    max_tokens=4096,
    thinking={"type": "adaptive"},
    messages=[...]
)

# 응답의 usage를 누적해서 작업별 상한과 비교
used += response.usage.input_tokens + response.usage.output_tokens

핵심: 예산의 절반쯤 소진한 시점부터 "검증 단계를 줄이고 핵심 결과만" 요청하는 식으로 페이스를 조절하는 거예요.

실제 사용 사례 3가지

사례 1. 무한 도구 호출 방지

n8n 자동화 (n8n + Claude API 자동화 5단계 참고)에서 Claude가 같은 도구를 30번 반복 호출하던 문제. Task Budget 100K 설정 후 15~20회에서 자체 종료.

사례 2. PR 리뷰 시간 보장

PR 자동 리뷰에서 큰 PR 만나면 1시간씩 걸리던 게, Task Budget 50K 설정 후 5분 내 핵심 코멘트만 남기고 종료. 이슈 라벨로 "더 깊은 분석 필요" 표시.

사례 3. 비용 상한선 준수

월 $500 예산 안에서 운영. Task Budget으로 작업당 토큰 상한 설정 → 한 작업이 폭주해서 예산 깨먹는 일 방지.

멀티시간 PR 자동화 5단계 — 직접 운영 중

저는 n8n + Claude API 자동화와 결합해서 PR 자동 처리 워크플로우 운영 중이에요. 5단계 구조:

단계 1. GitHub Webhook → n8n 트리거

PR 오픈 이벤트가 webhook으로 들어옴. 라벨 'auto-review' 가 있으면 Claude 4.7 호출 분기.

단계 2. PR 컨텍스트 수집

gh pr diff #123 으로 변경 사항 + gh pr view --json 으로 메타 정보 수집. 평균 5K 토큰.

단계 3. 코드베이스 컨텍스트 캐싱

해당 PR이 건드리는 모듈의 전체 소스(평균 100K~300K 토큰) 를 prompt cache로 등록. 5분 캐시.

단계 4. Claude 4.7 호출 — Task Budget 200K + xhigh effort

변경 사항을 7가지 관점에서 리뷰:
1. 잠재적 버그·null 처리 누락
2. 타입 안전성 약한 곳
3. 테스트 커버리지 부족
4. 성능 회귀 가능성
5. 보안 위험 (SQL 주입·XSS·secret 노출)
6. 코드 스타일·가독성
7. 비즈니스 로직 모순

각 이슈에 인라인 코멘트로 위치·심각도·수정 제안 작성.

평균 응답 시간 4~7분, 토큰 소모 80K~150K, 비용 PR당 $1~2.

단계 5. 인라인 코멘트 자동 작성

응답을 파싱해서 gh pr review --comment 로 인라인 코멘트 작성. 심각도 상 5개 이상이면 'changes-requested', 그 외 'commented'.

운영하면서 꼭 재보는 지표 5가지

수치는 팀마다 다르니 남의 숫자를 믿기보다 직접 측정하는 게 빨라요. 한 달만 아래 다섯 개를 기록하면 이 자동화가 본인 팀에 맞는지 바로 판단됩니다.

• 처리한 PR 수: 자동 리뷰 라벨이 붙은 PR만 세기
• 사람 손 안 댄 비율: 리뷰 코멘트를 그대로 반영해 머지된 비율
• PR당 평균 토큰: 입력·출력·캐시 읽기를 나눠서 기록
• PR당 평균 비용: 위 토큰에 공식 요금표 단가를 곱해 계산
• 오탐 코멘트 비율: 잘못 지적해서 무시한 코멘트 수

특히 오탐 비율이 중요해요. 비용이 싸도 오탐이 많으면 리뷰어가 코멘트를 무시하기 시작하고, 그 순간부터 자동화는 있으나 마나 한 장치가 됩니다. 오탐이 잦으면 프롬프트에서 지적 항목을 줄이고 심각도 기준을 올리세요.

xhigh effort 활용 시점 — 깊이 vs 속도

xhigh effort는 Claude Code 전용 명시적 옵션이에요. 일반 adaptive보다 thinking 토큰을 훨씬 많이 씁니다.

xhigh를 써야 하는 작업

1. 알고리즘 설계 — 동적 계획법·그래프 알고리즘 새로 짜기
2. 아키텍처 결정 — 마이크로서비스 vs 모놀리스 등
3. 성능 병목 진단 — 50ms → 5ms 줄이는 최적화
4. 복잡한 race condition 디버깅 — 비동기·멀티스레드
5. 보안 감사 — 한 모듈 통째 보고 취약점 5가지+

xhigh 쓰면 안 되는 작업

1. 변수명 바꾸기·import 정리 (DeepSeek V4 Pro로 충분)
2. README 작성 (adaptive로 충분)
3. CRUD API 작성 (adaptive 충분)
4. 테스트 케이스 작성 (adaptive 충분)
5. JSON 파싱·변환 (DeepSeek V4 Pro)

xhigh를 한 번 호출하면 응답도 느려지고 토큰도 많이 들어요. 정말 가치 있는 작업에만 쓰는 게 비용 효율적입니다.

흔한 실수 5가지 — 4.6 → 4.7 마이그레이션

실수 1. cache_control 안 붙이고 1M 컨텍스트 매번 호출

비용 5배 차이. 모든 long-context 호출에 cache_control 필수.

실수 2. xhigh effort를 모든 호출에 켬

토큰 5배·시간 5배. 단순 작업은 adaptive 충분.

실수 3. Task Budget 너무 작게 설정 (10K 이하)

작업이 도중에 끊김. 최소 50K 권장. 평균 작업은 100~200K.

실수 4. 4.6 호출 코드 그대로 복사

호출 코드의 모델 ID를 4.7 스냅샷으로 바꿔야 해요. 정확한 ID는 공식 모델 목록에서 복사해 오세요. SDK도 새 모델을 인식하는 버전으로 올려두는 게 안전합니다.

실수 5. 1M 컨텍스트 채울 때 무관한 파일까지 다 넣음

토큰 낭비 + 결과 품질 하락. 관련 파일만 컨텍스트에 넣고, 나머지는 도구 호출(file_read)로 필요할 때만 로드.

마무리 — 5월 4일 GPT-5.2 vs 5.5 비교 와 함께 보기

경쟁 모델과의 벤치마크 비교는 발표 주체와 측정 조건에 따라 결과가 달라지니 각 사 공식 자료를 직접 확인하세요. 제 체감으로는 코딩에선 Claude 4.7이 앞서고, 일반 채팅·창의적 글쓰기는 GPT 쪽이 더 자연스러워요.

저는 코드는 Claude, 마케팅·문서는 GPT 로 나눠 써요. Cursor 3.0 / best-of-n 으로 두 모델 동시에 던져서 작업 성격별 최적 모델 채택하는 흐름이 가장 효율적이에요.

처음 마이그레이션이라면 prompt caching·Task Budget 두 가지부터 적용하세요. 비용 50~80% 절감 + 안정성 동시에 잡혀요. 한 번 익숙해지면 4.6으로 못 돌아가요.