Grok 4.5가 프리미엄 프런티어 (Frontier) 모델의 가격표 없이도 Opus급의 에이전트 기반 코딩 (Agentic Coding) 결과를 제공할 수 있을까요? 저는 xAI의 최신 모델이 단순히 좁은 코딩 벤치마크를 넘어 전체 소프트웨어 개발 생명주기 (SDLC) 워크플로우 전반에서 버틸 수 있는지 확인하기 위해, Grok Build를 사용하여 Grok 4.5를 대상으로 Ship-Bench를 실행했습니다.

가설: Grok 4.5는 로컬 모델들 사이에서 가성비의 새로운 기준이 될 것이며, 특히 최상위 추론 모델 (Reasoning-model)의 가격을 지불하지 않고도 강력한 코딩 경험을 원하는 팀들에게 해외 모델들과의 실질적인 경쟁력을 제공할 것이다.

핵심 통찰 (Key Insights)

• Grok 4.5는 가성비 경쟁자로서 확실한 근거를 보여주었습니다: 5개의 Ship-Bench 역할(Role)에 대해 평균 91.96을 기록했으며, 첫 번째 기록된 실행에서 5/5 단계를 모두 통과했습니다.
• 가장 강력한 작업은 초기에 나타났습니다: Architect가 97, UX가 94.5, Planner가 93.9를 기록했으며, 이는 구현 (Implementation) 단계로의 인계가 일관되게 강력했음을 의미합니다.
• 앱이 실제로 작동했습니다: Developer 평가를 통해 여러 뷰포트 (Viewport) 및 데이터베이스 상태에 걸쳐 헤드리스 크로미움 (Headless Chromium)을 통한 브라우징, 검색, 편집 및 로컬 실행 흐름을 검증했습니다.
• Reviewer가 가장 취약한 단계였습니다: 앱이 실패했기 때문이 아니라, QA 증거가 부족했고 평가 과정에서 성능 측정 누락, 의존성 취약점 스캐닝 누락, 필수 출력 템플릿 미준수 등이 지적되었기 때문입니다.
• 이번 실행의 비용은 정직하게 측정될 수 없습니다: 토큰 가시성이 없는 Grok의 무료 티어 (Free tier)에서 실행되었기 때문입니다. 하지만 동일한 무료 티어 설정임에도 불구하고 모델의 불안정성 때문이 아니라 일일 제한량 때문에 실행 기간이 일주일 이상 늘어났습니다.

설정 (Setup)

이번 실행은 시리즈의 나머지 부분과 동일한 Ship-Bench 구조를 사용했지만, 런타임 (Runtime) 세부 사항은 저의 일반적인 Windows 설정과는 달랐습니다. 이는 하네스 (Harness) 동작과 환경적 마찰이 에이전트 기반 워크플로우의 실질적인 결과에 영향을 미칠 수 있기 때문에 중요합니다.

환경 (Environment)

Ship-Bench 컨텍스트 (Context)

Ship-Bench는 소프트웨어 개발 생명 주기 (SDLC)의 다섯 가지 역할인 설계자 (Architect), UX 디자이너 (UX Designer), 기획자 (Planner), 개발자 (Developer), 리뷰어 (Reviewer)를 통해 모델을 평가합니다. 각 단계는 다음 단계로 이어지는 산출물 (artifacts)을 생성하며, 이는 이 벤치마크가 개별 출력 품질을 측정할 뿐만 아니라, 모델이 현실적인 인수인계 중심의 워크플로 (workflow) 전반에서 연속성을 유지할 수 있는지 테스트하는 데 유용하게 만듭니다.

이번 실행에서는 표준화된 단순 지식 베이스 앱 작업을 사용했습니다. 해당 작업은 아키텍처 (architecture), 기획 (planning), 구현 (implementation), QA 사이의 유의미한 차이를 드러낼 만큼 충분히 규모가 크면서도, 실행 간의 깔끔한 비교를 방해할 정도로 제약이 없지는 않습니다. 설계자 (Architect), UX, 기획자 (Planner)가 모두 관문 (gates)을 통과했기 때문에, 이번 실행의 하위 단계(downstream phase)를 위해 표준 재실행 (canonical rerun)을 수행할 필요는 없었습니다.

