콘텐츠로 이동

보안 사고 뉴스로 백엔드 면접 준비하기 — 공식 조사 결과를 설계 질문으로 바꾸는 법

큰 보안 사고가 터지면 면접에서 "그 사고 어떻게 보셨어요?"라는 질문이 나오기 쉽습니다. 이때 기사 제목을 옮기는 답과, 사고 원인을 내가 만드는 서버의 설계 질문으로 바꿔 말하는 답은 차이가 큽니다. 이 글은 2025~2026년에 정부가 공식 조사 결과를 발표한 세 사고를 골라, 확인된 원인만 뽑아 백엔드 설계 질문으로 바꾸고, 제가 운영하는 서비스와 강의 교재에서 그 질문에 어떻게 답했는지 코드로 연결합니다.

이 글의 기준

2025년 12월에 올린 같은 주제의 글은 유튜브 영상 한 편을 요약한 것이었고, 일부 사고 원인을 언론 분석에 기대어 단정했습니다. 2026-10-24에 과학기술정보통신부·금융위원회·개인정보보호위원회의 공식 발표로 사실을 다시 확인해 전면 다시 썼습니다. 공식 발표에 없는 내용은 "보도·추정"으로 따로 표시했습니다. 코드 예시는 제가 혼자 운영하는 정책 뉴스 서비스 On Pocket News의 저장소와 개인 위키의 Java/Spring 교재에서 옮겼습니다.

1. 출처 등급부터 나눈다

면접에서 사고를 말할 때 가장 먼저 무너지는 것은 사실 관계입니다. 기사마다 원인이 다르게 적혀 있기 때문입니다. 롯데카드 사고가 좋은 예입니다. 2025년 9월 보안뉴스는 2017년에 패치가 나온 오라클 웹로직 취약점(CVE-2017-10271)이 쓰였다고 보도했습니다. 그런데 금융위원회 발표와 이후 개인정보보호위원회 의결 자료에는 취약점 이름이 나오지 않습니다.

등급 예 면접에서 말하는 법
공식 조사 결과 과기정통부 민관합동조사단 발표, 개인정보위 의결 "조사 결과에 따르면 ~입니다"
당국의 1차 발표 금융위원회 긴급 대책회의 자료 "당국 발표 기준으로 ~입니다"
언론 보도·업계 추정 특정 CVE가 쓰였다는 분석 기사 "~라는 보도가 있었지만 공식 확인은 못 봤습니다"

교훈: 확인된 사실과 추정을 나눠 말하는 태도 자체가 면접관에게는 신뢰 신호입니다. 보안 담당자가 사고 보고서를 쓸 때 하는 일도 같습니다.

2. 쿠팡 — "토큰 서명키는 누가, 어디에, 언제까지 갖고 있나"

과기정통부는 2026년 2월 쿠팡 침해사고 민관합동조사단 조사 결과를 발표했습니다. 확인된 원인은 다음과 같습니다.

  • 공격자는 재직 중 관리하던 인증 시스템의 서명키를 빼내 전자 출입증(인증 토큰)을 위·변조했고, 정상 로그인 없이 이용자 계정에 접속했습니다.
  • 관문 서버에 전자 출입증이 정상 발급된 것인지 검증하는 절차가 없었습니다.
  • 담당자가 퇴사할 때 서명키를 갱신하는 절차가 미비했고, 개발자 노트북에 서명키가 저장된 정황이 확인됐습니다.
  • '내 정보 수정' 페이지에서 성명·이메일 등 33,673,817건이 유출됐고, 쿠팡은 이를 탐지·차단하지 못했습니다.

이 원인을 설계 질문으로 바꾸면 이렇습니다.

  1. JWT의 서명키는 어디에 보관하고, 누가 읽을 수 있습니까?
  2. 서명키를 교체하면 이미 발급된 토큰은 어떻게 됩니까?
  3. 서명만 맞으면 그 토큰을 믿습니까, 아니면 발급 기록과 대조합니까?

위키의 Java 교재 「서버와 인증」 장은 JWT의 Signature를 "위변조 방지용 서명"으로 설명하고, 자주 하는 실수로 만료 전략 없는 무기한 토큰과 재발급 전략 없는 발급만 구현을 꼽습니다. 서명이 위변조를 막는다는 말에는 서명키가 새지 않는다는 전제가 숨어 있습니다. 쿠팡 사고는 그 전제가 깨진 경우입니다.

On Pocket News에서는 수집 에이전트에 토큰을 줄 때 원문 대신 SHA-256 해시만 저장하고, 토큰이 맞더라도 요청 경로의 에이전트와 일치하는지 한 번 더 확인합니다.

