개인정보 유출 사고 사례: 개인정보위 처분에서 반복된 원인 5가지

국내 개인정보 유출 사고 사례를 개인정보보호위원회 처분 기준으로 보면, 원인은 고도의 해킹보다 다섯 가지로 모입니다. 객체 단위 권한 검증 누락, 알려진 웹 취약점과 패치 방치, 인증키·계정정보 관리 실패, 불필요한 접근 경로와 쌓아 둔 데이터, 이상 신호 미대응과 통지 지연입니다. 개인정보위도 쿠팡 사건을 설명하면서 원인을 "기본적인 안전관리 체계 미비 및 관리 소홀"이라고 표현했습니다.

따라서 우리 서비스가 먼저 확인할 것은 공격 기법 목록이 아닙니다. 타인 데이터를 서버가 거부하는지, 서명키를 누가 볼 수 있는지, 웹서버에서 DB로 가는 경로가 꼭 필요한지, 이상 알림을 누가 분석하는지를 봐야 합니다. 이 글은 피해 규모 대신 처분에서 지적된 사실을 추려 개발팀의 점검 항목으로 바꿨습니다.

자료 범위도 밝혀 둡니다. SK텔레콤과 쿠팡은 정부가 공개한 처분 자료를, 골프존과 카카오는 개인정보위 보도자료 내용을 옮긴 기사를 기준으로 했습니다. 전북대·이화여대, 영훈의료재단, 대교, 보람상조는 처분 내용을 전한 언론 보도로 확인했고 의결서 원문은 확인하지 못했습니다.

어떤 사고에서 어떤 원인이 나왔나

한 사고에 원인이 하나만 있는 경우는 드뭅니다. 아래 표는 처분 또는 조사 결과에서 확인된 항목만 표시했습니다.

사고	권한 검증	웹 취약점·패치	키·계정 관리	접근 경로·과잉 보관	탐지·통지
전북대	○	○			○
이화여대	○				○
영훈의료재단		○	○
대교		○		○	○
보람상조		○		○	○
골프존			○	○
SK텔레콤		○	○	○	○
쿠팡			○	○	○
카카오		○			○

카카오 사건은 항소심이 진행 중이고, SK텔레콤도 처분 취소 소송을 냈습니다. 두 사건의 지적 사항은 "법원이 확정한 사실"이 아니라 "개인정보위가 처분에서 판단한 내용"으로 읽어야 합니다.

원인 1: 로그인만 확인하고 대상 소유권은 확인하지 않았다

이화여대 사건에서는 세션값과 조회 대상이 일치하지 않아도 학번만 바꾸면 다른 사용자의 정보를 조회할 수 있었습니다. 전북대 사건에서도 비밀번호 찾기 페이지에서 학번을 확보한 뒤 조회 페이지에서 변조와 무작위 대입이 이어졌습니다. 두 취약점 모두 시스템 구축 당시부터 존재했다고 보도됐습니다.

개인정보위가 2026년 7월 낸 API 주의 안내도 같은 지점을 짚습니다. 로그인 여부만 확인하고 해당 데이터에 대한 권한은 확인하지 않는 API, 화면에 보이지 않는 정보까지 내려주는 응답, 개편 뒤 남은 미사용 API가 대표 유형입니다. OWASP Top 10:2025도 Broken Access Control을 1위로 두고, 기본 거부와 레코드 소유권 강제를 권고합니다.

// 취약: 로그인만 통과하면 URL의 학번으로 누구든 조회
app.get('/api/students/:studentNo/records', requireLogin, async (req, res) => {
  const record = await db.record.findUnique({
    where: { studentNo: req.params.studentNo },
  });
  res.json(record); // 화면에 없는 필드까지 전부 응답
});

// 고침: 조회 대상을 세션에서 결정하고, 필요한 필드만 응답
app.get('/api/me/records', requireLogin, async (req, res) => {
  const record = await db.record.findFirst({
    where: { ownerId: req.session.userId },
    select: { semester: true, courseName: true, grade: true },
  });
  if (!record) return res.sendStatus(404);
  res.json(record);
});

