바야흐로 모델 전성시대 입니다.

AI에게 뭔가 있을 시키려고 하면 먼저 어느 모델에게 시킬지 결정해야합니다. 그런데 막상 선택하려고 보면 너무나 많은 모델이 있죠.

GPT에는 Sol/Terra/Luna가 있고, Gemini에는 3.7 Flash/Flash-Lite가 있습니다. Claude에는 Fable/Sonnet/Opus가, Grok에도 여러 모델과 도구가 있습니다. 프론티어 모델 뿐만 아니라 각종 작은 모델들도 넘쳐납니다.

문제는 모델마다 성능과 특성이 모두 다르다는 점입니다.

예를 들어 AI에게 계약서를 검토하는 일을 시킨다면 요약까지만 해주는 모델보다 깊은 추론을 통해 예외 조항과 근거까지 정리해 주는 모델이 필요합니다. 반면 고객 문의 10만 건을 분류하는 일을 시켰다면 깊은 추론을 하는 모델 보다 빠르고 저렴한 모델이 더 나을 수 있습니다.

계약서 검토에는 추론과 긴 문맥 이해를, 대량 분류에는 속도, 비용, 형식 정확도가 중요하겠죠. 최신 정보를 다뤄야 한다면 검색같은 도구 사용을 잘하는지도 중요합니다.

그래서 모델 선택은 가장 똑똑한 놈 하나를 고르는 일이 아니라, 내 업무에 필요한 능력, 추론 강도, 문맥 크기, 도구, 비용을 조합하는 일이 라고 볼 수 있습니다.

우리는 여러 AI제품 이름을 들을 수 있는데 GPT/Gemini/Claude/Grok는 모델 계열을 의미하고, ChatGPT/Claude Code/Codex/Antigravity는 모델에 파일+검색+도구+화면을 결합한 작업 환경입니다. 이 글에서는 그 중에서 어떤 모델을 어떤 설정으로 쓸는게 적절한지에 대해 이야기 해보려고 합니다.

본격적으로 모델 이야기를 하기 앞서 먼저 AI 모델과 관련된 용어들부터 정리를 해보겠습니다.

파운데이션 모델? 프론티어 모델?

파운데이션 모델(Foundation Model)은 언어, 이미지, 코드처럼 넓은 데이터를 미리 학습해 여러 일에 재활용할 수 있는 범용 기반 모델입니다. 이 위에 대화형 AI, 검색 AI, 코딩 에이전트, 사내 문서 AI 같은 제품을 만들고 업무에 필요한 추가 기능을 붙입니다. 최신 또는 최고 성능이라는 뜻은 아니며, GPT/Gemini/Claude/Grok 같은 모델 계열이 대체로 여기에 속합니다.

요즘 얘기되는 독자 파운데이션 모델(독.파.모) 프로젝트는 국내 기술로 이런 파운데이션 모델을 만들어 보겠다는 프로젝트입니다.

프론티어 모델(Frontier Model)은 현재 가장 어려운 문제 해결을 겨냥한 최상위 모델입니다. 정해진 기술 규격이 아니라 시대에 따라 바뀌는 상대적 표현입니다. 프론티어 모델은 보통 파운데이션 모델이지만, 모든 파운데이션 모델이 프론티어 모델인 것은 아닙니다. 비용과 시간이 문제가 안된다면 프론티어 모델을 선택하는게 좋습니다. 다만 회의록 요약/문의 분류/데이터 추출처럼 기준이 명확한 일에는 프론티어가 아닌 균형형/고속 모델이 더 빠르고 경제적일 수 있겠죠.

증류 모델(Distilled Model)은 큰 모델의 답변과 판단 패턴을 작은 모델이 배우도록 만든 모델입니다. 증류는 큰 모델이 만든 질문/답변 예시를 작은 모델이 학습하는 방식이 주로 쓰입니다. 정답만 학습시키는 경우도 있고 큰 모델이 답을 고를 때 사용한 각 선택지의 확률 분포까지 함께 학습시키기도 합니다.

분류/추출/정해진 형식의 답변처럼 범위가 명확한 업무에서는 이렇게 만든 더 작고 빠른 모델도 충분한 성능을 낼 수 있습니다.

자사의 큰 모델을 증류해서 빠르고 저렴한 작은 모델을 만드는 경우도 있지만, 최근에는 타사 모델을 무단으로 증류하는 사례가 늘어 국제적 지적 재산권 분쟁 요인이 되기도 합니다.

