사람들이 "감사(audit)"라는 단어를 들으면 보통 회계사, 스프레드시트, 그리고 세금 신고 기간을 떠올립니다. 하지만 소프트웨어 분야에서 감사는 완전히 다른 영역입니다. 이는 장부의 균형을 맞추는 일이라기보다, 여러분의 코드와 데이터, 그리고 제어 시스템에 대해 까다로운 질문을 던지는 것에 가깝습니다. 시스템 감사는 정보 자산이 안전한지, 데이터가 정확하게 유지되는지, 그리고 리소스가 실제로 의도한 대로 작동하는지를 평가합니다.

기능적인 시스템이 곧 신뢰할 수 있는 시스템인 것은 아닙니다. 어떤 학사 관리 플랫폼은 학생 등록을 정확히 처리하고 깔끔한 성적표를 생성하면서도, 정작 비밀번호를 평문(plain text)으로 저장하고 있을 수도 있습니다. 어떤 물류 대시보드는 완벽한 배송 시간을 보여주면서도, 데이터베이스 접속 정보를 공개적으로 읽을 수 있는 소스 코드에 노출하고 있을지도 모릅니다. 시스템 감사는 바로 이러한 간극을 메우기 위해 존재합니다.

시스템 감사가 실제로 다루는 내용

시스템 감사의 핵심은 기밀성(confidentiality), 무결성(integrity), 효율성(efficiency)이라는 세 가지 요소를 살펴보는 것입니다. 기밀성은 학생 기록, 트랜잭션 로그 또는 환자 파일에 오직 권한이 있는 사람만이 접근할 수 있음을 의미합니다. 무결성은 데이터가 시간이 지남에 따라 조용히 손상되거나, 계보(lineage)를 잃거나, 실제 값에서 벗어나지 않음을 의미합니다. 효율성은 서버, 서비스 및 프로세스가 단순히 리소스를 소비하는 데 그치지 않고 가치를 전달하고 있음을 의미합니다.

이 세 가지 특성은 반드시 검증 가능해야 합니다. 데이터베이스가 아직 다운되지 않았다는 이유만으로 신뢰하는 것은 검증이 아닙니다. 진정한 감사는 규제 기관, 고객 또는 미래의 여러분 자신이 "시스템이 건전하다는 것을 어떻게 확신합니까?"라고 물었을 때 제시할 수 있는 증거를 만들어냅니다.

시스템 감사의 주요 유형

모든 감사가 동일한 대상을 살펴보는 것은 아닙니다. 직면한 리스크에 따라 다음 중 하나 이상의 감사가 필요할 수 있습니다.

애플리케이션 감사(Application Audit). 소프트웨어 로직이 올바른지 확인합니다. 계산이 정확한가요? 상태 머신(state machines)이 예외 케이스를 제대로 처리하나요? 민감한 데이터에 접근하는 모든 함수 내부에서 권한 부여가 강제되고 있나요? 전형적인 애플리케이션 수준의 실패 사례로는 소수점을 잘못 반올림하는 성적 모듈이나, 드롭다운 값을 수정함으로써 우회할 수 있는 장학금 자격 확인 절차 등이 있습니다.

보안 감사(Security Audit). 액세스 제어, 암호화 및 취약점에 집중합니다. 누가 어떤 기록을 읽을 수 있는지, 데이터가 전송 중 및 저장 시에 암호화되어 있는지, 세션 관리가 변조를 견딜 수 있는지 등을 질문합니다. 또한 종속성(dependencies)에 알려진 취약점이 있어 시스템이 몰래 공격에 노출될 위험은 없는지도 점검합니다.

데이터베이스 감사(Database Audit). 데이터 무결성이 결정되는 곳입니다. 참조 제약 조건(referential constraints)이 강제되고 있나요? 백업이 실제로 복구 가능한 상태인가요, 아니면 단순히 예약만 되어 있나요? 데이터 보존 정책이 법적 요구 사항과 일치하나요? 데이터베이스 감사는 복구 계획도 검토합니다. 한 번도 연습해 보지 않은 백업은 그저 이론에 불과하기 때문입니다.

