최근 「결국 어떤 LLM이 가장 좋은가요?」라는 질문을 받는 일이 늘었습니다.

그 마음은 충분히 이해합니다. OpenAI, Anthropic, Google 등 각 기업에서 새로운 모델이 나올 때마다 추론 능력이나 코딩 성능, 컨텍스트 길이 (Context Length), 속도, 요금 체계 등이 화제가 됩니다. 순수하게 추론 능력만 본다면, 그 시점에서 각 기업이 내놓은 최신 플래그십 모델을 사용하고 싶어지는 것은 자연스러운 일입니다🧠

다만, 저의 최근 답변은 조금 다릅니다.

**「하나를 선택하는 것」이 아니라, 「전부 사용하는 것을 전제로 설계하는 것」**이 업무에서는 더 현실적이지 않을까 합니다. 적어도 저는 단일 모델·단일 실행의 결과를 그대로 믿을 정도로 아직 LLM을 신뢰하지는 않습니다.

이 기사는 모델 비교를 위한 벤치마크 기사가 아닙니다. 업무나 개인 개발에서 LLM을 사용할 때, 「어떤 모델이 최강인가」가 아니라 「어떤 모델 편성으로 구성해야 업무에 적합할까」를 생각하기 위한 idea 기사입니다🧭

그런 의미에서 제가 GitHub Copilot을 좋게 생각하는 이유 중 하나도, 단일 벤더의 세계관에 갇히지 않고 여러 회사의 모델을 선택지로 가질 수 있다는 점입니다. 공식 문서에서도 GitHub Copilot은 OpenAI, Anthropic, Google, Microsoft 등 여러 프로바이더의 모델을 지원하고 있으며, 집필 시점에서는 MAI-Code-1-Flash도 선택 가능한 모델로 안내되고 있습니다.

이 글을 다 읽고 나면, 단일 모델의 선정뿐만 아니라 생성·리뷰·반증·통합을 어떻게 나눌 것인가라는 설계 관점을 얻어갈 수 있을 것입니다.

먼저, 왜 이 질문이 어려운지를 정리하겠습니다.

「어떤 LLM이 가장 좋은가」라는 질문은 짧고 편리합니다.

하지만 실무에서 생각하면, 이 질문에는 여러 가지 전제가 숨어 있습니다. 무엇을 시키고 싶은가. 얼마나 빨리 응답받기를 원하는가. 비용은 어디까지 허용할 수 있는가. 일본어(또는 해당 언어)의 뉘앙스가 중요한가. 코드의 정확성이 중요한가. 사내 정보를 다루는가. 최종 판단을 인간이 하는가.

같은 「좋은 모델」이라도 목적이 다르면 평가는 달라집니다.

관점	흔한 견해	실무에서 필요한 질문
🧠 추론 능력	가장 똑똑한 모델을 고른다	이 업무의 판단에 필요한 추론인가
...

모델의 능력은 물론 중요합니다. 다만, 모델만 보고 있으면 업무의 목적이나 제약 조건에서 벗어나게 될 때가 있습니다.

특히 LLM은 temperature 등의 생성 설정에 따라 같은 요청이라도 실행할 때마다 답이 흔들릴 수 있습니다. 표현이 바뀌는 정도라면 괜찮지만, 관점의 누락, 판단의 강약, 리스크의 간과까지 달라질 수 있습니다. 제가 업무에서 사용할 때 두려운 것은 바로 이러한 흔들림입니다.

그렇기에 단순히 「가장 강력한 모델」을 찾기보다, 흔들림을 전제로 한 사용법을 설계하고 싶습니다.

저의 현재 결론은 상당히 소박합니다.

하나의 모델로 단정 짓지 않는다. 여러 모델을 병렬로 사용하며, 서로 경쟁시키고, 리뷰하게 하고, 마지막에 통합한다.

이것은 「모든 모델을 항상 최대 화력으로 사용한다」는 의미가 아닙니다. 중요한 것은 모델을 단일 도구로 보는 것이 아니라, 여러 관점을 가진 팀처럼 다루는 것입니다.

예를 들어, 어떤 모델은 구성을 만드는 데 능숙합니다. 다른 모델은 비판적인 리뷰가 날카롭습니다. 또 다른 모델은 문장의 자연스러움이나 바꿔 쓰기에 특화되어 있을지도 모릅니다. 모델이나 설정에 따라 출력 경향이 다르기 때문에, 코딩에서도 구현안을 내는 모델과 버그를 찾는 모델을 나누는 것이 다루기 쉬운 상황이 있습니다.

인간 팀에서도 한 명의 천재에게 모든 것을 맡기기보다 설계자, 구현자, 리뷰어, 운영 담당이 각자의 관점을 갖는 것이 품질을 높입니다. LLM에서도 마찬가지로 역할을 나누어 조합하는 발상이 유효하다고 느끼고 있습니다🤝

