세상 바라보기

시작은 이랬습니다

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

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 (사고 개요 및 규제 현황)

사고경위

침해 유형 및 자산

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

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

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

피해 Scale

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

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) 또한 실질적으로 확보될 수 있습니다. 유사한 회원 기반 서비스를 운영하는 조직이라면, 본 사고를 계기로 자사의 로그 보존 주기와 이상행위 탐지 룰이 '몇 개월 전'이 아닌 '몇 년 전' 침해까지 소급하여 발견할 수 있는 수준인지 점검해 볼 필요가 있습니다.

자료 출처

• 채비(CHAEVI) - [공지] 개인정보 유출 사과 공지 안내(2026. 07)
• 채비(CHAEVI) - [공지] 개인정보 유출 관련 추가 안내(2026. 07)

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

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

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

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) 확보가, 결국 규제 리스크와 평판 리스크를 동시에 관리하는 핵심 축임을 다시 한번 확인시켜 준 사례라 하겠습니다. 실무 현장에서 유사한 통신·엣지 인프라 접근통제 이슈를 겪고 계신 분들의 의견과 사례를 함께 나누고 싶습니다.

자료 출처

• ZDNet Korea - KT 개인정보 유출 과징금 540억원…LGU+ 증거인멸 수사의뢰(2026.07)
• ZDNet Korea - KT 540억·SKT 1348억…개인정보 유출 과징금, 왜 차이났나(2026.07)
• 한국일보 - 개인정보위 '무단소액결제' KT에 과징금 540억 원(2026.07)
• 헤럴드경제 - KT, 개인정보 유출 과징금 '540억' 처분(2026.07)
• 아시아경제 - SKT의 40% 수준…KT 과징금 540억원 어떻게 나왔나(2026.07)
• 파이낸셜뉴스 - 개인정보 유출-조사방해 KT, 539억 과징금에 고발까지(종합)(2026.07)
• 한국일보 - 1만6000명 개인정보 털린 KT… '539억 과징금' 철퇴(2026.07)
• 뉴스웨이 - '개인정보 유출' KT···개보위, 과징금 약 540억원 부과(2026.07)
• 아이티데일리 - '펨토셀 해킹' KT에 과징금 540억…조사 방해 행위는 고발(2026.07)
• 보안뉴스 - SKT, 개인정보 유출 과징금 1347억원 취소 소송 제기(2026.01)

안녕하세요.

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

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

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

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

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

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

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

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

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

3. 재즈가 알고싶다

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

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

4. 개별교양환승센터

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

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

5. 지지익선

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

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

6. 요즘 소설 이야기

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

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

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

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

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

최근 정부 유관 기관 및 대규모 공공 프로젝트를 타깃으로 한 공급망(Supply Chain) 기반의 위협과 API 취약점 악용 사례가 고도화되고 있습니다. 특히 중소벤처기업부와 창업진흥원이 추진한 대국민 창업 프로그램인 '모두의 창업' 플랫폼에서 발생한 데이터 유출 사고는 외부 조직에 의한 전통적인 침해 공격이 아닌, 내부 프로젝트 참여 수탁 업체(파트너사)에 의한 비정상적 API 호출 및 데이터 크롤링을 통해 발생했다는 점에서 강력한 기술적·관리적 시사점을 던져줍니다.

타사 침해 사례의 사후 분석(Post-Mortem)을 통해 서비스 Front-End 단계의 통제에만 의존하는 아키텍처의 한계를 짚어보고, 실무자가 자사 인프라에 즉시 반영해야 할 방어 체계와 컴플라이언스 통제 포인트를 도출하고자 합니다.

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

• 사고경위:

  일시 (2026년)	사건 내용	비고
  6월 15일 09:00	1차 합격자 프로필 공개 후, 프로젝트 참여 AI 솔루션 업체가 비정상적 API 호출 및 크롤링 시작	침해 발생 시점
  6월 15일 16:00	취약점이 노출된 서버 API 인가 차단 및 자동 수집 기능 방어 조치 적용	1차 긴급 조치
  6월 18일 전후	정보주체 통지(문자 발송) 및 국가사이버안보센터 등 외부 전문기관 합동 조사 착수	지연 통지 논란 제기

• 침해 유형 및 자산:
  • 침해 유형: API 접근 통제 우회(BOLA/BFLA), 내부 인가 업체에 의한 무단 웹 크롤링 및 데이터 마이닝.
  • 자산 영역: 플랫폼 웹/앱 API 서버 영역(도전자 프로필, 심사평, 아이디어 관리 컴포넌트).
  • 유출 데이터 항목: 화면상 비공개 설정된 참가자 개인 이메일 주소, 심사평, 창업 아이디어 요약본, 자기소개 등. (단, 실명 및 휴대전화 번호 등의 타 고유식별정보 유출은 현재까지 미확인)

