月光愛靑狼

1. 개요

• 6월 8일, 루이비통코리아의 시스템이 해킹을 당해 일부 고객 개인정보가 유출되는 사고가 발생했습니다.
• 회사는 7월 2일에 해당 사고를 인지하고, 7월 3~4일 공식 홈페이지와 언론을 통해 사실을 알렸습니다.
• 이번 사고는 디올, 티파니, 까르띠에 등 글로벌 명품 브랜드에서 연이어 발생한 해킹 및 개인정보 유출 사건의 연장선상에서 발생했습니다.

2. 피해범위

• 유출된 정보는 일부 고객에 한정되며, 정확한 피해 인원이나 규모는 공개되지 않았습니다.
• 루이비통 측은 "고객마다 유출된 항목이 다를 수 있다"고 밝혔으나, 전체 고객 데이터베이스가 아닌 일부에 국한된 것으로 파악됩니다.

3. 유출항목

• 이름, 성, 연락처(전화번호), 이메일, 우편 주소, 생년월일, 국가, 구매·선호 데이터 등 고객이 제공한 추가 정보가 포함될 수 있습니다.
• 비밀번호, 신용카드 정보, 은행 계좌 정보 등 금융정보는 유출되지 않음을 공식적으로 밝혔습니다.

4. 원인

• 권한 없는 제3자가 시스템에 일시적으로 접근하여 고객 정보가 유출되었습니다.
• 구체적인 해킹 방식은 공개되지 않았으나, 최근 명품 브랜드를 겨냥한 해킹 시도가 집중적으로 발생하고 있습니다.
• 보안 업계에서는 명품 브랜드의 고객 정보가 구매력 높은 소비자 데이터로서 해커들의 표적이 되고 있다고 분석하였습니다.

5. 대응

• 사고 인지 후 즉시 시스템 차단 및 기술적 조치 시행하였습니다.
• 관계 당국(개인정보보호위원회 등)에 사고 사실을 통지하고 조사에 협조 중이라고 합니다.
• 고객들에게는 예상치 못한 연락이나 의심스러운 커뮤니케이션에 주의할 것을 안내하였습니다.
• 시스템 보안 강화 및 사이버 보안 전문가와의 협력을 진행 중이라고 합니다.

6. 문제점

• 늑장 인지 및 공지: 사고 발생(6월 8일)과 공식 인지(7월 2일) 사이에 약 한 달의 시차가 발생, 피해 고객에 대한 신속한 안내가 부족한 것으로 보여집니다.
• 피해 규모·경로 비공개: 구체적인 피해 범위와 유출 경로, 인원 등은 공개되지 않아 소비자 불안이 가중되고 있습니다.
• 반복되는 명품업계 해킹: 디올, 티파니, 까르띠에 등 LVMH 산하 브랜드에서 연이어 유사 사고가 발생, 업계 전반의 보안 취약성이 지적되고 있습니다.
• 소극적·비공개적 대응: 피해 고객에 대한 개별 통보 외에 구체적 설명이나 투명한 정보 공개가 부족하다는 비판이 있습니다.

[ 민관합동조사단 조사결과 ]

▷ (조사방식) 국내 1위 통신사의 침해사고, 국민 우려 증가, 악성코드의 은닉성 등을 고려하여 SK텔레콤 전체 서버(42,605대) 대상 점검

▷ (감염 현황) 감염서버 총 28대, 악성코드 총 33종 확인 및 조치

※ ①이번 침해사고와 연관성은 없으나 공급망보안 관리 취약으로 악성코드 1종이 SK텔레콤 서버 88대에 유입 확인, ②‘22.2월 SK텔레콤에서 악성코드 2종 자체 조치

▷ (정보유출 규모) 유심정보 25종 유출(9.82기가바이트<GB>, 가입자 식별번호<IMSI> 기준 2,696만건)

▷ (사고 원인 및 문제점) SK텔레콤의 계정정보 관리 부실, 과거 침해사고(‘22.2월) 대응 미흡, 주요 정보 암호화 조치 미흡 등을 원인으로 파악

▷ (재발방지 대책) 계정 비밀번호 관리 강화, 주요 정보 암호화, 정보보호 관리체계(거버넌스) 강화(최고경영자<CEO> 직속), 정보보호 인력·예산 확대 등

(중간 생략)

과학기술정보통신부(장관 유상임, 이하 “과기정통부”)는 SK텔레콤 침해사고 민관합동조사단(이하 “조사단”)의 조사 결과 및 SK텔레콤의 이용약관 상 위약금 면제 규정에 대한 검토결과를 7월 4일(금)에 발표하였다.

Ⅰ. SK텔레콤 침해사고 원인분석 및 재발방지 대책

지난 4.18일 23시 20분, SK텔레콤은 평소 대비 대용량 데이터가 외부로 전송된 정황을 인지하고, 4.20일 16시 46분, 한국인터넷진흥원(원장 이상중)에 침해사고를 신고하였다.

※ 정보통신망법 상 사고인지 시점부터 24시간 이내에 신고를 해야 하며, 이를 위반 시 3천만원 이하 과태료 부과 대상

과기정통부는 SK텔레콤의 유심정보 유출을 중대한 침해사고로 판단하고 4.23일 민관합동조사단을 구성하여 피해현황, 사고원인 등을 조사하였다.

1. 조사 방식

조사단은 이번 SK텔레콤 침해사고가 ①국내 1위 이동통신사의 침해사고, ②유심정보 유출로 인한 휴대폰 부정 사용 등 국민 우려 증가, ③악성코드의 은닉성 등을 고려하여 전체 서버 42,605대를 대상으로 BPFDoor 및 타 악성코드 감염여부에 대해 강도 높은 조사(4.23~6.27)를 시행하였다.

또한, 조사 과정에서 확인된 감염서버는 디지털 증거수집(포렌식) 등 정밀분석을 통해 정보유출 등 피해발생 여부를 파악하였다.

2. 감염서버 및 정보유출 규모

조사단은 이번 침해사고로 공격받은 총 28대 서버에 대한 디지털 증거수집(포렌식) 분석 결과, BPFDoor 27종을 포함한 악성코드 33종*을 확인하였다.

* BPFDoor 27종, 타이니쉘 3종, 웹쉘 1종, 공개 소프트웨어(오픈소스) 악성코드 2종(CrossC2 1종, 슬리버 1종)

확인된 악성코드 정보는 피해확산 방지를 위해 백신사, 경찰청, 국정원 등 주요 민간·공공기관에 공유하고, 악성코드 점검 지침(가이드)을 보호나라 누리집(www.boho.or.kr)을 통해 배포(조회수 : 약 12.9만건, 6.30일 기준)하였다.

유출된 정보는 전화번호, 가입자 식별번호(IMSI*) 등 유심정보 25종이며 유출 규모는 9.82기가 바이트(GB), 가입자 식별번호 기준 약 2,696만건이었다.

* International Mobile Subscriber Identity : 유심 내 저장되며, 통신사가 사용자 식별 시 사용

한편, 조사단은 감염서버 중 단말기식별번호(IMEI*), 개인정보(이름, 생년월일, 전화번호, 이메일 등)가 평문으로 임시 저장된 서버 2대와 통신기록(CDR**)이 평문으로 임시 저장된 서버 1대를 발견하였으나, 정밀 분석 결과 방화벽 로그기록이 남아있는 기간(단말기 식별번호<IMEI> : ‘24.12.3~’25.4.24, 통신기록<CDR> : ‘24.12.9~ ’25.4.20)에는 자료유출 정황이 없는 것을 확인하였다. 다만, 악성코드 감염시점부터 로그기록이 없는 기간(단말기 식별번호<IMEI> : ‘22.6.15~’24.12.2, 통신기록<CDR> : ‘23.1.31.~ ’24.12.8.)에는 유출여부를 확인하는 것이 불가능하였다.

