감사

정의

IT 감사는 조직의 정보시스템과 그 운영 체계가 자산을 보호하고, 데이터의 무결성을 유지하며, 조직의 목표를 효과적으로 달성하도록 작동하는지를 평가하는 감사입니다. 정보시스템 감사라고도 합니다.

회계 감사를 하는 데에도 IT 감사가 필요합니다. 오늘날 재무 데이터는 사람이 장부에 적는 것이 아니라 전산 시스템이 만들어 냅니다. 시스템을 믿을 수 없으면 그 시스템이 산출한 숫자도 믿을 수 없습니다. 전표 한 장 한 장을 확인하는 것보다, 전표를 만들어 내는 구조가 건전한지를 확인하는 편이 효율적이기도 합니다.

IT 일반통제 (ITGC)

여러 시스템에 공통으로 적용되는 기반 통제를 말합니다. 대표적인 영역은 다음과 같습니다.

• 접근 통제: 권한이 있는 사람만 시스템에 접근하는가. 퇴직자 계정은 즉시 차단되는가. 한 사람이 요청과 승인을 모두 할 수 있지는 않은가(직무 분리). 공용 계정을 여럿이 나눠 쓰고 있지는 않은가. 공용 계정은 특히 위험합니다. 누가 무엇을 했는지 특정할 수 없으면 사고가 나도 책임을 물을 수 없고, 조사도 거기서 막힙니다.
• 변경 관리: 프로그램 변경이 승인, 테스트, 배포의 절차를 거치는가. 개발자가 운영 환경을 직접 고칠 수 있는가. 개발자가 운영 데이터베이스에 직접 접속할 수 있다면, 그 시스템이 만들어 내는 어떤 숫자도 검증되지 않은 것입니다.
• 운영 관리: 배치 작업, 장애 대응, 백업과 복구가 정해진 절차대로 이뤄지는가. 백업은 존재 여부가 아니라 실제로 복구되는지를 확인해야 합니다.

응용통제

개별 업무 시스템 안에 내장된 통제입니다. 입력값 검증, 한도 초과 시 승인 요구, 중복 전표 차단, 필수 항목 누락 방지처럼 특정 거래의 정확성을 직접 보장합니다.

왜 일반통제를 먼저 보는가

ITGC 가 무너지면 응용통제도 신뢰할 수 없게 됩니다. 누구나 프로그램을 고칠 수 있는 환경이라면, 그 프로그램 안의 검증 로직이 지금 이 순간에도 살아 있다고 장담할 수 없기 때문입니다. 승인 한도를 우회하도록 코드를 잠깐 바꾸고 되돌려 놓으면, 시스템은 아무 일도 없었던 것처럼 보입니다.

그래서 IT 감사는 대개 일반통제부터 확인하고, 그것이 신뢰할 만할 때 응용통제의 유효성을 인정합니다. 순서를 바꾸면 모래 위에 검증을 쌓는 셈이 됩니다.

로그라는 최후의 보루

통제가 완벽할 수는 없으므로, 무슨 일이 있었는지 나중에 확인할 수 있는 기록이 필요합니다. 접속 기록, 변경 이력, 권한 부여 이력이 그것입니다.

다만 로그는 남기기만 해서는 의미가 없습니다. 아무도 보지 않는 로그, 관리자가 마음대로 지울 수 있는 로그, 보존 기간이 한 달인 로그는 사고가 났을 때 아무 역할도 하지 못합니다. 로그를 누가 볼 수 없게 하고, 누가 지울 수 없게 하며, 얼마나 오래 보관하는지가 실제 통제의 수준을 결정합니다.

정의

내부 감사는 조직의 운영을 개선하고 가치를 더하기 위해 수행하는 독립적이고 객관적인 확신 및 컨설팅 활동입니다. 국제내부감사인협회(IIA)의 정의가 널리 쓰이며, 체계적이고 규율 있는 접근법으로 리스크 관리, 통제, 지배구조 프로세스의 유효성을 평가하고 개선하는 것을 목적으로 합니다.

정의에 확신 과 컨설팅 이 함께 들어 있는 점이 눈에 띕니다. 잘못을 찾아내는 것만이 아니라, 잘 굴러가도록 돕는 것도 내부 감사의 일이라는 뜻입니다. 다만 스스로 설계한 통제를 나중에 스스로 평가하게 되는 순간 독립성이 깨지므로, 컨설팅의 범위에는 늘 선이 필요합니다.

두 개의 축

