[AI활용] 고급 프롬프트 패턴과 AI 도구 연계

앞 모듈에서 좋은 프롬프트의 4요소(역할·맥락·제약·출력형식)를 배웠습니다. 실무 산출물을 안정적으로 뽑으려면 여기에 한 블록을 더합니다 — 자기검증 루프. 2026년 프롬프트 표준은 작성(drafting)→검토(review)→수정(editing)을 한 프롬프트 안에서 끝내는 것입니다. 정리하면 5요소를 순서대로 쌓습니다.

회의도구는 전사는 잘하지만 액션아이템이 어디로도 이동하지 않는 약점이 있습니다. 이 프롬프트가 그 빈틈을 메웁니다 — 전사록을 고정 구조의 표로 강제하고, 추측을 금지합니다.

먼저 흔한 나쁜 프롬프트(before)입니다.

이 회의 내용 정리해 줘.
"""(전사록)"""

→ 역할·형식·검증이 없어 매번 결과 모양이 다르고, 없는 담당자·기한을 지어냅니다. 이제 5요소를 적용한 좋은 프롬프트(after)입니다.

당신은 10년차 IT 프로젝트 PMO다. 아래 회의 전사록을 다음 고정 구조의
마크다운 표로 정리하라.

[출력 형식]
## 결정사항
| # | 결정 내용 | 근거 | 결정권자 |
## 액션 아이템
| # | 할 일 | 담당자 | 기한 | 상태 |
## 미해결 이슈 / 리스크
| # | 이슈 | 영향 | 후속 |

[규칙]
- 전사록에 명시되지 않은 담당자·기한은 "미정"으로 표기하고 절대 추측하지 마라.
- 발언자 이름이 있으면 담당자에 반영하라.

[전사록]
"""{{transcript}}"""

출력 예시(일부):

## 액션 아이템
| # | 할 일 | 담당자 | 기한 | 상태 |
|---|---|---|---|---|
| 1 | 배치 재처리 스크립트 점검 | 김운영 | 미정 | 진행중 |
| 2 | 고객사 SLA 재협의 안건 정리 | 미정 | 6/27 | 대기 |

→ "미정 표기·추측 금지"가 환각 억제 장치입니다. 담당자가 회의에서 안 정해졌으면 빈칸을 지어내지 않고 "미정"으로 남겨, 사람이 채울 자리를 정확히 알려 줍니다.

긴 RFP와 제안서를 대조하는 일은 긴 문서에 강한 도구(Claude 등)에 맞습니다. 여기서 핵심은 인용 강제 — "실제 문장을 인용하라"가 환각을 막는 가장 강한 패턴입니다.

당신은 공공/대기업 입찰 제안 PM이다. 아래 [RFP 요구사항]과 [우리 제안서]를
대조해 요구사항별 준수 여부 매트릭스를 만들어라.

[출력]
| RFP 항목ID | 요구사항 요약 | 준수(Y/부분/N) | 제안서 근거(페이지/문장 인용) | 갭/리스크 |

[규칙]
1. RFP 항목을 하나도 빠뜨리지 마라. 누락이 의심되면 마지막에
   "확인 필요 항목" 목록을 별도로 출력하라.
2. 근거는 제안서에서 실제 문장을 인용하라. 인용을 못 찾으면 준수=N 또는 '부분'.
3. 추측으로 Y를 매기지 마라.

[RFP 요구사항]
"""..."""
[우리 제안서]
"""..."""

→ 인용을 못 찾으면 Y를 못 매기게 만드는 것이 핵심입니다. AI가 "준수했을 것 같다"는 느낌으로 Y를 찍는 것을 구조적으로 막습니다.

장애 분석은 시간순 정렬(단계적 추론)과 확신도 표기가 핵심입니다.

당신은 SRE 사고 분석가다. 아래 Slack 스레드와 로그에서 장애 타임라인을
복원하라.

[출력]
## 타임라인 (KST)
| 시각 | 이벤트 | 출처(로그줄/메시지) |
## 근본원인 가설 (확신도: 높음/중간/낮음)
## 재발방지 액션 (담당 후보)

[규칙]
- 시각이 불명확한 이벤트는 "시각 불명"으로 두고 순서만 추정하되, 추정임을 표기.
- 근본원인은 가설이며 검증 필요함을 명시하라.

WBS 초안은 Few-shot으로 사내 포맷을 강제하고, 누락 위험 영역을 체크리스트로 박습니다.

당신은 SI 프로젝트 PM이다. 아래 [프로젝트 개요]로 WBS 초안을 작성하라.
형식은 아래 예시를 그대로 따라라.

