Notepad++ 해킹 사태 — 프로그램이 아니라 ‘업데이트’가 공격당했다

“Notepad++가 해킹됐다” — 개발자 커뮤니티를 흔든 뉴스

2026년 초, 보안 커뮤니티와 개발자 커뮤니티를 동시에 흔든 뉴스 하나가 빠르게 퍼지기 시작했다. 제목은 단순했다. “Notepad++가 해킹됐다.” 이 한 문장은 생각보다 많은 사람들에게 충격적으로 들렸다. Notepad++는 단순한 텍스트 에디터 이상의 의미를 가지는 프로그램이기 때문이다. 수십 년 동안 Windows 환경에서 가장 널리 사용된 개발자 도구 중 하나였고, 가볍고 빠르면서도 다양한 언어를 지원하는 편집기로 많은 개발자들의 기본 도구처럼 자리 잡아 왔다. IDE를 사용하지 않는 상황에서도 로그 파일을 확인하거나 설정 파일을 수정할 때 자연스럽게 실행되는 프로그램이 바로 Notepad++였다. 그래서 이 뉴스는 단순히 한 프로그램의 보안 사고가 아니라, 개발자 생태계 전체에 영향을 줄 수 있는 사건처럼 느껴졌다.

많은 사람들은 처음 이 소식을 접했을 때 자연스럽게 몇 가지 가정을 떠올렸다. 혹시 GitHub 저장소가 침해된 것일까. 개발자의 계정이 탈취되어 악성 코드가 소스 코드에 삽입된 것일까. 아니면 빌드 과정 자체가 공격당해 배포되는 프로그램에 백도어가 들어간 것일까. 최근 몇 년 동안 실제로 이런 사건들이 반복적으로 발생해 왔기 때문에 이런 추측은 충분히 현실적인 것이었다. 특히 SolarWinds 사건 이후로 소프트웨어 공급망 공격은 더 이상 이론적인 위험이 아니라 실제로 산업 전체를 흔들 수 있는 공격 방식으로 인식되기 시작했다. 그렇기 때문에 많은 개발자들은 이 사건 역시 비슷한 유형의 대규모 공급망 침해일 것이라고 예상했다.

하지만 사건을 조금 더 자세히 들여다보면 흥미로운 사실이 드러난다. 실제로 공격이 발생한 지점은 사람들이 처음 예상했던 곳과 전혀 달랐다. 소스 코드도, 개발자 계정도, 빌드 시스템도 공격당하지 않았다. 그럼에도 불구하고 공격자는 실제 사용자 환경에 악성 코드를 전달하는 데 성공했다. 즉 공격은 분명히 존재했지만, 공격 지점은 우리가 일반적으로 생각하는 소프트웨어 보안의 영역과는 조금 다른 곳에 있었다. 바로 그 지점이 이 사건을 흥미롭게 만든다.

이 사건의 핵심은 프로그램이 아니라 배포 과정, 더 정확히 말하면 업데이트 시스템이었다. 우리가 매일 아무 생각 없이 사용하는 자동 업데이트 기능이 바로 공격의 통로가 되었던 것이다. 이 사실을 이해하기 시작하면 자연스럽게 다음 질문이 등장한다. 소프트웨어 자체는 공격당하지 않았는데, 어떻게 공격자가 사용자 컴퓨터에 악성 코드를 전달할 수 있었을까. 이 질문에 대한 답을 이해하기 위해서는 먼저 이 사건에서 사람들이 가장 크게 오해했던 부분을 바로잡을 필요가 있다.

사건의 핵심 — Notepad++는 해킹되지 않았다

이 사건을 이해하기 위해 가장 먼저 짚고 넘어가야 할 사실이 하나 있다. 많은 사람들이 처음에 생각했던 것과 달리 Notepad++ 프로그램 자체는 해킹되지 않았다. 이것은 단순한 표현상의 차이가 아니라 사건의 본질을 이해하는 데 매우 중요한 지점이다. 보통 우리가 “프로그램이 해킹되었다”고 말할 때는 몇 가지 특정한 상황을 떠올리게 된다. 소스 코드가 침해되었거나, 개발자의 계정이 탈취되어 악성 코드가 저장소에 삽입되었거나, 빌드 시스템이 조작되어 배포되는 프로그램 자체가 변조되는 경우다. 실제로 과거의 많은 공급망 공격이 이런 방식으로 이루어졌다.

