에러 로그를 AI한테 제대로 물어보는 법 중급 디버깅: Claude Code에 던지기 전 잘라낼 것들

AI에게 에러 로그를 잘 물어보는 핵심은 로그 전체를 붙여넣는 것이 아니라, “무엇을 하다 실패했는지·첫 번째 에러가 어디인지·최근 바꾼 파일이 무엇인지”를 같이 주는 것입니다. 중급 디버깅에서는 ChatGPT, Claude Code, Cursor가 답을 맞히는 능력보다 당신이 로그를 압축하는 방식이 결과를 좌우합니다.

에러가 날 때마다 로그 전체를 붙여넣지 말고, debug-note.md 템플릿에 첫 에러와 최근 변경부터 정리해 AI에게 물어보세요.

특히 Next.js, Supabase, Prisma, Docker, GitHub Actions처럼 여러 레이어가 얽힌 프로젝트에서는 마지막 200줄보다 첫 실패 지점과 실행 맥락이 더 중요합니다. 아래 방식대로 정리하면 AI가 “그럴듯한 일반론” 대신 실제 수정 후보를 좁혀줍니다.

AI가 잘 푸는 로그와 못 푸는 로그는 다릅니다

AI 코딩 도구는 스택트레이스의 패턴을 빠르게 읽습니다. 하지만 “왜 내 환경에서만 터지는지”는 로그만으로 모릅니다. 그래서 질문에는 코드보다 먼저 상황 정보가 들어가야 합니다.

제가 실무형 테스트 셋업에서 가장 효과를 본 조합은 이렇습니다. 터미널 로그는 1차로 정리하고, 의심 파일은 Claude Code나 Cursor에 열어둔 상태로 넘깁니다. 긴 원인 분석은 ChatGPT에 맡기고, 실제 파일 수정은 Claude Code 또는 Cursor에서 확인하는 식입니다.

제가 쓰는 5분 로그 압축 셋업

• 1단계: 에러가 난 명령어를 그대로 적습니다. 예: pnpm build, npx prisma migrate dev, docker compose up
• 2단계: 로그에서 첫 번째 Error, Caused by, failed가 나온 블록만 가져옵니다.
• 3단계: 최근 수정한 파일 2~5개를 적습니다. “방금 건드린 부분”은 AI에게 강력한 힌트입니다.
• 4단계: 원하는 답변 형식을 지정합니다. 예: “가능성 높은 원인 3개, 확인 명령어, 최소 수정안 순서로 답해줘.”

여기서 중요한 건 로그를 예쁘게 만드는 게 아닙니다. AI가 추론할 수 있는 경계선을 주는 겁니다. “이 파일 안에서 봐줘”, “배포 환경에서만 난다”, “로컬에서는 통과했다” 같은 문장이 디버깅 시간을 줄입니다.

도구별로 맡기면 좋은 역할

바로 쓰는 중급 디버깅 질문 예시

예를 들어 Next.js 앱을 Vercel에 배포했는데 Prisma 관련 빌드 에러가 났다고 가정해보겠습니다. 실제 결과는 프로젝트 구조와 버전에 따라 달라질 수 있지만, 질문은 아래처럼 구성하면 좋습니다.

상황:
Next.js 14 앱을 Vercel에 배포 중이고, 로컬 pnpm build는 통과했습니다.
DB는 Supabase Postgres, ORM은 Prisma입니다.

실행/발생 위치:
Vercel build 단계에서 실패했습니다.

첫 에러:
Error: PrismaClientInitializationError: Environment variable not found: DATABASE_URL

최근 변경:
- prisma/schema.prisma에서 datasource 설정 수정
- .env.local에 DIRECT_URL 추가
- vercel 프로젝트 환경변수는 아직 확인 중

요청:
가능성 높은 원인 3개를 우선순위로 정리하고,
각 원인을 확인할 명령어나 화면 위치를 알려줘.
코드 수정이 필요하다면 최소 변경안만 제안해줘.

