Claude를 이용해서 AI Coding 도구를 상세 비교해봤어요. 2025년 9월 말 기준 Claude에서도 Open AI Codex가 가장 좋다고 하네요.

AI 코딩 도구 상세 비교

기본 정보 비교

접근 방식 및 플랫폼

핵심 기능 비교

성능 벤치마크

*추정치 (공식 벤치마크 미공개)

가격 정책

지원 언어 및 프레임워크

장단점 요약

GPT-5-Codex

장점: 최고 성능, 동적 작업 시간, 강력한 코드 리뷰 단점: 상대적으로 높은 비용, API 제한

Claude Code

장점: 터미널 특화, 자연어 처리 우수, 단계별 설명 단점: CLI만 지원, IDE 통합 없음

GitHub Copilot

장점: 광범위한 IDE 지원, Git 통합, 큰 커뮤니티 단점: 실시간 완성 위주, 복잡한 프로젝트 구축 제한

Gemini CLI

장점: Google 생태계 통합, 최신 AI 기술 단점: 상대적으로 새로움, 제한적인 문서

Cursor

장점: 올인원 에디터, 실시간 협업, 직관적 UI 단점: 새로운 에디터 학습 필요, 플랫폼 의존성

Windsurf

장점: 통합 개발 환경, 웹 개발 특화 단점: 상대적으로 새로움, 제한적인 언어 지원

선택 가이드

• 최고 성능 원할 때: GPT-5-Codex
• 터미널 작업 중심: Claude Code
• 기존 IDE 계속 사용: GitHub Copilot
• Google 생태계 사용자: Gemini CLI
• 올인원 솔루션: Cursor
• 웹 개발 중심: Windsurf
• 예산 고려: Codeium (무료)

AI가 급격히 발전하기 시작한 배경에는 모델 학습 효율을 높이는 다양한 시도도 중요했지만,  GPU·TPU 같은 하드웨어 성능의 도약과 학습 데이터의 폭발적 증가가 있었다.  즉, 모델 크기·데이터 규모·연산량이 함께 커지는 **Scale**의 증가가 큰 역할을 했다고 본다.  이는 AI 발전에서 자주 언급되는 Scale의 법칙(Laws of Scale)과 맞아떨어지는데,  이 법칙은 모델 크기·데이터 양·연산량이 일정 비율로 커지면 성능이 비약적으로 향상된다는 경험법칙을 말한다.  물리적 한계에 비유하자면, 지구의 가장 큰 포유류가 고래이고 그 이상 커지기 어려운 것처럼,  일부 연구자들은 이제 LLM도 Scale의 법칙만으로는 더 큰 발전을 이루기 어렵다고 지적한다.

최근 GPT-5가 발표되었지만, 일부에서는 “이제 발전이 멈춘 것 같다”는 이야기를 한다.  아마도 이러한 Scale의 법칙 한계 지적이 배경에 있을 것이다.  하지만 나는 조금 다르게 본다.  GPT-4 시기부터 멀티에이전트적 활용 가능성과 내부 조율 기능이 강화되기 시작했고,  GPT-5에서는 이를 한 단계 발전시켜 실시간 라우터가 요청을 분석해 여러 전문 모델(에이전트)에 작업을 자동 배분하는 구조를 도입했다고 OpenAI와 외부 분석에서 전한다.  이는 마치 CPU가 작업 특성에 따라 고성능 코어(P-core)와 저전력 코어(E-core)를 선택하는 멀티코어 아키텍처와 비슷하다.

그렇다면 다음은 무엇일까?  
CPU가 슈퍼스칼라, 멀티코어, 하이브리드 구조로 발전해온 것처럼,  AI 모델도 구조적 돌파구를 찾으며 또 한 번의 Breakthrough를 만들까?  
아니면 지금과는 완전히 다른 패러다임의 아키텍처가 등장할까?  
그 방향이 어디로 향할지는 아직 알 수 없지만, 분명 흥미롭고 기대되는 시점이다.

참고 자료

• OpenAI – Introducing GPT-5
• The Verge – GPT-5 announced
• SiliconAngle – GPT-5 hybrid routing system

들어가며

나는 기술이 대중화되었는지를 확인할 때, 아내를 자주 관찰한다. LCD TV, 스마트폰도 아내를 통해서 대중화되고 있구나를 알았다. IT 업계에서 일하는 나와 달리, 그녀는 기술을 도구로써 '필요할 때 적절히' 사용하는 사람이다.

