눈에 보이는 것만 지우는 방식은, 로그에서도 저장매체에서도 통하지 않습니다

한 개발자가 사내 업무 자동화를 위해 만든 AI 에이전트의 실행 기록을 정리합니다. 어떤 요청이 들어왔고 AI가 어떤 도구를 호출했는지가 순서대로 남은 파일입니다. 다른 팀도 참고할 수 있게 공개 저장소에 올리기 전에, 눈으로 훑으며 눈에 띄는 API 키와 계정 정보를 지웁니다. 대화 내용은 깨끗해졌습니다. 남은 것은 알아볼 수 없는 문자열 덩어리뿐이니, 암호화된 데이터가 무슨 문제가 되겠느냐고 판단합니다. 그리고 업로드 버튼을 누릅니다.

2026년 8월, 이 판단이 위험할 수 있다는 연구 결과가 공개됐습니다. 연구진은 공개된 AI 에이전트 작업 기록 6,708건에서 31만 5,320개의 추론 블록을 복원했고, 벤치마크용 데이터를 제외한 실제 사용자 세션에서 704건의 개인정보·민감정보 항목을 찾아냈습니다. 그 안에는 API 키 62개, 비밀번호 33개, 접근 토큰 24개, 개인키 7개가 포함돼 있었습니다. 더 눈여겨볼 대목은 따로 있습니다. 일부 정보는 사용자가 볼 수 있는 대화에서는 이미 삭제된 상태였는데, 숨겨진 추론 과정에는 그대로 남아 있었습니다. 지웠다고 생각한 것이 지워지지 않았던 것입니다.

암호화돼 있으니 공개해도 된다는 판단

이번에 확인된 문제의 구조를 이해하려면 요즘 AI가 답을 만드는 방식부터 볼 필요가 있습니다. 추론형 AI는 복잡한 질문에 답하기 전에 내부에서 여러 단계의 분석을 거칩니다. 모델 제공사들은 이 과정을 지식재산 보호와 정보 유출 방지를 위해 그대로 공개하지 않고, 암호화된 블록 형태로 처리합니다.

여기서 중요한 것은 이 블록을 제공사가 서버에 보관하지 않는다는 점입니다. 저장 비용 부담 때문에 암호화된 상태로 사용자 쪽에 돌려주고, 사용자는 다음 요청을 보낼 때 이 블록을 다시 함께 실어 보냅니다. 대화의 맥락이 이어지는 것은 이 왕복 덕분입니다. 결국 이 데이터는 제공사의 서버가 아니라 우리 조직의 애플리케이션과 로그, 캐시 안에 쌓입니다.

'독점 LLM API에서 추론 흔적 훔치기'라는 제목의 이 연구는 여기서 구조적 허점을 짚었습니다. 암호화된 블록이 서로 다른 세션과 서로 다른 사용자, 나아가 같은 제공사 안의 다른 모델들 사이에서 완전히 호환되고 서로 바꿔 쓸 수 있다는 사실입니다. 특정 세션이나 특정 사용자에게 묶여 있지 않다는 뜻입니다.

연구진이 한 일은 암호를 깨는 것이 아니었습니다. 암호키를 훔치지도, 제공사 서버를 해킹하지도 않았습니다. 대신 확보한 암호화 블록을 같은 제공사의 더 약하고 안전장치가 덜 걸린 모델에 입력한 뒤, 그 내용을 평문으로 다시 출력하도록 유도했습니다. 정문이 아니라 옆문으로 들어간 셈입니다. 국내 기업들이 업무 시스템에 흔히 연동하는 해외 대형 AI 제공사 세 곳의 API가 모두 대상이었습니다.

연구진은 이 성질을 이용해 또 다른 공격도 시험했습니다. 악성 명령을 사람이 읽을 수 없는 추론 블록 안에 심어 다른 작업에 전달했더니, AI가 그 명령을 자신의 이전 생각으로 받아들여 공격자가 원하는 행동을 수행했습니다. 사용자 화면에는 아무것도 보이지 않습니다. 모델이 자기 자신의 이전 추론은 의심 없이 신뢰하는 성질을 역이용한 것인데, 이런 명령이 한번 섞여 들어가면 이후 작업까지 계속 영향을 미칠 수 있습니다.