* International Mobile Equipment Identity : 휴대전화 기기 식별 시 사용

** Call Detail Record : 통화 시간, 수발신자 전화번호 등 통신 활동 관련 정보

3. 사고 원인 분석

< 초기 침투(‘21.8월~) >

공격자는 외부 인터넷 연결 접점이 있는 시스템 관리망 내 서버A에 접속 후 타 서버에 침투하기 위해 원격제어, 백도어 기능 등이 포함된 악성코드(CrossC2)를 ’21.8.6일에 설치*하였다.

* 조사 과정에서 확인된 감염서버 중 가장 빠른 시기에 감염

당시 서버A에는 시스템 관리망 내 서버들의 계정 정보(ID, 비밀번호 등)가 평문으로 저장되어 있었으며 공격자는 동 계정정보를 활용해 시스템 관리망 내 타 서버(B)에 접속한 것으로 추정*된다.

* (추정근거) 서버 A에 평문으로 저장된 ID, 비밀번호를 활용해 서버 B에 접속한 로그기록은 남아있지 않으나, 동일한 ID, 비밀번호로 시스템 관리망 내 타 서버에 접속한 기록을 확인하였음

또한, 당시 서버 B에는 코어망 내 음성통화인증(HSS*) 관리서버 계정정보가 평문으로 저장되어 있었으며, 공격자는 동 계정정보를 활용하여 음성통화인증 관리서버에 접속(’21.12.24) 후, 음성통화인증 관리서버 및 음성통화인증에 BPFDoor를 설치하였다(’21.12.24∼’22.1.1).

* Home Subscriber Server

< 추가 거점 확보(‘22.6월~) >

공격자는 시스템 관리망을 통해 고객 관리망 내 서버에 접속한 것으로 추정*되며, 서버 접속 후, 악성코드(웹쉘, BPFDoor)를 설치(’22.6.15, 6.22)하였다.

* (추정근거) 조사단은 공격자가 시스템 관리망과 고객 관리망 간 통신한 기록을 확인하였고, 이를 근거로 공격자가 시스템 관리망 내 감염서버에서 고객 관리망으로 접속이 가능한 것으로 판단

< 정보유출(‘25.4.18일) >

공격자는 초기 침투과정에서 확보한 계정 정보*를 활용하여 시스템 관리망 내 여러 서버에 추가로 악성코드를 설치하였다(’23.11.30∼’25.4.21).

* SK텔레콤은 시스템 관리망 내 서버의 계정 패스워드를 장기간 미변경(패스워드 만료일이 설정 되어있지 않고, 변경한 이력이 없는 것으로 확인)

이후 공격자는 ’25.4.18일 음성통화인증 3개 서버에 저장된 유심정보(9.82기가바이트<GB>)를 시스템 관리망 내 외부 인터넷 연결 접점이 있는 서버 C를 거쳐 유출하였다.

4. 문제점 및 재발방지 대책

조사단은 조사를 통해 SK텔레콤의 정보보호 체계에 문제점을 발견하고 재발방지 대책을 마련하였다.

< 유심정보 유출 관련 문제점 >

악성코드가 감염된 경위 및 침해사고 대처 등과 관련하여 SK텔레콤은 ①계정정보 관리 부실, ②과거 침해사고 대응 미흡, ③주요 정보 암호화 조치 미흡 등 3가지 문제점이 있었다.

① 계정 정보 관리 부실

SK텔레콤은 서버 로그인 ID, 비밀번호를 안전하게 관리*해야 하나 이번 침해사고에서 감염이 확인된 음성통화인증 관리서버(‘21.12.24, 12.30 감염) 계정정보를 타 서버에 평문으로 저장하였고, 조사단은 공격자가 동 계정정보를 활용해 음성통화인증 관리서버 및 음성통화인증을 감염시킨 것을 확인하였다.

* 종이, 파일, 모바일 기기 등에 비밀번호 기록∙저장을 제한하고, 부득이하게 기록∙저장하여야 하는 경우 암호화 등의 보호대책 적용(ISMS 인증기준 안내서)

⇒ (재발방지 대책) SK텔레콤은 서버 등에 비밀번호 기록 및 저장을 제한하고 부득이할 경우 암호화하여 저장하는 한편, 서버 접속을 위한 다중인증 체계를 도입해야 한다.

② 과거 침해사고 대응 미흡

SK텔레콤은 ‘22.2.23일 특정 서버에서 비정상 재부팅이 발생함에 따라 해당 서버 및 연계된 서버들을 점검하는 과정에서 악성코드에 감염된 서버를 발견하여 조치하였으나, 정보통신망 이용촉진 및 정보보호 등에 관한 법률(이하 “정보통신망법”)에 따른 신고 의무*를 이행하지 않았다.

* 당시 정보통신망법 제48조의3에 따라 침해사고가 발생하면 즉시 그 사실을 과기정통부 또는 한국인터넷진흥원에 신고하여야 하며 위반 시 3천만원 이하 과태료 부과 대상

또한, 당시 점검 과정에서 SK텔레콤은 이번 침해사고에서 감염이 확인된 음성통화인증 관리서버(‘21.12.24, 12.30 감염)에 비정상 로그인 시도가 있었던 정황도 발견하여 점검하였으나, 해당 서버에 대한 로그기록 6개 중 1개만 확인하여, 공격자가 서버에 접속한 기록을 확인하지 못하였다.

이로 인해 음성통화인증 관리서버 및 정보유출이 발생한 음성통화인증에서 BPFDoor 악성코드를 확인하지 못하였으며, 또한 침해사고를 신고하지 않아 정부가 조사를 통해 악성코드를 발견하여 조치하는 것도 이루어질 수 없었다.

※ 조사단은 감염서버뿐만 아니라 의심정황이 있는 서버까지 정밀분석(포렌식 등)하여 추가 악성코드 확인∙조치

⇒ (재발방지 대책) SK텔레콤은 침해사고 발생 시 법령에 따른 신고의무를 준수하고 철저한 원인 분석을 통해 피해확산 방지 노력을 이행하여야 한다.

③ 주요정보 암호화 조치 미흡

유출 정보 중 유심 복제에 활용될 수 있는 중요한 정보인 유심 인증키(Ki) 값 암호화를 세계이동통신사업자협회(GSMA)는 권고하고 있으며, 타 통신사들(KT, LGU+)도 암호화하여 저장하고 있으나, SK텔레콤은 암호화하지 않고 저장하였다.

※ GSMA(Global System for Mobile Communications Association)

⇒ (재발방지 대책) SK텔레콤은 관계 법령 및 국제 권고에 따라 주요 정보를 암호화하여 저장하여야 한다.

< 정보통신망법 위반사항 >

SK텔레콤은 침해사고 대응과정에서 ①침해사고 신고 지연 및 미신고, ②자료보전 명령 위반 등 망법상 준수 의무 2가지를 위반하였다.

① 침해사고 신고 지연 및 미신고

SK텔레콤은 정보통신망법 제48조의3에 따라 침해사고를 인지한 후 24시간 이내*에 과기정통부 또는 한국인터넷진흥원에 신고하여야 하나, 24시간이 지난 후 신고하였다. 또한, 악성코드(타이니쉘 2종)에 감염된 서버를 발견하고도 침해사고 신고를 하지 않았다.

* ’24.8.14일부터 24시간 이내 신고 의무가 시행되었으며, 이전에는 구체적 신고 기한 없이 ‘즉시’ 신고하도록 규정

⇒ (조치사항) 정보통신망법에 따라 과태료를 부과할 예정이다.

