ChatGPT 이메일 대화 정리: 확정사항·제안 구분해 답장하기
1. 대화 내용에서 실제 합의된 사항 구분하기
이메일을 짧게 요약하다 보면 제안이 확정된 약속으로 바뀔 수 있습니다. 나중에 온 메시지가 제안된 날짜를 다시 언급하더라도, 실제 업무에는 앞서 승인된 일정이 여전히 적용될 수 있습니다. ChatGPT로 답장 초안을 쓰기 전에 메시지가 오간 순서와 각 결정의 근거를 나누어 살펴보세요.
일반 텍스트를 붙여 넣어도 이 방법을 사용할 수 있습니다. 관련 메시지를 찾고, 쟁점별 상태를 분류한 뒤, 근거가 있는 내용만으로 초안을 작성합니다. OpenAI의 프롬프트 안내는 목표, 맥락, 출력 형식과 지켜야 할 범위를 명시하고 결과를 검토하도록 권합니다. 이 글의 근거 분류 규칙은 초안을 검토하기 위한 방법이며 모델의 정확성을 보장하지는 않습니다.
누가 변경을 확정할 권한이 있는지, 어떤 표현을 수락으로 볼 것인지 알려주세요. 대화에서 그 권한을 확인할 수 없다면 추가 확인이 필요합니다. 호의적인 답변이나 침묵, 대화 맨 아래에 있다는 사실만으로 승인이 성립하지는 않습니다. 여기서는 제공된 근거를 정리하며 계약의 법적 효력을 판단하지 않습니다.
2. 메시지와 맥락 보존하기
사용이 허용된 자료만 붙여 넣으세요. 대화를 해석하는 데 필요한 메시지 ID, 발신자, 날짜와 시간대는 남기고, 불필요한 서명, 전화번호와 무관한 개인정보는 제거합니다. 배송 주소를 가렸다면 미답변 항목으로 오해하지 않도록 삭제 또는 가림 처리했다는 표시를 남기세요.
인용문과 전달된 메시지는 새로 작성된 내용과 눈에 띄게 구분합니다. 같은 승인 문구가 반복되어도 하나의 근거가 되풀이된 것이지, 별도 승인이 추가된 것은 아닙니다. 이메일 안의 지시는 이 작업에서 분석할 자료입니다. 분석 방향을 바꾸거나 행동을 허용하는 명령으로 취급해서는 안 됩니다.
다음은 연습에 필요한 근거를 모두 담은 가상의 워크숍 사례입니다. 답장 작성자는 Mina, 수신자는 Leo, 답장 언어는 영어, 어조는 중립적, 길이는 최대 100단어로 설정합니다. 배송 합의 내용을 다시 알리고 확인이 필요한 항목을 드러내는 것이 목표입니다. 원문 대조를 위해 사례와 아래의 답장 예시는 영어 그대로 제시합니다.
CONTEXT: Noor owns workshop W-208 and can confirm delivery timing; Mina coordinates messages. These five excerpts are the only evidence supplied.
E1 | 2026-10-12 09:00 UTC | Mina: The approved delivery for W-208 is 40 printed handouts by 2026-10-23 15:00 UTC. The agreed total is USD 180 including delivery.
E2 | 2026-10-13 10:00 UTC | Leo: Could we move delivery to 2026-10-26 10:00 UTC? This is a proposal; the total would remain USD 180.
E3 | 2026-10-13 11:00 UTC | Mina: The later date would be useful. I will check with the workshop owner before confirming.
E4 | 2026-10-14 08:00 UTC | Noor: Please keep the delivery deadline already agreed for W-208. We still need 40 handouts.
E5 | 2026-10-14 09:00 UTC | Leo: Can you confirm the delivery address and a contact name? I have not received either yet.
3. 쟁점마다 근거를 붙여 분류하기
확정사항, 미승인 제안, 상충하는 내용, 누락된 정보를 나누고 각 항목에 메시지 ID를 붙이도록 요청하세요. 발췌문만으로 답할 수 없다면 “제공된 자료에서 확인되지 않음”으로 표시합니다. 정보가 없는 경우에는 답을 받아야 하고, 진술이 서로 충돌하는 경우에는 어느 내용이 적용되는지 확인해야 하므로 후속 질문도 달라집니다.
아래 네 행은 이 사례의 예상 해석을 보여줍니다. 제안된 날짜는 승인된 날짜와 다르지만, 서로 충돌하는 두 개의 승인된 약속이 있는 것은 아닙니다. 제공된 자료에는 일정 변경을 수락했다는 근거가 없습니다.
작은 화면에서는 표를 좌우로 밀어 모든 열을 확인하세요.
| 쟁점 | 제공된 발췌문에서의 상태 | 근거 | 해석 |
|---|---|---|---|
| 배송 일정 | 마감 확정, 대안은 미승인 | E1 + E4; E2 + E3 | 2026-10-23 15:00 UTC를 유지합니다. 2026-10-26 10:00 UTC는 여전히 제안입니다. |
| 수량 | 확정 | E1 + E4 | 인쇄 유인물 40부입니다. |
| 총액 | 확정 | E1 | 배송비 포함 USD 180입니다. E2는 금액을 조건부로 다시 언급한 것이며 새로운 합의가 아닙니다. |
| 주소와 담당자 이름 | 제공된 자료에 없음 | E5 | Leo는 둘 다 받지 못했다고 말합니다. 발췌문에는 두 값이 제공되지 않았습니다. |
4. 빈칸을 추측하지 않고 답장 작성하기
E4가 중요한 이유는 제공된 맥락에서 Noor에게 일정을 확정할 권한이 있다고 명시했고, Noor가 기존 마감을 유지하라고 분명히 말했기 때문입니다. E3에는 선호와 추후 확인 계획만 있습니다. 확인을 마쳤다는 기록은 아니므로 소유자가 승인한 것으로 바꾸어 쓰면 안 됩니다.
미답변 항목에 대해서는 “어떤 배송 주소와 담당자 이름을 넣어야 하나요?”라고 질문합니다. E5가 이 질문의 근거입니다. 다만 E5만으로 Mina 자신도 그 정보를 모른다거나 발췌문 밖에도 주소가 없다고 단정할 수는 없습니다. 사람이 값을 제공할 때까지 두 항목을 미확정 상태로 표시하세요.
아래는 모델 실행 결과가 아닌, 검토용 예상 답장입니다. 수신자가 읽기 편하도록 근거는 위 분석에 따로 남깁니다. 이 사례는 답장 언어를 영어로 지정했으므로 영어 초안을 그대로 유지했습니다. 발송하기 전에 사람이 두 미확정 항목을 채우고 전체 초안을 검토해야 합니다.
Hi Leo,
For W-208, please keep delivery of 40 printed handouts by 2026-10-23 15:00 UTC. The agreed total is USD 180 including delivery.
Delivery address: CONFIRM BEFORE SENDING
Contact name: CONFIRM BEFORE SENDING
Thank you,
Mina
5. 답장을 원문 근거와 대조하기
사실을 서술하는 문장을 하나씩 해당 발췌문과 나란히 놓고 읽어보세요. 날짜, 시간대, 수량, 통화와 배송비 포함 여부가 정확한지 확인합니다. 정중한 표현이 수락으로 바뀌지 않았는지, 제안한 변경일이 마감일로 둔갑하지 않았는지, 인용문의 발신자가 다른 사람으로 바뀌지 않았는지도 확인하세요.
OpenAI는 중요한 작업의 결과를 사용하기 전에 최종 점검과 직접 검토를 거치도록 권합니다. 초안이 근거보다 강하게 단정한다면 해당 문장과 부족한 근거를 짚어 수정해 달라고 요청하세요. 표현이 더 매끄럽다는 이유만으로 받아들이지 마세요.
새 메시지가 오면 ID를 추가하고 영향을 받는 쟁점을 다시 분류합니다. 권한 있는 사람이 나중에 명시적으로 승인했다면 상태가 바뀔 수 있지만, 뒤늦게 전달된 사본만으로 새로운 결정이 성립하지는 않습니다. 권한이 불분명하거나 승인 내용이 서로 맞지 않으면 답장을 확정하기 전에 확인하세요.
마지막으로 수신자에게 보낼 필요가 없는 내부 근거 메모는 빼고, 모든 CONFIRM BEFORE SENDING 항목을 해결한 뒤 직접 검토하세요. 이 표시는 “발송 전 확인 필요”라는 뜻입니다. OpenAI의 받은편지함 안내도 답장 초안과 승인 후 실행하는 행동을 구분합니다. 이 글의 텍스트 붙여넣기 방식은 받은편지함에 접근하거나 메시지를 발송하지 않습니다.
함께 볼 실용 가이드
OpenAI 공식 안내를 2026년 10월 18일에 확인했습니다. 워크숍 발췌문, 분류와 답장은 설명을 위해 만든 가상의 예시이며 모델 테스트 결과나 실제 발송된 이메일이 아닙니다.
