업무 생산성 프롬프트

언제 쓰나

회의를 잡긴 했는데 아젠다가 "○○ 논의" 한 줄뿐일 때, 또는 매번 시간만 쓰고 결정된 게 없이 끝날 때 씁니다. 결정 안건을 앞에 두고 공유 안건을 뒤로 미루는 배치만으로도 회의의 결론율이 달라집니다.

사용법

1. {purpose} 에 이 회의로 무엇을 하려는지 적습니다. (예: 다음 분기 채용 인원 확정, 장애 재발 방지 대책 정하기)
2. {participants} 에 참석자를 역할과 함께 적습니다. (예: 팀장 1, 백엔드 2, 디자이너 1, PM 1) 역할이 있어야 담당 배정과 "빠져도 되는 사람" 판단이 나옵니다.
3. {duration} 에 회의 시간을 적습니다. (예: 30분)
4. 나온 아젠다와 4단계 사전 준비를 회의 초대장에 그대로 붙여 미리 보내세요. 이 단계를 건너뛰면 시간 배분이 무너집니다.

사용 예시

입력

회의 목적: 지난주 결제 장애의 재발 방지 대책을 정하고 담당을 배정하기
참석자: 개발팀장 1, 백엔드 2, SRE 1, CS 매니저 1, PM 1
시간: 45분

출력 (요약)

회의 유형: 결정 회의

성공 조건
  "재발 방지 조치 3건 이하가 담당자·기한과 함께 확정되어 있다."

| 안건 | 유형 | 시간 | 담당 | 내려야 할 결정 |
|---|---|---|---|---|
| 타임라인 확인 | 공유 | 5분 | SRE | (없음 — 사전 문서로 대체 가능) |
| 근본 원인 합의 | 논의 | 10분 | 백엔드 | 원인을 무엇으로 확정할지 |
| 대책 후보 검토 | 결정 | 15분 | 개발팀장 | 어떤 조치를 채택할지 |
| 담당·기한 배정 | 결정 | 10분 | PM | 누가 언제까지 |
| 고객 공지 여부 | 결정 | 5분 | CS 매니저 | 공지할지, 문안은 누가 |

사전 준비
  SRE — 장애 타임라인 문서를 회의 전날까지 공유 (회의에서 읽지 않습니다)
  백엔드 — 원인 가설 2개를 근거와 함께 각 3줄
  CS — 접수된 고객 문의 건수

참석자 검토
  디자이너는 이번 안건에 결정 권한이 없습니다. 결과 문서 공유로 충분합니다.

마무리 (5분)
| 결정 | 담당 | 기한 |
|---|---|---|
결론이 안 나면: "다음 단계는 무엇이고, 누가, 언제까지"만 정하고 종료합니다.

팁

• 1단계에서 "문서로 대체 가능"이라는 답이 나오면 그 판단을 존중하세요. 회의를 없애는 것이 가장 좋은 아젠다입니다.
• 정기 회의라면 지난 회의록을 함께 붙이고 "지난번 미결 항목을 맨 앞에"라고 요청하세요. 같은 안건이 매주 반복되는 것을 막습니다.
• 회의가 끝난 뒤 5단계 표를 채워 그대로 공유하면 회의록을 따로 쓸 필요가 없습니다.

언제 쓰나

슬라이드는 다 만들었는데 정작 뭐라고 말할지 정리가 안 될 때, 또는 리허설을 해 보니 시간이 두 배로 나올 때 씁니다. 슬라이드 텍스트는 읽으라고 만든 게 아니라서 그대로 읽으면 어색합니다. 이 프롬프트는 자료를 "입으로 말하는 문장"으로 바꾸고 시간까지 맞춥니다.

사용법

1. {audience} 에 듣는 사람을 적습니다. (예: 개발 배경이 없는 임원진, 같은 팀 엔지니어, 학회 참석자) 용어 수위와 도입부가 여기에 맞춰집니다.
2. {duration} 에 발표 시간을 적습니다. 질의응답 시간이 별도라면 그것도 함께 적으세요. (예: 10분 발표 + 5분 질의)
3. {content} 에 슬라이드 제목과 각 장의 핵심 내용을 붙여 넣습니다. 발표 자료 아웃라인이면 충분합니다.
4. 나온 스크립트를 소리 내어 읽으며 시간을 재세요. 초과하면 5단계 우선순위대로 잘라냅니다.

사용 예시

입력

