리뷰는 사랑입니다
일반통제가 rely 된다는 가정 아래에서
전산감사를 하다 보면 한 번쯤 이런 질문을 한다.
“자동화통제… 정말 믿어도 되나요?”
시스템이 알아서 해준다.
사람은 개입하지 않는다.
그래서 더 믿고 싶다.
하지만 우리는 안다.
자동화는 실수를 하지 않는다.
대신, 설계된 대로 틀린다.
⸻
1. 전제 : 일반통제가 rely 된다는 가정
자동화통제를 신뢰하려면
ITGC(일반통제)가 먼저 받쳐줘야 한다.
• 변경통제는 승인 후 반영되고
• 접근권한은 최소권한이며
• 운영환경은 안정적이고
이게 무너지면
아무리 로직이 완벽해도
결국 “누군가 바꿀 수 있는 통제”가 된다.
자동화통제는 ITGC 위에 세워진 유리탑이다.
⸻
2. 자동화통제는 크게 세 가지로 나눠본다
2.1 로직 검증
핵심은 완전성과 정확성
• 조건이 빠지지 않았는가? (완전성)
• 계산이 정확한가? (정확성)
또 우리는 선택해야 한다.
• 블랙박스 테스트로 결과만 볼 것인가
• 화이트박스로 코드까지 볼 것인가
효율성은 화이트박스다.
특히 중요 통제라면
코드 검토가 곧 감사의 깊이다.
하지만 감사 자체로는 화이트박스 테스트를 지양하라고 가이드된다. 우리는 감사인이므로 risk based 감사를 해야 하며, 모든 개발 코드 depth를 파악하는 게 주목적이 아니기 때문이다.
⸻
2.2 인터페이스 검증
여기는 단순하다.
• Source Destination
• 데이터가 어디서 와서 어디로 가는가
파일 전송? API? 배치?
중간에 누락은 없는가?
중복은 없는가?
100건을 A 시스템에서 B 시스템으로 옮길 때,
건수가 100건인지 (완전성) 샘플로 1건 뽑으니 각각 시스템에 동일한지 (정확성) 봐야 한다.
우와 100건 맞네~ 하고 봤더니 1~100 이 아니라 200~300건이 옮겨져서 건수가 맞으면 낭패!
우와 한건 봤더니 맞네? 샘플 한건만 되고 나머지는 오류면?
그래서 우리는 완전성과 정확성 둘 다 확인해야 한다.
인터페이스는
“보내는 사람의 진심”이 아니라
받는 사람의 데이터로 판단한다.
⸻
2.3 Input / Output 검증
이건 블랙박스의 영역이다.
• 인풋을 넣고
• 결과를 본다.
전체 흐름이 맞는지 본다.
하지만 이 방법은 항상 묻는다.
“왜 이렇게 나왔지?”
그래서 중요한 통제라면
결국 다시 로직으로 돌아간다.
⸻
로직을 보다 멈칫하는 순간,
코드를 보다가
주석 처리된 부분을 발견한다.
이 순간 감사인은 두 갈래 길에 선다.
• 과거엔 있었던 유효성 검증
• 지금은 없는 상태
이건 단순한 코드 수정이 아니다.
통제의 철학이 바뀐 것이다.
질문은 이것이다.
• 변경승인은 있었는가?
• 리스크 평가는 했는가?
• 제거된 통제의 대체통제는 존재하는가?
주석은 말이 없다.
하지만 시스템은 그대로 반영한다.
⸻
자동화통제를 믿는다는 것
자동화통제를 믿는다는 건
코드를 믿는 게 아니다.
• 설계를 믿고
• 변경통제를 믿고
• 운영통제를 믿는 것이다.
그리고 무엇보다
“누군가 의도적으로 약화시키지 않았다”는
환경을 믿는 것이다.
⸻
같이 일하는 선생님들이 한 자동화통제를 리뷰한다.
조서에서 빠져나오면 보이는 것들이 있다.
로직이 연결되지 않아 흐름에 이가 빠졌거나,
잘못된 데이터 이거나,
목적에 맞지 않는 테스트를 하기도 한다.
리뷰어도 사람이라 못 보는 것도 분명히 있다.
하지만 확실한 건 정직하게
리뷰하면 조서는 더 정제되고 risk는 줄일 수 있다는 거.
이래서 남 리뷰는 사랑이라고 생각한다.
자동화통제는 사람보다 정확하다.
하지만 사람보다 정직하지는 않다.
그래서 우리는 묻는다.
코드에, 변경이력에, 로그에.
“당신은 여전히 통제입니까?”
그리고 답이 명확할 때만
우리는 조심스럽게 말한다.
rely 가능합니다.