멀티모달(Multimodal)은 텍스트뿐 아니라 이미지/표/음성/영상처럼 여러 형태의 정보를 함께 이해하거나 생성하는 능력입니다. 모델에 따라 이미지/음성등의 입력까지만 지원하는 경우가 있고 이미지/음성 생성까지 지원하는 경우가 있습니다.

오픈웨이트 모델(Open-weight Model)은 학습된 모델의 가중치(weights)를 공개해, 사용자가 직접 내려받아 온프레미스 서버나 로컬기기에서 직접 실행/수정/파인튜닝할 수 있게 한 모델입니다.

외부 API 대신 내부 환경에서 운영해야 하거나, 비용/데이터 통제/세밀한 커스터마이즈가 중요하다면 오픈웨이트 모델을 검토할 수 있습니다. 반면 서버 운영, 보안, 성능 최적화등도 직접 책임도 져야 합니다.

모델 라우터(Model Router)는 모델의 종류가 아니라 여러 모델을 운영하는 방식입니다. 요즘 워낙 다양한 모델이 나오다 보니 이런 모델 라우터가 많이 생기고 있는데요, 모델 라우터는 일반 LLM모델처럼 LLM요청 사항을 처리하는 프로토콜이 구현이 되어 있고, 어플리케이션이 여기에 LLM요청을 보내면 모델 라우터가 자기에게 등록된 모델중 적절한 모델을 골라서 처리한 후에 그 결과를 다시 어플리케이션에 돌려줍니다.

즉 어플리케이션 입장에서는 다양한 모델을 각각 연결할 필요 없이 모델 라우터가 하나의 LLM 모델인 것 처럼 이것 하나만 연결하면 여러 모델을 골라 쓸 수 있게 되는거죠.

요청을 할때 수동으로 혹은 정해진 규칙에 따라 모델을 지정하는 방식이 있고, 요청의 난이도/문서 길이/비용/필요한 도구를 분석해서 적절한 모델을 선택하는 스마트 라우터 방식이 있습니다.

정리하면 파운데이션/프론티어는 모델의 역할과 위치, 증류는 모델을 만드는 방식, 오픈웨이트는 모델을 어떻게 배포하고 통제할 수 있는지, 라우터는 모델을 운영하는 방식을 말합니다.

모델은 어디에서 실행되는가?

추가로 모델이 어디에서 실행되는가에 따라서도 구분할 수 있는데 AI는 보통 세 방식으로 씁니다.

• 클라우드 서비스형: ChatGPT/Claude/Gemini처럼 서비스 화면이나 API로 호출합니다. 데이터 보안은 공급자가 책임집니다. 사용자들은 이에 대한 책임 범위가 서비스 공급 계약에 명시가 되어 있는지 확인 해야 하죠. 그리고 일반적으로 사용한 만큼 비용을 내는 경우가 많습니다.

• 자체 운영형: 오픈웨이트 모델이나 자체 개발 모델을 회사 서버에 올려 씁니다. 데이터 통제와 맞춤화에는 유리하지만 운영/보안 책임이 생기고 높은 초기 투자 비용이 발생합니다. 또한 프런티어 모델을 유지하려면 대형 서비스 공급자들 못지 않은 모델 갱신 비용을 투자해야 하는데, 이 금액이 막대하기 때문에 쉽게 시도하기 어려운 방식입니다.

• 기기 내 실행형: 휴대폰/PC에서 직접 실행합니다. 개인정보와 응답 지연에는 유리하지만 모델 크기와 성능에 제약이 있습니다.

모델을 고를 때는 성능뿐 아니라 회사 문서를 외부에 보내도 되는지, 누가 운영할지, 인터넷 없이도 써야 하는지도 등도 함께 판단해야 합니다.

추론 모델? 에이전트 모델?

이전글에서도 언급했지만 그동안 모델이 지속적으로 발전해 오면서 기능에 따라 추론 모델이나 에이전트 모델처럼 새로운 이름들을 붙이게 되었습니다.

기본 언어 모델은 텍스트를 이해하고 생성하는 데서 출발했습니다. 이후 코딩, 이미지·음성·영상 이해 같은 멀티모달, 복잡한 문제를 단계적으로 검토하는 추론 능력이 더해졌습니다. 여기에 계획을 세우고 도구를 호출해 실제 작업을 수행하는 능력과 실행 환경이 결합되면서 에이전트가 만들어졌습니다.

