프롬프트 반복 개선 프레임워크

원칙: "단순하게 시작하기"

경험 많은 사람들이 빠지는 실수는 처음부터 너무 복잡하게 만들거나, 필요할 것 같은 모든 조건을 다 넣는 것이다. [conversation]

올바른 시작 방식은 아래 3가지만 먼저 명시하는 것이다.

1. 1.어떤 일을 하려고 하는가?
2. 2.누가 받아볼 것인가?
3. 3.결과 형식이 무엇인가?

실전 예시 — 팀 회의록 작성 (가장 단순한 버전)

아래 회의 녹음을 회의록으로 정리해줘.
형식: 마크다운
- 의사결정사항
- 액션아이템 (담당자, 마감일)

AI가 결과를 주면 "이게 뭐가 부족한가?"를 구체적으로 파악해야 한다. [conversation]

평가 질문지

실전 예시 — 평가

AI 첫 결과: 의사결정사항 2개, 액션아이템 2개 (담당자·마감일 포함) 평가 결과: - 각 항목이 너무 간략하며, "왜" 이런 결정을 했는지 배경이 없음 - 의사결정사항이 실제 회의보다 적음 - 액션아이템의 예상 규모나 상세 내용이 불명확

결과가 부족한 이유는 보통 프롬프트가 불충분했기 때문이다. [conversation]

문제-원인-해결 매핑

실전 예시 — 개선된 프롬프트

아래 마케팅팀 회의 녹음 (2026.07.22, 30분)을 회의록으로 정리해줘.
참석자: 마케팅 리더 3명, 디자인팀 1명

형식 (마크다운):

## 의사결정사항
각 항목마다:
- [항목명]: [배경] → [결정 내용] → [기대효과]

예시:
- Q3 마케팅 예산 50% 증가 승인: "신규 캠페인이 효과적이라는 데이터가 나와"
  → "현 200M에서 300M으로 확대" → "월 추가 리드 200개 확보 예상"

## 액션아이템
각 항목마다:
- [항목명] / 담당자 / 마감일 / 우선순위(높/중/낮)

[톤] 조직 내부 공유용 (정형적이되 읽기 쉬운 한국어)
[주의] 참석자 의견만 기록 (추측 금지), 미결정사항은 따로 표시

개선된 프롬프트로 다시 AI에게 요청한 뒤, 아래 체크리스트로 검증한다. [conversation]

• 맥락이 충분히 반영되었는가?
• 깊이가 첫 번째보다 나아졌는가?
• 형식이 정확하게 맞았는가?
• 빠진 정보가 있는가?
• 만족할 만한 수준인가?

실전 프롬프팅 가이드에서도 강조하듯, 수정 방향은 문제 유형에 따라 달라진다. [conversation]

시나리오 1: 내용이 부족할 때

프롬프트에 아래 내용을 추가한다.

각 의사결정마다 다음을 포함해줘:
1. 그 결정이 필요했던 배경
2. 가능했던 옵션들 (A안, B안)
3. 최종 선택과 이유
4. 예상 영향

시나리오 2: 형식이 안 맞을 때

원하는 형식의 예시 테이블을 직접 제시한다.

결과를 표 형식으로 바꿔줄 수 있나?

| 항목 | 배경 | 결정 | 담당자 | 마감 |
|------|------|------|--------|------|

시나리오 3: 이미 만족하지만 조금 더 필요할 때

한 가지만 추가 요청한다.

좋아. 여기에 한 가지 더 추가해줄래?
각 액션아이템마다 '우선순위'를 높음 / 중간 / 낮음으로 매겨줘.

팁 1: 한 번에 너무 많이 수정하지 말기

DO/DON'T 가이드와 마찬가지로, 변경은 한 번에 하나씩이 원칙이다. [conversation]

팁 2: 수정 요청도 구체적으로

팁 3: 템플릿화하기

좋은 프롬프트가 완성되면 저장해두고 재사용한다. 다음 번에는 참석자·날짜·주제만 바꿔서 사용하면 된다. [conversation]

템플릿을 저장해두면 다음 첫 시도가 이미 80점 수준으로 시작된다. [conversation]

매번 프롬프트를 수정할 때 사용한다. [conversation]

• 무엇이 부족한가? (내용 / 형식 / 깊이 / 톤 / 길이)
• 그 부족함의 원인이 무엇인가?
• 프롬프트 어느 부분을 수정할 것인가?
• 한 가지만 수정할 것인가, 여러 가지를 동시에?
• 수정 후 AI에게 명확하게 요청했는가?
• 결과가 나아졌는가?
• 이 프롬프트를 저장해야 할까?

반복 개선의 핵심 원칙 5가지 [conversation]:

1. 1.완벽함을 기대하지 말기 — 첫 시도는 출발점일 뿐
2. 2.문제를 구체적으로 파악하기 — "별로야"가 아니라 "왜 별로인지" 찾기
3. 3.원인을 분석하기 — 결과가 아닌 프롬프트에서 원인 찾기
4. 4.한 가지씩만 수정하기 — 변수를 최소화해야 효과를 알 수 있음
5. 5.좋은 프롬프트는 저장해두기 — 자산으로 쌓이는 것이 진짜 실력