03. 계정과목 매핑과 오류 탐지

일반감사 vs 전산감사 비교 포인트

실습 데이터 예시

교육에서는 다음과 등의 필드를 가진 샘플 CSV 또는 엑셀 파일을 사용합니다. 데이터는 회사 실무 자료와 유사한 구조로 작성하고, 일부 오류를 의도적으로 반영하여 비교 실습을 진행합니다.

• ACCOUNT_MASTER: account_code, account_name, fs_caption, normal_balance
• MAPPING_RULE: account_code, fs_line, disclosure_group
• JE_LINE: account_code, description, department, vendor_id, amount

상세 케이스 배경

예제 회사는 여러 부서가 같은 시스템을 사용하지만, 각 부서가 보는 화면과 책임 범위는 서로 다릅니다. 영업 담당자는 거래 생성에 집중하고, 회계팀은 전표 반영과 결산 금액을 확인하며, IT 운영팀은 권한·배치·로그·장애 처리를 관리합니다. 계정과목 매핑과 오류 탐지는 이 세 관점이 만나는 지점이므로 한 부서의 설명만으로는 충분한 감사 결론을 내리기 어렵습니다.

강의에서는 먼저 회사 담당자의 설명을 업무 흐름도로 정리합니다. 이후 흐름도에 전표, 마스터, 로그, 파일, 승인 증빙을 하나씩 붙여 실제 데이터 계보를 만듭니다. 이 과정에서 화면상 정상 처리된 거래라도 승인자가 부적절하거나, 마스터 변경 이력이 누락되었거나, 증빙 파일이 사후 교체된 경우처럼 일반적인 검토에서 놓치기 쉬운 위험을 찾아냅니다.

학습자는 감사인, 전산감사인, 현업 담당자, IT 운영자 역할을 번갈아 맡습니다. 감사인은 재무제표 영향과 경영진 주장을 확인하고, 전산감사인은 모집단과 시스템 로그를 검토하며, 현업 담당자는 업무 사유를 설명합니다. 역할을 나누면 같은 예외도 회계 오류, 통제 미비, 보안 취약점, 정상 업무처리 중 어디에 해당하는지 더 현실적으로 판단할 수 있습니다.

업무 프로세스와 시스템 흐름

계정과목 매핑과 오류 탐지를 정확히 이해하려면 화면에서 보이는 기능만 확인해서는 부족합니다. 사용자가 입력한 값이 어떤 승인 단계를 거쳐 저장되고, 어떤 배치나 인터페이스를 통해 다른 테이블로 이동하며, 최종적으로 어떤 보고서나 회계처리 결과에 반영되는지 순서대로 추적해야 합니다.

교육에서는 먼저 업무 담당자의 설명을 듣고, 그 설명을 시스템 흐름도로 다시 표현합니다. 그 다음 실제 데이터 필드와 로그를 대조하여 설명과 데이터가 일치하는지 확인합니다. 문서에는 정상 절차만 기록되어 있어도 실제 시스템에서는 예외 승인, 재처리, 수기 보정, 임시 권한, 파일 재업로드가 발생할 수 있습니다.

1. 입력 단계: 누가 어떤 화면이나 파일을 통해 데이터를 생성하는지 확인합니다.
2. 승인 단계: 승인자, 승인 기준, 반려·수정 이력, 대체 승인 절차를 검토합니다.
3. 처리 단계: 자동계산, 인터페이스, 배치, 마스터 참조, 예외 처리 로직을 정리합니다.
4. 보고 단계: 처리 결과가 원장, 보고서, 대시보드, 감사증거로 어떻게 사용되는지 연결합니다.

상세 실습 절차

학습자는 감사팀 회의에서 받은 문제 상황을 기준으로 절차를 직접 설계합니다. 강사가 정답 쿼리를 바로 제공하기보다, 먼저 어떤 위험을 검증할지 토론하고 그 위험을 데이터 조건으로 바꾸는 과정을 거칩니다. 이를 통해 단순 도구 사용이 아니라 감사 판단을 위한 분석 설계 역량을 기릅니다.