기본 언어 모델

  ├─ 코딩 능력

  ├─ 멀티모달 능력

  └─ 추론 능력

        └─ 계획·도구 호출 능력

              → 에이전트 시스템

이런 과정을 거쳐서 오늘날 프론티어 모델은 이런 능력을 모두 가지고 있는 경우가 많습니다. 이제는 "코딩을 할 수 있는가?"처럼 특정 기능을 묻기보다 우리의 Task를 얼마나 안정적으로, 얼마나 빠르게, 얼마나 경제적으로 끝내는가를 비교해야 되는거죠.

모델을 고를 때 보는 여섯 가지 기준

모델을 선택할 때 고려해야 하는 부분은 아주 다양합니다. 하지만 여기서는 여섯 가지로 정리해 보았습니다.

1. 기본 문제 해결 능력: 파라미터 수? 실제 과업 성능?

더 많은 파라미터를 가지는 상위 모델은 복잡한 조건을 연결하거나 낯선 문제를 푸는 데 대체로 유리합니다. 하지만 최신 상용 모델의 파라미터 수는 거의 공개되지 않고, 공개돼도 학습 데이터/구조/후속학습/추론 방식이 달라 성능을 비교할 수 없습니다. 따라서 파라미터 숫자보다는 우리의 어려운 사례를 얼마나 정확히 해결하는가를 봐야 합니다.

예를 들어 "필요한 정확도를 지키는가?" 같은 지표가 될 수 있겠죠.

2. 추론 깊이: 더 오래 생각할 수 있는가?

추론 모델은 답을 내기 전 문제를 나누고 가설과 대안을 검토합니다. GPT-5.6은 none~max, Gemini 3 계열은 thinking level로 추론 강도를 조절합니다.

여기서 기본 모델의 능력과 추론 강도는 역할이 다른 두 축입니다. 하나는 문제의 난이도를 이해하는 바탕이고, 다른 하나는 그 바탕을 얼마나 꼼꼼히 쓰는지를 정합니다. ("#4.3 추론모델" 참고)

즉 이렇게 정리할 수 있습니다.

• 상위 모델: 복잡하고 낯선 문제, 미묘한 예외, 긴 작업을 이해할 기본 능력이 더 높다.

• 고속/저비용 모델: 규칙이 명확하고 반복적인 작업에서는 충분히 잘할 수 있다.

• 높은 추론 강도: 조건/예외/근거를 더 많이 검토 할 수다. 그래서 중요한 항목을 놓칠 가능성을 낮출 수 있다.

• 낮은 추론 강도: 검토 단계가 적어 빠르고 싸지만, 복잡한 작업에서는 예외/근거/반대 조건을 놓칠 위험이 커진다.

그래서 업무의 복잡도와 처리량에 따라 적절한 모델의 기본 능력 + 추론 강도 조합을 찾는것이 중요합니다.

같은 문제를 다른 조합에 맡기면 어떻게 달라질까?

예를 들어 다음과 같은 요청을 생각해 봅시다.

복잡한 계약서에서 위험 조항을 찾고, 그 근거와 예외 조건을 함께 설명해 줘.

아래 예에서는 GPT-5.6 계열을 세 역할로 나눠 보겠습니다. Sol은 복잡한 추론과 코딩을 겨냥한 상위 모델, Terra는 품질/속도/비용의 균형을 겨냥한 모델, Luna는 대량 작업을 빠르고 경제적으로 처리하는 모델입니다. 같은 요청이라도 기본 모델과 추론 강도를 어떻게 조합하느냐에 따라 결과가 달라질 수 있습니다.

기본 능력과 추론 강도를 조합하면 다양한 결과를 기대할 수 있게 되는데, 아래 표는 그에 대한 예시 입니다.

높은 추론 강도는 모델의 기본 능력을 더 꼼꼼히 쓰게 하지만, 작은 모델의 기본 한계나 제공되지 않은 근거까지 없애지는 못한다는 점을 주목할 필요가 있습니다.

3. 컨텍스트 윈도우: 얼마나 많이 넣는가? 필요한 것을 찾는가?

컨텍스트 윈도우는 모델이 한 번에 읽을 수 있는 입력의 최대 범위입니다. GPT-5.6 Sol/Terra/Luna는 모두 약 105만 토큰, Gemini 3.6 Flash와 Gemini 3.5 Flash-Lite는 100만 토큰의 입력 문맥을 제공합니다.

