11. 신규 서비스 검토할 때 가장 먼저 보는 것들

신규 서비스나 시스템이 나오면
보안·개인정보 담당자 쪽으로 문서가 하나 둘씩 넘어옵니다.

기획서, 화면 설계, API 명세, 인프라 구성도…
처음에는 이걸 어디서부터 봐야 할지 막막할 수 있습니다.

저도 초반에는 체크리스트만 붙들고 헤매다가,
시간이 지나면서 자연스럽게 순서를 조금 정리하게 됐습니다.
지금은 대략 아래 순서로 보는 편입니다.

1. 이 서비스는 누가, 무엇을 위해 쓰는가

가장 먼저 보는 것은 기술 요소가 아니라
서비스의 목적과 사용자입니다.

• 누가 쓰는 서비스인지 (내부 직원, 고객, 파트너 등)
• 어떤 가치를 주려고 하는지
• 어떤 데이터가 있어야 그 가치가 나오는지

이 세 가지가 정리되어야
데이터 수집 항목이 과한지, 적당한지,
보안 수준을 어느 정도로 잡아야 할지 감이 잡힙니다.

2. 개인정보가 어디에서 어떻게 흐르는지

다음으로는 개인정보 흐름을 거칠게 그려봅니다.

• 입력: 어디서 들어오는지
  (앱, 웹, API, 배치, 제휴사 등)
• 저장: 어디에 쌓이는지
  (DB, 로그, 캐시, 외부 스토리지 등)
• 전송: 어떤 구간을 타고 오가는지
  (내부망, 인터넷, 제3자, 클라우드 등)
• 출력: 어디로 나가는지
  (화면, 리포트, 외부 연동, 통계 등)

이 흐름이 눈에 들어오면
암호화, 접근통제, 로그, 망 구성 같은 것들이
어느 구간에서 필요한지 자연스럽게 따라옵니다.

3. 꼭 필요한 정보만 쓰고 있는지

그다음 보는 것은 수집 항목입니다.

• 서비스 목적을 달성하는 데
  정말 필요한 정보인지
• 이미 다른 시스템에서 가지고 있는 정보는 아닌지
• 나중에 혹시 다른 목적으로 쓰려고 미리 받아두려는 건 아닌지

실무에서는
“일단 받아 두면 언젠가 쓰겠지”라는 말이
생각보다 자주 나옵니다.

그럴수록

• 지금 당장 쓰지 않는 정보는 최소화하고
• 나중에 정말 필요해지면
  그때 근거와 함께 다시 설계하자

라는 방향으로 조율하는 편이
리스크 관리 측면에서 훨씬 깔끔했습니다.

4. 누가 어느 정도까지 볼 수 있어야 하는지

권한 설계는
처음에 대충 잡아두면
나중에 정리하는 데 훨씬 더 많은 비용이 듭니다.

그래서 최대한 초기에 질문을 던집니다.

• 이 데이터는 누가 꼭 봐야 하는지
• 단순 조회와 수정, 삭제 권한을 어떻게 나눌지
• 외주·협력사 계정이 필요한지, 필요하다면 범위를 어디까지 줄지

권한을 넓게 주는 것은 순간에는 편하지만,
사고가 나면 그 범위만큼 설명해야 할 것도 늘어납니다.

5. 로그를 어디까지 남기고, 얼마나 오래 볼 수 있는지

새로운 서비스를 볼 때
로그는 거의 후순위로 밀리는 경우가 많습니다.

하지만 사고가 나거나,
문의가 들어오거나,
점검·감사를 받을 때
결국 마지막에 기대게 되는 것이 로그입니다.

그래서 처음 검토 단계에서
아래 정도는 꼭 확인하려고 합니다.

• 누가, 언제, 어떤 데이터에 접근했는지 남길 수 있는지
• 오류·예외 상황이 어느 수준까지 기록되는지
• 로그를 얼마나 보관하고, 누가 열람할 수 있는지

6. 법·규제와의 연결 고리

마지막으로
이 서비스가 어떤 규제와 관계가 있는지 정리해 둡니다.

• 국내 개인정보보호법에서 특별히 더 요구하는 부분이 있는지
• ISMS-P, ISO 등 인증 항목과 직접적으로 연결되는 부분이 있는지
• 국외 이전, 제3자 제공, 민감정보 처리 등 민감한 요소가 있는지

처음부터 여기까지 완벽하게 보고 시작할 수는 없지만,
적어도 방향을 한 번 짚어두면
추후 영향평가나 점검을 준비할 때
논의를 다시 처음부터 시작하지 않아도 된다는 장점이 있었습니다.