개인정보를 받는 순간부터 지울 때까지 살피려면

회원가입과 주문 기능이 정상적으로 동작해도, 그 과정에서 받은 개인정보가 어디에 남고 누가 볼 수 있는지는 별도로 확인해야 합니다. AI의 도움으로 기능을 만들 때도 정보를 받는 목적, 보호 방법과 삭제 시점을 정하는 일은 남습니다.

이 제안은 운영자가 모든 법령과 기술을 스스로 해석하도록 맡기기보다, 사용하는 기능에 맞춰 확인할 항목과 담당자에게 물어볼 내용을 안내하자는 취지입니다. 적용해야 할 의무와 추가로 권장하는 보호 방법을 구분하고, 판단이 어려운 부분을 확인할 지원도 함께 마련할 필요가 있습니다.

필요한 정보와 남길 기간을 함께 정해야 합니다

정보를 받기 전에 각 항목을 어디에 사용할지 설명할 수 있어야 합니다. 가상의 예로, 이메일로 소식을 전하는 기능에 연락처와 집 주소까지 필요한지는 따로 살펴볼 일입니다. 다른 서비스의 양식이나 AI가 만든 화면에 들어 있다는 이유만으로 같은 정보를 받을 필요는 없습니다. 이용자가 직접 입력한 내용뿐 아니라 방문 기록이나 외부 문의 양식에서 자동으로 남는 정보도 함께 파악해야 합니다.

정보를 안전하게 보관하는 것과 그 정보를 받아 이용할 근거가 있는지는 다른 판단입니다. 주민등록번호나 건강정보처럼 별도 조건을 확인해야 하는 정보, 본인확인 과정에서 전달받는 정보는 수집 목적과 적용 기준을 먼저 검토할 수 있어야 합니다. 모든 항목에 같은 동의 문구를 붙이는 방식으로 이 검토를 대신하지 않도록 설명이 필요합니다.

보관할 이유와 기간, 삭제를 맡는 주체도 함께 정해야 합니다. 계정을 화면에서 숨겼다고 정보까지 삭제된 것은 아닙니다. 내려받은 파일, 로그(프로그램에서 일어난 일을 남긴 기록), 백업(복구를 위해 따로 보관하는 복사본)에도 남는지 살펴야 합니다. 계속 보관해야 할 기록은 그 근거와 기간을 구분하고, 백업의 삭제 주기와 복구 과정에서 이미 삭제한 정보가 다시 사용되는 문제도 검토할 필요가 있습니다.

원래 내용을 다시 써야 하는지에 따라 보호 방법이 달라집니다

데이터베이스(DB)는 회원이나 주문 정보를 모아 보관하는 저장소입니다. 암호화는 별도의 열쇠인 암호키가 있어야 원래 내용을 읽을 수 있게 바꾸는 방법입니다. 원문을 다시 쓸 필요가 없다면, 원문 대신 같은 값인지를 확인할 비교용 정보만 남기는 방안도 검토할 수 있습니다. 두 방식의 목적과 한계를 구분해 설명해야 합니다.

로그인 비밀번호는 입력한 값이 맞는지 확인하는 데 쓰입니다. 원래 비밀번호를 다시 꺼내는 방식보다, 비밀번호 저장에 맞게 검토된 전용 기능으로 해시값(입력값을 비교하는 데 쓰는 값)을 만들어 확인하는 방식이 적합합니다. 글자를 바꾸거나 일반적인 해시 기능을 적용했다는 설명만으로 점검을 끝내지 않고, 비밀번호 저장에 적합한 기능과 설정인지 확인할 수 있어야 합니다. 비밀번호를 잊었을 때도 기존 값을 알려주기보다 새로 설정하는 절차가 필요합니다.

연락을 위해 전화번호 원문이 필요하다면 암호화해 보관하고, 필요한 업무에서만 꺼내 쓰는 방안을 검토할 수 있습니다. 같은 번호인지 비교할 목적만 있다면 원문을 계속 보관해야 하는지도 다시 살펴볼 수 있습니다. 다만 전화번호처럼 가능한 값을 추측할 수 있는 정보는 단순한 해시값만으로 충분히 보호된다고 보기 어렵습니다. 비밀키를 사용하는 비교 방식의 적합성과 키 관리까지 검토하도록 안내하되, 특정 구성을 모든 서비스의 법적 의무처럼 제시하지 않아야 합니다.

본인확인 정보도 목적과 이용 범위를 확인해야 합니다

본인확인 과정에서는 연계정보(CI)와 중복가입 방지정보(DI)를 받을 수 있습니다. CI는 여러 서비스의 이용자를 연계해 구분하는 데, DI는 해당 웹사이트에서 같은 이용자의 중복가입 여부를 확인하는 데 쓰입니다. 읽기 어려운 문자로 보이더라도 회원과 연결해 사람을 구분하는 정보이므로 보호 대상에서 빠진다고 생각해서는 안 됩니다.

받은 값을 다른 서비스나 본인확인 기관에 다시 전달해야 하는지, 내부에서 같은 사람인지 비교하는 데만 쓰는지에 따라 검토할 방식이 달라집니다. 원래 값이 필요한 경우에는 암호화와 접근 제한을, 비교만 필요한 경우에는 원문 대신 비교용 값을 남길 수 있는지 검토하도록 안내할 수 있습니다. 제공 조건과 연계 기능에 맞는지도 담당자가 확인할 수 있어야 합니다.

값을 변환했다고 보관 목적과 기간을 확인할 필요가 없어지는 것은 아닙니다. 탈퇴 이후에도 중복가입 방지 등을 이유로 남기려면 필요한 범위와 보관 근거를 별도로 검토해야 합니다. 본인확인 정보에 적용되는 보호 기준을 확인하고, 불필요한 수집과 서비스 간 연결을 줄일 수 있도록 지원할 필요가 있습니다.

