업무 이메일은 한 통만 보면 오래 걸리는 일이 아닐 수 있다.
하지만 하루 동안 일정 변경 안내, 자료 요청, 회의 후속 연락, 내부 협조 요청처럼 비슷한 이메일을 계속 작성하다 보면 생각보다 많은 시간이 들어간다.
특히 내용은 이미 머릿속에 있는데 첫 문장을 어떻게 시작할지 고민하거나, 너무 딱딱하지 않으면서도 예의를 갖춘 표현으로 바꾸는 과정에서 시간이 쓰이기 쉽다.
이럴 때 생성형 AI는 이메일을 대신 판단하는 도구라기보다 이미 정해진 내용을 읽기 좋은 업무 문장으로 바꾸는 초안 작성 도구로 활용하기 좋다.
제가 이메일 작업에서 중요하게 보는 부분도 “멋진 이메일을 한 번에 만들어달라”가 아니다.
누구에게 왜 보내는지와 반드시 전달해야 할 사실을 먼저 정리해주고, AI에게 문장화를 맡기는 것이다.
“이 내용으로 메일 써줘”가 자주 수정되는 이유
다음과 같은 요청도 충분히 사용할 수 있다.
“교육 일정이 바뀌었다고 직원들에게 이메일 써줘.”
AI는 이 정보만으로도 이메일을 작성할 수 있다.
하지만 결과를 받은 뒤 수정해야 할 부분이 많아질 가능성이 있다.
누구에게 보내는지 명확하지 않다.
기존 일정과 변경된 일정이 무엇인지 알 수 없다.
변경 이유를 알려줘야 하는지도 모른다.
받는 사람이 별도로 해야 할 행동이 있는지도 알 수 없다.
결국 AI가 빈 부분을 추측해야 한다.
이런 상황에서는 프롬프트를 길고 화려하게 쓰기보다 필요한 사실을 몇 줄로 나눠 제공하는 편이 좋다.
예를 들어 다음과 같이 정리할 수 있다.
“다음 내용으로 내부 직원 대상 안내 이메일 초안을 작성해줘.
수신자: 이미 교육을 신청한 직원
목적: 교육 시간 변경 안내
기존 일정: 8월 20일 오전 10시
변경 일정: 8월 20일 오후 2시
수신자가 할 일: 참석이 어려우면 담당자에게 회신
문체: 정중한 업무용 문체, 지나치게 딱딱하지 않게
분량: 짧게”
이 정도만 제공해도 AI가 임의로 결정해야 하는 부분이 상당히 줄어든다.
이메일 초안에는 네 가지 정보부터 넣어본다
업무 이메일을 AI에 맡길 때 기억하기 쉬운 항목은 네 가지다.
첫째는 수신자다.
같은 내용도 팀원에게 보내는지, 상급자에게 보내는지, 외부 고객에게 보내는지에 따라 표현이 달라진다.
둘째는 이메일의 목적이다.
단순 안내인지, 자료 요청인지, 일정 조율인지, 확인을 받기 위한 메일인지 명확하게 알려준다.
셋째는 반드시 포함할 사실이다.
날짜, 일정, 파일명, 요청 사항처럼 틀리면 안 되는 정보다.
넷째는 상대방이 해야 할 행동이다.
회신이 필요한지, 자료를 전달해야 하는지, 별도 행동 없이 확인만 하면 되는지 적는다.
예를 들어 자료 요청 메일이라면 다음처럼 만들 수 있다.
“외부 협력사 담당자에게 자료를 요청하는 이메일 초안을 작성해줘.
목적: 다음 주 회의 전 판매 현황 자료 요청
필수 내용: 1~7월 월별 자료
희망 회신일: 이번 주 금요일
상대방이 할 일: 엑셀 파일로 회신
문체: 정중하되 과도하게 사과하거나 압박하는 표현은 피하기”
이런 프롬프트는 다른 이메일에도 쉽게 재사용할 수 있다.
제목과 본문을 함께 요청하면 편집 시간이 줄어든다
이메일을 작성할 때 본문만큼 자주 고민하는 것이 제목이다.
AI에게 본문만 요청한 뒤 제목을 다시 만드는 대신 처음부터 함께 요청할 수 있다.
예를 들어,
“제목 후보 3개와 이메일 본문을 함께 작성해줘. 제목만 읽어도 일정 변경에 관한 메일임을 알 수 있게 해줘.”
라고 요청한다.
업무 이메일 제목에서는 멋진 표현보다 목적이 잘 드러나는 것이 중요하다.
“중요한 안내드립니다”
같은 제목보다,
“8월 20일 내부 교육 시간 변경 안내”
처럼 구체적인 제목이 실제 업무에서는 확인하기 쉽다.
특히 메일함에 여러 메시지가 쌓이는 환경이라면 날짜나 프로젝트명, 요청 내용을 제목에 포함하는 것이 도움이 된다.
AI에게도,
“과장된 제목이나 ‘필독’, ‘긴급’ 같은 표현은 실제로 필요한 경우가 아니면 사용하지 말아줘.”
라는 조건을 넣을 수 있다.
일정과 숫자는 문장보다 먼저 확인한다
AI가 작성한 이메일에서 가장 먼저 확인할 것은 자연스러운 문장이 아니다.
날짜, 시간, 금액, 파일명, 사람 이름처럼 실제 업무와 직접 연결되는 정보다.
예를 들어 원래 일정이 오후 2시인데 AI가 문장을 다듬는 과정에서 오전 2시라고 쓴다면 표현이 아무리 정중해도 사용할 수 없다.
그래서 중요한 이메일은 완성된 초안을 읽을 때 다음 순서로 확인하는 편이 효율적이다.
먼저 날짜와 시간을 본다.
그다음 수신 대상과 사람 이름을 확인한다.
첨부파일이나 자료명이 있다면 실제 파일과 일치하는지 본다.
마지막으로 요청 마감일과 상대방이 해야 할 행동을 확인한다.
이런 사실 확인이 끝난 뒤 문체를 다듬는다.
AI 이메일 초안에서는 문장 품질보다 업무 정보의 정확성이 우선이다.
지나치게 정중하거나 장황한 AI 문장을 줄이는 방법
생성형 AI에게 업무 이메일을 부탁하면 필요 이상으로 격식을 차리는 경우가 있다.
예를 들어 단순 자료 요청인데,
“바쁘신 와중에도 늘 적극적으로 협조해주셔서 진심으로 감사드리며…”
처럼 긴 인사말이 붙을 수 있다.
상황에 따라 괜찮을 수도 있지만 내부 업무 메일에서는 오히려 핵심이 늦게 보일 수 있다.
이럴 때는 단순히 “짧게 써줘”보다 문체 기준을 더 구체적으로 주면 좋다.
“첫 문단에서 바로 이메일 목적을 알려줘.”
“의례적인 인사말은 한 문장 이내로 해줘.”
“요청 사항은 별도 문단으로 분리해줘.”
“같은 감사 표현을 반복하지 말아줘.”
이런 조건을 넣으면 실무에서 바로 쓰기 쉬운 형태에 가까워진다.
특히 사내 이메일은 긴 서론보다 무엇이 바뀌었고 무엇을 해야 하는지 빠르게 보이는 구조가 편한 경우가 많다.
민감한 이메일은 내용 자체보다 문장 다듬기에 AI를 쓴다
모든 이메일을 같은 방식으로 AI에 맡길 필요는 없다.
예를 들어 중요한 계약 조건, 민감한 인사 내용, 고객 분쟁처럼 잘못된 표현 하나가 문제가 될 수 있는 이메일은 AI가 초안 전체를 결정하도록 하기보다 사람이 먼저 핵심 내용을 작성한 뒤 문장만 다듬게 하는 편이 낫다.
예를 들어,
“아래 문장의 사실 내용과 입장은 바꾸지 말고, 정중한 업무 이메일 문체로만 다듬어줘. 새로운 약속이나 보상 조건은 추가하지 말아줘.”
라고 요청할 수 있다.
이 방식은 AI가 내용을 확장하는 범위를 줄인다.
특히 금액, 계약, 일정 약속처럼 새로운 문구가 실제 책임으로 이어질 수 있는 상황에서는 AI의 창의성보다 원문 보존이 더 중요하다.
이메일 하나를 여러 버전으로 비교해볼 수도 있다
어떤 말투가 적절한지 애매할 때는 한 가지 결과만 받기보다 두세 가지 버전을 만들어 비교하는 방법도 있다.
예를 들어,
“같은 내용으로 세 가지 버전을 작성해줘.
가장 간결한 버전
일반적인 업무용 버전
외부 협력사에게 보낼 조금 더 정중한 버전”
처럼 요청할 수 있다.
그러면 처음부터 원하는 문체를 완벽하게 설명하지 못해도 결과를 비교하면서 적절한 수준을 선택할 수 있다.
특히 AI를 처음 업무에 사용하는 단계에서는 이 방식이 유용하다.
어떤 표현이 내가 평소 사용하는 메일과 잘 맞는지 직접 비교해볼 수 있기 때문이다.
마음에 드는 버전이 나오면 다음부터는,
“앞서 사용한 일반적인 업무용 버전 정도의 문체로 작성해줘.”
처럼 자신의 기준을 만들 수 있다.
자주 보내는 이메일은 템플릿으로 만들어둔다
반복 업무 자동화의 장점은 같은 작업을 다시 할 때 커진다.
예를 들어 일정 변경 메일을 자주 보낸다면 다음과 같은 기본 틀을 저장할 수 있다.
“아래 정보로 일정 변경 안내 이메일을 작성해줘.
수신자: [대상]
기존 일정: [기존 일정]
변경 일정: [새 일정]
변경 이유: [필요한 경우만 입력]
수신자가 할 일: [회신/확인/별도 행동 없음]
작성 규칙:
제목과 본문을 함께 작성
첫 문단에서 변경 사실을 바로 전달
날짜와 시간은 입력한 값을 그대로 유지
불필요한 사과나 과장 표현은 넣지 않기
전체는 짧은 업무용 이메일 형식”
다음번에는 대괄호 부분만 바꿔 사용하면 된다.
자료 요청 메일, 회의 일정 조율, 내부 공지 등도 각각 템플릿으로 분리해둘 수 있다.
하나의 만능 이메일 프롬프트보다 자주 보내는 이메일 유형별로 짧은 템플릿을 만드는 편이 실제 사용에서는 관리하기 쉽다.
AI가 만든 이메일에도 개인정보가 들어갈 수 있다
업무 이메일을 AI로 작성할 때는 원본 이메일을 그대로 복사해 붙여 넣는 경우가 많다.
그 과정에서 수신자의 이메일 주소, 전화번호, 고객 정보, 계약 내용 등이 포함될 수 있다.
따라서 사용하는 AI 서비스가 회사에서 허용된 것인지 먼저 확인해야 한다.
또 실제 이름이 꼭 필요하지 않다면 가명이나 역할명으로 바꿔서 초안을 만들 수 있다.
예를 들어,
“김민수 고객에게…”
대신,
“고객 A에게…”
라고 작성하게 한 뒤 최종 단계에서 사람이 실제 이름을 넣는 방식이다.
이메일 문장만 다듬는 데 고객의 상세 주소나 전화번호까지 필요한 경우는 거의 없다.
AI에 제공하는 정보는 문장을 만드는 데 필요한 최소 범위로 제한하는 것이 좋다.
보내기 전에는 ‘AI 검토’보다 ‘사람 검토’가 마지막 단계다
AI에게,
“이 이메일에 문제 없는지 확인해줘.”
라고 다시 검토시킬 수 있다.
오탈자나 중복 표현을 찾는 데는 도움이 된다.
하지만 최종 발송 여부를 AI에게 맡겨서는 안 된다.
AI는 실제 회사 상황을 모두 알지 못한다.
받는 사람과의 관계도 정확히 알 수 없고, 어떤 표현이 조직 내부에서 민감한지도 판단하기 어렵다.
따라서 마지막에는 사람이 직접 읽어야 한다.
특히 다음 네 가지는 반드시 확인하는 습관이 좋다.
누구에게 보내는가?
무엇을 요청하는가?
날짜와 숫자가 맞는가?
이 문장이 실제로 내가 약속해도 되는 내용인가?
이 네 가지가 맞다면 AI가 만든 초안을 훨씬 안전하게 활용할 수 있다.
간단한 이메일 자동화 흐름
업무에서 반복적으로 이메일을 작성한다면 다음과 같은 흐름으로 고정할 수 있다.
먼저 전달할 사실을 메모한다.
수신자와 목적을 정한다.
AI에게 제목과 본문 초안을 만들게 한다.
날짜, 이름, 금액, 요청 사항을 확인한다.
말투를 필요한 수준으로 조정한다.
마지막으로 사람이 직접 읽고 발송한다.
이 과정에서 AI가 담당하는 부분은 문장을 처음부터 만드는 수고를 줄이는 것이다.
반면 사실 확인과 최종 책임은 사람에게 남는다.
이 역할 분담이 명확하면 이메일 작성에도 AI를 부담 없이 활용하기 쉽다.
마무리
업무 이메일은 생성형 AI를 적용하기 좋은 반복 작업 중 하나다.
이미 전달할 내용은 정해져 있고, 사람이 시간을 쓰는 부분은 그것을 적절한 문장과 형식으로 만드는 과정인 경우가 많기 때문이다.
AI에게 이메일을 맡길 때는 “메일 써줘”라고만 요청하기보다 수신자, 목적, 반드시 포함할 사실, 상대방이 해야 할 행동을 먼저 정리해주는 것이 좋다.
그리고 중요한 이메일일수록 AI에게 내용 전체를 새로 만들게 하기보다 사람이 정한 사실과 입장을 유지한 상태에서 문장을 다듬게 하는 편이 안전하다.
무엇보다 마지막에는 날짜, 숫자, 이름, 약속 내용을 사람이 직접 확인해야 한다.
생성형 AI를 이메일에 활용하는 목적은 사람이 어떤 말을 해야 할지 판단하는 일을 대신시키는 것이 아니다.
이미 정해진 내용을 빠르고 읽기 좋은 초안으로 바꾸는 반복 작업을 줄이는 것이다.
이 방식이 자리 잡으면 매번 첫 문장에서 멈춰 고민하는 시간을 줄이고, 실제로 중요한 내용 확인에 더 집중할 수 있다.
다음 글에서는 긴 보고서나 기사, 사내 자료처럼 읽는 데 시간이 많이 드는 문서를 대상으로 AI를 이용해 필요한 내용만 빠르게 추출하고 요약하는 업무 방식을 살펴본다.
FAQ
Q1. AI가 만든 이메일을 그대로 보내도 되나요?
간단한 메일이라도 최종 확인은 사람이 하는 것이 좋다. 특히 수신자, 날짜, 일정, 금액, 요청 사항처럼 실제 업무에 영향을 주는 정보가 정확한지 확인해야 한다. AI는 문장을 자연스럽게 만들 수 있지만 실제 조직 상황까지 모두 알고 있는 것은 아니다.
Q2. 이메일 프롬프트에서 가장 중요한 정보는 무엇인가요?
수신자와 이메일의 목적, 반드시 포함해야 할 사실, 상대방이 해야 할 행동을 우선적으로 알려주는 것이 좋다. 이 네 가지가 분명하면 AI가 불필요하게 내용을 추측하는 범위를 줄일 수 있다.
Q3. 매번 다른 이메일인데도 템플릿을 만들어둘 수 있나요?
가능하다. 실제 내용은 달라도 일정 변경, 자료 요청, 회의 조율처럼 이메일의 목적은 반복되는 경우가 많다. 목적별 템플릿을 만들어두고 대상·날짜·요청 사항만 바꾸는 방식으로 사용하면 매번 프롬프트를 처음부터 작성할 필요가 없다.
0 댓글