작은 회사 개인정보 보안, 업무 시스템에 최소한 넣어야 할 것

휴가 신청 화면에서 병가를 고르면 증빙 첨부가 필수였습니다. 사유 칸도 반드시 채워야 했습니다.

제가 운영하는 사내 그룹웨어의 개인정보처리방침을 새로 쓰다가 그 화면 코드를 열어 본 참이었습니다.

진단서와 병명은 건강에 관한 정보입니다. 개인정보 보호법 제23조의 민감정보라서 별도 동의나 법령 근거가 있어야 처리할 수 있습니다.

화면에는 최소한만 적으라는 안내뿐이었습니다. 동의 절차는 어디에도 없었습니다.

진단서 칸 하나에서 출발해 보겠습니다. 암호화나 마스킹 같은 기술 이야기는 덜어 내고, 대표나 겸직 담당자가 직접 정해야 하는 자리만 골랐습니다.

법 조문은 판단의 출발점이고 자문을 대신하지 않습니다. 제 경우에도 선택지는 제가 쓰고 결정은 회사가 했습니다.

진단서 칸 하나에 걸린 것

병가는 회사 규정으로 운영하는 제도입니다. 그래서 "법령이 요구하니 받는다"는 근거에 기대기 어렵습니다.

남는 길은 별도 동의입니다.

여기서 흔히 하는 실수가 있습니다. 방침에 "건강 정보는 별도 동의를 받아 처리합니다"라고만 써 두는 것입니다.

화면에 동의 절차가 없는데 방침에 그렇게 쓰면 사실과 다른 고지가 됩니다.

진단서 파일은 한 번 올라가면 한자리에 머물지 않습니다. 결재 문서에 붙고 백업 사본에 들어갑니다. 결재 문서를 읽는 사내 AI 비서의 경로에도 걸립니다.

동의를 받을까, 아예 받지 않을까

검토 노트에는 선택지를 이렇게 적었습니다.

선택지	바뀌는 것	남는 위험
별도 동의 체크박스 추가	신청 폼, 동의 시각 저장, 결재 문서 표시	진단서가 시스템과 백업에 계속 쌓임
시스템에서 건강 정보 수집 중단	병가만 첨부 해제, 원본은 담당 부서에 직접 제출	가장 낮음
현행 유지, 방침만 보강	문구만	절차가 없어 자문에서 지적받기 쉬움

제 추천은 두 번째였습니다. 닫힌 그룹웨어에 진단서를 쌓아 둘 이유가 약했습니다. 파일이 시스템과 백업, AI 비서 경로 밖에 머물러 위험도 가장 낮았습니다.

동의를 받으면 처리할 근거는 생깁니다. 대신 받은 파일을 지키고, 보관 기간을 정하고, 언젠가 지우는 일까지 함께 떠안습니다.

받지 않은 정보는 유출될 일도 없습니다. 꼭 필요하지 않은 민감정보라면 동의서를 고민하기 전에 그 칸을 지울 수 있는지부터 보세요.

회사가 고른 쪽과 그 뒤의 장치

회사는 첫 번째 안을 골랐습니다. 저는 진단서를 시스템으로 받는 인사 절차가 있다는 뜻으로 읽었습니다.

선택지를 쓴 사람은 저였지만 현장 절차는 회사가 더 잘 압니다. 그 결정을 따르기로 하고 동의 절차를 만들었습니다.

동의를 받기로 했다면 동의가 장식으로 끝나지 않게 만들어야 합니다. 실제로 넣은 장치는 아래와 같습니다.

• 동의 칸은 병가에서만 뜹니다. 경조 휴가의 가족관계는 제23조 민감정보 범주에 들지 않고, 공가는 사유마다 달라 이번 범위에서 뺐습니다.
• 체크하지 않으면 신청 버튼이 꺼집니다. 화면을 거치지 않고 요청을 보내도 서버가 "건강 정보 수집 동의가 필요합니다"로 거부합니다.
• 동의 시각은 서버가 직접 찍습니다. 사용자 컴퓨터의 시계는 바꿀 수 있기 때문입니다.
• 결재 문서 상세에 "건강정보 수집 동의, 동의함(시각)" 줄이 붙습니다.
• 휴가 종류를 바꾸면 체크가 풀립니다.

