필요한 정보만 수집

필드가 있으면 목적과 종료도 있어야 합니다

행사 신청 폼에 전화번호를 추가하자는 요청을 받았습니다. “언젠가 연락할 수 있다”는 말만으로 필수 필드를 만들면 상태 조회라는 목표와 무관한 정보가 쌓입니다. 조사에서 선택한 Q01은 결과 확인 경로를 찾지 못하는 재문의입니다. 연락처 수집이 이 문제를 해결한다는 근거는 아직 없습니다. 이번 레슨은 기존 eventId·applicationId·status에 목적, 필수 여부, 생성 주체, 열람자, 보관 종료, 삭제 책임을 붙이고 불필요한 전화번호를 제외하는 판단을 작성합니다.

수집 목적을 실제 행동으로 씁니다

목적을 “서비스 운영”이라고 적으면 어떤 필드도 필요하다고 주장할 수 있습니다. eventId의 목적은 어느 행사에 신청했는지 연결하는 일, applicationId는 내역의 한 신청을 구별하는 일, status는 접수와 승인 결과를 표시하는 일입니다. 각 필드가 없으면 어떤 행동을 할 수 없는지 설명합니다. 목적이 상태 조회라면 사용자에게 전화나 문자를 보내는 기능은 별도의 제안입니다. 새 연락 기능이 확정되기 전에는 전화번호를 필수로 넣지 않는 결정을 남깁니다.

필수 여부는 폼에서 별표를 붙이는 문제만이 아닙니다. eventId는 사용자 선택으로 필요하지만 applicationId와 status는 서버 생성 값이므로 사용자가 입력하지 않습니다. 필드 표에서 required=true라고 해도 “사용자에게 직접 받는다”는 뜻은 아닙니다. 생성 책임을 분리하면 운영자가 신청 번호와 승인 상태를 임의로 입력하게 하는 화면 실수를 피할 수 있습니다. 수집하지 않는 phone은 collect=false, required=false, source=excluded로 적고 입력칸·API·로그에서 제외합니다.

소유권에는 연결 정보가 필요합니다

앞 모듈의 모의 API는 신청 소유자를 저장하지 않습니다. 본인 신청만 조회하도록 제안하려면 ownerUserId를 서버가 확인한 세션 주체에서 얻어 신청에 연결하는 후속 설계가 필요합니다. 클라이언트가 아무 계정 번호를 보내게 하고 그대로 소유자로 저장하면 권한 표의 전제가 무너집니다. 이번 fields에는 ownerUserId의 source를 server-session으로 적으며 일반 화면 열람자는 서버만으로 제한합니다. 실제 저장·권한 검사 구현 여부는 limits에 미확인으로 남깁니다.

기존 data-flow.json에는 applicationId가 개인정보가 아니라는 표현이 있습니다. 연습의 A001은 가명 자료지만 실제 계정과 연결되는 신청 식별자가 언제나 개인정보가 아니라고 단정할 수 없습니다. 이름을 지웠어도 다른 기록과 연결해 개인을 식별하거나 활동을 추적할 수 있습니다. 이전 문서를 몰래 바꾸지 않고 corrections에서 표현의 한계와 보호 범위를 보완합니다. 법적 분류는 적용 환경의 담당자 검토가 필요하며 이번 문서에서는 연결 가능한 식별자로서 접근과 삭제를 제한합니다.

열람자는 역할 이름만 쓰지 않습니다

본인과 운영자라는 두 단어만 쓰면 모든 운영자가 모든 행사 신청을 읽는 것으로 해석될 수 있습니다. 필드의 readers에는 self·operator를 쓰고 permissions의 담당 행사 in 조건과 함께 읽게 합니다. status는 본인과 담당 운영자에게 보이지만 다른 신청자에게 공개하지 않는 제안입니다. ownerUserId는 서버 소유권 검사에 쓰며 조회 응답에 그대로 노출할 필요가 없습니다. 내부 처리에 필요한 정보와 화면 표시가 필요한 정보를 구별해서 응답 계약 검토 질문을 만듭니다.

지원 담당자가 원인 파악을 해야 한다는 이유만으로 전체 신청 목록을 내려받게 하지 않습니다. 오류 코드·요청 번호·발생 시각으로 필요한 기록을 좁히고 제한된 내부 담당자가 조회하도록 제안합니다. 행사 운영자와 지원 담당자는 업무 목적이 다를 수 있으므로 같은 권한을 자동 부여하지 않습니다. 새 지원 역할이 필요하면 어떤 필드를 어떤 문의에 얼마 동안 볼지 추가 합의합니다. 자동 검사기의 self·operator 열람 목록은 이 연습의 기준이지 모든 조직의 권한 정답이 아닙니다.