운영자 기능은 같은 경로에 조건을 얹지 말고, 별도 경로와 역할 검사로 분리하는 편이 안전합니다. 구현 패턴은 IDOR 취약점 방어법에 더 자세히 정리했습니다.

점검 항목

• 계정 두 개로 A의 토큰을 써서 B의 리소스를 요청하는 테스트가 CI에 있는가
• API 응답에 화면에서 쓰지 않는 개인정보 필드가 있는가
• 운영 중인 API 목록이 있고, 구버전·미사용 API를 제거했는가
• 학번·주문번호처럼 추측 가능한 식별자로 조회하는 경로에 호출 제한이 있는가

원인 2: 이미 알려진 취약점과 패치를 방치했다

영훈의료재단 사건에서는 병원 홈페이지의 SQL 인젝션 취약점이 공격 경로였습니다. 웹 공격 탐지·차단 장치와 웹 취약점 점검, 입력값 검증이 없었고, 안전하지 않은 암호 알고리즘에 솔트도 적용하지 않아 일부 비밀번호를 복호화할 수 있었다고 보도됐습니다. 보람상조도 홈페이지 SQL 인젝션으로 통합 고객 DB가 침해됐습니다.

대교 사건의 시작점은 관계사 홈페이지의 파일 업로드 취약점과 웹셸이었습니다. SK텔레콤 사건에서는 2016년 10월 패치가 공개된 OS 취약점(DirtyCow)이 2025년 4월까지 업데이트되지 않았고, 2020년부터 이를 탐지할 수 있었던 상용 백신도 설치되지 않았습니다.

# 취약: 입력값이 SQL 문장의 일부가 됨
query = f"SELECT id, name FROM members WHERE login_id = '{login_id}'"
cursor.execute(query)

# 고침: 값은 바인딩으로 분리
query = "SELECT id, name FROM members WHERE login_id = %s"
cursor.execute(query, (login_id,))

ORM을 쓴다고 끝나는 문제는 아닙니다. 원시 쿼리, 동적 정렬 컬럼, 검색 필터처럼 문자열을 직접 조립하는 곳을 찾아야 합니다.

점검 항목

• 저장소에서 문자열로 조립한 SQL을 검색해 없앴는가
• 업로드 파일이 실행 불가능한 별도 저장소에 저장되고, 저장 파일명은 서버가 생성하는가
• 관계사·이벤트·구형 페이지까지 점검 대상에 포함했는가
• 서버 OS와 패키지의 패치 상태를 자산별로 조회할 수 있는가
• 비밀번호를 bcrypt나 Argon2 같은 전용 해시로 저장하는가

원인 3: 인증키와 계정정보를 사람이 꺼내 볼 수 있었다

쿠팡 사건의 공격자는 대체 인증 기능을 개발했던 전직 직원이었고, 서명키로 인증 토큰을 위조했습니다. 개인정보위가 지적한 내용은 세 가지입니다. 업무상 필요 없는 직원도 키를 평문으로 볼 수 있었고, 키 시스템의 접근 권한 관리가 허술했으며, 퇴사 후 키를 신속히 갱신하거나 폐기하지 않았습니다.

SK텔레콤은 약 2,365개 서버의 계정정보가 담긴 파일을 관리망 서버에 암호 설정 없이 보관했고, HSS에서는 비밀번호 입력 없이 개인정보를 조회할 수 있었습니다. 유심 인증키도 평문으로 저장했습니다. 골프존은 재택근무를 확대하면서 ID와 비밀번호만으로 내부망 VPN 접속을 허용했습니다.

공통된 교훈은 퇴사자 계정 삭제만으로는 부족하다는 것입니다. 그 사람이 알던 비밀값도 함께 교체해야 합니다.

// 취약: 코드에 키가 있어 저장소를 본 사람이면 토큰을 위조할 수 있음
const SIGNING_KEY = 'fallback-auth-key';
const token = jwt.sign({ sub: userId }, SIGNING_KEY);

// 고침: 서명은 KMS 안에서 수행하고 키를 밖으로 꺼내지 않음
const token = await kmsSigner.sign({
  keyId: 'fallback-auth',
  claims: { sub: userId, aud: 'https://api.example.com' },
  expiresInSeconds: 900,
});
// 검증 측은 공개키로 알고리즘·발급자·대상·만료를 확인하고,
// 폐기된 키 ID로 서명된 토큰은 거부

