AWS가 10월 13일 Grok 4.7의 추론 강도별 에이전트 성능 실험을 공개했습니다. 모델 출시가 아니라 같은 모델을 얼마나 깊이 생각하게 할지에 대한 실험이라는 점이 포인트입니다.

실험 설계는 단출합니다.

모델: Bedrock의 Grok 4.7 (컨텍스트 500K)
과제: 3개 합성 과제 (이중 장애 진단·유지보수 스케줄·마이그레이션 예산)
강도: low / medium / high / xhigh
반복: 과제×강도×6회 = 총 72회 실행
채점: 정답이 하나로 정해지는 과제 + 필수 최종 줄 검사

결과부터 보면 이렇습니다.

정확도: xhigh 18/18 > medium·high 17/18 > low 15/18 (전체 67/72)
출력 토큰(평균): low 1,184 → medium 6,430 → high 6,778 → xhigh 9,147
도구 호출(평균): 17.2 ~ 18.7회로 강도별 거의 동일
중앙값 소요: low 18초 → xhigh 106초

즉 깊이 생각하면 더 맞추지만, 토큰은 약 7.7배, 시간은 약 6배가 듭니다.

가장 재밌는 발견: 도구는 똑같이 쓰고 생각만 늘었다

도구 호출 수가 강도에 따라 거의 안 변했다는 대목이 핵심입니다.

찾아온 사실은 같다 (도구 호출 동일)
달라진 것은 생각의 양이다 (토큰 8배)

에이전트가 사실을 더 모은 게 아니라, 같은 사실을 더 오래 따졌다는 뜻입니다. 그래서 AWS의 해석도 분명합니다. 스케줄처럼 여러 후보를 저울질하는 제약 만족 과제에서 xhigh 차이가 가장 컸고, 단일 경로로 따라가는 과제는 low로도 충분했습니다.

과제별 표를 보면 감이 옵니다.

이중 장애 진단:  low 5/6, medium 6/6, high 6/6, xhigh 6/6
유지보수 스케줄: low 5/6, medium 5/6, high 5/6, xhigh 6/6
예산 마이그레이션: low 5/6, medium 6/6, high 6/6, xhigh 6/6

어려운 저울질에만 최고 강도가 필요했다는 얘기입니다.

이 결과를 일반 정확도 차이로 읽으면 안 되는 이유

AWS 스스로 단서를 달았습니다.

- 셀당 6회라 차이는 방향성 제시, 통계적 결론 아님
- 소규모 합성 환경, 실전 장기 작업의 축소판 (18초~106초)
- 벤더 공개 실험, 독립 벤치마크 아님

low의 15/18을 “Grok이 low면 83%” 같은 일반 점수로 받아들이면 안 됩니다. 이 실험의 가치는 점수가 아니라 같은 일을 같은 하네스로 6번씩 돌려 비교하는 방법에 있습니다.

설정 방법도 알아두면 좋습니다. Responses API에서는 reasoning: { effort } 파라미터로, Converse API에서는 additionalModelRequestFields로 강도를 정합니다. 기본값은 high라서, 가만히 두면 저지연·고볼륨 호출도 필요 이상으로 생각합니다.

response = client.converse(
    modelId="us.xai.grok-4.7",
    messages=[{"role": "user", "content": [{"text": "질문"}]}],
    inferenceConfig={"maxTokens": 3000},
    additionalModelRequestFields={"reasoning_effort": "xhigh"},
)

실전 원칙: 에이전트가 아니라 요청마다 정하라

이 실험에서 가장 옮겨갈 만한 아이디어는 하나입니다. 강도는 에이전트 단위가 아니라 요청 단위 파라미터라는 점입니다.

계획·검증 단계 → high / xhigh
도구 결과 정리·형식 변환 → low
답이 downstream에서 검토됨 → low로도 충분
처음부터 맞아야 함 → 높은 강도가 안전

운영 팁도 따라옵니다. 정답이 없는 프로덕션에서는 토큰량이 신호가 됩니다. 같은 강도에서 평소보다 훨씬 적은 토큰으로 끝난 실행, 도구 호출 없이 끝난 실행은 리뷰 대상으로 찍어보는 겁니다. AWS가 예시로 든 flag_for_review 함수가 바로 그 용도입니다.

Reasoning High vs Max 글에서 다룬 에스컬레이션 구조와도 이어집니다. 처음부터 max가 아니라 낮은 강도에서 시작해 검증 실패 때만 올리는 방식입니다.

CodeBridge Mini Lab: 우리 일로 6번씩 돌려보기

브리핑의 액션을 그대로 옮기면 이렇습니다.

① 과제 2개를 고른다 (복잡한 계획 1 + 단순 변환 1)
② 강도 low/high/xhigh × 각 6회 실행한다
③ 다음을 기록한다:

   [ ] 성공률 (성공 조건 고정, 필수 최종 줄 검사)
   [ ] 출력 토큰 평균 (강도별 배율)
   [ ] 소요 시간 중앙값
   [ ] 성공 1건당 비용
④ “xhigh 추가 비용만큼 실패가 줄었는가”로 판단한다

한 번의 실행을 믿지 마세요. 이 실험의 전제가 반복 실행입니다.

결론: 추론 예산은 품질 슬라이더가 아니라 지갑이다

정리하면 한 문장입니다.

어려운 저울질에만 깊이 생각하고, 나머지는 싸게 돌려라.

복잡한 계획·검증에는 높은 강도를, 단순 분류·형식 변환에는 낮은 강도를. 그리고 그 기준을 감이 아니라 6번씩 돌린 표로 정하세요. 그게 이번 실험이 주는 가장 싼 교훈입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

강도를 언제 올리고 언제 사람에게 넘길지 정하는 감각이 이 글의 요청별 선택 이야기와 바로 이어집니다. 분류와 우선순위 결정을 코드로 연결하는 연습부터 시작해 보세요.