BoB 뉴스레터 2026년 10월 호

안녕하세요, 구독자 님!

뉴스레터를 구독하신 분들께 매번 감사드립니다.

🍎 BoB 뉴스레터 10월호 스토리

📢 10월 BoB 수료생&멘토 소식

🍧 BoB13기 최ㅇ원님 안랩 입사를 축하합니다

뉴스레터가 여러분의 소식을 함께 전달해드립니다. 🎉

✈️ 2억 2천만 건의 여객정보 노출, 여권번호도 포함

베트남 항공 여객정보 노출 사건으로 살펴본 기술적 보안의 한계와 국제 개인정보 거버넌스의 과제

1. 2억 2천만 건의 여객정보 기록이 발견되다

2026년 6월 3일, 필자가 속한 국제 보안 연구그룹 Kinryū Labs는 베트남과 연관된 데이터베이스에서 약 2억 2천만 건의 항공 여객·승무원 기록이 외부에 노출된 사실을 확인했다. 탑승자의 고유식별정보인 여권번호와 만료일, 생년월일 등, 출발 공항 및 도착 공항, 심지어 탑승 좌석까지 이 포함되었다. 이 가운데 국내 항공사 5곳과 관련된 기록은 약 2,480만 건에 달했다. 연구진은 국내외 관계기관에 관련 사실을 통보했고, 6월 7일에는 해당 시스템에 대한 외부 접근이 차단된 상태임을 확인했다.

사건의 기술적 경위와 분석 결과는 Kinryū Labs의 공개 보고서에서 확인할 수 있다.

kinryu.sh 220 Million Traveller Records: A Vietnam-Linked Passenger Database Left Exposed. 작성자 Davis Zheng

필자의 관심은 취약점 자체보다 그 이후의 과정에 있었다. 외부 접근이 차단됐다고 해서 모든 문제가 해결된 것은 아니기 때문이다. 그동안 누가 데이터베이스에 접근했는지, 실제 개인정보 반출이 있었는지, 영향을 받은 사람들은 누가 보호해야 하는지에 대한 질문은 여전히 남아 있었다.

이번 데이터베이스에는 전 세계 1,008개 항공사와 관련된 기록이 포함돼 있었다. 한 국가에서 발견된 보안 취약점이 여러 국가의 정보주체에게 영향을 미칠 수 있다는 사실은 오늘날 개인정보 처리환경의 복잡성을 잘 보여준다. 데이터는 국경을 자유롭게 넘나들지만, 이를 보호하기 위한 법적 권한과 행정적 책임은 국가별로 나뉘어 있다.

2. 책임은 어디에 머무는가?

항공 여객정보는 국제선 운항과 출입국 관리 과정에서 여러 기관을 거친다. 항공사가 제공한 정보는 목적지 국가의 관계기관으로 전달되고, 별도의 정보시스템 운영업체가 저장과 처리를 담당하기도 한다. 데이터를 제공한 기관과 실제 시스템을 운영하는 주체가 서로 다른 경우도 적지 않다.

이러한 구조에서는 사고가 발생한 뒤 책임을 확인하는 일부터 쉽지 않다. 이번 사건에서도 데이터베이스가 위치한 네트워크와 저장된 정보의 성격은 확인할 수 있었지만, 실제 시스템의 관리주체는 아직 추정 단계에 머물러있다. 국내 항공사와 관련된 기록이 발견됐다는 사실만으로 해당 항공사에 시스템 운영상의 책임이 있다고 판단할 수도 없다.

개인정보 보호 책임을 판단하려면 누가 어떤 목적으로 정보를 수집하고 제공했는지, 누가 처리 목적과 수단을 결정했으며 실제 시스템 운영은 누구에게 맡겼는지를 살펴봐야 한다.

OECD 개인정보 보호 가이드라인은 이를 책임성(Accountability) 원칙으로 설명한다. 개인정보 처리 업무가 외부 업체나 해외 시스템을 통해 이루어지더라도 관련 관리주체의 개인정보 보호 책임은 유지돼야 한다는 취지다.

하지만 책임이 존재한다는 사실과 이를 직접 조사할 권한이 있다는 사실은 다르다. 한국과 관련된 개인정보가 해외에서 노출됐더라도 국내 관계기관이 해당 시스템을 직접 조사하거나 조치를 강제할 수 있는 것은 아니다. 데이터는 국경을 넘어 이동하지만, 조사권과 법적 집행 권한은 각국의 관할권 안에서 행사된다.

개인정보 처리 흐름과 위탁관계, 시스템 운영주체를 평상시에 명확히 관리해야 하는 이유도 여기에 있다. 사고가 발생한 뒤에야 실제 관리주체를 찾아야 한다면, 사실관계 확인은 물론 필요한 보호조치까지 늦어질 수밖에 없다.

