SHA-256 체크섬을 사용하여 감사 기록(Audit Trail)이 변조되지 않았음을 증명하는 방법

본 가이드는 CIO, 리스크 책임자 또는 수직 AI 팀에서 실제로 수행할 순서에 따라 ZizkaDB에 내장된 SHA-256 기반의 위변조 방지 체크섬을 사용하는 방법을 안내합니다. 이 체크섬은 계보(lineage), 재현(replay), 그리고 특정 시점 검색(point in time retrieval) 아래에 위치하는데, 이는 세 가지 기능 모두 기록이 진실하다고 가정하기 때문입니다. 다음 단계는 이를 증명하는 방법입니다.

시작하기 전에: SHA-256이란 무엇인가
SHA-256은 암호화 해시 함수(cryptographic hash function)입니다. 이 함수에 어떤 데이터 조각, 문장, 로그 항목 또는 전체 파일을 입력하면, 해당 데이터를 나타내는 고정 길이의 지문(fingerprint), 즉 64자 길이의 결과값을 반환합니다.

감사(auditing) 목적으로 유용하게 만드는 세 가지 속성이 있습니다.

1. 결정론적입니다 (deterministic). 동일한 입력은 항상 동일한 지문을 생성합니다. 누구든지 언제든지 이를 재계산하여 같은 답을 얻을 수 있습니다.
2. 극도로 민감합니다 (extremely sensitive). 입력의 단일 문자만 변경하거나, 거래 금액의 한 자리 숫자나 의사 결정의 한 단어만 변경해도 지문은 완전히 달라집니다.
3. 일방향입니다 (one way). 이 지문으로부터 원래 데이터로 역추적할 수 없으며, 실제로 동일한 지문을 생성하는 다른 입력을 만들 수도 없습니다. SHA-256은 NIST가 표준화한 SHA-2 계열의 일부이며, 은행업, 소프트웨어 서명 및 인증서 인프라에서 널리 사용됩니다.

이를 포장재에 붙인 위변조 봉인(tamper seal)이라고 생각하십시오. 이 봉인이 누군가에게 포장을 여는 것을 막지는 못하지만, 만약 누군가가 열었다면 그것을 알 수 있습니다.

1단계: 무엇이 증명되어야 하는지 결정하기
로그의 가치는 신뢰할 수 있는 정도에 달려 있습니다. 감사자, 규제 기관 또는 법원은 기록 내용뿐만 아니라 그 기록이 이후에 변경될 수 있었는지 여부도 묻습니다.

기록이 의문시될 수 있는 상황 목록을 작성하십시오: 고객 분쟁, 감독 검토(supervisory reviews), 기업 구매자의 보안 설문지, 내부 조사. 에이전트 AI(agentic AI)의 경우 이는 평소보다 더 중요합니다. 왜냐하면 에이전트가 논란이 되는 결정을 내렸다면, 그 결정에 대한 로그가 증거이기 때문입니다. 이 목록은 아래 단계에 대한 수용 기준(acceptance criteria)이 됩니다.

2단계: 지속적인 이벤트 로깅 활성화
에이전트를 ZizkaDB에 연결하여 사용자 메시지, 의사 결정, LLM 호출, 도구 호출 및 응답 등 모든 이벤트가 발생하는 즉시 캡처되도록 합니다. 기록된 모든 이벤트에는 해당 콘텐츠로부터 SHA-256 체크섬이 계산되어 이벤트와 함께 저장됩니다.

다음 단계로 넘어가기 전에 완전성을 확인하십시오. 테스트 세션을 실행하고 첫 메시지부터 최종 응답까지 각각의 세션이 재구성될 수 있는지 확인합니다. 체크섬은 기록된 내용을 보호하므로, 캡처에 공백이 있으면 보호에도 공백이 생깁니다.

3단계: 주변 제어 장치 잠그기
체크섬은 변조를 감지 가능하게 만들 뿐, 불가능하게 만드는 것은 아닙니다. 이것이 '변조 증거(tamper evident)'의 의미입니다. 예방은 그 주위의 제어 장치에서 나오므로, 다음 사항들을 지금 설정하십시오:

