Build long-horizon agents with Grok 4.7 on Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock의 Grok 4.7 도구 호출 에이전트를 72회 평가한 결과, 추론 노력 수준을 높일수록 출력 토큰 사용량이 늘었으며 xhigh는 18회 모두 정답을 내고 low는 약 8분의 1의 출력 토큰으로 18회 중 15회 정답을 냈다.

📌 핵심 요약

• SpaceXAI는 Grok 4.7이 장시간 걸리는 어려운 작업, 자체 검증, 긴 문맥 관리에 초점을 맞춰 학습됐다고 설명한다. Amazon Bedrock에서는 추론 노력 설정, 도구 호출, 구조화된 출력을 지원하며, SpaceXAI가 제시한 문맥 창은 500K 토큰이다.
• 평가는 20개 서비스와 7개 도구로 구성된 합성 환경에서 장애 원인 진단, 유지보수 일정 편성, 예산 내 마이그레이션 선택을 대상으로 진행됐다. 각 과제의 유일한 정답을 전수 탐색으로 검증하고, 네 추론 노력 수준에서 과제별 6회씩 총 72회 실행했다.
• 전체 정답은 72회 중 67회였으며, low는 15/18, medium과 high는 각각 17/18, xhigh는 18/18이었다. 과제와 수준별 표본이 6회에 불과하므로 수준 간 차이는 통계적으로 확정적인 결론이 아니라 방향을 보여주는 결과다.
• low·medium·high·xhigh의 평균 출력 토큰은 각각 1,184·6,430·6,778·9,147개였고, 실행 시간 중앙값은 18·98·89·106초였다. 평균 도구 호출은 17.2~18.7회로 비슷해, 추론 노력 증가가 도구 탐색량 증가로 이어지지는 않았다.
• 접속에는 us.xai.grok-4.7 또는 global.xai.grok-4.7 추론 프로필을 사용한다. 추론 토큰도 출력 한도를 소모하므로 답변 공간을 함께 확보해야 하며, 평가에서는 32,768 토큰 한도를 사용했다. 원문은 가격 변동을 고려해 금액 대신 토큰 수를 보고한다.

🧩 주요 포인트

1. 추론 노력과 자원 사용: 도구 호출이 17.2~18.7회로 유지되는 동안 xhigh의 평균 출력 토큰은 low의 7.7배가 됐다. 사실 수집량과 답을 검토하는 데 쓰는 출력 자원을 구분해 수준별 효과를 판단할 필요가 있다.
2. 평가의 해석 가능성: 유일한 정답의 전수 검증, 채점 규칙의 명시, FINAL 결론 줄 채점, 형식 준수와 정답 여부의 분리는 명세의 모호함과 모델의 오류를 구별하는 기반이 된다.
3. 통합 조건과 운영 제약: 미국 내 라우팅과 상용 AWS 리전 라우팅은 데이터 상주 조건에 따라 선택하며, IAM의 bedrock:InvokeModel 권한은 추론 프로필과 계정의 기본 프로젝트 모두에 필요하다. 추론 토큰이 답변 전에 출력 한도를 소모하는 특성도 구현에 반영해야 한다.

🧠 상세 정리

1. Grok 4.7의 지향점과 공급사가 보고한 성능

Amazon Bedrock에 제공된 SpaceXAI의 Grok 4.7은 여러 단계를 이어가는 에이전트 작업에서 후보 답을 만들고, 확보한 사실과 대조하며, 결과를 수정하는 능력에 초점을 둔다. SpaceXAI에 따르면 Grok 4.6보다 큰 기반 모델을 사용하고, 여러 시간이 걸리는 어려운 과제의 비중을 높인 구성으로 더 긴 강화학습을 수행했으며, 자체 검증과 긴 문맥 관리가 개선됐다. 공급사가 공개한 Grok 4.6 대비 Grok 4.7 점수는 Terminal-Bench 4.0에서 20.3%→37.6%, EEBench에서 53.0%→64.0%, Harvey Legal Agent Benchmark에서 15.8%→19.6%다. CursorBench 4.0은 40.4%→46.3%, HealthBench Professional은 48.5%→56.7%, AA Briefcase v1.1은 1,546→1,657로 제시됐다. 이는 출시 당시 SpaceXAI가 발표한 수치이며, 원문은 표준 벤치마크와 별개로 실제 업무 형태에 맞춘 평가가 필요하다고 설명한다. SpaceXAI가 명시한 문맥 창은 500K 토큰이고 입력은 텍스트와 이미지, 출력은 텍스트이며, Bedrock에서는 추론 노력 조절과 도구 호출 및 구조화된 출력을 지원한다.

