AI 컨텍스트와의 사투를 멈추는 방법: Rider에서의 JetBrains AI vs. Copilot 비교

지난 화요일, 저는 .NET 9 API를 부팅하려고 시도하던 중 새로운 Program.cs 파일에서 System.NullReferenceException: Object reference not set to an instance of an object. (Parameter 'serviceProvider') 오류를 뚫어지게 쳐다보고 있었습니다. 반전은 무엇이었을까요? 그 코드는 거의 전적으로 AI 어시스턴트(AI assistant)로부터 생성된 것이었습니다. 저는 레거시 .NET 7 서비스를 마이그레이션하는 속도를 높이기 위해 Rider 2026에서 JetBrains AI Assistant와 GitHub Copilot을 활용하려 노력해 왔는데, 솔직히 말해서 이 둘 사이의 컨텍스트(context)를 조율하는 과정이 저를 조금 미치게 만들고 있었습니다.

한동안 저는 실제 코드를 작성하는 시간보다 AI가 출력한 결과물을 디버깅(debugging)하는 데 더 많은 시간을 쓰고 있다는 느낌을 받았습니다. 제 목표는 단순했습니다. AI를 사용하여 상용구 코드(boilerplate)를 덜어내고, 거대한 코드베이스(codebase) 내의 생소한 패턴을 이해하며, 전반적으로 일상적인 업무 속도를 높이는 것이었습니다. 하지만 처음에 제가 마주한 결과는 미완성된 제안들과 컨텍스트를 무시한 리팩터링(refactor)이 뒤섞인 혼돈 그 자체였습니다. 상당한 시행착오를 거친 끝에, 마침내 저에게 효과적인 실용적인 접근 방식을 찾아낸 것 같습니다.

컨텍스트의 난제: 나의 가정이 무너진 지점

저의 초기 실수는 JetBrains AI Assistant(Claude Sonnet 4.6 기반)와 GitHub Copilot(최신 Copilot for Workspaces 버전)을 모두 서로 대체 가능한, 모든 것을 알고 있는 신탁(oracle)처럼 취급했다는 점입니다. 저는 채팅창에 질문을 던지거나, 인라인 완성(inline completion) 기능이 마법처럼 제 프로젝트 구조 전체를 이해하기를 기대했습니다. 하지만 이는 거의 작동하지 않았습니다.

예를 들어, JetBrains AI Assistant에게 "이 프로젝트에 새로운 AuditLogService를 추가해줘"라고 요청하면, 제가 기존에 설정해둔 의존성 주입 (DI) 설정, appsettings.json 컨벤션, 또는 다른 모든 곳에서 사용 중인 ILogger 패턴을 완전히 무시한 채 뼈대만 있는 클래스 정의를 반환했습니다. 기술적으로는 올바른 C# 코드였지만, 제 컨텍스트 (Context) 내에서는 전혀 쓸모가 없었습니다. 반면, Copilot은 종종 순수하게 구문 (Syntax)과 지역 변수 (Local variables)만을 기반으로 한 줄을 완성하곤 했는데, 이는 아키텍처적인 함의 (Architectural implications)를 완전히 놓치는 것이었습니다. 심지어 _dbContext가 주입되기 전에 사용되어, 제가 앞서 언급했던 그 끔찍한 NullReferenceException을 유발하는 코드 블록을 받은 적도 있습니다.

제가 받았던 출력물의 단순화된 예시는 다음과 같습니다. 컴파일은 되지만 제 상황에는 딱 맞지 않는 형태였습니다:

