“입금 계좌가 바뀌었습니다” 국내 기업의 거래처 사칭메일 사례

국내 기업도 익숙한 거래처의 계좌 변경 요청에 피해를 입었습니다

KOTRA 리스본무역관은 2025년 3월 13일 포르투갈 계좌를 이용한 무역사기 사례를 발표했습니다. 현지에서 파악한 국내 기업 피해는 2024년 12건, 2025년 2월까지 2건이었습니다. 이는 해당 자료의 집계이며 국내 전체 사칭메일 피해 통계는 아닙니다.

자료에는 거래처와 한 글자 정도 다른 이메일 주소의 요청을 믿고 송금한 기업이 등장합니다. 예전에도 거래처 계좌가 바뀐 적이 있어 의심하지 않았다고 합니다. 또 다른 기업은 평소와 같은 주소로 요청을 받아 송금했으며, 이후 진짜 거래처의 미입금 연락을 받고 이메일 해킹 사실을 알게 됐다고 자료는 설명합니다. 5년 이상 거래한 업체의 계좌 변경 요청을 믿었다가, 추가 송금을 요구받은 뒤 이상을 확인한 사례도 있습니다. KOTRA 공개 자료 · 2025-03-13 ↗

이 사례에서 배울 점은 계좌 변경이 드문 일인지보다 변경을 확인하는 근거가 무엇이었는지에 있습니다. 과거에 계좌를 바꾼 사실은 이번 요청이 진짜라는 증거가 되지 않습니다.

‘거래처가 보낸 것처럼 보인다’에도 여러 경우가 있습니다

이런 사기를 흔히 BEC(Business Email Compromise), 업무 이메일 사기라고 부릅니다. 익숙한 회사나 담당자를 내세워 송금 같은 업무 행동을 유도하는 방식입니다. 이름에 이메일 침해라는 뜻이 들어가지만, 모든 사건에서 피해 기업의 메일 계정이 해킹된 것은 아닙니다. 비슷한 주소만 이용하는 경우도 있습니다. FBI의 BEC 설명 ↗

메일 앱은 보낸 사람의 이름을 크게, 실제 주소를 작게 보여주기도 합니다. 이름이 같다고 주소가 같은 것은 아닙니다. 주소가 같아 보여도 실제 계정에서 발송됐는지는 별도 문제입니다. 다음 표는 조사할 때 나누어 볼 유형이며, 앞의 세 기업을 각각 여기에 배정한 것은 아닙니다.

표의 두 번째와 세 번째는 화면만 보고 구분할 수 없습니다. 같은 주소로 왔다는 이유만으로 계정 탈취를 확정하면 안 됩니다. 메일 관리자가 원본과 로그를 확인해야 합니다. 유사 주소 역시 어느 글자가 달랐는지에 따라 조사 내용이 달라지며, KOTRA 자료만으로 주소의 정확한 구조를 재구성할 수는 없습니다.

DMARC가 확인하는 것은 계좌의 주인이 아닙니다

DMARC는 메일의 From 도메인, 즉 보낸 사람 주소의 @ 뒤 부분을 확인합니다. 발신 서버를 검사하는 SPF나 전자서명을 검사하는 DKIM 중 하나가 통과하고, 그 인증 도메인이 From 도메인과 맞아야 통과합니다. 이 관계를 도메인 정렬이라고 합니다. 다른 서버가 회사 도메인을 도용해 보내는 메일을 막는 근거가 됩니다.

공격자가 별도의 유사 도메인을 쓰거나 탈취한 정상 계정으로 보내면 인증이 통과할 수도 있습니다. DMARC는 담당자 이름이나 계좌번호의 정당성을 검사하지 않습니다. DMARC 표준의 사칭 대응 범위 ↗

또한 우리 회사가 DMARC를 설정했다고 거래처 도메인을 도용한 모든 메일이 차단되는 것은 아닙니다. 우리 설정은 주로 우리 도메인을 적어 보낸 메일에 대한 방침입니다. 거래처가 보낸 메일을 받을 때는 상대 도메인의 인증과 우리 수신 서비스의 보안 판단이 적용됩니다. 인증 통과 여부와 지급 승인을 한 항목으로 합치지 않아야 합니다.

청구 금액이 맞아도 새 계좌는 아직 확인되지 않았습니다

계좌 변경 요청이 어려운 이유는 메일의 모든 내용이 틀려야 사기가 되는 것이 아니기 때문입니다. 실제 진행 중인 거래의 이름과 금액이 맞으면 담당자는 남은 정보도 맞을 것이라고 받아들이기 쉽습니다. 그러나 발주 내용과 수취 계좌는 서로 다른 정보입니다.

