프롬프트 엔지니어링

언제 쓰나

에러 메시지만 보고 원인을 못 찾겠을 때, 또는 동작은 그대로 두고 구조만 정리하고 싶을 때 씁니다. 코드 품질을 버그·가독성·보안·성능 네 관점에서 두루 점검하는 코드 리뷰 프롬프트와 달리, 이 프롬프트는 문제 원인을 규명하고 실제로 코드를 고치는 실행 단계에 초점을 맞춥니다. 리뷰에서 지적된 항목을 실제 수정으로 옮길 때, 또는 에러 로그를 붙여넣고 원인부터 수정안까지 한 번에 받고 싶을 때 적합합니다.

사용법

1. {language} 에 언어·프레임워크를 적습니다(예: Python / FastAPI).
2. {goal} 에 디버깅과 리팩터링 중 무엇을 원하는지 적습니다.
3. {context} 에 증상, 에러 메시지, 재현 조건, 지켜야 할 제약을 적습니다. 정보가 없으면 비워 둘 수 있지만, 채울수록 원인 추정의 정확도가 올라갑니다.
4. {code} 자리에 대상 코드를 붙여 넣습니다.

사용 예시

입력 — 변수 4개를 채운 실제 입력입니다.

언어/프레임워크: Python / FastAPI
목표(디버깅 또는 리팩터링): 디버깅
증상·에러 메시지·제약: 사용자 100명 이상이 동시에 접속하면 간헐적으로 500이 납니다.
로그에는 `sqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow 10 reached`.
평소에는 정상이고, 재현은 부하 테스트에서만 됩니다. DB 스키마는 변경할 수 없습니다.
대상 코드: (get_user_orders 핸들러와 세션 생성부 30줄)

출력 (요약) — 원인 추정 → 근거 → 수정 코드 → 변경 이유 순으로 돌아옵니다.

원인 추정 (2~3문장)
커넥션 풀 고갈로 보입니다. 요청마다 세션을 열지만 예외 경로에서 반환되지 않아,
동시 요청이 풀 상한(5+10)을 넘는 시점에 대기 타임아웃이 발생합니다.

근거
- 24행: `session = SessionLocal()` 이후 `close()`가 try/finally 밖에 있습니다.
- 31행: 조회 실패 시 early return — 이 경로에서 세션이 반환되지 않습니다.
- 에러 메시지의 "QueuePool limit ... reached"는 풀 반환 누락의 전형적 신호입니다.
- [확인 필요] 미들웨어에서 별도로 세션을 여는지는 제공된 코드만으로 알 수 없습니다.

수정 코드 (변경된 부분 중심)
  # before: session = SessionLocal() ... session.close()
  # after:  with SessionLocal() as session:
  #             ...

변경 이유
컨텍스트 매니저로 감싸면 예외·early return 어느 경로로 빠져나가도 세션이 반환됩니다.
풀 크기를 늘리는 것은 누수 속도만 늦추므로 근본 해결이 아닙니다.

[확인 필요] 표시가 붙은 항목은 그대로 믿지 말고, 실제 코드나 로그로 직접 확인한 뒤 다음 단계로 넘어가세요.

팁

• 에러 메시지나 스택 트레이스가 있다면 {context}에 그대로 붙여넣으세요. 원문 그대로가 원인 추정의 가장 강력한 근거가 됩니다.
• 리팩터링을 요청할 때는 기대 동작이나 테스트 코드를 {context}에 함께 적어두면, 리팩터링 이후 동작이 바뀌지 않았는지 확인하기 쉬워집니다.
• 원인 추정 결과에 [확인 필요] 표시가 붙은 부분은 실제로 실행하거나 로그를 추가로 확보해 직접 검증한 뒤 다음 단계로 넘어가세요.
• 프롬프트를 과제별로 어떻게 응용하는지 더 보고 싶다면 프롬프트 엔지니어링 실전 예제 10가지 글을, 관련 프롬프트를 모아보고 싶다면 프롬프트 엔지니어링 토픽 페이지를 참고하세요.

사용법

목표 하나를 에이전트가 실행할 수 있는 단계별 워크플로우로 쪼갤 때 씁니다. 단계를 나열하는 데서 그치지 않고, 단계마다 검증 기준과 실패 시 대응까지 함께 뽑아내도록 설계했습니다.

1. {goal} 자리에 달성하려는 목표를 구체적으로 적습니다. (예: "매주 발행되는 경쟁사 블로그 글을 요약해 슬랙으로 보고한다")
2. 결과로 나온 단계 목록에서 검증 기준이 애매한 단계가 있으면, 목표 자체를 더 좁혀 다시 실행합니다.
3. 목표가 넓을수록 검증 기준을 먼저 고정한 뒤 단계 수를 줄여서 시작하는 편이 안전합니다. 처음부터 모든 단계를 자동화하지 말고, 검증에 반복적으로 실패하는 단계는 사람이 확인하는 단계로 남겨두세요.

사용 예시

입력 — {goal} 하나만 채운 실제 입력입니다.

다음 목표를 AI 에이전트 워크플로우로 분해해 주세요.
목표: 매주 월요일 아침, 지난주에 올라온 경쟁사 블로그 글을 수집해 요약하고 팀 슬랙 채널에 보고한다.

각 단계마다 다음을 명시하세요. (1) 이 단계에서 하려는 일, (2) 필요한 도구(있다면),
(3) 성공 여부를 판단할 검증 기준, (4) 검증에 실패했을 때의 대응(재시도, 계획 수정,
사람에게 넘기기 중 선택). 단계 수는 최소한으로 유지하고, 검증 기준이 모호한 단계는
만들지 마세요. 출력 형식: 표 또는 번호 목록으로 단계 / 도구 / 검증 기준 / 실패 시 대응을
정리하세요.

출력 (요약) — 표 형태로 단계별 도구와 검증 기준이 돌아옵니다.

마지막 단계처럼 재시도가 부작용을 만드는 지점은 자동 재시도 대신 사람 확인으로 빠지는 것이 정상적인 결과입니다.