Security

침해사고는 왜 매년 반복되지만, 대응은 늘 익숙하고 질문은 제자리에! Part1

Donghwi Shin, Jin Kwak

Published: 11:22, 23 Jan 2026 (Updated: 15:04, 10 Feb 2026)

Photo by Clint Patterson / Unsplash

💡

Editor Pick
- 사고는 반복되는데, 질문은 제자리에 머물고 있음
- 질문을 바꾸기 위해 시선을 바꿔야하 상황
- 9가지 질문을 선정하고 논해보고자 한다.

2025년, 대한민국의 사이버 공간은 조용하지 않았다. 연초부터 연말까지 이어진 침해사고들은 통신, 금융, 플랫폼, 유통, 교육, 게임 산업을 가리지 않았다. 한 해 동안 공개적으로 확인된 침해사고만 수십 건에 달했고, 그중 상당수는 수백만 명, 많게는 수천만 명 규모의 개인정보에 영향을 주었다. 사고 발생 시점과 외부 공개 시점 사이에 수개월 이상의 간극이 존재한 사례도 적지 않았다. 그 결과 개인정보 유출과 랜섬웨어 감염은 뉴스의 단골 소재가 되었다.

그러나 사고의 빈도와 규모에 비해, 사고를 해석하는 사회적 논의는 놀라울 만큼 익숙한 질문 위에 머물러 있다. “어떤 기업인가?”, “얼마나 유출됐는가?”, “암호화는 되어 있었느냐”라는 질문은 반복되지만, 왜 이 사고가 가능했는지, 무엇이 구조적으로 바뀌지 않았는지에 대한 질문은 상대적으로 적다. 2025년의 침해사고들을 되돌아보는 이유는 단순한 정리가 아니라, 그 질문의 방향을 다시 설정하기 위함이다.

본지는 다음 9개의 질문에 대한 의견을 2부로 나누어 작성했으며 각 질문에 대한 효과적인 방향성이 무엇인지 생각해보는 기회가 되었으면 한다. Part1에서는 9개 질문 중 5개에 대해 살펴본다.

인증은 있었지만, 사고는 왜 발생했나
이미 유출된 개인정보, 정말 ‘더 이상 문제없나’
개인정보를 ‘누가 어디로 가져갔는지’가 핵심일까
공격자의 행동 변화는 일어나고 있는가?
침해사고 후, 정보보호 공시 분석의 한계
“암호화되어 있으니 안전하다”라는 말의 한계
결과만 묻고, 원인은 묻지 않았다
“랜섬웨어에 감염되었다”라는 현상을 바라보는 적절한 시선
대기업 중심의 침해사고 발생으로 명명되는 상황은?

yellow and white star illustration — Photo by Brands&People / Unsplash

1.인증은 있었지만, 사고는 왜 발생했나

침해 사고가 발생할 때마다 언론 보도와 국회 질의에서 자주 등장하는 표현이 있다. 바로 “해당 기업은 ISMS 인증을 받았음에도 침해사고가 발생했다”는 문장이다. 이 문장은 곧바로 다음 질문으로 이어진다. “ISMS 인증을 받았는데 어떻게 사고가 날 수 있는가?”, 혹은 반대로 “ISMS 인증을 받지 않았기 때문에 사고가 난 것 아닌가?”라는 식이다. 이 과정에서 ISMS 인증은 어느새 사고의 원인을 설명하는 핵심 변수처럼 소비된다.

그러나 이와 같은 접근은 ISMS 인증의 성격을 지나치게 단순화한다. ISMS는 침해 사고의 발생 여부를 보장하는 ‘무사고 인증’이 아니라, 조직이 정보보호를 체계적으로 관리하고 있는지를 점검하는 관리체계 인증이다. 다시 말해 인증은 일정 시점에 정해진 기준을 충족했음을 의미할 뿐, 이후 모든 위협을 자동으로 차단해 주는 안전장치가 아니다. 그럼에도 사고가 발생하면 인증의 존재 여부가 곧바로 실효성 논쟁으로 이어지는 구조는, 인증이 수행해야 할 역할을 벗어난 기대를 전제하고 있다.