• 피해 Scale: '모두의 창업' 1기 합격자 및 선정자 전원인 5,000명의 정보주체 데이터 유출.
• 법적 행정처분:
  • 현재 국가사이버안보센터 등 전문기관과 협력하여 기술 침해 사고 조사가 진행 중이며, 개인정보보호위원회의 정식 조사가 불가피할 것으로 전망됩니다.
  • 안전성 확보조치 미비(보안 취약점 방치, 접근통제 실패) 및 인지 후 지체 없는 유출 통지 위반 여부에 따라 위반 행위별 과태료 처분 및 정밀 시정명령 조치가 내려질 것으로 분석됩니다.

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

• TTPs (공격 기법):
  이번 사고의 주 공격 벡터(Threat Vector)는 외부 해킹 툴을 이용한 침투가 아니라, Insecure API Endpoints와 BOLA(Broken Object Level Authorization) 취약점의 결합입니다. 플랫폼 아키텍처상 Front-End(웹 UI) 화면에서는 사용자가 설정한 '비공개' 옵션에 따라 해당 데이터가 보이지 않도록 필터링 기능을 구현하였으나, 정작 Back-End API 서버 단에서는 적절한 접근 권한 검증(Authorization) 없이 해당 Object 데이터를 JSON 등의 페이로드(Payload)에 그대로 담아 리턴하는 구조적 결함이 있었습니다. 공격 주체(참여 AI 솔루션 업체)는 도전자 프로필 및 심사평을 호출하는 특정 API의 식별자 매개변수를 순차적으로 변조(Parameter Tampering) 및 호출하는 자동화 봇 기반의 웹 크롤링을 수행하여 대량의 비공개 데이터를 수집했습니다.
• Technical Vulnerabilities (취약점):
  • 접근통제 아키텍처 결함 및 데이터 과도 노출 (Excessive Data Exposure): Front-End 단에서의 화면 차단(UI-level hiding)에만 의존하고, 실제 Back-End API 레벨에서 요청자의 권한에 따른 필드 단위 데이터 마스킹 및 스코프(Scope) 격리 통제를 누락했습니다.
  • Rate Limiting 및 자동화 봇 탐지 미비: 단시간 내에 5,000명에 달하는 대규모 합격자 데이터 API를 순차적·연속적으로 호출하는 비정상 트래픽 패턴이 발생했음에도 불구하고, 임계치 설정 오류 또는 API Rate Limiting 통제가 작동하지 않아 대량의 크롤링 행위를 사전에 차단하지 못했습니다.
  • 공급망 위협 관리 및 SIEM 연동 공백: 내부 파트너사(수탁사) 계정 및 연동 인프라로부터 유입되는 내부 트래픽을 신뢰 대상으로만 오인하여, 이상 행위 프로파일링(Anomaly Detection) 및 실시간 SIEM(보안 정보 및 이벤트 관리) 경보(Alert) 시스템의 공백이 존재했던 것으로 유추됩니다.

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

• 규제 법령 위반 (개인정보 보호법 기준):
  • 제29조 (안전성 확보조치): 개인정보처리자는 개인정보가 분실·도난·유출·위조·변조 또는 훼손되지 아니하도록 대통령령으로 정하는 바에 따라 안전성 확보에 필요한 기술적·관리적 및 물리적 조치를 하여야 합니다. 서버 API 단의 취약점을 방치하여 비공개 정보가 무단 크롤링되도록 허용한 점은 안전성 확보조치 위반(고시 제4조 접근통제 중심)에 매칭됩니다.
  • 제34조 (개인정보 유출 통지 등): 유출을 오전에 인지했음에도 대외 통지 및 관계기관 신고 과정에서 수십 시간의 Gap이 발생했다면, "지체 없이(24시간 이내)" 통지해야 하는 법적 타임라인 준수 여부에 대해 Compliance 위반 지적을 받을 소지가 매우 높습니다.

• ISMS-P 인증 통제 항목 Gap 분석:
  • 2.6.2 (접근통제): "정보시스템과 개인정보처리스템에 접근할 수 있는 권한을 최소한으로 부여하고... 권한 없는 접근을 통제해야 한다." 화면상 비공개된 데이터가 API 다이렉트 호출로 평문 획득이 가능했다는 점은 명백한 결함 사항(지적 사항)입니다.
  • 2.10.1 (침해사고 예방 및 대응): "외부 위협뿐만 아니라 내부 위협, 웹 크롤링 등의 이상 징후를 모니터링할 수 있는 체계를 수립·운영해야 한다." 인가된 협력 업체의 대량 API API 마이닝 행위를 실시간 탐지·차단하지 못한 통제 공백이 존재합니다.
  • 2.1.3 (수탁자 관리): "개인정보 처리업무를 위탁하는 경우 수탁자를 감독하고 교육해야 한다." 사업 참여 AI 솔루션 업체의 무단 정보 수집 행위는 협력업체/수탁자 보안 관리 체계의 치명적인 Gap을 방증합니다.

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

