Claude Opus 5 전환 전 확인할 프롬프트·하네스 점검법

제공 자료는 Claude Opus 5를 일상적인 엔터프라이즈·에이전트 작업에 맞춘 모델로 소개하고, 신세대 Claude에서는 기존 프롬프트와 하네스를 다시 설계해야 한다고 주장한다. 그러나 자료에 언급된 Claude Opus 5, Fable 5, Sonnet 5의 출시일·가격·성능 및 파트너 발언은 이 글에 제공된 정보만으로 독립 검증되지 않았다. 특히 Fable이 Anthropic의 공식 모델명인지도 공식 모델 목록에서 먼저 확인해야 한다.

따라서 이 문서는 해당 출시 정보를 확정된 사실로 반복하기보다, 공식 문서로 확인해야 할 항목과 실제 모델 전환에 적용할 수 있는 검증 절차를 구분해 정리한다.

먼저 확인해야 할 출시 정보

새 모델을 API, Claude 앱 또는 Claude Code에 적용하기 전에는 다음 항목을 Anthropic 공식 문서와 사용 중인 서비스의 모델 선택 화면에서 대조해야 한다.

모델명이나 가격이 공식 문서에 없으면 API 설정과 예산 계산에 사용해서는 안 된다. 클라우드 사업자나 재판매 서비스를 이용한다면 Anthropic 직접 API와 모델 ID, 가격, 제공 시점이 다를 수도 있다.

모델 전환에서 달라져야 하는 판단 기준

1. 최고 성능보다 작업당 효율을 측정한다

모든 요청을 가장 비싼 모델로 처리하는 방식은 에이전트가 여러 도구와 subagent를 반복 호출할 때 비용을 빠르게 늘릴 수 있다. 모델은 이름이나 등급이 아니라 다음 지표를 함께 보고 선택해야 한다.

• 성공률: 사람이 수정하지 않아도 요구 조건을 충족한 비율
• 총비용: 최초 요청뿐 아니라 재시도, 도구 호출, subagent 호출을 포함한 비용
• 완료 시간: 대기 시간과 사람의 검토·수정 시간까지 포함한 시간
• 실패 비용: 보안 결함, 잘못된 배포, 누락된 분석처럼 실패가 초래하는 영향
• 일관성: 같은 종류의 작업을 반복했을 때 결과가 흔들리는 정도

작업당 비용은 단순 토큰 단가만으로 판단하면 안 된다. 개념적으로는 다음처럼 계산할 수 있다.

작업당 총비용 = 주 모델 비용 + subagent 비용 + 도구 비용 + 재시도 비용 + 사람의 검토 비용

2. 공개 벤치마크와 자체 평가를 분리한다

공개 벤치마크는 모델의 일반적 특성을 비교하는 출발점이지만, 특정 코드베이스·문서 양식·업무 규칙에서의 성공을 보장하지 않는다. 조직은 실제 작업을 익명화한 자체 평가 세트를 만들어야 한다.

좋은 평가 세트에는 다음 사례가 함께 들어간다.

• 정상적으로 완료해야 하는 대표 작업
• 모델이 자주 틀리는 경계 사례
• 요구가 모호해 추가 질문이 필요한 작업
• 도구 호출이나 외부 자료 확인이 필요한 작업
• 실행을 중단하거나 사람의 승인을 받아야 하는 고위험 작업
• 장시간 수행 중 상태를 저장하고 복구해야 하는 작업

모델별로 동일한 입력, 도구, 시간 제한, 성공 기준을 적용해야 비교가 가능하다. 한두 개의 인상적인 결과보다 여러 차례 반복한 성공률과 비용 분포를 기록하는 편이 안전하다.

3. 모델과 하네스를 하나의 시스템으로 평가한다

**하네스(harness)**는 모델을 둘러싼 실행 환경을 뜻한다. 시스템 프롬프트, 프로젝트 지침, 검색, 메모리, 도구, Skill, subagent, 권한 관리, 검증 및 재시도 로직이 모두 포함된다.