문제는 인증 자체보다는 인증을 대하는 태도에 있다. ISMS 인증을 하나의 ‘완결된 상태’로 인식하는 순간, 운영과 점검, 변화에 대한 대응은 뒷전으로 밀린다. 실제 침해 사고를 들여다보면, 관리 체계가 문서상으로는 존재했지만, 현실의 시스템 변화나 운영 환경을 충분히 반영하지 못한 경우가 적지 않다. 인증받은 시점 이후에 인프라가 확장되고, 외부 위탁 구조가 복잡해졌으며, 새로운 위협이 등장했음에도 관리 체계가 그 속도를 따라가지 못한 것이다.

이 때문에 ISMS 인증을 둘러싼 논의가 “인증받았느냐, 받지 않았느냐?” 혹은 “제도가 무용한 것 아니냐”라는 이분법으로 흐르는 것은 생산적이지 않다. 중요한 질문은 인증의 유무가 아니라, 인증 이후 그 관리 체계가 실제로 어떻게 운영되고 있었는가다. 인증이 형식적 절차로 남았는지, 아니면 조직 내부에서 지속적인 점검과 개선의 기준으로 작동했는지가 침해사고의 양상을 가른다.

결국 2025년의 침해사고들이 던지는 질문은 제도의 존폐가 아니다. ISMS 인증을 하나의 방패로 기대하는 인식에서 벗어나, 인증 이후의 운영과 실천을 어떻게 담보할 것인가를 묻는 방향으로 논의가 이동해야 한다. 인증은 출발점이지, 사고를 막아주는 종착점이 아니기 때문이다.

person using laptop computer holding card — Photo by rupixen / Unsplash

2.이미 유출된 개인정보, 정말 ‘더 이상 문제없나’

침해사고가 반복되면서 종종 들려오는 반응이 있다. “이미 유출된 개인정보인데, 또 나간다고 해서 무슨 차이가 있겠는가”라는 인식이다. 개인정보가 사실상 공공재처럼 취급되는 순간이다. 그러나 이러한 태도는 개인정보 유출의 위험을 지나치게 단순화한다. 유출된 정보는 그 자체로 끝나지 않고, 시간의 흐름 속에서 서로 결합하며 새로운 위협을 만들어낸다.

과거에 유출된 정보와 최근에 유출된 정보를 결합하면, 공격자는 훨씬 정교한 시나리오를 구성할 수 있다. 이름, 연락처, 주소와 같은 기본 정보에 최근 서비스 이용 내역이나 계정 정보가 더해질 경우, 피해자를 속이기에 충분한 신뢰성이 만들어진다. 개인정보에는 ‘흐름’과 ‘역사’가 존재하고, 이 누적된 맥락은 공격자에게 강력한 도구가 된다. 지속적인 유출은 단순한 반복이 아니라, 공격자의 성공 확률을 높이는 자산 축적에 가깝다.

특히 유출된 정보에 비밀번호가 포함되면 그 위험성은 더 커진다. 동일하거나 유사한 비밀번호를 여러 서비스에서 사용하는 현실을 고려하면, 한 번의 유출이 연쇄적인 계정 침해로 이어질 가능성은 충분하다. 더 나아가 유출된 비밀번호가 암호화되어 있다고 하더라도, 앞서 살펴본 것처럼 암호화된 데이터는 복호화 가능성을 전제로 존재한다. 지금 당장은 악용되지 않더라도, 시간이 흐르며 다른 정보와 결합될 여지는 계속 남는다.

그렇다고 해서 개인정보 유출 소식에 막연한 불안에 빠질 필요는 없다. 현실적으로 국내 환경에서는 단순히 개인정보를 보유하고 있다는 이유만으로 공격자가 피해자의 적극적인 행위 없이 직접적인 금전 피해를 주는 것은 쉽지 않다. 오히려 중요한 것은 불안을 키우는 것이 아니라, 통제 가능한 대응을 지속하는 것이다.

다양한 IT 서비스가 제공하는 다중 인증, 로그인 알림, 접근 제한 기능을 적극적으로 활용하고, 서비스별로 비밀번호를 다르게 설정하는 것만으로도 위험은 상당 부분 낮아진다. 또한 개인정보 유출 관련 소식을 계기로 인증 정보를 주기적으로 변경하는 습관은, 공격자가 기대하는 ‘과거 정보의 재활용’을 무력화하는 가장 현실적인 대응이다. 이미 유출된 개인정보를 두려워하기보다, 그 정보가 더 이상 쓸모없어지도록 만드는 것이 지금 우리가 선택할 수 있는 최선의 대응이다.

