컴플라이언스와 감사: 부산물로서의 증거

SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security

기록된 실행 이력으로 SOC2 증거 수집과 GDPR 삭제를 쉽게 만들고, 보장하지 않는 부분도 정확히 짚습니다.

컴플라이언스 세금: 감사가 속도를 늦추는 이유

SOC2, ISO27001, HIPAA 감사를 받아 본 적이 있다면 그 고통을 알 것입니다. 감사인이 묻습니다. "모든 사용자 오프보딩 요청이 24시간 이내에 처리되었다는 증거를 보여 주세요."

전통적인 시스템에서는 이 질문이 정신없는 보물찾기로 이어집니다.

이런 수작업 증거 수집은 엔지니어링 시간을 몇 주씩 잡아먹을 수 있습니다. 이것이 바로 컴플라이언스 세금입니다. 최고의 인력을 기능 개발에서 멀어지게 만듭니다. 더 나쁜 것은, 증거가 정황 증거에 그치는 경우가 많다는 점입니다. 스크립트가 실행되었다는 것은 증명할 수 있어도, 그것이 정확히 어떤 데이터를 건드렸는지 증명할 수 있을까요?

감사 추적: 부산물로서의 증거

SchemaBridge는 증거가 실행의 부산물이어야 하며, 별도의 활동이어서는 안 된다고 믿습니다. 엔진은 작업하면서 감사 추적을 기록합니다. 실행의 시작·재실행(replay)·운영자 해결, 워크플로·버텍스·엣지 변경, 배포, 구성 및 보존 기간 변경, 권한 및 역할 변경, 승인 결정이 그 대상입니다.

감사 추적이 제공하는 것
감사 추적이 아닌 것

보장 범위에 대해서는 감사인에게 정확히 설명하세요. 감사 추적은 애플리케이션 수준에서 추가 전용(append-only)이지만, 변조 탐지(tamper-evident)가 가능하지는 않습니다. 해시 체인이나 서명이 없고 감사 기록은 최선 노력(best-effort) 방식으로 쓰이므로, 쓰기 실패가 탐지 가능한 공백으로 드러나지 않습니다. WORM 수준의 증거가 필요하다면, 직접 관리하는 한 번 쓰기(write-once) 저장소로 감사 추적을 내보내세요.

GDPR과 "잊힐 권리"

이력을 보관하는 모든 시스템에서 가장 어려운 과제 중 하나는 "잊힐 권리"(GDPR 제17조)입니다. 이력을 보관한다면 사용자의 PII(개인 식별 정보)는 어떻게 삭제할까요?

삭제와 보존

SchemaBridge는 삭제 경로와 보존 기간으로 이 문제에 접근합니다.

1. 삭제: 워크스페이스를 삭제하면 전용 삭제 경로가 실행됩니다. 이 경로는 되돌릴 수 없는 삭제 전에 기록되고 삭제 후에 검증되는 의무 원장(obligation ledger)으로 뒷받침됩니다. 개별 사용자의 데이터는 별도의 경로로 삭제됩니다.

2. 자동 정리: 보존 기간은 워크스페이스별로 설정됩니다(또는 플랜에서 상속됩니다). 기한이 지난 실행 행, 트레이스, 페이로드는 자동으로 삭제됩니다.

3. 자격 증명 마스킹: 자격 증명 형태의 필드(API 키, 시크릿, 토큰)는 실행 로그에서 로 마스킹됩니다. PII 마스킹은 자동으로 이루어지지 않으므로*, 가장 좋은 방어책은 개인 데이터가 필요 없는 단계로 그것을 전달하지 않는 것입니다.

SOC2 증거 수집 자동화

SchemaBridge 워크플로를 사용해 감사 자체의 일부를 자동화할 수 있습니다.

"감사 봇"

스크린샷을 수작업으로 모으는 대신, 매주 월요일 cron 일정으로 실행되는 전용 "증거 수집" 워크플로를 만듭니다.

1. 스캔: GitHub API를 조회해 지난주에 병합된 모든 PR을 나열합니다.

2. 검증: 각 PR에 code owner의 "Approved" 리뷰가 있는지 확인합니다.

3. 스냅샷: 컴플라이언스 상태의 JSON 스냅샷을 생성합니다.

4. 보관: 감사인이 읽을 수 있는 저장소에 스냅샷을 기록합니다(직접 관리하는 HTTP 엔드포인트를 통해, 이상적으로는 한 번 쓰기 저장소에).

