
한컴 솔루션웨어. 국민 워드프로세서가 된 코드는 30년을 버텼고, 그 틈을 북한이 파고들었다.
김호광 싸이월드 전 대표 / 2026년 10월 10일
분류: TLP:CLEAR | 문서유형: 분석 칼럼 (Analytical Column) | 작성일: 2026-10-10 심각도: HIGH | 신뢰도: A2 | 관련 행위자: APT37 · 김수키(Kimsuky)
코드는 늙지 않는다. 코드를 이해하는 사람이 늙을 뿐이다. 한국의 '문서 인프라'가 된 국산 워드프로세서, 그리고 30년 묵은 코드가 남긴 숙제
— 마스터 버전 (2026년 10월 9일)
들어가며 - 이번 달, 공무원 메일에서 HWP가 막힌다
정부 계획대로라면 2026년 10월, 공무원이 국민과 주고받는 공직자통합메일에서 HWP 파일 첨부가 제한된다. 지방정부 온나라시스템은 이미 5월 18일부터 HWPX 의무화가 확대됐다. 정부가 내세운 명분은 'AI가 읽을 수 있는 문서'다. 그런데 이 전환에는 공식 보도자료에 거의 등장하지 않는 또 하나의 이유가 있다. HWP는 10년 넘게 북한 해킹의 가장 확실한 출입문이었다.
2025년 12월, 지니언스 시큐리티 센터는 북한 연계 해킹 조직 APT37의 '아르테미스 작전(Operation Artemis)'을 공개했다. 공격자는 대학 교수나 방송작가를 사칭해 여러 차례 대화를 나누며 신뢰를 쌓은 뒤, 사전 인터뷰 질문지나 행사 안내문으로 위장한 HWP 파일을 보냈다. 피해자가 문서를 열고 콘텐츠 실행을 허용한 다음 본문 속 '하이퍼링크'를 누르는 순간 감염이 시작됐다. 그 링크는 사실 링크처럼 꾸며진 OLE 개체였다.
미국의 북한 전문 매체 38노스는 2025년 10월 보고서에서, HWP가 한국의 부처·군·핵심 산업·학계 전반의 사실상 표준이라는 사실 자체가 한국과 한미동맹의 사이버 안보 약점이 되었다고 진단했다.
왜 하필 아래아 한글인가? 이 칼럼은 그 답을 역사, 문화, 기술이라는 세 겹으로 풀고, 마지막으로 아직 아무도 본격적으로 말하지 않는 문제, 곧 30년 된 C 코드와 그 코드를 이해하는 사람들의 고령화를 이야기하려 한다.
1. 한국어를 위해 태어난 워드프로세서
아래아 한글은 1988년 서울대 컴퓨터 연구 동아리 출신인 이찬진, 김형집, 우원식, 김택진 등이 개발을 시작해 1989년 1.0 버전으로 세상에 나왔다. 제품명의 'ᄒᆞᆫ글'은 아래아(ㆍ)를 살린 옛 표기다. 1990년 한글과컴퓨터가 설립되며 본격적으로 상용화됐다.
당시 해외 워드프로세서는 한글을 제대로 다루지 못했다. 한글 한 글자는 초성·중성·종성의 조합이고, 현대 한글 음절만 1만 1,172자에 이른다. 아래아 한글은 조합형 코드로 이 문제를 정면 돌파했고, 한글·한자 혼용, 세로쓰기, 한국식 문단과 자간 제어까지 구현하며 '국민 워드프로세서'가 됐다.
한국어는 조사와 어미가 발달한 교착어이고, 한자어와 고유어가 섞이며, 공문서와 학술 문서에는 한자 병기와 특수 기호가 빈번하다. 이 조판 요구에 가장 먼저, 가장 정확하게 답한 것이 아래아 한글이었다. 1990년대 중반 마이크로소프트 워드가 한국 시장을 두드렸지만 한국어 조판 품질과 사용자 습관이라는 벽을 넘지 못했다. 1998년 외환위기 당시 마이크로소프트의 투자 제안에 맞서 '한글 지키기 운동'이 벌어진 일은, 이 소프트웨어가 한국 사회에서 제품 이상의 상징이었음을 보여준다.
바로 그 상징성이 훗날 공격자에게 기회가 된다.
2. 표(表)의 나라, 그리고 '한국만 쓰는' 포맷이 된 이유
공문서 표 문화
한국 행정 문서의 특징은 표와 개조식이다. 기안문, 보고서, 계획서, 예산서, 한 장짜리 상황 보고까지 대부분 표로 항목을 나누고 "함", "임"으로 끝나는 개조식 문장을 채운다. 셀 병합, 테두리 굵기, 줄 간격, 글꼴과 장평까지 정해진 서식이 있고, 조금만 어긋나도 "다시 해 오라"는 말을 듣는 것이 공직 사회의 오랜 풍경이다.
아래아 한글은 이 표 편집에서 압도적이었다. 복잡한 표를 그리고 셀을 쪼개고 합치고, 표 안에서 계산까지 하는 기능은 공무원과 연구자의 업무 방식 그 자체가 됐다.
왜 한국만 HWP를 쓰는가? - 정치경제적 잠금
기능만으로는 설명이 부족하다. HWP의 지배력은 국민정서와 더불어 관공서 표준 문서를 비롯한 몇 겹의 잠금(lock-in)으로 유지돼 왔다.
- 시스템 잠금. 정부 업무관리시스템 온나라가 HWP를 기본 문서 형식으로 써 왔다. 공무원이 HWP를 쓰니 민간 협력업체·연구기관·학교도 HWP로 제출해야 했다.
- 서식 자산 잠금. 수십 년 동안 쌓인 공문 양식, 지원사업 신청서, 입찰 서식이 모두 HWP다. 포맷을 바꾸면 양식 수만 개를 다시 만들어야 한다.
- 조달과 산업 정책. 국산 소프트웨어 육성이라는 명분 아래 공공 조달에서 한컴오피스는 오랫동안 기본값이었다.
- 상징 잠금. '외산에 맞선 국산 소프트웨어'라는 서사는 전환 논의를 정서적으로 어렵게 만들었다.
공격자의 관점에서 이 구조는 결정적이다. 표적이 매일 열어보는 파일 형식, 열 때 아무도 의심하지 않는 파일 형식, 그리고 전 세계에서 사실상 한국만 쓰는 파일 형식. 이 세 조건이 겹치는 지점이 HWP다. 마이크로소프트 워드나 PDF는 전 세계 보안 업계가 함께 들여다보지만, HWP는 사실상 한국 보안 업계만 감시한다. 지켜보는 눈이 적은 곳에 공격이 몰릴 수 밖에 없다.
"G7 각국 정상 회담에 따른 BH의 정책 변화"
이 제목이 hwp 문서가 메일이나 카카오톡으로 왔다면 클릭 안할 관료들은 사실상 거의 없을 것이다.
3. 결함(Defect)의 특징 - 두 개의 공격 축
HWP를 노리는 공격은 성격이 전혀 다른 두 갈래로 나뉜다. 이 둘을 구분하지 않으면 처방도 엉뚱한 곳을 향한다.
첫째 - 메모리 결함, 문서를 '읽는' 순간 뚫린다
기존 HWP(5.0) 포맷은 마이크로소프트 복합 문서 구조(OLE Compound File) 위에 독자적인 바이너리 레코드를 압축해 쌓는 방식이다. 한컴이 포맷 명세를 공개하고는 있지만, 30년 넘는 하위 호환 요구 때문에 파서가 처리해야 할 예외와 분기가 매우 많다. 복잡한 바이너리 파서는 곧 넓은 공격 표면이 되고 있다.
공개 취약점을 보면 패턴이 뚜렷하다.
| 시기 | 식별자 | 유형 | 비고 |
|---|---|---|---|
| 2015 | CVE-2015-6585 | 타입 혼동 | FireEye가 북한 연계 공격의 제로데이로 확인, 한컴이 9월 7일 패치 |
| 2016~2020 | CVE-2017-8291 등 | 내장 고스트스크립트(EPS 처리) 취약점 | HWP 안의 EPS 그림을 처리하던 외부 C 라이브러리가 공격 통로가 됨 |
| 2022 | CVE-2022-33896 | 버퍼 언더플로우 | XML 기반 문서 파싱 과정의 메모리 결함 |
| 2026.02 공개 | CVE-2025-29867 | 타입 혼동(CWE-843) | Hancom Office 2018·2020·2022·2024 전 라인, CVSS 4.0 기준 8.5. 공개 시점 기준 실제 악용 보고는 없음 |
타입 혼동, 버퍼 오버플로·언더플로, 해제 후 사용(Use-After-Free)은 모두 C/C++ 같은 메모리 비안전 언어에서 전형적으로 발생하는 결함이다. 하나를 패치하면 같은 계열의 버그가 다른 곳에서 나온다. 개별 개발자의 실수가 아니라 언어와 아키텍처의 문제다. 고스트스크립트 사례는 이 문제가 한컴 자체 코드에만 있지 않다는 것도 보여준다. 문서 안에 그림 하나를 그리기 위해 끌어온 외부 C 라이브러리 역시 공격 지점이 될 수 있다.
둘째 - 정상 기능의 악용, 취약점 없이도 뚫린다
HWP는 문서 안에 OLE 개체를 넣을 수 있다. 원래는 표나 그림, 다른 프로그램의 데이터를 넣기 위한 기능이다. 아르테미스 작전에서 공격자는 이 OLE 개체를 평범한 하이퍼링크처럼 위장했다. 소프트웨어에 버그가 하나도 없어도, 사용자가 경고를 무시하고 클릭 한 번만 하면 감염이 성립한다. 압축 파일 안에 HWP 아이콘을 단 바로가기(LNK) 파일을 넣는 수법도 같은 계열이다.
이 축의 핵심은 기술이 아니라 신뢰다. 공격자는 교수, 기자, 방송작가, 연구기관 직원을 사칭하며 몇 주에 걸쳐 대화를 나눈 뒤에야 파일을 보낸다.
정리하면 두 공격의 축은 서로 다른 처방을 요구한다
| 축 A: 메모리 결함 | 축 B: 정상 기능 악용 | |
|---|---|---|
| 공격 시점 | 문서를 여는(파싱하는) 순간 | 사용자가 허용·클릭하는 순간 |
| 대표 사례 | CVE-2015-6585, EPS/고스트스크립트 | 아르테미스 작전, HWP+LNK |
| 패치로 막히는가 | 개별 버그는 막힘, 계열은 반복 | 막히지 않음 (기능 자체가 정상) |
| 근본 처방 | 메모리 안전 언어 전환, 샌드박스 | CDR·문서 검사, 사용자 행동 |
Rust로 다시 쓴 HWP도 사용자가 위장된 링크를 누르면 뚫린다. 반대로 아무리 교육을 잘해도 문서를 여는 것만으로 실행되는 제로데이는 막을 수 없다. 둘 중 하나만으로는 안 된다.
4. 북한의 HWP 표적 공격, 13년의 연대기
| 시기 | 주체 | 내용 | 공격 축 |
|---|---|---|---|
| 2013 | 김수키 | 카스퍼스키가 김수키 캠페인을 처음 공개. HWP 문서를 골라 훔치는 전용 모듈 포함. HWP는 침투 수단이기 전에 수집 목표였다 | 수집 |
| 2015 | 북한 연계 추정 | FireEye가 HWP 제로데이(CVE-2015-6585)와 백도어 'Hangman' 공개. 명령 서버가 다른 북한 의심 공격과 연결 | A |
| 2016~2020 | 북한 연계 다수 | 통일·안보 세미나 자료, 가상자산 관련 문서로 위장한 HWP에 악성 EPS를 심는 공격이 수년간 지속 | A |
| 2017 | APT37 | 외교·안보·통일 분야 인사 약 20명을 겨냥한 HWP 스피어피싱 | A+B |
| 2023 | 김수키 | 한미 6개 기관(미 FBI·국무부·NSA, 한 국정원·경찰청·외교부)이 공동 보안 권고문 발표. 기자·학자 사칭 사회공학을 경고 | B |
| 2025.03 | APT37 | '토이박스 스토리' 작전. 북한 관련 활동가를 겨냥해 HWP로 위장한 LNK 유포 | B |
| 2025.08~11 | APT37 | '아르테미스 작전'. 교수·방송작가 사칭, OLE 하이퍼링크 위장, 스테가노그래피와 DLL 사이드 로딩 결합 | B |
연대기를 보면 흐름이 분명하다. 2010년대 중반까지는 축 A(취약점)가 주력이었다. 한컴의 패치가 빨라지고 내장 고스트스크립트가 제거되자, 공격의 무게는 축 B(사회공학과 정상 기능 악용)로 옮겨 갔다. 2023년 한미 공동 권고문이 강조한 것도, 김수키가 첫 메일에는 악성코드를 붙이지 않고 오랫동안 신뢰를 쌓는다는 점이었다.
5. 지금도 HWP를 노리는 북한
북한의 HWP 공격은 과거형이 아니다. 2026년에도 HWPX 문서와 스크립트 파일(JSE)을 결합한 변종, HWP와 LNK를 엮은 김수키의 연쇄 공격이 보안 업계에서 계속 보고되고 있다.
주목할 점이 하나 더 있다. 공격자는 이미 HWPX도 미끼로 쓴다. 개방형 포맷으로 바꾸는 것만으로 이 전쟁이 끝나지 않는다는 뜻이다. 공격자는 포맷이 아니라 표적이 신뢰하는 업무 흐름을 따라온다. 한국 공공기관이 HWPX를 쓰면 HWPX로, 공직자통합메일이 막히면 메신저와 클라우드 링크로 이동할 것이다.
6. 우리는 무엇을 해야 하는가?
처방은 두 개의 공격 축에 맞춰 설계해야 한다. 이 칼럼은 네 가지를 제안한다. 첫째와 둘째는 축 A, 셋째는 축 B, 넷째는 조직과 개인의 몫이다.
첫째, 30년 된 C 코드를 메모리 안전 언어로 옮겨야 한다 [축 A]
이 칼럼에서 가장 강조하고 싶은 부분이다.
아래아 한글의 뿌리는 1980년대 말 도스(DOS) 시절의 C 코드다. 윈도우 시대를 거치며 C/C++로 확장됐고, 그 위에 30년 넘게 기능과 하위 호환 코드가 덧대어졌다. 포인터를 직접 다루고 메모리를 손으로 할당·해제하는 방식은 당시엔 성능을 위한 최선의 선택이었다. 그러나 오늘날 그 코드는 북한이 10년 넘게 파고드는 공격의 지점이다. 한 때는 각 윈도우 버전마다 GDI 렌더링의 차이가 있는 MFC도 사용하지 않고 렌더링을 했다고 했다.
여기에 사람의 문제가 겹친다. 아래아 한글을 만든 1세대 개발자들은 이제 환갑을 전후한 나이가 됐고, 대부분 회사를 떠난 지 오래다. 초기 설계 의도와 내부 구조를 깊이 이해하는 인력은 줄어드는데, 그 위에 덧댄 코드는 계속 늘어난다. 코드는 늙지 않지만, 코드를 이해하는 사람은 늙는다. 레거시 시스템의 가장 큰 위험은 바로 이 지식의 단절이다.
세계의 방향은 이미 정해졌다.
- 마이크로소프트는 매년 자사 제품에서 패치하는 보안 취약점의 약 70%가 메모리 안전성 문제라고 밝혔다.
- 구글은 안드로이드 신규 코드를 Rust 등 메모리 안전 언어로 쓰기 시작한 뒤, 전체 취약점 중 메모리 안전성 취약점 비중이 2019년 76%에서 2024년 24%로 떨어졌다고 발표했다. 기존 C/C++ 코드를 전부 갈아엎지 않고 새 코드만 바꿔도 효과가 났다는 점이 핵심이다.
- 미국 CISA·NSA·FBI와 우방국 사이버 보안 기관들은 2023년 소프트웨어 제조사에 '메모리 안전 로드맵' 수립을 공동 권고했고, 백악관 국가사이버국장실(ONCD)도 2024년 메모리 안전 언어 전환을 공식 촉구했다.
- 미국 국방고등연구계획국(DARPA)은 AI로 C 코드를 Rust로 자동 변환하는 TRACTOR 프로그램을 추진하고 있다.
과거에는 수백만 줄의 C 코드를 다른 언어로 옮기는 것이 비현실적이었다. 이제는 LLM 기반 코드 마이그레이션이라는 새로운 도구가 있다. 현실적인 순서는 이렇다.
- 파서부터 옮긴다. 축 A의 공격은 문서를 '읽는' 순간 일어난다. HWP/HWPX 파서, 이미지·OLE 처리 모듈처럼 외부 입력을 받는 경계 코드부터 Rust로 다시 쓴다.
- AI로 변환하고, 테스트로 검증한다. LLM이 C 코드를 Rust로 초벌 변환하고, 기존 엔진과 새 엔진에 같은 문서 수백만 건을 넣어 결과를 비교하는 차분 테스트(differential testing)와 퍼징(fuzzing)으로 동작을 확인한다. 한컴은 30년간 쌓인 실제 문서라는, 다른 어느 회사도 갖지 못한 테스트 자산을 갖고 있다. LLM은 번역기이지 판정자가 아니다. 판정은 테스트가 한다.
- 남은 C 코드는 가둔다. 당장 옮기지 못하는 부분은 샌드박스에 격리해, 뚫려도 시스템 전체로 번지지 않게 한다.
- 지식을 코드로 남긴다. 변환 과정에서 레거시 코드의 동작을 LLM으로 문서화하고 테스트로 고정하면, 1세대 개발자의 암묵지가 다음 세대가 읽을 수 있는 형태로 보존된다.
비용은 누가 내는가? 솔직히 말해 이 작업은 한컴 혼자 감당하기에 크다. 매출을 늘려주지 않는 보안 재작성에 기업이 자발적으로 수백억 원을 쓰기는 어렵다. 그러나 HWP가 국가 문서 인프라인 이상 이것은 한 기업의 품질 문제가 아니라 국가 사이버 안보의 문제다. 두 가지 명분과 지렛대가 필요하다.
- 조달 조건. 공공기관이 구매하는 문서 소프트웨어에 '메모리 안전 로드맵' 제출을 요구한다. 미국이 '설계 단계부터 안전한(Secure by Design)' 원칙을 조달에 연결하는 것과 같은 방식이다.
- 공동 R&D. 파서 재작성과 퍼징 인프라를 국가 R&D로 지원하고, 그 결과물 일부(특히 HWPX 파서)를 오픈소스로 공개해 보안 업계 전체가 함께 검증하게 한다.
둘째, 개방형 문서 체계로의 전환을 끝까지 밀어붙여야 한다. 단일 워드 프로세서로 노출되는 취약점을 최대한 줄여야 한다.
정부는 2022년 중앙부처 온나라에 HWPX를 의무화했고, 2026년 5월 18일부터 지방정부까지 확대했다. 공무원 간 온메일과 대민 창구인 공직자통합메일은 10월부터 HWP 첨부를 제한한다. HWPX는 XML 기반 개방형 문서 표준(OWPML, KS X 6101)을 따르며, 확장자를 zip으로 바꾸면 내부 구조를 그대로 들여다볼 수 있다.
전환의 진짜 가치는 '검사 가능성'에 있다. 구조가 투명해야 자동 검사, 무해화(CDR), AI 분석이 가능하다. 다만 앞서 봤듯 개방형 포맷이 곧 안전한 포맷은 아니다. HWPX에서도 파싱 취약점이 보고됐고 공격자는 이미 HWPX를 쓴다. 포맷 전환은 출발점이지 결승선이 아니다.
셋째, LLM 기반 문서 검사 체계를 구축해야 한다
첫째 항목의 LLM이 코드를 고치는 도구라면, 여기서의 LLM은 들어오는 문서를 검사하는 도구다. 같은 기술, 전혀 다른 용도다.
축 B의 공격은 시그니처로 잡기 어렵다. 악성 코드가 아니라 정상 기능과 그럴듯한 맥락으로 이루어져 있기 때문이다. 그래서 문맥을 읽는 검사가 필요하다. HWPX에서 OLE 개체, 외부 링크, 스크립트, 메타데이터를 구조적으로 추출한 뒤, LLM이 다음과 같은 질문을 던지게 할 수 있다.
- "인터뷰 질문지라면서 왜 실행 가능한 개체가 들어 있는가?"
- "본문에 보이는 링크 텍스트와 실제 연결 대상이 일치하는가?"
- "발신자로 표시된 교수의 소속과 문서 서식·메타데이터가 일치하는가?"
이 구조에서도 LLM은 최종 판정자가 아니다. 결정론적 검사 엔진이 위험 요소를 확정하고, LLM은 그 앞단에서 의심 신호를 걸러내고 사람이 이해할 수 있는 말로 설명하는 역할을 맡는다. 수십 년 치 구버전 HWP 문서를 HWPX나 구조화된 데이터로 옮겨 두는 작업도 이 검사 체계와 공공 데이터 활용을 동시에 위한 기반이 된다.
넷째, 조직은 CDR을 기본값으로, 개인은 다섯 가지 습관을 [조직·개인]
조직 차원. CDR(Content Disarm and Reconstruction, 콘텐츠 무해화)은 문서에서 OLE 개체, 스크립트, 외부 링크 같은 실행 요소를 걷어내고 안전한 문서로 재구성한다. 취약점이 알려졌든 아니든 상관없이 작동하므로 축 A의 제로데이와 축 B의 위장 링크 양쪽에 효과가 있다. 외부에서 들어오는 문서는 CDR을 거친 뒤에만 열리도록 메일 게이트웨이에 기본값으로 두어야 한다.
개인 차원. 정책과 기술이 바뀌는 데는 몇 년이 걸린다. 그 사이 북한이 노리는 것은 결국 한 사람의 클릭이다.
오늘부터 할 수 있는 다섯 가지
- 처음 연락 온 교수·기자·작가가 문서를 보내면, 원래 알던 경로로 한 번 더 확인한다. 2023년 한미 공동 권고문은 짧은 영상통화로 신원을 확인하는 방법을 권했다. 쌩얼일지도 모르는 순간 영통이라니...
- 문서를 열었을 때 '콘텐츠 허용', '실행' 같은 경고가 뜨면 누르지 않는다. 정상적인 보고서나 질문지는 그런 허락을 요구하지 않는다.
- 문서 안의 링크와 아이콘은 문서가 아니다. 꼭 필요하면 링크 주소를 직접 확인하고 브라우저에 따로 입력한다.
- 윈도우 탐색기에서 '파일 확장자 표시'를 켠다. 'HWP 아이콘'을 단
.lnk파일은 문서가 아니라 실행 파일이다.- 한컴오피스를 최신으로 유지하고, 지원이 끝난 구버전은 교체한다. 의심스러운 문서를 받았다면 KISA(118)나 국가정보원(111)에 신고한다.
7. 예상되는 반론과 응답
그럴 바엔 MS 워드로 갈아타면 되지 않나?실제로 국가AI전략위원회 민간위원들 사이에서도 워드 도입론이 나왔다. 그러나 워드로 바꾸면 해킹의 단일 공격축 하나가 사라지는 것이 아니라다른 회사의 C++ 파서로 옮겨 갈 뿐이다. 워드 역시 매크로와 OLE를 악용한 공격의 단골 통로였다. 더구나 수십 년 치 공공 서식과 한국어 조판 자산을 버리는 비용, 국가 핵심 문서 인프라를 해외 기업 한 곳에 의존하게 되는 위험도 따져야 한다. 문제는 '국산이냐 외산이냐'가 아니라 검사 가능하고 메모리 안전한가다. 그 기준을 충족한다면 HWPX든 DOCX든 ODF든 상관없다. HWPX가 현실적인 출발점인 이유는 기존 서식 자산을 가장 손실 없이 옮길 수 있기 때문이다.
공무원과 연구자들의 전환 비용은?작지 않다. 오래된 양식이 깨지고, 구버전 사용자는 파일을 못 열고, 부처 간 시스템 연계도 손봐야 한다. 그래서 정부도 공직자통합메일에 5개월의 유예기간을 두고 안내 팝업부터 띄우는 단계적 방식을 택했다. 전환 비용은 실재하지만,13년간 이어진 침투의 비용과 비교하면 이야기가 달라진다.
한컴은 그동안 아무것도 안 했나?그렇지 않다. 한컴은 2010년부터 HWPX를 지원해 왔고, 2021년에는 정기 패치로 HWPX를 기본 저장 형식으로 바꿨다. 2018년 무렵에는 공격 통로가 된 내장 고스트스크립트 모듈을 보안 업데이트로 제거했고, 취약점이 보고되면 KrCERT/CC를 통해 패치를 내고 있다. 이 칼럼의 요지는 한컴의 노력이 부족했다는 것이 아니라,패치와 포맷 전환이라는 지금의 방식만으로는 언어 수준의 결함 계열을 끝낼 수 없다는 것이다. 다음 단계는 코드의 토대를 바꾸는 일이다.
Rust로 바꾸면 북한 해킹이 끝나나? 아니다. 3장에서 봤듯 Rust는 축 A를 줄일 뿐, 위장 링크를 누르는 축 B는 막지 못한다. 그래서 처방은 네 가지가 한 묶음이어야 한다.
마무리하며
1989년, 외국 소프트웨어가 한글을 제대로 다루지 못하던 시절에 대학생 몇 명이 한국어로 문서를 쓰는 방식을 바꿨다. 그들이 쓴 C 코드는 30년 넘게 이 나라의 행정과 연구와 산업을 떠받쳤다.
그 코드는 지금도 그때 모습 그대로 작동한다. 달라진 것은 바깥 세상이다. 북한은 그 코드의 틈을 13년째 파고들고 있고, 코드를 처음 설계한 사람들은 하나둘 현장을 떠났다. 이제 공무원 메일에서 HWP가 막히는 이번 10월은 끝이 아니라 시작이어야 한다. 포맷을 바꾼 다음에는 코드를 바꾸고, 코드를 바꾼 다음에는 그 지식을 다음 세대에 남겨야 한다.
1989년의 대학생들에게 C가 있었다면, 2026년의 우리에게는 AI와 메모리 안전 언어가 있다. 아래아 한글을 다시 쓰는 일은 그 유산을 버리는 일이 아니라, 그 유산이 앞으로 30년을 더 버티게 하는 일이다.
참고 링크
북한의 HWP 공격 사례
- 38 North, "HWP as an Attack Surface: What Hancom's Hangul Word Processor Means for South Korea's Cyber Posture as a US Ally" (2025.10): https://www.38north.org/2025/10/hwp-as-an-attack-surface-what-hancoms-hangul-word-processor-means-for-south-koreas-cyber-posture-as-a-us-ally/
- Genians Security Center, Operation Artemis 분석 보고서 (2025.12): https://www.genians.co.kr/en/blog/threat_intelligence/dll
- Genians Security Center, "Operation: ToyBox Story" (2025.05): https://www.genians.co.kr/blog/threat_intelligence/toybox-story
- 보안뉴스, "'한글파일 열었더니 해킹' 北 연계 APT37 '아르테미스' 공격 포착" (2025.12.22): https://m.boannews.com/html/detail.html?idx=141110
- 보안뉴스, "북한 해킹그룹 APT37의 치밀한 스피어피싱 공격기법 분석해보니" (2023.06.13): https://m.boannews.com/html/detail.html?idx=119028
- 조선비즈, "'HWP에 악성 파일 숨겨 유포'… 北 해커 먹잇감 된 아래아한글" (2025.12.26): https://biz.chosun.com/it-science/ict/2025/12/26/6BU7EWAVA5FVDADT3W4XPQI4BU/
- KBS, "한글파일 열었더니 감염…북한 해킹 '아르테미스' 포착" (2025.12.22): https://newsws.kbs.co.kr/news/pc/view/view.do?ncd=8439673
- Korea JoongAng Daily, "Pyongyang-backed hackers launch newly detected cyberattack scheme using computer files" (2025.12): https://www.koreajoongangdaily.com/korea/pyongyang-backed-hackers-launch-newly-detected-cyberattack-scheme-using-computer-files/12026158
- Kaspersky Securelist, "The 'Kimsuky' Operation: A North Korean APT?" (2013.09): https://securelist.com/the-kimsuky-operation-a-north-korean-apt/57915/
- SecurityWeek, "North Korea Suspected of Using Zero-Day to Attack South" (2015.09): https://www.securityweek.com/north-korea-suspected-using-zero-day-attack-south/
- Computerworld, "North Korea is likely behind attacks exploiting a Korean word processing program" (2015.09): https://www.computerworld.com/article/1632897/north-korea-is-likely-behind-attacks-exploiting-a-korean-word-processing-program.html
- Trend Micro, "HWP and PostScript Abused Via Malicious Attachments" (2017.09): https://www.trendmicro.com/en/research/17/i/hangul-word-processor-postscript-abused-malicious-attachments.html
- 보안뉴스, "EPS 취약점 공격, 현재도 공공기관과 기업 노려" (2018.11.23): https://m.boannews.com/html/detail.html?idx=74890
- 시큐레터, "Kimsuky(APT43) HWP+LNK 연쇄 공격 — 한국 공공·안보 표적 TTP 완전 해부" (2026.04.21): https://seculetter.com/content-security/blog/a12-kimsuky-hwp-lnk/
- 시큐레터, "HWP/HWPX 제로데이 2020-2026 연표" (2026.04.18): https://seculetter.com/content-security/blog/a11-hwpx-zeroday-timeline/
취약점·공동 권고문
- NVD, CVE-2025-29867 상세: https://nvd.nist.gov/vuln/detail/CVE-2025-29867
- FBI·국무부·NSA·국정원·경찰청·외교부 공동 권고문, "North Korea Using Social Engineering to Enable Hacking of Think Tanks, Academia, and Media" (2023.06.01): https://media.defense.gov/2023/Jun/01/2003234055/-1/-1/0/JOINT_CSA_DPRK_SOCIAL_ENGINEERING.PDF
- CISA·FBI·USCYBERCOM 공동 권고문 AA20-301A, "North Korean Advanced Persistent Threat Focus: Kimsuky" (2020.10): https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-301a
개방형 문서 전환 정책
- 바이라인네트워크, "정부, 공공 문서 유통망서 hwp 첨부 제한 추진" (2026.04.23): https://byline.network/2026/04/23-586/
- 헤럴드경제, "공공부문, 5월부터 'hwp 첨부' 제한된다" (2026.04.23): https://www.heraldk.com/article/2026042316000053545
- 머니투데이, "AI 못 읽는 한글 파일… AI G3 이끄는 숨은 공신들" (2026.06): https://www.mt.co.kr/article/2026052623275813425
- 디지털데일리, "[국감 2025] 韓 디지털 갈라파고스화 우려... '정부 문서 90%는 AI가 못 읽는 깜깜이'" (2025.10.14): https://www.ddaily.co.kr/page/view/2025101415400444080
- 바이라인네트워크, "아래아한글, HWP 아닌 HWPX로 저장된다" (2021.04.15): https://byline.network/2021/04/15-117/
- 디지털투데이, "韩国5月起限制公共文书流通使用HWP,推动转向HWPX" (2026.04.24): https://www.digitaltoday.co.kr/cn/view/50599/
메모리 안전 언어 전환
- Microsoft Security Response Center, "A proactive approach to more secure code" (2019): https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/
- Google Security Blog, "Eliminating Memory Safety Vulnerabilities at the Source" (2024.09): https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
- CISA 외, "The Case for Memory Safe Roadmaps" (2023.12): https://www.cisa.gov/resources-tools/resources/case-memory-safe-roadmaps
- 백악관 ONCD, "Back to the Building Blocks: A Path Toward Secure and Measurable Software" (2024.02): https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
- DARPA, "TRACTOR: Translating All C to Rust": https://www.darpa.mil/research/programs/translating-all-c-to-rust