red and black heart illustration — Photo by Martin Sanchez / Unsplash

3.개인정보를 ‘누가 어디로 가져갔는지’가 핵심일까

개인정보 유출 사고가 발생하면 자연스럽게 따라붙는 질문이 있다. “누가 개인정보를 가져갔는가?”, “어디로 유출된 것인가?”라는 물음이다. 이 질문은 책임 소재를 가리고, 공격자를 특정하기 위해 중요해 보인다. 그러나 최근의 침해사고 현실을 놓고 보면, 이 질문이 항상 핵심에 해당하는 것은 아니다.

실제로 최근 침해사고 중 상당수는 공격자가 누구인지 명확히 밝혀지지 않은 채 마무리된다. 공격자는 흔적을 최소화하고, 다수의 경유지를 거치며, 해외 인프라를 활용해 자신을 숨긴다. 그 결과 “누가 가져갔는지”를 밝히기 위한 분석은 장기간 이어지지만, 끝내 명확한 결론에 도달하지 못하는 경우도 적지 않다. 공격자 식별을 시도하는 노력 자체는 중요하지만, 그것이 사고 대응의 중심이 되어야 하는지는 다시 생각해 볼 필요가 있다.

오히려 더 시급한 과제는 유출된 개인정보가 어떤 위험을 만들어낼 수 있는지를 판단하고, 이에 대응하는 것이다. 공격자가 누구인지 알지 못하더라도, 유출된 정보의 종류와 범위를 파악하면 피해 시나리오는 예측할 수 있다. 특히 유출된 개인정보가 이미 다른 침해사고에서 유출된 정보와 결합될 경우, 어떤 형태의 사기나 계정 침해로 이어질 수 있는지를 선제적으로 분석하는 것이 훨씬 실질적인 대응이 된다.

즉, 초점은 ‘누가 가져갔는가’에서 ‘이 정보로 무엇을 할 수 있는가’로 이동해야 한다. 유출된 개인정보를 기준으로 가능한 공격 시나리오를 가정하고, 이를 차단하기 위한 인증 강화, 접근 제한, 이용자 안내와 같은 조치를 준비하는 것이 더 건설적이다.

a man wearing a mask — Photo by Kaptured by Kasia / Unsplash

4.공격자의 행동 변화는 일어나고 있는가?

한해가 끝나는 시점에 또는 새해가 시작하는 기간 동안 있었던 사고들을 모아 공격자 행동의 분석 결과를 내놓을 것이다. 어느 누군가가 어떤 결과를 내놓는다고 하더라도 사실 공격자의 사고는 큰 틀에서 변화가 없다고 보는 것이 적절하다. 공격자는 집요하며 집요하기 위해 충분한 시간을 보내며 한번 잡은 곳을 기반으로 최고의 이득을 취하려고 한다. 이 부분을 간과하지 않았으면 한다. 생각해 보면 공격자도 사람으로 아주 기초적인 경제 논리라 할 수 있는 최소한의 투자로 최대 이윤 창출을 목표로 한다. 생각해보자, 저기 어디 서버 하나의 권한을 탈취했다면 이제 판도라의 상자를 열 수 있는 시작점에 서 있는데 거기서 멈출 것인가? 서버가 갖고 있는 데이터와 서버의 위치를 기반으로 얻을 수 있는 최대한 많은 것들을 가져갈 것이다. 과거부터 지금까지 공격자는 계속 그래왔다.

다만 2025년 침해사고에서 공격자의 행동에서 드러났으며 아쉬운 부분은 큰 사고임에도 불구하고 오래된 취약점을 기반으로 공격이 시작된 점이다. 이 부분에서 공격자 행동에서 살펴볼 부분이 하나 있다고 생각한다. 공격자가 최신의 취약점을 활용하기도 하지만 오래전 취약점이라 하더라도 활용할 수 있는 옵션이라면 얼마든지 활용하며 무려 10여 년이 지난 취약점이라 하더라도 시도하는 것인 공격자이다. 그러므로 오래된 취약점 심지어 식별한 취약점이지만 패치가 쉽지 않아 그로 인한 위협을 수용했던 취약점까지도 살펴봐야 한다.