// JetBrains AI Assistant에게 "새로운 AuditLogService를 추가해줘"라고 요청함
public class AuditLogService
{
...

문제는 AI의 지능이 아니라, 저의 프롬프트 전략 (Prompting strategy)과 AI의 컨텍스트 인식 (Context awareness)에 대한 기대치였습니다. Rider 2026의 MCP (Model Context Protocol) 지원이 관련 코드 스니펫 (Code snippets)을 제공하는 데 훌륭한 역할을 수행하지만, AI가 독심술사는 아닙니다. 저는 명시적인 컨텍스트 (Explicit context)가 가장 중요하다는 것을 배웠습니다.

나만의 워크플로우 찾기: 두 어시스턴트 이야기

결과적으로 저는 이들을 경쟁자가 아닌 상호 보완적인 도구로 취급하며 더 명확한 역할 분담을 하게 되었습니다. 개인마다 차이가 있을 수 있지만, 이 방식은 제 생산성을 획기적으로 향상시켰습니다.

Rider에서의 GitHub Copilot: 이것은 저의 빠른 근육 기억 (Fast-twitch muscle memory)과 같습니다. 빠른 인라인 완성 (Inline completions), 보일러플레이트 (Boilerplate) 생성, 특정 메서드에 대한 단위 테스트 (Unit tests) 작성, 또는 단순히 XML 문서 주석 (XML documentation comments)을 채우는 작업 등에 있어 Copilot은 믿을 수 없을 정도로 효율적입니다. 컨텍스트가 좁고 현재 파일이나 주변 라인에서 즉시 확인할 수 있을 때 탁월한 성능을 발휘합니다. 저는 if (string.IsNullOrWhiteSpace(value))와 같은 코드를 작성하거나 switch 식 (Switch expressions)을 생성할 때 Copilot을 끊임없이 사용합니다. 또한, 로컬 함수를 추출하거나 LIN LINQ 쿼리를 단순화하는 것과 같이 단일 메서드 내에서의 빠른 리팩터링 (Refactor)을 위해 Copilot Edits를 사용하는 것도 놀라울 정도로 유용하다는 것을 발견했습니다.

// 빠른 완성 (Completion) 및 테스트 생성 (Test generation)을 위해 Copilot 사용
public interface IOrderService
{
...

Rider에서의 JetBrains AI Assistant (Claude Sonnet 4.6 포함): 더 깊은 이해, 아키텍처 리팩터링 (Architectural refactoring), 또는 더 미묘한 코드 생성 (Code generation)이 필요할 때 제가 찾는 도구입니다. 이 도구의 강점은 채팅 인터페이스에 있으며, 이를 통해 다회차 대화 (Multi-turn conversations)와 명시적인 컨텍스트 제공 (Context feeding)이 가능합니다. 복잡한 레거시 클래스 (Legacy class)를 이해해야 할 때, 저는 파일 전체를 채팅창에 붙여넣고 "이 LegacyOrderProcessor의 의존성 (Dependencies)과 책임 (Responsibilities)을 설명해줘"라고 요청한 뒤, 이어서 "이 코드를 .NET 9용 CQRS 패턴을 사용하여 리팩터링할 전략을 제안해줘"라고 후속 질문을 던집니다. 프롬프트 (Prompt)를 작성하는 데 더 많은 노력이 들지만, 복잡한 작업에 대한 결과물의 품질은 현저히 높습니다. 특히 까다로운 문제의 경우 어시스턴트를 통해 Claude Opus 4.7을 사용하기도 했는데, 속도는 더 느립니다.

// 리팩터링을 위해 JetBrains AI Assistant에 프롬프트 입력
// (먼저 채팅창에 'LegacyOrderProcessor' 클래스 전체를 붙여넣었다고 가정합니다)
"제공된 `LegacyOrderProcessor` 클래스를 `IOrderStategy` 패턴을 사용하도록 리팩터링해줘.
...

이러한 이중 도구 접근 방식은 Copilot이 작고 국소적인 작업들을 처리하는 동안, JetBrains AI Assistant는 제가 제공하는 더 명시적인 컨텍스트의 도움을 받아 더 큰 그림을 다루는 것을 의미합니다.

저는 여전히 Copilot for Workspaces의 광범위한 컨텍스트 기능을 활용하면서도, 특히 초기 .NET 10 프리뷰 (Preview) 기능을 다룰 때 쏟아지는 제안들에 압도되지 않는 최선의 방법을 찾아가는 중입니다. 만약 여러분이 대규모 .NET 리팩터링을 위해 Rider에서 JetBrains AI Assistant와 GitHub Copilot을 효과적으로 통합하여 사용하고 계신다면, 여러분의 전략이나 겪었던 시행착오 (Pitfalls)를 꼭 듣고 싶습니다.