하지만 Notepad++ 사건에서는 이런 일이 발생하지 않았다. 프로젝트의 소스 코드는 침해되지 않았고, GitHub 저장소 역시 공격당하지 않았다. 개발자의 계정이 탈취된 것도 아니었으며, 프로그램의 공식 빌드 과정이 조작된 것도 아니었다. 다시 말해 프로그램 자체의 개발 과정에는 아무런 문제가 발생하지 않았다. 그럼에도 불구하고 일부 사용자들은 악성 코드가 포함된 프로그램을 다운로드하게 되었고, 실제로 공격이 성공했다. 이 사실은 사건의 핵심이 프로그램 자체가 아니라 소프트웨어가 사용자에게 전달되는 과정에 있었다는 것을 의미한다.

현대 소프트웨어 보안에서 이런 공격 방식은 Supply Chain Attack, 즉 공급망 공격이라고 불린다. 이 공격 방식의 핵심은 프로그램을 직접 공격하는 것이 아니라 프로그램이 사용자에게 전달되는 경로를 공격하는 것이다. 공격자는 소프트웨어의 개발 과정이 아니라 배포 과정에 개입함으로써 사용자에게 악성 코드를 전달한다. 이 방식이 위험한 이유는 사용자가 이미 신뢰하고 있는 경로를 이용한다는 점에 있다. 사용자는 프로그램 제작자를 신뢰하고, 그 제작자가 제공하는 업데이트나 다운로드를 의심 없이 실행한다. 공격자는 바로 이 신뢰 구조를 이용한다.

이 사건에서도 정확히 같은 일이 발생했다. 공격자는 Notepad++ 프로그램을 만들거나 수정할 필요가 없었다. 대신 프로그램이 사용자에게 전달되는 과정 중 하나를 장악함으로써 사용자에게 악성 코드를 전달할 수 있었다. 이 사실을 이해하면 사건의 구조가 조금씩 명확해지기 시작한다. 그리고 동시에 또 하나의 질문이 등장한다. 프로그램 자체가 아니라 배포 과정이 공격당했다면, 도대체 그 과정의 어디가 공격 지점이 되었을까.

그 질문의 답은 우리가 평소에 가장 아무 생각 없이 사용하는 기능 중 하나에서 발견된다. 바로 소프트웨어 업데이트다.

우리가 너무 쉽게 신뢰하는 기능 — 소프트웨어 업데이트

현대 소프트웨어 환경에서 자동 업데이트는 너무나 당연한 기능이 되었다. 프로그램을 실행하면 새로운 버전이 있는지 확인하고, 업데이트가 존재하면 사용자에게 설치 여부를 묻는다. 대부분의 사용자는 이 과정에서 큰 고민을 하지 않는다. 오히려 업데이트를 하지 않는 것이 더 위험하다고 생각하는 경우가 많다. 보안 취약점이 발견될 때마다 “최신 버전으로 업데이트하라”는 권고가 반복되기 때문에, 업데이트는 보안의 일부처럼 인식되어 왔다. 그래서 업데이트 버튼을 누르는 행동은 거의 자동화된 습관처럼 이루어진다.

하지만 조금만 시각을 바꾸어 보면 업데이트 시스템이 얼마나 강력한 기능인지 깨닫게 된다. 소프트웨어 업데이트는 프로그램 제작자가 사용자 컴퓨터에 새로운 코드를 전달할 수 있는 공식적인 경로다. 즉 업데이트 시스템은 프로그램 제작자에게 사용자 컴퓨터에서 실행될 코드를 전달할 수 있는 권한을 부여한다. 만약 이 경로가 공격자에게 장악된다면 상황은 완전히 달라진다. 공격자는 사용자에게 악성 코드를 전달하면서도 그것을 정상적인 업데이트처럼 보이게 만들 수 있다. 사용자는 자신이 공격당하고 있다는 사실을 전혀 인식하지 못한 채 공격자가 만든 프로그램을 실행하게 된다.

업데이트 시스템의 기본 구조는 생각보다 단순하다. 프로그램 내부에는 보통 작은 업데이터 모듈이 포함되어 있으며, 이 모듈은 정기적으로 업데이트 서버에 연결하여 새로운 버전이 존재하는지 확인한다. 새로운 버전이 발견되면 프로그램은 업데이트 파일을 다운로드하고 설치를 진행한다. 사용자가 보는 화면은 단순한 알림 창 하나지만, 그 뒤에서는 서버와의 통신, 파일 다운로드, 검증 과정, 설치 과정이 연속적으로 이루어진다. 이 과정은 사용자에게 거의 보이지 않기 때문에 대부분의 사람들은 그 내부 구조를 생각해 볼 기회조차 없다.