제공사 입장에서의 손실도 있습니다. 추론 과정을 감추는 목적 자체가 경쟁사가 이를 학습해 저렴한 복제 모델을 만드는 일을 막는 데 있었는데, 가장 약한 모델을 통해 우회할 수 있다면 그 방어는 사실상 의미를 잃습니다. 실제로 연구진은 복원한 추론 내용을 공개 가중치 모델들의 추론과 비교하는 실험까지 진행했습니다. 다만 이 대목은 제공사들의 지식재산 문제이고, API를 가져다 쓰는 기업 입장에서 더 중요한 것은 앞서 살펴본 민감정보 노출 쪽입니다.

다만 과장은 경계해야 합니다. 이 연구가 일반 사용자의 비공개 대화를 누구나 열어볼 수 있다는 뜻은 아닙니다. 공격자는 먼저 공개된 에이전트 로그 등에서 암호화된 블록을 확보해야 했고, 이를 처리할 수 있는 같은 제공사의 호환 모델에도 접근해야 했습니다. 실제 악용 사례가 확인된 것도 아닙니다. 연구진은 발견 내용을 각 제공사와 코드·모델 공유 플랫폼 운영사에 전달했고, 대응 조치 이후 논문에서 사용한 주요 추출 공격은 더 이상 재현되지 않는다고 밝혔습니다.

그래도 남는 질문은 우리 조직 쪽에 있습니다

공격 경로가 막혔다는 소식으로 이 이슈를 덮기 어려운 이유가 있습니다. 이번 사건이 드러낸 진짜 문제는 특정 취약점이 아니라, 우리가 데이터를 분류하는 기준 자체에 있기 때문입니다. 많은 조직이 '사람이 읽을 수 있는가'를 기준으로 민감정보를 걸러냅니다. 화면에 주민등록번호가 보이면 지우고, 로그에 이메일 주소가 찍히면 마스킹합니다. 그런데 AI 연동 환경에서는 사람이 읽지 못하는 형태로 저장된 데이터도 AI는 다시 읽어낼 수 있습니다. 읽을 수 없다는 것은 없다는 것과 다릅니다.

이 착각이 특히 위험한 이유는, 보안 점검 항목이 대개 사람의 눈을 기준으로 설계돼 있기 때문입니다. 유출 여부를 확인할 때도 화면과 문서를 훑어보는 방식이 기본이고, 자동 탐지 도구 역시 알려진 형태의 문자열 패턴을 찾는 데 맞춰져 있습니다. 사람이 읽을 수 없고 알려진 패턴에도 걸리지 않는 데이터는 어느 쪽 그물에도 잡히지 않습니다. 결국 점검을 했는데도 남아 있는 상태, 그러면서 점검을 마쳤다고 기록되는 상태가 만들어집니다.

이 문제가 남의 일이 아닌 이유는, API 원본 응답이 생각보다 여러 곳에 기록되기 때문입니다. 애플리케이션 로그와 관측 도구, 요청 캐시, 개발자 워크스테이션의 임시 파일, 자동 빌드 서버의 실행 기록에 원본이 그대로 남는 경우가 흔합니다. 실제로 공개 저장소에 노출되는 자격증명 문제는 AI 도구 확산과 함께 눈에 띄게 악화됐습니다.

한 보안 기업의 2026년 조사에 따르면 2025년 한 해 동안 공개 저장소 커밋에서 새로 발견된 하드코딩 자격증명은 약 2,865만 건으로 전년 대비 34퍼센트 늘었고, 그중 AI 서비스와 관련된 유출은 81퍼센트 증가했습니다. AI 도구를 연결하는 설정 파일에서만 2만 4천여 건의 자격증명이 확인됐고, 자격증명이 발견된 손상 장비의 59퍼센트는 개인 노트북이 아니라 공용 빌드 서버였습니다. 개인의 실수 문제가 아니라 조직 인프라의 문제라는 뜻입니다.

