이메일 주소 12개를 하나씩 눈으로 찾지 않아도 됩니다. 원본 열을 그대로 둔 채 ChatGPT에 판정 규칙과 원하는 표 모양을 알려 주면, 먼저 확인할 행을 빠르게 나눌 수 있습니다. 이 글에서는 실제 개인정보가 아닌 example.com 계열의 가상 주소만 사용해 정상 후보 6개, 앞뒤 공백 수정 1개, 형식 수정 필요 5개를 직접 찾아봅니다.
먼저 기억할 30초 결론
- 원본 보존:
email_raw는 바꾸지 않고 정리값을 새 열에 만듭니다. - 기초 판정: OK, TRIM, FIX 세 가지만 사용합니다.
- 검산값: 전체 12행, OK 6행, TRIM 1행, FIX 5행입니다.
- 중요한 한계: OK는 실제 메일함이 있거나 메일을 받을 수 있다는 뜻이 아닙니다.
실습 파일부터 내려받기
처음에는 정답을 보지 말고 연습 CSV와 빈 판정표로 시작하세요. 결과를 만든 뒤 정답 CSV와 개수를 비교하면 ChatGPT 답을 그대로 믿지 않고 스스로 검산할 수 있습니다.
모든 주소는 문서 예시용으로 예약된 example.com, example.net, example.org만 사용했습니다. 실제 고객, 구독자, 직원의 이메일은 들어 있지 않습니다.
이 글에서 확인하는 것은 ‘기초 형식’입니다
이메일 주소를 아주 단순하게 보면 @ 앞부분, @ 기호, 도메인으로 나뉩니다. RFC 5322도 주소 형식의 핵심을 local-part "@" domain으로 표현합니다. 예를 들어 alpha@example.com에서는 alpha가 로컬 부분이고 example.com이 도메인입니다.
하지만 인터넷 이메일 문법 전체는 훨씬 복잡합니다. 따옴표, 주석, 국제화, 도메인 리터럴처럼 초보자용 한 번의 표 점검으로 다루기 어려운 경우가 있습니다. 그래서 이번 실습은 RFC 전체를 구현하지 않습니다. 우리가 찾을 것은 다음 다섯 가지뿐입니다.
- 주소 앞이나 뒤에 공백이 있는지
- @가 정확히 한 개인지
- @ 앞부분이 비어 있지 않은지
- 도메인 부분이 비어 있지 않고 점이 하나 이상 있는지
- 도메인에 연속 점
..이 없는지
이 기준에 걸리지 않으면 이번 표에서는 OK로 둡니다. 여기서 OK는 이번 기초 규칙에서 수정할 항목을 찾지 못했다는 뜻일 뿐입니다. 실제 메일함 존재, 오타 없는 실사용 주소, 수신 가능 여부를 증명하지 않습니다.
OK, TRIM, FIX를 먼저 구분하세요
| 판정 | 뜻 | 이번 실습 예 | 다음 행동 |
|---|---|---|---|
| OK | 기초 규칙에서 수정 항목 없음 | alpha@example.com |
필요하면 별도 수신 확인 |
| TRIM | 앞뒤 공백만 제거하면 됨 | beta@example.com[공백] |
새 열에 공백 제거값 기록 |
| FIX | 정해 둔 형식 문제 발견 | gamma.example.com |
실제 값을 추측하지 말고 원본 시스템 확인 |
TRIM과 FIX를 나누는 이유는 처리 방법이 다르기 때문입니다. 앞뒤 공백은 원문을 보존한 상태에서 기계적으로 제거할 수 있습니다. 반면 @가 빠진 주소의 실제 값은 알 수 없습니다. gamma.example.com을 보고 어디에 @를 넣을지 ChatGPT가 추측하게 만들면, 그럴듯하지만 틀린 개인정보를 새로 만들 수 있습니다.
연습 CSV 12행 미리 보기
| ID | email_raw | 찾아볼 점 |
|---|---|---|
| E-01 | alpha@example.com |
기초 형식 |
| E-02 | beta@example.com[뒤 공백] |
눈에 잘 안 보이는 공백 |
| E-03 | gamma.example.com |
@ 개수 |
| E-04 | delta@@example.com |
@ 개수 |
| E-05 | echo@ |
도메인 |
| E-06 | @example.com |
로컬 부분 |
| E-07 | foxtrot@example..com |
연속 점 |
| E-08~E-12 | 예약 예시 도메인의 서로 다른 가상 주소 | +와 밑줄을 이유 없이 오류로 잡는지 |
ChatGPT 파일 실습 6단계
1단계: 원본 파일을 복사합니다
연습에서는 내려받은 CSV를 그대로 써도 되지만, 실제 업무라면 먼저 사본을 만드세요. 이름은 contacts_original.csv와 contacts_working.csv처럼 구분합니다. 원본을 덮어쓰지 않아야 판정이 잘못됐을 때 바로 비교하고 되돌릴 수 있습니다.
2단계: 열 이름과 행 수를 확인합니다
CSV를 열어 contact_id와 email_raw 두 열이 있는지 봅니다. 데이터 행은 헤더를 제외하고 12개여야 합니다. CSV 파일을 처음 다룬다면 ChatGPT에 CSV 올리고 열 이름 확인하기를 먼저 따라 해도 좋습니다.
3단계: ChatGPT에 CSV와 질문문을 보냅니다
새 대화에서 연습 CSV를 첨부하고, 내려받은 질문문 내용을 붙여 넣습니다. OpenAI의 프롬프트 안내처럼 목표, 맥락, 원하는 출력, 경계를 나눠 적으면 무엇을 해야 하고 무엇을 하지 말아야 하는지가 분명해집니다.
목표: email_raw를 OK, TRIM, FIX로 분류해 주세요. 원본: email_raw는 바꾸지 마세요. 출력: contact_id, email_raw, decision, reason, email_trimmed 순서의 CSV로 만들어 주세요. 규칙: 앞뒤 공백만 있으면 TRIM, @ 개수·양쪽 값·도메인 점·연속 점 문제는 FIX입니다. 경계: + 기호만으로 오류 처리하지 말고, 실제 주소를 추측해 고치지 마세요. 검산: 총 12행, OK 6행, TRIM 1행, FIX 5행인지 마지막에 알려 주세요.
4단계: 결과 표를 먼저 화면에서 봅니다
파일을 바로 내려받기 전에 다섯 열이 모두 있는지 확인합니다. email_raw와 email_trimmed가 따로 있어야 합니다. 원본 열이 사라졌거나 값이 임의로 수정됐다면 “원본 열을 복원하고 새 열에만 정리값을 적어 달라”고 요청하세요.
5단계: 12와 6·1·5를 직접 셉니다
ChatGPT가 “검사가 끝났다”고 말하는 것보다 ID와 개수를 확인하는 편이 더 중요합니다. E-01부터 E-12가 하나씩 있는지, 중복이나 누락이 없는지, 판정 개수가 OK 6·TRIM 1·FIX 5인지 확인합니다. 이 세 숫자가 다르면 어떤 ID가 달라졌는지 정답 CSV와 비교합니다.
6단계: 결과 파일을 내려받고 별도 이름으로 저장합니다
OpenAI의 파일 작업 안내는 원하는 파일 형식과 구조, 검토 기준을 알려 주고 결과물을 확인하거나 내려받아 다시 피드백하는 흐름을 설명합니다. 결과가 맞으면 email_review_result.csv처럼 원본과 다른 이름으로 저장하세요. 생성된 파일을 미리 보고 수정하고 내려받는 기본 흐름은 ChatGPT 생성 파일 미리보기·수정·다운로드에서 더 자세히 볼 수 있습니다.
정답과 비교하기
| ID | 판정 | 이유 | 처리 |
|---|---|---|---|
| E-01 | OK | 기초 규칙에서 문제 없음 | 그대로 |
| E-02 | TRIM | 뒤 공백 1칸 | 새 열에서만 제거 |
| E-03 | FIX | @ 누락 | 원본 확인 |
| E-04 | FIX | @가 2개 | 원본 확인 |
| E-05 | FIX | 도메인 누락 | 원본 확인 |
| E-06 | FIX | 로컬 부분 누락 | 원본 확인 |
| E-07 | FIX | 도메인 연속 점 | 원본 확인 |
| E-08~E-12 | OK 5개 | 기초 규칙에서 문제 없음 | 그대로 |
성공 기준: ID 12개가 모두 남아 있고, 판정은 OK 6개·TRIM 1개·FIX 5개입니다. E-02의 email_raw에는 뒤 공백이 보존되고 email_trimmed에서만 제거돼야 합니다. FIX 다섯 행은 그럴듯한 주소로 자동 교체하지 않습니다.
실패 화면: + 기호만 보고 오류로 바꾼 경우
hotel+news@example.com에는 + 기호가 있습니다. 이번에 고정한 다섯 규칙에는 “+가 있으면 FIX”가 없습니다. 그런데 모델이 익숙하지 않은 모양이라는 이유만으로 FIX를 붙이면 정상 후보까지 바뀝니다.
이때는 “내가 제공한 기준에 있는 항목만 적용하고, 추가 규칙을 사용했다면 별도 열에 제안으로 표시해 달라”고 다시 요청하세요. 정답을 맞히는 것만큼 판정 범위를 함부로 넓히지 않는 것이 중요합니다. 실제 운영 규칙에 + 주소를 금지하는 별도 정책이 있다면, 그때는 회사 규칙을 명시하고 새 검산값을 만들어야 합니다.
ChatGPT 답이 달라졌을 때 고치는 질문 5개
- 행이 12개가 아닐 때: “E-01부터 E-12까지 누락·중복 ID를 목록으로 보여 주세요.”
- 원본 열이 바뀌었을 때: “email_raw는 입력 그대로 복원하고, 수정값은 email_trimmed에만 적어 주세요.”
- + 주소를 FIX로 잡았을 때: “+ 기호만으로 오류 처리하지 않는다는 경계를 다시 적용해 주세요.”
- FIX 값을 추측했을 때: “확인할 수 없는 실제 주소를 만들지 말고 reason에 문제만 기록해 주세요.”
- 개수가 다를 때: “OK 6, TRIM 1, FIX 5와 다른 ID만 비교표로 보여 주세요.”
빈 행이나 중복 행이 함께 섞여 있다면 이번 실습과 규칙이 달라집니다. 먼저 CSV 빈 행·중복 행 찾기로 구조 문제를 정리한 뒤 이메일 열을 점검하세요. 숫자가 문자로 저장된 문제라면 CSV 문자형 숫자 정리 실습처럼 열에 맞는 별도 기준이 필요합니다.
왜 OK가 ‘메일을 받을 수 있음’은 아닌가요?
문법처럼 보이는 것과 실제 존재하는 것은 다른 문제입니다. someone@example.com이 @와 도메인을 갖췄다고 해도 누군가 실제로 그 메일함을 사용한다는 뜻은 아닙니다. 도메인이 존재하더라도 특정 계정이 없을 수 있고, 계정이 있어도 오타 난 다른 사람의 주소일 수 있으며, 서버 정책 때문에 메일이 반송될 수도 있습니다.
그래서 이번 결과의 OK는 기초 형식 점검 통과 후보로 읽습니다. 실제 서비스에서는 회원이 보낸 인증 링크를 누르게 하거나, 조직이 승인한 방식으로 반송 결과를 관리하거나, 담당자가 원본 시스템과 대조하는 별도 절차가 필요합니다. 무단으로 확인 메일을 대량 전송하거나 수집한 주소를 다른 목적으로 쓰면 안 됩니다.
실제 연락처를 다룰 때 개인정보부터 줄이기
이번 CSV는 예약 예시 도메인이라 그대로 연습할 수 있습니다. 실제 고객 CSV에는 이메일만으로도 개인을 식별하거나 연락할 수 있는 정보가 들어갈 수 있습니다. 이름, 전화번호, 주소, 주문번호가 함께 있으면 위험은 더 커집니다.
- 조직의 AI 사용 정책과 허용 계정을 먼저 확인합니다.
- 실제 이메일 원문이 꼭 필요한지 묻습니다. 형식 연습이라면 가상 데이터로 바꿉니다.
- 이름, 전화번호, 주소, 고객번호 등 불필요한 열을 제거합니다.
- 업로드 전 원본을 안전한 위치에 백업하고 작업용 사본만 사용합니다.
- 결과를 공유할 때도 이메일 원문이 화면 캡처와 보고서에 남지 않게 확인합니다.
실제 정보를 붙여넣기 전 가리는 순서는 이름·전화번호·이메일 10문장 가리기 실습에서 먼저 연습할 수 있습니다.
공식 자료 두 종류를 어떻게 비교했나요?
이 글은 서로 역할이 다른 자료를 나눠 사용했습니다. OpenAI의 안내는 ChatGPT에 파일을 주고 결과물을 만드는 작업 방법의 근거입니다. 목표와 출력, 경계를 분명히 적고, 결과 파일을 확인·다운로드한 뒤 수정 요청을 이어가는 흐름을 참고했습니다.
RFC 5322는 이메일 주소 문법에서 로컬 부분과 @, 도메인이 어떻게 연결되는지 확인하는 기술 형식의 근거입니다. RFC 2606은 독자 실습에 실제 주소 대신 example.com, example.net, example.org를 쓰는 이유를 뒷받침합니다.
둘 중 하나만으로는 이 글을 만들기 어렵습니다. ChatGPT 사용법 문서는 이메일 전체 문법의 표준이 아니고, 이메일 표준은 ChatGPT 파일 결과를 어떻게 검산할지 알려 주지 않습니다. 그래서 제품 사용 안내와 인터넷 표준을 분리해 읽고, 자체 제작 12행 정답으로 결과를 다시 확인했습니다.
적용 과정에서 생기는 질문
엑셀 파일도 같은 방식으로 할 수 있나요?
가능하지만 처음에는 열이 두 개인 CSV가 더 단순합니다. 엑셀 파일에 여러 시트, 병합 셀, 수식, 숨김 열이 있으면 먼저 어떤 시트와 열을 볼지 지정하세요. 결과를 새 파일로 받을 때는 원본 수식과 서식이 유지됐는지 별도로 확인해야 합니다.
공백을 원본 열에서 바로 지워도 되나요?
연습 단계에서는 권하지 않습니다. 원본 email_raw를 남기고 email_trimmed를 새로 만들어야 무엇이 달라졌는지 확인하고 되돌릴 수 있습니다. 최종 시스템 반영은 검수 후 별도 절차로 진행하세요.
정규식 하나면 모든 이메일을 검증할 수 있나요?
이번 글은 그런 주장을 하지 않습니다. 이메일 문법과 실제 사용 환경에는 복잡한 예외가 있습니다. 간단한 정규식은 빠른 1차 후보 분류에는 쓸 수 있지만 RFC 전체 준수나 메일함 존재를 보장하지 않습니다.
ChatGPT가 FIX 주소를 직접 고쳐 주면 편하지 않나요?
실제 값의 근거가 없다면 위험합니다. @가 빠졌다는 사실은 알 수 있어도 정확히 어디에 들어가야 하는지는 알 수 없습니다. FIX는 자동 교체 목록이 아니라 사람이 원본을 다시 확인할 목록으로 사용하세요.
OK 행도 다시 확인해야 하나요?
업무 영향이 크다면 확인해야 합니다. 이번 OK는 정해 둔 다섯 기초 규칙을 통과했다는 뜻입니다. 가입 인증, 결제 알림, 계약 통지처럼 중요한 발송은 승인된 인증·반송 관리 절차와 사람 검토를 사용하세요.
내 결과가 6·1·5가 아니면 실패인가요?
이 연습 파일에서는 원인을 찾아야 한다는 신호입니다. 실제 데이터에서는 정답 개수가 미리 정해져 있지 않으므로, 샘플 일부를 사람이 판정해 기준 사례를 만들고 전체 행 수·ID 보존·판정 누락 0개 같은 검산 항목을 사용하세요.
실습 완료 체크
- 연습 CSV와 빈 판정표를 내려받았습니다.
email_raw를 바꾸지 않고 새 열을 만들었습니다.- E-01부터 E-12까지 12개 ID가 남아 있습니다.
- OK 6개, TRIM 1개, FIX 5개를 확인했습니다.
- E-09의 + 기호를 이유 없이 오류로 처리하지 않았습니다.
- FIX 주소를 추측해 새 값으로 바꾸지 않았습니다.
- OK가 메일함 존재와 수신 가능을 보장하지 않는다고 기록했습니다.
현재 안내의 한계
이 글의 분류 규칙은 초보자가 작은 CSV에서 흔한 입력 실수를 찾도록 만든 교육용 기준입니다. RFC 5322 전체 문법 검사기, DNS 검사기, 발송 가능성 검사기, 개인정보 보호 자문을 대신하지 않습니다. 실제 서비스의 허용 문자와 도메인 정책은 조직마다 다를 수 있으므로 운영 규칙을 먼저 확인하세요.
ChatGPT의 파일 업로드 화면, 생성 파일 미리보기와 다운로드 방식은 제품 버전과 계정에 따라 달라질 수 있습니다. 이 글은 2026년 8월 23일 확인한 공식 학습 문서를 기준으로 했습니다. 화면이 다르면 현재 제품 안내를 우선하고, 중요한 데이터는 승인된 도구에서만 처리하세요.
공식·기술 출처
- OpenAI – Prompting
- OpenAI – Work with files
- RFC Editor – RFC 5322 Internet Message Format
- RFC Editor – RFC 2606 Reserved Top Level DNS Names
작성: AI플레이집 편집팀
검토: Codex 근거·실습 자산 검수
사실 확인일: 2026년 8월 23일
AI 사용 고지: 공식 자료 조사, 초안 구성, 전용 3D 이미지와 가상 CSV·정답·교육 화면 제작에 AI 도구를 사용했습니다. 출처 역할 구분, 정답 CSV 12행과 6·1·5 개수, 예약 예시 도메인 사용, 이미지 원본 시각 검수, 자산 8개와 내부 링크는 별도로 확인했습니다.
오류나 변경된 기능을 발견하면 정정 정책의 절차로 알려 주세요.