청중: 개발 배경이 없는 임원진 6명
발표 시간: 10분 발표 + 5분 질의
발표 내용:
1) 문제 — 고객 문의 응답이 평균 이틀 걸림 (사내 집계, 6월)
2) 원인 — 문의가 3개 채널에 흩어져 담당자 배정이 늦음
3) 제안 — 문의 통합 도구 도입
4) 비용과 일정 — 도입 3개월, 예산은 검토 중

출력 (요약)

시간 배분 — 도입 1분 / 본론 7분 / 마무리 1분 / 여유 1분

한 줄 메시지
  "문제는 사람이 부족해서가 아니라, 문의가 흩어져 있어서입니다."

슬라이드 1 — 문제 (1분 30초)
  말할 내용:
  "고객 문의에 답하는 데 평균 이틀이 걸립니다. 6월 사내 집계 기준입니다.
   이틀이라는 숫자보다 중요한 건, 그중 대부분이 실제로 답을 쓰는 시간이
   아니라 누가 답할지 정해지기까지 기다린 시간이라는 점입니다."
  연결: "왜 그렇게 되는지, 다음 장에서 보시겠습니다."

슬라이드 2 — 원인 (2분)
  ...

예상 질문
  Q. 도구를 사면 정말 하루로 줄어듭니까?
  A. 뼈대 — 배정 대기 시간이 전체의 몇 할인지 먼저 제시 → 그 구간만
     줄어든다고 보수적으로 답변 → 목표치는 파일럿 후 확정.
     (실제 비율은 출처 확인 필요)
  Q. 예산은 얼마입니까? → 확정 전임을 밝히고 언제까지 산정해 오겠다고 약속.

시간 초과 시 자를 순서: 4번 일정 상세 → 2번 원인의 세부 사례 → (도입과
마무리의 한 줄 메시지는 절대 자르지 않습니다)

팁

• 원고를 통째로 외우려 하지 말고, 슬라이드마다 첫 문장과 연결 문장만 외우세요. 나머지는 그 자리에서 말이 이어집니다.
• 긴장을 많이 타는 자리라면 "도입 30초는 한 글자도 안 바꾸고 읽을 수 있게"라고 요청해 시작 부분만 완전 원고로 받으세요.
• 발표 뒤 공유용 문서가 필요하면 같은 {content} 로 "이번엔 읽는 문서로"라고 다시 요청하면 됩니다. 구어체와 문어체는 다른 결과물입니다.

언제 쓰나

이력서를 써 놓고 보니 "무슨무슨 업무를 담당했음"의 나열이 되어 있을 때, 또는 서류에서 자주 떨어지는데 이유를 모를 때 씁니다. 채용 담당자가 보는 것은 맡은 역할이 아니라 그 역할에서 무엇이 달라졌는가입니다. 이 프롬프트는 그 간극을 문장 단위로 짚습니다.

사용법

1. {targetRole} 에 지원하려는 직무를 적습니다. 구체적일수록 좋습니다. (예: 핀테크 백엔드 개발자 (Java/Spring)) 채용 공고가 있으면 주요 자격 요건을 함께 붙이세요.
2. {years} 에 경력 연차를 적습니다. (예: 3년차) 신입이면 신입 (인턴 6개월)처럼 적습니다.
3. {resume} 에 경력기술서 원고를 붙여 넣습니다. 완성본이 아니어도 됩니다.
4. 출력에 남은 [수치 확인 필요] 표시를 직접 채우세요. 이 부분이 이력서의 설득력을 결정합니다. 정확한 숫자를 모르면 "약", "체감상" 같은 표현으로 얼버무리지 말고, 확인 가능한 다른 근거로 바꾸세요.

사용 예시

입력

지원 직무: 이커머스 백엔드 개발자 (Node.js)
경력 연차: 3년차
현재 원고:
- 주문 API 개발 및 유지보수 담당
- 레거시 코드 리팩터링 수행
- 신규 입사자 온보딩 문서 작성

출력 (요약)

첫인상
  세 항목 모두 '무엇을 맡았는가'로 끝나 결과가 읽히지 않습니다. 이커머스
  지원인데 트래픽·정합성·결제 같은 도메인 신호가 하나도 없습니다.

문장 진단
  주문 API 개발 및 유지보수 담당 → (가) 담당 업무 나열
  레거시 코드 리팩터링 수행     → (가) 담당 업무 나열
  온보딩 문서 작성              → (나) 행동은 있으나 결과 없음