이번이 처음 제기된 문제도 아닙니다. 앞서 2025년에는 추론형 대형 모델이 답변 자체는 조심스럽게 내놓으면서도 내부 추론 과정에는 사용자가 알려준 개인정보를 그대로 풀어놓는다는 연구가 발표된 바 있습니다. 최근에는 AI 도구를 외부 시스템과 연결해 주는 표준 규약의 설정 파일에서 자격증명이 대량으로 노출된 사례, AI 코딩 도구가 악성 저장소를 여는 것만으로 개발자의 API 키를 흘릴 수 있었던 취약점도 잇따라 보고됐습니다. 개별 사안은 서로 다르지만 형태는 같습니다. AI를 업무에 연결하는 지점마다 새로운 데이터 통로가 생기고, 그 통로에서 만들어지는 부산물이 기존 보안 점검 항목에는 아직 들어 있지 않다는 것입니다.

개인정보 파기 의무는 형태를 가리지 않습니다

여기서 법이 요구하는 기준을 다시 볼 필요가 있습니다. 개인정보처리자는 보유기간의 경과나 처리 목적 달성 등으로 해당 개인정보가 불필요하게 되었을 때에는 지체 없이 파기해야 합니다(제21조 1항). 여기서 말하는 파기 대상은 정형화된 데이터베이스 안의 고객 테이블만이 아닙니다. 개인을 알아볼 수 있는 정보가 담겨 있다면 로그 파일이든 캐시든 임시 파일이든 마찬가지입니다. 파일이 어느 폴더에 있는지, 사람이 읽을 수 있는 형태인지는 판단 기준이 아닙니다.

파기 방법도 정해져 있습니다. 전자적 파일 형태는 복원이 불가능한 방법으로 영구 삭제해야 하고, 그 밖의 기록물이나 기록매체는 파쇄 또는 소각하도록 규정합니다(시행령 제16조 1항). 하위 고시는 여기에 더해 전용 소자장비를 이용해 삭제하거나, 데이터가 복원되지 않도록 초기화 또는 덮어쓰기를 수행하는 방법을 구체적으로 제시합니다. 그리고 이 의무를 위반해 필요한 조치를 하지 않으면 과태료 대상이 됩니다(제75조 2항 4호).

책임 구조도 미리 정리해 둘 필요가 있습니다. 개인정보가 포함된 업무를 외부 AI 서비스에 넘겨 처리하는 형태라면 처리 위탁의 성격을 띠게 되고, 이 경우 위탁자는 수탁자가 개인정보를 안전하게 처리하는지 감독할 책임을 집니다(제26조 4항). 그런데 실무에서 더 자주 문제가 되는 것은 제공사 쪽이 아니라 우리 조직 쪽에 남는 데이터입니다. 앞서 살펴본 것처럼 추론 블록은 제공사 서버가 아니라 우리 애플리케이션과 로그에 쌓이기 때문입니다. 계약서에 제공사의 데이터 보관 정책만 확인해 두고 정작 내부 로그의 보존과 파기 기준은 비어 있는 경우가 적지 않습니다.

아울러 개인정보처리자는 개인정보가 분실·도난·유출·위조·변조 또는 훼손되지 않도록 기술적·관리적·물리적 조치를 다해야 합니다(제29조). 이 의무는 개인정보가 살아 있는 동안뿐 아니라 파기하기로 결정한 순간부터 실제 파기가 끝나는 순간까지 그대로 이어집니다. AI 연동 로그처럼 관리 주체가 애매한 데이터는 바로 이 구간에서 통제가 끊기기 쉽습니다. 누구의 데이터인지, 어느 부서가 보존 기한을 정하는지 정해져 있지 않으면, 아무도 지우지 않은 채 수년이 흐릅니다.

지금 점검해볼 부분