[예시]
1. 분석
  1.1 요구사항 수집 — 산출물: 요구사항정의서 — 기간: 2w — 선행: 없음
[/예시]

[규칙]
- 각 작업에 산출물·예상기간·선행작업을 채워라.
- 누락 위험이 큰 영역(보안검토, 인수테스트, 이행/안정화)을 빠뜨리지 마라.
[프로젝트 개요] """..."""

→ Few-shot 예시 한 줄이 "우리 회사 WBS 포맷"을 강제하고, "누락 위험 영역" 규칙이 PMO 노하우를 주입합니다.

위 어떤 프롬프트든 마지막에 이 블록 하나를 덧붙이면 발행 전 스스로 한 번 거릅니다.

위 결과를 발행 전 스스로 검토하라:
1) 사실 중 [원문에 근거 없는 것]을 모두 찾아 표시하라.
2) 담당자/기한/숫자가 [추측]인 항목을 표시하라.
3) 위를 반영해 최종본을 다시 출력하되, 불확실 항목은 "[검토 필요]"로 남겨라.

이 모든 패턴을 관통하는 메타 규칙이 환각 방어 4종 세트입니다. 아래 네 가지를 프롬프트 제약에 박아 두면, 어떤 산출물이든 AI가 지어내는 위험이 크게 줄어듭니다.

엔지니어가 서버·DB·캐시를 용도에 맞게 나눠 쓰듯, AI 도구도 작업 성격에 맞춰 나눠 쓰는 것이 자연스럽습니다. "가장 좋은 AI 하나로 다 한다"는 발상은, "가장 좋은 서버 한 대로 모든 워크로드를 돌린다"만큼 비현실적입니다.

아래는 자주 쓰이는 범용 AI 도구의 일반적인 강점입니다. 제품 기능은 빠르게 바뀌므로, 절대적 우열이 아니라 "대체로 이런 작업에 잘 맞는다"는 경향으로 받아들이는 것이 안전합니다.

핵심 두 갈래만 기억하면 됩니다.

• 범용 초안·구조화가 필요한가 → 범용 챗봇(ChatGPT 등)이 빠릅니다.
• 긴 문서를 끝까지 읽고 분석해야 하는가 → 긴 문맥에 강한 도구(Claude 등)가 유리합니다.
• 이미 쓰는 오피스/구글 환경 안에서 보조가 필요한가 → 그 생태계의 AI(Copilot·Gemini)가 자연스럽습니다.
• 사내 문서만을 근거로 답해야 하는가(아무 말이나 지어내면 안 됨) → 올린 문서 기반으로 답하는 도구(NotebookLM 등)가 맞습니다.

범용 챗봇과 별개로, 우리가 이미 쓰는 업무도구 안에도 AI가 들어옵니다. 그리고 도구와 도구 사이를 잇는 자동화는 또 다른 결입니다. 이 둘을 헷갈리면 "AI에 다 맡기면 알아서 굴러간다"는 착각에 빠집니다.

업무도구 내장 AI가 대체로 돕는 방향(제품마다 다르므로 일반화):

• 인시던트·이슈 티켓의 긴 내용 요약 — 길게 쌓인 댓글을 한눈에.
• 들어온 신고의 분류·우선순위 제안 — 사람이 최종 확인.
• 지식 문서(위키) 초안·검색 보조 — 비슷한 과거 사례 찾기.

자동화 도구(Zapier·Make)가 반복 업무를 줄이는 예:

• "새 서비스 요청 티켓이 열리면 담당 채널에 알림을 보낸다."
• "특정 라벨이 붙은 이슈가 완료되면 보고용 시트에 한 줄 추가한다."
• "양식 응답이 들어오면 정해진 폴더에 기록을 남긴다."

두 축 모두 사람의 판단·책임을 대신하지 않습니다. 요약이 정확한지, 자동 분류가 옳은지, 자동화 규칙이 엉뚱하게 반복되지 않는지는 사람이 점검합니다.

한국 SI/SM 현장의 보안 관점을 한 줄 더합니다. Zapier·Make는 완전 관리형 SaaS라 데이터가 외부로 나갑니다. 고객사 폐쇄망·기밀 데이터를 다루는 자동화라면 n8n 셀프호스트(사내 인프라에서 실행, 데이터 외부 유출 없음)가 정석입니다. Zapier/Make는 사내 비민감 업무·빠른 PoC에, n8n은 기밀·복잡 로직에 — 여기서도 "이 데이터를 외부로 보내도 되는가"가 도구 선택의 첫 질문입니다.