if (authenticatedAgent != null) {
    // path에 agent id가 포함된 경우 토큰의 에이전트와 일치해야 함 (cross-agent 방지)
    val pathAgentId = AGENT_ID_IN_PATH.find(path)?.groupValues?.getOrNull(1)
    if (pathAgentId == null || pathAgentId == authenticatedAgent.id) return true
    response.sendError(HttpStatus.FORBIDDEN.value(), "에이전트 토큰이 요청 대상과 일치하지 않습니다.")
    return false
}

외부 앱용 읽기 키는 지금 비밀값 저장소의 값 하나로 관리합니다. 그래서 키를 바꿀 때마다 재배포가 필요하고 마지막 사용 시점도 알 수 없습니다. 이 한계를 백로그에 "어드민에서 발급·폐기, 해시만 저장, 마지막 사용 시각 기록" 항목으로 올려 두었습니다. 키를 폐기할 수 있는 구조가 있어야 퇴사나 유출 같은 상황에 대응할 수 있기 때문입니다.

교훈: 인증 질문의 핵심은 토큰 형식이 아니라 키의 수명입니다. 발급, 보관, 교체, 폐기 네 단계를 말할 수 있으면 됩니다.

3. SK텔레콤 — "비밀값을 평문으로 둔 곳이 있습니까"

과기정통부가 2025년 7월 4일 발표한 SK텔레콤 침해사고 최종 조사 결과에서 지적된 문제는 다음과 같습니다.

  • 음성통화 인증(HSS) 관리 서버의 계정 정보가 다른 서버에 평문으로 저장돼 있었고, 공격자가 이를 활용한 것으로 추정됐습니다.
  • 유심 복제에 악용될 수 있는 인증키(Ki)를 암호화하지 않고 저장했습니다. 조사단은 다른 통신사 두 곳은 이를 암호화해 저장하고 있었다고 밝혔습니다.
  • 2022년 이상 징후를 발견했을 때 로그 6개 중 1개만 확인하고 점검을 끝냈고, 방화벽 로그는 자체 규정(6개월)에 못 미치는 4개월만 보관했습니다.
  • 유심 정보 25종, 9.82GB, IMSI 기준 약 2,696만 건이 유출됐습니다.

면접 질문으로는 이렇게 바꿉니다. "DB 비밀번호와 외부 API 키는 어디에 둡니까?", "개인정보 중 무엇을 암호화하고, 그 키는 데이터와 같은 곳에 있습니까?", "로그는 얼마나 보관합니까?"

위키의 카카오 책 검색 연동 과제는 첫 단계가 코드가 아니라 키를 두면 안 되는 곳을 정하는 표입니다. Java 코드와 application.yml에 직접 쓰면 커밋 기록에 남고, 화면의 VITE_ 환경 변수는 빌드할 때 자바스크립트 파일에 그대로 박힙니다. 그래서 키는 서버의 Git 제외 파일이나 환경 변수에만 둡니다.

On Pocket News는 2026년 10월 개편에서 회원 이름과 전화번호를 AES-256-GCM으로 암호화해 저장하도록 바꿨습니다. 이미 평문으로 저장된 회원이 있었기 때문에, 암호문에 enc:v1: 접두어를 붙이고 접두어가 없는 값은 기존 평문으로 읽은 뒤 서버 시작 시 자동으로 암호화해 다시 저장하게 했습니다. 암호화 키는 데이터베이스가 아니라 클라우드 비밀값 저장소에 두고, 키를 잃으면 데이터를 복구할 수 없다는 경고를 운영 문서 맨 위에 적었습니다.

교훈: "암호화했습니까?"보다 "키를 어디에 뒀습니까?"가 더 좋은 질문입니다. 데이터와 키가 같은 곳에 있으면 한 번에 함께 털립니다.

4. 롯데카드 — "로그에 무엇을 남깁니까"

금융위원회는 2025년 9월 18일, 해커가 롯데카드 온라인 결제 서버(WAS)에 웹셸을 설치해 8월 14~27일 사이 약 200GB의 정보를 빼냈고 약 296.9만 명의 개인신용정보가 포함됐다고 발표했습니다. 그중 약 28.3만 명은 카드 비밀번호와 CVC 번호까지 유출됐습니다.

설계 관점에서 더 배울 것은 2026년 3월 11일 개인정보보호위원회의 제재 의결입니다. 개인정보위는 롯데카드가 결제 관련 로그에 주민등록번호를 평문으로 기록했고, 로그 파일 암호화가 미흡했으며, 최소한만 남겨야 할 로그에 여러 개인정보 항목을 검토 없이 저장한 것이 대규모 유출의 원인 중 하나였다고 밝혔습니다. 과징금은 96억 2,000만 원이었습니다.

