개발자중급·2026.05.12

에러 메시지로 원인·재현 절차·수정안까지

에러 스택·환경 정보를 던지면 원인 후보·재현 절차·수정 코드를 단계별로.

프롬프트 본문

당신은 한국어 시니어 백엔드 개발자입니다.

다음 에러를 분석하세요.
- 에러 메시지/스택:
```
[에러 메시지 또는 스택 트레이스]
```
- 코드 일부 (관련된 부분만):
```
[코드]
```
- 환경: [언어/프레임워크/버전, OS]
- 발생 조건: [언제 발생, 재현 빈도]

출력 형식:
1. **가장 가능성 높은 원인 1~3가지** — 각 한 문단으로 "왜 그렇게 추정하는지" 근거 포함.
2. **재현 절차** — 최소 코드로 재현하는 단계 3~5개.
3. **수정안** — 코드 diff 형식. 변경 이유 한 줄씩 주석.
4. **추가 점검** — 같은 원인으로 다른 곳에서 터질 수 있는 부분 1~2곳.

한국어. 추측이면 "추정"이라고 명시. 모르는 부분은 추가 정보 요청.

ⓘ 대괄호 [ ] 부분을 본인 상황에 맞게 채운 뒤 쓰세요. 그대로 복사하기보다 아래 사용 예시·실패 예시·수정 팁을 먼저 읽으면 결과가 크게 달라집니다.

실전 사용 팁

1.재현 절차가 너무 추상적이면 "Docker 또는 단일 파일로 재현 가능한 최소 예제를 만들어달라"고 명시.
2.스택 트레이스를 통째로 던지지 말고, 직접 의심되는 부분 + 최상위 5줄만 줘도 정확도가 올라간다.

사용 예시 (이렇게 나옵니다)

Node 환경에서 "TypeError: Cannot read properties of undefined (reading 'id')"가 간헐적으로 뜬다고 입력했을 때의 분석 형태입니다.

1. 가장 가능성 높은 원인

(추정) 비동기 응답 도착 전 접근: fetch 결과를 await 없이 바로 .id로 읽는 코드가 보입니다. 응답이 느린 요청에서만 터지는 게 "간헐적"이라는 증상과 맞습니다.
(추정) 빈 배열에서의 [0] 접근: 조회 결과가 0건일 때 result[0]이 undefined가 됩니다. 평소엔 데이터가 있어 안 보이다가 특정 조건에서만 노출됩니다.

2. 재현 절차

해당 조회의 응답을 빈 배열로 강제하는 목 데이터를 준비
그 상태에서 문제 함수를 단독 호출
같은 TypeError가 재현되는지 확인

3. 수정안

옵셔널 체이닝과 기본값으로 방어합니다.

const id = result?.[0]?.id ?? null; // 빈 결과를 null로 흡수
이후 id가 null일 때의 분기를 명시적으로 처리

4. 추가 점검

같은 패턴(배열 첫 요소를 바로 참조)이 다른 핸들러에도 있는지 검색해 보길 권합니다. 한 곳에서 터졌다면 보통 두세 곳이 더 있습니다.

스택 트레이스 전체와 발생 직전 입력값을 주시면 원인을 한두 개로 좁힐 수 있습니다.

이렇게 쓰면 실패해요

잘못된 입력과 그때 나오는 아쉬운 결과, 그리고 이유입니다. 같은 실수를 피하면 한 번에 쓸 만한 답이 나옵니다.

에러 한 줄만 던지면

대괄호 네 칸 중 에러 메시지만 한 줄 채우고 나머지를 비웁니다. 코드 일부는 빈칸, 환경 칸은 비움, 발생 조건도 비움. 예: 에러 메시지/스택에 "500 에러 나요"만 적고 제출.

이런 결과가 나옵니다

원인 후보가 "DB 연결 끊김(추정), 인증 토큰 만료(추정), 미들웨어 예외(추정)..."처럼 일반론 5~6개로 늘어지고, 재현 절차는 "서버를 띄우고 요청을 보낸다" 같은 빈 단계, 수정안은 "에러 핸들링을 추가하세요" 한 줄로 끝납니다. 어느 것도 내 코드와 연결되지 않습니다.

왜 추측만 쌓일까

이 틀은 빈칸을 메우는 구조라, 코드와 발생 조건이 비면 모델이 짚을 단서가 없어 추측만 쌓습니다. 특히 "간헐적/항상" 여부는 원인 후보를 가르는 핵심인데, 이게 비면 후보를 좁히지 못하고 백과사전식 나열로 빠집니다. "500 에러"는 메시지가 아니라 증상이라 스택·로그가 없으면 진단이 시작되지 않습니다.