다시 쓰기
  - 주문 API 를 설계·운영하며 [수치 확인 필요: 일 주문 건수 또는 피크 RPS]
    규모의 트래픽을 처리했고, 결제 실패 시 주문 상태가 어긋나던 문제를
    보상 트랜잭션으로 정리했습니다.
  - 주문 도메인의 레거시 모듈을 분리해 [수치 확인 필요: 변경 후 배포 주기
    또는 장애 건수 변화] 를 개선했습니다.
  - 온보딩 문서를 작성해 신규 입사자가 [수치 확인 필요: 첫 커밋까지 걸린
    기간] 안에 개발 환경을 갖추도록 했습니다.

배치
  이커머스 지원이므로 주문 API 항목을 맨 위로. 온보딩 문서는 마지막으로.

예상 질문
  Q. 보상 트랜잭션은 어떤 실패 시나리오까지 감당합니까?
     → 준비: 실패 케이스 목록과 각각의 처리 방식, 재시도 정책
  ...

팁

• 채용 공고를 {targetRole} 뒤에 통째로 붙이고 "공고의 자격 요건 각 항목에 대응하는 경험이 있는지 표로"라고 요청하면 지원 여부 판단까지 됩니다.
• [수치 확인 필요] 를 채우지 못하는 항목이 많다면 그건 이력서 문제가 아니라 기록 문제입니다. 지금부터라도 배포 주기, 장애 건수, 처리량을 메모해 두세요.
• 회사마다 원고를 새로 쓰기보다, 이 프롬프트를 지원 직무만 바꿔 다시 돌려 배치와 순서를 조정하는 편이 빠릅니다.

언제 쓰나

새 기술, 시험 범위의 낯선 단원, 회의에서 나온 모르는 용어처럼 혼자 검색해서는 감이 안 잡히는 개념을 익힐 때 씁니다. "설명해줘" 한마디와 달리 비유의 한계, 흔한 오해, 확인 문제까지 강제하기 때문에 이해한 착각을 걸러냅니다.

사용법

1. {concept} 자리에 배우려는 개념을 적습니다. (예: "RAG", "복리", "베이즈 정리")
2. 변수 2개를 채웁니다.
   • {background} — 내 배경 (예: "프로그래밍은 처음인 마케터", "고등학교 수학까지 아는 대학생")
   • {goal} — 목적 (예: "다음 주 발표 준비", "면접 대비", "업무 도구 선택")
3. 6단계 확인 문제에 직접 답을 적어 보내면 채점을 받을 수 있습니다. 이 단계를 건너뛰면 효과가 절반으로 줄어듭니다.

사용 예시

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

저는 프로그래밍은 해본 적 없는 마케터 수준의 학습자이고, 사내 AI 도구 도입 검토를
위해 [개념]을 이해하려고 합니다.
[개념]: 벡터 데이터베이스

출력 (요약) — 6단계가 순서대로 돌아옵니다.

1단계 한 줄 정의
벡터 데이터베이스는 문장이나 이미지를 숫자 목록으로 바꿔 저장하고, "의미가 비슷한
것"을 빠르게 찾아주는 저장소입니다.

2단계 비유
서점의 주제별 서가와 비슷합니다. 제목이 달라도 비슷한 주제의 책은 가까운 칸에 놓이죠.
어긋나는 지점 — 서가는 사람이 분류하지만, 벡터 DB는 좌표가 자동으로 정해집니다.

3단계 원리
(1) 텍스트를 임베딩 모델에 넣어 숫자 목록(벡터)으로 바꿉니다.
(2) 이 벡터들을 좌표처럼 저장합니다.
(3) 검색할 때는 질문도 벡터로 바꿔, 거리가 가까운 것부터 꺼냅니다.

4단계 예시
- 쉬운 예: 사내 FAQ에서 "환불 언제 되나요"로 검색해도 "반품 처리 기간" 문서가 나옵니다.
- 실무에 가까운 예: 고객 문의를 벡터로 저장해두고, 새 문의가 오면 유사 사례를 붙여
  상담원에게 보여줍니다.

5단계 오해 바로잡기
- "키워드 검색보다 항상 낫다" — 정확한 제품 코드 검색 등은 키워드 쪽이 낫습니다.
- "벡터 DB가 답을 만들어준다" — 찾아줄 뿐이고, 답 생성은 별도 모델의 몫입니다.
- "한 번 넣으면 끝" — 임베딩 모델을 바꾸면 전체를 다시 넣어야 합니다.