• 독립성: 조직 구조의 문제입니다. 내부 감사는 자신이 감사하는 부서의 지휘를 받지 않아야 하며, 통상 이사회 또는 감사위원회에 직접 보고합니다. 감사 대상인 경영진이 감사인의 인사와 예산을 쥐고 있다면 그 감사는 형식만 남습니다.
• 객관성: 감사인 개인의 태도 문제입니다. 최근까지 자신이 수행하던 업무를 감사하게 되거나, 감사 대상 부서와 이해관계가 있다면 회피해야 합니다.

3선 모델

조직의 리스크 관리 책임을 세 개의 선으로 나누어 설명하는 모델입니다.

• 1선: 현업 부서. 업무를 수행하면서 그에 따르는 리스크를 직접 관리합니다.
• 2선: 리스크 관리, 준법 감시, 정보보호 등 관리 기능. 1선을 지원하고 감독하며 기준을 만듭니다.
• 3선: 내부 감사. 1선과 2선이 제대로 작동하는지를 독립적으로 평가합니다.

내부 감사가 1선이나 2선의 업무를 직접 수행하면, 나중에 자기가 만든 통제를 자기가 평가하는 상황이 됩니다. 인력이 부족한 조직에서 내부 감사가 규정 제정이나 시스템 구축을 떠맡는 일이 흔한데, 그 순간 3선은 사라집니다. 자리를 지키는 것 자체가 기능인 셈입니다.

감사의 유형

• 재무 감사: 재무 기록의 정확성과 신뢰성을 확인합니다.
• 업무 감사: 업무가 효율적이고 효과적으로 수행되는지를 봅니다. 규정 위반이 없어도 낭비가 있으면 지적 대상이 됩니다.
• 준법 감사: 법령과 내부 규정을 지키고 있는지를 확인합니다.
• IT 감사: 정보시스템이 신뢰할 수 있게 운영되는지를 봅니다.
• 부정 조사: 부정 혐의가 제기되었을 때 사실관계를 규명합니다. 이 단계에서 디지털 포렌식 기법이 사용되는 경우가 많습니다.

일반 감사와 부정 조사의 차이

둘은 성격이 상당히 다릅니다. 일반 감사는 통제가 작동하는지를 표본으로 확인하고, 대상자의 협조를 전제합니다. 반면 부정 조사는 특정 혐의를 두고 사실을 규명하며, 대상자가 증거를 없애려 할 수 있다는 전제에서 움직입니다.

그래서 부정 조사는 착수 시점부터 다릅니다. 대상자에게 미리 알리지 않고, 자료를 요청하는 대신 확보하며, 확보 절차 자체를 기록으로 남깁니다. 일반 감사의 관행대로 "자료 좀 보내 주세요" 라고 요청하는 순간, 받게 되는 것은 정리된 자료이고 사라지는 것은 원래의 자료입니다.

정의

부정은 부당하거나 불법적인 이익을 얻기 위해 의도적으로 속임수를 쓰는 행위를 말합니다. 회계상의 오류와 부정을 가르는 기준은 결과의 크기가 아니라 고의 의 유무입니다. 같은 금액의 오기라도 실수면 오류이고, 숨기려는 의도가 있었다면 부정입니다.

이 구분은 감사인에게 실질적인 의미를 갖습니다. 오류는 통제를 개선하면 줄어들지만, 부정은 통제를 우회하려는 지능이 개입하므로 같은 방식으로 접근할 수 없습니다. 부정을 저지르는 사람은 감사가 무엇을 보는지 알고 그것을 피해 갑니다.

세 가지 유형

• 자산의 유용: 조직의 자산을 빼돌리는 행위입니다. 현금 횡령, 허위 거래처를 통한 대금 지급, 재고 절취, 법인카드 사적 사용 등이 여기에 속하며 건수로는 가장 많습니다. 개별 금액은 크지 않지만 오래 지속되는 경향이 있습니다.
• 부패: 직위를 이용해 사적 이익을 취하는 행위입니다. 뇌물 수수, 리베이트, 이해충돌 거래가 대표적입니다. 회사 장부에는 정상 거래로 기록되기 때문에 회계 자료만 봐서는 드러나지 않고, 거래처와의 관계나 의사결정 경위를 봐야 보입니다.
• 재무제표 부정: 실적을 좋게 보이려고 매출을 부풀리거나 비용과 부채를 감추는 행위입니다. 건수는 적지만 금액 규모가 압도적으로 큽니다. 개인의 사적 이익보다 조직의 외형을 위해 저질러지는 경우가 많다는 점이 다른 유형과 다릅니다.

