MSFS 2020에서 IFR 비행을 할 때 쓰려고 만든 개인용 터치 EFB(Electronic Flight Bag)예요. 게임 PC에서 작은 브리지 서버를 띄우고, 태블릿 브라우저로 접속해서 FCU 조작, 지도, 경로, 체크리스트를 봐요.

저장소: https://github.com/joseph-84/fs2020_EFB (MIT)

FLY 화면. FCU 조작과 비행 정보를 한 화면에 모았어요 (모의 데이터)

왜 만들었나

FS2020에서는 주로 기본 A320이나 FlyByWire A32NX로 IFR 비행을 해요. 비행 중 FCU 속도·방향·고도를 바꿀 때마다 가상 콕핏을 마우스로 돌리는 게 꽤 번거로웠어요. 조이스틱(TCA Sidestick)을 잡은 채로 시점을 옮기고, 작은 노브에 마우스를 맞추고, 휠을 돌리고…

마침 쓰지 않는 태블릿이 하나 있어서, 이걸 조종석 옆에 세워 두고 터치로 FCU를 돌리는 보조 화면으로 쓰기로 했어요. 처음엔 FCU만 생각했는데 만들다 보니 지도, 경로 계산, 출발 준비, 체크리스트, 음성 콜아웃까지 붙었어요.

구조

[게임 PC]                                          [태블릿]
MSFS 2020 ⇄ SimConnect ⇄ 브리지 서버 (Node.js) ──LAN/WebSocket──▶ 브라우저 (웹 UI)
 
  • 브리지 서버: 게임 PC에서 돌아요. SimConnect로 비행 데이터를 읽고, 태블릿에서 온 명령(FCU 조작 등)을 시뮬레이터로 보내요.
  • 웹 UI: 태블릿은 브라우저만 있으면 돼요. 앱 설치가 필요 없고, Windows 태블릿·안드로이드·아이패드 어느 쪽이든 쓸 수 있어요.
  • 같은 공유기(와이파이)에 붙어 있으면 콘솔에 나온 http://192.168.x.x:8787 주소로 접속하면 끝이에요.

사용한 기술

구분 사용한 것
서버 Node.js 22+ / TypeScript, node-simconnect, ws(WebSocket)
웹 UI Vite + 바닐라 TypeScript (프레임워크 없음, 저사양 태블릿 고려)
지도 Leaflet + OpenTopoMap 타일
경로 데이터 Little Navmap이 만든 FS2020 항법 DB (Node 내장 SQLite로 읽기)
글꼴 B612 / B612 Mono (Airbus 조종석용으로 만들어진 공개 글꼴)

화면 소개

아래 화면들은 모두 시뮬레이터 없이 모의 비행 데이터(김포 → 제주)로 찍었어요. 그래서 상단에 MOCK 표시가 있어요.

1. FLY: FCU + 비행 정보

  • 위쪽 띠: 지상속도와 바람, 남은 연료, 다음 웨이포인트까지 거리·시간, 목적지까지 거리와 ETA
  • 그 아래: 비행 단계(PREFLIGHT → TAXI → … → LANDED). 속도·고도·지상 여부로 자동으로 판단해요.
  • FCU 카드 4개(SPD / HDG / ALT / V/S): 큰 − + 버튼, PUSH / PULL, 길게 누르면 빠르게 바뀌어요.
  • 카드마다 "현재" 줄이 있어서 목표값과 실제 속도·방향·고도·승강률을 같이 볼 수 있어요.
  • 아래 줄: LOC, AP1, AP2, A/THR, EXPED, APPR 모드 버튼

기체를 바꾸면 화면도 자동으로 바뀌어요. Cessna 172(G1000)로 바꾸면 HDG / ALT / V/S와 GA용 AP 버튼(AP, HDG, NAV, APR, REV, ALT)이 나와요.

Cessna로 바꾸면 GA 오토파일럿 배치로 바뀌고, 위쪽 띠에 IAS가 추가돼요

기본 A320과 FBW A32NX는 내부 구현이 완전히 달라요. FBW는 FCU 대부분을 자체 L:Var와 커스텀 이벤트로 처리해서 표준 SimConnect 이벤트가 먹지 않아요. 그래서 서버에서 기체 이름(TITLE)으로 기체를 판별하고, 기체별 어댑터(기본 A320 / FBW / GA)가 같은 버튼을 각자 맞는 방식으로 보내도록 했어요.

2. MAP: VFR Map처럼 경로와 내 위치

지형도 위에 경로, 웨이포인트, 내 항공기, T/D(강하 시작점)가 표시돼요

  • 지나온 구간은 흐리게, 다음 웨이포인트까지는 굵게, 다음 지점은 강조해요.
  • 왼쪽 위 카드: GS, 고도, 트랙, 다음 지점, T/D까지 거리, 목적지
  • 오른쪽 버튼: 확대/축소, 따라가기, 경로 전체 보기, 북쪽 위 / 진행 방향 위, 레이어(공항·VOR·NDB·이름)

야간 비행용 어두운 지도도 있어요.

야간 모드. 같은 지형도의 색을 반전해서 어둡게 만들었어요

진행 방향을 위로 두는 모드도 있어요. 실제 항공기 ND처럼 진행 방향이 항상 위를 향하고, 내 항공기는 화면 아래쪽에 있어서 앞쪽이 더 넓게 보여요.

진행 방향 위(TRK UP). 웨이포인트 이름은 지도가 돌아가도 똑바로 서 있어요

3. ROUTE: FS2020 데이터로 경로 계산

  • SimBrief 사용자명으로 OFP를 불러오거나, 출발·도착 공항만 넣고 "직접 계산"을 눌러요.
  • 활주로는 실제 METAR 바람을 보고 고르고, SID → 항로 → STAR까지 이어서 계산해요.
  • 비행 중에는 현재 위치 기준으로 지나간 지점(PASSED), 다음 지점(NEXT), 남은 거리와 ETA가 자동으로 갱신돼요.
  • 계산한 경로는 MSFS용 .PLN 파일로도 저장해서 월드맵에서 바로 불러올 수 있어요.