• 위험 정의: 계정과목 매핑과 오류 탐지와 관련된 재무제표 왜곡 가능성, 통제 실패 가능성, 보안 침해 가능성을 문장으로 작성합니다.
• 자료 요청: 필요한 테이블, 로그, 화면 캡처, 승인 문서, 정책 문서, 담당자 인터뷰 자료를 목록화합니다.
• 무결성 확인: 기간, 건수, 합계, 키 중복, 누락값, 코드값 범위를 검사하여 데이터가 분석 가능한 상태인지 판단합니다.
• 예외 추출: 위험과 직접 연결되는 조건을 만들고 전체 모집단에서 예외 항목을 추출합니다.
• 표본 재검토: 예외 항목 중 대표 사례를 선정해 증빙, 로그, 담당자 설명과 대조합니다.
• 결론 작성: 발견사항의 원인, 영향, 보완통제, 개선 우선순위를 감사조서 문구로 정리합니다.

심화 데이터 설계 예시

기본 실습 데이터 외에도 아래와 같은 필드를 추가하면 감사 절차를 더 현실적으로 구성할 수 있습니다. 각 필드는 단순 조회용이 아니라 통제 목적, 증거 신뢰성, 예외 원인 분석에 직접 연결되도록 설계합니다.

• GL_DETAIL: account_code, journal_id, posting_date, amount, user_id
• SUB_LEDGER: customer_id, invoice_no, due_date, balance, status
• AUDIT_MATCH: source_key, target_key, match_result, exception_reason
• EVIDENCE_INDEX: evidence_id, journal_id, file_name, reviewer, conclusion

실습에서는 원천 데이터와 가공 데이터의 차이도 함께 다룹니다. 원천 테이블은 시스템에서 최초 생성된 값을 보존하고, 가공 테이블은 분석 목적에 맞게 조인·정제·집계한 결과입니다. 감사인은 가공 결과만 저장하지 않고 원천 데이터 위치, 추출일시, 추출자, 필터 조건, 재수행 방법을 함께 남겨야 합니다.

분석 로직 설계

계정, 기간, 전표번호, 거래처, 승인상태, 증빙번호, 사용자 정보를 연결해 거래 흐름을 재구성합니다. 실무에서는 하나의 조건만으로 예외를 판단하기 어렵기 때문에 여러 조건을 조합해 위험을 단계화합니다. 예를 들어 금액이 크지만 승인 이력이 정상인 거래와 금액은 작지만 마감 이후 권한 변경 직후 입력된 거래는 서로 다른 방식으로 평가해야 합니다.

강의에서는 먼저 쉬운 규칙부터 작성합니다. 이후 정상 업무 패턴을 학습하여 오탐을 줄이고, 예외가 반복되는 사용자·부서·기간·거래유형을 찾아 원인 분석으로 확장합니다. 최종 로직은 사람이 이해할 수 있는 설명, 재수행 가능한 조건식, 조서에 붙일 수 있는 결과표 세 가지 형태로 남깁니다.

재수행과 대사 방법

감사 절차에서 중요한 것은 회사가 제공한 결과를 그대로 믿는 것이 아니라, 감사인이 독립적으로 재수행할 수 있는지 확인하는 것입니다. 계정과목 매핑과 오류 탐지 실습에서는 회사 산출물과 감사인 산출물을 같은 기준으로 다시 계산하거나 대사하여 차이를 찾습니다. 차이가 발생하면 계산식 오류, 데이터 누락, 기준일 차이, 필터 조건 차이, 수기 조정 여부를 순서대로 확인합니다.

• 회사 보고서의 기간과 감사인이 받은 원천 데이터의 기간이 일치하는지 확인합니다.
• 데이터 추출 시 제외된 상태값, 취소건, 임시저장건, 테스트 계정이 있는지 확인합니다.
• 집계 기준이 전표일, 입력일, 승인일, 반영일 중 무엇인지 명확히 구분합니다.
• 대사 차이는 단순 금액 차이뿐 아니라 건수, 키값, 승인상태, 처리결과 차이로 나누어 정리합니다.
• 재수행 결과는 스크린샷보다 원천 데이터, 계산 파일, 검토자 서명, 결론 문구로 남깁니다.