같은 모델도 하네스에 따라 결과가 달라질 수 있다. 예를 들어 모델 자체가 테스트를 작성하고 실행하는데 하네스도 동일한 검증을 강제하면, 같은 작업이 중복될 수 있다. 반대로 배포 승인이나 보안 검사처럼 결정론적 통제가 필요한 단계까지 모델의 자율 판단에 맡기면 위험하다.

핵심 원칙은 모델이 잘하는 추론과 시스템이 반드시 보장해야 하는 통제를 구분하는 것이다.

프롬프트와 하네스에서 점검할 6가지

1. 중복된 검증·재확인 지시를 실험적으로 제거한다

완료 후 반드시 다시 확인하라와 같은 문장을 무조건 삭제하는 것이 정답은 아니다. 먼저 새 모델이 자발적으로 수행하는 검증과 하네스의 검증 단계가 겹치는지 추적한다.

• 모델의 자체 검토가 반복될 뿐 품질이 나아지지 않으면 프롬프트를 줄인다.
• 테스트, 스키마 검증, 정적 분석처럼 자동화할 수 있는 검사는 하네스에 남긴다.
• 결제, 배포, 데이터 삭제 등 고위험 작업의 승인은 모델의 자체 검증으로 대체하지 않는다.

2. subagent의 호출 조건과 상한을 정한다

subagent는 병렬 조사나 전문 영역 분리에 유용하지만, 작은 작업까지 위임하면 비용과 지연 시간이 커진다. 다음과 같은 정책을 명시할 수 있다.

• 독립적으로 나눌 수 있는 작업에만 subagent를 사용한다.
• 한 요청에서 동시에 실행할 수 있는 수를 제한한다.
• 각 subagent에 명확한 산출물과 종료 조건을 준다.
• 동일 자료를 여러 에이전트가 중복 탐색하지 않도록 한다.
• 예상 비용이나 시간이 임계값을 넘으면 사람의 승인을 받는다.

3. 세부 금지 규칙을 판단 기준으로 바꾼다

긴 금지 목록은 서로 충돌하거나 새로운 상황을 다루지 못할 수 있다. 스타일처럼 위험이 낮은 영역은 주변 맥락을 읽고 판단하도록 맡길 수 있다.

• 규정형: 여러 문단의 docstring을 절대 작성하지 마라.
• 판단 위임형: 기존 코드의 주석 밀도, docstring 형식, 네이밍과 관용구를 따르라.

다만 개인정보 처리, 보안, 법적 의무처럼 위반 비용이 큰 규칙은 명시적인 제약과 프로그램 방식의 검사로 유지해야 한다.

4. 응답 길이와 출력 형식을 직접 지정한다

추론에 쓰는 자원과 사용자에게 보이는 답변 길이는 같은 개념이 아니다. 클라이언트가 effort 또는 유사한 추론 강도 옵션을 제공하더라도, 짧은 답변이 필요하면 별도로 출력 조건을 작성한다.

예시는 다음과 같다.

• 결론을 먼저 쓰고 근거는 세 항목 이내로 정리하라.
• 최종 답변은 500자 이내로 작성하라.
• 설명 없이 유효한 JSON 객체만 반환하라.
• 변경 파일, 핵심 이유, 남은 위험만 보고하라.

5. 추론 강도는 실제 작업으로 다시 보정한다

이전 모델에서 사용하던 추론 강도나 effort 기본값을 새 모델에 그대로 적용하지 않는다. 낮은 설정부터 시작해 품질이 부족할 때만 올리는 방식으로 비용 곡선을 측정한다.

옵션의 정확한 명칭과 지원 범위는 API 버전 및 제품에 따라 달라질 수 있으므로 공식 문서를 확인해야 한다.

6. 컨텍스트를 역할별로 나누고 점진적으로 공개한다

