증거가 많은 보증 사례에서도 빠진 전제를 찾아야 하는 이유

보증 사례는 결론 문장과 증거 목록만 모은 문서가 아닙니다. 주장을 논증으로 이어 주는 이유, 그 이유가 성립할 가정, 그리고 그 가정을 뒤집는 반례를 드러내야 합니다.

정상적인 감사 로그가 많아도 모든 민감한 접근이 로그 경로를 거친다는 전제가 틀리면 ‘모든 접근을 통제했다’는 상위 주장을 뒷받침하지 못합니다. 로그의 품질뿐 아니라 기록되지 않은 경로가 있는지 확인해야 합니다.

근거와 주장 사이에 논증이 필요합니다

가상의 시스템 운영자가 정상적인 접근 로그 1만 건을 제시했다고 해 보겠습니다. 로그가 충분히 많다는 사실은 ‘모든 민감 접근이 승인되고 기록됐다’는 주장에 바로 연결되지 않습니다. 주장을 참으로 만들려면 적어도 모든 민감 경로가 동일한 게이트웨이를 지나고, 기록기가 우회 불가능하며, 로그가 수집·보존 과정에서 바뀌지 않았다는 전제가 필요합니다. 보증 사례는 어떤 주장에 어떤 논증으로 어떤 근거를 연결했는지, 그리고 어떤 가정 아래 결론이 적용되는지 보여 줍니다.

반례로 빠진 전제를 찾아냅니다

기본 웹 화면 요청은 모두 게이트웨이를 지나지만 비상시 쓰는 관리자 API는 별도 경로라고 합시다. 관리자 API가 권한을 확인하더라도 감사 로그를 남기지 않는다면 로그 표본만으로 ‘모든 민감 접근이 기록됐다’고 말할 수 없습니다. 이 반례는 로그 자체가 조작됐다는 뜻이 아니라, 상위 주장의 범위와 증거 수집 경로가 다를 수 있음을 보입니다. 빠진 경로를 발견하면 전체 주장을 유지할지, 해당 API를 포함하도록 증거를 추가할지, 또는 주장 범위를 좁힐지 판단해야 합니다.

1. 검증할 상위 주장을 주체·행동·대상·조건이 보이도록 적습니다.
2. 주장을 둘 이상의 하위 주장으로 나누고 각 연결에서 필요한 전제를 씁니다.
3. 근거의 생성 위치·버전·기간·대상 경로를 확인합니다.
4. 정상 사례뿐 아니라 우회·장애·운영자 예외 같은 반례를 구성합니다.
5. 반례가 어느 하위 주장을 무너뜨리는지 표시하고, 필요한 근거를 보완하거나 결론을 제한합니다.

많은 자료보다 관련성·완전성을 봅니다

로그가 많다는 것은 더 많은 기록이 모였다는 뜻이지, 누락 경로가 없다는 증명이 아닙니다. 한 달간의 로그는 그 기간에 관측된 요청을 설명할 수 있지만, 배포 전 버전이나 기록기가 꺼졌던 시간까지 말해 주지는 않습니다. NIST CSRC Glossary는 assurance case를 top-level claim을 뒷받침하는 논증·근거·명시적 가정이 포함된 합리적이고 감사 가능한 산출물로 정의합니다. NIST SP 800-53A Rev. 5는 조직이 통제 평가를 계획하고 결과를 분석하는 절차를 제공합니다. 두 자료는 증거를 연결하는 실무 배경이며, 로그가 충분하다는 단독 결론을 주지는 않습니다.

회상 연습: 로그가 말하지 않는 전제를 적습니다

교육용 문제입니다. 웹 경로의 모든 로그가 정상입니다. 그러나 별도 관리자 API가 존재하는지 확인하지 않았습니다. ‘모든 민감 접근이 기록됐다’고 말하기 전에 필요한 전제와 확인할 근거를 하나씩 적어 보세요.

필요한 전제는 민감 접근을 수행하는 모든 경로가 동일하게 승인·기록되는 경로를 거친다는 것입니다. 관리자 API, 다운로드, 캐시 경로 목록과 각 경로의 우회·로그 시험을 확인해야 합니다. 정상 로그만으로 범위 밖 경로의 존재 여부까지 알 수는 없습니다.