문제는 바로 이 지점에 있다. 업데이트 시스템은 프로그램의 정상적인 기능이기 때문에 사용자는 이를 의심하지 않는다. 공격자가 이메일이나 웹사이트를 통해 악성 파일을 배포하면 사용자는 경계심을 가지지만, 프로그램의 공식 업데이트 기능을 통해 전달되는 파일은 거의 무조건 신뢰하게 된다. 이 신뢰 구조는 소프트웨어 생태계를 유지하는 데 필수적인 요소이지만 동시에 매우 강력한 공격 표면이 되기도 한다. 그래서 최근 몇 년 동안 많은 공격자들이 프로그램 자체가 아니라 업데이트 인프라를 공격 대상으로 삼기 시작했다.

Notepad++ 사건 역시 바로 이 지점을 노린 공격이었다. 공격자는 프로그램을 수정할 필요도 없었고, 개발자를 공격할 필요도 없었다. 대신 사용자에게 업데이트를 전달하는 시스템을 장악함으로써 동일한 결과를 얻을 수 있었다. 이 사실을 이해하는 순간 사건의 구조가 조금 더 분명해진다. 이제 남은 질문은 하나다. Notepad++의 업데이트 시스템은 정확히 어떤 구조를 가지고 있었고, 공격자는 그 구조의 어디를 공격했을까. 이 질문에 답하기 위해서는 먼저 Notepad++의 업데이트 메커니즘 자체를 조금 더 자세히 살펴볼 필요가 있다.

Notepad++ 업데이트 시스템 구조

앞서 살펴본 것처럼 이번 사건을 이해하기 위해서는 Notepad++ 프로그램 자체가 아니라 업데이트 메커니즘을 먼저 이해할 필요가 있다. 많은 소프트웨어가 그렇듯이 Notepad++ 역시 내부에 자동 업데이트 기능을 포함하고 있으며, 사용자가 프로그램을 실행하면 새로운 버전이 존재하는지 확인하는 과정이 자동으로 이루어진다. 사용자가 보는 화면은 단순하다. 프로그램이 최신 버전인지 확인하고, 새로운 버전이 존재하면 업데이트 알림을 띄운다. 하지만 이 단순한 동작 뒤에는 생각보다 복잡한 구조가 존재한다. 바로 업데이트 확인 → 버전 정보 조회 → 다운로드 → 검증 → 설치라는 일련의 과정이다.

Notepad++는 이 과정을 위해 **WinGup(Windows GUP)**이라는 업데이터 모듈을 사용한다. WinGup은 프로그램 내부에서 동작하며 업데이트 서버와 통신하여 최신 버전 정보를 확인한다. 일반적인 흐름을 조금 더 자세히 살펴보면 다음과 같다. 프로그램이 실행되면 먼저 업데이트 서버에 연결하여 최신 버전 정보를 담고 있는 XML 또는 manifest 파일을 다운로드한다. 이 파일에는 현재 배포 중인 버전 번호, 다운로드 위치, 그리고 업데이트 파일의 해시 값 같은 정보가 포함되어 있다. 프로그램은 이 정보를 바탕으로 현재 설치된 버전과 서버의 버전을 비교하고, 만약 새로운 버전이 존재한다면 사용자가 업데이트를 진행할 수 있도록 안내한다.

이 과정에서 중요한 점은 프로그램이 실제 업데이트 파일을 바로 다운로드하는 것이 아니라 먼저 업데이트 정보를 담은 파일을 조회한다는 것이다. 즉 업데이트 시스템에는 최소 두 개의 중요한 요소가 존재한다. 하나는 업데이트 버전 정보를 제공하는 서버이고, 다른 하나는 실제 설치 파일이 저장된 다운로드 위치다. 프로그램은 이 두 요소를 차례로 참조하면서 업데이트를 수행한다. 따라서 만약 공격자가 이 과정 중 하나라도 조작할 수 있다면 사용자는 정상적인 업데이트 과정이라고 믿으면서도 공격자가 제공한 파일을 다운로드하게 된다.

Notepad++ 사건에서 바로 이 지점이 중요한 역할을 하게 된다. 프로그램 자체는 정상적으로 동작하고 있었고, 업데이트 기능 역시 설계된 대로 작동하고 있었다. 하지만 업데이트 정보를 제공하는 인프라가 공격자의 통제 아래 들어가면서 상황이 완전히 달라졌다. 사용자 입장에서는 여전히 동일한 업데이트 창을 보고 동일한 버튼을 누르지만, 그 버튼이 가리키는 다운로드 위치는 이미 공격자가 조작해 놓은 상태였던 것이다. 결국 이번 사건은 프로그램 코드가 아니라 업데이트 인프라 구조 자체가 공격 표면이 되었던 사례라고 볼 수 있다. 이 구조를 이해하면 다음 단계에서 등장하는 공격 방식이 왜 가능했는지 자연스럽게 설명된다.