모든 지침을 시스템 프롬프트나 CLAUDE.md 하나에 넣으면 관련 없는 정보까지 매 요청에 포함될 수 있다. 다음과 같은 계층 구조가 실용적이다.

1. 시스템·제품 지침: 역할, 안전 경계, 출력 계약처럼 항상 필요한 규칙
2. 가벼운 프로젝트 지침: 빌드 명령, 디렉터리 구조, 공통 작업 방식
3. 필요할 때 불러오는 Skill: 배포, 데이터베이스 변경, 특정 프레임워크 등 조건부 절차
4. 기술 레퍼런스: API 스키마, 코드 예제, 설계 문서, 테스트 가능한 명세

이를 점진적 공개라고 부를 수 있다. 모델이 현재 단계에 필요한 자료를 검색하거나 불러오게 하되, 어떤 자료를 사용했는지 기록해야 재현성과 감사 가능성을 확보할 수 있다.

권장 마이그레이션 절차

1단계: 현재 상태를 고정한다

기존 모델의 프롬프트, 도구 버전, 성공률, 토큰 사용량, 지연 시간과 실패 사례를 저장한다. 기준선이 없으면 새 모델이 실제로 개선됐는지 판단하기 어렵다.

2단계: 모델 정보와 권한을 검증한다

공식 모델 ID, 가격, 컨텍스트 한도, 도구 지원, 데이터 보존 정책을 확인한다. 테스트 환경에서는 쓰기·삭제·배포 권한을 제한한다.

3단계: 기존 하네스를 그대로 시험한다

처음에는 한 번에 모든 것을 바꾸지 않는다. 모델만 교체해 기준선과 비교하면 모델 변화가 미치는 영향을 분리할 수 있다.

4단계: 중복 지시를 하나씩 제거한다

검증 지시, 장황한 스타일 규칙, 불필요한 예시, 항상 주입되는 레퍼런스를 한 종류씩 제거한다. 변경마다 품질과 비용을 다시 측정한다.

5단계: 라우팅 정책을 만든다

업무 난도, 위험, 예상 컨텍스트, 시간 제한에 따라 모델을 선택한다. 제공 자료가 제안한 모델별 역할은 공식 명칭과 성능이 확인된 뒤 가설로 시험해야 하며, 그대로 운영 정책으로 채택해서는 안 된다.

6단계: 제한된 트래픽부터 배포한다

일부 사용자나 비위험 작업에 먼저 적용한다. 실패율, 재시도, subagent 수, 도구 오류, 사람의 수정 시간을 관찰한 뒤 범위를 확대한다.

운영 체크리스트

• 공식 모델명과 API 모델 ID를 확인했다.
• 입력·출력·캐시·배치 등 실제 적용 요금을 확인했다.
• 실제 업무로 구성된 자체 평가 세트가 있다.
• 모델과 하네스의 검증 단계가 중복되지 않는다.
• subagent 호출 기준, 동시 실행 수, 예산 상한이 있다.
• 응답 길이와 출력 스키마를 명시했다.
• 추론 강도별 품질·비용·지연 시간을 비교했다.
• 고위험 작업에는 결정론적 검사와 사람의 승인이 남아 있다.
• 컨텍스트가 상시 지침, Skill, 레퍼런스로 분리돼 있다.
• 롤백할 기존 모델과 설정이 준비돼 있다.

결론

새 모델 전환의 핵심은 프롬프트를 무조건 짧게 만들거나 자율성을 무조건 확대하는 데 있지 않다. 공식 제품 정보를 먼저 확인하고, 실제 업무 평가를 통해 모델과 하네스의 역할을 다시 나누는 것이 핵심이다.

제공 자료의 Claude Opus 5 관련 수치와 명칭은 공식 근거가 확인될 때까지 잠정 정보로 취급해야 한다. 다만 중복 검증 제거, subagent 제한, 명확한 출력 계약, 점진적 컨텍스트 공개, 자체 평가 기반 라우팅은 모델 세대와 관계없이 적용할 수 있는 전환 원칙이다.