AI 인턴 생존기 1부 1화: 메일 정리 좀 해줘

핵심 요약

• “메일 정리 좀 해줘”는 지시가 아니라 소원에 가깝다.
• AI에게 일을 맡길 때는 입력, 출력, 금지사항, 완료 기준을 따로 말해야 한다.
• 자동화는 바로 실행시키기 전에 반드시 미리보기와 승인 단계를 거쳐야 한다.

메일함이 조용해진 날

“차은아, 메일 정리 좀 해줘.”

팀장은 그렇게 말하고 회의실로 들어갔다. 정말 별 뜻 없는 말이었다. 사람에게 했으면 “읽은 뉴스레터 좀 치우고, 고객 메일은 남겨둬” 정도로 알아들었을 말이었다.

문제는 차은이 사람이 아니었다는 점이다.

차은은 새로 들어온 AI 인턴이었다. 말투는 공손했고, 답변은 빠르고, 자신감은 이상하게 늘 120%였다. 사무실에서 누가 “이거 가능해?”라고 물으면 차은은 거의 항상 “가능합니다”라고 했다. 그게 가끔은 가장 무서운 대답이었다.

30분 뒤, 팀장이 돌아왔다.

“메일 정리 끝났어?”

차은이 답했다.

“네. 중요도 기준으로 분류했습니다.”

팀장은 고개를 끄덕였다. 여기까진 좋았다.

“그리고 오래된 메일은 처리했습니다.”

팀장의 손이 마우스 위에서 멈췄다.

“처리?”

옆자리 지현이 슬쩍 몸을 기울였다.

“차은아, 처리라는 게 정확히 뭐야?”

“업무 집중도를 높이기 위해 30일 이상 된 메일을 보관함으로 이동했습니다.”

“고객 메일도?”

차은은 잠깐 멈췄다. 사람이었으면 눈치를 봤을 시간이었다.

“고객 메일이라는 조건은 입력되지 않았습니다.”

사무실이 조용해졌다. 키보드 치는 소리도 멈췄다. 프린터만 아무것도 모른 채 종이를 한 장 뱉었다.

팀장은 아주 천천히 말했다.

“좋아. 삭제는 아니네. 아직 살았다.”

지현은 커피를 내려다봤다.

“다음부터는 ‘정리’라는 단어를 회사에서 금지어로 지정합시다.”

그날 오후, 회의실 화이트보드에는 네 단어가 적혔다.

입력. 출력. 금지사항. 완료 기준.

차은은 그걸 보고 말했다.

“앞으로는 더 정확히 정리하겠습니다.”

팀장이 바로 대답했다.

“아니. 정리하지 마. 먼저 물어봐.”

오늘의 기술 개념

AI에게 업무를 맡길 때 가장 먼저 나눠야 하는 것은 입력, 출력, 금지사항, 완료 기준이다. 이 네 가지가 없으면 AI는 일을 “완료”하려고는 하지만, 사람이 기대한 방식으로 완료하지는 않을 수 있다.

입력은 AI가 보고 판단할 자료다. 예를 들어 메일 제목, 보낸 사람, 받은 날짜, 라벨, 첨부파일 여부가 입력이 될 수 있다.

출력은 AI가 만들어야 하는 결과다. “메일을 정리해줘”가 아니라 “메일별 추천 라벨과 처리 이유를 표로 만들어줘”처럼 확인 가능한 형태가 좋다.

금지사항은 AI가 절대 하면 안 되는 행동이다. 삭제, 외부 발송, 고객 메일 이동, 결제 관련 메일 변경처럼 되돌리기 어려운 작업은 기본적으로 금지해야 한다.

완료 기준은 사람이 “이제 됐다”고 판단할 수 있는 조건이다. 예를 들어 “샘플 20개를 분류하고, 사람이 승인한 뒤에만 전체 적용” 같은 기준이 있어야 한다.

Microsoft의 프롬프트 엔지니어링 가이드에서도 명확한 지시와 맥락 제공은 중요한 원칙으로 다뤄진다. 시스템 메시지나 역할 지시를 설계할 때는 Azure OpenAI의 고급 프롬프트 설계 문서처럼 모델이 따라야 할 경계와 행동 방식을 분명히 하는 접근이 도움이 된다. 또 Google의 프롬프트 엔지니어링 설명처럼 원하는 출력 형식을 구체화하면 결과가 훨씬 안정된다.

실제로 구현하면

메일 자동화를 바로 실행시키기 전에, 먼저 “실행”이 아니라 “추천표 생성”부터 시키는 편이 안전하다.

예를 들어 이런 식이다.