그런 아내가 요즘 ChatGPT를 능숙하게 다루는 걸 보며, 나는 문득 이렇게 생각했다. “이제는 정말, 누구나 AI를 사용하는 시대가 되고 있구나.”

그런데 이 AI, 어디까지 갈 수 있을까? 그리고 우리는 이 흐름을 어디서 본 적 없을까?

바둑에서 일어난 일 – 알파고와 알파고 제로의 혁명

2016년, 인류는 바둑이라는 영역에서 엄청난 전환점을 맞았다. 딥마인드의 알파고(AlphaGo)는 이세돌 9단을 4:1로 꺾으며, 인간 직관의 마지막 보루 같던 바둑에서조차 인공지능이 앞설 수 있음을 보여주었다.

많은 이들이 이세돌 9단과의 대국을 기억하지만, 정작 더 충격적인 장면은 그 다음에 펼쳐졌다. 2017년 등장한 알파고 제로(AlphaGo Zero)는 단 한 판의 인간 기보 없이, 오직 스스로의 셀프플레이를 통해 불과 40일 만에 기존 알파고를 압도했다.

이 사건은 AI가 인간 지식 기반 없이도 스스로 학습하고 창의적으로 전략을 만들어낼 수 있다는 가능성을 보여준 대표적 사례였다.

지금 일어나고 있는 일들 – LLM과 그 확장

지금 우리는 언어의 세계에서 바둑에서 일어났던 비슷한 변화를 목격하고 있다. ChatGPT, Claude, Gemini 등 수많은 대규모 언어 모델(LLM)은 인간이 만들어온 방대한 텍스트를 학습하며 인간과 자연스럽게 대화하는 능력을 갖추고 있다. 그리고 지금, 이들 모델은 바둑에서 일어났던 똑같은 알고리즘인 강화학습(RLHF)을 통해 사람의 선호를 더 정교하게 반영하는 방법도 익혀가고 있다.

역사는 반복된다고 했다. 바둑에서 인간이 먼저 가르치고, 이후 AI가 인간을 초월했던 그 흐름이, 지금 언어 영역에서도 서서히 닮아가고 있는 것이다.

자연어가 바둑과 같을까? 다를까?

그런데 여기서 잠깐, 중요한 차이를 짚고 넘어가야 한다. 바둑과는 달리, 언어는 훨씬 복잡한 세계다. 언어는 바둑보다 훨씬 더 복잡하고 주관적인 영역이라는 점이다. 바둑은 승패가 있고, 규칙이 명확하며, 수의 선택지 또한 한정적이다. 하지만 언어는 정답이 하나가 아니며, 문맥과 문화, 감정과 뉘앙스 같은 비정형적인 요소들이 핵심이다.

그렇다면 요즘 각광받고 있는 LLM이 다루는 언어의 측면에서 AI가 인간을 넘어설 수 있는 영역은 없는 것일까? 이 질문에 대한 현재의 답은 "있다" 이다. 공동 주의가 명확하고, 의미가 고정되며, 목표와 피드백이 명확한 도메인들이다. 대표적으로:

• 프로그래밍: 문법이 명확하고, 출력과 결과를 정량적으로 평가할 수 있다. 이미 GPT는 상위 10% 개발자 수준의 코드를 작성할 수 있다는 평가를 받고 있다.
• 수학: 증명 과정이 엄격하며, 논리적 정합성을 따진다. DeepMind의 AlphaGeometry나 AlphaProof는 수학 올림피아드 문제를 해결하며 가능성을 보여주었다.
• 법률: 판례, 조항, 문서가 구조화되어 있고, 텍스트 비교와 요약이 중요하다. AI는 판결문 초안을 작성하고, 숨겨진 불이익 조항을 탐색할 수 있을 정도다.

이런 도메인에서는 AI가 이미 “도구”를 넘어 “조력자” 혹은 “대체자”로 진화하고 있다.

마치며 – 인간 중심일까, AI로부터의 배움일까

사실 나는 이 부분에서 양가감정을 느낀다. 하나는, 기술은 인간을 통해 완성된다는 믿음이다. AI는 인간의 언어, 데이터, 피드백 없이는 자랄 수 없고, 결국 그 방향성도 인간이 제시할 것이다.