공격이 발생한 지점 — 업데이트 서버 인프라

Notepad++ 사건에서 공격자가 노린 것은 프로그램 내부 코드가 아니라 업데이트 인프라 자체였다. 프로그램의 자동 업데이트 기능은 정상적으로 동작하고 있었지만, 그 기능이 의존하고 있는 서버 환경이 공격자의 통제 아래 들어가면서 전체 시스템의 신뢰 구조가 무너졌다. 이 사건에서 중요한 역할을 한 요소는 바로 shared hosting 환경이었다. 많은 오픈소스 프로젝트가 비용 절감과 관리 편의성을 위해 shared hosting 서비스를 사용한다. 이 환경에서는 하나의 물리적 서버 위에 여러 웹사이트와 프로젝트가 함께 존재하게 된다.

shared hosting 구조 자체가 항상 위험한 것은 아니지만, 보안 관점에서는 완벽한 격리가 이루어지지 않는 경우가 존재한다. 특히 서버 접근 권한을 확보한 공격자가 파일 시스템에 접근할 수 있는 상황이라면 여러 프로젝트의 파일을 동시에 조작할 수 있는 가능성이 생긴다. Notepad++ 사건에서도 바로 이런 구조가 공격 지점이 되었다. 공격자는 서버 접근 권한을 확보한 뒤 업데이트 관련 파일들을 조작할 수 있는 위치에 도달했다. 그 결과 업데이트 버전 정보 파일이나 다운로드 위치 같은 요소들이 공격자의 통제 아래 들어가게 되었다.

이 상황에서 공격자는 매우 간단하면서도 효과적인 공격을 수행할 수 있다. 업데이트 정보 파일을 수정하여 다운로드 경로를 변경하거나, 기존 업데이트 파일을 공격자가 준비한 악성 파일로 교체하면 된다. 프로그램은 여전히 정상적인 업데이트 절차를 따르고 있기 때문에 사용자는 어떤 의심도 하지 않는다. 사용자가 업데이트 버튼을 누르면 프로그램은 서버에서 제공하는 정보를 기반으로 파일을 다운로드하고 설치를 진행한다. 하지만 실제로 다운로드되는 파일은 이미 공격자가 바꿔놓은 악성 프로그램일 수 있다.

이 공격 방식이 특히 위험한 이유는 사용자 신뢰 구조를 그대로 이용한다는 점이다. 사용자는 이메일 첨부파일이나 의심스러운 웹사이트에서 다운로드한 프로그램을 실행할 때는 경계심을 가지지만, 자신이 사용하는 프로그램의 공식 업데이트 기능은 거의 무조건 신뢰한다. 공격자는 바로 이 심리적 신뢰를 공격 경로로 이용했다. 결국 Notepad++ 사건은 프로그램 보안 자체가 아니라 소프트웨어 배포 인프라의 보안이 얼마나 중요한지를 보여주는 대표적인 사례가 되었다. 그리고 이 지점에서 자연스럽게 또 하나의 의문이 등장한다. 만약 업데이트 파일이 변조되었다면, 프로그램은 왜 그것을 검증하지 못했을까.

왜 검증 시스템이 공격을 막지 못했을까

소프트웨어 업데이트 과정에는 일반적으로 파일 검증 과정이 포함된다. 프로그램은 다운로드한 파일이 정상적인 제작자가 배포한 파일인지 확인하기 위해 다양한 검증 절차를 수행한다. 가장 널리 사용되는 방법은 디지털 서명 검증이다. 제작자는 프로그램에 자신의 인증서를 이용해 서명을 하고, 사용자의 컴퓨터는 이 서명을 확인함으로써 파일이 실제 제작자가 만든 것인지 검증한다. 이 방식이 제대로 구현되어 있다면 공격자가 파일을 조작하더라도 검증 단계에서 차단된다.

하지만 Notepad++의 업데이트 시스템은 조금 다른 접근 방식을 사용하고 있었다. WinGup 업데이터는 기본적으로 checksum 기반 검증을 사용했다. checksum은 파일의 무결성을 확인하기 위한 방법으로, 파일의 내용을 해시 함수로 계산한 뒤 그 값을 비교하는 방식이다. 다운로드한 파일의 해시값이 서버가 제공한 값과 동일하다면 파일이 변조되지 않았다고 판단한다. 이 방식은 파일 전송 오류를 감지하거나 저장 과정에서의 데이터 손상을 확인하는 데 매우 유용하다.