※ 정보통신망법 제76조에 따라 3천만원 이하 과태료 부과 대상

② 자료보전 명령 위반

과기정통부는 정보통신망법 제48조의4에 따라 SK텔레콤에 침해사고 원인 분석을 위해 자료 보전을 명령(4.21 17:42)하였으나, SK텔레콤은 서버 2대를 디지털 증거수집(포렌식) 분석이 불가능한 상태로 임의 조치(4.21 19:52) 후 조사단에 제출하였다.

⇒ (조치사항) 자료보전 명령 위반과 관련하여 수사기관에 수사를 의뢰할 예정이다.

※ 정보통신망법 제73조에 따라 자료보전 명령을 위반하여 자료를 보전하지 아니한 자는 2년 이하의 징역 또는 2천만원 이하의 벌금 대상

< 정보보호 활동 및 관리(거버넌스) 체계 미흡 >

조사단은 이번 침해사고 조사 과정에서 SK텔레콤이 ①보안 관리 미흡, ②공급망 보안 소홀 등 기본적인 정보보호 활동이 미흡했던 점과, ③SK텔레콤의 침해사고 대응이 체계적으로 가동되지 않는 사실도 확인하였다.

① 보안 관리 미흡

SK텔레콤은 자체 규정에 따라 연 1회 이상 서버 보안점검을 수행하고 있으나, 쉽게 탐지가 가능한 웹쉘은 점검항목에 포함하지 않아 이를 발견하지 못하였다.

또한, SK텔레콤은 전화번호의 마스킹 규칙이 담긴 정보를 통신기록(CDR)이 임시 저장된 서버에 저장하는 등 마스킹된 정보의 보안관리가 미흡하였다.

⇒ (재발방지 대책) SK텔레콤은 EDR*, 백신 등 보안 해결책(솔루션) 도입 확대, 철통인증(제로트러스트) 도입, 분기별 1회 이상 모든 자산에 대해 보안 취약점 정기 점검 및 제거 등 보안 관리를 강화해야 한다.

* Endpoint Detection and Response : 서버 등 네트워크가 연결되는 장치에서 발생하는 모든 활동을 감지·분석하는 도구

② 공급망 보안 소홀

SK텔레콤은 협력업체로부터 공급받은 소프트웨어를 면밀히 점검하지 않고 내부 서버 88대에 설치하여 해당 소프트웨어에 탑재되어 있었던 악성코드가 유입되었다.

※ 유입된 악성코드가 SK텔레콤 시스템에서 실행된 흔적은 없음

⇒ (재발방지 대책) SK텔레콤은 협력업체 공급 소프트웨어 등 외부 조직 및 서비스로부터 발생하는 위험에 대한 보호대책을 마련하여 이행하는 등 공급망 보안체계를 구축해야 한다.

③ 정보보호 관리(거버넌스) 체계 미흡

SK텔레콤은 정보통신망법 제45조의3 등에 따라 정보보호 최고책임자(CISO)가 정보보호 관련 업무를 총괄하여야 하나, 보안 업무를 정보기술 영역(자산의 57%)과 네트워크 영역(자산의 43%)으로 구분하고 정보보호책임자는 정보통신 영역만 담당하고 있다.

※ SK텔레콤 시스템은 정보기술 영역(업무망, 고객관리망 등)과 네트워크 영역(시스템 관리망, 핵심망<코어망> 등)으로 구분

⇒ (재발방지 대책) SK텔레콤은 정보보호 최고책임자가 전사 정보보호 정책을 총괄 관리할 수 있도록 정보보호 최고책임자를 최고경영자 직속 조직으로 강화하여야 한다.

< 기타 개선 필요사항 >

① 로그기록 단기 보관

SK텔레콤은 자체 보안규정에 따라 로그기록을 6개월 이상 보관해야 하나, SK텔레콤은 실제 운영 시 방화벽 로그를 4개월간만 보관 중이었다. 이로 인해 조사단이 중요 정보의 유출 여부를 면밀히 조사하는 데 한계가 있었다.

⇒ (재발방지 대책) 방화벽 로그기록을 6개월 이상 보관하고, 중앙로그관리시스템을 구축하여 주기적인 점검과 사고 발생 시 분석에 적극 활용하여야 한다.

② 자산 식별의 어려움

조사단이 SK텔레콤 서버 전체 대상으로 점검 시, 전체 자산 종류, 규모, 유휴·폐기 여부 등을 체계적으로 관리되고 있지 않음을 확인하였다.

⇒ (재발방지 대책) 전사 자산을 담당하는 정보기술 최고책임자(CIO)를 신설하고, 정보기술 자산관리 해결책(IT자산관리 솔루션)을 도입하여야 한다.

③ 타사 대비 정보보호 인력 및 투자 규모 부족

’24년도 정보보호 공시 기준 SK텔레콤의 가입자 100만명당 정보보호 인력은 15명, 투자액 37.9억 원(SKB 포함)으로 통신사 평균 대비 그 규모*가 작았다.

*가입자 100만명 당 정보보호 인력(명) : SK텔레콤/SKB(15.0), KT(25.1), LGU+(14.3), 평균(17.7)
가입자 100만명 당 정보보호 투자액(억원) : SK텔레콤/SKB(37.9), KT(90.8), LGU+(57.5), 평균(57.4)

⇒ (재발방지 대책) SK텔레콤은 정보보호 강화에 필요한 인력 및 예산 규모를 타 통신사 이상의 수준(가입자 당 기준)으로 확대해야 한다.

5. 향후 계획

과기정통부는 SK텔레콤에 재발방지 대책에 따른 이행계획을 제출(7월)토록 하고 SK텔레콤의 이행(8~10월) 여부를 점검(11~12월)할 계획이다. 이행점검 결과, 보완이 필요한 사항이 발생하는 경우 정보통신망법 제48조의4에 따라 시정조치를 명령할 계획이다.

또한, 과기정통부는 인공지능 시대 국가 사이버보안 역량을 강화하지 않으면 큰 피해가 우려되는 상황에서 SK텔레콤 침해사고를 계기로 민간 분야 정보보호 전반의 체계를 개편할 계기가 되었다고 판단하였다.

이에 국민, 산업에 미치는 영향이 큰 통신망을 안전하게 보호하기 위한 별도의 법제도 방안, 민간 정보보호 투자 확대 및 정보보호 관리체계(거버넌스) 강화 등을 위한 제도 개선 방안 등을 국회 과학기술정보방송통신위원회 내 SK텔레콤 해킹사고 관련 전담조직(TF)과 논의를 거쳐 마련할 계획이다.

(이하 생략)

https://www.msit.go.kr/bbs/view.do?sCode=user&mId=307&mPid=208&pageIndex=&bbsSeqNo=94&nttSeqNo=3185964&searchOpt=ALL&searchTxt=

1. 개요

• 2025년 7월 2일, 놀 인터파크를 운영하는 놀유니버스에서 개인정보 유출 의심 사건이 발생했습니다.
• 국내 최대 티켓예매 플랫폼이자 여행 플랫폼인 놀 인터파크에서 개인정보 유출 정황이 포착되어, 개인정보보호위원회에 정식 신고되었습니다.

2. 피해범위

• 아직 유출 범위와 피해자 수는 확인되지 않은 상태입니다.
• 개인정보위가 조사에 착수함에 따라 구체적인 피해 규모가 드러날 전망입니다.
• 놀 인터파크 이용자 중 1000명 이상의 정보주체에 관한 개인정보가 유출되었거나, 민감정보 또는 고유식별정보가 유출된 것으로 추정됩니다.

3. 유출항목

