개인정보보호법(PIPA)은 한국 거주자의 개인정보를 수집·저장·처리하는 모든 서비스에 적용됩니다. 해외에서 운영 중인 서비스도 예외가 아닙니다.
법무팀이나 컴플라이언스 담당자가 처리하는 부분도 있지만, 상당수는 개발자가 직접 구현해야 하는 기술적 요구사항입니다. 이 글은 그 부분만 다룹니다.
데이터 수집 & 최소화
- [ ] 명시된 목적에 필요한 개인정보만 수집
- [ ] API 레이어에서 불필요한 필드를 거부하는 입력 검증 구현
- [ ] 어떤 개인정보를, 어디서, 왜 수집하는지 문서화 (데이터 플로우)
- [ ] 만 14세 미만 대상 서비스인 경우 연령 확인 메커니즘 구현
동의 & 투명성
- [ ] 데이터 수집 전 명시적 동의 획득 (약관 속에 묻어두기 금지)
- [ ] 사용자가 자신의 데이터를 조회할 수 있는 API 구현 (정보주체 접근권)
- [ ] 삭제 요청 시 DB 레이어까지 실제로 삭제되는 기능 구현
- [ ] 계정 삭제 없이도 동의 철회 가능하도록 구현
접근 제어
- [ ] 개인정보 접근은 역할 기반(RBAC)으로 제한 — 모든 개발자가 프로덕션 PII 조회 불가
- [ ] 개인정보 접근 로그 기록 (쓰기뿐 아니라 읽기도)
- [ ] PII 접근 권한이 있는 관리자 패널에 MFA 적용
- [ ] 서비스 계정이 PII 테이블에 직접 접근하지 못하도록 제한
암호화 & 저장
- [ ] 저장된 개인정보 암호화 (AES-256 이상)
- [ ] 전송 중 개인정보에 TLS 1.2+ 적용 (TLS 1.3 권장)
- [ ] 암호화 키를 보호 대상 데이터와 같은 위치에 저장하지 않음
- [ ] 개인정보가 포함된 백업도 암호화
자격증명 & 시크릿 관리 ⚠️
이 항목이 감사에서 가장 자주 지적받습니다.
- [ ] DB 자격증명을 애플리케이션 코드나 바이너리에 하드코딩하지 않음
- [ ] 이메일, SMS, 분석 서비스 등 PII 인접 서비스의 API 키를 하드코딩하지 않음
- [ ] 시크릿 교체 주기 문서화 및 이행
- [ ] 배포 전 바이너리 아티팩트에 삽입된 시크릿 스캔 ← 대부분의 팀이 놓치는 부분
마지막 항목을 놓치는 이유는 악의가 아닙니다. 시크릿 관리 정책이 소스코드 중심(git 히스토리 스캔, .env 파일 보호)으로만 짜여져 있어서, 컴파일된 아티팩트가 별도의 공격 표면이라는 사실을 간과하기 때문입니다.
개발자가 소스코드에서 시크릿을 제거합니다. 2주 전에 빌드된 바이너리는 여전히 스테이징에서 돌고 있고, 여전히 그 시크릿을 갖고 있습니다.
침해 대응
- [ ] 침해 통지 프로세스 문서화 (PIPA: 72시간 내 신고 의무)
- [ ] 모니터링에서 개인정보 침해를 다른 인시던트와 구별 가능하도록 설정
- [ ] KISA(한국인터넷진흥원) 신고 절차 숙지
제3자 위탁
- [ ] 한국 개인정보를 처리하는 모든 외부 벤더 목록 작성
- [ ] 각 벤더와 개인정보 처리 위탁 계약 체결
- [ ] 적정성 결정 미승인 국가로의 국외 이전 시 명시적 동의 획득
대부분의 팀이 놓치는 한 가지
위 목록 중 기술적으로 가장 구현이 어렵거나 비용이 많이 드는 항목은 없습니다. 그러나 배포 전 바이너리 시크릿 스캔은 체계적으로 수행하고 있는 팀이 드뭅니다.
이유는 간단합니다. 기존 시크릿 스캐닝 도구(GitLeaks, TruffleHog 등)는 소스코드와 git 히스토리를 스캔합니다. 컴파일된 바이너리는 완전히 다른 아티팩트입니다.
pipaguard는 이 간격을 채웁니다. Go 바이너리를 직접 스캔해서 숨겨진 자격증명, 고엔트로피 문자열, 내부 엔드포인트를 찾아냅니다. CI에 통합하면 60초 안에 스캔이 완료되고, 결과는 감사 보고서에 포함할 수 있는 형태로 제공됩니다.
지금 바로 컴플라이언스 점검하기
바이너리 하나만 있으면 됩니다. 소스코드나 설정 없이도 스캔 가능합니다.