Elixir 개발을 위한 주요 LLM(GPT 5.2, Claude Opus 4.5, Gemini 3 Pro) 비교 및 평가

Opus 4.5 vs. GPT 5.2 vs. Gemini 3 Pro for Elixir development

작성자
HackerNews
발행일
2025년 12월 18일

핵심 요약

  • 1 저자는 Elixir 프로젝트의 중규모 기능 설계를 위해 GPT 5.2, Claude Opus 4.5, Gemini 3 Pro 세 가지 LLM을 비교했으며, GPT 5.2가 가장 우수하다고 평가했습니다.
  • 2 GPT 5.2의 계획은 가장 정확하고 확장성이 뛰어난 것으로 평가되었으며, Claude Opus 4.5는 유효하나 병렬 응답 파싱 구조 도입으로 확장성에 한계가 있고 Gemini 3 Pro는 가장 구체성이 떨어지고 부정확했습니다.
  • 3 저자는 일상적인 작업에서 Claude Code가 빠른 속도와 다양한 기능을 제공하지만, Codex(GPT)가 더 철저하고 높은 품질의 코드를 생성하며 '/review' 기능이 특히 유용하다고 언급했습니다.

도입

본 게시물은 Elixir 코드 작성에 있어 어떤 LLM이 더 나은지에 대한 지속적인 논쟁에 대한 응답으로 작성되었습니다. 저자는 Google, OpenAI, Anthropic의 최신 LLM 모델인 Gemini 3 Pro, GPT 5.2, Claude Opus 4.5를 사용하여 중규모 프로젝트의 중규모 기능 설계를 비교 평가했습니다. 비교는 ReqLLM 라이브러리에 이미지 생성 지원을 추가하는 기능을 중심으로 이루어졌으며, 각 모델은 동일한 프롬프트를 사용하여 계획을 작성하고, 이후 각 모델에게 다른 모델의 계획을 비교하도록 요청하여 결과를 도출했습니다.

저자는 ReqLLM 프로젝트의 이미지 생성 지원 기능 구현 계획에 대해 세 가지 LLM의 성능을 분석했습니다. 다음은 각 모델에 대한 평가와 전반적인 경험에 대한 세부 사항입니다.

LLM 계획 평가 순위

저자의 평가 순위는 GPT 5.2 > Opus 4.5 > Gemini 3 Pro였습니다. 흥미롭게도, 세 모델 모두 이 평가에 동의했습니다.

각 모델별 상세 평가

  • GPT 5.2: 저자는 GPT의 계획을 유일하게 ‘정확한’ 계획으로 간주했습니다. 이는 이미지 지원 확장, 스트리밍 추가 등 향후 확장성을 고려할 때 가장 적합한 접근 방식을 제시했기 때문입니다.

  • Claude Opus 4.5: Claude의 계획은 기능적으로는 작동하지만, 본질적으로 병렬 응답 파싱 인프라를 도입하여 향후 이미지 지원 확장이나 스트리밍 추가를 어렵게 만들거나 불가능하게 할 수 있다고 평가되었습니다. 또한, Claude는 계획의 일부로 큰 구현 청크를 작성하는 경향이 있었습니다.

  • Gemini 3 Pro: Gemini의 계획은 가장 구체성이 떨어지고 정확도가 낮았습니다. 또한, 잘못된 이미지 생성 엔드포인트를 사용하는 문제가 발견되었습니다.

일상적인 작업 경험

저자는 Claude Code와 Codex(GPT)를 매일 사용하며 얻은 경험을 공유했습니다.

  • Claude Code: 더 깔끔한 출력, 병렬/백그라운드 실행과 같은 더 많은 기능, 더 빠른 작업 속도를 제공합니다.

  • Codex(GPT): 훨씬 더 철저하며 대부분 더 높은 품질의 코드를 생성합니다. 특히 Codex의 ‘/review’ 기능은 과소평가되어 있으며, 저자 자신, Claude, 또는 다른 Codex가 작성한 코드에 대해 항상 ‘/review’를 실행하여 최신 패치로 인해 도입된 미묘한 엣지 케이스와 버그를 찾는 데 탁월하다고 강조했습니다.

결론

이번 LLM 비교를 통해 Elixir 개발 환경에서 중규모 기능 설계 시 GPT 5.2가 가장 우수하고 정확하며 확장성 있는 계획을 제시한다는 결론이 도출되었습니다. Claude Opus 4.5는 유효하지만 확장성 측면에서 한계가 있었고, Gemini 3 Pro는 가장 낮은 평가를 받았습니다. 전반적으로 GPT 기반 모델인 Codex가 코드 품질과 깊이 있는 분석 능력에서 강점을 보였으며, 특히 '/review' 기능은 개발 워크플로우에서 매우 유용하다는 점이 부각되었습니다. 이는 개발자들이 LLM을 활용할 때 단순히 기능이나 속도뿐만 아니라 생성된 계획의 품질과 확장성을 종합적으로 고려해야 함을 시사합니다.

댓글 0

로그인이 필요합니다

댓글을 작성하거나 대화에 참여하려면 로그인이 필요합니다.

로그인 하러 가기

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!