문제는 이 방식이 보안 검증으로는 충분하지 않다는 점이다. checksum 검증은 파일이 전송 과정에서 손상되지 않았는지를 확인할 뿐, 파일이 신뢰할 수 있는 제작자가 만든 것인지까지는 보장하지 않는다. 특히 서버가 공격자에게 장악된 상황이라면 문제는 더욱 심각해진다. 공격자는 악성 파일을 업로드한 뒤 그 파일의 checksum 값 역시 함께 변경할 수 있기 때문이다. 프로그램은 다운로드한 파일의 해시 값을 계산하고 서버에서 제공한 값과 비교한다. 그리고 두 값이 일치한다는 이유만으로 파일을 정상적인 업데이트라고 판단하게 된다.

이 구조에서는 공격자가 서버를 장악하는 순간 검증 시스템 자체가 무력화된다. 프로그램은 검증 절차를 수행하고 있다고 생각하지만, 실제로는 공격자가 제공한 값과 공격자가 제공한 파일을 비교하고 있을 뿐이다. 이 점에서 checksum 검증은 무결성 확인에는 유용하지만 신뢰성 검증에는 충분하지 않다. 그래서 현대 소프트웨어 배포 시스템에서는 checksum 대신 디지털 서명이나 코드 서명 같은 방식이 점점 더 중요해지고 있다.

Notepad++ 사건은 바로 이 차이를 명확하게 보여준다. 검증 시스템이 존재했음에도 불구하고 공격이 성공할 수 있었던 이유는 그 검증 방식이 공격자가 통제할 수 있는 환경에 의존하고 있었기 때문이다. 결국 이 사건은 소프트웨어 보안에서 중요한 교훈 하나를 남긴다. 보안 검증은 단순히 존재하는 것만으로 충분하지 않다. 검증의 기준이 공격자의 통제 밖에 있어야만 의미가 있다. 그리고 이 지점에서 우리는 또 다른 질문을 마주하게 된다. 공격자는 왜 이런 복잡한 방법을 사용했을까. 그리고 왜 하필 Notepad++ 같은 개발자 도구가 공격 대상이 되었을까. 이 질문에 대한 답은 다음 섹션에서 조금 더 넓은 관점에서 살펴볼 수 있다.

이 공격은 왜 무차별 공격이 아니었을까

지금까지 살펴본 내용을 바탕으로 보면 Notepad++ 사건은 기술적으로 상당히 흥미로운 특징을 가지고 있다. 공격자는 업데이트 인프라를 장악했고, 이론적으로는 수많은 사용자에게 악성 코드를 배포할 수 있는 위치에 있었다. 하지만 실제 공격 패턴을 분석해 보면 이 사건은 우리가 흔히 떠올리는 대규모 악성코드 캠페인과는 조금 다른 모습을 보인다. 공격은 모든 사용자에게 동시에 발생하지 않았고, 특정 사용자 환경에서만 나타나는 특징을 보였다. 즉 공격자는 단순히 가능한 많은 컴퓨터를 감염시키려는 전략을 사용하지 않았다. 대신 선별적인 공격, 다시 말해 특정 대상에게만 악성 업데이트가 전달되는 방식이 관찰되었다.

이러한 패턴은 보안 연구자들에게 익숙한 유형의 공격을 떠올리게 한다. 바로 APT(Advanced Persistent Threat) 공격이다. APT 공격은 일반적인 사이버 범죄와 달리 금전적인 이익을 목적으로 하지 않는 경우가 많다. 대신 특정 조직이나 기업, 혹은 정부 기관을 대상으로 장기간에 걸쳐 정보를 수집하는 것이 주요 목표가 된다. 그래서 공격자는 가능한 한 조용하게, 그리고 눈에 띄지 않게 침투하는 방식을 선택한다. 만약 모든 사용자에게 악성 코드가 배포된다면 보안 업체와 연구자들의 관심이 집중되고 공격이 빠르게 발견될 가능성이 높아진다. 반대로 특정 대상에게만 공격을 수행한다면 공격자는 훨씬 더 오랜 시간 동안 시스템 내부에 머물 수 있다.

Notepad++ 사건에서 발견된 악성 코드 역시 단순한 트로이 목마 형태의 프로그램이 아니었다. 보안 분석 과정에서 발견된 백도어는 Chrysalis라는 이름으로 알려져 있으며, 일반적인 악성 프로그램보다 훨씬 더 정교한 기능을 가지고 있었다. 이 백도어는 감염된 시스템에서 원격 명령을 실행할 수 있었고, 시스템 정보를 수집하여 외부 서버로 전송하는 기능도 포함하고 있었다. 또한 추가적인 악성 코드를 다운로드하거나 내부 네트워크로 이동할 수 있는 기능도 갖추고 있었다. 이러한 기능은 보통 대규모 랜섬웨어 공격보다는 정보 수집을 목표로 하는 공격에서 더 자주 발견된다.