첫 번째 확인을 끝냈다고 두 번째도 끝나는 것은 아닙니다. 물품을 실제로 받았고 지급해야 할 금액이 맞아도, 새 계좌가 그 공급업체의 것이라는 근거는 아직 없을 수 있습니다. 반대로 계좌가 맞아도 청구 대상이나 금액이 다르면 지급을 승인할 수 없습니다.

두 사람이 결재하는 절차도 이 구분이 있어야 도움이 됩니다. 구매 담당자와 재무 담당자가 같은 메일을 읽고 “거래처가 보냈으니 맞겠지”라고 판단했다면 확인 근거는 여전히 하나입니다. 두 번째 담당자는 앞사람의 결론보다 누가, 어떤 연락처로, 무엇을 확인했는지를 볼 수 있어야 합니다.

‘기존 연락처’도 출처를 확인하세요

이번 요청이 오기 전에 등록하고 검증한 계약서나 거래처 관리대장의 번호를 사용합니다. 새 메일 서명에 적힌 전화번호, 첨부 공문에만 있는 번호, 의심 메일에 답장해서 받은 번호는 확인 경로로 삼기 어렵습니다. 요청을 보낸 사람이 확인할 상대까지 지정할 수 있기 때문입니다.

기존 담당자가 퇴사했거나 번호가 바뀌었다면 새 연락처 확인부터 다시 진행합니다. 이전에 검증한 회사 대표번호 등으로 담당 부서와 연결하고 변경 권한을 확인할 수 있습니다. 연락이 되지 않는 동안에는 계좌 변경을 보류합니다. 시차나 지급 기한 문제는 거래 담당자에게 알려 조율하되, 미확인을 승인으로 바꾸지 않습니다.

계좌 변경 한 건을 접수부터 결정까지 따라가 보겠습니다

1. 담당자는 변경 요청을 접수하고 지급 정보를 그대로 둡니다

구매 담당자는 메일을 받자마자 거래처 관리대장의 계좌를 덮어쓰지 않습니다. 기존 값과 요청받은 값을 나란히 남기고, 해당 지급 건을 ‘계좌 변경 확인 중’으로 표시합니다. 재무팀에도 보류 사유를 알려 기존 예약 송금이나 다른 담당자의 수동 지급이 진행되지 않도록 확인합니다.

여기서 계좌 변경 검토와 이미 승인된 청구서 검토를 연결합니다. 변경 요청을 처리하는 동안 같은 청구서가 재접수되어 이중으로 지급되지 않도록 발주번호·청구서 번호·지급 상태를 함께 확인합니다. ‘급하니 먼저 보내고 나중에 확인’이라는 예외를 만들지 않는 것이 핵심입니다.

2. 별도로 확보한 연락처에서 변경 요청을 확인합니다

담당자는 거래처 관리대장에 등록된 전화번호로 전화를 겁니다. 메일 속 번호를 사용하지 않습니다. 기존 거래를 담당하는 직원과 연결되면 “발주번호에 해당하는 이번 지급의 은행 계좌를 변경했나요?”라고 묻습니다. 실제로 변경했다는 답을 받으면 수취인 명칭, 은행명·국가, 계좌번호 또는 IBAN, 적용 시점까지 대조합니다.

IBAN은 일부 국가에서 사용하는 국제 은행 계좌번호입니다. 안내문과 번호 형식이 그럴듯한지만 볼 것이 아니라, 검증한 거래처가 그 지급 정보를 확인했는지가 중요합니다. 확인 과정에서는 전체 번호를 대조하고, 사내 기록의 열람 범위는 지급 담당 업무에 맞게 제한합니다.

이 예시에서 기존 담당자는 계좌를 변경한 적이 없다고 답합니다. 그러면 새 계좌로의 변경을 거부하고 송금을 멈춥니다. 거래처에 의심 메일을 알리며, 실제 청구서와 지급 계획은 별도 확인한 경로에서 다시 정리합니다. 계좌번호만 원래대로 돌리고 곧바로 송금하는 것으로 확인을 끝내지 않습니다.

3. 승인자가 판단할 수 있는 기록을 남깁니다

단순히 ‘전화 확인 완료’라고 쓰면 다음 담당자는 무엇이 확인됐는지 알 수 없습니다. 요청 내용, 연락처의 출처, 상대방과 확인 결과를 함께 적어야 합니다. 가온무역의 기록을 간단히 정리하면 아래와 같습니다.