4. PREP: 출발 준비 순서

  • 무게·연료(SimBrief), 이륙·착륙 속도, QNH와 바람
  • 기체별 MCDU/G1000 입력 순서: FBW 8단계, 기본 A320 9단계, Cessna 5단계
  • 각 항목에 넣을 값이 오른쪽에 나와서 MCDU 옆에 두고 하나씩 체크하면서 입력하면 돼요.

5. CHECKLIST + 음성

 비행 단계가 바뀌면 맞는 체크리스트가 자동으로 선택돼요

  • A320 NORMAL과 Cessna 172 체크리스트
  • 항목을 음성으로 읽어 주고, 조이스틱 버튼 하나로 "확인하고 다음"을 할 수 있어요. 손을 스틱에서 뗄 필요가 없어요.

음성 콜아웃 설정. 기체 계열별로 콜아웃을 켜고 끌 수 있어요

  • 이륙(One hundred knots, V1, Rotate, Positive climb), 고도(One thousand to go), 접근(Hundred above, Minimums), 착륙 후(Spoilers, Seventy knots) 콜아웃 9개
  • FBW·기본 A320은 기체가 직접 Minimums를 불러 주기 때문에 기본값은 꺼 뒀어요.
  • 소리는 게임 PC 스피커(헤드셋)로 나와요.

만들면서 부딪힌 것들

1. SimBrief 경로와 MCDU가 안 맞는 문제 처음엔 경로를 SimBrief OFP에서 그대로 가져왔어요. 그런데 무료 SimBrief는 AIRAC가 최신이고, FS2020 기본 항법 데이터는 그보다 오래돼서 SID/STAR 이름이 안 맞는 경우가 자주 생겼어요. 결국 경로 계산은 **FS2020 항법 데이터(Little Navmap DB)**로 직접 하고, SimBrief는 무게·연료·CI만 쓰도록 바꿨어요. 항로망을 그래프로 만들어 SID 끝점에서 STAR 시작점까지 최단 경로를 찾아요.

2. 다크 지도에 API 키가 필요해짐 야간 지도로 CARTO 다크 타일을 쓰려고 했는데, 지금은 API 키를 요구하더라고요. 그래서 같은 OpenTopoMap 타일에 CSS 필터(색 반전 + 색상 회전)를 걸어서 어두운 지도를 만들었어요.

3. 브라우저 음성의 제약 처음엔 태블릿 브라우저의 음성 합성(Web Speech API)으로 콜아웃을 냈는데, 브라우저 정책상 화면을 한 번 터치해야 소리가 나요. 헤드셋으로 듣는 것도 불편했고요. 지금은 게임 PC에서 Windows 내장 음성(PowerShell + System.Speech)으로 말하게 고정했어요. PowerShell을 매번 띄우면 1초 넘게 늦어서, 하나를 계속 띄워 두고 한 줄씩 보내는 방식으로 지연을 줄였어요.

4. 해상도가 다른 태블릿 처음엔 3:2 태블릿(1440×960) 하나에 맞춰 만들어서 아이패드나 16:10 안드로이드 태블릿에서는 아래쪽 버튼이 겹쳤어요. 지금은 1440×960 기준 레이아웃을 화면 크기에 맞춰 통째로 키우거나 줄이고, 비율이 다르면 남는 방향으로 레이아웃이 늘어나게 했어요.

 1024×768(구형 아이패드 크기)에서도 겹치지 않아요


