VS Code Copilot 디버깅: Agent Debug Log와 Chat Debug

먼저 문제 범위를 나누기

이 절의 pnpm dev·lint는 해당 script가 있는 기존 앱을 진단할 때의 예입니다. 아래 note.txt 독립 실습에서는 실행할 앱 코드가 없으므로 이 두 명령을 사용하지 않습니다.

예를 들어 “수정이 안 된다”는 증상은 다음처럼 나뉠 수 있습니다.

코드 자체가 빌드되지 않음
파일 저장 권한 문제
VS Code workspace가 다른 폴더를 가리킴
에이전트가 필요한 파일을 context에 넣지 못함
instruction 파일을 읽지 않음
tool call 실패
MCP 서버 연결 실패
모델 요청 자체 실패

그래서 먼저 에이전트 없이 동일 코드를 실행해 봅니다.

pnpm dev
pnpm lint

코드 자체가 정상이라면 그다음 에이전트 경로를 확인합니다.

Agent Debug Logs 열기

VS Code 공식 문서에서는 Chat view의 메뉴에서 Agent Debug Logs를 열거나 Command Palette 명령으로 디버그 패널을 열 수 있다고 안내합니다.

예시 흐름:

Chat view
→ ... 메뉴
→ Show Agent Debug Logs

또는 Command Palette에서 Developer: Open Agent Debug Panel을 실행합니다. Chat Debug는 Chat view의 메뉴에서 Show Chat Debug View로 엽니다.

UI 이름은 버전에 따라 바뀔 수 있으므로 현재 공식 문서를 기준으로 확인합니다.

Logs에서 무엇을 보는가

로그에는 세션의 이벤트가 시간 순서로 기록됩니다.

다음 항목을 우선 봅니다.

instruction 로딩
context 추가
model request
tool call
tool result
error
subagent 또는 작업 분기

“에이전트가 파일을 무시했다”면 실제로 해당 파일이 context에 포함됐는지 확인해야 합니다.

Chat Debug에서 Context 확인

Chat Debug의 Context 영역은 특정 요청에 어떤 파일이나 정보가 들어갔는지 확인하는 데 도움이 됩니다.

예를 들어 에이전트가 src/config/env.js를 참고해야 했는데 context에 없다면 다음을 확인합니다.

올바른 workspace를 열었는가
파일이 실제 workspace 안에 있는가
indexing이 가능한 상태인가
instruction에서 파일 경로를 잘못 지정하지 않았는가

모델의 답변만 보고 추측하는 것보다 실제 context를 확인하는 편이 빠릅니다.

tool call 확인

에이전트가 파일 검색, 터미널, MCP 같은 도구를 사용했다면 어떤 입력으로 호출했는지 확인합니다.

도구 이름
입력 값
호출 순서
결과
오류

잘못된 경로를 반복해서 조회한다면 모델 문제보다 앞 단계의 instruction이나 workspace 기준이 틀렸을 수 있습니다.

MCP 문제가 의심될 때

MCP 도구가 목록에 보이지 않거나 호출이 실패하면 다음을 분리해 확인합니다.

MCP 서버가 등록되어 있는가
서버가 실행 가능한가
권한 승인이 필요한가
도구 discovery가 성공했는가
호출 파라미터가 유효한가
서버 로그에 오류가 있는가

“AI가 MCP를 못 쓴다”와 “MCP 서버가 응답하지 않는다”는 다른 문제입니다.

재현 전에 logging이 필요한 경우

현재 VS Code 문서의 일부 agent debug 기능은 문제가 발생하기 전에 logging 관련 설정을 켜야 자세한 정보를 얻을 수 있습니다.

문제가 발생한 뒤에 켜도 과거 세션의 모든 정보가 소급 기록되는 것은 아닐 수 있습니다.

따라서 반복 재현이 가능한 문제라면 다음처럼 진행합니다.

logging 준비
→ VS Code reload
→ 같은 요청 재현
→ 해당 session 선택
→ logs/context/tool call 확인

정확한 설정 이름은 현재 버전 공식 문서를 기준으로 확인합니다.

로그에는 민감 정보가 들어갈 수 있다

Agent Debug Logs나 Chat Debug에는 다음 정보가 포함될 수 있습니다.

프롬프트
소스 코드
로컬 파일 경로
tool input/output
환경 정보
요청 내용

공식 문서도 로그를 외부에 공유하기 전에 credentials나 secret이 없는지 확인하라고 경고합니다.

블로그 예제에는 실제 토큰, 개인 경로, 회사 코드, 비공개 저장소 이름을 사용하지 않습니다.

자주 발생하는 실수