가장 먼저 확인할 것은 목록입니다. AI API를 연동한 서비스가 사내에 몇 개인지, 그 응답이 어느 시스템 어느 경로에 기록되는지 실제로 파악하고 있는 조직은 많지 않습니다. 개발 단계에서 디버깅용으로 켜 둔 상세 로깅이 운영 환경에 그대로 남아 있는 경우도 드물지 않습니다. 연동 서비스별로 로그가 남는 위치와 보존 기한, 관리 담당자를 한 장으로 정리해 두는 것만으로도 이후 판단이 훨씬 수월해집니다.

두 번째는 마스킹 기준을 어디에 적용하고 있는지 확인하는 일입니다. 화면에 표시되는 대화 내용만 걸러내고 API 원본 응답은 그대로 저장하고 있다면, 이번 연구가 지적한 상황과 정확히 같은 구조에 놓여 있는 것입니다. 걸러내야 할 대상에는 사람이 읽을 수 없는 추론 블록과 서명값도 포함해야 합니다.

세 번째는 외부 공개 절차입니다. 실행 기록이나 예제 코드를 외부 저장소나 데이터셋으로 내보낼 때, 눈으로 확인하는 검토만으로는 부족합니다. 원본 응답을 가공 없이 올리지 않는다는 원칙을 두고, 자동 탐지 도구를 함께 적용하는 편이 안전합니다.

네 번째는 보존 기한입니다. 접속기록처럼 법이 최소 보관 기간을 정해 둔 항목과 달리, AI 연동 로그는 기준이 없는 경우가 많습니다. 기준이 없으면 기본값은 '영구 보관'이 됩니다. 목적에 필요한 기간을 정해 두고, 그 기간이 지나면 지체 없이 파기 대상으로 넘기는 절차를 세워야 합니다. 이때 운영 서버의 로그만 지우고 백업본을 그대로 남겨두는 일이 흔한데, 백업까지 포함해야 파기가 끝난 것으로 볼 수 있습니다.

다섯 번째는 자격증명 관리입니다. 로그에서 발견된 키와 토큰이 여전히 유효하다면 노출 자체가 곧 침해로 이어집니다. 한 조사에서는 몇 해 전 유출된 자격증명 중 상당수가 여전히 유효한 상태로 남아 있었습니다. 유효기간을 짧게 잡고 주기적으로 교체하는 절차를 두면, 로그에 흔적이 남더라도 피해 범위를 줄일 수 있습니다.

이 다섯 가지를 매번 새로 판단하려 하면 담당자에 따라 기준이 달라지고, 시간이 지날수록 흐려집니다. 한 번 정리한 기준을 문서로 남겨 다음 담당자에게 그대로 넘기는 편이 낫습니다. 거창한 규정집일 필요는 없습니다. 연동 서비스 목록과 로그 위치, 보존 기한, 담당자를 적어 둔 한 장짜리 표만으로도 판단이 흔들리는 일을 크게 줄일 수 있습니다.

앞으로 달라질 부분

제공사 쪽에서는 암호화된 블록을 특정 세션과 사용자에 묶어 두는 방향의 개선이 논의되고 있습니다. 블록이 발급된 세션 밖에서는 아예 해석되지 않도록 하면 이번에 확인된 재사용 경로 자체가 막히기 때문입니다. 다만 이런 개선이 적용되더라도, 이미 우리 시스템에 쌓여 있는 과거 로그가 사라지는 것은 아닙니다. 앞으로의 위험은 줄어들어도 지금까지 축적된 데이터는 그대로 남습니다.

국내 규제 흐름도 같은 방향을 보고 있습니다. 개인정보의 안전성 확보조치 기준은 2025년 10월 개정되면서 인공지능과 클라우드 같은 기반 기술의 변화에 대응한다는 점을 개정 배경으로 밝혔고, 접근 권한과 접근통제, 접속기록 보관에 관한 조항의 적용 범위를 넓혔습니다. AI를 업무에 붙이는 과정에서 생기는 데이터가 규제 논의의 대상으로 올라오고 있다는 신호로 읽힙니다. 기준이 구체화되기를 기다리기보다, 지금 우리 조직에 무엇이 어디에 쌓이고 있는지부터 파악해 두는 편이 나중에 훨씬 수월합니다.