6단계 확인 문제
(1) 벡터로 바꾸는 단계를 생략하면 무엇이 안 되나요?
(2) 키워드 검색이 더 나은 상황을 하나 들어보세요.
(3) 문서를 추가했는데 검색에 안 나옵니다. 어디부터 확인하겠습니까?
정답은 답을 보내주시면 채점해 드리겠습니다.

6단계에 답을 적어 보내야 채점 단계로 넘어갑니다. 여기서 멈추면 읽기만 한 것과 같습니다.

팁

• 설명이 여전히 어려우면 "2단계 비유를 가 매일 겪는 상황으로 다시 들어줘"라고 요청하세요.
• 개념끼리 헷갈릴 때는 {concept}에 "A와 B의 차이"를 넣으면 비교 표 중심으로 설명을 받을 수 있습니다.
• AI 관련 개념이라면 이 사이트의 용어사전과 함께 보세요 — 정의를 먼저 읽고 프롬프트로 파고들면 빠릅니다.

언제 쓰나

이메일, 문서, 논문 초록, 제품 설명처럼 그대로 기계번역을 돌리면 어색해지는 글을 옮길 때 씁니다. 일반 번역기와 달리 독자·문체·분야를 지정할 수 있고, 번역투를 스스로 점검해 고치는 단계가 내장되어 있습니다.

사용법

1. {text} 자리에 번역할 원문을 붙여 넣습니다.
2. 변수 4개를 상황에 맞게 채웁니다.
   • {target_language} — 도착어 (예: "한국어", "영어(미국)")
   • {audience} — 독자 (예: "해외 거래처 실무자", "일반 소비자")
   • {tone} — 문체 (예: "격식 있는 비즈니스", "친근한 안내문")
   • {domain} — 분야 (예: "IT/소프트웨어", "계약/법무", "마케팅")
3. 결과의 "번역투 점검" 최종본을 채택하면 됩니다. 중간 번역문은 대조용입니다.

사용 예시

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

분야: IT/소프트웨어
도착어: 한국어
독자: 국내 기업 IT 담당자
문체: 격식 있는 비즈니스
[원문]: Our platform is designed to help teams ship faster without sacrificing
reliability. By automating routine checks, it frees engineers to focus on
what actually moves the needle.

출력 (요약) — 번역문 → 의역 노트 → 번역투 점검 최종본 순으로 돌아옵니다.

번역문
저희 플랫폼은 안정성을 희생하지 않으면서 팀이 더 빠르게 배포할 수 있도록 설계되었습니다.
반복적인 점검을 자동화함으로써, 엔지니어가 실제로 성과에 영향을 주는 일에 집중할 수
있게 해줍니다.

의역 노트
- "moves the needle" — 직역하면 "바늘을 움직인다"로 뜻이 통하지 않아, 같은 의미의
  "실제로 성과에 영향을 주는"으로 옮겼습니다.
- "ship" — IT 분야 관례에 따라 "배포"로 옮겼습니다.

번역투 점검 (최종본)
저희 플랫폼은 안정성을 유지하면서도 팀이 더 빠르게 배포하도록 돕습니다. 반복적인
점검을 자동화해 엔지니어가 실제 성과로 이어지는 일에 집중할 수 있습니다.
  - "희생하지 않으면서" → "유지하면서도" (부정문 직역투 제거)
  - "설계되었습니다" 수동태 → 능동 "돕습니다"
  - "함으로써" → "자동화해" (한자어 연결어미 축약)

채택할 것은 마지막 "번역투 점검" 최종본입니다. 위쪽 번역문은 무엇이 어떻게 다듬어졌는지 대조하는 용도입니다.

팁

• 한영 번역에서 존댓말 뉘앙스가 필요하면 {tone}에 "정중하지만 딱딱하지 않게"처럼 구체적으로 적으세요.
• 용어 통일이 중요한 문서(매뉴얼·계약서)는 프롬프트 앞에 "용어표: 원어=역어" 목록을 덧붙이면 일관성이 크게 올라갑니다.
• 긴 문서는 장 단위로 나눠 번역한 뒤, 마지막에 "전체를 다시 읽고 용어·문체 일관성을 맞춰라"라고 한 번 더 시키세요.

언제 쓰나