보관 종료는 실행할 수 있는 사건으로 정합니다

“필요 없어지면 삭제”는 담당자가 같은 날짜를 떠올릴 수 없는 기준입니다. 교육용 예시는 행사 종료와 이의 확인 완료라는 두 사건 뒤 30일에 삭제하는 제안입니다. 30일은 법정 기간이나 보안 표준 수치가 아닙니다. 실제 적용 전에 업무·개인정보 담당자가 목적, 이의 처리, 적용 요건을 검토하고 기간을 확정합니다. 이의 확인이 미완료일 때 누가 재검토하는지도 적어 종료 사건이 오지 않아 영구 보관되는 상황을 논의합니다.

삭제 책임은 업무 담당자의 대상 목록 승인, 개발 담당자의 실행과 결과 기록으로 나눕니다. 원본 신청 행을 지웠어도 CSV 내보내기, 지원 첨부, 백업 복원으로 같은 연결 정보가 남을 수 있습니다. 각각의 저장 위치와 접근자, 삭제 또는 격리 방법, 백업 보관 종료 시점을 확인할 후속 목록에 넣습니다. 실제 백업 처리 방법을 모르는 상태에서 즉시 완전 삭제했다고 쓰지 않습니다. 삭제 범위를 설명할 수 있어야 보관 종료 문장이 검토 가능한 운영 요구사항이 됩니다.

수집 제외와 선택 입력의 차이를 봅니다

전화번호를 선택 입력으로 바꾸면 부담은 줄지만 여전히 수집·저장·열람·삭제의 책임이 생깁니다. 이번 개선은 상태를 신청 내역에서 확인하도록 하므로 추가 연락처 자체를 받지 않는 제안입니다. collect=false라면 화면뿐 아니라 API가 받아 저장하거나 로그에 남기는 길도 제외하는 기준을 씁니다. 마케팅 알림처럼 별도 목적이 나중에 생기면 원래 신청 목적에 몰래 합치지 않고 새 목적과 사용자 안내를 검토합니다. 편의와 필요를 구별하는 문장이 제품 범위를 지켜 줍니다.

흔한 실수는 필수로 수집하면서 목적을 빈칸으로 두거나, 수집하지 않는 필드에 열람자를 넣는 것입니다. 검사에서 fields: 수집·필수 여부 오류가 나오면 collect와 required가 true·false 불리언인지 확인합니다. 문자열 “false”는 불리언 false가 아닙니다. fields: 생성 주체 오류는 사용자 입력과 서버 생성 책임이 바뀌었는지 보라는 뜻입니다. 통과하려고 검사기를 고치기보다 필드의 실제 목적과 결정값을 표에 대조합니다. 문구의 타당성은 구조 검사 후 동료가 검토합니다.

정책 표와 기존 계약 사이의 차이를 남깁니다

제출에는 기존 계약의 세 필드, 추가 소유권 필드, 제외 전화번호 다섯 행을 씁니다. 수집 필드는 목적과 보관 종료·삭제 절차를, 제외 필드는 제외 이유와 들어오지 않아야 할 경로를 설명합니다. 추가 ownerUserId는 기존 API가 이미 구현한 사실로 기록하지 않습니다. review.status=proposed로 표시하고 실제 화면·응답·로그가 이 정책을 따르는지 확인할 담당자를 정합니다. 자동 검사는 이 다섯 행과 연결 구조를 확인할 뿐 개인정보 보호의 실제 이행을 인증하지 않습니다.

더 읽기의 환경변수 장은 운영 비밀을 코드와 공유 출력에 드러내지 않는 기술 보충입니다. 신청 데이터의 보관 목적과 개발 환경의 API 토큰 관리가 같은 문제는 아니지만 둘 다 필요한 접근자와 노출 경로를 확인해야 합니다. 여기서는 환경변수 설정 코드를 옮기지 않고 개인정보 필드와 인증 비밀을 다른 목록으로 관리합니다. 다음 레슨에서는 자료를 더 받는 대신 허용된 증거로 문의를 좁히는 지원 절차를 작성합니다.