로그를 보지 않고 프롬프트만 계속 바꿉니다

같은 실패가 반복되면 context와 tool call을 확인합니다.

코드 오류를 에이전트 오류라고 판단합니다

먼저 pnpm dev와 pnpm lint로 프로젝트 자체 상태를 확인합니다.

로그 전체를 그대로 공유합니다

민감 정보가 포함될 수 있으므로 필요한 이벤트만 비식별화합니다.

UI 이름을 오래된 문서 기준으로 고정합니다

VS Code agent 기능은 빠르게 바뀌므로 현재 공식 문서를 확인합니다.

학습 완료 체크리스트

• 코드 문제와 에이전트 문제를 구분할 수 있습니다.
• Agent Debug Logs를 열 수 있습니다.
• Chat Debug에서 context를 확인할 수 있습니다.
• tool call 입력과 결과를 확인할 수 있습니다.
• MCP 연결 실패를 별도 문제로 분리할 수 있습니다.
• 재현 전에 logging이 필요한 경우를 이해했습니다.
• 로그 외부 공유 전 민감 정보를 제거합니다.

독립 실습: 파일 하나로 컨텍스트 확인

새 연습 폴더를 VS Code로 열고 note.txt에 다음 공개 문자열만 저장합니다. Chat에서 이 파일을 명시적으로 첨부하고 “note.txt의 label 값을 읽고 사용한 파일을 알려 주세요”라고 요청합니다. 먼저 아래 설명대로 logging을 준비하고 요청 시각을 기록합니다.

label=Context Practice

기대 결과: 응답에 Context Practice가 나타나고 해당 요청의 Context 또는 파일 읽기 도구 결과에서 note.txt가 확인됩니다. 사용한 도구가 없으면 첨부 컨텍스트로 전달됐는지 확인합니다. 이 실습에는 pnpm script나 MCP 연결이 필요하지 않습니다. 계정·버전에서 로그 기능이 보이지 않으면 공식 문서와 설치 버전을 대조하고 미확인으로 기록합니다.

변형 과제: 존재하지 않는 파일 이름으로 같은 요청을 바꾼 경우 파일 없음 tool 결과와 정상 파일 읽기 결과를 구분해 기록합니다. 모델의 답변만으로 파일을 읽었다고 단정하지 않습니다.

에이전트에게
"src/config/env.js 기준으로 환경 변수 오류를 확인해줘"
라고 요청했는데 일반적인 답변만 반복함

1. src/config/env.js 실제 존재 확인
2. 올바른 TaskFlow workspace인지 확인
3. Chat Debug Context에 파일 포함 여부 확인
4. instruction 로딩 이벤트 확인
5. 파일 읽기 tool call 여부 확인
6. tool error 여부 확인
7. 동일 요청 재현

dev-env-step-09-storybook-vite-fix

프로젝트 자체 검증
→ workspace 확인
→ Context 확인
→ instruction 확인
→ tool call 확인
→ MCP 확인
→ 재현

pnpm dev
pnpm lint

dev-env-step-10-copilot-debug

node_modules/
dist/
storybook-static/
.env.local
.env.*.local

VITE_API_URL=https://api.example.invalid
VITE_APP_NAME=TaskFlow

import js from '@eslint/js';
import { defineConfig } from 'eslint/config';
import globals from 'globals';

export default defineConfig([
  { ignores: ['dist/**'] },
  js.configs.recommended,
  {
    files: ['src/**/*.js'],
    languageOptions: { globals: globals.browser },
    rules: { 'no-console': 'warn' },
  },
]);

<!doctype html>
<html lang="ko">
<head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><title>TaskFlow 개발환경</title></head>
<body><main id="app"></main><script type="module" src="/src/main.js"></script></body>
</html>

{
  "name": "@taskflow/web",
  "private": true,
  "type": "module",
  "scripts": {
    "dev": "vite --host 127.0.0.1",
    "build": "vite build",
    "lint": "eslint ."
  },
  "devDependencies": {
    "vite": "8.3.0",
    "eslint": "10.11.0",
    "@eslint/js": "10.0.1",
    "globals": "17.12.0"
  }
}

const apiUrl = import.meta.env.VITE_API_URL;
const appName = import.meta.env.VITE_APP_NAME;

if (!apiUrl) {
  throw new Error('VITE_API_URL 환경 변수가 필요합니다.');
}

export const env = {
  apiUrl,
  appName: appName || 'TaskFlow',
};

import './style.css';
import { env } from './config/env.js';