이 점은 사건의 성격을 이해하는 데 중요한 단서를 제공한다. 만약 공격의 목적이 단순한 금전적 이익이었다면 공격자는 가능한 많은 시스템을 감염시키려고 했을 것이다. 하지만 실제 공격 패턴은 그와 달랐다. 공격은 조용하게 진행되었고, 특정 환경에서만 발견되었다. 이 사실은 Notepad++ 사건이 단순한 악성 코드 배포 사건이 아니라 정밀한 목표를 가진 공격이었을 가능성을 보여준다. 그리고 이 지점에서 자연스럽게 또 하나의 질문이 등장한다. 공격자가 굳이 이런 복잡한 방법을 사용하면서까지 노렸던 대상은 무엇이었을까. 그리고 왜 하필 Notepad++ 같은 개발자 도구가 공격의 경로로 선택된 것일까.

왜 개발자 도구가 공격 대상이 되는가

Notepad++ 사건을 조금 더 넓은 관점에서 바라보면 이 공격이 왜 흥미로운지 더 분명해진다. 표면적으로 보면 공격 대상은 단순한 텍스트 에디터다. 일반 사용자 입장에서는 특별히 중요한 프로그램처럼 보이지 않을 수도 있다. 하지만 개발자 관점에서 생각해 보면 이야기가 완전히 달라진다. 개발자에게 텍스트 에디터나 IDE는 단순한 도구가 아니라 소프트웨어 생산 과정의 중심에 있는 환경이기 때문이다. 코드가 작성되고 수정되는 장소가 바로 개발 도구이며, 대부분의 프로젝트는 이러한 환경에서 시작된다.

만약 공격자가 개발자 도구를 장악할 수 있다면 그 영향력은 생각보다 훨씬 넓어질 수 있다. 개발자가 사용하는 프로그램이 감염되면 그 개발자가 작성하는 코드 역시 영향을 받을 가능성이 생긴다. 예를 들어 공격자가 개발 환경에서 특정 파일을 조작하거나 빌드 과정에 악성 코드를 삽입할 수 있다면, 그 결과로 만들어지는 소프트웨어 역시 공격자의 영향을 받게 된다. 이 경우 공격자는 단순히 한 대의 컴퓨터를 감염시키는 것이 아니라 수많은 사용자에게 배포되는 소프트웨어 자체에 영향을 미칠 수 있다.

이러한 이유 때문에 최근 몇 년 동안 여러 보안 사건에서 개발 도구가 공격 대상이 되는 사례가 반복적으로 등장했다. 대표적인 사례로는 SolarWinds 사건이 있다. SolarWinds 사건에서는 네트워크 관리 소프트웨어의 업데이트 시스템이 공격당했고, 그 결과 수많은 기업과 정부 기관의 시스템이 영향을 받았다. 또 다른 사례로는 XcodeGhost 사건이 있다. 이 사건에서는 Apple의 개발 도구인 Xcode의 변조된 버전이 배포되었고, 이를 사용해 앱을 개발한 개발자들이 의도하지 않게 악성 코드가 포함된 앱을 배포하게 되었다.

이러한 사건들을 보면 하나의 공통된 패턴을 발견할 수 있다. 공격자는 일반 사용자를 직접 공격하기보다는 소프트웨어를 만드는 사람들을 먼저 공격한다. 개발자의 환경을 장악하면 그 개발자가 만드는 소프트웨어 역시 공격 경로가 될 수 있기 때문이다. Notepad++ 사건 역시 같은 맥락에서 이해할 수 있다. Notepad++는 단순한 텍스트 에디터처럼 보이지만 실제로는 수많은 개발자들이 사용하는 도구이며, 그만큼 영향력도 크다. 공격자가 이 도구의 업데이트 체인을 장악할 수 있다면 특정 개발자의 환경에 침투하는 것도 가능해진다.

이 점에서 Notepad++ 사건은 단순한 보안 사고 이상의 의미를 가진다. 이 사건은 개발 도구 자체가 공격 표면이 될 수 있다는 사실을 다시 한 번 보여준다. 그리고 이러한 흐름은 앞으로도 계속될 가능성이 높다. 소프트웨어가 점점 더 복잡한 공급망 위에서 만들어지고 배포되는 환경에서는 개발자 도구 역시 중요한 공격 경로가 될 수 있기 때문이다.