부정 삼각형

부정이 성립하는 조건을 설명하는 고전적인 이론입니다. 세 요소가 함께 있을 때 부정이 일어난다고 봅니다.

• 압력: 개인적 부채, 과도한 실적 목표, 생활 수준 유지처럼 부정을 저지를 동기가 되는 요인입니다.
• 기회: 통제가 허술해 들키지 않고 실행할 수 있다는 판단입니다.
• 합리화: "잠시 빌리는 것뿐이다", "회사가 나에게 먼저 부당했다" 처럼 자신의 행위를 정당화하는 심리입니다.

조직이 직접 통제할 수 있는 것은 대개 기회 입니다. 직원의 사정을 관리할 수도 없고 마음을 들여다볼 수도 없지만, 혼자서 처음부터 끝까지 처리할 수 있는 업무를 없애고, 기록이 남게 하고, 정기적으로 확인하는 것은 할 수 있습니다. 직무 분리, 승인 절차, 로그 기록처럼 내부통제가 겨냥하는 지점이 바로 여기입니다.

어떻게 발견되는가

여러 조사에서 반복적으로 확인되는 사실이 하나 있습니다. 부정은 정기 감사보다 제보 로 발견되는 비율이 높다는 것입니다. 가장 가까이서 보는 사람이 가장 먼저 알아차리기 때문입니다.

그래서 익명 제보 채널의 존재 여부와 그 채널이 실제로 안전하다고 믿어지는지가 부정 통제의 큰 부분을 차지합니다. 제보자가 불이익을 받은 사례가 한 번이라도 알려지면 그 채널은 그날로 죽습니다.

부정과 디지털 흔적

부정 행위는 대부분 전산 시스템 위에서 이뤄집니다. 허위 거래처를 등록하려면 시스템에 입력해야 하고, 자료를 빼돌리려면 파일을 복사해야 하며, 공모하려면 연락을 해야 합니다. 전표 데이터, 계정 접근 기록, 이메일과 메신저 대화, 외부 저장 매체 연결 흔적이 모두 남습니다.

부정 조사에서 포렌식 기법이 쓰이는 이유가 여기에 있습니다. 사람의 진술은 바뀌지만, 기록은 확보만 제때 되면 바뀌지 않습니다.

정의

컴플라이언스(Compliance)는 기업이 법령과 규제, 그리고 스스로 정한 내부 규정과 윤리 기준을 지키도록 만드는 체계와 활동을 말합니다. 단순히 규칙을 어기지 않는 상태가 아니라, 어기지 않도록 하는 구조를 갖추고 그것이 실제로 작동하게 만드는 것이 핵심입니다.

왜 중요한가

규정을 어기면 과징금과 형사 책임, 영업 정지 같은 직접적 제재가 따르지만, 더 큰 손실은 신뢰의 붕괴입니다. 한 번의 위반이 오래 쌓은 평판을 무너뜨리고 거래와 투자, 인재 확보에까지 영향을 미칩니다. 규제가 촘촘해지고 국경을 넘는 사업이 늘면서 지켜야 할 규범의 범위도 계속 넓어지고 있습니다.

내부감사와의 관계

컴플라이언스와 내부감사는 목적이 겹치지만 역할이 다릅니다. 컴플라이언스가 지키도록 설계하고 운영하는 1차 방어선이라면, 내부감사는 그 체계가 제대로 작동하는지 독립적으로 검증하는 역할을 합니다. 둘은 대립이 아니라 보완 관계이며, 건강한 조직일수록 이 경계가 분명합니다.

컴플라이언스 리스크

컴플라이언스 리스크는 규정 위반으로 조직이 입을 수 있는 법적·재정적·평판적 손실 가능성입니다. 부패·뇌물, 공정거래 위반, 개인정보 침해, 회계 부정, 자금세탁 등 업종과 사업 구조에 따라 노출되는 리스크가 다릅니다. 그래서 진단의 첫 단계는 우리 조직이 어디에 노출되어 있는지를 파악하는 것입니다.

진단과 점검

컴플라이언스 진단은 규정 준수 체계가 실제로 갖춰져 있고 작동하는지를 점검하는 과정입니다. 제도의 존재 여부만이 아니라 데이터와 기록으로 실제 이행을 확인하는 것이 중요합니다. 디지털 포렌식 기법을 활용하면 문서와 시스템 로그에서 위반의 징후를 객관적으로 찾아낼 수 있어, 형식적 점검을 넘어 실질적 진단이 가능해집니다.

