스프린트 플래닝 중 누군가가 “앱을 GDPR 준수하도록 만들어야 해”라고 말합니다.
그 문장은 보통 엔지니어링 팀에 법적 리스크, 제품 재설계, SDK 정리, 릴리스 마찰이 모호하게 섞인 덩어리로 다가옵니다. 누군가는 쿠키 배너를 추가하는 일이라고 생각합니다. 또 누군가는 분석 도구를 삭제하는 일이라고 보고요. 세 번째 사람은 고객 보안 검토가 조달 블로커로 번질 때까지 법무팀 문제라고 생각합니다.
개발자에게 유용한 질문은 GDPR 준수가 이론적으로 무엇인지에 그치지 않습니다. 코드베이스, 데이터 흐름, 릴리스 프로세스, 벤더 설정에서 무엇이 바뀌는지가 핵심입니다. 많은 개발자가 바로 이 지점에서 막힙니다.
위험은 현실입니다. 2018년 5월 이후 규제 당국은 27억 유로의 벌금을 부과했으며, GDPR은 또한 EU 기업 평균 이익 8% 감소 및 신규 앱 진입 50% 감소, 이는 컴플라이언스 문제이자 제품 전략 문제가 된다고 이 GDPR 집행 및 시장 영향 수치가 보여줍니다. 앱에서 사용자 식별자, 분석 이벤트, 지원 로그, push token 또는 광고 기술을 다룬다면, 이미 구현 디테일이 중요한 영역에 들어선 것입니다.
GDPR 대응을 잘하면 단순히 방어에 그치지 않습니다. 보통 팀에는 더 깔끔한 아키텍처, 정체불명 SDK 감소, 더 나은 감사 추적, 동의에 대한 더 의도적인 접근이 남습니다. 앱 권한, 분석 이벤트 또는 동의 UX를 다루고 있다면, 이 가이드를 참고하세요: 앱 컴플라이언스에 동의 관리가 중요한 이유 유용한 참고 자료입니다.
목차
- 서론: 모든 개발자가 두려워하는 다섯 단어
- GDPR의 7가지 핵심 원칙
- 컨트롤러 vs 프로세서: 누가 무엇을 책임지나
- 미준수의 재무적·운영적 비용
- 모바일 개발자를 위한 실전 GDPR 플레이북
- CI/CD와 Live Update 시대의 컴플라이언스
- 앱 개발을 위한 GDPR 준수 체크리스트
서론: 모든 개발자가 두려워하는 다섯 단어
팀들이 GDPR를 처음 마주하는 방식은 대개 가장 비효율적인 형태입니다. 영업 담당자가 보안 설문지에서 준수 사항을 묻거나, 프로덕트 매니저가 유럽 시장 출시를 서두르거나, 법무팀이 엔지니어링 작업이 아닌 정책 문서처럼 읽히는 요구사항 목록을 보내오는 식입니다.
그때부터 'GDPR 준수'는 혼란으로 변합니다. 엔지니어는 앱이 개인 데이터에 접근하는 모든 지점을 찾아다니기 시작합니다. 분석 SDK이 기기 식별자를 수집하고 있나요? 크래시 리포트가 사용자 ID와 연결되어 있나요? 지원 도구가 사용자 콘텐츠를 벤더에게 노출하고 있나요? 모바일 앱이 로그아웃 후에도 로컬 스토리지에 오래된 프로필 데이터를 유지하고 있나요?
실무 원칙: GDPR 준수는 배너나 체크박스가 아니라 데이터 흐름 가시성에서 시작됩니다.
개발자 관점에서 GDPR은 개인 데이터가 시스템을 통해 어떻게 이동할 수 있는지에 대한 규칙 세트입니다. 이는 스키마 설계, 클라이언트 텔레메트리, 데이터 보존 작업, 액세스 제어, 벤더 계약, 배포 워크플로에 영향을 미칩니다. 앱이 EU 사용자를 대상으로 한다면 이것도 업무의 일부입니다.
흔히 하는 실수는 이를 일회성 법적 승인으로 취급하는 것입니다. 그렇게 하면 보통 오래된 문서와, 문서와 다르게 동작하는 실제 제품이 남습니다. 잘 처리하는 팀은 프라이버시를 일상적인 엔지니어링 운영에 내재화합니다. 이들은 무엇을, 왜 수집하는지, 누가 받는지, 얼마나 오래 보관하는지, 어떻게 끌 수 있는지 정확히 압니다.
GDPR의 7가지 핵심 원칙
원칙을 아키텍처 제약 조건으로 생각하세요
7가지 원칙을 법적 슬로건이 아닌 엔지니어링 제약 조건으로 이해하면 훨씬 쉽습니다.
- 적법성, 공정성, 투명성 데이터를 처리할 정당한 근거가 있어야 하고, 동작이 오해를 불러일으켜서는 안 되며, 사용자가 자신의 데이터가 어떻게 처리되는지 이해할 수 있어야 한다는 뜻입니다.
- 목적 제한 특정 기능을 위해 수집한 데이터를 나중에 사전 공지 없이 전혀 다른 목적으로 재사용해서는 안 된다는 뜻입니다.
- 데이터 최소화 가장 작은 유용한 데이터 세트만 수집하라는 뜻입니다. 패키지 전체 대신 필요한 함수만 import하는 것과 같습니다.
- 정확성 사용자 데이터가 의사결정이나 커뮤니케이션에 사용된다면, 수정 경로와 업데이트 경로가 필요합니다.
- 저장 제한 데이터베이스가 다락방이 아니라는 뜻입니다. 더 이상 필요 없는 데이터는 어떻게 삭제할지 정의해야 합니다.
- 무결성과 기밀성 안전한 처리를 의미합니다. 암호화, 접근 제어, 시크릿 관리, 감사 가능성이 여기에 해당합니다.
- 책임성 단순히 프라이버시를 중시한다고 주장하는 것이 아니라, 위 내용을 증명해야 한다는 뜻입니다.
개발자가 이를 활용해 할 일
이 원칙들은 앱 동작에 매핑하면 구체화됩니다:
| 원칙 | 개발자 관점 해석 |
|---|---|
| 법적 근거와 투명성 | 수집 전 명확한 고지를 표시하고 각 플로우의 법적 근거를 로깅하세요 |
| 목적 제한 | 분석, 지원, 마케팅, 핵심 제품 데이터 경로를 분리하세요 |
| 데이터 최소화 | SDK, 이벤트 페이로드, 요청 본문에서 불필요한 필드를 감사하세요 |
| 정확성 | 오래된 사본이 남지 않는 계정 편집, 수정, 동기화 로직을 구축하세요 |
| 저장 제한 | 적용 가능한 경우 백업을 포함하여 보존 작업 및 삭제 워크플로를 추가하세요 |
| 보안 | 전송 중 및 저장 시 데이터를 보호하고, 내부 접근을 제한하며, 변경 사항을 모니터링하세요 |
| 책임성 | 처리 기록, 벤더 문서, 구현 노트를 최신 상태로 유지하세요 |
분산 시스템 전반에 걸친 사용자 요청 삭제 및 정리도 간과하기 쉬운 영역입니다. 앱이나 사이트에서 개인 콘텐츠를 공개적으로 표시하는 경우, 실무 가이드는 온라인 GDPR 데이터 삭제 팀이 기본 데이터베이스 밖의 삭제까지 검토하도록 돕습니다.
팀은 보통 GDPR의 주변부에서 실패합니다. 오래된 logs, 잊힌 staging 데이터, 방치된 SDK, 제3자에게 보낸 export 데이터가 메인 앱 데이터베이스보다 더 큰 문제를 일으킵니다.
컨트롤러 vs 프로세서: 누가 무엇을 책임지나
역할을 모델링하는 간단한 방법
레스토랑 예시를 들어 보세요. 레스토랑은 어떤 음식을 만들지, 고객 정보를 왜 수집하는지, 주문을 어떻게 처리할지 결정합니다. 이것이 바로 컨트롤러입니다. 주문 정보를 받아 배송을 완료하는 배달 플랫폼은 그런 역할에 더 가깝습니다 처리자. 식당을 대신해 데이터를 처리합니다.
소프트웨어에서 귀사는 사용자 계정 데이터, 제품 의사결정과 관련된 분석, 고객 지원 기록, 앱 내 행동 추적에 대한 컨트롤러인 경우가 많습니다. 클라우드 제공업체, 이메일 발송 업체, 고객 지원 도구, 텔레메트리 플랫폼은 그중 일부 작업에서 처리자 역할을 할 수 있습니다.
실질적인 구분은 이렇습니다:
- 컨트롤러 처리 목적과 수단을 결정합니다.
- 프로세서 컨트롤러의 지시에 따라 데이터를 처리합니다.
- 개발자 통합 방식이 시스템 밖으로 나가는 데이터와 그 조건을 결정하므로 두 역할 모두에 영향을 줍니다.
개발자들이 흔히 실수하는 부분
흔히 하는 실수는 벤더를 '단순 인프라'로 치부하고 역할 분석을 건너뛰는 것입니다. 만약 SDK가 식별자를 캡처하거나 페이로드를 전달하거나 로그를 저장하거나 사용 패턴을 프로파일링한다면, 팀은 해당 벤더가 정확히 무엇을 하는지, 누구의 지시를 따르는지 반드시 파악해야 합니다.
바로 이 지점에서 계약이 중요합니다. 벤더 의무, 보안 책임, 책임 경계에 관한 문구를 검토 중이라면, 데이터 보호에 관한 Technovation LLC의 이 분석 자료는 실용적인 참고가 될 것입니다. 외부 서비스를 사용하는 앱 팀에게 계약은 사후 서류가 아니라 구현의 일부입니다.
유용한 습관은 네 가지 항목으로 구성된 벤더 레지스터를 관리하는 것입니다: 취급하는 데이터 카테고리, 처리 목적, 해당 흐름에서 벤더가 컨트롤러인지 프로세서인지 여부, 관련 계약서입니다. 프로세서 약관의 시작점이 필요하다면, 데이터 처리 계약(DPA) 예시는 팀이 운영상 어떤 약속을 보통 명시해야 하는지 파악하는 데 도움이 됩니다.
미준수의 재무적·운영적 비용
벌금 상한이 엔지니어링 팀에 의미하는 것
개발자가 금요일에 릴리스를 배포합니다. 월요일, 법무팀이 간단한 질문을 던집니다. '왜 앱이 개인정보 처리방침에 명시되지 않은 벤더에게 기기 식별자를 보내고 있나요?'
많은 GDPR 문제가 이렇게 시작됩니다. 극적인 유출이 아니라, 문서화·동의 로직·벤더 검토 프로세스보다 빠르게 배포된 일상적인 변경 때문입니다.
재무적 리스크는 로드맵 결정을 바꿀 만큼 큽니다. 제83조에 따라 GDPR 벌금은 2,000만 유로 또는 전 세계 연간 총 매출액의 4%에 달할 수 있습니다. Advisense의 GDPR 과징금 개요 또한 제5조 처리 원칙과 관련된 심각한 위반 사례로 인해 이미 수십억 유로에 달하는 수백 건의 과징금이 부과되었다고 언급합니다.
개발자에게 주는 실질적인 교훈은 명확합니다. 비용이 큰 실패는 대개 일반적인 제품 및 플랫폼 작업에서 비롯됩니다. 적법한 근거 없이 데이터를 수집하거나, 명시된 목적을 넘어 사용하거나, 필요 이상으로 오래 보관하거나, 취약한 접근 제어·로깅·벤더 통합을 통해 노출하는 경우입니다.
엔지니어링 팀이 과징금을 맞기 훨씬 전부터 비용을 체감하는 이유
GDPR 위반은 대개 뉴스 헤드라인을 장식할 만한 대형 사고로 시작되지 않습니다. 릴리스, 환경, 의존성 전반에 걸친 엔지니어링 드리프트에서 시작됩니다.
모바일 팀이 분석용 SDK 이벤트를 추가하면서 동의 게이팅(consent gating)을 업데이트하지 않습니다. 웹 앱이 데이터 인벤토리에 정의되지 않은 지원 메타데이터를 수집하기 시작합니다. 시간을 아끼려고 운영 환경의 실제 사용자 레코드를 스테이징 환경으로 복사합니다. CI/CD를 통한 핫픽스로 전송되는 데이터가 변경되었지만, 아무도 개인정보 처리방침이나 보관 규칙을 다시 확인하지 않습니다.
리스크는 침해 사고만이 아닙니다. 시스템이 실제로 하는 일과 조직이 한다고 말하는 일 사이의 간극이 바로 리스크입니다.
이 간극은 엔지니어링 팀이 이미 부담을 느끼는 영역에서 추가 업무를 만듭니다. 엔터프라이즈 고객은 조달 과정에서 보안 및 개인정보 보호 검토를 요구합니다. 어떤 사용자가 영향을 받았는지, 어떤 SDK에 어떤 필드가 전달되었는지, live update이 수집 동작을 변경했는지에 대한 답변이 없어 인시던트 대응이 지연됩니다. 지원 및 법무 팀은 답변이 code, 파이프라인 설정, 벤더 대시보드, 릴리스 히스토리에 흩어져 있어 요청을 엔지니어링 팀으로 되돌려 보냅니다.
이유로 개발자는 명확한 플레이북을 갖추어야 합니다. 서드파티 침해 대응 모범 사례앱이 외부 SDK, 텔레메트리 서비스, 크래시 리포트, 기능 플래그 또는 live update 툴링에 의존한다면, 데이터 흐름을 빠르게 추적하고 정확히 설명할 수 있는지가 컴플라이언스를 좌우합니다.
모바일 개발자를 위한 실전 GDPR 플레이북
실제로 관리할 수 있는 데이터 인벤토리부터 시작하기
모바일 팀이 통제력을 잃는 가장 빠른 방법은 백엔드 테이블에만 집중하는 것입니다. 앱 자체는 SDK, 로그, 캐시, 알림 시스템, 기능 플래그, 크래시 리포트를 통해 데이터를 수집하고 전송합니다.
작동하는 인벤토리부터 시작하세요:
- 모든 입력 지점 나열회원가입 폼, 백그라운드 동기화, 분석 이벤트, 푸시 등록, 지원 채팅, 결제 화면, 진단.
- 모든 출력 지점 매핑귀하의 API, 서드파티 SDK 엔드포인트, 지원 벤더, CDN, 모니터링 도구.
- 식별자 플래그 지정. 이메일, 전화번호, 계정 ID, IP 관련 메타데이터, 기기 ID, 푸시 토큰, 위치 정보, 개인과 연결될 수 있는 모든 필드.
- 보관 및 삭제 추적. 데이터가 어디에 저장되는지뿐 아니라 앱 저장소, 백엔드 시스템, 벤더 시스템에서 어떻게 삭제되는지도 중요합니다.
하이브리드 앱을 개발 중이라면, 이 가이드는 Capacitor 앱의 사용자 데이터 처리 로컬 저장소, 플러그인 동작, 동기화 경계를 고민하게 만든다는 점에서 유용한 엔지니어링 참고 자료입니다.
동의를 팝업이 아닌 제품 동작으로 다루기
부실한 동의 UX는 기술 부채를 만듭니다. 사용자가 '모두 동의'를 할 수는 있지만 나중에 선택을 쉽게 변경할 수 없다면, 배너가 제때 배포되었더라도 구현은 취약합니다.
개발자는 동의 상태를 앱 상태 모델에 연결해야 합니다:
- 비필수 수집을 기본적으로 차단 사용자가 선택할 때까지.
- 버전 관리와 함께 동의 결정을 저장합니다 사용자가 당시 어떤 프롬프트를 보았는지 확인할 수 있도록 합니다.
- 동의 상태 전파 애널리틱스, 광고, 지원 도구, 실험 프레임워크로 전파합니다.
- 철회 처리 실제 이벤트로 처리합니다. 향후 수집을 중단하고 이미 수집된 데이터에 대한 처리 방식을 결정하세요.
DPIA가 필요한 시점
GDPR 제35조는 데이터 보호 영향 평가(DPIA) 고위험 처리를 시작하기 전에 수행해야 하며, 준수하는 DPIA에는 처리 목적, 필요성 평가, 사용자 위험 평가, 암호화 등 보호 조치를 명시해야 합니다. Bloomberg Law의 GDPR 요약에 따르면.
개발자에게 DPIA는 민감한 데이터 흐름에 대한 구조화된 사전 출시 리스크 리뷰입니다. 프로파일링, 대규모 민감 데이터 처리, 사용자에게 실질적 영향을 줄 수 있는 모니터링 패턴 등이 도입될 때 이를 예상해야 합니다.
유용한 DPIA 워크플로우는 다음과 같습니다:
- 기능 설명 데이터가 어디로 이동하는지 포함해 쉬운 말로 설명하세요.
- 필요성 입증. 각 필드가 왜 필요한가요?
- 리스크 모델링 시스템 가동 시간만이 아닌 사용자 관점에서.
- 보호 조치 정의 암호화, 접근 제어, 가명화, 레이트 리밋, 검토 게이트, 삭제 경로 등.
- 결정 기록 출시 후가 아니라 출시 전에.
보안 및 사고 대응
보안 조치는 GDPR 준수의 일부이지 별개의 영역이 아닙니다. 앱 팀이라면 보통 안전한 전송, 시크릿 보호, 최소 권한 접근, 신중한 로그 설계, 서드파티 SDK의 방어적 기본값을 뜻합니다.
사고 대응 준비를 운영 수준으로 유지하세요:
- 소속 책임자 사전 지정 엔지니어링, 보안, 법무, 지원 팀에 걸쳐.
- 조사에 충분한 로그 기록 민감한 원본 페이로드를 모든 곳에 기록하지 않도록.
- 격리 조치 연습 위협된 토큰, 잘못된 릴리스, 벤더 측 사고에 대비하여.
- 데이터 노출 경로 문서화 긴급 상황에서도 추측하지 않도록.
CI/CD와 Live Update 환경에서의 컴플라이언스
번들 배포도 처리에 해당할까
이러한 맥락에서 오래된 GDPR 가이드는 더 이상 유용하지 않을 수 있습니다. 현대 앱은 앱 스토어만 통해 배포되지 않습니다. 팀들은 CI/CD 파이프라인과 live update 시스템을 통해 JavaScript 번들, 설정 변경, 기능 플래그, 로컬라이즈된 카피, 원격 에셋을 푸시합니다.
앱이 EU 거주자에게 서비스를 제공하면 GDPR은 EU 외부에도 적용됩니다. 실용적인 준수 공백 중 하나는 클라우드 서비스를 통해 전달되는 서명된 웹 번들과 같은 동적 에셋 업데이트가 처리에 해당하는지, 따라서 제30조 문서화 요구사항을 유발하는지 평가하지 않는 것입니다. 이는 일반적인 GDPR 준수 실수에 대한 이 논의에서 언급된 바와 같습니다.
모든 에셋 푸시가 자동으로 프라이버시 이벤트라는 뜻은 아닙니다. 올바른 엔지니어링 질문을 해야 한다는 뜻입니다:
- 업데이트 서비스가 어떤 메타데이터를 확인합니까 예: 기기 식별자, IP 관련 정보, 채널, 버전, 롤아웃 상태 등
- 전달, 재시도, 롤백, 또는 관찰 가능성 과정에서 사용자 연결 텔레메트리가 저장됩니까 배포, 재시도, 롤백 또는 가시성 관리는 어떻게 하나요?
- 업데이트 타겟팅이 사용자 세분화를 의미합니까 지역, 고객, 플랜, 또는 행동 기준
- 빌드 로그나 릴리스 주석에 개인 데이터가 포함됩니까 티켓, 지원 노트, 또는 디버깅 필드에서
서비스가 식별 가능한 기기 정보나 사용자와 연결된 메타데이터를 다룬다면, 개인정보 관련 시스템으로 보고 그에 맞게 문서화하세요.
벤더 검토는 앱 아키텍처의 일부입니다
CI/CD 및 live update 벤더도 분석 및 지원 도구만큼 꼼꼼히 검토해야 합니다. 로깅 모델, 보존 방식, 접근 제어, 지역별 처리, 서명 모델, DPA 제공 여부를 확인하세요. 시장 구조도 여기서 중요합니다. 대형 기존 업체는 컴플라이언스 부담을 더 쉽게 흡수하는 반면, 소형 벤더도 데이터 처리에 투명하고 처리 범위를 좁게 유지한다면 여전히 유효한 선택지가 될 수 있습니다.
하이브리드 모바일 팀을 위한 이 카테고리의 한 가지 옵션은 Capgo입니다. 이 도구는 Capacitor 앱에 서명된 웹 번들을 전달하고 채널, 관측성, 롤백 같은 릴리스 제어를 제공합니다. 중요한 질문은 도구가 컴플라이언스에 부합하는 것처럼 들리는지가 아닙니다. 해당 도구가 어떤 데이터를 처리하는지, 왜 처리하는지, 그리고 이를 뒷받침하는 계약과 제어가 무엇인지 정확히 설명할 수 있는지가 핵심입니다.
실용적인 방법은 릴리스 파이프라인에 컴플라이언스 검사를 직접 추가하는 것입니다. 빌드에서 새로운 텔레메트리나 업데이트 동작이 도입될 때마다 팀은 환경 설정, 데이터 수집 변경 사항, 벤더 영향을 확인해야 합니다. 이 가이드는 Capacitor 앱을 위한 CI/CD 컴플라이언스 체크 에 대한 것으로, 해당 검토를 마지막 순간의 논의가 아닌 반복 가능한 게이트로 전환하는 데 좋은 출발점이 됩니다.
앱 개발을 위한 GDPR 준수 체크리스트
설계 및 구축
이 리스트를 킥오프 이후 아무도 열어보지 않는 정책 문서가 아니라, 실제로 쓰는 체크리스트로 활용하세요.
-
개인 데이터 흐름 파악. 앱이 수집하는 데이터, 전송 경로, 어떤 벤더가 받는지, 각 필드의 수집 목적을 문서화하세요.
Capgo 준수 사항: 기기 관련 메타데이터를 확인하는 모든 업데이트 또는 배포 플랫폼은 이 맵에 포함되어야 합니다. -
SDK 수집 최소화. 분석, 크래시 리포팅, 어트리뷰션, 채팅, 광고 SDK를 점검하세요. 필요 없는 기본 데이터 수집은 끄세요. Capgo 준수 사항: 사용자 대상 SDK뿐 아니라 릴리스 툴링에도 같은 검토를 적용하세요.
-
세밀한 동의 제어 구축. 필수 처리와 분석, 마케팅, 개인화, 선택적 진단을 분리하세요. Capgo 준수 사항: 릴리스 시점의 설정 변경이 앱에 이미 배포된 동의 모델과 일치하도록 유지하세요.
-
사용자 권리 운영 지원. 엔지니어는 주요 시스템과 벤더 전반에서 동작하는 삭제, 내보내기, 수정 워크플로를 갖춰야 합니다. Capgo 준수 사항: 관련이 있는 경우, 제3자 앱 인프라가 보유한 운영 메타데이터도 권리 대응 검토에 포함하세요.
배포 및 운영
배포 규율은 많은 팀이 규정 준수를 유지할지 이탈할지 갈리는 지점입니다.
| 체크리스트 항목 | 이상적인 모습 |
|---|---|
| 보존 제어 | 정기 삭제, 명확한 보유 규칙, 무기한 디버그 저장 없음 |
| 보안 보호 조치 | 암호화, 접근 제어, 시크릿 관리, 신중한 로깅 |
| 벤더 검토 | DPA 체결, 역할 명확화, 데이터 처리 방식 파악 |
| DPIA 프로세스 | 고위험 기능 출시 전 리스크 검토 |
| 인시던트 대응 | 명확한 책임자, 조사 로그, 알림 경로 |
| 변경 사항 검토 | 제품, 법무, 엔지니어링이 개인정보 영향 릴리스를 함께 검토 |
개발자에게 “GDPR 준수”란 체계적인 시스템 설계의 문제입니다. 숨겨진 플로우가 적고, 우발적인 수집기가 없으며, 기록이 잘 되어 있고, 앱이 개인 데이터를 어떻게 다루는지 묻는 질문에 빠르게 답할 수 있어야 합니다.
GDPR 준수란 무엇인지에 대한 간단한 답은 이렇습니다: 앱이 개인 데이터를 합법적으로, 최소한으로, 투명하게, 안전하게 처리하고, 팀이 이를 증명할 수 있어야 합니다. 어려운 부분은 이를 반복 가능한 엔지니어링 관행으로 전환하는 것입니다. 그렇게 하면 고객 리뷰가 쉬워지고, 감사 기간이 짧아지며, 프라이버시가 릴리스 당일 붙여지는 사후 조치가 아닌 핵심 요소가 됩니다.
팀이 Capacitor 앱을 출시하고 라이브 업데이트에 대한 더 엄격한 제어가 필요할 때, Capgo 서명된 웹 번들을 롤아웃 제어, 롤백 지원, 문서화된 릴리스 프로세스에 맞는 관측 가능성과 함께 배포할 수 있는 방법을 제공합니다. GDPR을 고려하는 팀에게는 이것이 중요합니다. 업데이트 인프라는 스택의 다른 프로세서와 마찬가지로 검토 가능해야 하며, 준수를 우회하는 보이지 않는 단축키로 취급되어서는 안 됩니다.