2. 접속 경로와 권한 준비

Grok 4.7은 bedrock-runtime 엔드포인트에서 교차 리전 추론 프로필을 통해 호출하며, 요청에는 개별 모델 ID 대신 해당 프로필을 지정한다. us.xai.grok-4.7은 미국 지리적 범위 안에서 요청을 라우팅해 미국 내 데이터 상주 요구가 있을 때 사용하고, global.xai.grok-4.7은 상주 제약이 없고 더 넓은 처리 용량을 원하는 경우 상용 AWS 리전으로 라우팅한다. 교차 리전 추론은 여러 AWS 리전에 요청을 분산하므로 사용자가 리전별 용량을 따로 관리하지 않고 처리량을 높일 수 있다는 설명이다. 지원 인터페이스는 OpenAI 호환 Chat Completions와 Responses API, Amazon Bedrock Converse API이며, Converse에서는 추론이 text와 함께 reasoningContent 블록으로 반환된다. 준비 사항은 Grok 4.7 접근이 활성화된 Amazon Bedrock 계정, Python 3.9 이상, openai·boto3·aws-bedrock-token-generator 패키지와 환경에 설정된 AWS 자격 증명이다. IAM의 bedrock:InvokeModel 권한은 선택한 추론 프로필뿐 아니라 해당 계정의 project/default 리소스에도 필요하며, 현재 지원 리전·서비스 계층·토큰 가격은 모델 카드와 가격 페이지에서 확인하도록 안내한다.

3. 인증과 추론 노력 및 출력 한도

원문은 운영 환경에서 기존 AWS 자격 증명으로 단기 bearer 토큰을 생성해 인증을 IAM 신원에 연결하고 장기 비밀정보를 저장하지 않는 방식을 권장한다. 연결 예시는 us-west-2의 OpenAI 호환 엔드포인트와 us.xai.grok-4.7 프로필을 사용하며, 시간 제한을 360초로 두고 명시적 재시도 처리를 위해 클라이언트의 max_retries를 0으로 설정한다. 추론 토큰은 출력 토큰에 포함되고 답변 본문이 나오기 전에 max_completion_tokens를 소모하므로, 한도는 추론과 최종 답변을 모두 수용해야 하며 평가에서는 32,768 토큰을 사용했다. 추론 중 한도에 도달하면 답변 텍스트 없이 반환될 수 있어 에이전트 코드에서 빈 내용을 확인하고 이런 경우 한도를 늘리도록 설명한다. 지원 추론 노력 수준은 low·medium·high·xhigh지만 모델 버전에 따라 달라질 수 있으므로 서비스에 직접 요청해 확인하며, Converse에서는 inferenceConfig에 maxTokens만 넣고 추론 노력 같은 모델 전용 매개변수는 additionalModelRequestFields에 둔다.

4. 조회만으로 풀 수 없는 세 가지 과제