설치와 실행

  1. 게임 PC에 Node.js LTS(22.13 이상)를 설치해요.
  2. (ROUTE를 쓰려면) Little Navmap에서 MSFS 2020 Scenery Library를 한 번 불러와요. 브리지가 DB를 자동으로 찾아요.
  3. 저장소를 받아요. GitHub(https://github.com/joseph-84/fs2020_EFB)에서 Code → Download ZIP으로 받거나 git clone을 써요.
    git clone https://github.com/joseph-84/fs2020_EFB.git
  4. 받은 폴더에서 start-efb.bat을 더블클릭해요. 처음 실행하면 패키지를 설치하고 빌드해요.
  5. 콘솔에 나온 주소를 태블릿 브라우저에서 열어요. 방화벽 창이 뜨면 "개인 네트워크"를 허용해요.

FS2020을 먼저 켜 두지 않아도 돼요. 브리지가 5초마다 다시 연결해요. 시뮬레이터 없이 화면만 보고 싶으면 start-efb.bat --mock으로 모의 비행을 볼 수 있어요.

⚠️ 집 네트워크 안에서만 쓰는 툴이에요. 인증이 없으니 공유기 포트포워딩으로 외부에 열지 마세요.

앞으로

  • 실제 비행으로 하나씩 테스트하는 중이에요. (기본 A320 FCU는 확인 완료, FBW와 Cessna는 진행 중)
  • 실기 테스트에서 나온 문제를 고치면서 FBW 전용 기능(FCU 모드 표시 등)을 더 채워 갈 예정이에요.
  • 이슈나 개선 아이디어는 GitHub 저장소에 남겨 주세요: https://github.com/joseph-84/fs2020_EFB/issues

  • 저장소: https://github.com/joseph-84/fs2020_EFB
  • 라이선스: MIT
  • 지도: © OpenStreetMap contributors, SRTM · © OpenTopoMap (CC-BY-SA)
  • Microsoft Flight Simulator, Airbus, FlyByWire, Cessna, SimBrief는 각 소유자의 상표이며 이 프로젝트와 관계가 없어요.

시작은 이랬습니다

서버 몇 대를 관리하다 보면 하루에도 몇 번씩 이런 패턴을 반복하게 됩니다.

  1. 터미널 열기
  2. ssh myserver
  3. tmux attach -t work (또는 세션 이름 까먹어서 tmux ls부터)
  4. 작업
  5. 다른 서버는 또 새 터미널 탭 열고 처음부터 반복

세션이 늘어날수록, 서버가 늘어날수록 이 반복이 점점 귀찮아졌습니다. "이거 그냥 브라우저에서 다 보이면 안 되나?" 싶어서, 주말에 하나 만들어봤습니다. 이름은 그냥 tmuxctl.

tmuxctl이 뭐냐면

한 줄로: tmux를 위한 Cockpit 스타일 웹 콘솔입니다.

  • 브라우저에서 서버 계정으로 로그인하고
  • 떠 있는 tmux 세션들을 한눈에 보고
  • 클릭 한 번으로 새 세션을 만들고
  • 터미널 화면이 브라우저 안에서 그대로 실시간으로 나옵니다 (진짜 tmux attach를 한 것과 완전히 동일하게 동작합니다)
  • (Linux 서버라면) 계정 생성/삭제 같은 사용자 관리도 웹에서 할 수 있고요

중요한 건, 가짜로 흉내만 낸 게 아니라 진짜 시스템 계정으로 로그인하고, 진짜 tmux 명령을 그대로 호출한다는 점입니다. 브라우저 탭을 닫아도 안의 세션은 서버에서 계속 살아있습니다. 딱 SSH로 붙어서 tmux attach 했다가 나온 것과 똑같습니다.

재밌었던 건 만드는 과정

이건 Claude로 디자인 목업(스크린 시안)을 먼저 그려보고, 그 목업을 그대로 실제로 동작하는 앱으로 구현하는 방식으로 만들었습니다. 로그인 화면, 세션 목록, 터미널 화면까지 눈으로 먼저 보고 "이렇게 생겼으면 좋겠다"를 정한 다음, 그걸 실제 Node.js 백엔드 + React 프런트엔드로 옮기는 흐름이었어요.

만들면서 신경 쓴 부분들:

  • 로그인: 별도 계정 DB 없이 서버의 진짜 PAM 인증을 그대로 씁니다. 새 계정을 또 만들 필요가 없어요.
  • 권한 분리: 웹 앱 자체는 평범한 일반 계정으로 돌아갑니다. 계정 생성/삭제처럼 root가 필요한 작업만 딱 하나의 스크립트를 통해서만, 그것도 sudoers에 그 경로 하나만 화이트리스트로 열어뒀습니다. 앱이 뚫려도 root 권한 전체를 내주는 구조가 아닙니다.
  • 역할 기반 권한: 관리자 / 운영자 / 뷰어로 나눠서, 뷰어는 터미널을 보기만 하고 입력은 못 하게 막아뒀습니다.
  • 브루트포스 방지: 로그인 실패가 쌓이면 계정을 잠급니다.

그리고 한 차례 SAST/DAST/SBOM 점검도 거쳐서 발견된 취약 라이브러리 버전들을 올렸습니다.

설치는 명령어 한 줄

git clone https://github.com/joseph-84/tmuxctl.git
cd tmuxctl
./deploy/bootstrap.sh

이 한 줄이 알아서:

  • node, tmux, 빌드 도구 같은 필요한 것들이 없으면 감지해서 설치하고
  • 백엔드/프런트엔드 의존성을 깔고 빌드하고
  • 마지막에 "로그인할 때마다 자동으로 켜지게 할까요?"까지 물어봐줍니다.

Linux, macOS 둘 다 됩니다 (사용자 관리 기능만 Linux 전용이에요 — macOS는 계정 구조가 좀 달라서요).

써보고 싶으시다면

GitHub에 공개해뒀습니다: https://github.com/joseph-84/tmuxctl

혼자 쓰려고 만들었는데, 비슷한 불편함 겪으시는 분들 있을 것 같아서 공유합니다. 이슈/PR 다 환영이고, 써보시고 불편한 점 있으면 편하게 남겨주세요.

전기차 충전 인프라 시장은 회원 가입, 결제, 실시간 충전 제어를 위해 대규모 개인정보와 IoT 통신 데이터를 동시에 다루는 영역으로, 공격자에게는 매력적인 표적 자산이 집중된 환경입니다. 2026년 7월 발생한 채비(CHAEVI)의 해킹 사고는 단순한 웹 서비스 침해를 넘어, 조사 과정에서 약 1년 6개월 전인 2025년 1월경 발생한 미탐지 침해까지 드러났다는 점에서 '탐지되지 않은 침해가 얼마나 오래 지속될 수 있는가'라는 화두를 던집니다. 타사의 사고를 사후 분석(Post-Mortem)하여 자사의 탐지·대응 체계를 점검하는 것은 정보보호 실무자에게 상시적으로 요구되는 과제이며, 본 사고 역시 이러한 관점에서 되짚어볼 가치가 있습니다.

1. Incident Summary (사고 개요 및 규제 현황)

사고경위

일자 내용
2026. 07. 23. 외부의 불법적인 해킹 공격으로 개인정보 유출 발생, 채비 인지 및 공격 경로 차단
2026. 07. 26. 개인정보보호위원회·KISA 신고 완료, 대상 고객 1차 개별 통지 및 공지사항 게시
2026. 07. 30. 내부 조사 과정에서 2025년 1월경 발생한 별도 유출 이력 추가 확인, 2차 공지 및 고객 후속 통지
2026. 07. 30. 이후 외부 전문기관과 합동 원인 조사 및 재발 방지 대책 수립 진행 중

침해 유형 및 자산

침해 대상은 채비 회원 가입 시스템(웹·앱 연동 회원 DB)으로, 유출된 개인정보 항목은 다음과 같이 구분됩니다.

  • 2026년 7월 사고: 이메일(평문), 비밀번호(암호화), 이름(암호화), 연락처(암호화), 성별, 생년월일, 회원순번, 가입일시
  • 2025년 1월 사고(소급 확인): 고객명(암호화), 주소(암호화), 연락처(암호화), 휴대폰번호(암호화), 데이터 생성일시, 데이터 순번

주민등록번호, 여권번호, 카드·계좌번호 등 결제 관련 고유식별정보 및 금융정보는 미수집 항목으로 유출 대상에서 제외되었습니다.

피해 Scale

2026년 7월 사고 기준 총 유출 건수는 298,333건이며, 세부 내역은 다음과 같습니다.

유출 유형 건수
이메일 단독 유출 164,858건
이메일 + 비밀번호(암호화) 131,411건
이메일 + 이름·연락처(암호화) + 성별·생년월일·회원순번·가입일시 1,235건
이메일 + 이름·연락처·비밀번호(암호화) + 성별·생년월일·회원순번·가입일시 829건

2025년 1월 사고분의 구체적 항목별 규모는 이 리포트 작성 시점 기준 외부 전문기관과 조사 중으로, 공식 확정치는 아직 공개되지 않았습니다.

법적 행정처분

채비는 개인정보보호위원회, 한국인터넷진흥원(KISA), 금융위원회, 금융감독원 및 수사기관에 신고를 완료한 상태입니다. 다만 이 리포트 작성 시점(2026년 8월) 기준으로 개인정보보호위원회의 과징금·과태료 의결 등 행정처분 결과는 아직 공개되지 않았으며, 조사가 진행 중인 것으로 파악됩니다. 참고로 최근 국내 대규모 유출 사고들에서는 개인정보 보호법 개정에 따라 관련 매출액의 최대 3%(위반 정도에 따라 상향)까지 과징금이 부과되는 추세이므로, 본 건 역시 향후 안전조치의무 위반 여부에 따라 상당한 수준의 제재가 예상됩니다.

2. Root Cause Analysis (공격 벡터 및 기술적 결함 분석)

채비 측 공지에는 침해 경로에 대한 구체적인 기술적 원인이 공개되지 않았습니다. 다만 유출 데이터의 구성(이메일은 평문, 이름·연락처·비밀번호는 암호화 상태로 유출)과 사고 정황을 종합할 때, 보안 전문가 관점에서 다음과 같은 공격 벡터 및 구조적 결함이 합리적으로 추정됩니다.

TTPs (추정 공격 기법)

  • 회원 DB 테이블에 대한 비인가 접근: 이메일 필드가 평문으로, 나머지 개인식별 필드는 암호화 상태로 그대로 유출된 정황은 애플리케이션 계층의 취약점(SQL Injection, 인증 우회, 취약한 API 엔드포인트 등)을 통해 DB 레코드를 직접 조회·추출(Bulk Export)하는 방식의 공격이었을 가능성을 시사합니다.
  • 회원 조회·본인확인 관련 API의 인증/인가 로직 결함을 이용해 대량의 회원 레코드에 순차적으로 접근했을 가능성(IDOR, 과도한 페이지네이션 허용 등)도 배제할 수 없습니다.
  • 2025년 1월 침해가 약 1년 6개월간 미탐지 상태로 존재했다는 점은, 최초 침투 이후 공격자가 장기간 은닉하며 정보를 수집했거나, 혹은 별도의 침투 경로를 통한 독립적 사고였을 가능성을 모두 열어두고 조사해야 할 지점입니다.

Technical Vulnerabilities (취약점)

  • 접근통제 아키텍처 결함: 회원 정보 대량 조회·다운로드에 대한 임계치(Threshold) 기반 이상 탐지 및 Rate Limiting이 미비했을 가능성이 높습니다. 정상적인 서비스 트래픽 패턴에서는 발생하기 어려운 대량 조회 시도가 장기간 차단되지 않았다는 것은 접근통제 계층의 공백을 방증합니다.
  • 암호화 범위의 비일관성: 이름·연락처·비밀번호는 암호화되어 있었으나 이메일은 평문으로 저장·유출되었습니다. 이메일은 그 자체로 계정 식별자이자 피싱·크리덴셜 스터핑의 진입점이 되는 민감 식별정보임에도 암호화 대상에서 제외되어 있었던 것으로 보이며, 이는 개인정보 항목별 위험도 평가(Data Classification)가 충분히 이루어지지 않았음을 시사합니다.
  • 탐지·대응 프로세스의 공백: 2025년 1월 유출이 사고 발생 시점이 아닌 2026년 7월 사고의 원인 조사 과정에서 '소급 발견'되었다는 사실은, SIEM·이상행위 탐지체계가 구축되어 있었더라도 실효성 있게 운영되지 않았거나, 접속기록·로그 보존 및 정기 점검 주기가 침해 조기 탐지에 충분하지 않았음을 의미합니다.

3. Compliance Gap Analysis (법적·인증 기준 매칭)

규제 법령 위반 소지

  • 개인정보 보호법 제29조(안전조치의무): 접근통제, 암호화, 접속기록 보관·점검 등 기술적·관리적 보호조치 이행 수준에 대한 조사가 불가피하며, 이메일 등 일부 항목의 암호화 미적용은 안전조치의무 위반 소지로 검토될 수 있는 지점입니다.
  • 개인정보 보호법 제34조(유출 통지 등): 채비는 사고 인지 후 3영업일 이내 신고·통지 원칙에 부합하는 시점(7. 23. 인지 → 7. 26. 신고·통지)에 조치한 것으로 확인되며, 이후 2025년 1월 건에 대해서도 확인 즉시(7. 30.) 후속 통지한 점은 절차적으로 긍정적으로 평가될 수 있는 대응입니다.
  • 정보통신망법상 개인정보 보호조치 관련 조항 역시, 서비스가 웹·앱 기반으로 운영된다는 점에서 함께 검토 대상이 될 수 있습니다.

ISMS-P 인증 통제 항목 Gap

  • 2.6.2 접근통제: 회원 정보에 대한 비정상적 대량 조회·추출 행위를 제어하는 통제가 미흡했던 것으로 판단됩니다. 특히 관리자 권한 및 대량 데이터 조회 API에 대한 세분화된 접근 통제 정책 존재 여부가 심사 시 중점 확인 사항입니다.
  • 2.9.4 로그 및 접속기록 관리: 1년 6개월 전 발생한 유출이 자체 모니터링을 통해서가 아니라 별도 사고의 후속 조사 과정에서 발견되었다는 점은, 로그 보관 주기 및 정기적 로그 분석·이상탐지 프로세스의 실효성에 결함이 있었음을 시사합니다.
  • 2.10.1 침해사고 예방 및 대응: 침해사고 탐지 체계(SIEM, IDS/IPS 등)의 탐지 룰이 회원 DB에 대한 비정상 접근 패턴을 충분히 커버하지 못했을 가능성이 있으며, 이는 결함 사항으로 지적될 수 있습니다.
  • 2.5.3 사용자 인증: API 또는 관리자 계정에 대한 인증 강도(다단계 인증 적용 여부 등)를 재검토할 필요가 있습니다.

4. Mitigation Strategies (실무자를 위한 아키텍처 보완 대책)

[1] 개인정보 항목 전수 재분류 및 암호화 범위 확대: 이메일을 포함한 모든 식별·준식별 정보에 대해 중요도 기반 분류를 재수행하고, 암호화 미적용 항목을 최소화합니다. 특히 이메일과 같은 로그인 식별자는 검색 가능 암호화(Deterministic Encryption) 또는 토큰화(Tokenization) 적용을 검토합니다.

[2] API 계층 Rate Limiting 및 이상 탐지 강화: 회원 정보 조회·다운로드 API에 대해 사용자·IP·세션 단위의 임계치를 설정하고, 짧은 시간 내 대량 조회가 발생할 경우 자동 차단 및 실시간 경보가 발생하도록 WAF 정책을 튜닝합니다.

[3] 위험 기반 적응형 인증(Adaptive Authentication) 도입: 관리자 콘솔 및 대량 데이터 접근 권한을 가진 계정에 대해 접속 위치, 디바이스, 시간대 등 컨텍스트 기반 위험도를 평가하여 추가 인증을 요구하는 체계를 적용합니다.

[4] SIEM/UEBA 연동을 통한 상시 이상행위 탐지: DB 접근 로그, 애플리케이션 로그, 네트워크 트래픽을 통합 수집하고, 평시 트래픽 프로파일 대비 이상 편차(대량 Export, 비정상 시간대 접근 등)를 자동 탐지하는 SOC 탐지 룰을 구체화합니다.

[5] 로그 보존 주기 및 정기 점검 프로세스 재정비: 최소 1년 6개월 이상의 소급 조사가 가능하도록 접속기록의 보존 기간과 무결성을 확보하고, 분기 단위 이상행위 재점검(Retrospective Review) 프로세스를 도입하여 미탐지 침해의 조기 발견 가능성을 높입니다.

[6] 정기적 모의해킹 및 소스코드 보안 점검: SQL Injection, IDOR, 인증 우회 등 웹 애플리케이션 계층 취약점에 대한 정기 모의해킹과 시큐어코딩 점검(SAST/DAST)을 연 1회 이상 수행하고, 결과를 배포 파이프라인에 반영합니다.

[7] 네트워크 및 데이터베이스 접근 구간 분리: 서비스 서버와 회원 DB 간 접근을 망분리 및 최소 권한 원칙에 따라 재설계하고, DB 직접 접근이 가능한 계정을 최소화하며 모든 접근에 대한 감사 로그를 별도 저장소에 이중 보관합니다.

[8] 2차 피해 예방을 위한 사용자 공지·모니터링 체계 유지: 비밀번호 변경 유도, 피싱·스미싱 주의 안내와 더불어, 유출된 이메일을 대상으로 한 크리덴셜 스터핑 시도 여부를 로그인 실패 패턴 모니터링을 통해 지속 추적합니다.

5. Conclusion & Takeaway

이번 채비 사고는 최근 침해 자체보다도, 약 1년 6개월 전 발생한 별도 유출이 사후 조사 과정에서야 드러났다는 점에서 정보보호 거버넌스에 시사하는 바가 큽니다. 침해사고 대응은 '탐지된 사고를 얼마나 빨리 신고·통지하는가'뿐 아니라, '탐지되지 않은 침해를 얼마나 빨리 찾아낼 수 있는가'의 문제이기도 합니다. 조직의 보안 가시성(Visibility)은 실시간 이상 탐지뿐 아니라 장기 로그 보존과 주기적 소급 점검 역량까지 포함하는 개념으로 확장되어야 하며, 이를 통해 침해 발생 이후의 회복 탄력성(Resilience) 또한 실질적으로 확보될 수 있습니다. 유사한 회원 기반 서비스를 운영하는 조직이라면, 본 사고를 계기로 자사의 로그 보존 주기와 이상행위 탐지 룰이 '몇 개월 전'이 아닌 '몇 년 전' 침해까지 소급하여 발견할 수 있는 수준인지 점검해 볼 필요가 있습니다.

자료 출처

※ 본 리포트 작성 시점 기준 개인정보보호위원회의 과징금·과태료 의결 등 행정처분 결과는 아직 공개되지 않았으며, 관련 내용은 확정되는 대로 별도 업데이트가 필요합니다. 2번 항목(공격 벡터·기술적 결함)은 공식적으로 확인된 사실이 아니라, 공개된 정보를 토대로 한 보안 전문가 관점의 합리적 추정임을 명시합니다.

2026년 하반기 국내 정보보호 규제 환경은 통신 3사 중 두 곳(SKT, KT)이 연이어 대형 침해사고 제재를 받으며 새로운 국면에 진입했습니다. 특히 KT 사고는 단순한 해킹 침해를 넘어, 사고 은폐와 조사 방해라는 조직적 컴플라이언스 실패가 결합된 사례라는 점에서 실무자들이 반드시 벤치마킹해야 할 반면교사입니다. 타사의 Post-Mortem을 통해 자사의 접근통제 아키텍처와 침해사고 대응 프로세스의 공백을 점검하는 것은, 규제 리스크와 재무적 손실을 동시에 예방하는 가장 효율적인 방법입니다.

1. Incident Summary (사고 개요 및 규제 현황)

구분 내용
사고 인지 시점 2025년 8월 이용자 무단 소액결제 민원 다수 접수
실제 침해 기간 2024년 10월 ~ 2025년 9월 (약 11개월간 비인가 접속 지속)
별건 악성코드 감염 2024년 3월 KT 로밍렌탈서비스 홈페이지 취약점을 통한 침투
개인정보위 의결 2026년 7월 29일 제15회 전체회의
처분 발표 2026년 7월 30일

KT는 내부망에 접속하는 펨토셀에 대해 접속 인터넷프로토콜(IP)을 제한하지 않아 타사나 해외 IP로도 접속 가능하도록 운영했고, 개인정보처리시스템에 대한 접근통제 관리를 소홀히 하는 등 안전조치 의무를 위반했습니다. 해커는 유실된 KT 펨토셀에서 인증서를 추출한 뒤 자체 제작한 펨토셀에 이를 삽입해 KT 이동통신망에 접속했고, 이후 이용자의 스마트폰이 해커가 만든 펨토셀을 경유하도록 유도해 단말과 KT 내부망 간 송수신 정보를 가로챘습니다.

침해 유형 및 자산

  • 1차 사고(펨토셀 해킹): 가입자식별번호, 단말기식별번호, 전화번호 등이 유출되었습니다.
  • 2차 사고(악성코드/BPFDoor): 해커는 KT 로밍렌탈서비스 홈페이지 취약점을 이용해 내부망에 침투한 뒤 악성코드를 설치했고, 관리자 페이지에 대한 SQL 삽입 공격을 통해 KT 임직원과 협력사 직원 일부의 이름과 전화번호, 계정 정보 등을 조회·유출한 정황이 확인되었습니다. 2024년 3월 KT 네트워크 내 38대 서버가 해킹으로 악성코드에 감염된 사실이 확인되었으며, 과학기술정보통신부 민관합동조사단은 지난해 12월 29일 KT 서버 41대가 감염됐다고 발표한 바 있습니다.

피해 Scale
IMSI·IMEI·휴대전화 등 1만6,647명 정보가 유출되었으며, 368명이 2억4,000만원 규모의 소액결제 피해를 입었습니다.

법적 행정처분
개인정보보호위원회는 개인정보보호법을 위반한 KT에 539억 7,900만 원의 과징금을 부과하고, 처분 결과를 홈페이지에 공표하도록 의결했습니다. 개인정보위는 유사사고 재발 방지를 위해 펨토셀 등 무선통신망 장비에 대한 취약점 점검 및 통신망 내 개인정보에 대한 불법적인 접근통제 등 안전조치를 강화하는 한편, 회사 전반의 개인정보 처리 업무에 대해 개인정보 보호책임자(CPO)의 책임과 역할을 명확히 하는 등 거버넌스 체계를 정비할 것을 시정명령했습니다. 또한 'ISMS-P 유지' 관련 논의와 함께, 인증 범위를 이동통신 네트워크까지 확대하도록 권고했습니다.

특히 조사 방해 행위에 대해서는 별도 제재가 병과되었습니다. KT 조사 과정에서 거짓 자료를 제출하고 자료를 뒤늦게 제출하는 등 위원회 조사를 실질적으로 방해한 행위에 대해서는 고발하기로 결정했습니다.

과징금 산정 근거 (타사 대비 벤치마크)

동종 사고 대비 규모가 상대적으로 작은 배경에는 명확한 산정 로직이 있습니다. 개인정보보호법에 따른 유출사고 과징금 부과 시 해당 유출 사건과 관련 없는 매출은 제외하고 직접 관련된 매출의 최대 3%까지 범위 내에서 결정하며, KT의 지난해 이동통신사업 매출액은 약 6조 8000억원으로 실제 부과된 과징금은 약 0.8% 수준입니다. 개인정보위는 무단 소액결제 사고가 발생한 KT 이동통신서비스의 5G·LTE 통신 매출을 기준으로 과징금을 산정했고, 인터넷TV·인터넷통신 등 관련 없는 독립적인 매출액은 제외했습니다. 법정 상한을 단순 적용하면 과징금 규모는 2,000억 원 수준이었습니다. 비교 참조로 SKT는 2324만4649명 이용자의 휴대전화번호, 가입자식별번호(IMSI), 유심 인증키 등 25종의 정보 유출로 1347억9100만원을 부과받았습니다.


2. Root Cause Analysis (공격 벡터 및 기술적 결함 분석)

TTPs (공격 기법)

① 펨토셀 인증서 탈취 및 리플레이 (1차 사고)
해커는 유실된 KT 펨토셀에서 인증서를 추출한 뒤 자체 제작한 펨토셀에 이를 삽입해 KT 이동통신망에 접속했습니다. 이는 물리적으로 탈취/유실된 엣지 장비의 인증서가 폐기·무효화(Revocation)되지 않고 유효 상태로 남아있었음을 의미하며, 공격자는 이를 이용해 정상 사업자 장비로 위장(Rogue Base Station)해 코어망에 접속할 수 있었습니다. 펨토셀 관리서버를 우회할 수 있는 경로가 존재했고, 셀 아이디 관리도 제대로 이뤄지지 않아 비인가 장비의 이상 접속을 탐지하거나 차단하는 체계를 갖추지 못했습니다.

② 취약점 기반 침투 및 SQL Injection (2차 사고)
해커는 2024년 3월 KT 로밍렌탈서비스 홈페이지 내 취약점을 이용해 네트워크에 침투한 뒤 'BPF도어(BPFDoor)'를 비롯한 악성코드 파일을 업로드해 다수 서버를 감염시켰습니다. BPF도어는 과거 SK텔레콤 해킹 사고 때 발견된 악성코드로 리눅스 OS 커널 기능인 '버클리 패킷 필터(BPF)'를 악용해 보안 솔루션 탐지를 회피하는 특징이 있습니다. 이후 관리자 페이지에 대한 SQL 삽입 공격을 통해 KT 임직원과 협력사 직원 일부의 이름과 전화번호, 계정 정보 등을 조회·유출했습니다.

Technical Vulnerabilities (취약점)

  • 접근통제 아키텍처 결함: KT는 내부망에 접속하는 펨토셀에 대해 접속 IP를 제한하지 않아 타사나 해외 IP로도 접속 가능하도록 운영했습니다. 이는 화이트리스트 기반 IP 필터링, 상호 인증(Mutual TLS), 인증서 폐기 목록(CRL/OCSP) 연동이라는 기본적인 통신 인프라 보안 통제가 부재했음을 뜻합니다.
  • 탐지 프로세스의 공백: 해커는 2024년 10월부터 2025년 9월까지 약 11개월 동안 별도 인증 절차 없이 KT 내부망에 접속했지만, KT는 이용자들의 소액결제 피해 민원이 제기된 이후에야 비정상 접속 사실을 인지했습니다. 11개월간 이상 접속을 탐지하지 못했다는 것은 네트워크 이상행위 프로파일링(UEBA) 및 SIEM 연동 모니터링 체계가 사실상 작동하지 않았음을 시사합니다.
  • 로그 보존 및 포렌식 대응력 부재: 사고 당시 네트워크 로그 등이 남아 있지 않아 감염 서버에서 처리하던 이용자 개인정보가 추가로 유출됐는지는 확인하지 못했습니다. 이는 SIEM/로그 보존 정책의 리텐션 기간 설정 미비 또는 로그 무결성 관리 체계의 결함으로 해석됩니다.

3. Compliance Gap Analysis (법적·인증 기준 매칭)

규제 법령 위반

개인정보보호법 제29조(안전조치의무)를 정면으로 위반한 사례로 판단됩니다. 개인정보위는 KT가 내부망에 접속하는 펨토셀에 대해 접속 IP를 제한하지 않고, 개인정보처리시스템에 대한 접근통제 관리를 소홀히 하는 등 안전조치 의무를 위반했다고 판단했습니다. 아울러 개인정보위는 이를 '중대한 위반'으로 판단하고 무선통신망 장비 보안 강화와 개인정보 보호 거버넌스 개선을 명령했습니다.

별도로 조사 방해 행위 자체가 새로운 규제 강화의 트리거가 되었다는 점도 주목할 필요가 있습니다. 정부는 올해 안에 개인정보보호법을 개정해 조사 착수 전 증거은닉·폐기에 대한 형사처벌 규정을 마련하고, 증거 은닉·폐기 시 전체 매출액의 3% 과징금을 부과하는 방안을 추진하기로 했습니다.

ISMS-P 인증 통제 항목 Gap (심사원 관점 결함 사항)

본 사고를 ISMS-P 인증기준 관점에서 재구성하면 다음과 같은 결함 사항(Deficiency)이 도출됩니다.

  • 2.6.2 정보시스템 접근: 펨토셀 등 코어망 연동 장비에 대한 접속 IP 대역 미제한은 서버·네트워크 장비 접근 시 안전한 접속수단 또는 인증수단을 적용해야 한다는 통제 취지에 정면으로 배치됩니다.
  • 2.6.3 응용프로그램 접근: 로밍렌탈서비스 관리자 페이지의 SQL Injection 취약점 노출은 응용프로그램의 사용자 인증·권한 관리 및 입력값 검증 통제의 결함에 해당합니다.
  • 2.9.1 변경관리 / 2.9.4 로그 및 접속기록 관리: 펨토셀 관리서버를 우회할 수 있는 경로가 존재했다는 점은 시스템 변경·형상관리 프로세스가 정보보호 담당 조직의 검토 없이 우회 경로를 방치했음을 의미하며, 11개월간 이상행위를 탐지하지 못한 것은 로그 분석·모니터링 체계의 실효성 결함입니다.
  • 2.10.1 침해사고 예방 및 대응체계 구축, 2.10.2 취약점 점검 및 조치: KT가 2024년 악성코드 감염 사실을 인지했음에도 정부에 침해 사실을 신고하지 않고 자체 조치만 진행한 것은 침해사고 대응 절차의 법적 신고 의무 이행 통제가 형해화된 사례입니다.
  • 2.5.1 사용자 계정 관리 / 2.5.6 접근권한 검토: KT가 지난해 4월 악성코드 감염 여부를 전수 점검하는 과정에서 침해 서버 10대의 로그를 삭제한 정황은 사고대응 증적 관리 및 무결성 통제의 심각한 결함이며, 심사원 관점에서는 '결함'을 넘어 인증 취소 사유에 해당할 수 있는 중대사안입니다.

4. Mitigation Strategies (실무자를 위한 아키텍처 보완 대책)

[1] 펨토셀/엣지 장비 인증서 라이프사이클 관리 강화: 장비 유실·도난 신고 즉시 인증서를 자동 폐기(CRL/OCSP 실시간 반영)하는 프로세스를 구축하고, 상호 인증(Mutual TLS) 기반 장비 인증 체계로 전환합니다.

[2] Zero Trust 기반 코어망 접근통제: 펨토셀-코어망 연동 구간에 화이트리스트 기반 IP 필터링과 마이크로세그멘테이션(Microsegmentation)을 적용하여, 인가되지 않은 국가/ISP 대역의 접속을 원천 차단합니다.

[3] 이상 접속 탐지를 위한 SOC 탐지 룰 세팅: 셀 ID·장비 식별자 기반 베이스라인을 수립하고, 신규/미등록 장비의 코어망 접속, 비정상 트래픽 패턴에 대한 실시간 알람 룰을 SIEM에 등록합니다. 11개월간 미탐지된 사례를 반면교사 삼아 UEBA(사용자·개체 행위분석) 도입을 검토합니다.

[4] WAF 및 시큐어 코딩 정책 튜닝: 로밍렌탈서비스와 같은 대외 노출 웹 애플리케이션에 대해 SQL Injection 등 OWASP Top 10 기반 공격 패턴 탐지 룰을 WAF에 적용하고, 정기 취약점 진단(모의해킹)을 의무화합니다.

[5] 위험 기반 적응형 인증(Adaptive Authentication) 적용: 소액결제와 같은 고위험 거래에는 디바이스 핑거프린팅, 위치 기반 이상거래탐지(FDS)를 결합한 적응형 인증을 적용하여 2차 피해를 조기에 차단합니다.

[6] 로그 무결성 및 보존 체계 강화: 로그 삭제·변조가 불가능하도록 WORM(Write Once Read Many) 스토리지 또는 중앙집중형 로그 서버(원격 로깅)를 도입하고, 최소 보존 기간을 법정 기준 이상으로 설정합니다.

[7] 침해사고 신고 및 에스컬레이션 프로세스 정비: 악성코드 감염 등 침해 징후 인지 시 자체 판단으로 은폐하지 않고, 법정 신고 기한 내 관계기관 신고를 의무화하는 내부 통제 프로세스와 CPO 직속 보고 체계를 구축합니다.

[8] ISMS-P 인증 범위 확대: 이동통신 네트워크 영역까지 ISMS-P 인증 범위를 확대하여, 코어망·펨토셀 등 그간 인증 사각지대에 있던 인프라에 대한 정기 심사 통제를 적용합니다.


5. Conclusion & Takeaway

KT 사고는 단일 취약점이 아니라, 접근통제·탐지·사고대응이라는 3단계 방어선이 순차적으로 실패한 전형적인 사례입니다. 더 나아가 사고 인지 후 신고·로그 보존이라는 최소한의 절차적 의무마저 이행하지 않은 점은, 기술적 방어체계 못지않게 조직의 거버넌스와 윤리적 대응 문화가 규제 리스크에 직결됨을 보여줍니다. 흥미로운 점은 과징금 산정에 있어 유출 규모 자체보다 2차 피해(무단 소액결제) 발생 여부와 관련 매출 범위가 결정적 변수로 작용했다는 것으로, 이는 향후 유사 사고 대응 시 피해 확산 차단(Containment) 속도가 곧 재무적 리스크 경감으로 직결된다는 시사점을 남깁니다. 조직의 보안 가시성(Visibility)과 사고 발생 후 투명한 대응을 통한 회복 탄력성(Resilience) 확보가, 결국 규제 리스크와 평판 리스크를 동시에 관리하는 핵심 축임을 다시 한번 확인시켜 준 사례라 하겠습니다. 실무 현장에서 유사한 통신·엣지 인프라 접근통제 이슈를 겪고 계신 분들의 의견과 사례를 함께 나누고 싶습니다.

자료 출처

안녕하세요.

출근길에는 세상 돌아가는 뉴스나 영상을 보며 바쁘게 움직이지만, 퇴근길만큼은 조금 다른 조용함을 즐깁니다. 주로 자전거를 타고 퇴근하는 편인데, 페달을 밟으며 귀를 채우기에는 팟캐스트만 한 동반자가 없더군요.

벌써 팟캐스트를 들은 지도 10년이 넘었습니다. 그동안 여행, 술, 커피, 종교 등 다양한 분야를 전전하다가, 요즘은 확실히 교양 분야에 정착했습니다.

제 블로그를 보시는 분들 중 취향이 비슷한 분이 있다면 참고해 보셔도 좋겠습니다. 다만 대중적인 메이저 방송보다는 소소하고 마이너한 채널이 대부분이라는 점은 감안하고 봐주시기 바랍니다.


1. 책잡힌 사이 : 독서모임장들

평소 직업 특성상 IT나 보안 관련 기술 서적만 딱딱하게 읽다 보니, 문학이나 인문학 같은 다른 분야의 책에 갈증이 있었습니다. 즐겨 듣던 소설 방송이 종영되어 아쉬웠던 차에, 회사 신규 입사자 소개 자리에서 운영자이신 세실 님이 본인 방송이라고 소개해 주셔서 접하게 되었습니다.

소설을 포함해 아주 광범위한 분야의 책을 다룹니다. 서로 다른 분야의 독서모임장 세 분이 진행하는데, 확실히 내공이 있어서 그런지 매끄럽고 깔끔합니다. 왠지 어렵게만 느껴졌던 독서모임에 나도 한번 참여해 보고 싶다는 생각이 들게 만듭니다. 나아가 내 전문 분야를 살려 팟캐스트를 한번 개설해 볼까 하는 기분 좋은 자극을 주는 방송이기도 합니다.


2. [공기톡] 공부하기 기찮은 사람들을 위한 친절한 지식 톡

네 분의 진행자가 정말 다양한 주제를 다룹니다. 과학보다는 인문학이나 사회과학 분야 비중이 높습니다. 각자 본인의 전문 분야에 대해 깊이 있게 공부한 내용을 발표하는 식인데, 청취자가 이해하기 쉽게 풀어주는 능력이 탁월합니다.

아래에 소개할 '지지익선'의 정주행을 마치고 새로운 교양 채널을 찾다가 정착했는데, 마음에 들어서 벌써 세 번이나 정주행했습니다. 개인적으로는 '조변 님'의 K시리즈를 가장 좋아합니다. 여러 주제를 하나의 소설처럼 엮어내는데, 일부 에피소드는 진행자들이 함께 연기하는 라디오 소설 형태로 진행되어 몰입감이 좋습니다.


3. 재즈가 알고싶다

앞서 소개한 채널들이 넓고 얕은 지식을 다룬다면, 이 방송은 조금 더 전문적입니다. 실제 강의를 하시는 재즈 전문가들이 직접 진행합니다.

귀를 즐겁게 하는 연주 자체도 훌륭하지만, 그 음악에 얽힌 비하인드 스토리나 진행자들의 담백한 입담이 매력적입니다. 퇴근길 밤바람을 맞으며 듣기에 이만한 방송이 없습니다.


4. 개별교양환승센터

'공기톡'과 비슷한 시기에 발굴한 교양 팟캐스트입니다. 현재는 종영된 상태지만, 시의성을 타는 주제들이 아니라서 지금 언제 아무 에피소드나 골라 들어도 괜찮습니다.

공기톡에 비하면 전체적으로 분위기가 젊고 가벼운 편입니다. 다양한 주제를 어렵지 않게 툭툭 던져주듯 다뤄서, 퇴근길에 복잡한 생각 없이 편하게 귀동냥하기 좋습니다.


5. 지지익선

팟캐스트를 처음 듣기 시작한 초창기부터 함께한 채널입니다. 당시 메인 화면에 '암호'에 관한 에피소드가 뜬 것을 보고 호기심에 들어갔다가 구독하게 되었습니다.

학술적인 전문성보다는 본인이 공부한 내용을 가볍게 공유하는 느낌에 가까워서 부담 없이 들을 수 있었습니다. 가장 아끼던 방송이었는데 종영되어 개인적으로 참 안타까운 마음이 듭니다.


6. 요즘 소설 이야기

친구가 진행하는 방송이라 듣기 시작했습니다. 라디오 PD와 문학서점 주인장이 소설을 주제로 엮어가는 방송이었습니다.

업무 특성상 항상 메마르고 딱딱한 IT 세상에 갇혀 지내는데, 이 방송을 들을 때면 "나도 예전엔 저런 감수성을 느끼던 때가 있었지" 하며 일상에서 잠시 벗어나 환기할 수 있었습니다. 제게는 일종의 힐링 방송이었는데, 지금은 종영되어 아쉬움이 남습니다.

 

간혹 영어 공부 삼아 '코리아헤럴드'도 틀어두긴 합니다만, 퇴근길 자전거 위에서 편하게 들을 수 있는 수준은 아니라 마음의 여유가 아주 많을 때만 간간이 엽니다.

지나고 보니 팟캐스트와 함께한 시간도 벌써 10년이 넘었습니다. 예전에는 여행, 술, 커피 관련 방송도 자주 들었지만 요즘은 확실히 교양 쪽으로 취향이 좁혀지네요. 퇴근길 페달을 밟는 시간이 덕분에 심심하지 않습니다.

여러분은 주로 출퇴근길에 어떤 콘텐츠를 들으시는지 궁금합니다. 괜찮은 채널이 있다면 댓글로 공유해 주셔도 좋겠습니다. 안전한 퇴근길 되세요.

+ Recent posts