이 사건이 보여준 현대 소프트웨어 보안의 현실

Notepad++ 사건은 단순히 하나의 프로젝트에서 발생한 보안 사고로 끝나지 않는다. 오히려 이 사건은 현대 소프트웨어 생태계가 얼마나 복잡한 신뢰 구조 위에 존재하는지를 보여주는 사례라고 할 수 있다. 오늘날 대부분의 소프트웨어는 다양한 외부 구성 요소와 연결되어 있다. 소스 코드는 GitHub 같은 저장소에서 관리되고, 빌드는 자동화 시스템에서 이루어지며, 배포는 CDN이나 업데이트 서버를 통해 이루어진다. 그리고 사용자는 이러한 과정을 거의 의식하지 않은 채 프로그램을 다운로드하고 실행한다. 이 모든 과정은 신뢰를 기반으로 작동한다.

하지만 공급망 공격이 등장하면서 이 신뢰 구조는 점점 더 취약한 지점이 드러나고 있다. 공격자는 더 이상 프로그램 자체를 직접 공격할 필요가 없다. 대신 프로그램이 사용자에게 전달되는 경로 중 하나를 장악하면 동일한 결과를 얻을 수 있다. 특히 업데이트 시스템은 공격자에게 매우 매력적인 목표가 된다. 사용자는 업데이트 기능을 의심하지 않으며, 프로그램은 업데이트 서버에서 제공하는 파일을 자동으로 다운로드하기 때문이다. 이런 구조에서는 단 하나의 서버가 침해되는 것만으로도 수많은 사용자에게 영향을 미칠 수 있다.

또 하나 중요한 점은 오픈소스 프로젝트라고 해서 반드시 더 안전한 것은 아니라는 사실이다. 많은 사람들은 오픈소스 소프트웨어가 공개되어 있기 때문에 보안 측면에서도 더 안전할 것이라고 생각한다. 실제로 소스 코드의 투명성은 보안 측면에서 분명한 장점을 제공한다. 하지만 이번 사건에서 공격자는 소스 코드를 건드릴 필요조차 없었다. 대신 소프트웨어가 배포되는 인프라를 공격함으로써 동일한 효과를 얻었다. 이 사실은 소프트웨어 보안을 단순히 코드의 문제로만 볼 수 없다는 점을 보여준다.

Notepad++ 사건은 결국 하나의 중요한 교훈을 남긴다. 현대 소프트웨어의 보안은 프로그램 내부 코드만으로 결정되지 않는다. 오히려 코드가 사용자에게 전달되는 공급망 전체의 보안이 더 중요한 요소가 될 수 있다. 그리고 이 지점에서 우리는 다시 처음 질문으로 돌아오게 된다. 공격자는 왜 이런 복잡한 공격을 선택했을까. 그 답은 개발자 도구가 단순한 프로그램이 아니라 소프트웨어 생산 생태계의 핵심에 위치해 있기 때문이다. 그리고 바로 이 이유 때문에 개발자 도구는 앞으로도 계속 공격자의 관심을 끌 가능성이 높다.

결론 — 프로그램이 아니라 공급망이 공격당했다

지금까지 살펴본 Notepad++ 사건을 처음부터 다시 떠올려 보면 한 가지 흥미로운 사실이 드러난다. 사건이 처음 알려졌을 때 많은 사람들은 자연스럽게 프로그램 자체가 해킹되었을 것이라고 생각했다. 소스 코드가 변조되었거나, 개발자의 계정이 탈취되었거나, 혹은 빌드 시스템이 공격당했을 것이라는 추측이 이어졌다. 이런 반응은 결코 이상한 것이 아니다. 과거의 많은 보안 사건들이 실제로 이런 방식으로 발생했기 때문이다. 하지만 이번 사건의 구조를 하나씩 살펴보면, 우리가 흔히 떠올리는 “프로그램 해킹”이라는 개념과는 조금 다른 모습이 나타난다. 공격자는 프로그램 자체를 수정할 필요도 없었고, 개발자 환경을 침해할 필요도 없었다. 대신 프로그램이 사용자에게 전달되는 경로 자체를 장악하는 방식을 선택했다.

