개인정보 영향평가 2026 — 의무 대상 판정과 발주 일정·과업 범위 7단계
개인정보 영향평가는 개발이 끝난 뒤 받는 검사가 아니라 설계 착수 전에 하는 절차입니다. 시행령 제35조의 5만·50만·100만 명 판정 기준, 평가기관 계약을 개발보다 앞에 두는 일정, 지적사항 반영이 과업인지 별도인지 계약에 적는 법을 발주처 기준으로 정리했습니다.
시스템을 새로 만들거나 크게 고칠 때, 공공기관이라면 개인정보 영향평가를 먼저 받아야 하는 경우가 있다. 이걸 모르고 개발을 먼저 시작하면 설계를 되돌리게 된다.
이 글은 영향평가 제도를 설명하는 글이 아니다. 그건 KISA 수행안내서와 개인정보위 홈페이지에 있다. 여기서 다루는 것은 시스템을 발주하는 쪽이 판단해야 하는 것들이다. 우리 사업이 대상인지, 언제 해야 하는지, 발주서에 무엇을 적어야 하는지, 개발사에게 무엇을 요구해야 하는지.
먼저 판단할 것 — 우리 사업이 의무 대상인가
개인정보 보호법 제33조 제1항은 공공기관의 장에게 영향평가 의무를 지운다. 대상 기준은 시행령 제35조가 정한다.
| 호 | 기준 |
| 1 | 구축·운용·변경하려는 개인정보파일에 5만 명 이상의 민감정보 또는 고유식별정보 처리가 수반 |
| 2 | 다른 개인정보파일과 연계하는데 연계 결과 50만 명 이상의 개인정보가 포함 |
| 3 | 구축·운용·변경하려는 개인정보파일이 100만 명 이상 |
| 4 | 영향평가를 받은 뒤 개인정보 검색체계 등 운용체계를 변경 (이 경우 변경된 부분만 대상) |
세 숫자가 다른 이유를 보면 기준이 이해된다. 민감정보·고유식별정보는 5만 명이고 일반 개인정보는 100만 명이다. 주민등록번호나 건강 정보를 다루면 훨씬 적은 규모에서 의무가 생긴다.
4호도 자주 놓친다. 이미 평가를 받은 시스템이라도 검색체계를 바꾸면 다시 대상이 된다. 고도화 사업을 발주할 때 확인해야 하는 항목이다.
판정에서 헷갈리는 지점이 하나 더 있다. 인원 수는 "지금 가진 데이터"가 아니라 "운용할 개인정보파일"을 기준으로 센다. 신규 구축이라 아직 데이터가 0건이어도, 설계상 100만 명을 담게 되어 있으면 대상이다. 기획 단계에서 예상 규모로 판정해야 하는 이유다.
민감정보와 고유식별정보의 범위도 확인이 필요하다. 고유식별정보는 주민등록번호·여권번호·운전면허번호·외국인등록번호이고, 민감정보는 건강·유전·범죄경력·사상·노조 가입 등이다. 채용 시스템에 건강검진 결과가 들어가거나 복지 시스템에 장애 정보가 들어가면 5만 명 기준이 걸린다. 일반 회원 정보만 생각하고 100만 명 기준으로 판단하면 틀린다.
민간은 어떻게 되나
제33조 제11항은 공공기관 외의 개인정보처리자에게 "영향평가를 하기 위하여 적극 노력하여야 한다"고 정한다. 의무가 아니라 노력 규정이다.
다만 민간이라도 다음에 해당하면 실질적으로 하게 된다.
- 공공기관 사업을 수탁해 개인정보파일을 운용하는 경우
- 발주처가 계약 조건으로 요구하는 경우
- 금융·의료처럼 다른 법령이 별도 평가를 요구하는 경우
언제 해야 하나 — 개발 전이다
이 제도에서 발주처가 가장 많이 틀리는 지점이다. 영향평가는 시스템을 만든 뒤 검사받는 절차가 아니라, 설계 단계에서 위험을 줄이는 절차다.
| 시점 | 무엇을 하나 |
| 사업계획 수립 | 대상 여부 판단, 예산에 평가 비용 반영 |
| 설계 착수 전 | 영향평가 수행 ← 여기가 정본 |
| 개발 | 평가에서 나온 개선사항을 반영 |
| 개인정보파일 등록 시 | 평가 결과를 함께 제출(제33조 제5항) |
제5항이 결과 제출 시점을 정한다. 개인정보파일을 등록할 때 영향평가 결과를 첨부해야 한다. 등록 시점에 결과가 없으면 사업이 멈춘다.
일정을 역산하면 이렇게 된다. 개통일에서 거꾸로 개인정보파일 등록, 그 앞에 평가 결과 확정, 그 앞에 평가 수행, 그 앞에 평가기관 계약이 온다. 평가 수행 자체에도 몇 주가 걸리므로 개발 일정과 별도로 앞단에 자리를 잡아 둬야 한다. 이걸 안 하면 개통을 앞두고 등록이 막히는 상황이 생긴다.
개발이 끝난 뒤에 평가를 시작하면 지적사항이 나왔을 때 이미 만든 것을 고쳐야 한다. 암호화 대상 항목이 늘거나 접근 권한 구조가 바뀌면 설계 변경이고, 그건 과업 변경이다. 과업 변경 절차는 과업지시서 작성법에서 다뤘다.
누가 수행하나
제33조 제2항은 공공기관이 평가기관에 의뢰하도록 정한다. 발주처가 직접 하거나 개발사가 대신할 수 없다.
| 주체 | 역할 |
| 발주처(공공기관) | 대상 판단, 평가기관 선정·계약, 결과 제출 |
| 평가기관 | 영향평가 수행 (지정받은 기관만) |
| 개발사 | 자료 제공, 개선사항 반영 |
여기서 일정 문제가 생긴다. 평가기관 계약과 개발 계약이 별건이라 두 일정을 발주처가 맞춰야 한다. 개발 착수일을 먼저 잡아 두고 평가기관 선정을 나중에 하면, 설계가 시작된 뒤에 평가가 들어와 앞의 문제가 그대로 발생한다.
개발사 입장에서도 이 구분이 중요하다. 평가기관은 발주처와 계약한 제3자라, 개발사가 평가 결과를 협의로 바꿀 수 없다. 지적사항이 나오면 반영하거나, 반영이 어려운 이유를 발주처를 통해 설명하는 것이 전부다. 그래서 발주 단계에서 개발사의 협조 범위(자료 제출 횟수, 인터뷰 대응, 산출물 제공)를 적어 두면 양쪽 기대가 맞는다.
평가가 실제로 보는 것
제33조 제3항은 고려사항을 네 가지로 정한다.
| 호 | 고려사항 |
| 1 | 처리하는 개인정보의 수 |
| 2 | 개인정보의 제3자 제공 여부 |
| 3 | 정보주체의 권리를 해할 가능성 및 그 위험 정도 |
| 4 | 그 밖에 대통령령으로 정한 사항 |
발주 관점으로 옮기면 설계 단계에서 다음이 정해져 있어야 평가가 진행된다.
| 정해야 할 것 | 안 정해져 있으면 |
| 수집 항목 목록 | 평가 자체가 시작되지 않는다 |
| 항목별 수집 근거(동의·법령·계약) | 근거 없는 항목이 지적된다 |
| 보유 기간과 파기 절차 | 「영구 보관」은 거의 지적 대상 |
| 제3자 제공·위탁 현황 | 위탁 계약서까지 확인한다 |
| 접근 권한 설계 | 전 직원 조회 가능 구조는 지적 |
| 암호화 대상 | 고유식별정보·비밀번호는 필수 |
이 목록이 곧 요구사항 정의서에 들어가야 할 항목이다. 정의서를 쓸 때 개인정보 항목을 빼 두면 평가 단계에서 되돌아온다. 요구사항을 검증 가능한 형태로 쓰는 법은 요구사항 정의서 작성법에 정리했다.
발주서에 적을 것
영향평가가 걸린 사업을 발주할 때 범위를 닫는 항목들이다.
| 항목 | 적는 법 |
| 영향평가 대상 여부 | 대상이면 그 사실과 근거 호(1~4호)를 명시 |
| 평가 일정 | 설계 착수 전 완료를 전제로 한 일정표 |
| 개발사 협조 범위 | 자료 제출·인터뷰 대응 몇 회, 산출물 제공 범위 |
| 개선사항 반영 | 지적사항 반영이 과업에 포함되는지, 별도인지 |
| 재평가 | 운용체계 변경 시 재평가 비용 부담 주체 |
| 산출물 | 개인정보 흐름도, 수집 항목 목록, 권한 매트릭스 |
네 번째가 분쟁 지점이다. 평가에서 "이 항목은 암호화하라", "이 권한은 분리하라"가 나오면 그건 추가 개발이다. 과업에 포함인지 별도인지를 계약 전에 적어 두지 않으면 인도 직전에 협의가 붙는다.
실무에서 쓸 만한 문장은 이런 형태다. "영향평가 지적사항 중 설계 변경을 수반하지 않는 항목은 과업에 포함하고, 설계 변경이 필요한 항목은 과업 변경 절차에 따른다." 경계가 애매하면 용역계약 일반조건의 과업변경 절차를 기준으로 삼는다.
개발사에게 요구할 산출물
평가기관이 요구하는 자료는 결국 개발사가 만든다. 발주서 산출물 목록에 넣어 두면 나중에 따로 요청할 일이 없다.
| 산출물 | 무엇인가 |
| 개인정보 흐름표 | 수집→저장→이용→제공→파기 경로 |
| 개인정보 흐름도 | 위 흐름을 시스템 구성도 위에 표시 |
| 수집 항목 목록 | 항목별 수집 근거와 보유 기간 |
| 권한 매트릭스 | 역할별로 어느 데이터에 무엇을 할 수 있는지 |
| 암호화 적용 내역 | 저장·전송 구간별 |
| 접속기록 설계 | 무엇을 얼마나 남기는지 |
이 중 개인정보 흐름표와 권한 매트릭스가 특히 자주 빠진다. 둘 다 코드를 보면 알 수 있는 게 아니라 설계 의도를 적는 문서라, 개발사가 만들지 않으면 나중에 누구도 재구성하지 못한다.
흐름표가 값을 하는 이유는 하나다. 개인정보가 어디서 나가는지는 코드를 읽어도 잘 안 보인다. 로그에 남는 것, 외부 API로 넘어가는 것, 백업에 복제되는 것은 화면 어디에도 표시되지 않는다. 평가에서 지적되는 항목의 상당수가 이 "보이지 않는 경로"다.
데이터 구조를 문서로 남기는 방법은 테이블 정의서·ERD 작성법에서 다룬다.
설계에서 미리 막을 수 있는 지적사항
평가에서 반복적으로 나오는 항목들이다. 설계 단계에 반영하면 재작업이 없다.
| 자주 나오는 지적 | 설계에서 할 일 |
| 필요 이상의 항목 수집 | 항목마다 "이게 없으면 무엇이 안 되나"를 적어 본다 |
| 보유 기간 미설정 | 항목별 기간과 자동 파기 절차를 넣는다 |
| 전 직원 조회 가능 | 역할 기반 권한으로 나눈다 |
| 고유식별정보 평문 저장 | 주민번호·여권번호는 암호화 |
| 접속기록 미보관 | 누가 언제 무엇을 조회했는지 남긴다 |
| 위탁 계약서 누락 | 클라우드·문자 발송도 위탁이다 |
마지막 줄이 놓치기 쉽다. 외부 서비스를 쓰면 대부분 개인정보 처리 위탁에 해당한다. 문자 발송, 이메일 발송, 클라우드 스토리지, 외부 API가 전부 여기 들어간다. AI 기능을 붙일 때 외부 모델에 데이터를 보내는 구성도 같은 문제다. 판단 기준은 AI 도입 데이터 거버넌스·개인정보 체크리스트에 정리했다.
준비 7단계
| 단계 | 할 일 | 산출 |
| 1 | 시행령 제35조 각 호로 대상 여부 판정 | 대상 여부 |
| 2 | 대상이면 예산에 평가 비용 반영 | 사업계획 |
| 3 | 평가기관 선정 일정을 개발 일정보다 앞에 | 일정표 |
| 4 | 수집 항목·근거·보유기간 확정 | 요구사항 정의서 |
| 5 | 평가 수행(설계 착수 전) | 영향평가서 |
| 6 | 지적사항을 설계에 반영 | 변경 설계 |
| 7 | 개인정보파일 등록 시 결과 첨부 | 등록 완료 |
3번이 실무의 핵심이다. 평가기관 계약이 개발 계약보다 늦으면 나머지 순서가 전부 무너진다.
흔한 실수 다섯 가지
| 실수 | 결과 | 대응 |
| 개발 끝나고 평가 시작 | 설계 변경 = 과업 변경 | 설계 착수 전으로 일정 배치 |
| 대상 여부 미판정 | 등록 단계에서 사업 정지 | 기획 단계에 시행령 제35조 확인 |
| 지적사항 반영 범위 미기재 | 인도 직전 협의 | 과업 포함/별도를 계약에 명시 |
| 흐름표·권한 매트릭스 누락 | 자료를 나중에 재구성 못 함 | 발주서 산출물에 포함 |
| 위탁 현황 누락 | 외부 서비스가 전부 지적 | 클라우드·문자·API를 목록화 |
트리숲이 영향평가 사업을 다루는 방식
트리숲은 공공 사업 문의를 받으면 영향평가 대상 여부부터 확인한다. 대상이면 일정의 앞단이 통째로 달라지기 때문이다. 개발 착수일을 먼저 잡아 두고 평가를 나중에 끼우면 설계를 두 번 하게 된다.
요구사항 정의서를 쓸 때 개인정보 항목을 별도 섹션으로 뺀다. 수집 항목·근거·보유 기간·암호화 대상을 여기에 모아 두면 그대로 평가 자료가 되고, 나중에 따로 만들 일이 없다.
지적사항 반영은 계약 단계에서 경계를 정한다. 설계 변경을 수반하지 않는 항목은 과업에 포함하고, 그렇지 않은 것은 과업 변경 절차를 탄다고 적는다. 이 한 줄이 없으면 인도 직전에 모든 지적사항이 무상 요구로 들어온다. 견적 산정 근거를 맞추는 방법은 기능점수(FP) 기반 비용 산정에 있다.
자주 묻는 질문
우리 사업이 대상인지 어떻게 아나요?
개인정보 보호법 시행령 제35조 각 호로 판정한다. 민감정보·고유식별정보가 5만 명 이상, 연계 결과 50만 명 이상, 일반 개인정보 100만 명 이상, 그리고 평가 후 운용체계 변경이 기준이다.
민간 기업도 해야 하나요?
제33조 제11항은 "적극 노력하여야 한다"는 노력 규정이다. 다만 공공 사업을 수탁하거나 발주처가 계약 조건으로 요구하면 실질적으로 하게 된다.
개발사가 대신 해줄 수 있나요?
없다. 제33조 제2항에 따라 지정된 평가기관에 의뢰해야 한다. 개발사는 자료를 제공하고 지적사항을 반영하는 역할이다.
언제 시작해야 하나요?
설계 착수 전이다. 개발이 끝난 뒤에 하면 지적사항이 설계 변경이 되고, 그건 과업 변경과 추가 비용으로 이어진다.
한 번 받으면 끝인가요?
아니다. 시행령 제35조 제4호에 따라 개인정보 검색체계 등 운용체계를 변경하면 변경된 부분이 다시 대상이 된다. 고도화 사업을 발주할 때 확인해야 한다.
아직 데이터가 없는 신규 구축인데도 대상인가요?
그렇다. 인원 수는 보유량이 아니라 운용할 개인정보파일 기준으로 센다. 설계상 기준을 넘기게 되어 있으면 데이터가 0건이어도 대상이므로, 기획 단계에서 예상 규모로 판정한다.
정리
개인정보 영향평가에서 발주처가 실제로 결정해야 하는 것은 평가 방법이 아니라 순서와 경계다. 언제 하는지(설계 착수 전), 누가 하는지(평가기관), 지적사항 반영이 과업인지 별도인지.
기획 단계에서 세 가지만 확정해 두면 나머지가 굴러간다. 시행령 제35조로 판정한 대상 여부, 평가기관 계약 시점, 그리고 지적사항 반영 범위를 정한 계약 문장이다. 이 셋이 없으면 개발이 끝난 뒤에 설계를 되돌리게 된다.
산출물 목록을 문서로 닫는 방법은 과업지시서 작성법에서 다룬다.