이 정도만 줘도 AI는 “Prisma가 문제입니다”에서 멈추지 않고, Vercel 환경변수 누락, 빌드 타임 접근 여부, DATABASE_URL/DIRECT_URL 분리 같은 실제 확인 지점으로 내려옵니다.

가장 흔한 실수: 로그를 많이 주면 더 잘 맞힐 거라는 착각

긴 로그를 통째로 넣으면 AI가 중간의 경고를 진짜 원인처럼 집어낼 때가 있습니다. 특히 npm peer dependency warning, deprecated notice, TypeScript 부가 경고가 섞이면 초점이 흐려집니다.

또 하나는 토큰, API 키, 사용자 이메일을 그대로 넣는 일입니다. 운영 로그를 ChatGPT나 Claude에 붙여넣기 전에는 sk-..., JWT, 쿠키, 이메일, 결제 관련 값은 반드시 마스킹하세요. 디버깅 속도보다 보안이 먼저입니다.

이 방식이 특히 맞는 사람

혼자 SaaS나 자동화 도구를 만드는 빌더라면 이 방식이 잘 맞습니다. 백엔드, 프론트, 배포, DB를 혼자 오가야 하므로 AI에게 “어디부터 봐야 하는지”를 시키는 효과가 큽니다.

팀 개발자라면 Slack에 로그를 던지기 전에 같은 형식으로 정리해두면 좋습니다. 동료가 봐도 빠르고, AI에게 물어봐도 재현 조건이 살아 있습니다. 반대로 단순 문법 오류나 린트 에러는 이 정도 절차 없이 IDE의 Cursor/VS Code Copilot 수정 제안만으로 충분한 경우가 많습니다.

다음 행동: 로그 질문 파일을 하나 만들어두세요

오늘 바로 할 일은 간단합니다. 프로젝트 루트에 debug-note.md를 만들고, “명령어 / 첫 에러 / 최근 변경 / 내가 원하는 답” 네 칸을 고정해두세요. 에러가 날 때마다 이 파일을 채운 뒤 Claude Code나 ChatGPT에 붙여넣으면 됩니다.

AI 디버깅은 마법이 아니라, 잘 정리된 맥락을 빠르게 검토하는 워크플로입니다. 로그를 줄이고, 상황을 늘리고, 마지막에는 반드시 직접 실행해서 확인하세요.

FAQ

로그는 몇 줄까지 넣는 게 좋나요?

처음에는 첫 에러 전후 30~80줄이면 충분합니다. 그래도 부족하면 AI에게 “추가로 어떤 로그가 필요해?”라고 물어본 뒤 범위를 늘리는 편이 낫습니다.

Claude Code와 ChatGPT 중 무엇을 먼저 쓰면 좋나요?

레포 안 파일까지 함께 봐야 하면 Claude Code나 Cursor가 편합니다. 원인 후보를 넓게 정리하거나 배포/DB/인프라 흐름을 설명받고 싶다면 ChatGPT가 유용합니다.

운영 로그를 AI에 넣어도 괜찮나요?

민감정보를 제거했다면 분석용으로 활용할 수 있습니다. 다만 회사 정책, 고객정보, 보안 규정이 있다면 내부 승인된 도구나 Sentry 같은 관측 도구의 권한 설정을 먼저 확인하세요.

관련 링크

• ai api 비용 비교: 사이드프로젝트 챗봇 만들 때 실제로 갈리는 지점
• ai 자동화 수익화 사례: 작은 리서치 봇을 팔 수 있는 워크플로로 바꿔본 기록
• ai 코드 리뷰 자동화, PR 품질 안 떨어뜨리고 빠르게: GitHub Actions로 돌린 현실 셋업
• 관련 태그 더 보기
• 카테고리 더 보기
• 검색 결과 더 보기
• 참고 링크