감사인이 오면 스크린샷 더미 대신 아카이브를 안내하면 되고, 그만큼 감사 준비 시간이 줄어듭니다.

{
  "week": "2026-W03",
  "mergedPullRequests": 42,
  "withCodeOwnerApproval": 42,
  "exceptions": []
}

예시 시나리오: 규제 환경에서의 환자 접수

환자 접수 양식을 자동화해야 하는 가상의 HealthTech 스타트업을 생각해 봅시다.

과제

다음을 입증해야 합니다.

1. 권한이 있는 직원만 접수 워크플로를 변경하거나 실행할 수 있었다.

2. 워크플로에 대한 모든 변경과 모든 실행 결과가 기록되었다.

3. 데이터가 서드파티 로깅 도구(Splunk/Datadog)에 노출된 적이 없다.

접근 방식

1. 역할 기반 접근: 워크스페이스 역할(admin, writer, reader)과 권한 범위가 워크플로를 편집·배포·실행할 수 있는 사람을 제한하며, 모든 역할 변경은 감사 추적에 기록됩니다.

2. 기록된 실행: 각 접수 실행의 시작과 운영자 해결은 감사 추적에 남고, 전체 상태 이력은 실행 이력에 보관되며, 각 단계의 페이로드는 stdout에 출력되는 대신 플랫폼 안에서 확인할 수 있습니다.

3. 여전히 직접 책임져야 할 공백: SchemaBridge는 누가 페이로드를 열람했는지 기록하지 않고, HIPAA 전용 역할이 없으며, HIPAA 인증도 보유하고 있지 않습니다. 열람 단위 접근 로깅과 규제 관련 서류 작업은 여전히 그 회사의 책임으로 남습니다.

예상되는 효과

이런 구성이라면 감사 중 변경 관리와 실행 이력에 관한 부분의 부담이 크게 줄어들 것이며, 동시에 플랫폼이 다루지 않는 부분에 대해서도 솔직할 수 있습니다.

비교: 전통적 로깅 vs. SchemaBridge 감사 추적

| 기능 | Syslog / Splunk | 데이터베이스 감사 테이블 | SchemaBridge 감사 추적 |

| :--- | :--- | :--- | :--- |

| 불변성 | 낮음(삭제 가능) | 중간(DBA가 수정 가능) | 중간~높음(애플리케이션 수준 추가 전용, 운영자가 관리하는 저장소) |

| 컨텍스트 | 단일 라인 | 행 변경 | 워크플로 및 실행 컨텍스트 |

| 자격 증명 처리 | 수동 마스킹 | 컬럼 암호화 | 실행 로그에서 자격 증명 필드 마스킹 |

| 보존 | 제한적(비용 높음) | 제한적(성능) | 워크스페이스별 / 플랜별 보존 기간 |

컴플라이언스 아키텍처를 위한 전문가 체크리스트

1. PII를 로그에 남기지 마세요: stdout에 무엇을 출력하는지, 단계 간에 무엇을 전달하는지 주의하세요. 개인 데이터가 필요 없는 페이로드에는 개인 데이터를 넣지 마세요.

2. 증거를 자동화하세요: 수작업으로 하면 실수가 생깁니다. 감사를 스크립트로 만드세요.

3. 직무를 분리하세요: 워크플로를 작성하는 사람이 관리자 키를 보유해서는 안 됩니다.

4. 삭제를 테스트하세요: 정기적으로 "모의 GDPR 요청"을 실행해 삭제 및 보존 경로가 실제로 작동하는지 검증하세요.

5. 플랫폼의 한계를 파악하세요: 저희를 포함한 모든 벤더에게 정확히 무엇이, 얼마 동안 기록되는지, 그리고 변조 탐지가 가능한지 물어보세요. 그 답을 통제 기술서(control narrative)에 반영하세요.

결론: 신뢰는 API다

컴플라이언스는 서류 작업이 아니라 신뢰의 문제입니다. 기록되고 조회 가능한 이력을 기반으로 시스템을 구축하고, 그 이력이 무엇을 보장하고 무엇을 보장하지 않는지 정확히 밝힘으로써, "믿어 주세요, 저는 좋은 엔지니어입니다"에서 "여기 증거가 있습니다"로 나아갈 수 있습니다.

Building the Bridge 시리즈의 일부입니다. 함께 읽어 보세요: 통합의 미래.

살펴보기