보안 컴플라이언스 입문: GDPR·PCI-DSS·ISO 27001 기초

지난 글에서 침해사고가 터졌을 때의 대응 프로세스를 다뤘다. 그런데 그 글에서 “GDPR 72시간 통지”, “개인정보보호법상 의무” 같은 표현이 반복해서 등장했다. 이런 외부 규칙들은 단순한 권고가 아니라, 위반 시 과징금과 법적 책임이 따르는 강제 규범이다. 이번 글에서는 웹 서비스를 운영하는 개발자가 알아야 할 보안 컴플라이언스의 지형을 정리한다. 이것이 보안 운영의 마지막 퍼즐 조각이다.

컴플라이언스란, 그리고 왜 개발자가 알아야 하는가

보안 컴플라이언스는 법규, 산업 표준, 계약상 의무가 요구하는 보안 통제를 충족하고 그것을 증명하는 활동이다. “우리는 규정이 요구하는 만큼 안전하게 데이터를 다루고 있다”를 외부에 입증하는 일이라고 볼 수 있다.

흔히 컴플라이언스를 법무팀이나 보안팀의 일로 여기지만, 실제로 요구사항을 구현하는 것은 개발자다. “암호화하여 저장하라”, “접근 로그를 남겨라”, “최소 권한을 적용하라”, “데이터 삭제 요청을 처리하라” — 이 모든 항목이 코드와 인프라 설정으로 귀결된다. 그래서 개발자가 큰 그림을 이해하고 있으면 설계 단계에서부터 컴플라이언스를 내재화할 수 있고, 출시 직전에 급하게 뜯어고치는 사태를 피할 수 있다. 앞서 다룬 Secure SDLC의 “요구사항 단계”에 컴플라이언스 요구사항이 함께 들어가야 하는 이유다.

주요 컴플라이언스 지형

어떤 규제·표준이 적용되는지는 “무엇을, 누구의 데이터를, 어디서 다루는가”에 따라 결정된다. 대표적인 것들을 정리하면 다음과 같다.

GDPR(EU 일반개인정보보호법) 은 EU 거주자의 개인정보를 다루는 모든 조직에 적용된다. 한국 기업이라도 EU 사용자가 있으면 대상이다. 핵심은 명시적 동의, 정보주체의 권리(열람·정정·삭제·이동권), 그리고 침해 시 72시간 내 통지다. 과징금이 전 세계 연 매출의 최대 4%에 달해 강제력이 강하다.

국내 개인정보보호법과 ISMS-P 는 국내에서 개인정보를 처리하는 사업자에게 적용된다. 수집·이용 동의, 안전성 확보 조치(암호화, 접근통제, 접속기록 보관 등)가 법적 의무이며, 일정 규모 이상 사업자는 ISMS-P(정보보호 및 개인정보보호 관리체계) 인증이 의무화되어 있다.

PCI-DSS 는 신용카드 데이터를 취급하는 모든 주체에 적용되는 보안 표준이다. 법규가 아니라 카드 브랜드와의 계약상 의무라는 점이 특징이다. 12개 요구사항(네트워크 분리, 카드 데이터 암호화, 접근 통제, 정기 점검 등)으로 구성된다. 그래서 많은 서비스가 카드 데이터를 직접 저장하지 않고 PG사·토큰화 서비스에 위임해 적용 범위를 줄인다.

ISO 27001 은 성격이 다르다. “무엇을 보호하라”가 아니라 “정보보안을 어떻게 경영하라”를 다루는 정보보안경영시스템(ISMS) 국제표준이다. 위험 평가 → 통제 선택 → 운영 → 개선의 사이클을 요구한다. 자발적 인증이지만 B2B 거래에서 신뢰를 입증하는 수단으로 널리 쓰인다.