결국 마지막 관문은 물리 매체입니다

여기까지가 논리적 삭제의 영역입니다. 그런데 삭제 명령을 내렸다고 데이터가 사라지는 것은 아닙니다. 일반적인 삭제나 포맷은 파일 시스템의 색인 정보만 지울 뿐, 데이터가 실제로 기록된 영역은 매체에 그대로 남는 경우가 대부분입니다. 로그를 지웠다고 생각한 뒤에도 그 흔적은 디스크 위에 남아 있을 수 있습니다.

그래서 로그가 얹혀 있던 물리 매체를 처분하는 시점이 마지막 관문이 됩니다. 로그 서버의 디스크를 교체할 때, 백업 스토리지를 세대교체할 때, 개발자에게 지급했던 노트북을 회수해 재지급하거나 처분할 때가 그렇습니다. 이 시점에 매체를 어떻게 처리했는지가, 앞선 모든 관리 조치의 실효성을 결정합니다.

특히 주의해야 할 것은 개발 환경입니다. 운영 서버는 관리 대상이 명확하고 담당자가 지정돼 있는 경우가 많지만, 개발자 개인에게 지급된 장비나 테스트용으로 잠깐 쓰고 방치된 서버는 목록에서 빠지기 쉽습니다. 그런데 API 원본 응답을 가장 자주 그대로 저장하는 곳이 바로 개발 환경입니다. 상세 로깅을 켜 두고 응답 전체를 파일로 떨어뜨려 확인하는 작업이 일상적으로 이뤄지기 때문입니다. 프로젝트가 끝나고 몇 년이 지난 뒤, 그 장비를 처분할 차례가 왔을 때 안에 무엇이 들어 있는지 아무도 기억하지 못하는 상황이 만들어집니다.

매체 종류에 따라 방법이 달라진다는 점도 함께 짚어야 합니다. 하드디스크나 LTO 백업테이프처럼 자성 방식으로 데이터를 기록하는 매체는 디가우징으로 자기 정보 자체를 지울 수 있습니다. 반면 SSD와 NVMe, eMMC 같은 플래시 매체에는 디가우징이 통하지 않습니다. 자성으로 기록하는 방식이 아니기 때문입니다. 플래시 매체는 물리적 파기나 검증된 소프트웨어 기반 영구삭제로 처리해야 하고, 특히 웨어 레벨링과 오버프로비저닝 영역 때문에 단순 초기화만으로는 잔존 위험이 남습니다. AI 연동 서비스의 로그와 캐시는 응답 속도 때문에 플래시 매체에 올라가 있는 경우가 많아, 이 구분이 실무에서 그대로 문제가 됩니다.

알테크코리아가 이 마지막 관문을 담당합니다.

데이터 파기 브랜드 DieHDD™를 통해 디가우징, 유압천공, 분쇄파기, 소각파기 네 가지 방식을 운용하며, 보안 수준이 높은 자료는 디가우징과 물리파기를 함께 적용하는 더블크러시 방식으로 처리합니다. 재사용을 전제로 데이터만 지워야 하는 장비는 블랑코(Blancco) 기반의 인증 영구삭제로 처리하고 검증 리포트를 함께 제공합니다. 알테크코리아는 블랑코의 공식 한국 파트너사입니다.

전기가 없는 환경이나 매체를 반출하기 어려운 현장을 위해서는 유압으로 작동하는 수동 파기 장치 waZac을 활용할 수 있습니다. 파기 이후 재사용이 가능한 자산은 ITAD 절차에 따라 평가와 재제조를 거치고, 남는 잔여물과 전기·전자폐기물은 허가 범위 안에서 적법하게 처리합니다. 알테크코리아는 ISO 9001과 ISO 14001 인증, 전기·전자폐기물 처리 및 수집·운반 허가를 보유하고 있으며 KISIA 회원사입니다.