const app = document.querySelector('#app');
const title = document.createElement('h1');
title.textContent = env.appName;
const status = document.createElement('p');
status.textContent = '개발환경 스타터가 실행 중입니다.';
const api = document.createElement('p');
api.id = 'api-url';
api.textContent = `API URL: ${env.apiUrl}`;
app.append(title, status, api);

body { margin: 0; color: #202020; background: #f6f6f6; font: 16px/1.6 system-ui, sans-serif; }
main { max-width: 720px; margin: 64px auto; padding: 24px; }
h1 { font-size: 30px; font-weight: 500; }
p { overflow-wrap: anywhere; }

# TaskFlow 개발환경

이 스타터는 개발환경 진단을 위한 최소 Vite/vanilla JavaScript 앱입니다. 할 일 관리 기능이나 API 서버는 포함하지 않습니다.

Node.js 24.19.0, pnpm 11.19.0으로 검증했습니다. 루트는 pnpm만 사용하며 apps/*만 workspace입니다. labs의 npm/Yarn/pnpm 실습은 독립 프로젝트입니다.

## 2회차

메인 앱은 pnpm을 유지합니다. labs/yarn-modern은 독립 Yarn 실습입니다.

## 3회차

apps/web/.env.example을 apps/web/.env.local로 복사합니다. .invalid 주소는 표시만 하며 실제 API 호출은 하지 않습니다. 공개 샘플값만 제공하고 로컬 파일은 ZIP에서 제외합니다.

## 4회차

Vite 루트는 apps/web입니다. env.js가 필수 VITE_API_URL을 검사하고 화면에 공개 URL을 표시합니다.

## 5회차

ESLint 설정과 의존성은 apps/web에 있습니다. 루트 pnpm lint가 앱의 eslint .을 호출합니다.

## 6회차

npm ERESOLVE 실습은 labs/npm-eresolve에서 실행합니다. 최종본은 react와 react-dom 19.3.0 호환 조합입니다.

## 7회차

설치 오류는 경로 → Node/pnpm 버전 → workspace → package.json → lockfile 순으로 확인합니다. 새 폴더에서 pnpm install --frozen-lockfile로 재현합니다.

## 8회차

Tailwind lab은 독립 pnpm 프로젝트입니다. PostCSS 빌드와 VS Code 언어 모드/확장 상태를 구분합니다. VS Code GUI 경고는 이번 자동 검증 범위에 포함하지 않았습니다.

## 9회차

Storybook lab은 HTML/Vite 기반 최소 UI입니다. 잘못된 import 경로를 진단합니다. Linux 대소문자/CI 자원 문제는 이 Windows 실행으로 검증하지 않았습니다.

## 10회차

VS Code Copilot Agent Debug Logs와 Chat Debug는 선택 기능입니다. 사용자 계정, 모델, 확장 상태가 필요한 GUI 단계는 직접 검증하지 않았습니다.

{
  "name": "taskflow",
  "private": true,
  "packageManager": "pnpm@11.19.0",
  "engines": {
    "node": ">=24"
  },
  "scripts": {
    "dev": "pnpm --filter @taskflow/web dev",
    "build": "pnpm --filter @taskflow/web build",
    "lint": "pnpm --filter @taskflow/web lint"
  }
}

packages:
  - "apps/*"

# TaskFlow 개발환경 10 완료 체크포인트

Node.js 24.19.0 / pnpm 11.19.0 검증 기준입니다. pnpm을 별도로 설치한 환경에서 실행하세요. ZIP에는 node_modules, dist, 로컬 환경 변수, 실제 비밀값이 없습니다.

1. 이 폴더에서 `pnpm install --frozen-lockfile`
2. PowerShell: `Copy-Item apps/web/.env.example apps/web/.env.local` 또는 macOS/Linux: `cp apps/web/.env.example apps/web/.env.local`
3. `pnpm dev` 후 http://127.0.0.1:5173 확인
4. `pnpm build`
5. `pnpm lint`

apps/web가 Vite 루트입니다. 환경 변수도 이 폴더에 둡니다. 표시용 API 주소에 실제 요청을 보내지 않습니다. labs는 메인 workspace에서 제외되어 각 폴더에서 별도 설치합니다.

원문 단계별 전체 파일과 실행 검증 범위는 docs/development-environment.md를 확인하세요.

nodeLinker: node-modules

{
  "name": "taskflow-yarn-lab",
  "private": true,
  "type": "module",
  "packageManager": "yarn@4.18.0",
  "scripts": {
    "dev": "node src/main.js",
    "lint": "node --check src/main.js"
  }
}

console.log('TaskFlow Yarn 독립 실습');

{
  "name": "taskflow-npm-eresolve",
  "private": true,
  "type": "module",
  "packageManager": "npm@11.16.0",
  "scripts": {
    "test": "node verify.mjs"
  },
  "dependencies": {
    "react": "19.3.0",
    "react-dom": "19.3.0"
  }
}

# npm ERESOLVE 실습

이 폴더에서만 npm을 사용합니다.

오류 재현: `npm install react@18.3.1 react-dom@19.3.0 --save-exact`

복구: `npm install react@19.3.0 react-dom@19.3.0 --save-exact`

검증: `npm ls react react-dom`, `npm test`

react-dom 19.3.0의 peerDependencies는 react ^19.3.0입니다. 최종 package.json은 복구된 상태입니다.

import { createElement } from 'react';
import { renderToString } from 'react-dom/server';
import assert from 'node:assert/strict';
const html = renderToString(createElement('p', null, 'TaskFlow'));
assert.equal(html, '<p>TaskFlow</p>');
console.log('React 서버 렌더링 통과');

{
  "recommendations": [
    "bradlc.vscode-tailwindcss"
  ]
}

{
  "files.associations": {
    "*.css": "tailwindcss"
  }
}

<!doctype html>
<html lang="ko"><head><meta charset="UTF-8"><title>Tailwind lab</title><link rel="stylesheet" href="/src/style.css"></head><body><h1 class="text-brand text-2xl">TaskFlow Tailwind</h1></body></html>

{
  "name": "taskflow-tailwind-lab",
  "private": true,
  "type": "module",
  "packageManager": "pnpm@11.19.0",
  "scripts": {
    "dev": "vite --host 127.0.0.1",
    "build": "vite build"
  },
  "devDependencies": {
    "vite": "8.3.0",
    "tailwindcss": "4.3.3",
    "@tailwindcss/postcss": "4.3.3",
    "postcss": "8.5.28"
  }
}

packages:
  - "."

export default {
  plugins: { '@tailwindcss/postcss': {} },
};

# Tailwind lab

이 폴더에서 `pnpm install --frozen-lockfile`, `pnpm dev`, `pnpm build`를 실행합니다.

빌드 오류 재현은 postcss.config.js의 plugin을 tailwindcss로 바꿔 확인하고, @tailwindcss/postcss로 복구합니다. VS Code에는 Tailwind CSS IntelliSense를 설치하고 이 폴더를 열어 언어 모드를 확인합니다. 전역 CSS 검사는 끄지 않습니다.

@import "tailwindcss";

@theme {
  --color-brand: #111111;
}

export default {
  stories: ['../src/**/*.stories.js'],
  framework: '@storybook/html-vite',
};