평가 환경은 20개 서비스와 7개 도구로 구성되며, 단순히 기록을 읽고 필터링하는 작업과 달리 후보 해답을 제안하고 규칙에 맞는지 확인해야 하는 세 과제를 사용한다. two_fault_diagnosis는 03:00에 조용히 실패한 두 서비스를 다른 12개 서비스의 경보로 찾아내는 문제로, 실패한 서비스 자체는 경보를 발생시키지 않는다는 조건이 핵심이다. 가능한 서비스 쌍은 190개이고 관측된 경보를 정확히 설명하는 쌍은 하나뿐이므로, 경보를 낸 서비스를 곧바로 원인으로 고르는 접근으로는 해결되지 않는다. maintenance_schedule은 8개 서비스를 4일 밤에 매일 2개씩 배치하면서 10개 제약과 같은 팀의 서비스는 같은 밤에 배치하지 않는 규칙을 만족해야 하며, 가능한 일정 2,520개 중 유효한 것은 하나다. 이 팀 규칙을 적용하려면 에이전트가 관련 데이터를 직접 조회해야 하고, migration_budget에서는 전이적 선행 요건을 포함해 예산 안에서 위험 감소를 최대화하는 마이그레이션 집합을 선택한다. 마지막 과제의 실행 가능한 집합은 53개이고 최적해는 하나이며, 비율이 좋은 후보부터 고르는 휴리스틱은 최적값보다 9점 낮은 결과를 낸다.

5. 정답과 채점 규칙을 먼저 검증하는 평가 설계

원문은 추론 노력의 효과를 측정하기 전에 채점기가 사용하는 모든 규칙을 과제에 명시해야 한다고 강조하며, 장애 서비스는 자체 경보를 내지 않는다는 조건을 그 예로 든다. 경계 조건이 빠지면 합리적인 답도 오답으로 처리될 수 있어, 평가가 모델의 능력보다 명세의 모호함을 반영하게 된다는 이유다. 각 환경은 모든 후보를 열거할 수 있을 만큼 작게 만들고 실행 전에 유일한 정답을 증명했으며, 일정 문제에서는 전체 규칙을 적용하면 정답이 하나이고 팀 규칙을 제거하면 여러 답이 남는지도 확인했다. 채점은 설명 전체가 아니라 FINAL: auth, checkout과 같은 필수 마지막 줄을 대상으로 하므로, 추론 중 다른 후보를 언급해도 최종 결론을 기준으로 판단한다. 또한 마지막 줄이 없는 형식 오류와 결론이 틀린 정답 오류를 별도로 추적했고, 실제 72회 응답은 모두 채점 가능한 FINAL 줄을 포함했다.

6. 도구 제약과 에이전트 실행 루프

도구 정의에서는 서비스 이름처럼 유효한 값의 집합이 알려진 매개변수에 enum을 지정해 모든 도구 호출이 실제 리소스를 대상으로 하도록 제한한다. 예시인 get_dependencies는 특정 서비스가 직접 의존하는 서비스를 반환하며, service 매개변수에 SERVICE_NAMES를 허용값으로 지정하고 이를 필수로 요구하는 구조다. 시스템 프롬프트는 짧게 유지하면서 도구로 사실을 수집하고 조회 가능한 값을 추측하지 말 것, 답변 전에 모든 과제 규칙과 대조할 것, 지정된 FINAL 줄로 끝낼 것을 요구한다. 실행 루프는 reasoning_effort를 설정해 모델을 호출하고 반환된 도구 호출을 실행한 뒤, 결과를 tool_call_id에 연결해 대화에 추가하고 모델이 더 이상 도구를 요청하지 않을 때까지 반복한다. 이 과정 전체의 prompt_tokens와 completion_tokens를 누적해 토큰 사용량을 집계하며, 원문은 가격이 변해도 측정값을 비용 계산에 활용할 수 있도록 금액 대신 토큰 수를 보고한다.

7. 72회 실행의 정확도와 자원 사용 결과