긴 문맥은 긴 계약서/보고서/코드베이스에 유용하지만, 컨텍스트 윈도우가 너무 커지면 중요한 조건을 놓치거나 문맥을 잘못 이해하고 엉뚱한 답변을 할 수 있습니다. 이런 현상을 컨텍스트 열화(Context Rot)라고 합니다.

또 입력 토큰이 늘면 비용과 응답 시간도 커집니다. 따라서 ‘100만 토큰’처럼 숫자로 표현되는 컨텍스트 크기만 볼 게 아니라 문맥에서 중요한 내용을 얼마나 잘 인식하는가를 확인해야 합니다. 각 모델의 트랜스포머 능력에 따라 이 부분이 차이가 날 수 있습니다.

4. 토큰 비용: 다양한 토큰 종류 만큼 과금 체계도 다양함

요즘 서비스형 AI는 토큰 단위로 과금을 합니다. 단순히 입출력 토큰을 계산해서 과금을 하면 될것 같지만 실제 과금이 되는 방식은 상당히 복잡합니다.

입력 토큰, 캐시된 입력 토큰, 출력 토큰, 내부 추론(Reasoning) 토큰 등은 서비스에 따라 별도 항목으로 집계되거나 과금에 반영됩니다. 도구 사용과 에이전트가 작업 중 쌓는 중간 기록, 즉 에이전트 경로(Agent Trajectory)를 어떻게 보존/압축/재투입하는지에 따라서도 소비량이 달라집니다.

일반 대화에서는 보통 이전 출력 토큰 전체가 다음 요청의 입력으로 누적되지만, 리서치나 코딩 에이전트는 검색/실행 결과 가운데 필요한 일부만 전달 되는 경우도 많은 것을 참고해야 합니다.

한 번의 요청 비용 

= 일반 입력 토큰 + 캐시된 입력 토큰

+ 내부 추론 토큰 + 최종 답변 토큰

+ 도구 호출/이미지/영상 같은 추가 사용 토큰

5. 도구와 멀티모달: 실제 작업으로 연결할 수 있는가?

텍스트뿐 아니라 이미지/표/음성/영상을 이해하는지, 검색/파일 검색/코드 실행/함수 호출/컴퓨터 사용 같은 도구를 쓸 수 있는지를 확인해야 합니다.

예를 들어 GPT-5.6과 Gemini 3.6 Flash는 이미지 입력과 도구 호출을 지원하고, Gemini 3.6 Flash는 코드 실행/파일 검색/검색 grounding(Google 검색 결과를 근거로 답하고 출처를 붙이는 기능)을 제공합니다.

6. 배포 방식과 데이터 통제: 어디에서 운영할 것인가?

같은 수준의 모델이라도 클라우드 API로 쓸지, 오픈웨이트 모델을 자체 서버에서 운영할지, 기기 안에서 실행할지에 따라 선택이 달라집니다. 외부로 보낼 수 없는 문서가 있는지, 운영/보안을 누가 책임질지, 응답 지연과 초기 투자 비용을 감당할 수 있는지를 함께 확인해야 합니다.

업무와 모델 선택 예제

이번에는 업무 종류에 따라 적절한 모델을 선택하는 예시를 몇가지 들어보겠스니다.

“고객 문의 10만 건에서 환불/배송/결제 유형을 분류해 줘.”

긴 추론보다 처리량/형식 정확도/비용이 중요합니다. Luna, Flash-Lite, Haiku 같은 고속/저비용 계열부터 시험하고, 분류 기준과 JSON 형식을 얼마나 안정적으로 지키는지 평가합니다.

“매주 들어오는 회의록을 요약하고, 담당자별 할 일을 정리해 줘.”

특별히 어려운 추론이나 대량 처리가 아니라면 Terra나 Sonnet 5 같은 균형형 모델이 첫 후보입니다. 문맥 길이뿐 아니라 담당자와 마감일을 빠뜨리지 않는지 시험합니다.

“이 계약서와 별첨을 비교해 우리 회사에 불리한 예외 조항을 찾아 줘.”

Sol, Opus 4.8, Fable 5처럼 복잡한 판단/장기 과업용 모델을 첫 후보로 둡니다. 높은 추론 강도에서 근거/예외/반대 해석을 얼마나 빠짐없이 찾는지 평가합니다.

“버그를 고치고 테스트를 통과시킨 뒤, 변경 내역을 설명해 줘.”

