레거시 .NET 코드에서 AI와 싸우는 것을 멈춘 방법

현대적인 AI 도구들을 사용하기 전의 제 워크플로우는 끊임없는 컨텍스트 스위칭 (Context Switching)의 반복처럼 느껴졌습니다. 하루의 절반을 솔루션 탐색기 (Solution Explorer)를 뒤지고, 의존성 (Dependencies)을 이해하기 위해 파일 사이를 점프하며, 보일러플레이트 (Boilerplate) 코드를 수동으로 작성하는 데 소비하곤 했습니다. 디버깅 (Debugging)은 코드를 한 줄씩 따라가며 진행해야 했고, 10년 넘게 유지되어 온 복잡한 .NET Framework 4.8 서비스에서 문제의 근본 원인을 추측해야 하는 경우가 많았습니다.

이제 GitHub Copilot for Workspaces와 Claude Opus 4.7 같은 도구들이 Visual Studio 2026 및 Rider 2026에 통합되면서 상황이 달라졌습니다. 보일러플레이트 (Boilerplate) 코드, 초기 테스트 초안, 심지어 모호한 C# 13 구문을 설명하는 것까지 AI가 처리합니다. 새로운 기능을 시작하거나 작고 고립된 모듈을 이해할 때 발생하는 마찰이 급격히 줄어들었습니다. 하지만 이러한 새로운 효율성은 또 다른 종류의 마찰, 즉 내 특정 코드베이스에 대해 실제보다 더 많이 알고 있다고 생각하는 도구와의 미묘한 싸움을 불러왔습니다.

아키텍처적 뉘앙스에 대한 AI의 사각지대

저는 Claude Sonnet 4.6과 같은 최신 모델조차 깊은 아키텍처적 컨텍스트 (Architectural Context)를 파악하는 데 상당한 어려움을 겪는다는 것을 빠르게 배웠습니다. AI는 단일 파일 내에서의 국소적인 코드 생성 및 리팩터링 (Refactoring)에는 탁월합니다. 하지만 멀티 프로젝트 솔루션 (Multi-project Solution)에서의 횡단 관심사 (Cross-cutting Concern)를 이해하거나, 수년에 걸쳐 진화해 온 서비스 레이어 (Service Layer)를 리팩터링하라고 요청하면 그 제안은 종종 실패하곤 합니다. 저의 경우, 많은 현대적 패턴보다 앞서 만들어진 커스텀 이벤트 기반 아키텍처 (Event-driven Architecture)를 사용하는 우리의 주요 레거시 .NET 9 서비스를 다룰 때 이 점이 특히 두드러졌습니다.

지난 화요일, 저는 세 개의 서로 다른 프로젝트에 걸쳐 있는 PaymentProcessor 인터페이스와 그 구현체들을 리팩터링(refactor)하려고 시도했습니다. 저는 Cursor 0.42+에 전체 솔루션 구조와 관련 파일들을 입력하며, AI가 암묵적인 도메인 지식(domain knowledge)을 파악하기를 기대했습니다. AI는 깔끔하고 현대적인 C# 13 인터페이스와 추상 기본 클래스(abstract base class)를 생성했지만, 우리의 커스텀 메시지 버스(message bus)가 PostProcess 메서드와 어떻게 통합되는지에 대해서는 완전히 빗나간 결과를 내놓았습니다. MediatR 알림(notification)이 예상되는 상황에서 직접적인 의존성 주입(dependency injection)을 제안한 것입니다. 구문(syntax)상으로는 완벽했지만, 아키텍처(architecture) 측면에서는 틀렸습니다.

// PaymentProcessor를 리팩터링하려는 AI의 초기 제안
// 깔끔해 보이지만, 우리의 내부 메시지 버스 통합을 완전히 놓치고 있음
public class StripePaymentProcessor : IPaymentProcessor
...