대략 그림으로 나타내면 다음과 같은 이미지입니다. 여기서 말하는 오케스트레이터(Orchestrator)는 반드시 전용 툴을 의미하지 않습니다. 사람이 절차로서 돌려도 되고, 스크립트나 워크플로우 기반으로 자동화해도 됩니다.

여기서의 주인공은 특정 모델명이 아니라, 태스크를 어떻게 분해하고, 어떤 관점을 어떤 모델에 담당시키며, 어떻게 통합할 것인가 하는 오케스트레이션 설계입니다.

다음 장에서는 실제로 사용하기 쉬운 패턴으로 구체화하겠습니다.

갑자기 거창한 기반을 만들 필요는 없습니다.

처음에는 같은 태스크를 여러 모델에 던져 비교하는 것만으로도 차이를 관찰하기 쉬워집니다. 익숙해지면 생성·리뷰·반증·통합의 역할을 나누어 가면서 사용법을 상당히 정리할 수 있습니다.

패턴	활용처	포인트
🧭 동일 태스크 병렬	방침 결정, 설계안, 문장 구성	동일한 입력을 여러 모델에 전달하여 공통점과 차이점을 확인
...

제가 특히 중요하다고 생각하는 것은, 한 번의 답변을 완성품으로 취급하지 않는 것입니다.

LLM의 답변은 첫 번째 결과물이라기보다, 리뷰 전의 초안 (Draft)에 가깝습니다. 잘 만들어진 경우도 있지만, 놓치고 있는 관점도 있습니다. 그렇기 때문에 다른 모델에게 읽게 하여 모순이나 전제의 누락을 지적하게 합니다.

여러 모델 운용을 시작하고 싶을 때, 첫 번째 장벽은 "어떻게 모델을 전환할 것인가"이기도 합니다. 이 지점에서 GitHub Copilot처럼 동일한 작업 환경 안에서 모델을 선택하기 쉬운 기반은 다루기 편합니다.

공식 모델 목록을 보면, GitHub Copilot은 OpenAI, Anthropic, Google, Microsoft 등 여러 프로바이더 (Provider)의 모델을 제공하고 있습니다. 즉, "먼저 OpenAI 계열로 초안을 만든다", "다음으로 Claude 계열로 비판적인 리뷰를 수행한다", "Gemini 계열로 다른 해답을 살펴본다", "경량 모델인 MAI-Code-1-Flash로 일상적인 가벼운 작업을 돌린다"와 같은 발상을 비교적 동일한 문맥 안에서 시도하기 쉽다는 뜻입니다.

물론 어떤 모델을 사용할 수 있는지는 플랜이나 제공 상황에 따라 달라지며, 조직의 정책에도 좌우됩니다. 그럼에도 불구하고 여러 회사의 모델을 횡단하여 사용할 수 있는 환경은, 모델 오케스트레이션 (Model Orchestration)을 실무에 적용하는 입구로서 상당히 강력하다고 느낍니다.

예를 들어, 설계 상담이라면 다음과 같이 흐름을 가져갑니다.

• 모델 A에게 설계안을 3개 내놓게 한다
• 모델 B에게 각 안의 실패 패턴과 운용 리스크를 지적하게 한다
• 모델 C에게 다른 관점에서 대안을 내놓게 한다
• 마지막으로 인간이 제약 조건에 비추어 채택안을 결정한다

이런 흐름으로 진행하면, 첫 번째 모델이 간과한 전제를 깨닫는 계기가 됩니다. 물론 최종적으로는 인간이 판단하지만, 판단 재료의 폭은 넓어집니다.

문장 작성도 마찬가지입니다. 구성안을 내는 모델, 독자의 흐름을 리뷰하는 모델, 표현을 다듬는 모델, 사실 확인 관점을 제시하는 모델을 나누면, 단일 모델로 한꺼번에 쓰는 것보다 다루기 쉬워질 때가 있습니다.

여러 모델을 사용하는 목적은 "다수결로 정답을 결정하는 것"이 아닙니다. 서로 다른 관점을 모아 누락이나 선입견을 찾기 쉽게 만드는 것입니다.

실무에 도입한다면, 처음에는 작은 평가 세트 (Evaluation Set)를 만드는 것을 추천합니다.

용도	평가 세트 예시	확인하고 싶은 것
🧱 설계 상담	과거에 고민했던 설계 과제 5건	전제 확인, 트레이드오프 (Trade-off), 유지보수성
...

이 정도의 작은 세트만으로도 자신들의 태스크에서 비교하는 시각을 갖기 쉬워집니다. "유명하니까", "벤치마크 점수가 높으니까"가 아니라, "우리 업무에서는 어떤 조합이 안정적인가"를 볼 수 있게 됩니다.

우선 추천하는 것은 2개 모델 비교, 상호 리뷰, 인간의 판단, 판단 이유의 기록까지 이어지는 최소 구성입니다. 내일부터 작게 시작한다면 다음 정도면 충분합니다.