업무용 이메일 초안을 빠르게 만들어야 하거나, 회의·프로젝트 진행 상황을 보고서 형태로 정리해야 할 때 씁니다. 목적, 수신자, 전달할 핵심 내용만 채우면 이메일과 보고서 두 가지 형식에 모두 대응하도록 만들었습니다.

사용법

1. {purpose} 에 이 글을 쓰는 목적을 적습니다. (예: "지난주 진행 상황 공유", "협업 요청")
2. {recipient} 에 수신자 또는 독자를 적습니다. (예: "팀장", "협력 부서 담당자", "경영진")
3. {key_points} 에 전달하고 싶은 핵심 내용을 적습니다. 문장이든 불릿이든 상관없습니다.
4. {tone} 에 원하는 어조를 적습니다. (예: "격식 있는 존댓말", "간결한 실무", "친근한 톤")
5. {format} 에 이메일 또는 보고서 중 하나를 적습니다.
6. 실행 결과에 [확인 필요] 표시가 있다면, 그 부분은 프롬프트에 넣은 정보만으로는 채울 수 없었다는 뜻이므로 직접 내용을 보완한 뒤 최종본으로 사용하세요.

사용 예시

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

목적: 신규 기능 출시일 연기 공지와 사유 설명
수신자·독자: 협력 부서(영업팀) 담당자
전달할 핵심 내용:
 - 당초 계획 8월 12일 → 8월 26일로 2주 연기
 - 사유: 결제 연동 테스트에서 중복 청구 케이스 발견, 수정 및 재검증 필요
 - 영업팀 요청 사항: 고객 안내 자료의 날짜 수정, 사전 데모 일정 재조율
톤: 격식 있는 존댓말
형식: 이메일

출력 (요약) — 제목 / 인사말 / 본문 / 요청 / 맺음말 구조로 돌아옵니다.

제목: [일정 변경] 결제 연동 기능 출시일 8/12 → 8/26 연기 안내

안녕하세요, 영업팀 담당자님. 제품팀입니다.

결제 연동 기능의 출시 일정 변경을 안내드립니다. 당초 8월 12일로 예정되어 있던
출시일을 8월 26일로 2주 연기하게 되었습니다.

사유는 다음과 같습니다. 출시 전 결제 연동 테스트 과정에서 특정 조건에서 중복 청구가
발생하는 케이스를 확인했습니다. 고객 결제와 직결되는 사안인 만큼 수정 후 재검증까지
마친 뒤 출시하는 것이 안전하다고 판단했습니다.

요청드릴 사항
1. 고객 안내 자료의 출시일을 8월 26일로 수정 부탁드립니다.
2. 기존에 잡혀 있던 사전 데모 일정의 재조율이 필요합니다. [확인 필요 — 데모 대상
   고객사와 현재 예정일이 공유되지 않아 구체적인 대안 일정을 제시하지 못했습니다.]

일정 변경으로 번거로움을 드려 죄송합니다. 문의사항은 회신 주시기 바랍니다.
감사합니다.

[확인 필요]는 오류가 아니라 정상 동작입니다. 입력에 없던 정보를 지어내지 않고 표시로 남긴 것이므로, 그 부분만 직접 채워 최종본으로 쓰시면 됩니다.

팁

• {key_points} 를 구체적으로 채울수록 결과물이 실제 상황에 맞게 나옵니다. 막연하게 적으면 본문도 막연해집니다.
• 같은 내용을 이메일과 보고서 두 형식으로 모두 받아보고 싶다면 {format} 만 바꿔 두 번 실행하면 됩니다.
• 결과물에 지어낸 것으로 보이는 문장이 있다면, "핵심 내용에 없는 사실은 절대 넣지 말라"는 규칙을 다시 강조해 재실행하세요.

긴 문서를 먼저 요약한 뒤 그 내용을 바탕으로 보고서를 쓰고 싶다면 긴 문서 요약 프롬프트를 함께 활용할 수 있습니다. 업무 생산성 관련 프롬프트는 이 페이지 위쪽에 전부 모여 있습니다.

사용법

이 프롬프트는 코드 변경분이나 파일을 붙여 넣으면 버그·가독성·보안·성능 네 축으로 구조화된 리뷰를 돌려줍니다. PR 셀프 리뷰, 페어 리뷰 보조, 리팩터링 전 진단에 쓰기 좋습니다.

1. {language} 에 언어·프레임워크를 적습니다(예: TypeScript / React).
2. {focus} 에 특별히 신경 쓸 부분을 적습니다(예: 동시성, SQL 인젝션, 없으면 전체).
3. {code} 자리에 검토할 코드나 diff를 붙여 넣습니다.