정의

M&A 실사(PMA, Post-Merger Audit)는 인수·합병이 끝난 뒤 인수한 기업의 실제 상태를 다시 들여다보는 감사입니다. 계약 전에 진행하는 사전 실사(Due Diligence)가 주로 제공된 자료를 검토하는 데 그친다면, PMA는 인수 후 확보한 접근 권한으로 기업 내부의 데이터를 직접 분석해 숨어 있던 문제를 규명합니다.

왜 필요한가

인수 전 실사는 대상 기업이 제공하는 범위 안에서만 이뤄집니다. 감추려는 부정이나 부실은 그 범위 밖에 있기 마련이고, 계약을 서두르는 압박 속에서 놓치는 것도 많습니다. 인수가 끝나 경영권과 데이터에 대한 접근이 확보되면, 그제야 장부 뒤에 가려졌던 횡령·분식·이해충돌 거래가 드러나는 경우가 적지 않습니다.

디지털 포렌식의 역할

PMA의 핵심은 이메일, 회계 시스템, 전자문서 등 인수한 기업의 디지털 데이터를 포렌식 절차로 수집·분석하는 데 있습니다. 삭제된 자료를 복원하고 자금 흐름과 의사결정 기록을 추적해, 무엇이 언제 어떻게 이뤄졌는지를 증거능력 있는 형태로 규명합니다. 이렇게 확보한 사실은 인수 후 손해배상이나 가격 조정, 책임 추궁의 근거가 됩니다.

언제 하는가

보통 인수 직후, 경영권 이전이 마무리된 시점에 시작합니다. 시간이 지날수록 데이터가 덮어써지고 관련자가 이탈해 확인 가능한 범위가 줄기 때문에, 이르게 착수할수록 규명의 폭이 넓어집니다.

목록의 첫 줄은 결론이 아닙니다

심야 결제, 휴일 사용, 같은 금액의 반복 지급이 화면에 표시됩니다. 저는 이 목록을 부정 적발 결과라고 부르지 않습니다. 정상적인 긴급 업무, 정기 구독, 분할 납품도 같은 모양을 만들 수 있기 때문입니다. 분석 규칙이 찾는 것은 설명이 필요한 거래입니다.

이 구분이 무너지면 감사인은 예외 건수를 성과처럼 세게 되고, 현업은 방어적으로 변합니다. 데이터 분석의 목적은 사람을 먼저 지목하는 데 있지 않습니다. 전체 거래에서 검토 우선순위를 정하고, 기존 표본감사에서 놓치기 쉬운 패턴을 찾는 데 있습니다.

규칙은 회사의 업무 구조를 반영해야 합니다

같은 법인카드 규칙도 부서에 따라 의미가 다릅니다. 교대근무 부서와 일반 사무부서의 심야 사용 기준을 같게 두면 불필요한 경보가 늘어납니다. 저는 사내 규정만 읽지 않고 비용이 실제로 발생하는 과정과 승인 관행을 함께 확인합니다.

기준일, 금액 구간, 거래처 분류, 승인권자 관계를 조합하면 탐지의 맥락이 생깁니다. 규칙을 복잡하게 만드는 것이 목적은 아닙니다. 어떤 위험 가설을 확인하려는지 한 문장으로 설명할 수 있어야 합니다.

예외에서 감사 증거로 넘어가는 단계

탐지된 거래는 원전표, 결재 내역, 계약, 납품 기록, 시스템 접속 이력과 맞춰 봅니다. 담당자의 설명도 필요하지만 설명만으로 닫지는 않습니다. 설명과 당시 기록이 서로 맞는지 확인합니다.

최종 결과에는 전체 예외 건수보다 검증 기준이 더 중요합니다. 어떤 조건으로 선별했고, 무엇을 추가 확인했으며, 정상과 미흡을 어떻게 구분했는지를 남깁니다. 그래야 다음 감사에서도 같은 기준을 적용하고 규칙을 조정할 수 있습니다.

실무에서 확인할 항목

• 탐지 규칙이 가리키는 위험 가설
• 부서와 업무 유형별 정상 범위
• 거래 원장과 비정형 증빙의 연결
• 정상, 미흡, 추가 확인 필요의 판정 기준

같은 금액이 두 번 나갔습니다