이 점에서 Notepad++ 사건은 현대 소프트웨어 보안 환경이 어떻게 변화하고 있는지를 잘 보여준다. 오늘날 대부분의 소프트웨어는 단순히 하나의 프로그램이 아니라 복잡한 공급망 위에서 만들어지고 배포된다. 소스 코드는 저장소에서 관리되고, 빌드는 자동화된 시스템에서 이루어지며, 최종적인 배포는 업데이트 서버와 다운로드 인프라를 통해 이루어진다. 사용자 입장에서 이 과정은 거의 보이지 않는다. 프로그램을 실행하고 업데이트 버튼을 누르면 새로운 버전이 설치되는 단순한 경험으로만 인식된다. 하지만 실제로는 그 뒤에서 수많은 시스템이 서로 연결되어 있으며, 각각의 지점은 잠재적인 공격 표면이 될 수 있다.

Notepad++ 사건은 바로 이 구조적인 문제를 드러낸 사례였다. 프로그램 자체는 안전했지만, 프로그램을 배포하는 인프라가 공격자의 통제 아래 들어가면서 결과적으로 사용자는 악성 코드를 다운로드하게 되었다. 이것은 단순한 기술적 문제라기보다 신뢰 구조의 문제에 가깝다. 사용자는 프로그램 제작자를 신뢰하고, 제작자가 제공하는 업데이트를 신뢰한다. 공격자는 바로 이 신뢰를 이용한다. 업데이트 시스템은 사용자에게 새로운 코드를 전달할 수 있는 가장 강력한 경로이기 때문에, 공격자가 이 경로를 장악하면 프로그램 자체를 수정하지 않고도 동일한 결과를 만들어낼 수 있다.

이 사건이 특히 중요한 이유는 그것이 단순한 예외적인 사건이 아니라는 점에 있다. 최근 몇 년 동안 등장한 여러 보안 사건을 살펴보면 비슷한 패턴이 반복되고 있다. SolarWinds 사건에서는 네트워크 관리 소프트웨어의 업데이트 과정이 공격당했고, 그 결과 수많은 기업과 정부 기관의 시스템이 영향을 받았다. XcodeGhost 사건에서는 Apple의 개발 도구가 변조된 형태로 배포되면서 개발자들이 의도하지 않게 악성 코드가 포함된 앱을 만들어 배포하게 되었다. 그리고 이번 Notepad++ 사건 역시 같은 흐름 속에서 이해할 수 있다. 프로그램 자체가 아니라 소프트웨어가 전달되는 공급망이 공격의 중심이 되고 있다는 것이다.

이 사실은 소프트웨어 보안을 바라보는 관점 자체를 바꾸어 놓는다. 과거에는 프로그램 내부의 취약점이나 코드의 보안 문제가 주요 관심 대상이었다. 물론 이러한 문제는 여전히 중요하다. 하지만 공급망 공격이 점점 더 현실적인 위협이 되면서 보안의 범위는 훨씬 넓어지고 있다. 이제는 코드뿐만 아니라 빌드 시스템, 업데이트 서버, 다운로드 인프라, 그리고 개발 도구까지 모두 보안의 대상이 된다. 소프트웨어는 더 이상 하나의 프로그램이 아니라 연결된 시스템의 집합이기 때문이다.

이 지점에서 다시 한 번 이 사건의 핵심을 정리할 수 있다. Notepad++ 사건은 단순히 “텍스트 에디터가 해킹된 사건”이 아니다. 오히려 그것은 현대 소프트웨어 생태계가 얼마나 복잡한 신뢰 구조 위에 존재하는지를 보여주는 사례다. 프로그램 자체는 안전했지만, 프로그램을 사용자에게 전달하는 경로가 공격당하면서 전체 시스템의 신뢰가 무너졌다. 이 사건이 남긴 가장 중요한 메시지는 바로 이것이다. 프로그램이 해킹된 것이 아니라, 공급망이 공격당했다.

그리고 이 지점에서 우리는 자연스럽게 다음 질문을 마주하게 된다. 왜 공격자는 이런 복잡한 방법을 선택했을까. 왜 하필 개발자들이 사용하는 도구를 공격 대상으로 삼았을까. 단순히 한 프로그램을 감염시키는 것보다 훨씬 더 큰 목표가 있었기 때문일까. 이러한 질문은 이번 사건을 넘어 현대 사이버 공격의 전략 자체를 이해하는 데 중요한 단서를 제공한다.

다음 글에서는 바로 이 질문을 중심으로 이야기를 이어가려고 한다. 공격자가 개발자 도구를 공격하면 어떤 일이 발생하는지, 그리고 왜 IDE와 에디터 같은 개발 환경이 점점 더 중요한 공격 목표가 되고 있는지를 살펴볼 것이다. 개발자 도구를 공격하면 세상을 공격할 수 있다는 말이 단순한 과장이 아닌 이유를 이해하기 위해서다.