결과가 이상할 때 — 수정 팁

한 번에 마음에 드는 답이 안 나오면, 아래 한 줄을 덧붙이거나 바꿔서 다시 시켜보세요.

→발생 조건 칸을 비우지 말고 '항상 재현' 또는 '10번 중 2번 정도 간헐적'처럼 빈도를 숫자로 적으세요. 이 한마디가 원인 후보를 절반으로 줄입니다.
→'500 에러' 같은 증상 대신 실제 스택 트레이스 최상위 5줄과 에러 클래스명(예: TypeError, ECONNREFUSED)을 코드 블록에 넣으세요.
→코드 일부 칸에 에러가 난 함수 본문과 그 함수가 호출하는 한 단계 아래까지 붙이세요. 빈칸이면 모델이 가상의 코드를 지어내 진단합니다.
→원인 후보가 4개 이상 나오면 '발생 직전 입력값과 로그를 추가로 줄 테니 후보를 2개 이하로 좁혀달라'고 한 줄 덧붙여 재요청하세요.

이 프롬프트 200% 활용법

역할 고정 + 빈칸 채우기 구조가 진단을 끌어올린다

이 프롬프트가 통하는 첫 이유는 "한국어 시니어 백엔드 개발자" 역할을 맨 앞에 박아둔 것입니다. 추측을 늘어놓는 대신 근거를 따지는 톤으로 답하게 만들어요. 두 번째는 대괄호 변수를 에러 메시지/스택, 코드 일부, 환경, 발생 조건 넷으로 쪼갠 점입니다. 진단에 필요한 정보를 미리 칸으로 만들어 두니, 무엇을 줘야 할지 헷갈리지 않고 빈칸만 메우면 됩니다. 결정타는 출력 형식을 원인 후보 → 재현 절차 → 수정안(diff) → 추가 점검 4단계로 못 박은 것이에요. 덕분에 답이 "이거 고치세요" 한 줄로 끝나지 않고, 왜 그렇게 추정하는지 근거와 다른 곳까지 번지는 위험을 함께 짚어 줍니다.

이런 상황엔 맞지 않아요

에러 메시지도 스택도 없이 "그냥 안 돼요" 수준이면 이 틀은 헛돕니다. 대괄호 칸이 비면 모델은 추정만 쏟아내니까요. 보안에 민감한 운영 로그·키·고객 데이터를 그대로 붙여 넣는 자리로 써서도 안 됩니다. 컴파일 에러처럼 메시지만으로 답이 뻔한 경우엔 이 4단계가 오히려 장황해요. 그리고 이건 진단 보조지 실행 환경이 아닙니다. 수정안 diff는 사람이 직접 돌려보고 검증하세요. 프롬프트 본문도 "추측이면 추정이라 명시하고, 모르면 추가 정보를 요청"하라고 스스로 한계를 그어 둡니다.

대괄호만 바꾸면 다른 상황에도 붙는다

개발자의 코딩·리서치 작업인 만큼 변수 교체로 폭넓게 응용됩니다.

프런트엔드 디버깅: 환경 칸을 "React/브라우저 콘솔"로, 코드 칸에 컴포넌트와 콘솔 경고를 넣으면 렌더링·상태 버그 추적용으로 바뀝니다.
인프라/배포 장애: 에러 칸에 컨테이너 로그, 환경 칸에 "Docker/CI 파이프라인"을 넣으면 빌드·배포 실패 분석으로 전환돼요.
성능 회귀 조사: 발생 조건 칸을 "특정 트래픽·데이터량에서만 느림"으로 바꾸면 원인 후보가 병목 가설로 좁혀집니다.

자주 헛발질하는 지점

가장 흔한 실수는 스택을 통째로 붙여 넣는 것입니다. 팁대로 의심 부분과 최상위 5줄만 줘도 정확도가 올라가요. 두 번째는 발생 조건을 비워 두는 것. "간헐적"인지 "항상"인지가 원인 후보를 가르는 핵심이라, 예시 출력처럼 "간헐적"이라는 한마디가 비동기 가설로 이어집니다. 셋째, 재현 절차가 추상적으로 나오면 그냥 받아들이지 말고 "단일 파일이나 Docker로 재현 가능한 최소 예제"를 다시 요구하세요. 끝으로 diff를 그대로 커밋하지 말고, 4번 "추가 점검"이 가리킨 같은 패턴이 다른 핸들러에도 있는지 직접 검색해 확인하세요.

#디버깅#버그 분석#에러 추적