전체 결과 (Overall Results)

설계자 (Architect)

설계자 (Architect) 단계는 모델이 제품 브리프 (product brief)를 명확한 결정과 최소한의 미해결 모호성을 가진 구체적인 기술 계획으로 전환할 수 있는지 테스트합니다.

인간 노트 (Human notes): Grok은 나머지 단계들을 안내하는 데 필요한 핵심 결정 사항들을 포함하여 합리적인 아키텍처 명세(architecture specification)를 생성했으며, 구현과 기사 작성 사이의 경과 시간을 고려할 때 의존성 버전도 충분히 근접했습니다. 다만, 일부 구간에서 지나치게 구체적이었을 수 있는데, 이는 더 많은 작업 여유(room to operate)를 갖는 것이 유리할 수 있는 후속 코딩 에이전트(downstream coding agents)들에게 긴장감을 유발할 수 있습니다.

실질적 시사점 (Practical takeaway): 이는 매우 강력한 아키텍처 결과물이었으며 견고한 시작이었습니다. 비록 지금까지 제가 본 최고 수준의 아키텍처 실행(architecture runs) 기준에는 약간 미치지 못했을지라도 말입니다.

UX 디자이너 (UX Designer)

UX 단계는 디자인 방향이 흐름(flows), 상태(states), 레이아웃 결정(layout decisions), 상호작용 세부 사항(interaction details)을 포함하여 구현을 안내할 수 있을 만큼 충분히 구체적인지 평가합니다.

인간 노트 (Human notes): 와이어플로우(wireflows)가 특히 강력했으며, 텍스트 와이어프레임(text wireframes)이 충분히 상세하여 문서가 핸드오프 산출물(handoff artifact)로서 상대적으로 완성도 있게 느껴졌습니다. Grok이 무엇의 우선순위를 낮출지에 대해 몇 가지 판단(judgment calls)을 내리긴 했지만, 전반적으로 이번 벤치마크 시리즈에서 지금까지 본 것 중 가장 우수한 디자인 명세 중 하나로 느껴졌습니다.

실질적인 시사점 (Practical takeaway): Grok 4.5의 UX 작업은 단순히 상세하기만 한 것이 아니라 실제로 구축하기에 진정으로 유용했기 때문에, 해당 그룹 내에서 최상위권에 가까웠습니다.

Planner (플래너)

플래너 단계는 모델이 이전의 산출물(artifacts)을 합리적인 작업 크기(task sizing)와 의존성 순서(dependency order)를 갖춘 실행 가능한 전달 시퀀스로 변환할 수 있는지 테스트합니다.

인간 검토 의견 (Human notes): 버티컬 슬라이스(vertical-slice) 지향성은 큰 장점이었으며, 기능이 분할된 방식을 고려할 때 6회의 반복은 타당해 보였습니다. 익숙한 약점으로는 E2E(End-to-End) 테스트가 계획 전반에 걸쳐 통합된 규율로 다뤄지는 대신 여전히 마지막으로 밀려났다는 점이지만, 전반적으로 이는 다른 많은 벤치마크 실행 결과보다 나았습니다.

실질적인 시사점 (Practical takeaway): Grok 4.5는 유능한 딜리버리 리드(delivery lead)처럼 계획을 세웠습니다. E2E 테스트를 미루는 일반적인 벤치마크 습관을 여전히 따르고 있긴 하지만, 대부분 합리적이고 실행 친화적이며 평균보다 강력했습니다.

Developer (개발자)

개발자 단계는 모델이 이전의 산출물(artifacts)과 일관성을 유지하면서 할당된 백로그(backlog)를 작동하는 MVP로 구현할 수 있는지 측정합니다.