문제는 AI가 코드를 생성하지 못하는 것이 아니라, 수년 전에 왜 특정 설계 결정이 내려졌는지에 대한 깊고 암묵적인 이해가 부족하다는 점입니다. AI는 아키텍처를 형성한 역사적 맥락, 트레이드오프(trade-offs), 또는 구체적인 비즈니스 규칙을 알지 못합니다. 이것이 바로 ai csharp의 한계가 진정으로 드러나는 지점입니다. 저는 아키텍처 패턴(architectural patterns)과 내부 컨벤션(internal conventions)에 대해 매우 상세한 맥락을 제공하는 것이 도움이 된다는 것을 발견했지만, 그럼에도 불구하고 끊임없는 수정 작업의 연속입니다.

보이지 않는 것의 디버깅: 환경 특화적 실패

제가 AI 코딩의 한계에 지속적으로 부딪히는 또 다른 영역은 환경 특화적(environment-specific)인 문제를 디버깅할 때입니다. 고급 MCP (Model Context Protocol) 기능을 갖춘 모델이라 할지라도, AI 모델들은 일반적인 코드 패턴과 공개 문서의 방대한 데이터셋으로 학습됩니다. 이들은 구문 오류를 식별하거나, 일반적인 예외(exception)를 제안하거나, 잘 알려진 프레임워크 내의 잠재적인 레이스 컨디션(race condition)을 찾아내는 데는 탁월합니다. 하지만 버그가 .NET 10 Preview가 실행되는 특정 Kubernetes 클러스터에서만 나타나거나, 서드파티 라이브러리의 네이티브 의존성(native dependency)과의 미묘한 상호작용으로 인해 발생하는 경우, AI는 종종 일반적이고 도움이 되지 않는 조언만을 제공합니다.

지난달 저는 우리 서비스가 스테이징(staging) 환경에 배포되었을 때만 발생하는 System.Net.Http.HttpRequestException을 해결하기 위해 사흘을 허비했습니다. Copilot Edits는 계속해서 네트워크 연결 문제나 잘못된 기본 URL(base URL)을 제안했습니다. Claude Opus 4.7에 스택 트레이스(stack trace)와 관련 코드를 입력했을 때는, 우리 설정에는 존재하지도 않는 프록시(proxy) 구성에 대해 환각(hallucination)을 일으켰습니다. 결국 그것이 스테이징 환경의 구버전 로드 밸런서(load balancer) 펌웨어와 관련된 특정 TLS 1.3 협상(negotiation) 문제였다는 것을 알아내는 데 창피할 정도로 많은 시간이 걸렸습니다. 이는 코드 자체와는 완전히 무관한 외부 요인이었습니다.

# 2일 후 Claude Opus 4.7에게 보낸 나의 절박한 프롬프트(prompt)
# Claude의 응답은 HTTP 클라이언트 모범 사례(best practices)에 대한 일반적인 목록이었습니다.
# 그것은 환경을 '볼' 수 없었습니다.
...

이것이 바로 복잡한 분산 시스템(distributed systems)을 다루는 .NET 개발자들이 AI에 대해 느끼는 한계입니다. AI는 런타임 환경(runtime environment), 네트워크 상태, 또는 특정 배포의 구체적인 구성을 관찰할 수 있는 "눈"이 부족합니다. AI는 자신이 보는 코드에 대해서만 추론할 수 있을 뿐, 저장소(repository) 외부에 존재하는 복잡한 요인들 간의 상호작용은 파악하지 못합니다. 개인마다 경험은 다를 수 있겠지만, 저에게 있어 환경 특화적인 디버깅(debugging)은 여전히 깊이 인간적인 영역으로 남아 있습니다.

저는 여전히 AI에게 주도권을 맡기는 것과 저 자신의 직관 및 경험을 믿어야 할 때를 아는 것 사이에서 최적의 균형을 찾아가는 중입니다. AI가 많은 작업에서 강력한 가속기(accelerator)라는 점은 분명하지만, 아키텍처 의도(architectural intent)와 보이지 않는 환경적 요인에 대한 이해는 여전히 초기 단계에 머물러 있습니다.

만약 여러분도 레거시 .NET 코드를 다루거나 미묘한 환경 특화적 버그를 해결할 때 AI 도구의 유사한 한계에 부딪힌 적이 있다면, 어떤 전략이 효과적이었는지 듣고 싶습니다.