내 일에 바로 쓰는 방법
프롬프트 디버깅 체크리스트
AI 답변이 뻔하거나 틀리거나 구조가 없거나 재사용하기 어려운 이유를 진단합니다.
핵심 아이디어
AI 답변이 별로일 때 원인은 대개 구체적입니다. 목표가 없거나, 맥락이 얇거나, 출력 형식이 흐리거나, 예시가 없거나, 제약과 검증 단계가 빠진 경우가 많습니다. 이 체크리스트는 “모델이 별로다”를 재사용 가능한 수리 루프로 바꿉니다.
왜 효과적인가
LLM은 우리가 준 작업 인터페이스에 반응합니다. 프롬프트를 구성요소별로 디버깅하면 실패 지점이 보입니다. 의도, 맥락, 출력 계약, 예시, 제약, 근거, 평가 기준을 따로 고칠 수 있습니다.
답변이 별로야. 더 좋게 해줘.
다시 쓰기 전에 이 프롬프트를 디버깅해줘. 1) 목표 명확성, 2) 빠진 맥락, 3) 출력 형식, 4) 예시/평가 기준, 5) 출처나 검증 필요성, 6) 제약을 점검해. 원인 Top 3와 고친 프롬프트를 줘.
내 일에 맞게 바꾸기
작업 템플릿
목표: [달성하려는 것]
맥락: [배경, 대상, 제약]
사용 패턴: 프롬프트 디버깅 체크리스트
변수: 원래 프롬프트, 별로였던 답변 샘플, 원하는 결과, 빠진 맥락, 출력 형식, 검증 규칙, 재사용 메모
출력: [정확한 출력 형식]
마무리 전: 한계와 개선점 1개를 적기운영 레시피
- 먼저 약한 버전을 적어 어떤 문제를 고치는지 확인한다.
- 지시문을 무작정 길게 만들지 말고 빠진 변수를 추가한다.
- 모델에게 출력 형식을 한 번 명확히 따르게 한다.
- 첫 답변을 아래 체크리스트로 검토한다.
- 개선된 버전을 재사용 패턴으로 저장한다.
복사해서 쓰는 7단계 프롬프트 디버그
답변이 뻔하거나 틀리거나 너무 길거나 재사용하기 어려울 때 붙여 넣어 쓰세요. 약한 프롬프트 아래에 체크리스트를 붙이고, 원인 Top 3와 고친 버전을 요구하면 됩니다.
점검: 이 프롬프트가 만들어야 하는 결과는 무엇이고, 어떤 결정/행동을 돕는가?
수리: 첫 줄을 “내가 [대상/맥락]에서 [목표]를 달성하도록 도와줘”로 다시 쓴다.
점검: 모델이 알아야 하는데 프롬프트에 빠진 배경은 무엇인가?
수리: 대상, 제약, 이전 시도, 데이터/출처 범위, “좋은 결과” 예시를 추가한다.
점검: 정확한 형식, 섹션, 길이, 언어, 톤을 지정했는가?
수리: 제목 구조, 불릿 개수, 표 사용 여부, JSON 형태, 최종 체크리스트 같은 보이는 계약을 준다.
점검: 좋은 예시를 보여줬거나 답변을 어떻게 판단할지 정의했는가?
수리: 최종 답변을 요구하기 전에 좋은 예시 1개, 나쁜 예시 1개, 또는 3점 평가 기준을 넣는다.
점검: 이 작업에 최신 사실, 출처, 계산, 도구 기반 검증이 필요한가?
수리: 가정과 검증된 사실을 분리하게 하고, 사실/최신 정보는 도구로 확인한다.
점검: 답변이 피해야 하거나 보존해야 하거나 바꾸면 안 되는 것은 무엇인가?
수리: 예산, 파일 범위, 금지 주장, 스타일 규칙, 안전 경계, 제외 옵션 같은 하드 제약을 명시한다.
점검: 고친 프롬프트를 다음에도 재사용 가능한 패턴으로 남길 수 있는가?
수리: [대상], [출처], [출력 형식], [품질 기준]처럼 일회성 정보를 변수로 바꾼다.
1. 목표 점검
- Check: 이 프롬프트가 만들어야 하는 결과는 무엇이고, 어떤 결정/행동을 돕는가?
- Repair: 첫 줄을 “내가 [대상/맥락]에서 [목표]를 달성하도록 도와줘”로 다시 쓴다.
2. 맥락 점검
- Check: 모델이 알아야 하는데 프롬프트에 빠진 배경은 무엇인가?
- Repair: 대상, 제약, 이전 시도, 데이터/출처 범위, “좋은 결과” 예시를 추가한다.
3. 출력 형식 점검
- Check: 정확한 형식, 섹션, 길이, 언어, 톤을 지정했는가?
- Repair: 제목 구조, 불릿 개수, 표 사용 여부, JSON 형태, 최종 체크리스트 같은 보이는 계약을 준다.
4. 예시/평가 기준 점검
- Check: 좋은 예시를 보여줬거나 답변을 어떻게 판단할지 정의했는가?
- Repair: 최종 답변을 요구하기 전에 좋은 예시 1개, 나쁜 예시 1개, 또는 3점 평가 기준을 넣는다.
5. 근거/검증 점검
- Check: 이 작업에 최신 사실, 출처, 계산, 도구 기반 검증이 필요한가?
- Repair: 가정과 검증된 사실을 분리하게 하고, 사실/최신 정보는 도구로 확인한다.
6. 제약 점검
- Check: 답변이 피해야 하거나 보존해야 하거나 바꾸면 안 되는 것은 무엇인가?
- Repair: 예산, 파일 범위, 금지 주장, 스타일 규칙, 안전 경계, 제외 옵션 같은 하드 제약을 명시한다.
7. 재사용 점검
- Check: 고친 프롬프트를 다음에도 재사용 가능한 패턴으로 남길 수 있는가?
- Repair: [대상], [출처], [출력 형식], [품질 기준]처럼 일회성 정보를 변수로 바꾼다.품질 체크리스트
- 단순 작업이 아니라 실제 목표를 알려줬는가?
- 답을 요구하기 전에 출력 형식을 정했는가?
- 예시, 제약, 품질 기준을 넣었는가?
- 한계, 불확실성, 실패 케이스를 요구했는가?
- 다음에도 재사용 가능한 패턴으로 남겼는가?
모델별 노트
긴 컨텍스트, 비평, 구조화된 글쓰기에 강합니다. 섹션과 예시를 명확히 주는 편이 좋습니다.
빠른 반복과 일상 템플릿에 강합니다. 출력 형식과 가정을 명확히 적는 편이 좋습니다.
넓은 종합과 Google 계열 리서치에 유용합니다. 출처 요구사항을 명확히 두는 편이 좋습니다.
한계
고친 프롬프트가 없는 사실, 접근 불가능한 출처, 약한 제품 전략, 실제 도구가 필요한 작업까지 해결하지는 못합니다. 이 체크리스트는 지시문을 개선하는 용도이고, 중요한 주장은 별도로 검증해야 합니다.
다음에 볼 것
이 내용을 재사용 워크플로로 바꾸세요.
프롬프트 디버깅 체크리스트와 솔로 빌더 AI 세팅 팩을 언어별 .md 파일로 받을 수 있습니다.