도메인 오판, AI 업무 에이전트의 신원 리스크

이메일 설정 오류가 AI 뉴스인 이유

Hacker News에 오른 Google Workspace thinks my domain is an email provider는 겉으로 보면 개인 도메인과 Google Workspace 설정이 충돌한 운영 기록이다. 그러나 업무용 AI 에이전트가 메일함, 캘린더, 문서, CRM, 코드 저장소까지 연결되는 지금은 단순한 이메일 장애로만 보기 어렵다. 에이전트가 누가 누구인지, 어떤 주소가 조직의 신뢰 경계 안에 있는지, 어떤 메일이 내부 요청인지 판단하는 기반은 여전히 도메인과 계정 체계다.

Google은 Workspace에서 도메인 소유권 확인, MX 레코드, 사용자 계정, 별칭을 연결한다. Google Workspace 도메인 설정 문서는 조직 도메인의 소유권과 서비스 연결을 별도 단계로 다룬다. Gmail 인증 가이드는 SPF, DKIM, DMARC를 통해 발신자를 검증하라고 말한다. 이 계층이 꼬이면 사람은 우회로를 찾지만, 에이전트는 잘못된 신호를 규칙처럼 받아들일 수 있다.

에이전트는 신원 인프라를 더 크게 증폭한다

업무 에이전트가 이메일을 읽고 답장을 작성하는 단계에서는 주소록 오류가 불편함에 그친다. 하지만 에이전트가 견적서를 전달하고, 초대 링크를 만들고, 외부 협력사와 일정을 잡고, 승인 워크플로를 자동 실행한다면 도메인 오판은 권한 문제로 변한다. 잘못 분류된 도메인은 내부자처럼 취급되거나, 반대로 정상 사용자를 외부자로 밀어낼 수 있다.

ClaudeBot 사칭 스캔, 에이전트 웹의 신원 문제가 터졌다는 자동화된 행위자의 신원 확인이 웹의 새 병목이라고 봤다. 에이전트 승인 피로, 인간 방화벽은 새고 있다는 사용자가 반복 승인에 무뎌질 때 신뢰 경계가 약해진다고 분석했다. 암호화된 추론 흔적, API 보안 경계가 흔들렸다는 API 내부 흔적도 보안 자산이 된다고 봤다. 세 글의 공통점은 모델보다 주변 시스템의 신뢰 설계가 더 중요해지고 있다는 점이다.

한국 기업에는 도메인 거버넌스가 부족하다

한국 스타트업과 중견 기업은 빠르게 SaaS를 붙여 성장한다. 회사 도메인, 별도 제품 도메인, 채용 도메인, 고객지원 도메인, 테스트 도메인이 섞이고, 일부는 외주사나 과거 담당자 계정에 묶여 있다. 사람만 쓰는 환경에서는 이런 부채가 불편한 운영 문제로 남는다. 그러나 AI 에이전트가 Google Workspace, Slack, Notion, GitHub, 결재 시스템을 가로질러 일하면 도메인 부채는 자동화 부채가 된다.

NIST Digital Identity Guidelines는 디지털 신원 보증을 별도의 통제 대상으로 본다. 이메일 쪽에서는 RFC 7489 DMARC가 도메인 기반 메시지 인증과 보고를 표준화했다. 이 표준들은 새롭지 않지만, 에이전트가 등장하며 중요도가 다시 올라간다. AI 도입 체크리스트에 모델 벤치마크만 넣고 도메인, 메일 인증, 계정 수명주기를 빼면 실제 업무 흐름에서 사고가 난다.

경쟁 구도는 모델보다 안전한 연결로 이동한다

AI SaaS 경쟁은 한동안 더 좋은 모델, 더 긴 컨텍스트, 더 싼 토큰으로 설명됐다. 다음 국면은 연결의 안전성이다. Microsoft, Google, OpenAI, Anthropic, 스타트업형 에이전트 플랫폼 모두 기업 데이터를 연결하려면 신원과 권한을 설득해야 한다. 관리자는 "모델이 똑똑한가"보다 "이 에이전트가 누구 권한으로 무엇을 했는지 설명할 수 있는가"를 묻는다.

따라서 이메일 같은 오래된 프로토콜의 운영 사고는 AI 뉴스의 주변부가 아니다. 오히려 기업 AI가 실제 업무에 들어갈 때 가장 먼저 부딪히는 면이다. 국내 기업은 에이전트 도입 전에 도메인 소유권, SSO 그룹, 메일 인증, 서비스 계정, 퇴사자 계정 회수, 외부 협력사 도메인 목록을 한 번에 정리해야 한다. 그렇지 않으면 에이전트는 회사의 업무 속도를 높이는 대신 오래된 신원 혼선을 더 빠르게 실행한다.

자주 묻는 질문

Q1: 단순 Google Workspace 문제를 왜 AI 이슈로 보나요?

A: 업무 에이전트가 메일과 캘린더를 실행 도구로 쓰기 때문이다. 도메인과 계정 오판은 자동화된 권한 판단에 직접 영향을 준다.

Q2: 모든 회사가 DMARC를 강제해야 하나요?

A: 적어도 SPF, DKIM, DMARC 정책과 보고 주소는 점검해야 한다. 처음부터 강한 차단 정책을 적용하기보다 모니터링부터 시작하는 접근이 현실적이다.

Q3: 에이전트 전용 계정이 필요한 이유는 무엇인가요?

A: 사람 계정에 붙은 에이전트는 책임 추적이 어렵다. 별도 계정을 쓰면 권한, 로그, 중단, 회수를 분리할 수 있다.

Q4: 한국 기업이 가장 먼저 볼 항목은 무엇인가요?

A: 조직 도메인 소유권, MX 레코드, SSO 그룹, 공유 메일함, 외부 협력사 도메인 목록, 퇴사자 계정 회수 내역이다.

Q5: 모델 선택보다 이 작업이 우선인가요?

A: 대규모 업무 자동화에서는 그렇다. 모델은 교체할 수 있지만 잘못된 신원 인프라 위에 쌓인 권한은 사고가 날 때까지 보이지 않는다.