테스트는 단위 6건과 DB 3건을 붙였습니다. 동의 없는 신청이 거부되고 행이 생기지 않는지 봅니다. 동의 시각이 서버 시각과 60초 안에서 맞는지, 연차에는 동의 값이 비어 있는지도 확인합니다.

업체 시스템이라면 동의하지 않은 요청을 서버가 막는지 확인하세요.

방침 문장이 절차보다 앞설 때

같은 검토에서 되풀이해 나온 문제는 방침 문장과 실제 절차 사이의 간격이었습니다. 진단서 칸이 그 첫 사례였고, 운영을 외부에 맡긴 구조가 두 번째였습니다.

저는 회사의 위탁을 받아 이 시스템을 개발하고 운영합니다. 방침에는 "운영자는 위탁받은 범위에서만 개인정보를 처리한다"고 적혀 있었습니다.

이 문장이 성립하려면 위탁 문서가 실제로 있어야 합니다. 개인정보 보호법 제26조는 위탁 업무와 목적, 기술적·관리적 보호 조치, 재위탁 제한 같은 내용을 문서로 남기고 수탁자를 방침에 공개하라고 정합니다.

검토 당시에는 구조만 적혀 있었고 그런 문서가 있는지는 확인되지 않았습니다. 회사는 표준 서식으로 위탁계약서를 따로 맺기로 정했습니다.

이미 용역계약서가 있다면 그 안에 제26조 기재사항이 들어 있는지부터 보세요. 빠져 있으면 부속합의서로 채울 수 있습니다.

직원 정보의 수집 근거도 그때 한 문장 넣었습니다. 근로계약 이행에 필요한 정보는 제15조 제1항 제4호로 동의 없이 수집합니다. 프로필 사진이나 서명 이미지 같은 선택 항목은 본인 동의로 처리합니다.

열람 기록은 몇 년 둘까

누가 언제 어떤 문서를 열었는지 남기는 기록도 결국 개인정보입니다. 무한정 쌓아도 안 되고 너무 빨리 지워도 안 됩니다.

개인정보의 안전성 확보조치 기준은 접속기록을 1년 이상 보관하라고 정합니다. 5만 명 이상의 고유식별정보나 민감정보를 처리하는 경우 등은 2년 이상입니다.

회사는 접속·열람·설정변경 기록을 2년 보관하고 넘으면 자동 파기하기로 정했습니다. 외부 문의 창구 쪽 기록은 처음에 1년이었는데 같은 검토에서 2년으로 맞췄습니다.

구현은 단순하게 했습니다. 기록을 쓰는 순간 마지막 파기에서 20시간이 지났는지 보고, 지났으면 2년 넘은 행을 지웁니다.

예약 작업을 따로 띄우지 않아도 기록이 쌓이는 동안 파기도 같이 돕니다. 테스트는 3년 전 기록이 지워지는지, 1년 전 기록이 남는지, 20시간 잠금이 걸렸다 풀리는지를 확인합니다.

방침에 "관련 법령이 정한 기간"이라고만 쓰면 읽는 직원은 그게 몇 년인지 알 수 없습니다. 기간은 숫자로 적고, 지우는 코드가 실제로 돌게 하세요.

안내문과 공개 페이지에서 새는 것

결재선의 부재 안내도 같은 기준으로 만들었습니다. 누가 자리를 비웠는지만 알리고 휴가 종류는 싣지 않았습니다.

방침 페이지 자체에서도 같은 일이 있었습니다. 개인정보 보호책임자 연락처를 적으려고 시스템에 저장된 담당자 연락처를 찾아보니 개인 휴대폰과 개인 메일이었습니다.

방침은 로그인 없이 누구나 여는 페이지입니다. 거기에 개인 연락처를 싣는 일 자체가 노출이라 회사 대표번호만 올렸습니다.

새 기능을 붙일 때마다 알림 문구, 목록 배지, 공개 페이지에 무엇이 실려 나가는지 한 번씩 보세요. 입력 폼만 점검하면 이런 부수 화면은 눈에 잘 들어오지 않습니다.