결제에 필요한 정보와 직접 보관할 정보를 구분해야 합니다

PG(결제 처리를 대신하는 결제대행사)의 결제창을 이용하면 서비스가 카드번호를 직접 받는 범위를 줄일 수 있습니다. 주문번호, 금액, 결제 결과와 거래를 구분하는 값처럼 서비스 운영에 필요한 정보를 먼저 정하고, 카드정보가 DB나 로그에 함께 남지 않는지 확인하도록 안내할 수 있습니다.

정기결제에 쓰는 빌링키는 등록한 결제수단으로 결제를 요청할 때 사용하는 값입니다. 카드번호가 아니라는 이유로 공개해도 되는 것은 아니므로, 사용할 프로그램과 담당자를 제한하고 유출이나 이용 종료 시 처리 방법도 확인해야 합니다. 카드결제 보안 기준인 PCI DSS에서는 상점이 결제 승인 후 카드 보안번호(CVC·CVV)를 보관하는 것을 금지하며, 암호화한 경우도 포함합니다. 결제 방식에 적용되는 기준과 제공업체의 조건을 확인할 경로가 필요합니다.

취소나 환불을 기존 거래번호로 처리할 수 있다면 계좌번호를 별도로 받을 필요가 있는지 검토해야 합니다. 가상계좌 환불이나 정산처럼 계좌정보가 필요한 업무는 제공업체의 처리 범위, 직접 보관할 이유와 기간, 원문에 접근할 사람을 확인하도록 안내할 수 있습니다. 결제를 외부에 맡겼다는 이유로 서비스에 남은 정보의 관리까지 끝나는 것은 아닙니다.

일부만 보여주는 화면과 원문 접근 권한을 함께 살펴야 합니다

마스킹은 이름이나 이메일의 일부를 가려 보여주는 방법입니다. 가상의 이름을 김*수처럼 표시하면 목록에서 원문을 반복해 노출하는 일을 줄일 수 있습니다. 다만 원래 이름을 브라우저에 모두 전달한 뒤 화면에서만 가렸다면, 그 정보는 이미 이용자의 기기에 도착한 것입니다. 일부만 볼 수 있는 사람에게는 가린 값만 보내는지 확인해야 합니다.

전체 정보가 필요한 업무에서는 볼 수 있는 권한과 용도를 확인하고, 필요한 항목만 제공하는 절차를 제안합니다. 조회 사유를 입력했다고 권한이 생기는 것은 아닙니다. 화면뿐 아니라 검색 결과, 파일 내려받기와 외부 전달에도 같은 기준을 적용할 수 있어야 합니다.

전체 조회 기록에는 누가 언제 어떤 항목을 어떤 이유로 보려 했는지와 성공·거부 여부를 남길 수 있습니다. 기록 자체에 개인정보 원문을 다시 복사하지 않고, 기록을 볼 수 있는 사람과 보관기간도 정해야 합니다. 내려받은 파일이나 담당자 기기에 남은 복사본까지 접근 제한과 보관·삭제 기준이 이어지도록 지원할 필요가 있습니다.

사용하는 기능에 맞춰 점검 항목을 고를 수 있어야 합니다

모든 서비스에 긴 점검표 하나를 적용하기보다, 공통 항목과 기능별 항목을 나누는 방안을 제안합니다. 먼저 어떤 개인정보가 어디에 남고 누구에게 전달되는지, 관리 권한과 통신 보호가 어떻게 적용되는지, 보안 업데이트를 누가 확인하는지 살펴볼 수 있습니다. 그다음 실제 사용하는 기능에 해당하는 항목을 더합니다.

다음은 점검표를 구성할 때 사용할 수 있는 질문의 예시입니다.

각 질문에는 적용 조건, 확인할 자료와 완료로 볼 근거를 붙일 필요가 있습니다. 같은 내용을 여러 점검표에서 확인했다면 결과를 함께 사용하되, 기능이나 설정이 바뀐 뒤에도 유효한지 살펴야 합니다. 적용해야 할 의무와 추가 개선을 구분하고, 개인정보 노출처럼 피해로 이어질 수 있는 문제가 발견되면 원래 순서보다 먼저 알리고 조치할 수 있어야 합니다.

AI가 확인한 결과와 운영자가 판단할 일을 구분해야 합니다

AI가 점검을 보조할 때는 허용된 코드와 설정, 제공업체의 공식 설명에서 먼저 확인한 뒤 근거를 남기도록 할 수 있습니다. 자료에서 알 수 있는 내용을 반복해서 묻기보다, 수집 목적이나 보관 필요성처럼 운영자가 결정할 일과 자료가 없어 확인하지 못한 부분을 질문하도록 안내할 필요가 있습니다. 실제 개인정보 원문이나 암호키를 대화에 붙여 넣게 하는 방식으로 확인 자료를 모아서는 안 됩니다.

결과는 확인한 범위에서 보호가 적용된 경우, 조치가 필요한 경우, 확인할 자료가 부족한 경우, 해당 기능을 사용하지 않아 적용되지 않는 경우로 구분할 수 있습니다. 확인 자료가 없다는 이유로 ‘해당 없음’으로 처리하거나, AI가 기능을 만들었다고 답했다는 이유로 ‘확인됨’으로 표시하지 않도록 기준이 필요합니다.

프로그램 파일만 살폈는지 실제 운영 설정과 처리 결과까지 확인했는지도 남겨야 합니다. 운영자가 이 구분을 바탕으로 다음 확인과 수정을 맡길 수 있도록, 검토할 담당자와 작업 시간을 확보하는 지원이 함께 필요합니다.