점검 항목

• 운영 서명키를 사람이 평문으로 조회할 수 있는가. 있다면 몇 명이며 업무상 필요한가
• 키 조회와 사용 기록이 남고, 누군가 정기적으로 보는가
• 핵심 인력 퇴사 시 교체할 키 목록이 있고, 무중단 교체를 실제로 해 봤는가
• 예외 경로인 대체 인증도 주 인증과 같은 수준으로 관리하는가
• VPN과 관리자 접속에 추가 인증이 있는가

원인 4: 필요 없는 경로를 열어 두고, 데이터가 어디 있는지 몰랐다

대교 사건에서는 관계사 웹서버가 대교 회원 DB에 직접 연결될 수 있었습니다. 관계사 쪽 침해가 곧바로 회원 정보 유출로 이어진 구조입니다. SK텔레콤 사건에서는 필요 없는 관리망 서버와 HSS 간 상호접속이 허용돼 인터넷에서 핵심 DB까지 경로가 이어졌습니다. 골프존도 서버 간 원격 접속과 전체 서버의 인터넷 통신을 허용했습니다.

데이터 파악도 함께 지적됐습니다. 골프존은 파일서버에 개인정보가 다량 저장되어 있다는 사실을 인지하지 못했고, 주민등록번호 등을 암호화하지 않았습니다. 보유기간이 지난 정보를 파기하지 않은 점은 골프존, 쿠팡, 보람상조 모두에서 나왔습니다. 없었어야 할 데이터는 애초에 유출될 수도 없습니다. SK텔레콤 처분에서는 CPO의 업무가 웹·앱에 한정돼 통신 인프라의 처리 실태를 파악하지 못한 점도 지적됐습니다.

점검 항목

• DB 방화벽 또는 보안 그룹의 허용 출발지를 하나씩 설명할 수 있는가
• 애플리케이션 서버의 인터넷 아웃바운드를 필요한 대상으로 제한했는가
• 계열사·외주 시스템과 공유하는 DB 계정이 있는가
• 스토리지, 공유 드라이브, 로그, 분석 도구, 백업의 개인정보 위치를 알고 있는가
• 탈퇴와 보유기간 만료 시 파기가 자동으로 실행되고, 실행 결과를 확인하는가

원인 5: 신호를 받고도 분석하지 않았고, 통지가 늦었다

탐지 도구가 없어서 생긴 문제만은 아닙니다. 쿠팡은 개인정보 페이지 트래픽이 평소보다 크게 늘었는데도 고객 민원 전까지 알아채지 못했고, 임계치가 느슨했으며, 탐지된 이상 징후 상당수를 깊이 분석하지 않았습니다. 대교는 보안관제업체의 탐지 안내를 받고도 상세 분석과 차단을 소홀히 해 이듬해 같은 방식으로 다시 유출됐습니다. SK텔레콤은 2022년 2월 해커의 HSS 접속을 확인하고도 점검하지 않았습니다. 전북대·이화여대는 주말·야간 모니터링 미흡이 지적됐습니다.

단순 요청 수만 보면 정상 트래픽에 묻힙니다. 이화여대 사례처럼 "한 주체가 타인 정보를 반복 조회"하는 패턴을 직접 지표로 만드는 편이 효과적입니다.

-- 최근 10분간 본인 외 정보를 많이 조회한 주체 찾기
SELECT actor_id, COUNT(DISTINCT target_user_id) AS target_count
FROM personal_data_access_log
WHERE accessed_at >= NOW() - INTERVAL '10 minutes'
  AND target_user_id <> actor_id
GROUP BY actor_id
HAVING COUNT(DISTINCT target_user_id) > 20; -- 예시 값, 역할별 평소 기준선으로 조정