이 절차를 통해 학습자는 “시스템에서 출력된 보고서”와 “감사인이 신뢰할 수 있는 감사증거”가 항상 같은 것은 아니라는 점을 이해합니다. 특히 자동화된 보고서는 편리하지만, 그 보고서를 만드는 기준과 권한, 변경 이력, 데이터 완전성이 확인되어야 감사증거로 사용할 수 있습니다.

예외 판단 기준과 후속 절차

모든 예외가 오류나 미비점은 아닙니다. 교육에서는 예외를 발견한 뒤 곧바로 결론을 내리지 않고, 업무 사유와 보완통제를 확인하는 단계를 반드시 거칩니다. 마감 이후 입력, 휴일 처리, 권한 변경, 재처리 로그는 실제 오류일 수도 있지만 정당한 승인과 증빙이 있는 정상 업무일 수도 있습니다.

감사조서 작성 예시

조서에는 분석 결과만 붙이지 않고, 절차의 목적과 판단 근거를 함께 남깁니다. 좋은 조서는 다른 감사인이 읽어도 왜 이 절차를 수행했는지, 어떤 데이터를 사용했는지, 어떤 예외가 있었는지, 최종 결론이 무엇인지 따라갈 수 있어야 합니다.

• 절차 목적: 계정과목 매핑과 오류 탐지와 관련된 통제 목적 또는 재무제표 왜곡 위험을 검토하기 위함입니다.
• 사용 자료: 회사가 제공한 원천 데이터, 시스템 로그, 승인 증빙, 인터뷰 메모를 기준으로 분석했습니다.
• 수행 내용: 데이터 완전성 확인 후 위험 조건을 적용하여 예외를 추출하고 대표 표본을 재검토했습니다.
• 발견사항: 예외 항목은 업무 사유와 증빙 유무에 따라 정상 예외, 추가 확인 필요, 통제 미비 후보로 분류했습니다.
• 결론: 발견사항이 재무제표와 내부통제에 미치는 영향을 평가하고 개선권고 또는 추가 감사절차 필요 여부를 기재했습니다.

강의에서는 같은 분석 결과를 초보자식 문구와 실무 조서 문구로 비교합니다. 예를 들어 “이상한 거래가 있음”이 아니라 “마감일 이후 승인 없이 반영된 거래 7건을 식별하였으며, 그중 2건은 증빙 미제출 상태이므로 추가 검토가 필요함”처럼 수량, 조건, 영향, 후속 절차를 포함해 작성합니다.

흔한 실패 사례

초보자가 가장 자주 하는 실수는 도구 사용에 집중한 나머지 감사 목적을 잊는 것입니다. 피벗테이블이나 SQL 결과가 아무리 많아도, 그 결과가 어떤 위험을 줄이는지 설명하지 못하면 감사증거로서 가치가 낮습니다. 또 회사가 제공한 데이터를 완전하다고 가정하고 분석을 시작하면, 누락된 기간이나 제외된 상태값 때문에 잘못된 결론을 낼 수 있습니다.

• 데이터 요청서에 기간, 회사코드, 시스템명, 필드 정의를 쓰지 않아 재요청이 반복됩니다.
• 예외 조건은 만들었지만 정상 업무 사유를 반영하지 않아 오탐이 지나치게 많아집니다.
• 표본 검토 결과와 전체 모집단 분석 결과를 연결하지 못해 조서 결론이 약해집니다.
• 로그나 증빙 파일의 신뢰성을 확인하지 않고 화면 캡처만 보관합니다.
• 개선권고가 추상적이어서 담당 부서가 무엇을 바꿔야 하는지 알기 어렵습니다.

