참고 URL: Debug chat interactions
이 글에서 정리하는 내용
저는 VS Code의 Agent Debug Log panel과 Chat Debug view를 함께 보면서, Copilot Chat이 어떤 컨텍스트를 읽고 어떤 도구를 호출했는지 추적하는 방법을 정리하겠습니다. 단순히 기능 이름만 나열하지 않고, 왜 응답이 이상해졌는지와 prompt file, custom agent, MCP tool이 실제로 반영됐는지 확인하는 흐름까지 한 번에 묶어 설명하겠습니다. 특히 Agent Debug Log panel을 어떤 순서로 읽어야 덜 헤매는지까지 같이 보겠습니다.
- 왜 Agent Debug Log panel이 필요한가
- Agent Debug Log panel 열기와 구조
- Logs와 Chat Debug view 읽는 법
- 실무에서 자주 막히는 문제 해결
- 정리
- FAQ
왜 Agent Debug Log panel이 필요한가
저는 Copilot Chat을 쓰다가 가장 답답했던 순간이 “왜 이런 답이 나왔는지 모르겠다”는 상황이었습니다. 프롬프트를 분명히 적었는데 코드베이스를 충분히 읽지 못하거나, 연결한 도구를 호출하지 않거나, custom instruction이 반영되지 않은 것처럼 보일 때가 있습니다. 이때 감으로 다시 질문만 반복하면 원인을 좁히기 어렵습니다. 그래서 Agent Debug Log panel은 단순한 부가 기능이 아니라, 제가 보낸 요청이 어떤 흐름으로 처리됐는지 확인하는 디버깅 창으로 이해하는 편이 정확합니다. 이 Agent Debug Log panel은 Preview 상태이며, 채팅 세션 동안 일어난 이벤트를 시간순으로 보여줘서 custom agent나 sub-agent 흐름을 분석할 때 특히 유용합니다.
일반 채팅 화면만으로 부족한 이유
질문 입력
→ 에이전트가 컨텍스트 수집
→ 필요하면 도구 호출
→ 모델 요청 전송
→ 응답 생성
→ 결과 표시제가 채팅창에서 바로 보는 것은 보통 마지막 결과뿐입니다. 하지만 실제 내부 흐름은 훨씬 길고, 중간에 어떤 파일이 로드됐는지, 어떤 도구가 후보에 있었는지, 어떤 요청이 모델로 전달됐는지를 봐야 문제가 풀립니다. Agent Debug Log panel은 이 중간 과정을 시간순으로 보여주고, Chat Debug view는 실제 system prompt, user prompt, context, tool response까지 확인하게 해줍니다. 즉, 전자는 흐름을 추적하는 데 강하고 후자는 요청 원문을 검증하는 데 강하다고 보면 됩니다.
Agent Debug Log panel 열기와 구조
저는 먼저 이 기능을 켜는 것부터 정리하겠습니다. 이 기능은 Preview라 관련 설정을 활성화해야 하고, 현재는 로컬 채팅 세션 중심으로 로그를 확인하는 흐름이 기본입니다. 예전에는 현재 VS Code 세션에서만 로그를 볼 수 있다는 제약이 컸지만, 최근에는 내보내기와 가져오기도 지원되어 이전 세션 로그를 다시 열어 확인할 수 있게 됐습니다. 다만 처음 배울 때는 “지금 보고 있는 로그가 어느 세션의 것인지”를 먼저 의식하는 편이 좋습니다.
설정과 진입 방법
{
"github.copilot.chat.agentDebugLog.enabled": true
}저는 보통 설정에서 기능을 켠 다음 Chat view의 메뉴에서 Agent Debug Log panel을 열거나, Command Palette에서 관련 명령을 실행해 접근합니다. /debug 명령으로 Chat Debug view를 열 수 있고, /troubleshoot 명령으로 현재 세션의 Agent Debug Log panel 이벤트를 바탕으로 AI에게 분석을 요청할 수도 있습니다. 그래서 단순히 패널만 켜 두는 것보다, 로그를 본 뒤 다시 채팅으로 질문을 던지는 흐름까지 같이 익혀 두면 활용 폭이 넓습니다.
| 화면 | 제가 확인하는 핵심 포인트 |
|---|---|
| Logs | 이벤트 순서, tool call, discovery, LLM request, error |
| Summary / Agent Flow Chart | 전체 요약, 토큰 사용량, 하위 에이전트 흐름 |
각 뷰를 나눠서 보는 이유
Logs: 시간순 사건 기록
Summary: 세션 요약과 핵심 지표
Agent Flow Chart: 어느 에이전트가 어떤 순서로 움직였는지 시각화제가 Logs에서 먼저 보는 것은 “어디서 어긋났는가”입니다. 이후 Summary에서는 총 소요 시간, 토큰 사용량, 오류 개수 같은 운영 관점 정보를 빠르게 파악합니다. custom agent를 여러 개 쓰거나 handoff가 들어간다면 Agent Flow Chart가 특히 유용합니다. 어떤 에이전트가 중간에 넘겨받았는지 시각적으로 보여주기 때문에, 단순 텍스트 로그보다 흐름을 훨씬 빨리 읽을 수 있습니다. 또한 Agent Debug Log panel에서는 tool usage와 subagent 결정도 함께 보이므로, 여러 설정이 한 번에 얽힌 세션일수록 이 화면의 가치가 커집니다.
Logs와 Chat Debug view 읽는 법
제가 먼저 보는 순서
1. Logs에서 Discovery / Tool calls / LLM requests 확인
2. Chat Debug view에서 System prompt 확인
3. Context에 필요한 파일이 실제로 들어갔는지 확인
4. Tool responses와 최종 Response를 비교저는 문제가 생기면 바로 Chat Debug view부터 열지 않고, 우선 Agent Debug Log panel의 Logs에서 큰 흐름을 봅니다. 여기서 Discovery 이벤트를 보면 prompt file, instruction file, skill, custom agent가 로드됐는지 감을 잡을 수 있습니다. Tool calls 쪽에서는 도구가 실제로 불렸는지, 후보에만 있었는지, 스킵됐는지를 확인합니다. LLM requests 이벤트는 토큰 사용량이나 요청 횟수를 볼 때 도움이 됩니다. 이처럼 Agent Debug Log panel은 먼저 큰 그림을 보고, Chat Debug view는 그다음 세부 원문을 확인하는 식으로 연결해서 읽는 편이 효율적입니다.
Chat Debug view에서 꼭 봐야 하는 섹션
System prompt
User prompt
Context
Tool responses
Response제가 이 화면에서 가장 먼저 보는 것은 System prompt입니다. 여기에 현재 에이전트의 역할, 사용 가능한 도구, 붙은 규칙이 어떻게 합쳐졌는지가 드러나는 경우가 많기 때문입니다. 다음으로 Context를 보면 workspace 파일이나 #file, #codebase 같은 참조가 실제 요청에 포함됐는지 판단할 수 있습니다. Tool responses는 도구가 성공적으로 결과를 돌려줬는지 확인할 때 중요하고, 마지막 Response는 모델이 그 결과를 어떻게 해석했는지 검토할 때 봅니다. 응답이 지나치게 일반론적으로 보인다면 Context가 비어 있거나 필요한 파일이 빠진 경우를 먼저 의심하는 편이 좋습니다.
실무에서 자주 막히는 문제 해결
저는 이 기능을 배울 때 이론보다 문제 상황과 연결해서 보는 편이 훨씬 이해가 빨랐습니다. 그래서 여기서는 실제로 자주 막히는 경우를 기준으로 어떤 화면을 먼저 봐야 하는지 정리하겠습니다. 핵심은 막연히 “AI가 이상하다”라고 느끼는 단계에서 멈추지 않고, 어느 지점에서 빠졌는지를 Agent Debug Log panel과 Chat Debug view로 좁혀 가는 것입니다.
코드베이스를 못 읽거나 도구를 안 부르는 경우
상황 1. 파일을 못 읽는 것 같다
- Logs의 Discovery 확인
- Chat Debug view의 Context 확인
- 필요하면 #file, #codebase 명시
상황 2. MCP tool이 안 불린다
- Logs의 Tool calls 확인
- Chat Debug view의 System prompt에서 available tools 확인
- 필요하면 #tool-name으로 명시제가 workspace 파일을 못 읽는다고 느낄 때는 Discovery와 Context를 함께 봅니다. 파일이 인덱싱되었는지, 현재 요청 컨텍스트에 들어갔는지를 둘 다 확인해야 하기 때문입니다. MCP tool이 호출되지 않는 경우에는 System prompt에 그 도구가 실제 사용 가능 목록으로 들어가 있는지 먼저 확인합니다. 여기에 없다면 서버 연결이나 설정 문제를 의심해야 하고, 있다면 프롬프트가 도구 호출을 유도하지 못했을 가능성을 봅니다. 최근 문서에서는 rename 같은 정밀 도구가 있어도 에이전트가 grep류 도구를 선호하는 경우가 있다고 설명하므로, 필요하면 #tool-name으로 명시하는 습관도 도움이 됩니다.
prompt file, instructions, custom agent가 적용되지 않는 경우
---
agent: agent
tools:
- search/codebase
- my-mcp-tool
description: review this bug
---
현재 버그 원인을 코드베이스 기준으로 분석해 주세요.저는 prompt file이나 custom agent를 만들었는데 기대한 규칙이 안 먹는다면, 파일 내용부터 고치기 전에 로드 자체가 되었는지 확인합니다. Discovery 이벤트에는 로드 성공, 스킵, 검증 실패 같은 단서가 남을 수 있습니다. monorepo 구조라면 상위 저장소의 customizations를 탐지하는 설정이 꺼져 있을 수도 있고, prompt file의 도구 목록이 현재 agent보다 우선 적용되는지도 같이 봐야 합니다. custom agent, prompt file, instructions, skills는 역할이 조금씩 다르므로, 무엇을 항상 적용할지와 무엇을 수동 실행할지를 구분해서 설계하는 것이 중요합니다. 추가로 Chat view의 Diagnostics를 열면 현재 로드된 custom agents, prompt files, instruction files, skills와 로드 오류를 한 번에 볼 수 있어, Agent Debug Log panel과 함께 쓰면 원인 파악 속도가 훨씬 빨라집니다.
정리
저는 VS Code의 AI 기능을 잘 쓰려면 프롬프트를 잘 쓰는 것만큼 디버깅 화면을 읽는 힘이 중요하다고 봅니다. Agent Debug Log panel은 전체 흐름과 사건 순서를 보는 창이고, Chat Debug view는 실제 요청 원문과 컨텍스트를 검증하는 창입니다. 그래서 응답 품질이 이상할 때는 다시 묻기 전에 Logs에서 흐름을 보고, Chat Debug view에서 System prompt와 Context를 확인하는 순서로 접근하면 훨씬 빠르게 원인을 찾을 수 있습니다. 특히 custom agent, prompt file, MCP tool, instructions를 함께 쓰는 환경이라면 Agent Debug Log panel과 Diagnostics를 함께 보는 습관이 거의 필수에 가깝습니다.
많이 받는 질문
Q. Logs와 Chat Debug view 중 어디부터 보면 되나요?
저는 먼저 Logs를 봅니다. 전체 흐름과 에러 위치를 빠르게 파악한 뒤, 세부 원문 검증이 필요할 때 Chat Debug view로 내려가는 방식이 가장 효율적이었습니다.
Q. custom instruction과 prompt file은 같은 개념인가요?
같지 않습니다. 저는 항상 적용되는 규칙은 instructions로, 특정 작업을 수동 실행하는 흐름은 prompt file로 구분해서 이해합니다. custom agent는 여기에 역할과 도구 제한까지 더하는 개념에 가깝습니다. 여러 instruction이 동시에 있으면 개인, 저장소, 조직 순으로 우선순위가 적용된다는 점도 같이 알아두면 좋습니다.
Q. MCP tool이 연결돼 있는데 안 불리면 바로 설정 오류인가요?
그렇게 단정하긴 어렵습니다. 저는 먼저 System prompt에 도구가 실제 목록으로 들어갔는지 보고, 그다음 Tool calls와 prompt 내용을 같이 확인합니다. 도구가 등록은 되어 있어도 현재 요청이 그 도구를 쓸 만큼 명확하지 않으면 호출되지 않을 수 있습니다.