세 과제를 네 추론 노력 수준에서 각각 6회씩 실행한 결과 전체 72회 중 67회가 정답이었고, 수준별 합계는 low 15/18, medium 17/18, high 17/18, xhigh 18/18이었다. two_fault_diagnosis와 migration_budget은 각각 low에서 5/6이고 나머지 세 수준에서 6/6이었으며, maintenance_schedule은 low·medium·high에서 각각 5/6, xhigh에서 6/6이었다. low·medium·high·xhigh 순서로 실행당 평균 출력 토큰은 1,184·6,430·6,778·9,147개이며, low 대비 배수는 1.0·5.4·5.7·7.7배였다. 같은 순서의 평균 도구 호출 횟수는 17.2·18.7·17.8·18.1회이고, 실행 시간 중앙값은 18·98·89·106초였다. 따라서 이 실험에서 xhigh는 모든 실행에 정답을 냈지만 더 많은 출력 토큰과 긴 실행 시간을 사용했고, low는 xhigh의 약 8분의 1에 해당하는 출력 토큰으로 18회 중 15회를 맞혔다. medium과 high는 정답 수가 같았으며 시간 중앙값도 노력 수준에 따라 단조롭게 증가하지 않아, 정확도·출력 토큰·시간을 각각 확인할 필요가 있다.

8. 결과의 의미와 제공된 본문의 한계

원문은 xhigh가 세 과제의 18회 실행을 모두 맞힌 결과를 제시하면서도, 과제와 수준별로 6회씩만 실행했기 때문에 수준 간 차이는 통계적으로 확정적인 결론이 아니라 방향을 시사하는 결과라고 명시한다. 세 과제 모두에서 더 높은 노력 수준의 정답 수가 low 이상이었지만, 이 관측만으로 다른 업무에서도 같은 정확도나 토큰 효율이 보장된다고 볼 근거는 제시되지 않는다. 또 다른 관측은 노력 수준이 달라져도 도구 호출이 실행당 평균 17.2~18.7회로 거의 일정했다는 것으로, 원문은 이를 수집한 사실은 비슷하고 추론에 쓰는 양이 달라지는 현상으로 설명한다. 따라서 이 글이 제시하는 실무적 선택의 근거는 자체 업무를 닮은 과제에서 정답 여부와 토큰 사용량을 함께 측정하고 요청별 노력 수준을 조절하는 데 있다. 다만 제공된 source_body는 이 두 번째 관측을 설명하는 문장 중간에서 끝나므로, 도입부에서 예고한 운영 모니터링이나 코드 주석이 가리키는 재시도 처리의 구체적 구현은 이 자료만으로 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 이 실험에서는 사실을 모으는 도구 호출량보다 출력 토큰 사용량이 추론 노력 수준에 따라 크게 달라졌다. 도구를 많이 호출하는 것과 확보한 사실로 해답을 검증하는 데 자원을 쓰는 것을 구분해 볼 수 있다.
• medium과 high는 모두 17/18 정답이었고 실행 시간 중앙값도 각각 98초와 89초였다. 노력 수준의 명칭만으로 정확도나 지연을 예측하기보다 실제 업무에서 측정한 결과로 판단해야 한다는 시사점이 있다.
• 유일한 정답과 명시적 규칙, 결론 줄 중심 채점은 결과를 해석하기 쉽게 만들지만, 세 합성 과제와 과제·수준별 6회라는 범위가 결과의 일반화를 제한한다.

✅ 액션 아이템

• 유일한 정답을 검증할 수 있는 업무형 과제에서 low·medium·high·xhigh의 정확도와 토큰 사용량 비교.
• low의 15/18과 xhigh의 18/18 정답, 평균 출력 토큰 1,184개와 9,147개를 기준으로 요청별 정확도·자원 사용 절충 검토.
• 미국 내 데이터 상주 조건에 따른 추론 프로필 선택과 bedrock:InvokeModel의 두 리소스 권한, 추론·답변을 함께 수용할 출력 한도 확인.

❓ 열린 질문

• 과제·수준별 6회보다 실행 횟수를 늘려도 low 15/18과 xhigh 18/18에서 관측된 정확도 차이가 유지되는가?
• 실제 업무에서도 도구 호출이 17.2~18.7회로 비슷한 가운데 xhigh의 출력 토큰이 low의 7.7배가 되는 양상이 나타나는가?
• 32,768 토큰 한도는 실제 업무에서 추론 토큰과 최종 답변을 모두 수용하기에 충분한가?