수업에서는 이러한 실패 사례를 일부러 포함한 샘플 데이터를 제공합니다. 학습자는 틀린 결과를 수정하면서 어떤 점검이 빠졌는지 찾고, 개선된 절차를 다시 실행합니다. 이 반복 과정이 실제 감사 현장에서 문제를 발견하고 설명하는 힘을 키워 줍니다.

강사 리뷰 기준

강사는 정답 여부보다 사고의 흐름을 중심으로 리뷰합니다. 좋은 답안은 위험을 명확히 정의하고, 그 위험을 확인하기 위한 데이터와 증빙을 정확히 요청하며, 분석 결과를 과장하지 않고 후속 절차와 연결합니다. 반대로 결과표는 화려하지만 데이터 완전성 검토가 없거나, 예외의 업무 사유를 확인하지 않은 답안은 감점됩니다.

실무 적용 체크리스트

• 분석 목적이 감사위험 또는 통제 목적과 직접 연결되어 있는지 확인합니다.
• 데이터 요청 범위가 기간, 회사코드, 시스템, 테이블, 필드 수준에서 명확한지 검토합니다.
• 원천 데이터의 완전성, 정확성, 권한 있는 추출 여부를 확인합니다.
• 예외 조건을 사람이 읽을 수 있는 문장과 재수행 가능한 쿼리 형태로 동시에 기록합니다.
• 정상 예외와 실제 오류를 구분한 근거를 증빙 색인으로 연결합니다.
• 발견사항은 원인, 영향, 개선안, 담당 부서, 완료 예정일로 나누어 작성합니다.
• 최종 산출물은 수업 후 포트폴리오에 넣을 수 있도록 요약본과 상세본을 분리합니다.

포트폴리오 전환 방법

계정과목 매핑과 오류 탐지 실습 결과는 교육장에서만 끝나지 않습니다. 민감한 회사명을 제거하고 가상 데이터 기준으로 재구성하면 개인 포트폴리오에 넣을 수 있는 사례가 됩니다. 포트폴리오에는 원본 데이터가 아니라 문제 정의, 분석 설계, 예외 판단 기준, 조서 예시, 개선권고 요약을 넣습니다.

권장 구성은 한 페이지 요약, 상세 조서, 데이터 사전, 예외 규칙표, 발표 슬라이드 순서입니다. 한 페이지 요약에는 “어떤 위험을 보았는가”, “어떤 데이터를 사용했는가”, “어떤 결과를 얻었는가”, “업무적으로 무엇을 개선할 수 있는가”를 간단히 정리합니다. 이렇게 정리하면 면접이나 사내 발표에서 자신의 역할과 판단 과정을 명확히 설명할 수 있습니다.

• README: 프로젝트 목적, 사용 데이터, 주요 절차, 결과 요약을 작성합니다.
• 조서 샘플: 민감정보를 제거한 감사 절차와 결론 문구를 정리합니다.
• 데이터 사전: 필드 의미, 키값, 조인 관계, 품질 점검 기준을 설명합니다.
• 발표 자료: 문제 상황, 접근 방법, 발견사항, 개선권고를 5장 내외로 구성합니다.

미니 과제

학습자는 제공된 샘플 데이터에서 계정과목 매핑과 오류 탐지와 관련된 위험 시나리오 1개를 선택하고, 데이터 요청서 1장, 예외 추출 규칙 3개, 검토 결과 요약표 1개를 작성합니다. 과제의 목적은 정답을 맞히는 것이 아니라 감사인이 왜 그 절차를 수행했는지 설명할 수 있게 만드는 것입니다.

제출물에는 분석 화면 캡처만 넣지 않습니다. 문제 정의, 사용한 데이터, 주요 필터, 예외 건수, 대표 사례, 담당자에게 물어볼 질문, 잠정 결론을 함께 포함합니다. 이렇게 정리한 산출물은 교육 종료 후 개인 포트폴리오나 면접 발표 자료로도 활용할 수 있습니다.

과제 제출 후에는 동료 리뷰를 진행합니다. 다른 학습자가 같은 데이터를 보고 어떤 다른 위험을 생각했는지 비교하고, 본인이 놓친 데이터 필드나 보완통제를 찾아봅니다. 이 과정은 실제 감사팀 회의처럼 서로의 판단을 검증하는 훈련입니다.