로그는 개발자가 디버깅하려고 가장 쉽게 늘리는 곳이고, 그만큼 개인정보가 새어 들어가기 쉬운 곳입니다. On Pocket News의 외부 앱 키 검사는 요청 헤더의 키를 앱 이름으로 바꾼 뒤 앱 이름만 로그에 남깁니다.

val clientApp = request.getHeader(HEADER_CLIENT_KEY)?.trim()?.let { clientKeys[it] }
if (clientApp != null && method == "GET" && CLIENT_READ_PATTERNS.any { it.matches(path) }) {
    log.info("client-app={} GET {}", clientApp, path)

교재의 JWT 설명에 있는 원칙도 같은 방향입니다. Payload는 암호화가 아니라 인코딩이므로 민감 정보를 넣지 않습니다. 토큰이든 로그든, 누군가 읽을 수 있다고 가정하고 내용을 정합니다.

교훈: 로그 설계 질문에는 "무엇을 남기나"와 함께 "무엇을 남기지 않나"를 답해야 합니다.

5. 사고를 면접 답변으로 바꾸는 틀

세 사고를 OWASP Top 10:2025 항목과 위키 개념에 연결해 한 표로 정리합니다.

사고 공식 확인된 원인 OWASP Top 10:2025 설계 질문 연결 개념
쿠팡 서명키 유출·토큰 위조, 발급 검증 없음, 퇴사 시 키 미갱신 A07 Authentication Failures 서명키 보관·교체·폐기 교재 「서버와 인증」 8.3 토큰 기반 인증
SK텔레콤 계정 정보 평문 저장, 인증키 미암호화, 로그 점검·보관 부족 A04 Cryptographic Failures, A09 Security Logging and Alerting Failures 비밀값 위치, 암호화 키 분리, 로그 보관 과제 2-4 키 보관 표
롯데카드 결제 로그에 주민번호 평문, 로그 암호화 미흡 A04 Cryptographic Failures, A09 Security Logging and Alerting Failures 로그 최소화와 마스킹 교재의 JWT Payload 원칙

답변은 세 문장으로 구성합니다. 첫째, 공식 조사에서 확인된 원인 하나. 둘째, 그 원인이 내 서버의 어느 지점에 해당하는지. 셋째, 내가 실제로 해 본 대응. 예를 들면 이렇습니다.

"SK텔레콤 조사 결과에서 인증키를 암호화하지 않고 저장한 점이 지적됐습니다. 제 프로젝트에서는 외부 API 키를 Git 제외 파일과 환경 변수에만 두었고, 회원 연락처는 암호화하되 키는 데이터베이스와 분리된 비밀값 저장소에 두었습니다."

교훈: 세 번째 문장이 없으면 뉴스 감상이고, 있으면 경험입니다. 그 경험은 작은 개인 프로젝트로도 만들 수 있습니다.

💡 원스의 인사이트: 큰 사고의 원인은 대개 기본기의 빈틈입니다

세 사고의 공식 조사 결과를 나란히 놓고 보면, 새로운 공격 기법보다 키의 수명 관리, 평문 저장, 로그에 남긴 것 같은 기본 항목이 반복됩니다. 신입 개발자가 혼자 운영하는 작은 프로젝트에서도 똑같이 점검할 수 있는 것들입니다.

그래서 면접 준비로 보안 뉴스를 읽을 때는 "무슨 일이 있었나"에서 멈추지 말고, 자기 저장소를 열어 같은 자리를 확인해 보길 권합니다. application.yml에 키가 있는지, 로그에 이메일이 찍히는지, 토큰을 무기한으로 발급하는지. 그 확인과 수정 기록이 면접에서 가장 설득력 있는 답이 됩니다.

체크리스트 — 보안 뉴스를 면접 준비로 바꿀 때

  • [ ] 사고 원인을 공식 발표와 언론 추정으로 나눠 적었다
  • [ ] 원인마다 "내 서버의 어느 지점인가"를 한 문장으로 썼다
  • [ ] 내 프로젝트에서 비밀값이 코드·설정 파일·화면 빌드에 들어 있지 않은지 확인했다
  • [ ] 토큰 서명키의 보관·교체·폐기 방법을 설명할 수 있다
  • [ ] 로그에 개인정보와 비밀값이 남지 않는지 확인했다

참고 자료 및 출처