하지만 동시에, 나는 이렇게도 생각한다. AI가 우리보다 뛰어난 부분이 있다면, 우리는 오히려 배워야 하지 않을까? AI가 발견한 전략, 표현, 논리를 통해 우리는 지금의 인간을 넘어설 수 있는 기회를 얻는지도 모른다.

이 두 가지 생각 사이에서 나는 여전히 전자 쪽에 조금 더 기울어 있다. 이 때, 떠오르는 영화가 있다. "Hidden Figures"의 주인공들의 대사에서 발췌해 본다.

Katherine: "They can't replace the mind."
Dorothy: "That’s true. But human beings still push the buttons."

Machine Learning(ML) 기술이 발전하면서 빠르게 기존 시스템과 통합이 이루어 지고 있다. LLM도 단순히 사람들이 ChatGPT와 같은 서비스를 사용하는 것을 넘어서서 Cloud를 통해서 여러 시스템과 통합이 이루어 지고 있다. 아래 그림데로 많은 ML 시스템에서 실제로 학습이나 예측에 사용되는 코드가 극히 일부에 불과하다는 것이 이미 알려져 있다[1]. 이러한 관점에서 기존의 여러 기술들이 ML 기술들과 통합되어야 한다. 이러한 관점에서 숨겨진 기술 부채(Hidden Technical Debt in Machine Learning)가 많을 수 있다.

특히, 기존의 성능과 관련된 항목에서도 이러한 부분을 살펴 볼 수 있다. 여기서는 성능 관점의 지연 시간(Latency)와 규모확장성(Scalability)에 대해서 잠시 살펴 보자.

기존 기술의 경우에도 Cloud를 기반으로 하게 되면 최종 사용자의 위치에 따라서 실재 연산을 처리하는 서버의 위치(Region)은 중요한 부분 중에 하나이다. 간단히 말하자면, 한국에 있는 사용자가 미국에 있는 서버에 접속해야 하는 경우라면 결국 요청을 미국 서버에 보내고 처리한 결과를 다시 한국에 있는 사용자에게 보내려면 시간이 걸릴 수 밖에 없다. 그렇다면, LLM의 Foundation Model을 운영하는 Cloud의 Region을 최종 사용자에 맞게 최적화 할 필요가 있다.

규모 확정성(Scalability)의 경우도 사용자가 많아 지면 하나의 LLM 인스턴스로 처리하는 것은 문제가 될 수 있을 것이다. 이것도 결국에는 Load balancing 이슈에 해당한다고 할수 있다. 결국 이러한 전통적인 문제는 기존과 같이 요청을 잘 분배해서 처리하는 구조가 필요하다[2].

참고 문헌

[1] D. Sculley et al., "Hidden Technical Debt in Machine Learning Systems",  https://papers.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf

[2] https://aws.amazon.com/ko/blogs/tech/multi-rag-and-multi-region-llm-for-chatbot/

[1]에서는 [2]에서 소개한 LLM Application의 Architecture를 위한 추상화 모델을 소개했다. [2]에서는 LLM 앱을 직접 구축하는 다섯 단계를 소개하고 있다. 그 내용을 살펴 보자.

• 문제에 집중: 처음에는 하나의 문제에 집중한다. 문제는 충분히 구체적이어서 빠르게 반복하고 진행할 수 있지만, 사용자를 감탄하게 할 정도로 충분히 큰 문제여야 한다.
• 올바른 LLM 선택: 특정 과제에 맞게 사전 훈련된 LLM을 선택한다. 상업적 사용이 가능한 라이센스가 있는 모델을 사용해야 할 수도 있다.
• LLM 맞춤화: LLM을 특정 작업에 맞게 조정하기 위해 인컨텍스트 학습, 인간 피드백에서의 강화학습(RLHF), 미세조정 등의 기술을 사용할 수 있다.
• 앱 아키텍처 설정: 사용자 입력, 입력 풍부화 및 프롬프트 구성 도구, 효율적이고 책임 있는 AI 도구 등 필요한 구성 요소를 설정한다.
• 온라인 평가 실시: 앱의 성능을 평가하여 사용자와의 상호작용 중에 모델의 출력 품질을 평가한다. 또한, 다양한 도구를 활용하여 사용자의 요구에 맞는 적절한 반응을 생성할 수 있도록 LLM을 최적화하고, 실시간 사용자 피드백을 통해 앱을 지속적으로 개선한다.