코딩 실력은 기본이고 거기에 코드베이스/터미널/테스트/브라우저를 오가므로 도구 사용과 긴 작업의 안정성이 중요합니다. Gemini 3.7 Flash, Sonnet 5/Opus 4.8, Grok 4.5, Sol/Terra등을 실제 개발 환경에서 비교하고, 답변 품질보다 테스트 통과율/불필요한 변경 수/실패 뒤 복구 능력을 측정합니다.

“오늘 나온 경쟁사 발표와 고객 반응을 찾아 보고서로 정리해 줘.”

모델의 내부 지식만으로는 풀 수 없으므로 웹 검색/출처 인용/필요하면 X 검색을 연결해야 합니다. Grok 4.5는 웹/X 검색과 코드 실행을, Gemini 3 계열은 Google 검색 결과를 근거로 답하고 출처를 붙이는 검색 grounding과 파일/코드 도구를 지원합니다. 검색 결과도 출처가 주장을 뒷받침하는지 확인해야 합니다.

숫자로 바로 비교할 수 있는 것과 없는 것

사양표에서는 같은 단위로 적힌 항목끼리만 비교해야 합니다. 다음은 모델명을 바꿔도 같은 기준으로 확인할 수 있는 항목입니다.

반대로 다음은 사양표의 숫자만으로 고르기 어렵습니다.

• 파라미터수 (최신 상용 모델은 파라미터 수를 대체로 공개하지 않고, 공개되더라도 기본 문제 해결 능력을 그대로 뜻하지 않습니다. )

• 긴 문서에서 핵심을 찾는 능력

• 지시를 지키는 정도

• 도구를 써서 과업을 끝내는 능력

결국 모델의 사양은 후보를 좁히는데만 사용하고, 최종 선택은 실제 과업 평가를 통해서 해야 합니다.

실제 모델을 고르는 4단계

1. 업무와 실패 기준을 한 문장으로 적는다

모델명부터 찾지 말고, 실패 비용이 가장 큰 업무 사례를 먼저 적습니다. 아래 질문에 답하면 비교 기준이 정리됩니다.

2. 역할이 다른 후보를 세 개로 좁힌다

어려운 사례용 상위 모델, 기본값이 될 균형 모델, 반복 업무용 고속/저비용 모델을 하나씩 고릅니다. 필요한 입력 형식, 도구, 배포 조건은 앞의 여섯 기준으로 걸러 냅니다.

3. 같은 사례로 품질·시간·비용을 비교한다

중요한 사례 20~50개를 골라 세 후보에 같은 조건으로 맡깁니다. 상위 모델의 답을 품질 기준선으로 삼고, 균형·고속 모델이 필요한 정확도와 형식을 지키면 기본값으로 내립니다.

상위 모델로 품질 기준선 만들기

                ↓

균형·고속 모델을 같은 사례로 시험하기

                ↓

품질이 충분한 가장 낮은 비용의 모델을 기본값으로 선택

                ↓

어렵거나 불확실한 사례만 상위 모델 또는 사람에게 보내기

4. 에이전트는 행동 권한 체크도 필요

파일 수정/검색/코드 실행을 하는 에이전트는 답변 품질만으로 고를 수 없습니다. 볼 수 있는 자료, 실행할 수 있는 명령, 사람의 승인 지점, 실패 뒤 되돌리는 방법을 정하고 도구 호출 성공률·테스트 통과율·복구 능력까지 기록합니다.

흔한 오해

“가장 비싼 모델 하나만 쓰면 안전하다”

상위 모델도 사실 확인을 대신하지는 않습니다. 최신 정보/수치/법률/의료/재무 판단은 근거를 확인해야 합니다. 비싼 상위모델보다 잘 만들어진 하네스가 더 도움이 될 수 도 있습니다.

“작은 모델은 단순한 챗봇에만 쓴다”

입출력 형식이 명확한 대량 분류/추출/변환에는 고속 모델이 더 경제적이고 충분히 정확할 수 있습니다.

“벤치마크 점수가 가장 높으면 우리 업무에도 최고다”

공개 시험은 후보를 좁힐 뿐입니다. 우리 문서/규칙/도구/오류 비용이 들어가는 실제 사례로 최종 시험해야 합니다.

한 모델로 고정하지 않기 : 모델 라우터와 멀티에이전트

