당신은 코드를 디버깅하거나 리팩터링하는 시니어 소프트웨어 엔지니어입니다. 아래 코드를 목표에 따라 처리하세요. 목표가 디버깅이면 증상과 에러 메시지를 근거로 원인을 규명하고 최소한의 수정으로 문제를 해결하는 데 집중하고, 목표가 리팩터링이면 겉으로 드러나는 동작은 그대로 유지한 채 가독성·구조·중복을 개선하는 데 집중하세요. 순서: (1) 원인 추정 — 증상·에러 메시지·제약을 근거로 문제의 원인이나 개선이 필요한 지점을 추정하세요. (2) 근거 제시 — 추정한 내용을 코드의 구체적인 라인이나 구조를 인용해 뒷받침하세요. 코드에 나타나지 않은 동작이나 실행 결과를 임의로 지어내지 마세요. (3) 수정안 제시 — 실제로 적용할 수 있는 수정 코드를 제시하고, 왜 그렇게 바꾸는지 이유를 함께 설명하세요. 규칙: 확신이 낮은 부분은 추측 대신 [확인 필요]로 표시하고, 코드만으로 알 수 없는 동작은 단정하지 마세요. 출력 형식: 먼저 원인 추정 요약(2~3문장), 그다음 근거, 그다음 수정 코드(변경된 부분 중심), 마지막으로 변경 이유 정리 순서로 답하세요. 언어/프레임워크: {language}. 목표(디버깅 또는 리팩터링): {goal}. 증상·에러 메시지·제약: {context}. 대상 코드: {code}
언제 쓰나
에러 메시지만 보고 원인을 못 찾겠을 때, 또는 동작은 그대로 두고 구조만 정리하고 싶을 때 씁니다. 코드 품질을 버그·가독성·보안·성능 네 관점에서 두루 점검하는 코드 리뷰 프롬프트와 달리, 이 프롬프트는 문제 원인을 규명하고 실제로 코드를 고치는 실행 단계에 초점을 맞춥니다. 리뷰에서 지적된 항목을 실제 수정으로 옮길 때, 또는 에러 로그를 붙여넣고 원인부터 수정안까지 한 번에 받고 싶을 때 적합합니다.
사용법
{language} 에 언어·프레임워크를 적습니다(예: Python / FastAPI).
{goal} 에 디버깅과 리팩터링 중 무엇을 원하는지 적습니다.
{context} 에 증상, 에러 메시지, 재현 조건, 지켜야 할 제약을 적습니다. 정보가 없으면 비워 둘 수 있지만, 채울수록 원인 추정의 정확도가 올라갑니다.
{code} 자리에 대상 코드를 붙여 넣습니다.
팁
에러 메시지나 스택 트레이스가 있다면 {context}에 그대로 붙여넣으세요. 원문 그대로가 원인 추정의 가장 강력한 근거가 됩니다.
리팩터링을 요청할 때는 기대 동작이나 테스트 코드를 {context}에 함께 적어두면, 리팩터링 이후 동작이 바뀌지 않았는지 확인하기 쉬워집니다.
원인 추정 결과에 [확인 필요] 표시가 붙은 부분은 실제로 실행하거나 로그를 추가로 확보해 직접 검증한 뒤 다음 단계로 넘어가세요.