같은 거래처에 550만 원이 두 차례 지급된 내역이 발견될 수 있습니다. 첫 송금이 실패해 재지급했다는 설명이 있더라도 전표 두 건만으로는 송금 실패 여부나 실제 출금 결과를 확인할 수 없습니다.

반대로 같은 금액이 실제로 두 번 출금됐더라도 서로 다른 납품에 대한 정상 지급일 수 있습니다. 금액의 중복과 채무의 중복을 구분해야 합니다.

전표에서 끝내지 않고 지급 결과까지 연결합니다

중복 지급 분석은 하나의 지급 의무가 두 번 이행됐는지를 확인하는 작업입니다. 계약·발주·검수·청구·지급 자료를 연결하고, 회계 시스템의 처리 상태와 은행의 실행 결과가 일치하는지 살핍니다.

취소 전표가 있다는 사실도 자금 반환을 곧바로 의미하지 않습니다. 장부상 취소, 은행 송금 취소, 거래처의 환급은 별개로 확인해야 합니다. 환급이 완료됐다면 중복 지급의 발생 사실과 최종 미회수 금액을 나누어 보고합니다.

IIA는 감사 분석에 사용하는 정보의 관련성·신뢰성·충분성을 강조합니다. 아래 확인사항은 이 원칙을 지급 감사에 적용한 실무 제안이며, IIA가 정한 중복 지급 전용 의무 목록은 아닙니다.

실무에서 확인할 사항

• 같은 거래처가 명칭이나 거래처 코드만 달리 등록됐는지
• 계약·청구·검수 자료가 같은 지급 의무를 가리키는지
• 지급 요청·승인·은행 실행 결과가 연결되는지
• 실패·반환·취소·환급을 뒷받침하는 외부 기록이 있는지
• 중복 발생금액, 회수금액과 미회수 잔액이 구분되는지

탐지 조건은 의심 거래를 찾는 수단입니다. 같은 금액의 정기 지급이나 분할 납품을 일괄적으로 부정으로 분류하지 않습니다. 확인된 중복 지급도 실수인지, 통제 결함인지, 고의적인 행위인지는 추가 근거로 판단합니다.

질문지는 회의실에 들어가기 전에 만들어집니다

인터뷰 직전에 파일을 훑고 질문을 적으면 확인하고 싶은 사실과 이미 믿고 있는 해석이 섞이기 쉽습니다. 저는 먼저 거래, 결재, 접속, 문서 작성 시각을 간단한 순서로 배열합니다. 그다음 빈 구간과 서로 맞지 않는 지점을 질문으로 바꿉니다.

좋은 질문은 정답을 포함하지 않습니다. '왜 승인 없이 처리했습니까'보다 '이 거래가 요청되어 승인되기까지의 과정을 설명해 주십시오'가 더 많은 정보를 줍니다. 처음부터 위반을 전제하면 상대방은 사실을 설명하기보다 전제를 반박하는 데 집중합니다.

기억과 기록은 역할이 다릅니다

사람의 기억은 시간이 지나며 바뀌고, 익숙한 업무는 여러 날의 경험이 섞일 수 있습니다. 그렇다고 진술이 쓸모없는 것은 아닙니다. 기록에 남지 않는 업무 관행, 역할 분담, 예외 처리 이유를 이해하는 데 필요합니다.

저는 진술을 곧바로 사실로 확정하지 않고 확인할 가설로 적습니다. 인터뷰 중 제시된 시스템명, 담당자, 문서, 시각을 후속 자료와 맞춰 봅니다. 진술과 기록이 다르면 어느 한쪽을 즉시 거짓으로 판단하지 않고, 기록 생성 방식과 기억의 근거를 다시 확인합니다.

인터뷰 기록에는 질문의 맥락도 남깁니다

답변만 옮기면 같은 문장도 의미가 달라질 수 있습니다. 누가 참석했고, 어떤 자료를 제시한 뒤 질문했는지, 답변자가 확인 후 보완하기로 한 내용이 무엇인지 함께 기록합니다. 중요한 진술은 표현을 바꾸어 요약하기보다 당사자가 확인할 수 있는 방식으로 남기는 편이 안전합니다.

인터뷰가 끝난 뒤에는 불리한 정황뿐 아니라 반대 방향의 자료도 찾습니다. 감사인의 첫 가설을 지지하는 답만 모으면 질문은 많아도 검증은 약합니다.

실무에서 확인할 항목

• 사실, 해석, 미확인 영역을 구분한 사전 타임라인
• 전제를 넣지 않은 개방형 질문
• 진술과 당시 생성 기록의 교차 확인
• 초기 가설을 반박할 자료의 별도 탐색