실제 서비스는 하나의 모델에 고정할 필요가 없습니다. 앞에서 언급한 모델 라우터를 쓰면, 반복 업무는 빠른 모델로, 어려운 판단/긴 문서 검토는 상위 모델로 나눠서 보낼 수 있습니다.

더 복잡한 업무에서는 메인 에이전트와 여러 서브에이전트가 협업하는 멀티에이전트(Multiagent) 구조를 구성할 수 있습니다. 메인 에이전트 또는 오케스트레이터가 일을 계획하고 역할별 에이전트에 나눕니다. 각 에이전트는 역할에 따라 가장 적절한 모델이 배정됩니다. 예를 들어 빠른 모델은 분류·추출을, 상위 모델은 위험 판단을, 코딩에 강한 모델은 테스트와 수정안을 맡는 식입니다.

위는 요청 하나를 알맞은 모델로 보내는 모델 라우터, 아래는 하나의 복잡한 일을 여러 역할 에이전트에 나누는 멀티에이전트 구조입니다.

핵심은 각 작업에 필요한 수준의 모델을 필요한 순간에 쓰는 설계입니다.

한 줄 정리

모델을 선택할 때는어려운 일에는 상위 모델, 대부분의 일에는 균형 모델, 반복 업무에는 고속/저비용 모델이라는 역할부터 잡으세요. 최종 선택은 순위표가 아니라 우리 업무 사례로 검증합니다.

Appendix: 최신 프론티어 모델들의 특징

OpenAI: Sol, Terra, Luna

GPT-5.6은 Sol(복잡한 추론/코딩), Terra(성능/비용의 균형), Luna(비용에 민감한 대량 작업)로 역할을 나눕니다.

GPT-6 Astra는 그보다 높은 난도의 전문 업무와 컴퓨터 사용을 겨냥한 OpenAI의 최상위 모델입니다. 특히 도구를 쓰는 사이버 보안 능력은 OpenAI의 최고 위험 등급(Critical)에 해당해, 일반적인 모델 선택 항목이면서도 강한 접근 통제와 모니터링을 전제로 배포됩니다.

Google: Flash가 ‘가벼운 모델’만을 뜻하지는 않는다

2026년 9월 출시된 Gemini 3.8 Flash는 3.7 Flash와 같은 속도·출시 가격(입력 100만 토큰당 $0.75, 출력 $3.75)을 유지하면서 코딩·에이전트 작업·전문 분야의 다단계 추론을 강화한 모델입니다. 복잡한 작업에서는 더 많은 추론과 도구 호출을 사용해 품질을 높일 수 있어, 추론 강도를 높이면 토큰 소비도 함께 늘 수 있습니다. 보안 취약점 탐지와 패치에 특화된 Gemini 3.8 Flash Cyber는 별도의 신뢰된 방어자 프로그램을 통해 제공됩니다.

3.8 Flash는 장기 코딩/에이전트 작업을, 3.7 Flash는 효율이 중요한 작업을, 3.6 Flash는 코드 생성/멀티모달 추론을, 3.5 Flash-Lite는 문서 추출/JSON 변환/대량 분류를 겨냥합니다.

Anthropic: Fable, Sonnet, Opus

Claude의 Sonnet 5는 일반 코딩·브라우저/터미널 도구·업무 자동화용 기본 모델이며, Opus 4.8은 복잡한 분석·에이전트·긴 전문 업무를, Fable 5는 장기간 조사·연구와 고난도 코딩을 겨냥합니다. Fable은 일부 고위험 주제에서 안전장치에 따라 Opus 4.8로 전환될 수 있습니다.

Grok 4.5: 추론과 도구 사용

Grok 4.5는 코딩·에이전트·지식 업무용 상위 모델로, 50만 토큰 문맥과 조절 가능한 추론 강도, 함수 호출·웹/X 검색·코드 실행·구조화된 출력을 제공합니다. 이미지 생성·편집은 Grok 4.5 자체가 아니라 별도 모델군인 Grok Imagine이 담당합니다.

모델 정보 확인처

• OpenAI:

  • GPT-5.6 모델 안내

  • GPT-6 Astra 안전성 개요

• Google AI for Developers:

  • Gemini 모델 목록

  • Gemini 3.8 Flash 및 Flash Cyber 소개

• Anthropic:

  • Claude Fable 5

  • Claude Sonnet 5

  • Claude Opus 4.8

• xAI:

  • Grok 4.5 모델 문서

  • Grok 4.5 소개

  • 가격

  • Grok Imagine