왜 이런 문제가 생기는가
내보내기 버튼의 함정
문제는 IT 담당자가 무심코 누르는 내보내기 버튼에 있습니다. 보통 DB(데이터베이스)에서 엑셀이나 CSV 파일로 데이터를 추출하시잖아요. 그런데 이 과정에서 데이터 무결성(Data Integrity), 즉 데이터가 변하지 않았음을 증명하는 고리가 끊겨버립니다.
엑셀은 누구나 수정할 수 있는 포맷이거든요. 감사인은 파일 자체를 믿는 게 아니라 그 파일이 생성된 과정과 보존 상태를 믿고 싶어 해요. 솔직히 현장에서 보면 이걸 단순한 파일 전달로 생각했다가 낭패를 보는 분들이 정말 많더라고요. 한마디로, 증거 능력이 없는 문서를 준 셈이죠.
어떻게 하면 되는가
디지털 지문, 해시값 활용하기
가장 확실한 방법은 해시값(Hash Value)을 활용하는 거예요. 해시값은 데이터의 디지털 지문 같은 건데요. 파일의 내용이 단 한 글자만 바뀌어도 이 값이 완전히 달라집니다.
첫째로 데이터를 추출한 즉시 SHA-256 같은 알고리즘으로 해시값을 생성하세요. 둘째로 이 값을 감사인에게 먼저 메일로 보내 증거를 남기시면 됩니다. 셋째로 나중에 파일과 해시값을 대조하게 하면 조작 의혹을 원천 차단할 수 있겠네요. 아예 읽기 전용 권한을 가진 감사 전용 계정을 만들어 DB를 직접 보게 하는 것도 좋은 방법이에요.
한 발 더 — 실무자가 놓치는 포인트
사람의 정직함보다 시스템의 강제성
여기서 실무 팁을 하나 더 드리자면, WORM(Write Once Read Many) 저장소를 검토해 보세요. 한 번 기록하면 절대 수정할 수 없는 저장 방식인데요. 감사 로그나 증거 데이터를 이곳에 저장하면 시스템적으로 수정이 불가능하다는 강력한 근거가 됩니다.
단순히 전 안 건드렸어요라고 말하는 건 내부통제(Internal Control) 관점에서 아무런 의미가 없거든요. 데이터 추출 쿼리문(Query)과 추출 시각을 기록한 로그를 세트로 묶어 관리하는 습관을 들이셔야 합니다. 이게 왜 중요하냐면요, 나중에 법적 분쟁으로 번졌을 때 담당자를 보호하는 유일한 방패가 되기 때문이에요.
결국 데이터의 진위 여부는 누가 줬느냐가 아니라 어떻게 증명하느냐의 싸움입니다. 데이터 추출 프로세스를 문서화하고 검증 단계를 추가하는 것만으로도 불필요한 오해는 사라지더라고요.
결국 시스템이 증명하게 만드는 것이 정답입니다. 지금 바로 우리 회사의 데이터 추출 방식이 '믿음'에 의존하고 있지는 않은지 확인해 보시는 건 어떨까요?


0 댓글