Claude Code를 Visual Studio로 가져온 뒤 디버거를 맡겨보았다

Visual Studio 대신 VS Code에서 C# 프로젝트를 실행한 적이 수없이 많습니다. 이는 VS Code를 더 선호해서가 아니라, Claude가 수정을 제안했을 때 제가 수락하거나 거절하기 전에 실제 diff(차이점)를 통해 편집 내용을 확인할 수 있는 곳이기 때문이었습니다. 이미 GitHub에 이와 유사한 요청이 올라와 많은 추천을 받았지만 아직 답변이 없는 상태입니다. 그래서 저는 부족한 나머지 절반을 직접 만들었습니다.

시작은 diff 창이었습니다. Claude의 편집 내용이 터미널의 yes/no 프롬프트 대신 실제 Visual Studio의 diff 창에 나타나기를 원했습니다. 그것이 성공하자, 저는 다음으로 가장 큰 불편함으로 넘어갔습니다. 바로 Claude CLI가 컴파일러 에러와 경고, 린트(lint) 문제, 그리고 기타 빌드 출력 결과들을 일일이 복사해서 붙여넣는 대신 직접 읽을 수 있도록 하는 것이었습니다. 이것이 제 프로젝트의 v1이었습니다.

다음으로 큰 문제(이자 기회)는 제가 디버거를 사용하면서, 콘솔 로그를 추가하고 그 값들을 Claude CLI에 직접 입력하여 까다로운 문제를 올바른 컨텍스트(context)와 함께 디버깅하도록 만드는 상황을 마주했을 때 찾아왔습니다. 그래서 저는 Visual Studio의 디버거 자동화와 CLI 사이의 가교를 만들기 시작했습니다. 몇 주 후, Claude는 제 파일에 중단점(breakpoint)을 설정하고, 코드를 한 단계씩 실행(stepping)하며, 서로 다른 프레임에서 변수가 어떻게 변하는지 관찰하고, 제가 코드를 읽을 때 아마 그냥 지나쳤을 법한 버그가 어디에 숨어 있는지 저에게 알려주었습니다.

먼저 빠른 면책 조항을 말씀드립니다. 이것은 Anthropic과 관련이 없는 비공식 커뮤니티 프로젝트입니다. 오픈 소스이며, Visual Studio 2026을 대상으로 하고, Claude Code CLI가 설치되어 있어야 합니다. Anthropic CLI가 실제 모델 작업을 수행하는 주인공이며, 제 확장 프로그램은 이를 지원하는 IDE 사이드킥(sidekick)입니다.

저를 설레게 만든 실행 결과

이 점수 산정 함수를 확인해 보세요. 각 라운드는 점수를 획득하며, 점수 산정 라운드가 이어지면 콤보 배수(combo multiplier)가 쌓입니다. 첫 번째 적중은 1점으로 계산되고, 연속된 두 번째 적중은 2배로 계산되는 식입니다. 점수를 얻지 못한 라운드는 실행(run)을 중단시키고 콤보를 초기화해야 합니다.

컴파일도 잘 되고, 실행도 잘 됩니다. 그런데 잘못된 숫자를 출력합니다. {5, 3, 0, 4, 2, 0, 6} 라운드를 입력하면 정답은 25인데 61을 반환합니다. 소스 코드 어디를 봐도 잘못된 점이 없어 보입니다. IDE 경고도 없습니다.

저는 해당 파일을 한 번도 본 적 없는 새로운 Claude 세션을 열었습니다. 그런 다음 무엇이 문제를 일으키고 있는지 찾아달라고 요청했습니다.

Claude는 각 단계마다 콤보 (combo)와 누적 합계 (running total)를 읽으며 라운드를 하나씩 짚어 나갔습니다.

진행하면서 생성한 추적 (trace) 결과는 다음과 같습니다:

라운드 (round)	점수 (points)	이후 콤보 (combo after)	합계 (total)	예상값 (expected)
0	5	1	5	5
...