경보는 쌓이는 순간 통제가 약해집니다

대시보드에 빨간 숫자가 계속 늘어납니다. 규칙은 정상 작동하고 있지만 담당자가 보지 못한다면 통제는 작동한다고 보기 어렵습니다. 저는 상시감사를 탐지 시스템이 아니라 경보를 처리하는 업무 절차로 봅니다.

누가 경보를 받는지, 얼마 안에 첫 검토를 하는지, 어떤 자료를 추가로 요청하는지, 누구의 판단으로 닫는지가 정해져야 합니다. 책임이 불명확하면 중요한 경보도 단순 알림과 같은 운명을 맞습니다.

오탐은 제거 대상이 아니라 조정 자료입니다

상시감사 초기에는 정상 거래가 많이 걸릴 수 있습니다. 이를 시스템 실패로만 보지 않습니다. 정상으로 판정된 이유를 코드화하면 업무 특성을 배우는 자료가 됩니다. 특정 부서, 거래처, 기간에 예외가 반복된다면 규칙의 기준을 조정할 수 있습니다.

다만 예외 목록을 넓게 제외하는 방식은 조심해야 합니다. 편의를 위해 거래처 전체를 허용 목록에 넣으면 그 안에서 발생하는 새로운 위험을 놓칠 수 있습니다. 제외에는 기간과 승인 근거를 두고 정기적으로 다시 봅니다.

종결 사유가 다음 탐지의 품질을 만듭니다

경보를 '이상 없음'으로 닫는 것만으로는 학습할 수 없습니다. 정기 계약, 긴급 구매, 데이터 오류, 승인 미흡처럼 이유를 구분해야 합니다. 저는 종결 코드와 근거 문서를 함께 남기고, 반복되는 원인을 규정이나 프로세스 개선 항목으로 연결합니다.

상시감사의 품질은 탐지 건수보다 처리되지 않은 경보의 나이, 재발한 원인, 규칙 변경 이력에서 더 잘 드러납니다. 자동화는 판단을 없애는 장치가 아니라 판단이 필요한 곳을 꾸준히 보여 주는 장치입니다.

실무에서 확인할 항목

• 경보별 담당자와 초기 검토 기한
• 추가 확인 자료와 단계별 승인 기준
• 종결 사유 코드와 근거 문서
• 규칙, 제외 조건, 변경 이력의 정기 검토

합계는 맞는데 거래가 다릅니다

한 감사에서 분석 파일의 합계가 원장과 정확히 일치했습니다. 그래서 자료가 온전하다고 넘어갈 뻔했는데, 확인해 보니 같은 금액의 거래 하나가 빠지고 다른 거래가 중복되어 있었습니다. 합계만으로는 이 차이를 알 수 없었습니다.

완전성은 데이터가 많다는 뜻이 아니라, 정해진 범위의 자료가 빠짐없이 포함되어 있는지를 말합니다. 무엇을 포함해야 하는지 먼저 정해야 확인할 수 있습니다.

추출 조건이 모집단을 바꿉니다

거래일, 전표일, 지급일 중 어떤 날짜를 기준으로 삼았는지에 따라 같은 기간의 자료도 달라집니다. 취소·보류 거래를 제외했는지, 특정 법인이나 부서만 추출했는지도 영향을 줍니다. 저는 자료를 받으면 파일명보다 추출 조건을 먼저 확인하고, 화면 조회 권한 때문에 일부 거래만 내려받은 경우도 검토합니다.

연결 과정에서 생기는 손실

거래 원장에 직원 정보를 연결할 때 식별값이 없는 거래는 빠지고, 한 직원에게 여러 행이 연결되면 거래가 중복될 수 있습니다.

• 원천 자료, 추출본, 가공본의 건수와 금액을 단계별로 대조하고 차이가 생긴 지점을 확인합니다.
• 거래 식별번호의 중복·빈값, 기간별 분포를 함께 살핍니다.

분석 결과의 전제

제외된 거래가 있으면 사유와 규모를 파악해 정상적인 범위 제외인지 자료 확보 실패인지 구분합니다. 완전성이 확인되지 않은 상태에서 이상거래가 적게 나왔다고 위험이 낮다고 해석하기는 어렵습니다. 결과를 보고할 때는 탐지 내용과 함께 어떤 모집단을 대상으로 했는지 제시합니다.

정리