Human notes (인간 노트): 코딩 실행은 비교적 원활했으며, 가장 큰 실질적인 어려움은 Grok이나 Grok Build 자체보다는 무료 티어 (free tier)였습니다. Grok은 빠르다고 느껴졌고, 눈에 띄는 어려움 없이 엔드투엔드 (E2E) 작업을 처리했으며, 구현 루프 (implementation loop) 동안 조종 (steering)이나 수동 구조가 필요하지 않았습니다.

Practical takeaway (실질적 시사점): Grok 4.5의 가장 큰 실질적인 강점은 코딩하기 쉽다는 느낌을 준다는 점이며, 이는 실제 반복적인 에이전트적 (agentic) 작업에서 매우 중요합니다.

Reviewer (검토자)

검토 (Reviewer) 단계는 구축된 MVP가 실제로 브리프 (brief), 사양 (specs), 그리고 구현 계획을 충족하는지 확인함으로써 루프를 완성합니다.

Human notes (인간 노트): 이 단계는 이전 단계들보다 약하게 느껴졌으며, 보고서 자체도 다른 실행 결과의 검토자 출력물보다 간소해 보였습니다. 여러 개의 "수동 (통과) (manual (passed))" 항목이 존재하여 신뢰도가 낮아졌으며, 이로 인해 평가자의 결론이 검토자 산출물 (reviewer artifact) 자체보다 더 신뢰할 수 있게 느껴졌습니다.

실질적인 시사점 (Practical takeaway): Grok 4.5의 검토자 (reviewer)는 통과하기에 충분할 만큼 훌륭했지만, 이번 실행 과정 중 신뢰도가 가장 낮았던 단계였습니다.

토큰 및 비용 분석 (Token and Cost Analysis)

여기서는 경제성이 중요합니다. 왜냐하면 이 글의 핵심 목적이 Grok 4.5가 그 소매 가격(retail price)을 고려했을 때 강력한 결과를 제공하는지 여부이기 때문입니다. 하지만 이번 특정 실행에서는 워크플로가 무료 Grok 티어 (free Grok tier)에서 완료되었기 때문에 토큰 데이터를 사용할 수 없었으며, 따라서 실행 산출물 (run artifacts)로부터 정직한 실제 비용 추정치를 산출할 수 없습니다.

이는 여기서의 가성비(price/performance) 논쟁이 계량화된 것이 아니라 질적인(qualitative) 성격을 띤다는 것을 의미합니다. 결과는 Grok 4.5를 가치 측면에서 매력적으로 보이게 할 만큼 강력했지만, 본 기사는 테스트 환경 (harness)이 노출하지 않은 데이터 없이는 실제 포인트당 비용 (cost-per-point) 수치를 주장할 수 없습니다.

앱 비교 (App Comparison)

이번 실행을 위해 설정된 스크린샷 세트에는 기사 목록 (article list), 기사 상세 (article detail), 편집 뷰 (edit views)가 포함되어 있으며, 이는 완전한 UX 비교 세트는 아닐지라도 기본적인 시각적 확인을 하기에는 충분합니다.

스크린샷 (Screenshots)

주관적 UX 리뷰 (Subjective UX review)

Grok 4.5 UI

Grok 45 UI

Grok 4.5 기사 뷰 (Article View)

Grok 45 Article View

Grok 4.5 에디터 (Editor)

Grok 45 Editor

주관적으로 볼 때, 제공된 앱은 벤치마크의 차분하고 정보 우선적인 지식 베이스 (knowledge-base) 목표에 충분히 일관성 있고 완성도 있게 보입니다. 시각적 시스템은 일관되어 보이고, 레이아웃은 깔끔하며, 전체적인 결과물은 망가진 프로토타입이라기보다 실제로 작동하는 내부 앱처럼 보입니다. 다만, 편집 페이지는 약간의 다듬기 (polish)가 필요할 수 있습니다.

해석 (Interpretation)