라운드 2가 결정적인 단서입니다. 점수가 0이므로 콤보는 다시 0으로 떨어져야 합니다. 하지만 2로 유지됩니다. 라운드 5에서도 마찬가지입니다. 연속 실행 (run)이 초기화되지 않기 때문에, 이후의 모든 라운드가 너무 큰 숫자에 의해 곱해지면서 합계가 61까지 치솟는 것입니다.

그다음 Claude는 원인을 지목했습니다:

0인 경우(zero case)가 두 분기 (branch)를 모두 통과해 버립니다. 코드는 0보다 큰 점수와 0보다 작은 점수는 처리하지만, 단순한 0은 어느 쪽에도 해당하지 않아 콤보가 결코 초기화되지 않습니다.

이 버그는 출력 결과에서는 보이지 않습니다. 이를 잡아낼 수 있는 유일한 방법은 프로그램이 실행되는 동안 콤보가 초기화되지 않는 것을 지켜보는 것뿐이며, 이것이 바로 사람이 디버거(debugger)를 사용하거나 (여러 개의 추적 문구(tracing statements)를 사용하는 것)을 통해 하는 방식이자, 여기서 에이전트(agent)가 수행한 방식입니다. 에이전트는 버그를 읽은 것이 아니라, 지켜본 것입니다. 시작부터 끝까지 약 1분 30분이 걸렸습니다.

그 후 에이전트는 수정 사항을 작성했고, 수정 사항은 제가 원하는 곳에서 열렸습니다. 터미널의 텍스트 형태가 아니라, Visual Studio 자체의 디프 뷰어(diff viewer)에서 '수락(Accept)'과 '거부(Reject)' 버튼과 함께 바로 나타났습니다.

이 기능이 기반하고 있는 일상적인 부분

해당 디프(diff) 기능은 디버깅 작업을 하기 전 몇 주 동안 제가 의존해 왔던 부분이며, 여전히 제가 가장 많이 사용하는 기능입니다. Claude가 제안하는 모든 변경 사항은 이미 신뢰하고 있는 에디터에서 실제 디프(diff) 형태로 열립니다. 내용을 읽고 '수락(Accept)' 또는 '거부(Reject)'를 클릭하기만 하면 됩니다. 터미널로 돌아가서 두 번째 확인을 기다릴 필요가 없습니다.

제가 좋아하는 부분은 '거부(reject)' 기능입니다. 단순히 '아니오'라고 말하는 것이 아니라, 한 문장으로 그 이유를 말할 수 있습니다.

그 메모는 CLI로 바로 전달되며, Claude는 이를 받아들여 무작정 다시 시도하는 대신 사용자의 수정 사항을 반영하여 다시 시도합니다.

또한 빌드(build) 결과도 읽어옵니다. 오류 목록(Error List)의 오류와 경고, C# 및 C++ 정보가 모델에 직접 전달되므로, 사용자가 아무것도 붙여넣지 않아도 무엇이 잘못되었는지 모델이 바로 확인할 수 있습니다. 그리고 세션의 투명성을 유지하기 위한 도킹된 패널(docked panel)이 있습니다. 여기에는 사용자가 수락하거나 거부한 내용, 토큰(tokens) 및 비용(cost), 그리고 에이전트가 디버거를 직접 제어(driving)하는 대신 단순히 조사(inspecting)하는 데 사용한 시간의 비율이 표시됩니다. 에이전트가 디버거를 제어할 수 있게 해주는 스위치도 여기에 있으며, 사용자가 켜기 전까지는 꺼져 있습니다.

이것이 왜 실제적인 작업(real work)이었는가

뻔한 방식으로는 작동하지 않으며, 그것이 이 이야기의 핵심입니다.

Claude Code는 작은 로컬 프로토콜, 즉 락파일(lockfile)과 MCP를 사용하는 localhost WebSocket을 통해 IDE와 통신합니다. 문제는 CLI가 IDE의 도구 중 어떤 것을 모델에게 실제로 보여줄지에 대해 매우 까다롭다는 점입니다. CLI는 진단(diagnostics) 정보만 넘겨주고 나머지는 직접 실행합니다. 따라서 제가 새로운 "디버거 읽기" 도구를 등록하더라도 모델은 해당 도구에 접근하는 것이 허용되지 않을 것입니다.