네트워크 감사(Network Audit). 서버, 방화벽, 라우팅 및 가용성을 점검합니다. 필요한 포트만 열려 있는지, 방화벽 규칙이 문서화되어 있는지, 인프라가 트래픽 급증이나 서비스 거부(DoS) 공격을 처리할 수 있는지 확인합니다. 또한 애플리케이션 계층뿐만 아니라 운영 체제에 패치가 적용되었는지도 확인합니다.

컴플라이언스 감사(Compliance Audit). 외부 규정에 따라 시스템을 측정합니다. 학생 플랫폼은 FERPA를 준수해야 할 수 있고, 의료 시스템은 HIPAA를 충족해야 합니다. 결제 처리는 PCI-DSS 준수가 필요합니다. 컴플라이언스는 단순히 보안을 유지하는 것을 넘어, 외부 기관에 그 보안성을 입증할 수 있는 능력을 의미합니다.

운영 감사(Operational Audit). 코드는 이야기의 절반에 불과합니다. 이 감사는 유지보수 프로세스, 지원 워크플로우, 변경 관리 및 문서의 최신성을 검토합니다. 배포 파이프라인을 이해하는 유일한 사람이 조직을 떠나게 되면, 아무리 뛰어난 애플리케이션이라도 리스크가 됩니다.

실제 사례: EduManage v1.0 감사하기

최근 저는 학사 관리 플랫폼인 EduManage v1.0에 대해 내부 보안 및 애플리케이션 감사를 수행했습니다. 이 시스템은 등록, 기록 및 성적 관리를 담당했습니다. 실제 학생 데이터에 접근하기 전에, 우리는 이 시스템을 신뢰할 수 있는지 확인해야 했습니다. 저는 명확한 6단계 프로세스를 따랐으며, 대부분의 내부 감사에 이와 동일한 구조를 적용할 것을 권장합니다.

범위 계획. 경계가 없는 감사는 끝없는 고된 작업이 됩니다. 우리는 인증, 레코드 관리, 핵심 등록 워크플로와 같이 어떤 모듈이 범위에 포함되는지 정확히 정의했습니다. 서드파티 통합 및 물리적 인프라는 명시적으로 범위에서 제외되었습니다. 우리는 2주의 기간을 할당하고 질문에 답변할 수 있는 핵심 인력을 식별했습니다. 이러한 명확성은 범위 확장(scope creep)을 방지하고 모두의 방향을 일치시킵니다.

정보 및 문서 수집. 아키텍처 다이어그램, API 문서, 데이터베이스 스키마 및 이전 사고 보고서를 수집했습니다. 리드 개발자와 배포 방식 및 기술 스택 선택에 대해 논의했습니다. 이해하지 못하는 것은 테스트할 수 없으며, 이 단계에서 내린 가정은 이후의 모든 결과에 악영향을 미칠 것입니다.

테스트 실행. 우리는 세 가지 관점에서 시스템에 접근했습니다. 코드 리뷰를 통해 안티 패턴, 인젝션 결함 및 보안에 취약한 종속성을 찾아냈습니다. 기능 테스트를 통해 등록 제한 및 선행 조건 확인과 같은 비즈니스 규칙이 단순히 프론트엔드 코드 뒤에 숨겨지는 것이 아니라, 실제로 유효하지 않은 상태를 차단하는지 확인했습니다. 침투 테스트는 외부 공격자를 모방하여 노출된 엔드포인트를 조사하고 요청을 조작하여 무엇이 유출되거나 손상되는지 확인했습니다.

리스크 및 결과 분석. 가공되지 않은 취약점들이 모두 동일하게 중요한 것은 아닙니다. 우리는 각 발견 사항을 발생 가능성에 따라 매핑하고