퇴사한 다음 날의 계정

퇴사자 계정은 남아 있는 동안 그 사람의 접근 경로가 됩니다. 지금은 관리자 화면에서 퇴사 처리를 하면 로그인 세션이 바로 끊기고 관리자 권한도 회수됩니다.

개인정보 쪽에서 챙긴 부분은 외부 연결입니다. 외부 메신저 알림 연결과 캘린더 연동 토큰을 함께 지워서 퇴사한 사람에게 사내 알림이 계속 나가지 않게 했습니다.

전자결재나 휴가처럼 사람이 빠지면 함께 정리해야 하는 흐름이 궁금하다면 그룹웨어 데모의 결재 화면부터 보세요. 실제 시스템 화면을 익명 데이터로 옮겨 둔 것입니다.

저장소 히스토리 한 번 훑기

코드 저장소도 점검 대상입니다. 지금 파일에서 지웠어도 예전 커밋에는 그대로 남아 있기 때문입니다.

다지점 매출 관리 시스템에서는 평문 클라우드 접근 키가 담긴 파일이 커밋 3개에 남아 있었습니다. 전체 백업 번들을 먼저 떠 두고 히스토리에서 그 파일을 걷어 냈습니다.

재작성된 참조가 193개였고, 그 파일이 들어간 커밋은 0개가 됐습니다. 히스토리를 지우는 일과 키를 새로 발급하는 일은 별개라서 키 교체는 따로 남은 일이었습니다.

같은 점검에서 더 실질적인 위험이 나왔습니다. 문서 6곳에 관리자 비밀번호가 평문으로 적혀 있었고, 모두 가렸습니다.

보험계약 관리 CRM은 비공개 원격 저장소를 처음 열기 전에 히스토리를 감사했습니다. 시크릿, 개인정보 덤프, 데이터 파일을 찾는 검사 세 겹이 모두 0건을 냈습니다.

그런데 따로 돌린 재검사가 데이터 교정용 SQL 3개와 주석에서 실명과 직원 ID를 찾았습니다. 정리한 뒤 커밋 124개를 다시 썼고 모든 커밋 해시가 바뀌었습니다.

세 겹의 검사는 키 모양의 문자열과 덤프 파일, 데이터 파일을 찾습니다. SQL 주석 속 이름 한 줄은 그 어느 모양에도 맞지 않아 그냥 통과했습니다.

비밀번호와 키가 어디에 남기 쉬운지, 직원이 AI 도구에 무엇을 넣어도 되는지를 회사 기준으로 정하고 싶다면 AI 개인정보보호 교육에서 점검표를 함께 만듭니다.

이미 쓰는 시스템에서 이런 칸과 기록이 어떻게 돌고 있는지 보고 판단하고 싶다면, 화면과 저장 구조를 같이 열어 보는 점검 상담도 가능합니다.

최소 기준 체크리스트

수십 명 규모 회사가 직원·고객 정보를 다루는 시스템을 만들거나 고를 때 제가 먼저 보는 항목입니다.

• 접속·열람·설정변경 기록이 남는가. 보관 기간이 "1년" "2년"처럼 숫자로 정해져 있고, 넘은 기록을 지우는 장치가 실제로 도는가.
• 진단서처럼 꼭 필요하지 않은 민감정보를 받고 있지 않은가. 받아야 한다면 별도 동의를 서버가 강제하고 동의 시각을 서버가 남기는가.
• 방침에 적힌 절차가 화면에 실제로 있는가. 없는 절차를 방침에 먼저 쓰지 않았는가.
• 운영이나 유지보수를 외부에 맡겼다면 위탁계약서가 있고, 방침에 수탁자가 공개돼 있는가.
• 알림 문구, 부재 안내, 공개 페이지에 휴가 종류나 개인 연락처가 실려 나가지 않는가.
• 퇴사 처리 즉시 로그인이 끊기고 외부 메신저·캘린더 연결까지 해제되는가.
• 코드 저장소 히스토리에 키, 비밀번호, 실명, 직원 ID가 남아 있지 않은가. 키를 지웠다면 새로 발급까지 했는가.