디버거가 Claude에게 전달되는 데는 다른 두 가지 방법이 있습니다.

첫 번째는 훅(hook)입니다. 중단점(breakpoint)에서 실행이 일시 중지된 상태에서 프롬프트를 보내면 훅이 실행되어 Visual Studio로부터 중단 상태를 읽어온 뒤, 모델이 메시지를 보기 전에 컨텍스트(context)에 삽입합니다. 별도의 도구 호출(tool call) 없이도 Claude는 사용자가 어디에서 멈춰 있는지, 그리고 모든 로컬 변수가 무엇을 담고 있는지 이미 알고 턴(turn)을 시작합니다.

두 번째는 프로젝트를 위해 직접 등록하는 방식인 별도의 MCP 서버입니다. 이러한 서버들은 필터링되지 않으므로, 서버가 노출하는 모든 도구를 모델이 호출할 수 있습니다. 확장 프로그램(extension)은 디버거를 위한 작은 MCP 서버를 실행하고 시작 시 이를 등록합니다. 실제 작업은 Visual Studio 내부에서 이루어지며, 심(shim)은 단지 메시지를 그곳으로 전달하는 역할만 수행합니다.

상태를 읽는 것은 꽤 쉬웠습니다. 디버거를 제어(Driving)하는 부분이 계속해서 오류를 일으키는 부분이었습니다. "Step over (프로시저 단위 실행)"는 즉각적인 답변이 나오는 질문이 아닙니다. 명령을 내린 후, 결과가 의미를 갖기 위해서는 프로그램이 다시 멈출 때까지 기다려야 합니다. 기다리기 위해 UI 스레드(UI thread)를 차단하면 IDE가 얼어버립니다. 해결책은 메인 UI 스레드를 차단하지 않고 스텝(step)을 수행하도록 구현하는 것입니다. 즉, 확장이 디버거의 모드 변경 이벤트(mode-change event)를 수신하고, 요청을 유지하다가 다음 중단점(break)이 걸릴 때 이를 완료하는 방식입니다. 모델 입장에서는 새로운 상태를 반환하는 하나의 깔끔한 호출일 뿐입니다. 그 이면에서는 에디터의 응답성을 유지하기 위한 이벤트 핸드셰이크(event handshake)가 작동합니다.

제어(Driving) 기능 또한 기본적으로는 꺼져 있습니다. 런타임 상태(runtime state)를 읽는 것은 무엇도 망가뜨릴 수 없기에 항상 켜져 있습니다. 계속 실행(Continue), 스텝(step), 중단점(breakpoints), 세션 시작 및 중지: 이 모든 기능은 패널의 체크박스 뒤에 있으며, Visual Studio를 재시작할 때마다 초기화됩니다. 에이전트(agent)가 코드를 실행하도록 허용하는 것은 중대한 결정이므로, 기본값은 꺼짐 상태입니다.

다음 단계

목록에 있는 몇 가지 사항들입니다:

• 테스트 주도 디버깅 (Test driven debugging). 테스트 스위트를 실행하고, 테스트가 실패하면 실패 지점에 중단점을 설정한 뒤, 해당 테스트를 디버깅하기 시작하여 스스로 결함 지점까지 찾아가도록 합니다.
• (진행 중) 예외 발생 시 중단 (Break on thrown). 선택한 예외가 발생한 즉시, 예외가 무시되는 지점이 아니라 예외가 던져진(throw) 지점에서 중단합니다.
• CPU 및 메모리. 실행 중인 프로세스에 .NET 진단 도구(diagnostics tools)를 연결하여, 핫 메서드(hot methods)와 가장 무거운 할당(allocations)을 표면화합니다.

사용해보기

Visual Studio Marketplace에 있으며, 소스 코드는 GitHub에 있습니다. Visual Studio 2026과 Claude Code CLI가 필요합니다.

• Marketplace: https://marketplace.visualstudio.com/items?itemName=firish.bridgev1
• 소스 및 문서: https://github.com/firish/claude_code_vs

Visual Studio에서 작업하며 Claude Code를 그곳에서 사용하고 싶었다면, 직접 사용해 보시고 무엇이 고장 나는지 저에게 알려주세요.