SOC 2 는 특히 SaaS 업계에서 사실상 입장권이 된 보고서다. AICPA의 신뢰 서비스 기준(보안·가용성·처리 무결성·기밀성·프라이버시)에 따라 통제가 적절히 설계·운영되는지를 외부 감사인이 평가한다. 특정 시점을 보는 Type I과, 일정 기간 동안의 통제 운영을 보는 Type II로 나뉘며, B2B 고객은 대개 Type II를 요구한다.

핵심 통찰: 컴플라이언스는 보안의 최소 기준선이다

가장 중요한 관점이 이것이다. 컴플라이언스를 통과했다는 것이 안전하다는 뜻은 아니다.

컴플라이언스는 본질적으로 “정해진 항목을 특정 시점에 충족했는가”를 본다. 감사와 증빙이 중심이고, 최소 기준 충족이 목표다. 반면 실질 보안은 “지금 이 순간 실제로 안전한가”라는 상시적 상태이며, 위협 모델과 통제의 실효성이 중심이다.

이 둘이 어긋난 사례는 많다. PCI-DSS 인증을 받은 기업이 대형 카드 정보 유출을 겪은 사례, 모든 규정 항목에 체크를 했지만 실제로는 작동하지 않는 통제를 가진 조직. 체크박스를 다 채우는 데 집중하다 보면 “규정에 없는” 위협을 놓친다. 규제는 항상 과거의 사고를 반영하므로, 새로운 공격 기법보다 늦다.

그렇다고 컴플라이언스가 무의미한 것은 결코 아니다. 올바른 관점은 이렇다.

컴플라이언스를 출발점으로 삼되, 목표로 삼지 않는다. 규정은 “최소한 여기까지는 해야 한다”는 바닥이지 “여기까지만 하면 된다”는 천장이 아니다.

지금까지 다뤄온 위협 모델링, 다층 방어, 최소 권한 같은 원칙들은 컴플라이언스 항목 너머의 실질 보안을 만든다. 가장 좋은 전략은 실질 보안을 제대로 구축하는 것이다. 그러면 대부분의 컴플라이언스 요구사항은 자연스럽게 따라온다 — 그 반대는 성립하지 않는다.

개발자를 위한 실무 접근

컴플라이언스를 매번 압박으로 겪지 않으려면, 평소의 엔지니어링에 녹여 두는 것이 답이다.

설계 단계   : 데이터 분류부터 — 어떤 데이터가 개인정보/카드정보인지
            식별하면 적용 규제와 통제가 따라온다
구현 단계   : 암호화(저장·전송), 접근 통제, 감사 로깅은
            대부분 규제의 공통 분모 — 한 번 잘 만들면 다목적
운영 단계   : 접속 기록 보관, 정기 권한 검토, 침해 통지 절차를
            프로세스로 — 감사 때 증빙이 자동으로 쌓이도록
증빙 자동화 : 정책을 코드로(Policy as Code), 통제 증거를
            파이프라인에서 자동 수집 → 감사 부담 최소화

특히 데이터 분류가 모든 것의 출발점이다. 우리가 어떤 종류의 데이터를 다루는지 정확히 알면, 어떤 규제가 적용되고 어떤 통제가 필요한지가 자동으로 도출된다. 반대로 이것을 모르면 과한 통제로 비용을 낭비하거나, 부족한 통제로 위반 위험을 떠안는다.

마무리하며 한 걸음 더

여기까지 웹 보안의 예방(시큐어 코딩·공급망), 검증(테스트·침투 테스트·바운티), 탐지와 대응(SIEM·IR), 그리고 이를 규율하는 컴플라이언스까지 큰 흐름을 짚었다. 마지막으로 강조하고 싶은 것은, 이 모든 활동의 토대에 “신뢰할 수 있는 기록”이 있다는 점이다. 침해를 탐지하려면, 사고를 조사하려면, 컴플라이언스를 증빙하려면 — 결국 안전하고 변조 불가능한 감사 로그가 필요하다. 그래서 다음 글에서는 그 기반이 되는 보안 감사 로깅을 다룬다.

---

지난 글: 침해사고 대응: 탐지부터 복구까지의 IR 프로세스

읽어주셔서 감사합니다. 😊