3. 법적 분석: 한국과 베트남의 개인정보보호법은 무엇을 말하는가

이번 사건은 베트남의 개인정보 보호 법제가 새롭게 정비된 시점에 발견됐다. 베트남은 2023년 개인정보 보호 시행령 제13/2023/ND-CP호를 도입한 데 이어, 2026년 1월 1일부터 독립적인 베트남 「개인정보보호법」(Law No. 91/2025/QH15)을 시행하고 있다.

국회의원들이 개인정보보호법 통과를 위해 버튼을 누르고 있다. (사진: https://vietnamlawmagazine.vn, VNA)

베트남 「개인정보보호법」은 개인정보 관리주체와 처리수탁자의 보호 책임을 규정하고, 일정한 요건에 해당하는 개인정보 보호 위반사고에 대한 신고와 대응 절차를 마련하고 있다. 이번 사건에서도 실제 관리주체가 누구인지, 어떤 보호조치를 이행했는지, 사고를 인지한 뒤 필요한 신고와 대응이 이루어졌는지가 법적 검토의 출발점이 될 것이다.

그렇다고 법률이 시행 중이었다는 사실만으로 특정 기관의 위법행위를 단정할 수는 없다. 실제 관리주체와 법률의 적용 범위, 사고 인지 시점, 보호조치 이행 여부 등을 확인해야 한다. 항공 여객정보가 출입국 관리와 같은 공적 목적으로 처리되는 경우에는 관련 특별법과 공공기관의 권한도 함께 살펴볼 필요가 있다.

대한민국의 「개인정보 보호법」은 국내 개인정보처리자의 안전조치 의무와 개인정보 유출 대응, 감독기관의 권한 등을 규정한다. 해외 데이터베이스에 한국 항공사 관련 기록이 포함돼 있다는 사실만으로 국내 항공사의 법률 위반이 성립하는 것은 아니다. 개인정보가 어떤 경로와 법적 근거에 따라 제공됐는지, 해당 처리 과정에서 국내 항공사가 어떤 역할을 맡았는지부터 확인해야 한다.

두 나라 모두 개인정보 보호를 위한 법적 체계를 갖추고 있지만, 국경을 넘는 사고에서 책임과 관할권이 자동으로 정리되는 것은 아니다. 법률상 의무를 판단하는 일과 해외 시스템에서 실제로 어떤 일이 발생했는지 조사하는 일은 별개의 절차를 필요로 한다.

법률과 제도의 정비는 개인정보 보호를 위한 중요한 기반이다. 다만 그 책임이 실제 시스템의 접근통제와 운영 절차, 위탁관리, 사고 대응으로 이어지지 않는다면 정보주체가 체감하는 보호 수준에는 한계가 남는다. 개인정보 보호의 실효성은 규정의 존재뿐 아니라 현장에서의 이행 여부에 달려 있다.

4. 실질적인 대응: 국제 공조는 어떻게 발전해야 할까

필자는 이번 사건과 관련해 국내외 관계기관과 직접 소통하면서 국제 공조의 중요성과 현실적인 어려움을 함께 체감했다. 해외 정보시스템에서 발생한 사고는 국내 관계기관이 직접 조사하거나 강제적인 조치를 수행하기 어렵다. 실제 관리주체를 확인하고 침해 여부를 조사하려면 해당 국가의 감독기관과 기술 대응기관의 협력이 필요하기 때문이다.

2026년 10월 22일 한겨레 보도에 따르면 한국인터넷진흥원(KISA)은 6월 4일 관련 신고를 접수했다. 이후 개인정보보호위원회는 베트남 정부에 사실관계 확인을 요청했으며, 개인정보 유출 가능성에 대비해 다크웹 모니터링을 강화하고 있다고 밝혔다. 국내 관계기관도 해외에서 발견된 개인정보 노출 위험에 대응하기 위한 후속 조치를 이어가고 있는 셈이다.

다만 최초 제보 이후 약 4개월이 지난 시점에도 데이터베이스의 실제 관리주체와 과거 비인가 접근 여부, 개인정보 반출 가능성에 관한 구체적인 조사 결과는 공개되지 않았다. 해외 사고에 대한 사실관계 확인이 여러 국가와 기관의 협력에 의존할 수밖에 없다는 점에서, 국제 공조의 어려움이 드러나는 대목이다.

연구진이 6월 7일 확인한 외부 접근 차단은 추가적인 노출 위험을 줄이기 위한 중요한 조치였다. 그러나 접근 차단만으로 과거 비인가 접근이나 실제 정보 반출 여부까지 확인되는 것은 아니다. 이를 규명하려면 접근기록과 시스템 증거를 분석해야 하며, 조사 결과에 따라 실제 영향 범위와 정보주체 보호조치의 필요성을 판단해야 한다.

국가 CERT 간의 기술정보 교환은 국제적인 사고 대응의 중요한 출발점이다. 다만 기술적 위험을 전달하는 것과 개인정보 관리주체의 법적 책임을 판단하는 것은 서로 다른 권한과 전문성을 요구한다. 국가 CERT와 개인정보 감독기관, 산업별 소관기관이 각자의 역할을 수행하면서도 사고 접수부터 사실관계 확인, 후속 조치까지 긴밀하게 협력할 수 있는 체계가 필요하다.

제보자와 관계기관 사이의 소통도 개선할 여지가 있다. 국제 협의나 조사상 비밀 유지가 필요한 경우 상세한 진행 경과를 공개하기는 어렵겠지만, 제보 접수 여부나 추가 자료 요청, 관계기관 연계 상태 등을 적절한 범위에서 공유한다면 협력의 연속성을 높일 수 있을 것이다.

이번 사건에 관한 언론 보도는 해외 개인정보 노출 위험을 사회적으로 환기하고 국제적인 개인정보 보호 책임에 대한 논의를 확대하는 계기가 됐다. 이러한 관심이 일시적인 사건 대응을 넘어 평상시에도 안정적으로 작동하는 국제 협력체계의 발전으로 이어지기를 기대한다.

보안 연구자는 위험을 발견하고 알릴 수 있다. 하지만 그 발견이 실제 위험 감소와 정보주체 보호로 이어지기 위해서는 시스템 운영주체와 정부기관, 산업계의 협력이 필요하다. 취약점을 발견하고 외부 접근을 차단하는 것에서 나아가, 남아 있는 위험을 확인하고 필요한 보호조치까지 연결하는 것이 사고 대응의 궁극적인 목적일 것이다.

필자는 이번 경험이 국경 간 개인정보 보호를 위한 협력체계를 더욱 정교하게 발전시키는 하나의 계기가 되기를 바란다. 개인정보는 국경을 넘어 이동하지만, 그 정보를 보호받아야 할 개인의 권리와 이를 보호해야 할 책임은 국경에서 멈춰서는 안 된다.

[참고자료]

🖥️ GPU는 우리가 무엇을 하는지 알고 있을까?

GPU(Graphics Processing Unit)라고 하면 가장 먼저 무엇이 떠오를까?

아마 고사양 게임을 실행하거나 인공지능 모델을 학습시키는 장치를 떠올릴 것이다. GPU는 원래 그래픽 처리를 위해 발전한 장치지만, 대규모 병렬 연산에 강점을 가지고 있어 오늘날에는 웹브라우저의 화면 렌더링부터 인공지능 모델의 학습과 추론, 클라우드 서비스에 이르기까지 다양한 분야에서 활용되고 있다. 우리가 웹사이트를 방문하고 영상을 시청하거나 생성형 AI를 사용하는 동안에도 GPU는 수많은 연산을 수행하고 있는 셈이다.

여기서 재밌는 질문을 해보자면, 다른 사람이 내 화면을 직접 볼 수 없고, 내가 사용하는 프로그램의 데이터에도 접근할 수 없다면, 내가 컴퓨터로 무엇을 하고 있는지 알아내는 것이 가능할까?

일반적으로 운영체제는 프로그램마다 접근할 수 있는 메모리와 자원을 구분하고 다른 프로그램의 데이터를 마음대로 읽지 못하도록 제한한다. 따라서 이러한 보안 경계가 제대로 작동한다면 다른 프로그램의 활동을 알아내기는 어려워 보인다. 하지만 보안 연구자들은 프로그램이 직접 접근할 수 있는 데이터가 아닌 하드웨어가 작동하면서 발생하는 간접적인 정보에 주목하기 시작했다.

이러한 접근 방식을 타고 올라가보면 사이드채널 공격이라는 개념이 나온다. 사이드채널 공격은 공격 대상의 데이터를 직접 읽거나 정상적인 보안 절차를 우회하는 대신, 시스템이 작동하면서 남기는 간접적인 정보를 관찰해 보호된 정보를 추론하는 공격이다. 예를 들어 옆방에서 누군가 무엇을 하는지 직접 볼 수 없더라도 여러 가지 소리로 행동을 어느 정도 짐작할 수 있다. 이와 비슷하게 컴퓨터에서도 처리 시간이나 메모리 사용 패턴, 전력 소비량과 같은 정보를 이용해서 무슨 행동을 하는지 짐작을 하는 것 이다.

GPU 역시 예외는 아니다. 서로 다른 프로그램이 동일한 GPU를 사용하면 각 프로그램의 작업 특성에 따라 메모리 사용량이나 처리 시간 등에 차이가 발생할 수 있다. 연구자들은 이러한 차이를 분석하면서 다른 프로그램이 수행하는 작업의 특징을 알아낼 가능성이 있다고 판단했다. 실제로 GPU 사이드채널 공격은 2018년부터 꾸준히 연구되어 왔으며, 최근에는 GPU의 작업 시간 배분과 하드웨어 격리 환경까지 연구 범위가 확대되고 있다.

GPU가 남기는 흔적에서 시작된 연구

GPU 사이드채널 공격의 가능성을 보여준 대표적인 연구 중 하나는 2018년 ACM CCS에서 발표된 「Rendered Insecure: GPU Side Channel Attacks are Practical」이다. 연구진은 GPU에서 실행되는 프로그램들이 하드웨어 자원을 공유한다는 점에 주목하며 프로그램이 다른 프로그램의 데이터를 직접 읽지 못하더라도 GPU의 메모리 할당 상태나 성능 관련 정보를 측정할 수 있을 때 다른 프로그램의 실행 흔적이 반영될 수 있다는 점을 확인하였다.

연구진은 실제로 GPU의 메모리 할당과 성능 관련 정보를 분석해 사용자가 방문한 웹사이트를 구분하는 실험을 진행하며 웹사이트마다 달라지는 이미지와 영상, 화면 구성 방식 때문에, 이를 화면에 표시하는 과정에서도 서로 다른 GPU 작업이 발생하는 것을 확인했다. 연구진은 이러한 차이를 수집하고 분석해 사용자의 웹사이트 방문 활동을 추론할 수 있음을 확인했다. 또한 웹사이트에서 발생하는 활동을 추적하거나 비밀번호를 직접 알지는 못하지만 비밀 번호 입력란에서 키를 누르는 시간 간격을 추정하는 실험도 수행했다.

연구는 웹브라우저뿐만 아니라 GPU에서 수행되는 연산 작업도 분석했다. 공격자의 프로그램과 다른 인공신경망 프로그램이 동일한 GPU에서 실행되는 환경을 구성하고, 성능 정보를 수집해 신경망의 내부 구조에 관한 정보를 추론하는 실험을 진행했다. 이는 GPU 사이드채널 공격이 사용자의 브라우징 활동뿐 아니라 다른 프로그램이 수행하는 계산 작업에도 영향을 줄 수 있음을 보여주었다.

이 이후에 나온 연구들

이 연구 이후 GPU 보안 분야에서는 하드웨어가 외부에 제공하는 각종 정보가 잠재적인 정보 누출 경로가 될 수 있다는 문제가 제기되었다. 성능을 측정하고 시스템을 관리하기 위해 제공되는 정보라도, 공격자가 다른 프로그램의 활동을 관찰하는 데 악용할 수 있기 때문이다.

시렞로 이후 연구자들은 GPU의 다른 특성에서도 비슷한 문제가 나타나는지 살펴보기 시작했다. 2023년 USENIX Security에서 발표된 「Hot Pixels」 연구는 GPU와 일부 시스템온칩(SoC)에서 발생하는 전력 소비, 온도, 작동 주파수 변화에 주목했고, 실제로 GPU는 처리해야 할 작업의 종류와 양에 따라 전력 소비량과 작동 속도가 달라질 수 있다는 점을 확인 했다. 연구진은 이러한 변화가 프로그램이 처리하는 명령이나 데이터와 관련되어 있다는 점을 분석했고, 특정 실험 환경에서 웹브라우저의 방문 이력이나 화면 정보와 관련된 사이드채널 공격이 가능함을 보였다.

2024년에는 GPU의 데이터 처리 방식 자체에 주목한 연구들도 발표되었다. IEEE Symposium on Security and Privacy에서 발표된 「GPU.zip」 연구는 GPU가 그래픽 데이터를 압축하는 과정에서 발생하는 정보 누출 가능성을 분석했다. 일부 GPU는 프로그램이 별도로 요청하지 않더라도 화면 데이터를 효율적으로 처리하기 위해 내부적으로 압축을 수행하는데 연구진은 데이터의 특성에 따라 압축 결과와 메모리 사용 패턴이 달라질 수 있다는 점에 주목했고, 특정 브라우저 환경에서 이러한 차이를 이용해 다른 출처의 웹 콘텐츠에 포함된 픽셀 정보를 추론하는 공격을 시연했다.

같은 해 USENIX Security에서 발표된 「Invalidate+Compare: A Timer-Free GPU Cache Attack Primitive」는 GPU의 캐시에 주목했다. 캐시는 자주 사용하는 데이터를 빠르게 처리하기 위해 임시로 보관하는 공간인데 여러 프로그램이 GPU를 사용하면서 캐시의 상태의 변화를 관찰하는 새로운 방식을 제안했다. 이를 통해 사용자가 방문한 웹사이트를 구분하거나 가상 키보드의 입력과 관련된 정보를 추론하는 실험을 진행했고 실제로 정밀한 타이머에 의존하지 않고 캐시의 상태를 분석하는 공격 방식을 제시했다.

이처럼 연구자들이 관찰한 정보는 메모리 할당에서 전력과 온도, 데이터 압축과 캐시 동작에 이르기까지 다양하게 연구하고 각 연구들은 보호된 데이터를 직접 읽지 못하더라도 데이터를 처리하는 과정에서 발생하는 흔적들이 또 다른 정보가 될 수 있다는 것을 확인했다.

GPU가 작업하는 시간만으로도 정보를 알아낼 수 있을까?

2026년에는 기존 연구에서 더 나아가, GPU의 메모리나 캐시가 아닌 여러 프고르매에 작업 시간을 배분하는 과정을 주목하는 「TIMESLICE-SANDWICH: A GPU Side-Channel Attack Exploiting Time-Sliced Scheduling」논문이 출시되었다.

타임 슬라이싱은 하나의 GPU에서 여러 프로그램이 실행될 때는 프로그램들이 GPU를 사용할 시간을 나누어 배분하는 방식이 활용되는 것을 뜻한다. 예시를 들어보면 프로그램 A와 프로그램 B가 동일한 GPU를 사용한다면, GPU는 상황에 따라 A의 작업을 수행한 뒤 B의 작업을 수행하고 다시 A의 작업으로 돌아가는 식으로 자원을 배분할 수 있다. 이러한 과정을 통해 GPU 자원을 효율적으로 활용하는 데 도움이 되지만 각 프로그램에 할당되는 작업 시간의 차이가 외부에서 관찰될 수 있다는 가능성을 보였다.

연구진은 실제로 다른 프로그램과 GPU를 공유하는 환경에서 작업 시간의 미세한 차이를 측정하는 방법을 개발했다. 공격자의 프로그램은 자신에게 할당된 작업 시간을 측정하지만, GPU가 여러 프로그램을 번갈아 실행하는 특성 때문에 측정 결과에는 다른 프로그램이 사용한 시간의 영향도 반영될 수 있다. 연구진은 이러한 특징을 활용해 상대 프로그램에 배분된 작업 시간의 패턴을 추정하고, 이를 기반으로 어떤 작업이 실행되는지 구분하는 공격 방식을 제시했다.

연구진은 이 방법을 검증하기 위해 두 가지 실험을 진행했다. 먼저 인공지능 모델은 구조에 따라 연산량과 실행 패턴이 달라지는데, 이 차이가 GPU의 작업 시간 배분에도 나타나는지 확인하기 위해 20개의 신경망 모델을 구분하는 실험을 했고 평균 F1 점수 94.40%를 기록했다. (F1 점수는 정밀도와 재현율을 함께 고려한 분류 성능 지표다.)

다음으로 웹사이트를 구분하는 실험도 진행했다. 웹브라우저는 웹페이지의 이미지나 그래픽 요소를 화면에 표시할 때 GPU를 사용하기 때문에, 웹사이트마다 렌더링 과정에서 나타나는 GPU 작업 시간 패턴이 달라진다. 200개 웹사이트를 대상으로 이 패턴을 분석했고, 200개 후보 중 실제 방문한 웹사이트 하나를 맞히는 Top-1 정확도가 평균 92.84%로 나타났다.

이러한 공격은 공격자의 측정 프로그램이 피해 프로그램과 같은 GPU에서 실행된다는 것을 전제로 하고, 연구진도 웹브라우저의 자바스크립트만으로는 같은 공격을 구현하기 어렵다고 설명했다. 그래도 이 연구는 GPU 자원을 효율적으로 나눠 쓰기 위해 만든 기능 자체가 정보 누출 경로가 될 수 있다는 것을 보여줬다는 점에서 의미가 있다.

GPU를 분리해서 사용한다면 안전할까?

GPU 사이드채널 공격이 계속 주목받는 이유 중 하나는 GPU를 여럿이 나눠 쓰는 환경이 빠르게 늘고 있기 때문이다. 특히 클라우드나 AI 서비스에서는 비싼 고성능 GPU를 놀리지 않으려고 하나의 GPU를 여러 작업에 쪼개서 할당한다. 이때 여러 사용자가 같은 물리 하드웨어를 쓰더라도 각자의 데이터와 작업은 안전하게 분리돼야 하고, 그래서 GPU 자원 격리가 중요한 보안 요구사항이 된다.

이런 격리에 쓰이는 대표적인 기술이 NVIDIA의 MIG(Multi-Instance GPU)다. 하나의 GPU를 여러 개의 독립된 인스턴스로 나누고 각 인스턴스에 연산 자원과 메모리를 따로 할당하는 방식인데, 덕분에 여러 작업을 동시에 돌리면서도 서로 간섭을 줄일 수 있다. TIMESLICE-SANDWICH 연구에서도 작업 시간 배분을 통한 정보 누출을 막는 방법으로 이런 공간적 분리를 언급한다. 공격 프로그램과 피해 프로그램을 애초에 다른 인스턴스에 두면, 같은 작업 시간 배분을 들여다보는 공격 자체를 막을 수 있기 때문이다.

그런데 공간을 나눴다고 해서 모든 하드웨어 동작까지 완전히 따로 논다고 확정을 할 수 는 없다. 왜냐하면 같은 해 USENIX Security에 발표된 「Behind Bars: A Side-Channel Attack on NVIDIA MIG Cache Partitioning Using Memory Barriers」 연구가 바로 이 틈을 파고들었다. 연구진은 MIG로 분리된 인스턴스 사이에서도 한쪽의 특정 메모리 동작이 다른 쪽의 처리 시간에 영향을 준다는 것을 확인했다. 구체적으로는 한 인스턴스에서 일어난 메모리 배리어(Memory Barrier) 동작이 다른 인스턴스의 메모리 접근 시간을 미세하게 바꿨는데, 메모리 배리어는 원래 메모리 작업의 순서와 완료를 제어하는 기능이다. 연구진은 여기서 생기는 미세한 시간 차이가 옆 인스턴스가 무슨 작업을 하는지 추론하는 단서가 된다는 점을 발견했다.

이 현상을 이용하면 분리된 다른 인스턴스에서 돌아가는 프로그램의 실행 패턴을 추론할 수 있다. 연구진은 대규모 언어 모델(LLM)의 추론 과정에서도 GPU 실행 패턴이 처리 중인 정보와 연관될 수 있다는 것까지 보여줬다. 물론 다른 사용자의 데이터나 AI 대화 내용을 곧바로 읽어낸다는 뜻은 아니지만, 분리된 환경에서도 실행 정보의 일부는 새어 나갈 수 있는 셈이다.

같은 고민은 가상화된 GPU 환경으로도 이어진다. NDSS 2026에 발표된 「Exploiting TLBs in Virtualized GPUs for Cross-VM Side-Channel Attacks」는 가상 GPU를 쓰는 서로 다른 가상머신 사이의 정보 누출을 다뤘다. GPU의 주소 변환 정보를 임시로 담아두는 TLB의 동작을 이용해 다른 가상머신 프로그램의 활동을 추론했는데, 게임에서 숨은 상대의 위치를 짐작하거나 가상 데스크톱 사용자가 방문한 웹페이지를 구분하는 사례까지 제시했다.

GPU 사이드채널 공격, 어떻게 바라봐야 할까?

여기까지 보면 GPU에서 정보가 새어 나갈 수 있는 길이 생각보다 다양하다는 걸 알 수 있다. 메모리 할당과 성능 정보에서 시작해 전력·온도, 캐시 상태, 작업 시간 배분, 그리고 분리된 인스턴스 사이의 하드웨어 동작까지 연구 대상이 계속 넓어졌다. 프로그램이 다루는 데이터뿐 아니라 그 데이터를 처리하는 과정 자체도 보안의 눈으로 봐야 한다는 이야기다.

사이드채널 공격 자체가 여러 조건이 까다롭기 때문에 이 결과들을 당장 위협이다! 라고 받아들일 필요는 없다. 또한 대응하려는 연구도 같이 진행되고 있다. 성능 측정 기능에 대한 접근을 제한하거나 측정값의 정밀도를 낮추는 방법, 프로그램들의 작업을 아예 분리하는 방법, 공격에 쓰이는 실행 패턴을 흐트러뜨리는 방법 등이 논의된다.

이러한 연구들은 AI 서비스가 커질수록 더 무거워진다. 예전에는 GPU를 얼마나 빠르고 효율적으로 굴리느냐가 관심사였다면, 이제는 서로 다른 사용자의 작업을 얼마나 안전하게 떼어 놓느냐도 같이 따져야 한다. 그러려면 GPU 하드웨어 설계는 물론 운영체제와 드라이버, 가상화, 클라우드 자원 관리까지 여러 층위에서 보안을 들여다봐야 한다.

결론: GPU를 안전하게 공유한다는 것은 무엇일까?

GPU 사이드채널 연구들을 쭉 봤을 때한 가지 공통점은 공격자가 정보를 얻으려고 꼭 데이터를 직접 읽을 필요는 없다는 것이다. 2018년에는 성능 정보와 자원 사용량이 단서가 됐고, 이후 전력·온도·주파수, 메모리 압축과 캐시 동작으로 분석 대상이 넓어졌다. 2026년의 TIMESLICE-SANDWICH는 여기서 한 발 더 나아가, 여러 프로그램이 GPU를 나눠 쓰는 과정에서 생기는 시간 차이만으로도 옆 프로그램의 실행 패턴을 읽어낼 수 있다는 것을 보여줬다.

이에 대응하려고 MIG처럼 자원을 분리하는 기술을 쓰지만, 하드웨어를 나눴다고 정보 누출 가능성이 사라지는 건 아니며 Behind Bars가 보여줬듯, 성능과 자원 공유를 위해 만든 기능이 오히려 예상치 못한 누출 경로가 되기도 한다.

그래서 GPU 사이드채널 공격이 던지는 질문은 ‘GPU를 해킹할 수 있는가?’가 아니다. 서로 다른 사용자의 작업을 같은 하드웨어에서 돌릴 때, 우리는 무엇을 공유하고 있고 어디까지 분리하고 있는가?에 가깝다. 앞으로 AI와 클라우드에서 GPU 활용이 늘어날수록, 보안도 데이터와 메모리 접근 권한을 확인하는 선을 넘어 작업 스케줄링과 자원 공유 과정에서 새어 나갈 수 있는 정보까지 챙겨야 한다.

참고문헌

🎥 AI에게 일을 맡겼더니, 해커가 시켰다: AI 에이전트와 프롬프트 인젝션

출처: GPT 생성

답하는 AI에서 '행동하는 AI'로

챗봇은 묻는 말에 답하는 데서 그쳤다. 틀린 답을 내놓아도 피해는 대개 화면 안에서 끝났다. 그런데 AI 에이전트는 다르다. 이메일을 보내고, 코드를 쓰고, 파일을 관리하고, 외부 도구와 API를 호출해 실제 작업을 실행한다. AI가 '말'에서 '행동'으로 넘어오는 순간, 보안의 계산법도 바뀐다.

국내 전문가들은 AI 에이전트의 작동 과정을 인지(입력 해석), 두뇌(추론·계획), 행동(도구 실행)의 세 단계로 나누고, 각 단계마다 고유한 취약점이 있다고 설명한다. 입력 단계에는 프롬프트 인젝션과 탈옥이, 추론 단계에는 출력 왜곡과 데이터 포이즈닝이 도사린다. 마이크로소프트의 2026년 에이전트 프레임워크 연구도 같은 맥락이다. 모델이 도구와 연결되면 AI 계층의 취약점은 더 이상 '내용의 문제'에 머물지 않고 시스템 장악으로 이어질 수 있다는 것이다. 실제로 이 연구는 모델이 통제하는 데이터와 에이전트 도구가 안전하지 않게 맞물려 코드 실행까지 가능했던 취약점 두 건(CVE-2026-26030, CVE-2026-25592)을 사례로 들었다.

프롬프트 인젝션: 읽은 글이 명령이 되는 순간

가장 많이 거론되는 위협이 프롬프트 인젝션이다. 공격자가 악의적인 지시를 입력에 심어두면 에이전트는 본래 목표와 상관없이 그 지시를 따른다. 사용자가 직접 입력하는 '직접 인젝션'은 눈에 띄기라도 하지만, 진짜 문제는 '간접 인젝션'이다. 이메일, 웹페이지, 공유 문서, 고객 문의 티켓, 캘린더 초대처럼 에이전트가 일상 업무 중에 읽는 콘텐츠 속에 지시를 숨겨두는 방식이다. 에이전트 입장에서는 수상한 공격이 아니라 원래 하던 일처럼 보인다.

근본 원인은 언어 모델의 구조에 있다. 모델에게는 '내가 따라야 할 지시'와 '내가 읽고 요약해야 할 자료'가 모두 같은 텍스트 흐름으로 들어온다. 과거 웹 개발자들이 데이터와 명령어를 뒤섞는 바람에 SQL 인젝션에 시달렸던 것과 닮은 구도지만, 자연어에는 SQL처럼 깔끔하게 문장을 걸러내는 문법적 경계선이 없다는 점에서 해법이 훨씬 까다롭다.

이미 뚫린 사례들

위협은 이론에 그치지 않는다. 2025년 7월에는 아마존의 AI 코딩 도우미 '아마존 Q'의 VS Code 확장 프로그램이 악성 프롬프트에 잠시 오염된 일이 있었다. 해당 프롬프트 자체는 형식이 어긋나 실제 피해로 이어질 가능성이 낮았다고 알려졌지만, AI 도구의 코드 리뷰와 배포 과정에 악성 지시문이 끼어들 수 있다는 '공급망'의 허점을 드러냈다.

더 최근에는 한 보안 연구자가 앤트로픽, 구글, 마이크로소프트의 AI 에이전트가 깃허브(GitHub) 액션 연동 환경에서 프롬프트 인젝션으로 탈취당할 수 있음을 시연했다. 앤트로픽의 코드 보안 리뷰 도구를 상대로는 풀 리퀘스트 제목에 공격 문구를 심는 방식을 썼고, 세 곳 모두에서 API 키와 토큰 같은 비밀 정보를 빼냈다고 한다. 보도에 따르면 세 기업은 취약점 신고 보상금(버그 바운티)을 지급하면서도 공개적인 경고는 하지 않았다.

학계의 진단은 더 냉정하다. 올해 초 발표된 78건의 연구를 종합 분석한 결과, 테스트된 코딩 에이전트는 예외 없이 프롬프트 인젝션에 취약했고, 공격자가 막히는 지점에 맞춰 수법을 바꾸는 '적응형 공격'의 성공률은 85%를 넘었다.

기업 현장은 이미 영향권

영국과 미국의 기술 임원 750명을 대상으로 한 2026년 조사에서는 응답 기업의 54%가 지난 1년 사이 AI 에이전트 관련 보안·개인정보 사고를 겪었거나 겪었다고 의심했고, 34.9%는 사고가 확실히 있었다고 답했다. 업종별로는 통신(67.3%)과 금융(54.7%)의 비율이 특히 높았다. 에이전트에 이메일, 고객 데이터, 결제 시스템 같은 민감한 자산이 연결될수록 한 번의 인젝션이 불러올 피해가 커지기 때문이다.

'완전한 해결'은 없다는 전제 위에서

더 불편한 사실은 이 문제에 완결된 해법이 아직 없다는 점이다. 오픈AI는 자사 브라우저 에이전트 '아틀라스'와 관련해 프롬프트 인젝션이 완전히 '해결'되지 않을 수 있다고 밝힌 것으로 전해졌다. 국제 웹 보안 커뮤니티 OWASP는 올해 '에이전트 애플리케이션 10대 위험'을 발표했고, 프롬프트 인젝션이 그중 6개 항목에 걸쳐 있다고 짚었다. 지난 9월 1일에는 운영 중인 에이전트가 추적·점검이 가능해야 하고 실행 중에도 정책이 강제되어야 한다는 '에이전트 통제 표준(Agent Control Standard)'도 내놓았다.

전문가들이 공통으로 권하는 대응은 한 가지 기술에 기대지 않는 다층 방어다. 데이터를 보호하고, 에이전트의 접근 권한을 최소화하며, 출력을 검증하고, 되돌릴 수 없는 작업(송금, 삭제, 외부 전송)에는 사람의 승인을 거치게 하고, 문제가 생기면 즉시 멈출 수 있는 장치를 두라는 것이다. 핵심은 에이전트를 얼마나 똑똑하게 만드느냐보다 '무엇까지 맡기느냐'에 있다. 같은 모델이라도 주변 시스템이 에이전트를 얼마나 무조건 신뢰하느냐에 따라 사고의 심각도가 갈렸다는 분석도 이를 뒷받침한다.

편리함의 값은 권한으로 치러진다

이 시리즈가 계속 짚어온 질문과도 맞닿는다. AI가 내 데이터로 학습되는 문제가 '내 정보가 어디로 흘러가는가'를 묻는다면, 에이전트 보안은 '내 정보에 누가 접근할 수 있는가'를 묻는다. 이메일함과 문서함 열쇠를 에이전트에게 건네는 순간, 에이전트가 읽는 모든 글이 잠재적인 침입 경로가 된다. 편리함은 공짜가 아니며, 그 값은 결국 우리가 내어준 권한의 크기로 치러진다.

[참고자료]

📢 신규 '친구 초대 누적 레이스' 안내

안녕하세요, BoB 뉴스레터 구독자 여러분!

매달 뜨거운 성원을 보내주셨던 ‘BoB 뉴스레터 퀴즈 이벤트’가 예산상의 이유로 6월호를 마지막으로 잠정 중단하게 되었습니다. 그동안 퀴즈에 적극적으로 참여하며 반짝이는 보안 지식을 나눠주신 모든 분께 진심으로 감사드립니다.

하지만 아쉬워하긴 이릅니다! 더욱 묵직한 혜택을 담은 장기 프로젝트가 찾아옵니다! 💎

퀴즈 이벤트의 아쉬움을 달래기 위해, 2026년 7월호 부터 [BoB 뉴스레터 친구 초대 누적 레이스]를 새롭게 시작합니다.

주변에 보안 트렌드를 함께 나누고 싶은 분들이 있다면, 이번 호 링크를 활용해 지금부터 미리미리 나만의 초대 포인트를 빌드업해 두세요! 😉

E D I T O R

🚨 BoB 가족들의 소중한 소식을 기다리고 있습니다. 🚨

함께 공유하고 싶은 소식, 수상 내역, 행사기타 소소한 일상까지 구독자분들의 공유를 기다립니다.

- 함께 만들어가는 BoB 뉴스레터 -  

bobnews@bobnews.kr

Best of the Best 뉴스레터팀 7기

(13449) 경기도 성남시 수정구 대왕판교로 815(시흥동 321) 기업지원허브 혁신기술존 4층

대표번호: 02-405-6512~5 | Fax: 02-565-6052