• 현재까지 구체적인 유출 항목은 공개되지 않은 상황입니다.
• 놀유니버스 관계자는 "개인정보 유출이 의심돼 개인정보위에 신고한 상태"라며 "현재 회사 차원에서 로그 분석 등 내부 파악을 진행하고 있다"고 밝혔습니다.

4. 원인

• 이번 개인정보 유출 사고의 구체적인 원인은 아직 조사 중입니다.
• 놀유니버스는 현재 로그 분석을 통한 내부 조사를 진행하고 있어, 원인 규명을 위한 작업이 계속되고 있습니다.

5. 대응

• 놀유니버스는 개인정보 유출 의심 사실을 즉시 개인정보보호위원회에 신고했습니다.
• 개인정보보호법에 따라 1000명 이상의 정보주체에 관한 개인정보 유출이나 민감정보 유출 시 72시간 내 신고해야 하는 의무를 이행했습니다.
• 현재 회사 차원에서 로그 분석 등을 통한 내부 파악을 진행하고 있으며, 인터파크글로벌 웹사이트에는 7월 1일 오전 11시부터 점검으로 티켓 예매가 중단되었습니다.

6. 문제점

• 거듭되는 해킹 사고 후 불과 2년여 만에 또 다시 개인정보 유출 정황이 발생한 만큼, 놀유니버스는 보안 관리에 대한 비난을 면하기 어려워 보입니다. 
• 2023년 크리덴셜 스터핑 공격으로 78만4920건의 개인정보를 탈취당한 지 얼마 되지 않아 재차 개인정보 유출 사건이 발생한 것으로, 반복적인 보안 사고에 대한 근본적인 원인 분석과 대책 마련이 필요한 상황입니다.

◎ 과거 인터파크 개인정보유출 사고 정리

2016년 인터파크 개인정보 대량유출 사고

1. 개요

• 2016년 7월, 인터파크에서 1030만명의 개인정보가 대량 유출되는 역대급 사고가 발생했습니다. 
• 당시 인터파크 회원 2000만명의 절반에 해당하는 규모로, 개인정보 유출 사고로는 역대 최고 규모였습니다.

2. 피해범위

• 총 1030만명의 개인정보 2540만건이 유출되었습니다. 
• 인터파크 직원이 받은 피싱 이메일로 시작된 APT 공격으로 약 2개월간 해커들이 잠복하며 정보를 빼낸 것으로 추정됩니다.

3. 유출항목

• 아이디, 비밀번호, 이름, 성별, 생년월일, 전화번호, 휴대전화번호, 이메일, 주소 등 9개 항목이 유출되었습니다. 
• 다만 주민등록번호와 금융정보는 유출되지 않았습니다.

4. 원인

• 인터파크 직원이 자신의 동생 이메일 주소로 발송된 악성코드가 심어진 가족사진 파일을 클릭하면서 시작되었습니다. 
• 해당 직원의 PC부터 시작하여 파일공유 서버를 거쳐 DB서버 관리 직원의 PC까지 연쇄적으로 악성코드에 감염되었습니다.

5. 대응

• 7월 11일 해커로부터 협박 메일을 받고 해킹 사실을 인지한 후, 12일 경찰에 신고했습니다. 
• 하지만 홈페이지 공지는 25일에 이루어져 늑장 대응 논란이 있었습니다.

6. 문제점

• 접근 통제 등 기술적·관리적 보호조치를 소홀히 한 점이 주요 문제로 지적되었습니다. 
• 방송통신위원회로부터 44억 8천만원의 과징금과 2500만원의 과태료를 부과받아 당시 역대 최고액의 처분을 받았습니다. 
• 또한 집단소송을 통해 1인당 10만원의 위자료를 지급하게 되었습니다.

2023년 인터파크 크리덴셜 스터핑 공격

1. 개요

• 2023년 1월 10일, 인터파크가 크리덴셜 스터핑 공격을 받아 개인정보가 유출되었습니다. 
• 크리덴셜 스터핑은 다른 곳에서 유출된 아이디와 패스워드를 무작위로 대입해 로그인에 성공한 후 개인정보를 탈취하는 방식입니다.

2. 피해범위

• 총 78만4920건의 개인정보가 유출되었습니다.

3. 유출항목

• 이메일, 성별, 생년월일, 전화번호, 주소 등이 포함되었습니다.

4. 원인

• 동일한 접속주소에서 대규모로 발생한 로그인 시도 같은 비정상적 상황을 차단하는 정책을 적용하지 않아 발생했습니다.

5. 대응

• 확인 즉시 개인정보보호위원회와 한국인터넷진흥원 등 관계기관에 신고했습니다. 
• 유출 의심 회원의 계정을 임시 차단하고 비밀번호 변경을 유도했습니다.

6. 문제점

• 개인정보위는 인터파크에 10억2645만원의 과징금과 360만원의 과태료, 시정명령을 내렸습니다. 
• 접근 통제 등 안전조치 의무를 소홀히 한 점이 문제로 지적되었습니다.

◎ 과거 야놀자 개인정보유출 사고 정리

2019년 야놀자펜션 해킹 사건

1. 개요

• 2019년 3월, 야놀자펜션 앱이 해킹 공격을 받아 개인정보 유출 사고가 발생했습니다.

2. 피해범위

• 약 7만명의 고객 정보가 유출되었습니다.

3. 유출항목

• 야놀자펜션 앱 이용자의 개인정보가 유출되었습니다.

4. 원인

• 해킹 공격으로 인한 것으로 파악됩니다.

5. 대응

• 관계기관에 신고 및 대응 조치가 이루어졌습니다.

6. 문제점

• 야놀자의 보안 체계 취약성이 노출된 사례로 지적받았습니다.

2021년 야놀자 클라우드 관리 소홀 사건

1. 개요

• 2021년, 야놀자에서 클라우드 관리 소홀로 인한 개인정보 유출 사고가 발생했습니다.

2. 피해범위

• 약 5만2천건의 개인정보가 외부로 유출되었습니다.

3. 유출항목

• 고객의 개인정보가 외부로 유출되었습니다.

4. 원인

• 관리자 접근 권한이 IP로 제한되지 않아 외부에서 무단 접근이 가능했던 관리 부실이 원인이었습니다.

5. 대응

• 유출 사실 확인 후 관계기관에 신고 및 보안 조치를 실시했습니다.

6. 문제점

• 이로 인해 야놀자는 과징금과 과태료 처분을 받았습니다. 
• 클라우드 보안 관리의 기본적인 원칙을 지키지 않은 점이 심각한 문제로 지적되었습니다.

1. 개요

• 2025년 6월 30일, 샌드위치 프랜차이즈 서브웨이에서 고객 개인정보가 무방비 상태로 노출된 정황이 국회 과학기술정보방송통신위원회를 통해 공개됐습니다. 
• 이는 최근 파파존스, 머스트잇 등에서 연쇄적으로 발생한 개인정보 유출 사고에 이어 또 다른 보안 허점이 드러난 사례입니다.
• 2025.07.01 개인정보위원회 개인정보 유출 조사 착수하였습니다.

 
2. 피해범위

• 실제 고객 정보 유출 여부와 유출 규모는 가늠이 되지 않는 상황입니다. 
• 하지만 최소 5개월간은 동일한 방식으로 개인정보가 무방비 상태에 놓였던 것으로 확인됐습니다. 
• 서브웨이 홈페이지와 모바일 앱을 통한 온라인 주문 시스템을 이용한 모든 고객이 잠재적 피해 대상에 해당합니다.

 
3. 유출항목

• 누구나 로그인 없이 주문 페이지에 접속한 뒤 웹주소(URL) 끝부분의 숫자를 임의로 변경하면 다른 고객의 연락처와 주문 정보가 그대로 화면에 표시되는 구조였습니다. 
• 구체적으로는 고객의 전화번호와 주문 내역 정보, 배달지 주가 노출되었습니다.

 
4. 원인