• 테넌트 격리: 각 팀 또는 사업 부문이 자신의 기록에만 접근하도록 합니다.
• 범위가 지정된 API 키: 각 에이전트가 작성해야 하는 내용에 대해서만 쓸 수 있도록 합니다.
• 데이터베이스에 대한 제한적인 쓰기 및 관리자 액세스
• 데이터 거주지 또는 보안 요구 사항이 필요로 하는 자체 호스팅(Self hosted) 또는 VPC 배포

보장의 강도는 체크섬이 어떻게 저장되고 보호되는지에 달려 있습니다. 공격자가 이벤트와 그 체크섬을 모두 다시 쓸 수 있다면, 독립적인 체크섬만으로는 이를 포착할 수 없습니다.

4단계: 더 엄격한 요구 사항을 위한 외부 계층 추가
요구 사항이 엄격하다면(은행업계처럼 종종 그렇듯이), 데이터베이스 관리자가 무시할 수 없는 보호 장치를 추가하십시오. 옵션에는 체크섬을 관리자가 수정할 수 없는 스토리지로 주기적으로 내보내거나, 일정에 따라 외부에서 체크섬을 앵커링하는 것이 포함됩니다. 체크섬을 유일한 계층이 아닌 강력한 한 계층으로 취급하십시오.

5단계: 주기적으로 무결성 검증하기
검증은 간단합니다. 저장된 이벤트로부터 체크섬을 재계산하여 기록된 체크섬과 비교합니다. 일치하면, 해당 이벤트는 작성되었을 때와 정확히 같습니다. 일치하지 않으면, 무언가 변경되었고 어떤 이벤트인지 알 수 있습니다.

사건이 발생하기를 기다리지 마세요. 예를 들어 매주 정기적으로 검증을 실행하고, 불일치 사항을 검토할 담당자를 지정하세요. 모든 무결성 문제는 악의적인 것이 아닙니다. 잘못된 마이그레이션(migrations), 스토리지 오류(storage faults), 버그가 있는 스크립트도 데이터를 변경하며, 체크섬은 원인에 관계없이 이를 표시합니다.

6단계: 기록에 의문을 제기하는 경우를 대비한 절차 마련하기
시스템을 구축한 엔지니어뿐만 아니라 모든 분석가가 따를 수 있도록 표준 절차를 작성하세요:

1. 문제의 세션 또는 이벤트를 가져옵니다.
2. 해당 데이터에 대해 체크섬 검증을 실행합니다.
3. 그 결과를 사례 파일에 기록합니다.
4. 증거와 함께 검증 결과를 감사관(auditor), 옴부즈맨(ombudsman) 또는 법률 자문가에게 전달합니다.
   이것은 “저희를 믿으세요”라는 주장을 “여기 검증 결과가 있습니다”로 바꿉니다.

7단계: 보안 심사를 위한 답변 준비하기
은행, 보험, 의료 분야의 기업 구매자들은 감사 데이터의 무결성을 어떻게 보호하는지 묻습니다. 표준을 명시하고, 모든 이벤트가 체크섬 처리됨을 설명하며, 3단계와 4단계에서 다룬 주변 통제(controls)를 설명하고, 검증 데모를 제공하는 간결한 답변을 준비하세요. 그들이 이미 신뢰하는 알고리즘에 기반한 구체적인 답변은 대화를 단축시킵니다.

8단계: 규정과 연계하기, 적절한 기대치와 함께
EU AI Act는 고위험 시스템이 추적성(traceability)과 시장 출시 후 모니터링을 지원하는 로그를 유지할 것을 요구하며(제12조), 기술적 견고성과 사이버 보안을 요구합니다(제15조). 은행 분야에서는 DORA와 감독 기관의 기록 보관 기대치가 같은 방향을 가리킵니다. 이들 중 어느 것도 SHA-256을 구체적으로 언급하지 않으며, 체크섬만으로는 시스템이 규정을 준수한다고 만들지 않습니다. 하지만 이는 귀하의 로그가 신뢰할 수 있다는 주장을 뒷받침하는 구체적이고 검증 가능한 통제(control)를 제공하며, 이것이 바로 규제 기관이 테스트하는 주장입니다.

9단계: 파일럿을 실행하고 측정하기
기존 프로세스와 병행하여 검증을 실행하고 전후를 측정하세요:

의심되는 기록을 신뢰할 수 있음을 확립하는 데 걸리는 시간
보안 검토에서 무결성 질문에 답변하는 데 소요되는 시간
변조 여부에 대한 수동 점검에 소요되는 시간
만약 아무것도 변경되지 않는다면, 이것은 현재로서는 주로 보험과 같으며, 그것은 괜찮습니다.