통지 지연은 거의 별도 위반처럼 따라붙습니다. SK텔레콤은 외부 전송을 확인하고도 72시간 내 통지하지 않았고, 쿠팡은 일부 회원 통지가 72시간을 넘겼으며 비회원에게는 통지하지 않았습니다. 카카오와 보람상조도 신고·통지 관련 사항이 지적됐습니다. 쿠팡은 보존 조치 후에도 앱 접속 로그가 삭제된 점 때문에 고발 대상이 됐습니다. 사고 직후 로그 보존 지시가 자동 삭제 작업까지 멈추는지도 확인해야 합니다. 시간대별 절차는 개인정보 유출 신고 절차를 참고할 수 있습니다.

점검 항목

• 개인정보 조회 로그에 누가, 누구의 정보를, 언제 봤는지 남는가
• 관제·알림을 받은 뒤 분석과 종결 기록을 남기는 담당자가 있는가
• 야간과 주말의 알림 수신자가 정해져 있는가
• 사고 시 로그 자동 삭제를 멈추는 방법이 문서화돼 있는가
• 회원뿐 아니라 배송지 수신자 같은 제3자 정보도 통지 범위에 넣어 판단하는가

2026년 9월 개정법 이후 어떤 순서로 점검할까

2026년 9월 11일 시행된 개정 개인정보 보호법은 이 점검의 우선순위를 높입니다. 보도에 따르면 3년 내 고의·중과실 반복, 1천만 명 이상 피해, 시정명령 미이행으로 인한 유출 등에는 전체 매출의 10%까지 과징금이 가능합니다. 유출 "가능성"을 안 단계부터의 통지, 위조·변조·훼손까지 넓어진 범위도 포함됩니다. 세부 요건은 법령 원문으로 확인해야 합니다.

시간이 부족한 팀이라면 다음 순서를 권합니다.

1. 이번 주: 개인정보 API의 교차 계정 테스트와 응답 필드 축소. 외부에서 바로 악용되는 문제이고, 비용이 작습니다.
2. 이번 달: 서명키·DB 계정·관리자 접근 목록 정리와 추가 인증 적용, 문자열 SQL과 업로드 경로 점검.
3. 이번 분기: DB 접근 경로 축소, 개인정보 위치 목록 작성, 파기 자동화.
4. 상시: 타인 정보 조회 지표, 알림 처리 기록, 72시간 통지 모의 훈련.

자주 묻는 질문

작은 스타트업도 처분 대상이 되나요?

됩니다. 이 글의 사례는 대기업에 한정되지 않습니다. 병원, 학교, 구형 쇼핑몰 솔루션 운영사도 처분을 받았고, 과징금이 수백만 원대인 사례도 있습니다. 규모보다 처리하는 개인정보와 안전조치 이행 여부를 봐야 합니다.

취약점 스캐너 결과가 깨끗하면 안심해도 되나요?

원인 1과 3~5는 스캐너만으로 확인하기 어렵습니다. 소유권 규칙, 키 조회 권한, 알림 처리 절차는 서비스의 맥락이 필요하기 때문입니다. 스캐너는 원인 2의 일부를 찾는 도구로 쓰고, 권한 테스트와 설정 검토를 함께 하는 것이 좋습니다.

유출이 확정되지 않았는데도 통지를 준비해야 하나요?

네. 개정법은 유출 가능성을 알게 된 경우까지 통지 대상을 넓혔습니다. 확정 때까지 기다리지 말고, 확인된 범위로 먼저 판단할 수 있도록 담당자와 문안을 미리 정해 두는 편이 좋습니다. 구체적인 적용은 법무 검토와 함께 판단하세요.

정리

개인정보위 처분에서 반복된 원인은 권한 검증, 알려진 취약점, 키·계정 관리, 접근 경로와 과잉 보관, 탐지와 통지입니다. 대부분 새로운 기법이 아니라 있어야 할 기본 통제가 실제로 작동하지 않은 경우였습니다. 개발팀은 교차 계정 테스트와 응답 필드 축소부터 시작하고, 서명키와 DB 접근 경로를 이어서 점검하면 됩니다. 이후에는 알림을 누가 분석하는지, 72시간 안에 움직일 수 있는지를 훈련으로 확인하세요. 직접 점검이 어렵다면 무료 분석 신청으로 외부 시각의 분석을 받아볼 수 있습니다.