• 이번 사고는 홈페이지 개편 과정에서 적절한 보안 검토 절차를 거치지 않아 발생한 것으로 전문가들은 분석하고 있습니다. 
• 특정 IP 주소에서 대량의 반복적인 로그인 시도 등 비정상적인 접속 시도를 방지하기 위한 침입 탐지·차단 대책 및 이상행위 대응 등 안전조치의무가 소홀했던 것으로 보입니다.

 
5. 대응

• 서브웨이는 최근 고객 정보와 관련한 제한된 데이터가 노출될 우려가 있는 기술적 문제를 발견해 조치 후 문제를 해결했다고 밝혔습니다. 
• 정보 오용 정황은 확인되지 않았으나 신속히 한국인터넷진흥원(KISA)에 신고했다고 발표했습니다.
• 2025년 7월 2일, 14일부로 홈페이지를 통한 주문 서비스를 종료한다고 합니다.

 
6. 문제점

• 전문가들은 기본적인 보안 관리 소홀과 시스템 설계 단계에서의 보안 검토 부족을 주요 문제점으로 지적하고 있습니다. 
• 김승주 고려대 정보보호대학원 교수는 "유출 규모를 떠나 누구나 타인의 정보에 쉽게 접근하는 건 큰 문제"라고 지적했습니다. 
• 개인정보를 허술하게 관리한 경우 최대 5천만 원의 과태료가 부과될 수 있으며, 전체 매출액의 3% 범위에서 과징금을 부과받을 수 있습니다.

1. 개요

• 명품 플랫폼 머스트잇에서 2025년 5월과 6월에 두 차례에 걸친 해킹으로 개인정보가 유출되는 사고가 발생했습니다. 
• 머스트잇은 6월 23일 한국인터넷진흥원(KISA)을 통해 개인정보 침해 정황을 통보받았고, 6월 25일 공식 홈페이지를 통해 사실을 공개했습니다. 
• 이번 사건은 최근 디올, 티파니, 아디다스에 이어 명품 관련 업계에서 연이어 발생한 개인정보 유출 사건입니다.

2. 피해범위

• 유출 가능성이 있는 개인정보는 현재 가입한 회원을 대상으로 하며, 탈퇴 회원의 정보는 포함되지 않았습니다.
• 구체적인 피해자 수는 공개되지 않았지만 현재 가입 회원 전체를 대상으로 한 것으로 파악됩니다.
• 고객은 머스트잇 홈페이지에 로그인 후 자신의 개인정보 유출 여부와 항목을 직접 확인할 수 있습니다.

3. 유출항목

 - 개인정보 유출 항목은 최대 9개로 다음과 같습니다:

• 회원번호
• 아이디
• 가입일
• 이름
• 생년월일
• 성별
• 휴대전화번호
• 이메일
• 주소

4. 원인

• 이번 해킹의 원인은 시스템 설계 오류로 인한 API 보안 취약점이었습니다. 
• 문제가 된 API는 별도 인증 없이 개인정보 일부를 조회할 수 있는 구조로 설계되어 있었습니다. 
• 해커들은 5월 6일부터 14일까지 특정 API에 대한 대량의 비정상 접근을 시도했고, 6월 9일에는 동일한 API 경로를 통한 2차 공격을 시도했습니다.

5. 대응

• 머스트잇은 사고를 인지한 즉시 해당 취약점을 차단하고 전면적인 보안 조치를 완료했습니다. 
• 기존 문제 API를 폐기하고 신원 확인 절차를 거친 사용자만 개인정보를 열람할 수 있는 신규 인증 시스템을 도입했습니다. 
• 웹 방화벽(WAF), 침입 탐지 시스템(IPS) 등 외부 위협 대응 체계를 강화하고 비정상 접근에 대한 로그 감시를 상시화했습니다.
•  또한 개인정보보호위원회와 KISA 등 관련 기관에 즉시 신고를 실시했습니다.

6. 문제점

• 이번 사건에서 드러난 주요 문제점은 API 설계 단계에서의 보안 고려 부족입니다. 
• 인증 절차 없이 개인정보에 접근할 수 있는 구조를 가진 API를 운영한 것이 근본적인 원인이었습니다.
• 또한 외부의 비정상적인 접근 시도에 대한 실시간 모니터링과 대응 체계가 미흡했던 것으로 보입니다.
• 머스트잇은 이번 사고를 계기로 개인정보 보호 체계를 보다 철저히 구축해 나가겠다고 밝혔습니다.

마이크로소프트가 2025년 Microsoft Build 컨퍼런스에서 Windows Subsystem for Linux(WSL)의 오픈소스화를 발표한 이후, 첫 번째 오픈소스 버전인 WSL 2.6.0이 프리릴리즈로 공개되었습니다. 이번 릴리즈는 WSL의 9년 여정에서 가장 중요한 이정표로, 개발자 커뮤니티에게 완전히 새로운 가능성을 열어주고 있습니다.

◎ WSL 오픈소스화의 역사적 의미
 - Build 2025에서의 발표
  > 마이크로소프트는 2025년 5월 19일 Microsoft Build 개발자 컨퍼런스에서 WSL의 완전한 오픈소스화를 발표했습니다. 이는 WSL GitHub 저장소에서 제기된 첫 번째 이슈인 "이것이 오픈소스가 될 것인가?"라는 질문에 대한 최종적인 답변이기도 합니다.
  > CEO 사티아 나델라는 기조연설에서 오픈소스 이니셔티브의 중요성을 강조하며, WSL 오픈소스화를 통해 투명성 향상, 커뮤니티 협업 촉진, 혁신 가속화를 목표로 한다고 밝혔습니다.

 - MIT 라이선스 하에서의 공개
  > WSL은 MIT 라이선스 하에 공개되어 누구나 소스 코드를 검토하고, 수정하며, 프로젝트에 직접 기여할 수 있게 되었습니다. 이는 마이크로소프트가 오픈소스 원칙을 수용하고 개발자 커뮤니티를 지원하겠다는 의지를 보여주는 중요한 신호입니다.

◎ WSL 2.6.0의 주요 개선사항
 - 안정성 및 버그 수정
WSL 2.6.0은 다양한 안정성 개선과 함께 여러 중요한 버그 수정을 포함하고 있습니다:

• 다국어 문자열 업데이트: 현지화된 문자열이 업데이트되었습니다
• 배포판 등록 해제 개선: BasePath가 존재하지 않는 배포판을 등록 해제할 때 예외가 발생하지 않도록 수정 (이슈 #13004 해결)
• 다운로드 오류 수정: URL에 매개변수가 포함된 경우 배포판 다운로드가 실패하는 문제 해결
• systemd 사용자 세션 문제 해결: systemd 사용자 세션과 관련된 다양한 문제 수정 (이슈 #13053 해결)

 - 시스템 레벨 개선

• wslsettings 안정성: wslservice에서 호출할 때 wslsettings가 충돌하는 문제 수정
• VHD 이동 최적화: 배포판 VHD 이동 시 MOVEFILE_WRITE_THROUGH 설정으로 안정성 향상 (이슈 #13055 해결)
• hosts 파일 파싱 개선: Windows 'hosts' 파일 파싱 시 BOM 헤더 무시 (이슈 #9642 해결)
• 디스크 오류 보고: mount()가 EUCLEAN으로 실패할 때 손상된 디스크를 올바르게 보고 (이슈 #13074 해결)

◎ WSL의 기술 아키텍처
 - 오픈소스화된 구성 요소
WSL의 아키텍처는 여러 분산 구성 요소로 이루어져 있으며, 이 중 대부분이 오픈소스로 공개되었습니다:

 - Windows에서 실행되는 구성 요소:

• 명령줄 실행 파일: wsl.exe, wslconfig.exe, wslg.exe - WSL과 상호작용하는 진입점 역할
• WSL 서비스: wslservice.exe - WSL VM 시작, 배포판 관리, 파일 액세스 공유 마운트 등을 담당

 - Linux VM 내부에서 실행되는 구성 요소:

• init 및 데몬 프로세스: 시작용 init, 네트워킹용 gns, 포트 포워딩용 localhost 등
• 파일 공유: WSL의 plan9 서버 구현을 통한 Linux-Windows 간 파일 공유

 - 여전히 비공개인 구성 요소
  > 일부 구성 요소는 Windows 이미지의 일부로 남아있어 현재로서는 오픈소스화되지 않았습니다:

• Lxcore.sys: WSL 1을 구동하는 커널 측 드라이버
• P9rdr.sys 및 p9np.dll: "\wsl.localhost" 파일시스템 리디렉션을 실행하는 구성 요소

◎ 개발자 커뮤니티에 미치는 영향
 - 커스터마이제이션과 기여 기회

  > 오픈소스화를 통해 개발자들은 자신의 특정 요구에 맞게 WSL을 커스터마이즈하고, 버그를 더 빠르게 수정하며, 새로운 기능을 추가할 수 있게 되었습니다. 이는 더 나은 성능, Linux 서비스와의 향상된 통합, 그리고 크로스 플랫폼 작업을 위한 더 강력한 도구셋으로 이어질 것으로 예상됩니다.

 - 보안 강화

  > 오픈 소스 코드베이스에 대한 공개적인 검토는 취약점의 식별과 패치로 이어져 보안 향상을 가져올 수 있습니다. 커뮤니티의 집단적 전문 지식을 활용하여 WSL의 발전을 촉진할 수 있습니다.

 - 호환성 개선

  > 커뮤니티 기여는 호환성 문제를 더 신속하게 해결할 수 있게 해줍니다. 이는 다양한 Linux 배포판과 개발 도구와의 더 나은 통합을 의미합니다.

◎ WSL의 진화 과정
 - WSL 1에서 WSL 2로의 전환

  > WSL은 2016년 Microsoft Build에서 처음 발표되어 Windows 10 Anniversary Update와 함께 출시되었습니다. 초기 WSL 1은 lxcore.sys라는 호환성 레이어를 사용하여 Linux 시스템 콜을 Windows NT 커널과 통신할 수 있도록 번역했습니다.

  > 2019년에는 실제 Linux 커널을 경량 가상 머신에서 실행하는 WSL 2가 출시되어 성능 향상, GPU 지원, systemd 지원, 그리고 그래픽 애플리케이션 실행 능력 등 상당한 개선을 제공했습니다.

 - 독립형 패키지로의 분리

  > 2021년 마이크로소프트는 WSL을 Windows 코드베이스에서 분리하여 Microsoft Store에서 독립형 패키지로 게시하기로 결정했습니다. 이는 확장되는 커뮤니티와 기능 요청에 대응하기 위해 WSL을 더 빠르게 개발하고 Windows와 별도로 릴리즈할 필요가 있다고 판단했기 때문입니다.

◎ 실무적 활용과 장점
 - 향상된 성능:
  > 파일 시스템 성능 개선: WSL 2에서 파일 시스템 성능이 많이 개선되었는데, WSL 2.6에서는 리눅스와 Windows 간 파일 시스템 접근 속도가 더욱 빨라졌습니다. 특히, Windows에서 리눅스 파일 시스템에 접근하는 속도와, 그 반대의 속도가 개선되었습니다.
  > 메모리 관리 향상: WSL 2의 메모리 관리가 더 효율적이게 되어, 리소스 사용을 최소화하면서 더 많은 작업을 동시에 처리할 수 있게 되었습니다.

 - 더 나은 통합:
  > Linux GUI 애플리케이션 지원 강화: WSL 2.6에서 리눅스 GUI 애플리케이션을 Windows에서 실행하는 경험이 더욱 매끄럽고 효율적으로 바뀌었습니다. 특히 X 서버를 별도로 설치할 필요 없이, Windows에서 직접 GUI 애플리케이션을 실행할 수 있는 기능이 강화되었습니다.
  > WSLg (WSL GUI) 업데이트: Windows에서 리눅스 GUI 애플리케이션을 네이티브처럼 실행할 수 있도록 돕는 기능이 더 좋아졌습니다.

 - 네트워크 성능 및 안정성 개선:
  > IP 주소 충돌 문제 개선: WSL 2와 호스트 시스템(Windows) 간 네트워크 충돌이 발생하는 경우가 있었는데, 이러한 충돌을 줄여 안정성을 높였습니다.
  > 향상된 네트워크 성능: 네트워크 성능도 크게 향상되었으며, 특히 Docker와 같은 컨테이너화된 애플리케이션을 사용할 때 네트워크 대역폭을 더 잘 활용할 수 있게 되었습니다.

 - 통합 개발 도구 개선:
  > VS Code와의 통합 강화: WSL 2.6에서는 Visual Studio Code와의 통합이 더 강력해져, Windows와 리눅스 환경 간의 개발 작업이 더 원활해졌습니다.
  > 새로운 디버깅 기능: 리눅스 환경에서 개발할 때, 디버깅 기능이 더 좋아졌습니다. 다양한 개발 도구와 디버거를 Windows와 리눅스 간에 원활하게 사용할 수 있게 되었죠.

 - 기타 변경 사항:
  > 파일 시스템 접근 방식 개선: Windows와 리눅스 파일 시스템 간의 상호작용이 더욱 유연하고 효율적으로 변경되었습니다.
  > 더 많은 배포판 지원: 추가적인 리눅스 배포판을 WSL에서 사용할 수 있도록 지원이 강화되었습니다.

◎ 향후 전망
 - 커뮤니티 주도 개발
  > 마이크로소프트는 "WSL은 커뮤니티 없이는 오늘날의 모습이 될 수 없었다"고 강조하며, 소스 코드에 접근할 수 없는 상황에서도 사람들이 WSL의 현재로 이어지는 큰 기여를 해왔다고 인정했습니다. 이제 커뮤니티가 프로젝트에 직접 코드 기여를 할 수 있게 되어 WSL의 발전이 더욱 가속화될 것으로 예상됩니다.

 - 혁신과 기능 확장
  > 오픈소스화를 통해 다양한 관점에서의 혁신적인 솔루션과 개선사항이 나올 것으로 기대됩니다. 개발자들은 이제 WSL의 내부를 탐색하고, 개선사항을 제안하며, 기능을 직접 기여할 수 있게 되었습니다.

◎ 결론
 - WSL 2.6.0의 오픈소스 릴리즈는 단순한 버전 업데이트를 넘어 WSL 생태계의 근본적인 변화를 의미합니다. 마이크로소프트의 이러한 결정은 개발자 친화적인 플랫폼으로서 Windows의 진화에서 중요한 이정표가 되며, 커뮤니티 주도 개발의 새로운 시대를 열어가고 있습니다.

 - 앞으로 WSL은 커뮤니티의 참여를 통해 더욱 강력하고 유연한 도구로 발전할 것이며, Windows와 Linux 환경 사이의 다리 역할을 더욱 효과적으로 수행할 것으로 전망됩니다. 개발자들에게는 이제 WSL의 미래를 직접 만들어갈 수 있는 기회가 주어진 셈입니다.

https://github.com/microsoft/WSL/

https://github.com/microsoft/WSL/releases/tag/2.6.0

설치버전을 다운받아서 바로 업데이트 했습니다.

Rust 최신 버전의 설치 파일과 관련 컴포넌트를 다운로드하는 Bash 스크립트입니다. 이 스크립트는 온라인 환경에서 필요한 파일들을 다운로드하여 오프라인 환경으로 옮길 수 있게 만들어줍니다.

◎ Rust 최신 버전 다운로드 스크립트

 - 설명:

• curl을 사용하여 GitHub API를 통해 최신 Rust 버전을 자동으로 가져옵니다.
• rustup-init은 Rust를 설치할 때 필요한 초기 설치 스크립트입니다.
• 최신 Rust 버전 및 표준 라이브러리(rust-std)를 다운로드합니다.
• 다운로드 디렉토리는 rust_downloads로 설정되며, 이 디렉토리 내에 필요한 파일들이 저장됩니다.

 - 사용 방법:

• 이 스크립트를 복사하여 .sh 파일로 저장합니다 (예: download_rust.sh).

  > 스크립트에 실행 권한을 부여합니다.

  > 스크립트를 실행합니다.

스크립트가 완료되면 rust_downloads 디렉토리 내에 필요한 파일들이 다운로드됩니다.
이후 파일들을 오프라인 시스템으로 scp나 다른 방법으로 전송하여 설치할 수 있습니다.

◎ 오프라인 시스템에서 Rust 설치 스크립트

이 스크립트는 미리 다운로드한 파일들을 사용하여 Rust를 오프라인으로 설치할 수 있게 도와줍니다.

 - Rust 오프라인 설치 스크립트

 - 설명:
  > 파일 확인:

• rustup-init, rust-$RUST_VERSION-$RUST_ARCH.tar.gz, rust-std-$RUST_VERSION-$RUST_ARCH.tar.gz 파일들이 있는지 확인합니다. 이 파일들은 미리 다운로드한 파일이어야 합니다.

  > rustup 설치:

• rustup-init를 실행하여 rustup을 설치합니다. 이때 --no-modify-path 옵션을 사용하여 시스템의 PATH를 수정하지 않도록 하고, --default-toolchain none 옵션으로 기본 툴체인 자동 다운로드를 방지합니다.

  > Rust 툴체인 설치:

• 미리 다운로드한 rust-$RUST_VERSION-$RUST_ARCH.tar.gz 파일을 풀고, 이를 시스템에 설치합니다.

  > Rust 표준 라이브러리 설치:

• rust-std-$RUST_VERSION-$RUST_ARCH.tar.gz 파일을 풀고, 이를 시스템에 설치합니다.

  > 환경 변수 설정:

• Rust 설치 후, $HOME/.cargo/bin을 PATH 환경 변수에 추가하여 cargo, rustc 등을 터미널에서 사용할 수 있도록 합니다.

  > 설치 완료 메시지:

• 설치가 완료되면, rustc --version 명령어로 Rust 버전을 확인합니다.

 - 사용 방법

  > 오프라인 시스템에 파일 복사:

• 먼저, 온라인 시스템에서 다운로드한 rustup-init, rust-$RUST_VERSION-$RUST_ARCH.tar.gz, rust-std-$RUST_VERSION-$RUST_ARCH.tar.gz 파일들을 오프라인 시스템으로 복사합니다.

  > 스크립트 실행:

• 이 스크립트를 오프라인 시스템에 저장하고 실행합니다. 예를 들어 install_rust_offline.sh로 저장합니다.

  > 설치 후 확인:

• 설치가 완료되면, rustc --version 명령어로 정상적으로 설치되었는지 확인합니다.

 - 추가적으로:
  > 다른 쉘 사용 시: 만약 bash가 아닌 다른 쉘을 사용하고 있다면, ~/.bashrc 대신 해당 쉘의 설정 파일을 수정해야 합니다. 예를 들어, zsh를 사용한다면 ~/.zshrc에 환경 변수를 추가합니다.
  > 설치 디렉토리 변경: $INSTALL_DIR을 다른 디렉토리로 변경하고 싶다면, 스크립트에서 해당 값을 수정할 수 있습니다.

◎ 오프라인 시스템에서 Rust 삭제 스크립트

이 스크립트는 설치된 Rust 파일과 관련된 디렉토리 및 환경 설정을 안전하게 제거하는 기능을 제공합니다.

 - Rust 오프라인 삭제/제거 스크립트

 - 설명:

  > 환경 변수에서 Rust 관련 PATH 제거:

• ~/.bashrc 또는 ~/.zshrc와 같은 쉘 설정 파일에서 cargo와 관련된 환경 변수 라인을 삭제합니다.
• sed -i '/cargo/d' 명령어로 PATH 변수에 추가된 cargo 경로를 제거합니다.

  > Rust 설치 디렉토리 삭제:

• $HOME/.cargo와 $HOME/.rustup 디렉토리를 제거합니다. 이 디렉토리들은 Rust의 주요 설치 위치이므로 이들을 삭제합니다.

  > Rust 관련 바이너리 삭제:

• rustc와 cargo가 설치된 위치를 확인한 후 삭제합니다. which 명령어로 경로를 찾고, 해당 경로에서 직접 삭제합니다.

  > 환경 변수 적용:

• .bashrc 또는 .zshrc 파일을 수정한 후, source 명령어를 사용하여 변경 사항을 즉시 적용합니다.

 - 사용 방법:

  > 스크립트 실행:

위 스크립트를 uninstall_rust.sh라는 파일로 저장한 후, 실행 권한을 부여하고 실행합니다.

  > 삭제 완료:

• 스크립트가 완료되면, Rust와 관련된 모든 파일이 삭제되고 환경 변수에서 cargo와 관련된 항목도 제거됩니다.

  > 검증:

• rustc --version 또는 cargo --version을 실행하여 Rust가 정상적으로 삭제되었는지 확인합니다. 명령어가 "command not found"로 나오면 삭제가 성공적으로 완료된 것입니다.

 - 추가 참고 사항:

  > 다른 쉘 사용 시:

• ~/.bashrc 외에 다른 쉘을 사용 중이라면 해당 쉘의 설정 파일 (~/.zshrc, ~/.fish, 등)을 지정해야 합니다. 스크립트에서 SHELL_RC_FILE 변수를 변경하여 적용할 수 있습니다.

  > 추가적으로 설치된 패키지:

• 만약 오프라인 환경에서 rustup 외에 다른 방식으로 Rust를 설치했다면, 해당 설치 방식에 맞게 디렉토리 삭제 부분을 수정해야 할 수 있습니다.

리눅스에서 네트워크 라우팅을 관리하는 것은 시스템 관리자에게 필수적인 기술입니다. ip route 명령어는 iproute2 패키지의 핵심 구성 요소로, 전통적인 route 명령어를 대체하여 더 강력하고 유연한 라우팅 관리 기능을 제공합니다. 이 글에서는 임시 및 영구 라우팅 설정 방법부터 단일 및 다중 인터페이스 환경에서의 차이점까지 상세히 알아보겠습니다.

◎ IP Route 명령어 기본 개념
 - 라우팅 테이블의 이해
  > 라우팅 테이블은 커널에 저장되어 있으며, 네트워크 패킷이 목적지에 도달하기 위해 어떤 경로를 선택할지를 결정하는 핵심 요소입니다. 각 라우팅 엔트리는 목적지 네트워크, 게이트웨이, 인터페이스, 그리고 메트릭 값 등의 정보를 포함합니다.

 - 기본 구문과 옵션
  > ip route 명령어의 기본 구문은 다음과 같습니다:

  > 주요 구성 요소는 다음과 같습니다:

• destination: 목적지 네트워크 주소
• via: 다음 홉 라우터의 IP 주소
• dev: 출구 인터페이스
• metric: 라우트 우선순위

◎ 임시 라우팅 설정 방법
 - 기본 라우트 조회
  > 현재 라우팅 테이블을 확인하는 가장 기본적인 명령어입니다:

 - 정적 라우트 추가
  > 단일 호스트에 대한 라우트 추가:

  > 네트워크에 대한 라우트 추가:

 - 기본 게이트웨이 설정

 - 라우트 삭제
  > 임시로 추가한 라우트를 제거하는 방법입니다:

◎ 영구 라우팅 설정 방법
 - 임시 설정과 달리 영구 설정은 시스템 재부팅 후에도 유지되는 설정입니다. 배포판별로 설정 방법이 다릅니다.

 - Ubuntu/Debian 계열 (Netplan 사용)
  > Ubuntu 18.04 이후 버전에서는 Netplan을 사용합니다:

  > 설정 예시:

  > 설정 적용:

 - RHEL/CentOS 계열
  > nmcli 사용 방법
  > 현대적인 RHEL/CentOS 시스템에서는 nmcli를 사용합니다:

  > 전통적인 방법 (CentOS 6/7)

  > 파일 내용 예시:

 - 설정 확인 및 검증
  > 영구 설정 후 다음 명령어로 확인합니다:

◎ 단일 인터페이스 vs 다중 인터페이스 환경
 - 단일 인터페이스 환경
  > 단일 인터페이스 환경에서는 라우팅 설정이 상대적으로 단순합니다:

특징:

• 모든 트래픽이 하나의 인터페이스를 통해 처리됩니다
• 라우트 충돌이 발생할 가능성이 낮습니다
• 설정과 관리가 간단합니다

 - 다중 인터페이스 환경
  > 다중 인터페이스 환경에서는 메트릭 값과 라우트 우선순위가 중요해집니다:

 - 메트릭 값의 중요성
  > 메트릭 값은 라우트 우선순위를 결정하는 핵심 요소입니다:

• 낮은 메트릭 값 = 높은 우선순위
• 이더넷 > WiFi > WWAN 순으로 우선순위 설정

 - 정책 기반 라우팅 (Policy-Based Routing)
  > 다중 인터페이스 환경에서는 고급 라우팅 기법이 필요할 수 있습니다:

◎ 실무 활용 예제
 - 백업 라우트 설정

 - 특정 서비스를 위한 라우팅

 - 문제 해결 명령어

◎ 주의사항 및 모범 사례

 - 임시 vs 영구 설정 선택 기준

• 임시 설정: 테스트, 긴급 복구, 일시적 우회 시 사용
• 영구 설정: 운영 환경, 정책적 라우팅, 지속적 서비스 제공 시 사용

 - 백업 및 복구

 - 보안 고려사항

• 라우팅 설정 변경 시 다음 사항을 주의해야 합니다:
• 네트워크 연결이 끊어질 수 있으므로 신중히 진행
• 원격 접속 시 대체 접속 경로 확보
• 변경 전 현재 설정 백업 필수

◎ 결론
ip route 명령어는 리눅스 네트워크 관리의 핵심 도구로, 임시 및 영구 라우팅 설정을 통해 효율적인 네트워크 관리가 가능합니다. 단일 인터페이스 환경에서는 단순한 설정으로 충분하지만, 다중 인터페이스 환경에서는 메트릭 관리와 정책 기반 라우팅을 통해 더욱 정교한 네트워크 제어가 필요합니다. 적절한 라우팅 설정을 통해 네트워크 성능 최적화와 안정적인 서비스 제공이 가능하며, 이는 현대적인 리눅스 시스템 관리에서 필수적인 기술입니다.

이 글에서는  4GB 이상의 대용량 파일이 증가하면서 리눅스에서 USB를 EXT4로 포맷하는 방법과 Windows에서 EXT4를 인식하고 포맷하는 다양한 방법을 상세히 알아보겠습니다.

◎ 리눅스에서 USB를 EXT4로 포맷하는 방법
 - USB 장치 식별
  > 먼저 연결된 USB 장치를 식별해야 합니다:

 - 파티션 테이블 생성 및 포맷
  > 방법 1: fdisk 사용

  > 방법 2: cfdisk 사용 (더 사용자 친화적)

 - EXT4 파일시스템 생성
  > 파티션이 생성되면 EXT4 파일시스템으로 포맷합니다:

  > 주요 옵션 설명:

• -L: 볼륨 라벨 설정
• -m 1: 예약 블록 비율을 1%로 설정 (기본값 5%)
• -b 4096: 블록 크기를 4096바이트로 설정

 - 포맷 확인

◎ Windows에서 EXT4 인식 방법
Windows는 기본적으로 EXT4 파일시스템을 지원하지 않지만, 여러 방법을 통해 EXT4 USB를 인식하고 사용할 수 있습니다.

 - WSL2를 이용한 방법 (Windows 10/11)
  > 최신 Windows에서 가장 권장되는 방법:

  > WSL2 사용 조건:

• WSL2가 설치되어 있어야 함
• WSL2 커널이 최신 버전이어야 함

 - 무료 오픈소스 솔루션: Ext2Fsd 드라이버 사용
  > 설치: https://sourceforge.net/projects/ext2fsd/에서 다운로드

  > 설치 옵션 선택:

• Make Ext2Fsd automatically started when system boots
• Enable write support for Ext2 partitions
• Enable force writing support on Ext3 partitions
• Start Ext2 volume manager right now

  > 사용법:

• Ext2 Volume Manager 실행
• EXT4 파티션 선택 후 F4로 드라이브 문자 자동 할당
• 또는 F10으로 수동 드라이브 문자 설정

  > 주의사항:

• 2017년 이후 개발 중단되었지만 여전히 작동
• 언마운트 시 반드시 F11(Flush cache)를 먼저 실행 후 F10(Remove drive letter) 실행

 - 상용 소프트웨어 솔루션

  > Linux File Systems for Windows by Paragon Software:

• 유료 소프트웨어이지만 안정적인 EXT4 지원
• 읽기/쓰기 모두 지원
• 전문적인 기술 지원 제공

  > DiskInternals Linux Reader:

• 무료 버전 제공
• 읽기 전용 지원
• 파일 복사 및 보기 가능

◎ Windows에서 EXT4로 포맷하는 방법
 - 타사 파티션 관리 도구 사용
  > EaseUS Partition Master:

  > MiniTool Partition Wizard:

  > AOMEI Partition Assistant:

 - WSL2를 이용한 포맷
  > Windows 10/11에서 WSL2가 설치되어 있다면 WSL 환경에서 EXT4 포맷이 가능합니다:

◎ 실무 권장사항
4.1 용도별 권장 방법

 - 주의사항

  > 데이터 백업:

• 포맷 전 반드시 중요 데이터 백업
• 포맷 과정에서 모든 데이터가 삭제됨

  > 호환성 고려:

• Ext2Fsd는 모든 EXT4 기능을 지원하지 않음
• 64bit 및 metadata_csum 기능이 비활성화된 EXT4만 완전 지원

  > 안전한 제거:

• Windows에서 EXT4 USB 사용 후 반드시 안전한 제거 절차 수행
• 캐시 플러시 후 드라이브 문자 제거

◎ 결론
4GB 이상의 대용량 파일을 다루기 위해 EXT4 파일시스템은 매우 유용한 선택입니다. 리눅스 환경에서는 mkfs.ext4 명령어로 간단히 포맷할 수 있으며, Windows 환경에서는 WSL2나 타사 도구를 활용하여 EXT4 USB를 사용할 수 있습니다.

가장 안정적인 방법은 리눅스에서 직접 포맷하고, Windows에서는 WSL2를 통해 마운트하거나 Ext2Fsd 같은 무료 드라이버를 사용하는 것입니다.