최근 저는 GitHub Copilot의 멀티 모델 (multi-model) 기능을 테스트할 기회가 있었으며, 시장에서 사용 가능한 주요 모델인 Claude, Gemini, 그리고 ChatGPT를 실험해 보았습니다. 이들의 효과를 극대화하기 위해, 저는 Spec-kit과 결합하여 심층적인 저장소 컨텍스트 (repository context)를 제공했습니다.

광범위한 일상적 사용 끝에, 개발 워크플로우에서 어떤 모델을 언제 사용해야 하는지에 대한 저의 명확한 관찰 결과와 논거를 정리했습니다.

Claude - 치트키를 쓰는 것 같은 기분!

• 코드 생성 (Code Generation): 최상. 코드를 생성하는 데 있어 타의 추종을 불허하며, 복잡하고 다중 마이크로서비스 (multi-microservice)로 구성된 코드베이스를 이해하는 능력이 매우 뛰어납니다. 생성된 코드는 우리 코드베이스의 원칙과 관례(예: camelCase, snake_case)를 엄격히 준수합니다. 생성된 코드는 더 이상 사용되지 않는 메서드 (deprecated methods)가 전혀 없으며, 최신 패키지와 코딩 관행을 활용합니다.
• 컨텍스트 분석 (Context Analysis): 최상. 주어진 요구사항을 깊이 있게 이해하며, 저장소의 영향을 받는 모든 영역을 결점 없이 검색합니다.
• 일반 기술 분석 (General Technical Analysis): 최상. 종종 프롬프트 (prompt)를 한 번만 입력해도(one-shot) 정확히 필요한 것을 얻을 수 있습니다. 모델이 제안하는 솔루션은 대부분 실제로 선택하게 될 솔루션일 가능성이 높습니다.
• 토큰 사용량 (Token Usage): 매우 높음. 토큰 사용량을 제한하는 것이 거의 불가능합니다. 코드베이스가 클수록 토큰 소모 속도가 빨라집니다. 평균적으로 저는 한 달에 약 200달러 상당의 토큰을 소비했습니다. 저뿐만 아니라 제 팀에 5명이 더 있었습니다.

Gemini - 더 낫지만, 경계하십시오

• 코드 생성 (Code Generation): 좋음 (Good). 코드 생성 능력은 상당히 준수하지만, 가끔 루프(loop)에 빠지거나 해결책을 제공하는 데 너무 오래 걸릴 때가 있습니다. 추가적인 유도(nudging) 없이는 코드가 우리가 설정한 원칙이나 명명 규칙 (naming conventions)을 항상 따르는 것이 보장되지 않습니다. 최선의 해결책을 얻기 위해 단 한 번의 프롬프트 (one-shot prompts)로 신뢰할 수 있는 결과를 얻기는 어려우며, 주고받는 반복적인 피드백 (back-and-forth iteration)이 필요합니다.
• 문맥 분석 (Context Analysis): 매우 좋음 (Very Good). Claude와 거의 대등한 수준입니다. 전체 코드베이스 (codebase)를 분석하고 영향받는 영역을 정확하게 식별합니다.
• 일반 기술 분석 (General Technical Analysis): 매우 좋음 (Very Good). 기대하는 결과에 대해 깨끗하고 명확한 세부 정보를 제공하면 훌륭한 해결책을 제시합니다. 하지만 지침이 모호할 경우 환각 (hallucinate) 현상이 발생하는 경향이 있습니다.
• 토큰 사용량 (Token Usage): 최적 (Optimal). Claude처럼 예산을 깎아먹지 않습니다. 일상적인 작업이나 Claude 크레딧이 부족할 때 사용할 수 있는 최고의 대안입니다.

ChatGPT - 복잡한 코드베이스에는 신뢰하기 어려움

• 코드 생성 (Code Generation): 나쁨 (Poor). 완전한 해결책을 생성하는 경우가 드물며, 영향받는 클래스 (classes)나 인프라 코드 (infrastructure code)를 업데이트하는 것을 자주 잊어버립니다. 환각 (hallucinate)이 너무 빈번하게 발생하며, 출력 결과는 우리의 특정 코드베이스에 맞게 필요한 조정 없이 Stack Overflow에서 복사하여 붙여넣은 듯한 느낌을 줄 때가 많습니다.
• 문맥 분석 (Context Analysis): 보통 (Fair). 실제 코드 생성에는 어려움을 겪음에도 불구하고, 상위 수준의 분석 (high-level analysis)은 제법 수행합니다. 하지만 정확성과 일관성은 여전히 큰 문제입니다.
• 일반 기술 분석 (General Technical Analysis): 기초적 (Basic). 아무것도 없는 상태에서 시작하거나 간단한 스크립트를 작성할 때는 유용합니다. 규모가 큰 프로젝트의 경우, 대화 초반에 언급된 기술적 세부 사항을 기억하지 못할 때가 있습니다.
• 토큰 사용량 (Token Usage): 해당 없음 (N/A). 결과가 너무 일관되지 않아 투입할 가치가 없었기 때문에 장기적으로 사용할 수 없었습니다.

비밀 병기: Spec-kit

어떤 모델을 선택하든, Spec-kit은 이제 절대적으로 필수적인 도구가 되었습니다. 이는 LLM (Large Language Models)에 PR (Pull Request) 가이드라인과 코딩 베스트 프랙티스 (Best Practices)를 제공하는 가교 역할을 합니다. 예를 들어, 우리는 다음과 같은 규칙을 강제하기 위해 이를 사용합니다:

• PubSub 토픽 명명 규칙 (PubSub Topic Naming): <component>.<boundary>.<type>.<entity-purpose>[.<direction>.<ext-component>] 형식을 따라야 함
• 아키텍처 규칙 (Architecture Rules): 멱등성 (Idempotency), 아웃박스/인박스 패턴 (Outbox/Inbox patterns), 그리고 재시도/백오프 (Retries/Backoff)를 포함한 최소 한 번 전달 (At-least-once delivery) 적용
• 데이터베이스 스크립트 명명 규칙 (Database Script Naming): V<x>_<y>_<z>__<description>.sql 형식을 따라야 함

이러한 세부 사항들은 사소해 보일 수 있지만, LLM이 매우 관련성 높고 즉시 사용 가능한 (Drop-in-ready) 코드를 생성하는 데 필요한 필수적인 컨텍스트 (Context)를 제공하여, 사용자가 결과물을 수동으로 최적화해야 하는 수고를 덜어줍니다.

MCP를 통한 컨텍스트 강화

수동 타이핑을 더욱 줄이기 위해, 저는 오픈 소스 Jira 및 Confluence MCP (Model Context Protocols)를 제 Copilot 플러그인에 통합했습니다. 이를 통해 AI가 비즈니스 요구사항과 활성화된 Jira 티켓으로부터 컨텍스트를 직접 자동으로 가져올 수 있습니다. 이는 믿을 수 없을 정도로 효율적이지만, 주의할 점이 있습니다. 방대한 Confluence 문서를 프롬프트 (Prompt)에 직접 입력하면 토큰 사용량 (Token usage)이 크게 증가할 수 있습니다.