정답을 맞히는 게 목적이 아니라, 가설을 세우는 습관을 만드는 게 목적입니다. 커밋하지 않아도 됩니다. 화면에서 바로 채우거나 복사해서 쓰세요.
각 사례마다 네 칸을 채웁니다.
city = weahter
# NameError: name 'weahter' is not defined| 칸 | 내가 쓴 것 |
|---|---|
| 오류 종류 | |
| 실제 단서 (어디를 봤나) | |
| 원인 가설 | |
| 다음 검증 행동 |
{"cod": 401, "message": "Invalid API key"}| 칸 | 내가 쓴 것 |
|---|---|
| 오류 종류 | |
| 실제 단서 (어디를 봤나) | |
| 원인 가설 | |
| 다음 검증 행동 |
! [rejected] main -> main (non-fast-forward)
| 칸 | 내가 쓴 것 |
|---|---|
| 오류 종류 | |
| 실제 단서 (어디를 봤나) | |
| 원인 가설 | |
| 다음 검증 행동 |
세 사례 중 하나를 골라, 비밀정보 없는 질문으로 완성하세요.
① 하려던 것 :
② 실제 결과 · 오류 전문 :
③ 이미 시도한 것 :
④ 현재 가설 · 원하는 도움 :
붙여넣기 전에 API 키·비밀번호·사내 코드가 섞여 있지 않은지 확인합니다. 이 습관 하나가 실무에서 사고를 막습니다.
- 세 사례의 오류 종류를 각각 분류했다
- 단서 / 가설 / 검증 행동을 구분해서 적었다
- 비밀정보 없는 4줄 질문을 한 건 완성했다
| 오류 종류 | 가장 먼저 볼 것 |
|---|---|
| 언어 · 런타임 | 마지막 요약 줄 + 내가 작성한 코드의 파일·줄 번호 |
| HTTP · API | 상태 코드 + 응답 본문 + 인증 파라미터 이름 |
| Git | 로컬·원격 브랜치와 커밋 차이 |
공통 원칙 6단계 ① 오류 전문·재현 절차 확보 → ② 비밀정보 제거 → ③ 정확한 오류 문구 검색 또는 공식 문서 → ④ AI로 설명·가설 생성 → ⑤ 공식 문서와 실제 실행으로 검증 → ⑥ 시도 기록과 함께 질문