현업 인터뷰 질문 세트

계정과목 매핑과 오류 탐지 실습에서는 데이터만 보는 것이 아니라 담당자의 설명을 통해 예외의 원인을 확인합니다. 인터뷰 질문은 단순히 “왜 발생했나요?”라고 묻는 방식이 아니라, 통제 설계와 실제 운영을 검증할 수 있도록 구체적으로 구성합니다. 질문을 잘 만들면 부족한 데이터를 보완할 수 있고, 반대로 질문이 추상적이면 담당자의 일반적인 설명만 듣고 끝날 위험이 있습니다.

• 업무 기준: 이 절차를 수행해야 하는 공식 정책, 매뉴얼, 승인 기준은 무엇이며 최근 변경된 적이 있나요?
• 시스템 기준: 화면에서 입력한 값이 저장되는 테이블, 자동계산 기준, 배치 반영 시점은 어떻게 정해져 있나요?
• 예외 처리: 일반 절차를 따르지 못하는 경우 누가 승인하고 어떤 증빙을 남기나요?
• 권한 관리: 담당자 변경, 휴가, 퇴사, 임시 프로젝트 상황에서 권한은 어떻게 부여·회수되나요?
• 검토 책임: 처리 결과를 누가 검토하며, 검토 흔적은 시스템 로그와 문서 중 어디에 남나요?
• 오류 수정: 오류가 발견되면 수정 전 값, 수정 후 값, 승인자, 수정 사유가 모두 추적되나요?
• 재발 방지: 같은 유형의 예외가 반복될 때 기준 변경, 시스템 개선, 교육 중 어떤 조치를 하나요?

학습자는 인터뷰 답변을 그대로 받아쓰기보다, 답변이 데이터와 맞는지 확인합니다. 예를 들어 담당자가 “월말에는 반드시 팀장 승인을 거친다”고 말하면 승인 로그와 결재 문서에서 실제 승인자, 승인일시, 반려·재승인 이력이 확인되는지 대조합니다. 이 과정을 통해 인터뷰는 단순 참고자료가 아니라 감사증거를 찾는 방향을 잡아 주는 절차가 됩니다.

최종 리뷰 시나리오

마지막 단계에서는 학습자가 작은 감사팀을 구성해 리뷰 회의를 진행합니다. 한 명은 절차 수행자, 한 명은 품질검토자, 한 명은 회사 담당자 역할을 맡습니다. 수행자는 계정과목 매핑과 오류 탐지 분석 결과를 설명하고, 품질검토자는 데이터 완전성, 예외 기준, 결론 문구가 충분한지 질문합니다. 회사 담당자는 업무상 예외 사유를 설명하면서 추가 증빙을 제시합니다.

리뷰 회의의 목적은 지적을 많이 하는 것이 아니라 결론을 더 견고하게 만드는 것입니다. 분석 결과가 맞더라도 설명이 부족하면 조서 품질은 낮아질 수 있습니다. 반대로 예외가 많이 발견되지 않았더라도, 데이터 범위와 검증 절차가 충분히 설계되어 있으면 신뢰할 수 있는 결론을 낼 수 있습니다. 학습자는 이 차이를 체감하면서 실제 프로젝트에서 필요한 커뮤니케이션 방식을 익힙니다.

리뷰가 끝나면 학습자는 최종 산출물을 한 번 더 다듬습니다. 분석 파일 이름, 조서 색인, 데이터 사전, 예외 리스트, 결론 문구가 서로 같은 용어를 쓰는지 확인하고, 발표용 요약본에는 핵심 메시지만 남깁니다. 이 정리 과정까지 마쳐야 교육 결과물이 실제 업무와 포트폴리오에서 사용할 수 있는 형태가 됩니다.

교육 산출물

• 계정과목 사용 기준표
• 오분류 판단 메모
• 계정 매핑 오류 탐지표
• 수정분개 후보 목록