이와 같은 공급망 기반 API 우회 유출 사고를 원천 예방하기 위해, 실무자는 운영 중인 시스템 아키텍처에 아래의 기술적 보안 통제를 즉시 검토 및 반영해야 합니다.

[1] Zero Trust 기반 API Gateway 권한 검증 (BOLA 방어)

• Front-End의 숨김 처리에 의존하지 말고, API Gateway 및 Back-End 라우터 단에서 요청자의 세션 토큰(JWT 등) 내 사용자 권한 스코프를 조회 대상 Object ID와 상호 매핑 검증하는 로직을 필수로 구현해야 합니다.
• API 응답 데이터 세트(Response Payload) 구성 시, 필요 최소한의 데이터 필드만 선택적으로 직렬화(Serialization)하여 반환하는 화이트리스트 기반 Data 이그레스(Egress) 필터링을 적용합니다.

[2] 인프라 전반의 적응형 Rate Limiting & 쓰로틀링(Throttling) 정책 적용

• 특정 IP, 특정 API 토큰, 혹은 동일 서브넷으로부터 인입되는 API 요청에 대해 초당/분당 최대 요청 임계치(예: 분당 최대 60회 제한)를 설정하는 Rate Limiting을 필수 적용합니다.
• 특히 프로필 조회, 자산 내려받기 등 대량의 개인정보 결합이 가능한 Endpoint에는 가중치를 높게 부여하여 누적 요청 발생 시 세션을 즉시 차단(Drop) 또는 챌린지(CAPTCHA 등) 페이지로 리다이렉트 시킵니다.

[3] 수탁사 및 서드파티 연동 파트너 대상 '최소 권한(Least Privilege)' 적용

• 프로젝트에 참여하는 협력업체나 AI 솔루션 연동용 API Key는 일반 사용자 API와 인프라 단에서 물리적·논리적으로 격리(Network Segmentation)해야 합니다.
• 수탁사 전용 API Endpoints를 별도 개설하고, 해당 파트너사가 비즈니스 목적상 접근해야 하는 데이터 격리 스코프 외의 데이터(예: 이메일, 심사평 전체 데이터셋 등)에 접근을 시도할 경우 즉시 HTTP 403 Forbidden을 반환하도록 아키텍처를 세분화합니다.

[4] AI 기반 봇/크롤링 탐지 및 WAF 행동 프로파일링 활성화

• 웹 애플리케이션 방화벽(WAF) 및 웹 안티봇(Anti-Bot) 솔루션을 연동하여 헤더 정보 변조, Payload 구조 분석, 요청 주기 간격 등을 실시간 분석합니다.
• 정상적인 브라우저 접근이 아닌 스크립트 기반(Python, Node.js, 웹 크롤러 등) 유입 트래픽 패턴을 탐지하여 API 스캐닝 공격 벡터를 실시간 방어합니다.

5. Conclusion & Takeaway

이번 중기부 '모두의 창업' 개인정보 유출 사고는 우리에게 매우 무거운 예방적 교훈을 줍니다. 보안 가시성(Visibility)과 회복 탄력성(Resilience)은 단순히 외부 악성 해커의 방화벽 차단에 그치지 않고, "인가된 파트너사와 내부 연동 모듈조차 완전히 신뢰하지 않는다"는 제로 트러스트(Zero Trust) 거버넌스의 확립에서 시작됩니다.

특히 대외 서비스를 개발할 때 Front-End 디자인의 보안성에만 치중하고 Back-End API의 엄격한 데이터 필터링을 간과한다면, 서비스 오픈과 동시에 모든 자산이 크롤링 위협에 노출될 수 있습니다. 공급망 보안과 API 시큐리티 코딩, 그리고 이상 징후 실시간 모니터링 체계가 유기적으로 맞물려야만 진정한 Compliance 컴플라이언스를 달성할 수 있음을 명심해야 합니다.

자료 출처

• 아이뉴스24 - "'모두의 창업' 개인정보 유출, 프로젝트 참여업체 소행"
• 뉴스1 - "'모두의 창업' 정보 유출, 해킹 주체는 프로젝트 참여 기업"
• 연합뉴스 - "6만명 몰린 정부 초대 창업 프로젝트…개인정보 유출로 '오점'"