정리하면, 완전성은 합계가 아니라 정해진 모집단이 빠짐없이 담겼는지로 판단합니다. 추출 조건과 연결 과정을 먼저 검증하고, 어떤 모집단을 봤는지와 함께 결과를 보고합니다.

구체적인 설명의 출처

한 제보에 업무 과정과 의심 사유가 매우 자세히 적혀 있었습니다. 읽다 보면 설명이 구체적일수록 사실도 정확한 것처럼 느껴집니다. 그러나 구체성과 정확성은 다른 문제입니다.

저는 각 문장을 직접 본 내용인지, 다른 사람에게 들은 말인지, 상황을 보고 추측한 것인지 나눕니다. 여러 사람이 같은 이야기를 했더라도 최초 출처가 하나라면 독립된 근거가 여럿이라고 보기 어렵습니다.

평가 표현을 확인 항목으로

"특정 거래처를 밀어준다"는 표현만으로는 검증 범위가 정해지지 않습니다. 선정 기준, 비교 견적, 예외 승인, 가격과 납품 조건처럼 자료로 확인할 항목으로 나눕니다. 주장을 뒷받침할 자료와 정상적인 업무로 설명할 자료를 함께 찾고, 질문도 "누가 지시했습니까"처럼 행위가 있었다는 전제로 시작하지 않도록 구성합니다.

신원과 내용의 분리

익명이라는 이유만으로 제보를 배제하지 않습니다. 신원을 알 수 없어도 확인 가능한 문서나 거래가 있을 수 있습니다. 반대로 실명 제보라고 내용이 자동으로 검증되는 것도 아닙니다. 제보자의 관계와 동기는 참고하되 주장별 근거를 따로 살피고, 제보 내용을 공유할 때는 표현과 세부 정황만으로 제보자가 드러날 수 있어 원문 전체가 필요한지 검토합니다.

결과의 표현

확인된 내용, 다른 자료로 설명된 내용, 자료 부족으로 판단하지 못한 내용을 구분합니다. 입증되지 않았다는 이유만으로 허위 제보라고 표현하지 않습니다. 후속 조사로 넘어갈 때는 제보자의 평가 문구보다 확인할 쟁점과 확보할 자료를 전달합니다.

정리

정리하면, 제보는 구체성이 아니라 확인 가능한 근거로 검증합니다. 관찰과 전언과 추측을 나누고, 신원과 내용을 분리해 쟁점별로 확인한 뒤 그 수준을 그대로 표현합니다.

바뀐 규정과 그대로인 화면

한 지적사항의 조치 결과에 "규정 개정 완료"라고 적혀 있었습니다. 문서는 분명히 바뀌었는데, 시스템에서는 이전 승인 경로가 그대로 살아 있어 실제로는 예전 방식으로 처리되고 있었습니다.

이행점검은 제출 자료의 존재를 확인하는 데서 끝나지 않습니다. 지적한 원인과 조치가 연결되는지, 그 조치가 실제 업무에서 적용되는지를 살펴야 합니다.

종결 기준부터 합의합니다

저는 개선안을 정할 때 완료 기준도 함께 적습니다. 책임자와 기한 외에 어떤 상태가 되어야 종결할 수 있는지 정하는 것입니다. 승인 누락이 문제였다면 규정 개정뿐 아니라 승인 없이 처리되는 경로가 남아 있는지 확인하고, 예외 처리가 필요하면 누가 승인하고 어떻게 추적할지도 포함합니다.

설계와 운영의 구분

기능이 구현된 사실과 일정 기간 적절하게 운영된 사실은 다릅니다. 실제 거래가 있으면 변경 이후의 처리 과정을 확인하고, 발생 빈도가 낮아 운영 사례가 없으면 설정 검토나 시험으로 확인한 범위를 표시합니다. 아직 관찰하지 못한 운영 효과까지 검증 완료로 적지 않습니다.

미완료와 위험 수용

조치가 지연되면 사유, 임시 대응, 새 기한을 정합니다. 권한 있는 사람이 남은 위험을 수용한 경우에도 개선 완료와 같은 상태로 표시하지 않는 편이 명확합니다. 같은 문제가 재발하면 미이행인지, 조치 설계가 부족했는지, 다른 경로에서 발생했는지 구분합니다. 이행점검의 종결은 원래 약속한 조치와 확인 기준을 충족했는지로 판단합니다.

정리

정리하면, 이행점검은 자료가 제출됐는지가 아니라 문제가 실제로 줄었는지를 봅니다. 종결 기준을 미리 합의하고, 설계와 운영을 나눠 확인해야 조치가 형식에 그치지 않습니다.