• 영향이 너무 크지 않은 대상 태스크를 1개 선정한다
• 동일한 입력을 2개의 모델에 전달하여 공통점과 차이점을 기록한다
• 한쪽의 출력을 다른 쪽 모델에게 리뷰시킨다
• 채택한 판단과 버린 판단의 이유를 남긴다
• 몇 번 반복하여 작은 평가 세트로 만든다

여기까지 정리하면 꽤 편리해 보입니다. 하지만 여러 모델을 사용한다고 해서 모든 것이 해결되는 것은 아닙니다.

동일한 입력을 여러 모델에 보내면 API 호출 횟수가 늘어나기 때문에, 통상적으로 비용과 레이턴시 (Latency)도 상승합니다.

모든 의뢰를 매번 3개의 모델에 던질 필요는 없습니다. 가벼운 브레인스토밍, 영향이 적은 문장의 바꾸어 쓰기, 개인적인 메모라면 단일 모델로도 충분한 경우가 많습니다. 반면 설계 판단, 공개 문서, 고객에 대한 답변, 보안과 관련된 변경 사항 등은 여러 관점을 넣을 가치가 높다고 생각합니다.

태스크의 성격	단일 모델로 충분한 상황	여러 모델을 검토하고 싶은 상황
📝 문장	개인 메모, 가벼운 바꾸어 쓰기	공개 기사, 제안서, 중요한 메일
...

또 하나 중요한 것은, 합의된 것처럼 보이는 여러 모델이 똑같이 틀릴 가능성이 있다는 점입니다.

여러 개의 LLM (Large Language Model)이 같은 답을 내놓았다고 해서, 그것이 진실의 증명은 아닙니다. 답변이 일치하더라도 중요한 내용은 1차 정보 (Primary Information)로 확인해야 합니다. 따라서 사양이나 수치, 법무·보안·의료·계약 등과 관련된 내용은 반드시 1차 정보로 돌아가거나 전문가에게 확인해야 합니다.

데이터 취급에도 주의가 필요합니다. 여러 벤더 (Vendor)에게 동일한 입력을 보낸다는 것은 송신처도 늘어난다는 것을 의미합니다. 기밀 정보, 개인 정보, 계약상의 제약이 있는 데이터를 다루는 경우에는 모델의 성능 이전에 확인해야 할 사항이 있습니다. 이용하는 서비스나 계약 조건에 따라 데이터의 송신 가능 여부·저장·학습 이용·감사 요건을 확인해야 합니다🔐

여러 모델을 통한 크로스 리뷰 (Cross-review)는 인간의 책임을 대체하는 것이 아닙니다. 오히려 판단 재료를 늘린 상태에서, 마지막에 인간이 책임을 지기 위한 메커니즘입니다.

저는 LLM을 신용하지 않기 때문에 사용하지 않는 것이 아닙니다. 너무 신용하지 않기 위해서, 사용법을 설계하고 싶은 것입니다.

"어떤 LLM이 가장 좋습니까?"라는 질문에 단일한 답을 내놓기는 어렵습니다.

순수한 추론 능력만 본다면, 각 사의 최신 플래그십 모델 (Flagship Model)을 사용하는 것이 알기 쉬운 선택일지도 모릅니다. 하지만 업무에서 항상 최강의 단일 모델이 필요하다고 단정할 수는 없습니다. 중요한 것은 목적·제약·리스크·비용·책임에 맞는 사용법입니다.

저의 지금 답은 "하나로 좁히는 것"이 아니라 "여러 개를 조합하는 것"입니다.

동일한 태스크 (Task)를 여러 번 실행한다. 서로 다른 모델에 같은 질문을 던진다. 생성된 것을 다른 모델에 리뷰시킨다. 일부러 반대 의견을 내게 한다. 마지막에 인간이 나온 주장들을 비교하여 근거를 확인하고, 채택할 것을 결정한다.

우선 영향이 작은 태스크를 하나 골라, 두 개의 모델로 비교하는 것부터 시작하는 것만으로도 충분합니다.

LLM의 출력은 흔들립니다. 그렇기에 그 흔들림을 싫어하여 단판 승부로 끝내는 것이 아니라, 흔들림을 관측하고, 비교하고, 통합하는 설계로 만들고 싶습니다.

앞으로 모델은 점점 더 늘어날 것이고, 성능도 변해갈 것입니다. 그때마다 "어떤 모델이 최강인가"만을 쫓다 보면 지치게 됩니다.

그보다는 자신들의 업무에 맞는 모델 오케스트레이션 (Model Orchestration) 전략을 갖는 것. 저는 그곳에 앞으로의 LLM 활용에 있어 현실적인 강점이 있다고 생각합니다🧭

각 모델의 사양, 제공 상황, 가격, 제약은 변합니다. 실제로 선정할 때는 최신 공식 정보를 확인해 주세요.