팁: diff 전체보다 관련 함수·모듈 단위로 나눠 넣으면 지적의 정확도가 올라갑니다. 심각도 정렬 덕분에 치명적 이슈부터 처리할 수 있습니다.

사용 예시

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

언어/프레임워크: TypeScript / Express
중점 관점: 보안
검토 대상 코드:
  app.get("/api/users", async (req, res) => {
    const q = req.query.name;
    const rows = await db.query(`SELECT * FROM users WHERE name LIKE '%${q}%'`);
    res.json(rows);
  });

출력 (요약) — 요약 → 심각도순 지적 목록 → 잘된 점 순으로 돌아옵니다.

요약
검색 파라미터가 SQL 문자열에 직접 삽입되어 인젝션에 노출됩니다. 응답도 사용자
레코드 전체를 그대로 반환하고 있어 민감정보가 노출됩니다.

[치명적][보안] 3행 — SQL 인젝션
  문제: req.query.name 이 검증·이스케이프 없이 쿼리 문자열에 삽입됩니다.
  근거: 템플릿 리터럴로 `LIKE '%${q}%'` 를 조립합니다.
  수정 제안: 파라미터 바인딩으로 교체 — db.query("... WHERE name LIKE ?", [`%${q}%`])

[높음][보안] 4행 — 과다 노출
  문제: SELECT * 결과를 그대로 직렬화해 password_hash·email 까지 나갈 수 있습니다.
  수정 제안: 필요한 컬럼만 명시하거나 응답 직전 화이트리스트로 매핑합니다.

[중간][버그] 2행 — 입력 타입 미검증
  문제: req.query.name 은 배열일 수 있어 문자열 연산에서 예상치 못한 값이 됩니다.
  수정 제안: typeof 검사 후 아니면 400 응답.

잘된 점
- 비동기 처리에 async/await 를 일관되게 사용했습니다.
- 라우트 하나가 한 가지 일만 하고 있어 수정 범위가 좁습니다.

언제 쓰나

보고서, 논문, 회의록, 계약서, 긴 이메일 스레드처럼 한눈에 안 들어오는 문서를 빠르게 파악할 때 씁니다. 단순히 짧게 줄이는 것이 아니라 핵심 요점, 수치 근거, 실행 항목, 불명확한 지점까지 나눠서 뽑아내도록 설계했습니다.

사용법

1. 프롬프트의 {document} 자리에 요약할 원문을 붙여 넣습니다.
2. 변수 4개를 상황에 맞게 채웁니다.
   • {length} — 원하는 분량 (예: "300자 이내", "불릿 5개")
   • {tone} — 문체 (예: "간결한 실무", "친근한 설명")
   • {audience} — 독자 (예: "경영진", "비전문가 신규 팀원")
   • {document} — 요약 대상 원문
3. 문서가 모델의 입력 한도를 넘으면 장(章) 단위로 나눠 각각 요약한 뒤, 그 요약들을 다시 이 프롬프트로 한 번 더 합칩니다.

사용 예시

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

분량: 불릿 5개 내외
톤: 간결한 실무
독자: 경영진
[문서]: (분기 서비스 운영 보고서 전문 — 장애 이력, 응답 지표, 인력 현황 등 18페이지)

출력 (요약) — 여섯 개 블록이 정해진 순서로 돌아옵니다.

한 줄 요약
2분기 서비스는 가용성 목표를 달성했으나, 장애 대응 시간이 1분기 대비 늘어 인력 보강
검토가 필요한 상태입니다.

핵심 요점
- 월 가용성 목표 달성 (3개월 연속)
- 평균 장애 복구 시간이 전 분기 대비 증가
- 장애 원인 1위는 배포 직후 설정 오류
- 야간 대응 인력이 1명으로 유지되고 있음
- 모니터링 알림의 상당수가 실제 조치 없이 종료됨

세부 내용
가용성 — (2~4문장)
장애 대응 — (2~4문장)
인력 운영 — (2~4문장)

수치·근거
| 항목 | 값 | 출처 위치 |
| --- | --- | --- |
| 2분기 평균 가용성 | 99.95% | 3페이지 표1 |
| 평균 복구 시간 | 42분 | 7페이지 |
| 야간 대응 인원 | 1명 | 12페이지 |

