에러 를 묻기 전 에 — 질문 보내기 전 다시 보는 10가지

질문 보내기 전 10가지를 다시 봅니다 — 에러 로그 질문 전 체크리스트

지난 글 덜 잃으면서 배우는 사람 에서 좋은 질문 은 5분 더 생각 한 흔적 이 있는 질문 이라 했다. 그럼 그 5분 에 구체적 으로 무엇 을 하나?

에러·로그 를 물을 때 특히 그렇다. “에러 나요” 한 줄 은 상대 를 디버거 로 만든다. 반대 로 잘 정리 된 질문 은 상대 를 리뷰어 로 만든다. 아래 는 질문 을 보내기 전 에 다시 보는 10가지 — 그 5분 의 체크리스트 다.

A. 맥락 을 준다 — 상대 가 재현 할 수 있게

① 제목 에 증상 이 1줄 로 있나? "에러나요" → "POST /payments 5XX, 배포 직후". 제목 만 보고 도 무슨 일 인지 가 잡혀야 한다. 채널 목록 에서 제목 은 유일한 미리보기 다.

② 언제부터 시작 됐는지 적었나? 날짜 · 배포 · 환경 변화. 버그 의 80% 는 여기서 풀린다. “어제 까진 됐는데” 한 줄 이 곧 범인 의 시간대 다. “무엇 이 바뀌었나” 가 디버깅 의 절반.

③ 에러 메시지·로그 를 텍스트 로 붙였나? 화면 캡처 는 검색 이 안 된다. 스택트레이스 를 텍스트 로 붙여야 상대 가 키워드 로 훑고, 나중 사람 이 검색 으로 찾는다. (스크린샷 은 UI 깨짐 처럼 텍스트 로 못 담는 경우 에만.)

④ 내 가 시도 한 3가지 를 적었나? 없으면 — 30분 더 시도 하고 온다. 이건 입장료 다. “재시작·로그레벨 DEBUG·설정 확인 은 해봤다” 한 줄 이, 상대 가 이미 한 걸 또 시키지 않게 한다.

⑤ 내 가설 을 적었나? 틀려도 좋다. “아마 커넥션 풀 고갈 같은데요” 한 줄 이 답하는 사람 을 빠르게 만든다. 가설 이 있으면 상대 는 검증 만 하면 되고, 없으면 처음 부터 다시 짚어야 한다.

⑥ 받고 싶은 도움 이 명확 한가? "같이 봐주세요" (막연) 보다 "이 로그 다음 에 뭘 봐야 할까요?" (구체). 원하는 게 방향 인지 리뷰 인지 결정 인지 를 못 박으면, 답 이 정확 해진다.

⑧ 긴급도 를 적었나? "오늘 안 되면 배포 막힘" vs "다음 주 까지 OK" — 답 의 속도 가 달라진다. 긴급도 를 안 쓰면 상대 가 추측 해야 하고, 대개 틀린다.

⑦ 민감 정보 가 안 찍혔나? DB 비밀번호 · 토큰 · 고객 데이터. 로그·캡처 를 붙이기 전 에 다시 한 번 확인. 한 번 채널 에 올라간 시크릿 은 회수 가 안 된다.

⑨ @here 대신 채널·스레드 가 맞나? 전체 멘션 은 정말 급할 때 만. 보통 은 #backend 스레드 에 올린다. 남 의 집중 을 깨는 비용 을 생각 한다.

⑩ 해결 후 “감사 + 정리” 답글 예정 인가? "덕분에 해결 — 원인 은 X, Y 로 고침" 한 줄. 도와준 사람 에 대한 예의 이자, 다음 사람 을 위한 검색 결과 한 줄 이다. 스레드 를 지식 으로 남기는 마지막 단추.

체크리스트 를 다 외울 필요 는 없다. 관통 하는 원칙 은 하나다:

“상대 가 내 문제 를 대신 풀게 하지 말고, 내 가정 을 같이 검증 하게 하라.”

이 10가지 는 사람 에게 묻든 AI 에게 묻든 똑같이 작동 한다. 좋은 질문 은 상대 를 아끼는 설계 이고, 그 설계 가 결국 내 답 을 가장 빨리 데려온다. 묻기 전 의 5분 — 그 5분 이 상대 의 30분 을 산다.