Privacy Desk

2026년 1월 22일, 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」이 본격 시행됐다. EU에 이어 세계에서 두 번째로 포괄적인 AI 규제 체계를 갖춘 나라가 됐다는 얘기가 나왔다.그런데 개인정보 담당자 입장에서 "그래서 내가 뭘 해야 하지?"라는 질문이 먼저 든다.AI 기본법의 핵심은 '고영향 AI'다이 법에서 가장 주의 깊게 봐야 할 개념이 고영향 AI(High-Impact AI)다. 자율주행, 의료 진단, 금융 신용평가처럼 사람의 생명이나 기본권에 중대한 영향을 미치는 AI가 여기에 해당한다.고영향 AI 사업자에게는 투명성 확보, 안전성 확보, 영향 평가 등의 의무가 붙는다. 위험관리방안 수립, 이용자 보호 방안 마련, 그리고 이를 홈페이지에 게시하는 것까지 포함된다.챗봇이나 단순 정보 제..

처음 pia-privacy.com을 만들었을 때는 챗봇 한 페이지였다. 지금은 10개 기능이 된다. 처리방침 리뷰, 위험도 자가진단, 동의서·계약서 생성, 컴플라이언스 캘린더, PIA 체크리스트, 침해사례 DB, 업종별 가이드 등이다.이 과정에서 설계에 대해 몇 가지를 배웠다.기능을 추가할 때 가장 중요한 건 진입점이다10개 기능이 생기면 사용자가 어디서 시작해야 하는지 모른다. 처음에는 그냥 링크 목록을 페이지에 나열했다. 그런데 기능이 4개만 넘어가도 "뭐가 있는지"보다 "내가 뭘 해야 하는지"로 생각하는 게 더 자연스럽다는 걸 깨달았다.그래서 드롭다운 메뉴로 묶고, 모바일에서는 햄버거 메뉴로 숨겼다. 기능의 이름보다 "내가 지금 뭘 하려는가"에 맞게 레이블을 붙이는 게 중요했다.각 기능의 시스템 프..

pia-privacy.com은 서버가 없다. 백엔드 코드가 없고, 데이터베이스도 없다. HTML 파일 몇 개를 S3 버킷에 올리고, 버킷을 정적 웹사이트로 설정한 게 전부다.왜 이 구조를 선택했나운영 부담이 제일 컸다. EC2나 Lambda를 쓰면 관리해야 할 것들이 생긴다. 보안 패치, 모니터링, 비용 관리. 개인 프로젝트에서 이걸 계속 신경 쓰고 싶지 않았다.S3 정적 호스팅은 파일을 올리면 끝난다. SSL도 CloudFront를 붙이면 해결된다. 비용은 거의 없다.실제 구성HTML 파일이 직접 fetch()로 Anthropic API를 호출한다. 중간에 아무것도 없다.사용자 → 브라우저 → Anthropic API장점은 단순함이다. 단점은 API 키가 클라이언트 코드에 들어간다는 것이다. 이 부분은..

pia-privacy.com을 만들면서 기술적인 고민보다 더 많이 한 게 있다. "AI가 법령 해석을 얼마나 믿을 수 있는가"라는 질문이다.AI는 법령을 '검색'하지 않는다가장 먼저 정리해야 했던 오해가 이거다. Claude나 GPT 같은 모델은 학습 데이터 기준으로 답한다. 최신 개정 내용이나 최근 고시는 반영이 안 될 수 있다.그래서 챗봇 UI에 항상 명시했다. "이 답변은 법적 효력이 없으며, 최신 법령 원문을 반드시 확인하세요."이게 사용자 기만이 아니라, 오히려 이 도구를 제대로 쓰게 만드는 장치라고 생각했다.잘 쓰이는 기능과 그렇지 않은 기능이 갈렸다처음에는 단순 챗봇만 만들었다. 그런데 쓰다 보니 반복해서 필요한 맥락이 있었다.동의서 초안 생성, 처리방침 리뷰, 위험도 자가진단 같은 기능은 ..

정보보호 업무를 하다 보면 반복되는 질문들이 있다."이 항목 수집해도 되나요?" "동의서 양식 어떻게 써야 하죠?" "개인정보 처리방침에 이거 넣어야 하나요?"매번 법령을 찾고 해석해서 답하는 일이 쌓이다 보니, 이걸 자동화할 수 없을까 하는 생각이 생겼다. 그래서 만든 게 pia-privacy.com이다.만들게 된 배경개인정보보호법은 조문도 많고, 고시·지침·가이드라인이 따로 흩어져 있다. 실무자 입장에서는 조문 하나를 제대로 이해하려면 시행령을 같이 봐야 하고, 개인정보위 해설자료까지 찾아봐야 하는 경우가 많다.그 과정에서 "내가 했던 해석을 다른 사람도 쉽게 할 수 있게 구조화하면 어떨까"라는 생각이 출발점이었다.기술 선택: 브라우저에서 바로 API 호출처음에는 백엔드 서버를 구성할까 생각했다. 그..