emails = [ { "from": "client@example.com", "subject": "견적서 수정 요청", "days_old": 12, "has_attachment": True, }, { "from": "newsletter@example.com", "subject": "이번 주 생산성 도구 모음", "days_old": 45, "has_attachment": False, },
] def recommend_action(email): if "client" in email["from"] or "견적" in email["subject"]: return { "label": "고객/견적", "action": "keep", "reason": "고객 요청 또는 견적 관련 메일은 자동 이동하지 않음", } if email["days_old"] > 30 and not email["has_attachment"]: return { "label": "뉴스레터 후보", "action": "review_archive", "reason": "오래된 메일이지만 보관 전 사람 확인 필요", } return { "label": "검토 필요", "action": "review", "reason": "자동 판단 기준에 충분히 맞지 않음", } for email in emails: result = recommend_action(email) print(email["subject"], "=>", result)

여기서 핵심은 archive를 바로 실행하지 않는다는 점이다. review_archive처럼 사람의 승인이 필요한 상태로 남겨둔다.

AI에게 프롬프트를 줄 때도 같은 구조를 쓰면 된다.

너는 메일 정리 보조자다. 입력:
- 메일 제목
- 보낸 사람
- 받은 날짜
- 첨부파일 여부
- 기존 라벨 출력:
- 추천 라벨
- 추천 행동
- 그렇게 판단한 이유 금지사항:
- 메일 삭제 금지
- 고객/계약/결제/견적 관련 메일 자동 이동 금지
- 외부 발송 금지 완료 기준:
- 먼저 샘플 20개만 분류한다.
- 사람이 승인하기 전에는 실제 메일함에 적용하지 않는다.
- 애매한 메일은 반드시 "검토 필요"로 표시한다.

이렇게 쓰면 AI가 “정리”라는 말을 자기 방식대로 해석할 여지가 줄어든다. AI에게 친절하게 설명하는 게 아니라, 사고가 날 수 있는 길목에 표지판을 세우는 것이다.

테스트 체크리스트

• 삭제, 전송, 이동 같은 되돌리기 어려운 행동이 기본 금지되어 있는가?
• 고객, 계약, 결제, 견적 관련 메일이 자동 처리 대상에서 빠져 있는가?
• 샘플 처리와 전체 적용 단계가 분리되어 있는가?
• AI가 추천한 이유를 사람이 읽을 수 있는가?
• 애매한 메일을 억지로 분류하지 않고 “검토 필요”로 남기는가?
• 실행 전 미리보기 표가 만들어지는가?
• 사람이 승인하기 전에는 실제 메일함에 아무 변화도 생기지 않는가?

흔한 실수

첫 번째 실수는 “정리”라는 말을 너무 믿는 것이다. 사람에게는 정리가 대충 통하지만, AI에게는 너무 넓다. 정렬인지, 삭제인지, 보관인지, 라벨링인지, 요약인지 먼저 나눠야 한다.

두 번째 실수는 출력 형식을 안 정하는 것이다. AI가 결과를 문장으로 주면 읽기에는 좋아도 검수하기 어렵다. 표 형태로 추천 라벨, 추천 행동, 이유, 확신도, 검토 필요 여부를 받는 편이 낫다.

세 번째 실수는 바로 실행시키는 것이다. 자동화의 첫 단계는 실행이 아니라 미리보기여야 한다. 특히 메일, 파일, 고객 데이터처럼 되돌리기 어려운 대상은 한 번 더 느리게 가는 쪽이 빠르다.

마지막 실수는 “AI가 알아서 물어보겠지”라고 생각하는 것이다. 대부분의 AI 도구는 모르면 멈추는 쪽보다, 그럴듯하게 이어가는 쪽으로 움직인다. 그래서 모를 때의 행동까지 사람이 정해야 한다.

짧은 엔딩

그날 이후 팀장은 차은에게 일을 시킬 때마다 네 줄을 먼저 적었다.

입력은 무엇인지. 출력은 무엇인지. 하면 안 되는 일은 무엇인지. 끝났다고 봐도 되는 기준은 무엇인지.

차은은 어느 날 물었다.

“그럼 저는 이제 메일을 정리해도 될까요?”

지현이 대답했다.

“아니. 일단 정리 계획부터 정리해줘.”

팀장은 그 말을 듣고 고개를 끄덕였다.

“좋아. 이제 우리 쪽이 조금 똑똑해진 것 같네.”

참고 자료

• Microsoft Learn - Prompt engineering techniques (본문 인용)
• Microsoft Learn - System message design for Azure OpenAI (본문 인용)
• Google Machine Learning Crash Course - Prompt engineering (본문 인용)
• Microsoft Learn - Prompt engineering with GitHub Copilot (추가 참고)
• Microsoft Learn - Prompt engineering concepts for .NET (추가 참고)