사례로 보는 문제

가상의 사례입니다. 구매 승인 누락이 발견돼 담당자 교육을 실시했지만 다음 감사에서도 같은 문제가 확인됐습니다. 실제 업무에서는 승인 전 발주가 가능했고, 긴급 발주에 대한 사후 검토 책임도 정해져 있지 않았습니다. 교육만으로는 이 조건이 달라지지 않았습니다.

발생 원인과 탐지 실패 원인을 함께 봅니다

근본원인 분석은 기준과 실제 업무 사이에 차이가 생긴 이유를 확인하는 과정입니다. 왜 승인을 누락했는지, 어떤 통제가 이를 막아야 했는지, 이후에도 왜 발견되지 않았는지를 연결해 살펴봅니다.

원인은 하나로 정해져 있지 않습니다. 담당자의 지식 부족, 불명확한 책임, 시스템 설정과 무리한 처리기한이 함께 작용할 수 있습니다. 반대로 모든 오류를 조직문화나 시스템 문제로 확대해서도 안 됩니다. 인터뷰에서 나온 설명은 당시 업무기록·설정·승인 이력과 대조하고, 확인된 원인과 검증이 필요한 가설을 구분합니다.

개선안은 원인과 효과로 평가합니다

승인 전 발주를 막을 통제가 없었다면 시스템 제한이나 예외 승인 절차를 검토합니다. 업무 기준을 몰랐던 것이 원인이라면 교육과 안내가 직접적인 조치가 될 수 있습니다. 단순히 교육 횟수나 규정 개정 여부만으로 개선의 효과를 판단하지 않습니다.

개선안별 담당자·기한·효과 확인 기준을 정합니다. 관찰기간 중 재발하지 않았다는 사실도 거래 건수나 통제 작동 증거와 함께 평가해야 합니다. 원인이 충분히 확인되지 않았다면 남은 위험과 추가 확인 계획을 기록합니다.

실무에서 확인할 사항

• 적용 기준, 실제 발생 사실과 업무상 영향
• 예방·탐지 통제의 설계와 실제 작동 여부
• 원인별 근거와 대안 설명을 검토한 결과
• 원인에 대응하는 개선안, 담당자와 이행기한
• 개선 후 통제 작동 증거와 재발 여부를 확인할 기간·범위

사례로 보는 문제

가상의 사례입니다. 회사는 1,000만 원 이상 구매에 추가 승인을 요구합니다. 같은 부서가 같은 거래처에 며칠 간격으로 480만 원씩 세 차례 발주했고, 최초 견적서는 이를 하나의 납품으로 제시합니다. 개별 전표에 결재가 있다는 사실만으로 필요한 승인이 모두 이뤄졌다고 볼 수 있을까요?

전표 수보다 구매 수요의 관계를 봅니다

전표별 금액만 확인하는 통제는 하나의 구매를 나눠 처리할 때 작동하지 않을 수 있습니다. 감사에서는 구매 요청·최초 견적·계약·납품 목적을 연결해 당초 하나의 수요였는지 살펴봅니다.

판단의 출발점은 해당 조직에 실제로 적용되는 승인 규정입니다. 건별·계약별·사업별 중 어떤 단위를 쓰는지, 부가세·추가 발주를 금액에 포함하는지 확인합니다. 내부 기준이 불명확하다면 규정 위반 판단과 통제 설계의 미비를 구분해야 합니다.

이상 징후와 우회 결론을 구분합니다

일정 기간의 거래 합계나 승인 한도 직전의 반복 금액은 점검 대상을 찾는 지표입니다. 독립적인 수요나 정당한 단계별 납품도 있으므로 합계만으로 고의 우회를 확정하지 않습니다. 분할 사유, 당시 구매계획과 승인 요청의 변경 경위를 확인합니다.

개선 시에는 관련 거래를 함께 검토할 기준과 예외 승인 절차를 정합니다. 단순히 일정 기간의 모든 거래를 합산하면 정상적인 반복 구매까지 불필요하게 제한할 수 있습니다.

실무에서 확인할 사항

• 구매 당시 적용된 승인 단위·금액 기준·예외 절차
• 동일 요청자·거래처·사업·품목 거래의 연관성
• 최초 견적과 발주·계약 사이의 수량·금액 변경
• 납품·검수·지급의 실질적 연계 여부
• 분할 이유를 뒷받침하는 당시 기록과 승인 이력