보안이나 개인정보 업무는 결과물이 눈에 잘 안 보이는 편이다.그래서 이직 준비를 하면서도 “내가 뭘 했는지”를 설명하기가 어렵다고 느끼는 사람이 많다.그런데 실무에서는 오히려 문서가 실력을 보여주는 경우가 많다.특히 정합성이 있는 문서는 그 사람의 사고방식을 그대로 드러낸다.정합성이란 결국 “앞뒤가 맞는 구조”다정합성이 없는 문서는 대체로 이런 특징이 있다.수집 목적과 항목이 연결되지 않는다보유기간이 근거 없이 길거나 짧다보호조치는 나열돼 있지만 실제 적용 위치가 없다접근권한은 “통제”라고 적혀 있지만 역할 구분이 없다반대로 정합성이 있는 문서는서비스 흐름 → 데이터 흐름 → 리스크 → 보호조치가 자연스럽게 이어진다.실무에서 문서를 쓸 때 내가 잡는 기준문서 한 장만 봐도 처리 흐름이 그려지는가“왜 필요..

요즘 시스템은 API 중심으로 흘러간다.그래서 보안 점검에서도 “API 인증 붙였나요?”로 끝내면 안 되는 경우가 많다.API는 인증이 시작점이고, 실제 사고는 다른 지점에서 터지는 일이 많다.인증 다음에 봐야 하는 것: 인가(Authorization)인증은 “누구냐”를 확인하고, 인가는 “무엇을 할 수 있냐”를 정한다.API 사고는 보통 인가에서 나온다.본인 데이터만 조회해야 하는데 다른 사용자 데이터가 조회되는 경우역할에 따라 접근 범위가 달라야 하는데 통제가 느슨한 경우객체 단위 인가가 빠져서 ID만 바꾸면 다른 데이터가 보이는 경우실무에서는 이걸 “객체 수준 접근통제” 관점으로 반드시 체크한다.속도 제한과 남용 방지: Rate Limit은 보안이다API는 공격자가 자동화하기 좋은 구조다.그래서 다..

개인정보 보호에서 보유기간 준수는 기본이라고 말하지만, 막상 운영을 들여다보면 가장 자주 틀어지는 영역이 보유·파기다.“파기 정책이 있다”와 “실제로 파기된다”는 다르다.특히 서비스가 커질수록 개인정보가 한 곳에만 있지 않기 때문에, 보유기간은 더 어려워진다.개인정보는 DB에만 있지 않다실무에서 보유·파기를 어렵게 만드는 건 데이터의 분산이다.운영 DB로그(접속/행위/오류)백업/스냅샷데이터 레이크/분석 플랫폼고객센터 티켓/첨부파일DB에서 지웠는데 분석 환경에 남아 있거나, 백업에 남아 있으면 “완전한 파기”라고 말하기 어렵다.보유기간은 목적별로 쪼개야 실행된다하나의 개인정보라도 목적이 다르면 보유기간이 달라진다.서비스 제공 목적분쟁 대응 목적법정 보관 목적보안 감사 목적(접속 기록)그래서 실무적으로는 “..

취약점 관리는 도구만 도입하면 해결될 것 같지만, 운영을 해보면 가장 어려운 건 “무엇부터 고칠지”를 결정하는 일이다.현업은 늘 바쁘고, 패치는 서비스 중단 위험도 있다. 그래서 취약점은 쌓이고, 어느 순간부터는 목록만 늘어난다.결국 취약점 관리는 스캐너보다 우선순위 체계가 핵심이라고 느낀다.CVSS 점수만으로 우선순위를 정하면 어긋나는 경우가 많다CVSS는 중요한 지표지만, 실제 영향도는 환경에 따라 달라진다.외부 노출 시스템인지(인터넷 공개 여부)공격 난이도(인증 필요 여부, 익스플로잇 존재 여부)자산 중요도(개인정보/결제/인증 여부)보완 통제 존재 여부(WAF 룰, 네트워크 차단, 권한 분리)그래서 점수만 보고 “높다/낮다”로 처리하면, 실제 위험한 것부터 놓칠 수 있다.실무에서 쓰기 좋은 우선순위..

개인정보 보호를 얘기할 때 암호화나 접근통제 같은 기술 조치가 먼저 떠오르지만, 실무에서 사고의 시작점은 의외로 위탁(수탁) 구간인 경우가 많다.내부에서 아무리 통제를 잘해도, 외부 업체가 처리하는 구간이 느슨하면 전체 리스크가 그쪽으로 새어 나간다.위탁 관리는 “계약서 한 장”으로 끝나지 않는다.오히려 계약 이후에 운영을 어떻게 굴리느냐가 핵심이다.위탁을 명확히 정의하지 않으면 통제가 시작되지 않는다가장 먼저 정리해야 하는 건 “이게 위탁인가?”다.단순 구매(라이선스/솔루션)인지운영대행(계정 접근/원격 접속)이 포함되는지데이터 처리(수집·보관·가공)를 실제로 수행하는지이 경계가 애매하면, 수탁사 접근권한·재위탁·파기 책임도 흐려진다.그래서 사전 검토에서부터 업무 흐름을 기준으로 위탁 여부를 먼저 확정하..