실행 항목
- 야간 대응 인력 충원 여부를 3분기 예산 논의에 포함
- 배포 후 설정 검증 절차 도입 검토

불명확·주의
- 1분기 복구 시간 수치가 본문과 부록에서 다르게 기재되어 있습니다 (불명확).
- 알림 대비 실제 조치 비율은 문서에 근거가 없어 산출하지 않았습니다.

"불명확·주의" 블록이 비어 있지 않다는 것은 요약이 빈칸을 지어내지 않았다는 신호입니다. 이 항목부터 원문과 대조하세요.

팁

• 요약이 원문에 없는 내용을 지어내면, "문서에 근거가 없으면 '불명확'으로만 표시하라"는 규칙을 다시 강조하세요.
• 표의 "출처 위치"는 페이지·섹션·문단 번호를 넣게 하면 원문 대조가 쉬워집니다.

사용법

녹취록, 채팅 로그, 손으로 적은 메모 등 정리되지 않은 회의 기록을 그대로 붙여넣으면 결정 사항과 액션 아이템으로 구조화해 줍니다.

1. {meeting_title}, {meeting_date} 에 회의 제목과 일시를 넣습니다. 모르면 비워 두어도 됩니다.
2. {raw_transcript} 에 원시 회의 기록 전체를 붙여넣습니다.
3. 실행 후 결정 사항과 액션 아이템 표를 먼저 확인하세요. 담당자나 기한이 미정 또는 [미확정]으로 표시된 항목은 참석자에게 다시 확인하면 됩니다.

기록에 없는 내용은 채우지 않도록 설계되어 있으므로, 빈 칸은 실제로 회의에서 정해지지 않았다는 신호로 활용하세요.

이 프롬프트를 원문 확보·요약·구조화·공유로 이어지는 전체 워크플로우 안에서 어떻게 쓰는지는 회의록·문서 요약, AI로 자동화하는 법 가이드에서 단계별로 다룹니다.

사용 예시

입력 — 정리되지 않은 원시 기록을 그대로 붙여넣은 실제 입력입니다.

회의 제목: 3분기 랜딩페이지 개편 킥오프
회의 일시: 2026-07-28 14:00

원시 회의 기록:
김: 일단 개편 범위부터. 전체 다 갈아엎는 건 무리고 히어로랑 가격 섹션만.
이: 가격 섹션은 법무 검토 있어야 되는데요
김: 아 맞다. 그럼 가격은 일단 빼고 히어로만 확정으로 가죠
박: 디자인 시안은 제가 다음 주까지... 아 근데 8/5에 휴가라
김: 그럼 8/3까지 초안만 주시고 확정은 복귀 후에
이: 법무 문의는 제가 넣을게요 이번 주 안에
박: 모바일 대응도 같이 봐야 하나요?
김: 그건 시안 나오면 그때 얘기하죠

출력 (요약) — 개요·논의·결정·액션 아이템·후속 순으로 구조화되어 돌아옵니다.

[회의 개요]
제목: 3분기 랜딩페이지 개편 킥오프 / 일시: 2026-07-28 14:00 / 참석자: 김, 이, 박

[핵심 논의 요약]
- 개편 범위를 전면 개편이 아닌 부분 개편으로 좁힘
- 가격 섹션은 법무 검토가 선행되어야 함이 확인됨
- 디자인 시안 일정이 담당자 휴가와 겹침
- 모바일 대응 범위는 논의만 되고 결론 없음

[결정 사항]
- 이번 개편 범위는 히어로 섹션으로 한정한다.
- 가격 섹션은 이번 범위에서 제외한다.
- 디자인은 8/3까지 초안만 제출하고, 확정은 담당자 복귀 후로 미룬다.

[액션 아이템]
| 할 일 | 담당자 | 기한 | 비고 |
| --- | --- | --- | --- |
| 히어로 섹션 디자인 초안 | 박 | 2026-08-03 | 확정본 아님 |
| 가격 섹션 법무 문의 접수 | 이 | 이번 주 내 | [미확정] 정확한 날짜 없음 |
| 시안 확정 검토 | 박 | 미정 | 휴가 복귀 후 |

[후속 논의 필요]
- 모바일 대응 포함 여부 (시안 확인 후 재논의)

미정과 [미확정]은 모델이 못 채운 것이 아니라 회의에서 실제로 정해지지 않았다는 신호입니다. 이 칸만 참석자에게 다시 확인하면 됩니다.