잘못된 질문: "가장 좋은 LLM은 무엇인가?"

현재 인공지능 (AI) 세계에서 가장 흔한 논쟁 중 하나는 겉보기에 단순해 보이는 질문을 중심으로 돌아갑니다: 가장 좋은 LLM (Large Language Model)은 무엇인가?

GPT-5? Claude? Gemini? DeepSeek? Qwen?

이 질문은 매우 대중적이지만, 저는 이것이 잘못된 전제에서 시작되었다고 믿습니다. 더 성숙한 AI 아키텍처 (Architecture)에서는 어떤 모델이 절대적으로 최고인가라는 문제는 거의 발생하지 않습니다. 가장 관련성 높은 질문은 다음과 같습니다: 시스템의 각 부분에 어떤 모델이 더 적합한가?

저는 많은 기업이 거대한 프롬프트 (Prompt)와 함께 단 하나의 LLM을 사용하여 모든 문제를 해결하려는 것을 봅니다. 언뜻 보기에 이 접근 방식은 단순해 보입니다. 하지만 복잡성이 증가함에 따라 예측 가능한 문제들이 발생합니다: 높은 비용, 더 큰 지연 시간 (Latency), 유지보수의 어려움, 컨텍스트 (Context) 낭비, 그리고 점점 더 일관성이 떨어지는 답변들입니다.

이유는 간단합니다. 모든 작업이 동일한 유형의 인지 능력을 요구하는 것은 아니기 때문입니다.

아키텍처를 설계하는 것은 작업을 실행하는 것과 다릅니다. 방대한 문서를 분석하는 것은 코드를 생성하는 것과 다릅니다. 결과를 평가하는 것은 정보를 검색하는 것과 다릅니다. 모든 것에 단 하나의 모델을 사용하려고 시도하는 것은 아키텍트, 개발자, QA, 비즈니스 분석가, 그리고 프로젝트 매니저의 역할을 동시에 수행할 단 한 명의 전문가를 고용하는 것만큼이나 비효율적입니다.

가장 진보된 AI 시스템은 단일 중앙 집중형 LLM이라는 아이디어에서 점점 멀어지고 있으며, 여러 전문화된 구성 요소로 이루어진 복합 아키텍처로 다가가고 있습니다.

이러한 시나리오에서 Harnesses, Agents, Skills, Memory, Retrieval, Evaluation과 같은 개념들이 등장합니다.

Harnesses는 워크플로 (Workflow)를 조정하는 역할을 담당하는 오케스트레이션 (Orchestration) 계층으로 작동합니다. 이들이 컨텍스트를 관리하고, 규칙을 적용하며, 도구 호출을 제어하고, 모델 간에 작업을 라우팅하며, 각 구성 요소가 필요한 정보만을 받도록 보장합니다.

Os Agents (에이전트)는 시스템 내에서 잘 정의된 책임을 가진 전문화된 엔티티를 나타냅니다. 단일 모델이 모든 것을 해결하려고 시도하는 대신, 서로 다른 에이전트가 특정 역할을 맡음으로써 복잡성을 줄이고 예측 가능성을 높일 수 있습니다.

Skills (기술) 또는 Tools (도구)는 에이전트가 외부 세계와 상호작용할 수 있도록 합니다. API 조회, 데이터베이스 액세스, 계산 실행 또는 검색 수행 등은 LLM (대규모 언어 모델)에 의해서만 독점적으로 해결될 필요가 없는 능력의 예시입니다.

또한, 현대적인 시스템은 Memory (메모리) 및 Retrieval (검색) 메커니즘에 크게 의존합니다. 모든 상호작용마다 방대한 양의 컨텍스트를 보내는 대신, 정보는 필요할 때만 검색됩니다. 이는 비용을 절감하고, 성능을 향상시키며, 컨텍스트 오염을 방지합니다.

자주 간과되는 또 다른 구성 요소는 Evaluation (평가) 계층입니다. 모델 또한 실수를 합니다. 응답을 검증하고, 비판하며, 평가하는 책임을 가진 메커니즘을 갖추는 것은 중요한 애플리케이션에서 점점 더 중요한 관행이 되었습니다.

이러한 생태계 내에서 서로 다른 모델들은 결국 각기 다른 역할을 수행하게 됩니다.

GPT-5와 같은 모델들은 계획 수립, 복잡한 추론, 문제 분해 및 시스템 아키텍처 작업에서 두각을 나타내는 경우가 많습니다.

Claude Opus는 방대한 문서 분석과 높은 문맥적 일관성이 요구되는 작업에서 뛰어난 성능을 보여줍니다.

Gemini는 멀티모달 (multimodal) 시나리오와 대량의 정보 처리에서 강점을 보입니다.

DeepSeek는 코드 생성 및 리뷰를 위한 매우 흥미로운 대안이 되었습니다.

반면 Qwen과 같은 모델들은 에이전트 워크플로우 (agentic workflows), 도구 호출 (tool calling) 및 오픈 소스 (open-source) 아키텍처에서 훌륭한 결과를 보여주고 있습니다.

이는 효율적인 아키텍처가 여러 모델을 동시에 사용할 수 있음을 의미합니다.

계획을 세우기 위한 하나의 모델.

실행을 위한 또 다른 모델.

컨텍스트를 검색하기 위한 Embeddings (임베딩).

결과를 검증하기 위한 평가자.

그리고 전체 흐름을 조정하기 위한 Harness (하네스).

이러한 진화를 관찰할 때, 경쟁 우위의 핵심이 이동하고 있다는 사실이 명확해집니다. 한동안 가장 중요한 기술은 더 나은 프롬프트 (Prompts)를 작성하는 것이었습니다. 하지만 오늘날 그 가치는 점점 더 컨텍스트 엔지니어링 (Context Engineering), 에이전트 엔지니어링 (Agent Engineering), 그리고 AI 시스템 아키텍처 (AI Systems Architecture)로 옮겨가고 있습니다.

LLM은 여전히 매우 중요한 구성 요소이지만, 더 이상 시스템 전체는 아닙니다.

진정한 강점은 컨텍스트 (Context), 메모리 (Memory), 도구 (Tools), 에이전트 (Agents), 그리고 특화된 모델 (Specialized Models)을 함께 작동하도록 어떻게 조직하느냐에 달려 있습니다.

그렇기에 아마도 향후 몇 년간 가장 중요한 질문은 어떤 LLM이 가장 좋은가 하는 것이 아닐지도 모릅니다.

어쩌면 질문은 다음과 같아야 할 것입니다: 각 모델로부터 최선의 결과를 끌어낼 수 있는 시스템을 어떻게 구축할 것인가?