{
  "name": "taskflow-storybook-lab",
  "private": true,
  "type": "module",
  "packageManager": "pnpm@11.19.0",
  "scripts": {
    "dev": "storybook dev -p 6006 --host 127.0.0.1 --no-open",
    "storybook": "storybook dev -p 6006 --host 127.0.0.1 --no-open",
    "build": "storybook build"
  },
  "devDependencies": {
    "vite": "8.3.0",
    "storybook": "10.6.0",
    "@storybook/html-vite": "10.6.0"
  }
}

packages:
  - "."
allowBuilds:
  esbuild@0.28.2: true

# Storybook lab

이 폴더에서 `pnpm install --frozen-lockfile`, `pnpm dev`, `pnpm build`를 실행합니다.

TaskCard.stories.js의 import를 ./missing/TaskCard.js로 변경하면 변환 오류를 재현할 수 있습니다. 개발 서버와 Network의 첫 실패 요청을 확인하고 ./components/TaskCard.js로 복구합니다. 이 실습은 HTML/JavaScript이며 JSX/React parser를 추가하지 않습니다.

export default function TaskCard({ title = '개발환경 확인' } = {}) {
  const article = document.createElement('article');
  const heading = document.createElement('h2');
  heading.textContent = title;
  article.append(heading);
  return article;
}

import TaskCard from './components/TaskCard.js';

export default { title: 'TaskFlow/TaskCard', render: (args) => TaskCard(args) };
export const Default = { args: { title: '개발환경 확인' } };

다음 학습

마지막 글에서는 VS Code 1.113에서 추가·변경된 agent 기능을 사례로 살펴보면서, 개발환경 글에서 “버전성 기능”을 어떻게 검증해야 하는지 정리합니다.

다음 글: VS Code 1.113 업데이트: MCP와 Thinking Effort 변화

공식 문서

• Debugging agent work: https://code.visualstudio.com/learn/foundations/debugging-and-whats-happening-behind-the-scenes
• Debug chat interactions: https://code.visualstudio.com/docs/agents/agent-troubleshooting/chat-debug-view