지급 건: 기존 발주에 대한 미화 20,000달러 청구
요청: 이번 지급부터 다른 은행 계좌 사용
연락처 출처: 요청 전부터 관리하던 거래처 관리대장
확인 상대: 기존 공급업체 담당자
확인 내용: 은행·계좌 변경 요청 여부
확인 결과: 거래처가 변경 요청을 부인함
처리: 새 계좌 등록 거부, 관련 지급 보류
후속 담당: 재무팀은 지급 상태 확인, IT는 원본 조사

실제 기록에는 확인 일시와 담당자, 연결한 번호, 관련 문서 위치도 남깁니다. 승인자는 연락처가 이번 메일에서 나온 것은 아닌지, 계좌 변경을 확인할 권한이 있는 상대였는지, 확인 결과가 최종 지급 화면과 맞는지를 검토합니다. 확인 업무와 지급 승인 업무를 나누기 어려운 작은 조직이라면 대표나 다른 책임자가 그 근거를 함께 검토하도록 정할 수 있습니다.

4. 확인 결과에 따라 승인·보류·거부를 나눕니다

마지막 줄은 전화 한 통으로 자동 승인한다는 뜻이 아닙니다. 확인한 수취인과 실제 등록한 계좌를 다시 대조하고, 해당 청구의 금액·지급 기한·중복 여부까지 확인해야 합니다. 계좌 변경을 승인한 사람이 누구인지도 남겨 다음 지급 때 같은 정보를 재사용할 근거를 만듭니다.

FBI도 지급 정보 변경을 전화 등으로 별도 확인하고, 의심 요청이 제공한 연락처를 그대로 사용하지 않도록 안내합니다. 위 예시는 이 원칙을 구매·재무 담당자가 실제로 처리할 수 있는 기록과 결정 과정으로 풀어낸 것입니다. FBI 예방 안내 ↗

이미 송금했다면 원인 분석이 끝나기 전에 은행에 연락하세요

사기인지 완전히 입증될 때까지 기다리면 안 됩니다. 사기가 의심되는 송금을 했다면 거래은행에 즉시 알리고, 지급정지·반환 요청 등 가능한 절차를 문의합니다. 송금 일시·금액·통화, 송금 확인번호, 수취 은행과 계좌 정보를 준비하고 수사기관 신고도 진행합니다. 자금이 이동한 상태와 관련 기관의 처리에 따라 결과가 달라지므로 회수를 보장할 수는 없습니다. FBI의 즉시 금융기관 연락 권고 ↗

추가 송금 요청과 아직 실행되지 않은 관련 지급도 함께 보류합니다. 은행에 연락할 담당자, 거래처와 연락할 담당자, 메일을 조사할 담당자를 정하면 같은 메일을 돌려보며 다음 결정을 기다리는 시간을 줄일 수 있습니다. 금액을 돌려받게 해주겠다며 새 수수료나 다른 계좌 송금을 요구하는 연락 역시 기존 경로에서 다시 확인해야 합니다.

재무팀은 지급 기록을, IT 담당자는 원본을 보존합니다

메일 화면의 캡처만 남기지 말고 원본 이메일과 헤더, 첨부파일, 대화 내역, 송금 자료를 보존합니다. 헤더는 메일의 발송 경로와 인증 결과를 살펴볼 수 있는 정보입니다. 일반 전달만 하면 조사에 필요한 일부 정보가 빠질 수 있으므로 메일 서비스의 원본 다운로드 기능이나 관리자의 안내를 이용합니다. 증거를 확보하느라 은행 연락이 늦어지지 않도록 두 작업은 함께 진행합니다.

계정 침해가 의심된다면 관리자는 로그인 기록, 자동 전달·받은편지함 규칙, 발송 내역, 연결된 앱의 접근 권한을 점검합니다. 침해가 확인되면 세션과 접근 권한을 정리하고 인증 수단을 복구하는 조치가 필요합니다. 비밀번호 변경만으로 조사가 끝난다고 생각하지 않는 편이 좋습니다. 구체적인 순서는 사용 중인 메일 서비스의 사고 대응 안내를 따릅니다. Microsoft의 침해 계정 대응 안내 ↗

이후 우리 주소가 다른 곳에 악용되는 위험은 발신처 목록과 SPF·DKIM·DMARC 점검으로 줄여 갑니다. 거래처에 돈을 보내는 업무에는 별도로 검증한 연락처와 계좌 변경 기록을 갖춥니다. 다음 요청이 도착했을 때 담당자가 찾을 수 있어야 할 것은 ‘조심하라’는 공지보다 확인할 연락처와 확인이 끝나기 전 보류할 수 있는 절차입니다.