처리 절차는 사전 확인에서 시작합니다. 대상 장비의 종류와 수량, 담긴 자료의 민감도를 미리 파악하고 일정과 방식을 협의합니다. 민감도가 높은 자료라면 담당자가 입회한 상태에서 현장 파기를 진행할 수 있고, 그렇지 않은 경우에도 인수인계 시점과 운송 책임 범위를 문서로 남깁니다. 매체가 사무실 문을 나서는 순간부터 작업이 끝나는 순간까지 통제가 끊기지 않도록 하는 것이 이 절차의 목적입니다.

작업 과정에서 남기는 기록도 함께 봐야 합니다. 처리 대상 장비의 종류와 시리얼 정보, 작업 일시와 장소, 적용한 파기 방식, 입회자와 작업자 확인, 파기 전후 사진이 결과 리포트로 정리됩니다. 담당자가 바뀌거나 한참 시간이 지난 뒤에 그때의 처리 내역을 다시 확인해야 하는 상황이 오더라도, 문서만 찾아보면 답할 수 있게 하는 것이 이 기록의 목적입니다.

마무리

이번 연구가 남긴 메시지는 기술적인 것이라기보다 판단 기준에 관한 것입니다. 암호화돼 있으니 공개해도 안전하다는 판단, 사람이 읽을 수 없으니 개인정보가 아니라는 판단, 삭제 명령을 내렸으니 지워졌다는 판단이 모두 같은 구조의 착각입니다. 확인하지 않은 것을 안전하다고 가정하는 것입니다.

AI를 업무에 연동하는 속도는 앞으로 더 빨라질 것입니다. 그만큼 어디에 무엇이 남는지 파악하지 못한 데이터도 함께 늘어납니다. 지금 연동 중인 서비스의 로그가 어느 서버 어느 디스크에 쌓이고 있는지, 그 디스크를 교체할 때 어떤 절차로 처리하는지를 한 번 확인해 보는 것으로 시작할 수 있습니다. 나중에 설명해야 하는 상황이 왔을 때, 그 확인 여부가 답할 수 있는 조직과 그렇지 못한 조직을 가릅니다.

법령 원문

개인정보 보호법 제21조(개인정보의 파기) 제1항 "개인정보처리자는 보유기간의 경과, 개인정보의 처리 목적 달성, 가명정보의 처리 기간 경과 등 그 개인정보가 불필요하게 되었을 때에는 지체 없이 그 개인정보를 파기하여야 한다. 다만, 다른 법령에 따라 보존하여야 하는 경우에는 그러하지 아니하다."

개인정보 보호법 시행령 제16조(개인정보의 파기방법) 제1항 "개인정보처리자는 법 제21조에 따라 개인정보를 파기할 때에는 다음 각 호의 구분에 따른 방법으로 해야 한다.

전자적 파일 형태인 경우: 복원이 불가능한 방법으로 영구 삭제(다만, 기술적 특성으로 영구 삭제가 현저히 곤란한 경우에는 법 제58조의2에 해당하는 정보로 처리하여 복원이 불가능하도록 조치해야 한다)

제1호 외의 기록물, 인쇄물, 서면, 그 밖의 기록매체인 경우: 파쇄 또는 소각"

개인정보 보호법 제29조(안전조치의무) "개인정보처리자는 개인정보가 분실·도난·유출·위조·변조 또는 훼손되지 아니하도록 내부 관리계획 수립, 접속기록 보관 등 대통령령으로 정하는 바에 따라 안전성 확보에 필요한 기술적·관리적 및 물리적 조치를 하여야 한다."

개인정보 보호법 제75조(과태료) 제2항 제4호 제21조 제1항을 위반하여 개인정보의 파기 등 필요한 조치를 하지 아니한 자에게는 3천만원 이하의 과태료를 부과한다는 취지를 정하고 있다.