이 부분에서 ENKI가 작성한 “최악의 보안 해 2025년, 한국을 흔든 해킹과 우리가 바꿔야 할 것들”에서 다음과 같은 멘트를 주목할 필요가 있다.

보안 담당자는 보고서를 위해 체크리스트를 채우고, 경영진은 “의무사항은 다 했지?”라고 묻는 수준에서 안심합니다. 하지만 해커는 이런 문서를 읽지 않습니다. 패치가 한 번 밀린 서버, 테스트용으로 잠깐 열어뒀다가 잊힌 계정, 편의상 완화해놓은 인증 규칙 같은 현실의 빈틈을 끝까지 집요하게 찌릅니다.

즉, 공격자는 회사가 했던 보안 활동을 고려하지 않는다. 즉각적으로 취할 수 있는 행동을 취하는 것이 공격자이다. 그러므로 우리는 문제가 될 수 있으나 잘 보고 있으면 막을 수 있으므로 미루어 두었던 작은 문제점 하나라도 놓치지 않을 준비를 해야 한다.

Bilingual russian and ukrainian language chart — Photo by Eugene Chystiakov / Unsplash

5.침해사고 후, 정보보호 공시 분석의 한계

침해사고 발생 후, 기업을 평가하는 기준 중 하나로 정보보호 공시를 언급하곤 한다. 특히 KISA 정보보호 공시 자료를 바탕으로 “보안 예산이 늘었다”, “동종 업계 대비 투자 규모가 낮다”는 비교/분석이 이어진다. 이러한 접근은 일견 합리적으로 보인다. 숫자는 객관적이고, 공시는 공식 자료이기 때문이다. 그러나 정보보호 공시를 해석하는 방식 자체에 한계가 존재한다는 점을 이해해야 한다.

우선 정보보호 공시가 담고 있는 정보의 밀도를 살펴볼 필요가 있다. 대부분의 공시는 1~2장 분량의 표 형식으로 구성되어 있으며, 정보보호 예산, 인력 규모, 정보보호 활동이 나열되어 있다. 만약 정보보안 활동이 세부 항목별로 충분히 설명되어 있다면, 그 내용을 비교·분석하는 것이 가능할 것이다. 하지만 현실의 공시 자료만으로는 “왜 이 예산이 필요한지”, “어떤 위험을 줄이기 위한 투자인지”, “실제 운영에서 어떻게 작동하고 있는지”를 파악하기 어렵다. 결국 제한된 데이터를 담고 있는 표 안에서 절대적인 숫자의 크고 작음만을 근거로 평가를 내리게 된다.

이 방식의 문제는 극단적인 예를 떠올려 보면 쉽게 드러난다. 한 기업이 정보보호 공시에 방화벽 등 정보보호 시스템 도입에 1,000억 원을 지출했다’고 가정해 보자. 이 숫자만으로 해당 기업의 보안 수준이 높아졌다고 단정할 수 있을까. 고가의 보안 시스템을 도입했다고 해서 자동으로 보안성이 강화되지는 않는다. 보안은 장비의 문제가 아니라 운영과 관리의 문제이기 때문이다. 정책은 적절했는지, 설정은 환경에 맞게 조정되었는지, 로그는 실제로 분석되고 있는지와 같은 질문 없이는 투자 금액은 의미를 갖기 어렵다. 그러나 이러한 요소들은 현재의 정보보호 공시만으로는 판단할 수 없다.

결국 정보보호 공시를 통해 우리가 알 수 있는 것은 “얼마를 썼는가”에 가깝지, “어떻게 보안을 운영하고 있는가”는 아니다. 이로 인해 공시는 침해사고 이후의 평가 도구로 활용되기에는 구조적인 한계를 가진다. 더 세분화된 공시를 요구하는 목소리도 있지만, 이는 기업 입장에서 또 다른 행정 부담과 형식적인 문서 작성을 늘릴 가능성이 크다. 그러므로 어느 정도의 공시가 필요한지 논의할 문제라고 생각한다. 다만 현재 정보보호 공시의 숫자를 비교 대상으로 삼으면서 보안 수준을 설명할 수 없는 자료를 과도하게 해석하고 있는 것은 아닌지를 되묻게 한다.