비즈니스 케이스가 어떻게 보이는지
이 수치들은 측정된 결과가 아니라 모델링된 가정입니다. 귀하의 것으로 대체하십시오.

매년 기록 무결성이 의심되는 상황을 10가지라고 가정하고, 시간당 100유로를 적용합니다. 접근 로그(access logs), 변경 이력(change history), 서면 증명(written attestations) 등을 통해 수동으로 신뢰를 확립하는 데는 각각 약 3일이 소요되며, 이는 연간 약 24,000유로의 비용이 발생합니다. 체크섬 검증을 사용하면 각각 약 1시간만 소요되어 연간 약 1,000유로의 비용이 발생합니다.

무결성이 언급되는 연간 기업 거래를 10건이라고 가정하고, 불분명한 답변은 건당 약 3일의 왕래(back and forth)를 추가합니다. 이는 노력과 더 중요하게는 지연 측면에서 대략 24,000유로에 해당합니다. 직접적인 답변은 이 중 대부분을 제거합니다.

변조 여부에 대한 수동 점검은 분기당 2일이 소요되어 연간 약 6,400유로가 발생할 수 있습니다. 자동화된 검증은 이를 적은 수준의 검토 비용으로 줄입니다.

종합적으로 볼 때, 이는 중규모 팀에게 연간 50,000유로 범위에 해당합니다. 더 큰 가치는 증명할 수 있는 기록이 분쟁에서 단지 주장만 할 수 있는 기록보다 훨씬 더 많은 가치를 지닌다는 것입니다.

체크섬이 하지 못하는 것들
그것들은 시퀀스나 카운트를 추적하지 않는 한 전체 기록의 삭제를 막지 못합니다. 그것들은 로깅된 내용이 작성되었을 때 진실했음을 증명하는 것이 아니라, 그 이후로 변경되지 않았다는 것만을 증명합니다. 그것들은 접근 제어(access control), 백업(backups), 또는 모니터링을 대체하지 못합니다. 그것들은 계층적 설계(layered design) 내의 하나의 통제 수단일 뿐입니다.

ZizkaDB가 SHA-256을 사용하는 이유
이것은 감사자(auditor)와 보안 팀이 이미 신뢰하는 표준이기 때문에, 아무도 자체 개발한 것을 평가할 필요가 없습니다. 비용도 저렴하고, 이벤트당 오버헤드가 미미합니다. 그리고 독립적으로 검증 가능합니다: 저장된 이벤트를 가진 누구나 공개 도구로 체크섬을 재계산할 수 있으며, 이는 ZizkaDB의 오픈 소스 및 자체 호스팅 접근 방식에 적합하므로 기록을 검증하기 위해 공급업체(vendor)를 신뢰할 필요가 없습니다.

다음 단계는?
감사 가능성(auditability)의 전제는 다른 누군가가 사용자의 기록을 신뢰할 수 있다는 것입니다. Lineage는 에이전트가 왜 행동했는지 설명하고, Replay는 무슨 일이 일어났는지 보여주며, at()은 시스템이 어떤 상태였는지 보여줍니다. SHA-256 체크섬은 그 기록이 당시 작성된 것과 정확히 같다는 것을 증거와 함께 말할 수 있게 해주는 조용한 기반입니다.

사용자의 산업 분야(vertical)와 고객들이 요구하는 무결성 또는 감사 요건에 대해 알려주시면, 이 수치들을 사용자의 사례에 맞게 조정해 드릴 수 있습니다.

에이전트에서 ZizkaDB를 테스트하고 싶으신가요? 여기에서 저희 오픈 소스 버전을 사용해 보세요: [https://github.com/ZIZKA-AI-SL/ZizkaDB]

디자인 파트너십에 관심 있으신가요? 저희 사이트의 양식을 작성하거나, 또는 저에게 직접 [email protected]로 연락 주세요.
이 글은 원래 Medium에 게시되었으며, 여기에서 볼 수 있습니다:[https://medium.com/@MirArshadTalpur/how-to-use-sha-256-checksums-to-prove-your-audit-trail-has-not-been-tampered-with-b58ed34f9721?postPublishedType=initial]