확인해야 할 것은 요청을 보낸 사람과 실행할 변경입니다
재무 담당자가 거래처의 평소 이메일 주소에서 계좌 변경을 받았다고 가정합니다. 발신 주소가 익숙하고 첨부된 양식에 회사 이름이 들어 있어도 거래처 메일 계정이 이미 침해됐을 수 있습니다. 조직 내 결재 계정이 유효한 경우에도 그 계정이 승인한 것이 최초 문서인지, 발송 직전에 바뀐 계좌인지 확인할 필요가 있습니다. 미국 FBI의 IC3는 합법적인 업무 이메일 계정을 침해해 자금 이체를 유도하는 BEC(Business Email Compromise)를 설명하고 계정 정보 변경은 두 번째 채널 등으로 확인하라고 권고합니다. FBI IC3 — Business Email Compromise[1]
같은 기관은 2024년 12월 공개 경고에서 생성형 AI를 사용한 문장·오디오·영상의 금융 사기 악용을 설명했습니다. 익숙한 문체나 음성을 그럴듯하게 재현할 수 있다는 경고입니다. 목소리의 떨림, 억양, 오탈자와 같은 단서는 담당자가 확인을 시작할 계기로 삼을 수 있습니다. 확인 단계를 적용할지는 그 단서보다 계좌 변경, 긴급 지급, 연락처 교체처럼 요청이 일으키는 상태 변경으로 판단합니다. 신뢰하던 내용이 합성됐는지 결론이 나지 않아도 미확인 변경을 보류할 근거는 충분합니다. FBI IC3 — Criminals Use Generative Artificial Intelligence to Facilitate Financial Fraud[2]
확인에 쓰는 두 번째 채널은 첫 채널의 변경으로 함께 넘어가면 효과가 줄어듭니다. 새 이메일에 첨부된 안내문의 전화번호, 회신 메일로 전달받은 메신저 계정, 요청 페이지가 띄운 채팅 버튼은 같은 출처에 의존할 수 있습니다. 거래처 등록 때 확인해 둔 대표번호, 기존 담당자의 검증된 연락처, 내부 디렉터리나 관리되는 결재 시스템처럼 요청과 독립적으로 신뢰할 수 있는 정보를 사용합니다. 전화로 받은 요청이라면 전화를 종료하고 내부 주소록의 알려진 번호로 새 통화를 시작합니다. 수신 화면에 찍힌 이름과 번호는 통화를 받는 단서로 사용할 수 있지만 그 자체로 변경 승인 증거가 되지는 않습니다.
신규 계좌와 확인 연락처를 한 번에 바꾸지 않습니다
마스터 데이터는 거래처의 법인 식별 정보, 승인된 수신 계좌와 확인 연락처처럼 이후 업무가 근거로 쓰는 값입니다. 신규 계좌와 연락처를 같은 건에서 바꾸고 새 연락처로 신규 계좌를 다시 확인하면, 처음 요청이 자기 증거를 만드는 형태가 됩니다. 첫 연락은 등록된 경로에서 시작하고 이전 담당자가 응답하지 않는 상황을 새로운 접수 절차로 전환하는 조건을 마련합니다. 등록 당시 확인 절차와 동등한 수준의 다른 경로를 쓰는 예로 이미 확인된 대표번호의 부서 연결이나 기존 거래 담당자의 인적 대조를 고려할 수 있습니다. 조직의 거래처 확인 정책과 계약 조건을 함께 적용합니다.
다음 표는 돈과 계정에 영향을 주는 업무를 분류하는 예입니다. 금액 기준은 조직에서 승인한 기준을 대입합니다. 새 계좌, 거래처 마스터 변경, 본인 확인 수단 변경처럼 후속 작업에 계속 영향을 주는 행동은 금액이 작더라도 별도 유형으로 둡니다.
| 요청 유형 | 요청과 독립된 확인 경로 | 승인자 또는 확인자 | 최소 기록 |
|---|---|---|---|
| 거래처 수신 계좌 신규 등록·변경 | 기존에 승인된 담당자 또는 대표번호에서 고객사 확인 담당으로 연결 | 거래처 마스터 관리자와 별도 재무 승인자 | 거래처·변경 건 ID, 이전·신규 계좌 참조, 확인 경로와 시각 |
| 기존 담당 연락처·메일 변경 | 변경 전 연락처 또는 승인된 거래처 재확인 경로 | 데이터 관리자와 거래처 업무 책임자 | 기존 확인 근거, 새 연락처 검증 결과, 적용 시점 |
| 대표·임원의 긴급 지급 | 내부 주소록이나 회사 결재 시스템으로 독립 확인 | 지급 승인 권한이 있는 업무 책임자와 집행 검토자 | 거래 목적·금액·계좌, 승인 당시 버전, 지급 결과 |
| 평소 거래처의 기존 계좌 지급 | 구매·검수·청구 기록과 등록 계좌의 일치 확인 | 기존 지급 결재 권한에 따름 | 계약·청구·지급 요청 ID, 검토 시각 |
| 재무 계정 복구나 인증 수단 재등록 | 등록된 내부 지원 요청과 권한 절차 | 신원 확인 담당자와 계정 관리자 | 변경 주체, 승인 참조, 인증 수단 교체·세션 처리 결과 |
| 기존 연락처가 전부 닿지 않는 신규 수신처 지급 | 사전에 승인한 재확인 또는 신규 등록 과정 | 지정된 재무·구매 책임자와 거래처 등록 담당 | 기존 경로 실패, 대체 경로 증거, 예외 적용 범위와 남은 확인 |
한 사람에게 여러 직책이 있으면 기록에 두 번 이름을 올려도 독립 확인은 한 번일 수 있습니다. 확인자와 승인자의 역할을 분리하고 업무 시스템도 같은 계정이 두 단계 승인할 수 있는지 점검합니다. 인력이 적은 팀은 실제 가능한 승인 대행자와 비상 연락 순서를 마련합니다. 두 번째 승인자가 첫 화면의 완료 표시만 보게 구성하면 놓치기 쉬운 정보가 남습니다. 승인 화면에서 지급 대상, 이전·신규 값, 거래 목적, 확인 근거를 조회할 수 있게 합니다.
중요 거래의 승인 정보가 바뀌면 이전 승인을 재사용하지 않는 통제를 둡니다. 예를 들어 결재를 받은 뒤 수취 계좌가 변경됐다면 그 변경을 새 승인 대상으로 보내야 합니다. 지급 시스템에서 사용한 정확한 거래 ID와 변경 버전을 결재 화면이 본 값과 대조합니다. 승인 순간의 값과 집행 순간의 값을 묶고 실행 전에 승인 유효성을 확인하는 방법은 OWASP — Transaction Authorization Cheat Sheet[3]를 참고할 수도 있습니다.
요구사항에서 승인까지 이어지는 근거 — 요구사항과 테스트, 결함 조치와 승인 기록을 연결해 같은 기준으로 품질을 판단합니다.
가상 훈련에서 두 요청이 같은 거래인지 확인합니다
가상 제조사에서 거래처 ‘한들 부품’ 이름으로 신규 계좌 안내 메일이 도착하고 잠시 후 대표의 음성처럼 들리는 전화로 오후 지급을 서두르라는 요청을 받습니다. 메일에는 담당자가 외근 중이므로 첨부된 새 번호로만 확인해 달라고 적혀 있습니다. 실제 고객이나 금융 사고 기록을 사용하지 않은 훈련 사례입니다. 직원이 어느 요청이 가짜인지 맞히는 대신, 확인과 승인 경로를 실제처럼 사용하는지 봅니다.
- 접수와 실행을 구분합니다. 메일의 요청을 변경 건으로 등록하고 기존 은행 계좌와 해당 지급의 처리 상태를 확인합니다. 지급 대기 상태라면 신규 계좌로 집행되기 전에 별도 확인 중으로 표시합니다.
- 거래처와 내부 승인 요청을 각각 확인합니다. 거래처 계좌는 거래처 등록부의 연락처에서 확인하고 대표 승인 요청은 내부 주소록과 결재 경로에서 조회합니다. 한쪽에서 확인되더라도 다른 쪽의 확인을 대체하지 않습니다.
- 승인 화면에 확인된 거래 내용을 제시합니다. 금액, 지급 목적, 거래처, 수신 계좌, 적용 문서가 같은 변경 버전을 참조하게 합니다. 승인 이후 값이 달라졌다면 수정 요청이 들어온 경로와 변경 이력을 검토합니다.
- 정상 업무에 영향을 주는 시간을 기록합니다. 등록된 연락처에 응답이 없어 지연되는 경우 구매와 재무 담당에게 상태를 공유합니다. 거래처가 정상적으로 연락처를 교체했을 수 있으므로 담당자 확인과 보류가 해제되는 조건을 분명히 둡니다.
- 불일치나 의심을 발견하면 재무·보안 담당에 연결합니다. 요청이 실제 거래와 일치하는지, 계정도 침해됐는지, 다른 지급 지시가 있었는지를 확인합니다. 관련 직원에게 메시지 회신이나 전달로 승인을 계속하지 않도록 안내합니다.
연습에서는 발신 전화번호, 이메일 주소, 첨부 회사 문서가 익숙한 변형을 넣을 수 있습니다. 반대로 실제 임원이 긴급하게 요청했으나 새 계좌는 거래처가 부탁한 정상 변경인 경우도 준비합니다. 이 경우 절차가 합법적인 거래를 얼마나 오래 보류하는지, 양쪽 확인과 결재를 마친 뒤 재개할 수 있는지가 테스트 대상입니다. 실패 기준에 잘못된 거래의 승인과 정상 거래의 미해결을 각각 넣으면 교육이 사기 탐지 시험에 머무르지 않습니다.
긴급 예외는 결재 경로를 빠르게 합니다
정상 업무가 자주 지연되면 직원은 긴급 요청을 별도 통제의 근거보다 통제 생략의 근거로 쓰기 쉽습니다. 예외 절차에는 응답할 사람과 승인 범위, 사용할 독립 연락처, 정상 순서의 어느 대기를 줄일 수 있는지를 명확히 씁니다. 야간에 처음 등록하는 수취처를 확인할 수 없다면 보류 상태에서 지급 시각을 조정하고 이미 검증된 수취처에 지급할 수 있는 대안을 거래의 실제 조건과 함께 검토합니다. 이 예외는 새 계좌나 연락처를 일반 업무에 자동 적용하는 승인으로 이어지지 않게 합니다.
운영 시에는 아래 세 시점을 구분해 기록합니다. 요청이 접수된 시점, 확인할 근거를 모두 얻은 시점, 실제 지급이 반영된 시점입니다. 단계별 대기 사유에 거래처 무응답, 업무 책임자 부재, 문서 불일치 등을 넣으면 확인 절차를 어디서 단축할 수 있는지 보입니다. 예컨대 사전 등록부의 연락처가 반복적으로 유효하지 않다면 접수 직원에게 재량을 더 주기보다 연락처 소유자와 갱신 주기를 정하는 개선이 우선입니다.
| 훈련 또는 운영 점검 | 봐야 할 결과 | 실패 시 보완 |
|---|---|---|
| 새 계좌와 새 연락처가 함께 첨부됨 | 기존 경로에서 변경 근거 확인, 두 변경의 별도 기록 | 마스터 변경 요청에 신규 연락처를 증거로 자동 채우는 경로 수정 |
| 발신자가 확인을 거부하고 시한을 압박함 | 승인 대행 호출 또는 보류, 요청과 독립된 통화 | 비상 연락 순서와 응답 가용성 확인 |
| 승인 뒤 금액 또는 수취 계좌가 편집됨 | 원 승인 거부, 바뀐 버전에 대한 재승인 | 승인-실행 연결과 편집 권한 수정 |
| 정상 거래라는 근거가 확보됨 | 보류 해제, 정해진 실행 경로에 복귀 | 보류 큐와 재개 책임자, 교대조 인계 점검 |
이미 처리했거나 처리 결과를 모를 때
아직 지급이 진행되지 않았다면 먼저 해당 건과 관련된 대기 변경의 적용을 보류하고 어떤 계정이 어떤 기록을 수정했는지 확인합니다. 이미 처리했다고 의심되거나 지급 서비스 응답이 불명확하면 기존 거래 ID를 가지고 지급 담당과 거래 금융기관의 공식 연락 경로에 즉시 확인합니다. 이전 지급 여부를 알 수 없는데 같은 금액을 다시 보내면 위험이 늘어납니다. 외부 지급 서비스에서 조회되는 상태와 내부 원장이 맞지 않으면 대사할 담당과 다음 확인 시점을 지정합니다. 상황에 따른 실제 지급 취소나 반환 가능 여부는 사용 기관과 회사 절차에 따라 확인합니다.
조사 자료는 승인된 저장소에 접근을 제한해 보관합니다. 원본 메시지와 필요한 메일 헤더, 사건 시각, 업무 시스템의 변경·승인 기록, 지급 거래 ID를 남기고 불필요한 금융정보를 다른 채팅에 재전송하지 않습니다. 계정 침해가 의심되면 운영과 보안 담당에게 계정 활동 조사·세션 회수·인증 수단 교체 판단을 연결합니다. 비밀키 등 별도의 접근 수단이 노출됐을 때는 시크릿 노출 대응 절차의 효력 회수와 사용처 확인도 적용할 수도 있습니다.
보류 해제는 정상 지급 요건과 조사 과정의 증거에 따라 결정합니다. 수취 계좌를 복원한 것과 이전 변경으로 지급된 건이 없는지 확인하는 일도 따로 기록합니다. NIST의 사고 대응 권고[4]와 장애 대응 런북을 참고해 초기 보류, 조치, 회복 확인과 후속 책임자를 나누면 인수인계가 쉬워집니다.