참고 문헌

[1] "Large Language Model의 추상화", https://technical-leader.tistory.com/127

[2] Nicole Choi, "The architecture of today’s LLM applications", https://github.blog/2023-10-30-the-architecture-of-todays-llm-applications/?fbclid=IwAR2daV0oLZAU8ZS45SeL5Wh7aVDcscJBL1hsEBBRVXW2rywoeqd6AnfwzJg

[1]에서도 다루었지만, 미리 트레이닝을 해야 하는 Machine Learning의 한 종류인 LLM도 동일한 특징을 가지고 있다. ChatGPT4o의 경우도  현재  23년 10월까지 업데이트 되어 있다고 한다. 이 부분의 한계를 극복하기 위한 것이 Retrieval Augmented Generation (RAG)이다. 이 부분은 추가된 정보를 제공해서 이를 기반으로 동작하게 하는 것이다. 이 동작을 이해하기 위한 몇 가지 개념이 있는데 임베딩 모델(Embedding Model), 벡터 데이터베이스(Vector Database)와 같은 개념이 있다. 이 부분에 대해서는 간단하게 다뤄 보자.

RAG(Retrieval-Augmented Generation)는 앞에서 언급한 Foundation Model이 최신 데이터를 가지고 학습하지 못한 문제를 해결하기 위한 방법 중 하나로,  LLM에 정보 검색을 결합하는 방식 또는 프로세스를 말한다. 즉, 검색된 정보를 이용해서 최신 정보와 원하는 정보를 추가하여 생성하도록 해서 신뢰성과 지식의 범위를 확장할 수 있도록 하게 한다.

이렇게 RAG를 하기 위해서 데이터를 추가 한다고 할 때, 추가된 데이터와 기존의 정보가 어떻게 관련되어 연관성이 있는지 알 수 있을까? 이를 이해하기 위해서 필요한 것이 임베딩 모델이다. 임베딩 모델은 정보를 다차원 공간의 조밀한 표현으로 캡슐화하도록 훈련된 알고리즘이다[2]. 좀 더 자세한 내용은 YouTube를 함께 보는 것도 좋다. 여기서 시각화 한 것과 같이 유사도를 vector측면에 cosine similarity를 사용하는지도 알 수 있다. 그리고, L2 distance 혹은 vector product도 사용할 수 있음도 알 수 있다. 이러한 것을 활용하여 시멘틱 서치(semantic search)가 가능해 진다.

이러한 정보를 어떻게 보관하고 사용할 것인가? 이를 위한 데이터베이스가 벡터 데이터베이스(vector database)이다[3]. 기존 데이터베이스도 위와 같은 임베딩을 저장하고 sementic search를 할 수 있지만, 저장된 모든 데이터의 embedding과 query embedding의 similarity를 연산해야 하기 때문에 너무 많은 연산을 해야 하고 느리게 결과를 가져오게 된다. 벡터 데이터 베이스는 자체적인 알고리즘으로 indexing하고 유사도 알고리즘을 조합하여 빠른 검색을 지원하므로 LLM에 RAG를 위해서는 이러한 데이터 베이스를 활용해야 한다.

결론은 [1]에서도 언급한 것처럼 LLM에 RAG이 적용되어야만 약점을 보완한 현대적인 아키텍처를 가진다고 볼 수 있다. 이 구조에는 임베딩 모델, 벡터 데이터 베이스들이 왜 연계되어 사용되는지, 그리고 왜 cosine similarity가 사용되는지 간단한  개념들이 살펴 볼 수 있다. 

참고문서

[1] Large Language Model의 추상화 , https://technical-leader.tistory.com/127

[2] 텍스트용 Vertex AI 임베딩: 간편해진 LLM 그라운딩, https://cloud.google.com/blog/ko/products/ai-machine-learning/how-to-use-grounding-for-your-llms-with-text-embeddings

[3] Vector Database: 벡터 임베딩을 저장하고 검색하는 가장 효율적인 방법, https://smilegate.ai/en/2023/11/07/vector-database-%EB%B2%A1%ED%84%B0-%EC%9E%84%EB%B2%A0%EB%94%A9%EC%9D%84-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B3%A0-%EA%B2%80%EC%83%89%ED%95%98%EB%8A%94-%EA%B0%80%EC%9E%A5-%ED%9A%A8%EC%9C%A8%EC%A0%81