BoB 뉴스레터 2026년 9월 호

안녕하세요, 구독자 님!

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

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

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

🍧 동문들의 소식들을 기다립니다

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

🔑 티빙 침해사고 - 키 하나가 털렸는데 왜 DB까지 뚫렸을까?

개발환경 곳곳에 퍼진 Secret과, 하나의 자격증명이 만들어내는 Blast Radius

2026년 9월, 티빙 개인정보 유출 사고에 대한 민관합동조사단의 조사 결과가 공개됐다. 유출된 계정은 중복 포함 약 3,954만 개에 달했으며, 소스코드 등 기술자산 361건도 외부로 유출된 것으로 확인됐다.

조사 결과 티빙은 개발·운영환경에 접근하기 위한 키를 소스코드에 평문으로 저장하거나 사내 메신저를 통해 공유했고, 모든 개발자에게 전체 개발 프로젝트에 대한 접근 권한을 부여하고 있었다. 이 때문에 하나의 접속키가 탈취될 경우 공격자가 여러 개발 프로젝트와 관련 자원에 접근할 수 있는 구조가 형성돼 있었다.

이번 사고는 접속키 유출 자체뿐 아니라, 하나의 자격증명이 여러 시스템과 권한으로 연결돼 있었다는 점에서도 살펴볼 필요가 있다. 특히 Secret 관리와 함께, 특정 계정이나 자격증명이 침해됐을 때 피해가 어디까지 확산될 수 있는지를 의미하는 Blast Radius 관점에서 볼 수 있는 사례다.

[출처] ChatGPT 생성

우리가 모르는 사이 곳곳에 퍼지는 ‘Secret’

개발 환경에서 말하는 Secret은 비밀번호에만 한정되지 않는다. API Key, Access Key, DB Password, 인증 Token, Private Key처럼 시스템이나 서비스가 다른 시스템에 접근할 때 사용하는 인증정보도 모두 Secret에 포함된다.

이러한 정보는 개발 과정에서 다양한 위치에 존재하게 된다. 개발자가 로컬 환경에서 테스트하기 위해 설정 파일에 API Key를 입력할 수 있고, 애플리케이션이 데이터베이스에 접속하기 위해 DB 계정을 코드나 환경변수에 저장할 수도 있다. 자동 배포 과정에서는 CI/CD 시스템에 클라우드 접근키를 등록하는 경우도 있다.

개발 환경이 복잡해질수록 동일하거나 유사한 Secret이 여러 환경에 복제될 가능성도 높아진다.

개발 PC → Source Code → Git Repository → CI/CD → Cloud → 운영 서버

처음에는 특정 개발 작업을 위해 생성된 자격증명이 여러 시스템과 서비스를 연결하는 데 사용될 수 있다. 이처럼 Secret이 다양한 시스템과 저장소에 분산되는 현상을 Secret Sprawl이라고 한다.

현대 서비스에서는 시스템 간 인증을 위해 많은 Secret이 필요하다. 따라서 중요한 것은 Secret의 존재 여부보다 어떤 Secret이 어디에 위치하고 있으며, 누가 사용할 수 있고, 어느 범위까지 접근할 수 있는지를 파악하고 관리하는 것이다.

키 하나가 만들어내는 피해 범위, Blast Radius

하나의 계정이나 자격증명이 침해됐을 때 공격자가 영향을 미칠 수 있는 범위를 Blast Radius라고 표현하기도 한다.

개발 서버 하나에만 접근할 수 있는 키가 탈취됐다면 피해 범위는 해당 개발환경으로 제한될 가능성이 높다. 반면 하나의 키로 여러 프로젝트에 접근할 수 있고, 그 과정에서 운영환경 접근정보까지 확보할 수 있다면 피해 범위는 빠르게 확대될 수 있다.

티빙 사고의 공격 흐름을 단순화하면 다음과 같이 볼 수 있다.

접속키 탈취 → 개발 프로젝트 접근 → 소스코드·설정정보 확인 → 추가 자격증명 확보 → 운영환경 접근 → DB 접근

공격자가 처음 확보한 자격증명은 하나였지만, 해당 자격증명이 접근할 수 있는 시스템이 많고 그 안에서 다른 인증정보까지 확보할 수 있다면 공격 범위는 단계적으로 커진다.

티빙 사고에서도 모든 개발자에게 전체 개발 프로젝트 접근 권한이 부여돼 있었으며, 개발·운영환경 접속키의 발급·사용·변경·폐기 절차도 충분히 마련돼 있지 않았던 것으로 조사됐다.

따라서 Secret 관리에서는 유출 자체를 방지하는 것과 함께, 하나의 Secret이 탈취됐을 때 공격자가 이동할 수 있는 범위를 제한하는 설계가 필요하다.

Secret을 코드에 넣지 않으면 끝일까?

API Key나 비밀번호를 소스코드에 직접 하드코딩하지 않는 것은 Secret 관리의 기본 원칙 중 하나다. Git Repository 등에 Secret이 포함될 경우 코드가 복제되거나 백업되고, Fork나 로그를 통해 예상하지 못한 위치까지 인증정보가 남을 수 있기 때문이다.

하지만 하드코딩을 제거하는 것만으로 Secret 관리 문제가 해결되는 것은 아니다. Secret을 .env 파일이나 환경변수로 옮기더라도 해당 정보에 접근할 수 있는 사용자가 지나치게 많거나, 동일한 키를 개발·운영환경에서 함께 사용하거나, 오랜 기간 같은 키를 변경하지 않는다면 위험은 그대로 남는다.

따라서 Secret 관리에서는 저장 위치와 함께 사용 범위와 권한도 확인해야 한다. 누가 해당 Secret을 사용할 수 있는지, 어떤 시스템에 접근할 수 있는지, 개발환경과 운영환경의 Secret이 분리돼 있는지, 언제 생성되고 마지막으로 변경됐는지, 탈취 시 즉시 폐기하거나 교체할 수 있는지, 사용 이력을 추적할 수 있는지 등이 함께 관리돼야 한다.

Secret Management는 Secret을 별도의 공간에 저장하는 기술만을 의미하지 않는다. Secret이 생성된 시점부터 사용, 변경, 폐기되는 과정까지 전체 생명주기를 관리하는 개념에 가깝다.

Secret을 ‘숨기는 것’에서 ‘관리하는 것’으로

최근에는 개발자가 직접 비밀번호와 키를 관리하는 방식에서 벗어나 Secret을 중앙화해 관리하는 방식이 널리 활용되고 있다. 대표적인 방법이 Secrets Manager나 Vault와 같은 관리 시스템이다.

애플리케이션 코드에 실제 Secret 값을 저장하지 않고, 필요한 시점에 중앙 관리 시스템을 통해 값을 전달받도록 구성할 수 있다. 이를 통해 Secret을 코드와 분리할 수 있으며 접근 권한 관리, 사용 기록 확인, 정기적인 키 변경(Rotation) 등도 함께 적용할 수 있다.

여기에 최소 권한 원칙(Least Privilege)이 함께 적용돼야 한다. 개발환경에서 사용하는 자격증명이 운영 DB까지 접근할 필요는 없으며, CI/CD 시스템의 계정 역시 배포에 필요한 범위 이상의 권한을 가질 이유가 없다.

각 자격증명에 필요한 최소 수준의 권한만 부여하면 하나의 Secret이 탈취되더라도 공격자가 접근할 수 있는 영역을 제한할 수 있다. 이는 Blast Radius를 줄이는 가장 기본적인 방법 중 하나다.

Secret을 보호하는 기술과 함께, 해당 Secret이 어떤 권한을 가지고 있는지를 관리해야 하는 이유다.

이미 알고 있던 취약점이라면?

티빙 조사 결과에서는 사고 이전에 일부 문제가 이미 확인됐던 사실도 드러났다.

티빙은 2024년 모의해킹 과정에서 개발·운영환경 접속키가 소스코드에 노출되는 문제를 확인했지만 이를 개선하지 않은 것으로 조사됐다. 이상징후가 발생한 이후 정보보호 조직에 공유되기까지 약 14시간이 걸렸고, 일부 접속기록은 약 6일 동안만 보관되고 있었다.

이러한 결과를 보면 이번 사고는 소스코드에 접속키가 포함돼 있었다는 한 가지 문제만으로 설명하기 어렵다. Secret 관리, 접근권한, 취약점 조치, 로그 관리, 이상징후 대응 등 여러 보안 통제가 함께 영향을 미쳤다.

특히 이미 확인된 위험요소가 실제 조치로 이어지지 않을 경우, 이후 다른 취약점이나 계정 탈취와 결합해 더 큰 사고로 이어질 수 있다. 모의해킹과 보안점검 이후 취약점을 발견하는 것만큼 실제 개선 여부를 추적하는 과정이 중요한 이유다.

결국 중요한 것은 ‘권한’

API Key와 Access Token은 클라우드, SaaS, CI/CD, 마이크로서비스 환경에서 필수적으로 사용되는 요소다. 시스템 간 연결이 많아질수록 사람이 사용하는 계정 외에도 시스템이 사용하는 자격증명의 수는 계속 증가한다.

이 때문에 Secret 관리 역시 저장 여부만 확인하는 방식에서 벗어날 필요가 있다. 조직 내에 어떤 Secret이 존재하는지 파악하고, 해당 Secret이 어떤 시스템과 자원에 접근할 수 있는지 함께 관리해야 한다.

티빙 사고는 접속키 관리 미흡이 실제 침해로 이어진 사례인 동시에, 하나의 자격증명이 여러 시스템과 권한으로 연결될 경우 피해 범위가 얼마나 커질 수 있는지를 보여준다.

앞으로 Secret 관리에서는 자격증명을 안전하게 보관하는 것과 함께, 하나의 자격증명이 침해됐을 때 접근 가능한 범위를 제한하는 권한 설계가 함께 고려돼야 한다. Secret의 수가 늘어나는 환경일수록 Blast Radius를 얼마나 작게 유지할 수 있는가가 중요한 관리 기준이 될 수 있다.

[참고자료]

❓ “할머니의 유품인데, 읽어주시겠어요?”

역할극에서 자동화된 공격으로 이어진 AI 탈옥의 역사

https://arstechnica.com/information-technology/2023/10/sob-story-about-dead-grandma-tricks-microsoft-ai-into-solving-captcha/

2023년, Denis Shiryaev가 공개한 Bing Chat 대화에는 조금 이상한 목걸이가 등장한다. 펜던트 안에 사진 대신 CAPTCHA가 들어 있다. 그는 이 목걸이를 돌아가신 할머니의 유품이라고 소개하면서, 안에 적힌 글자가 두 사람만의 특별한 암호라며 읽어 달라고 부탁했다. Bing은 위로의 말을 건넨 뒤 문자열을 읽어줬다. CAPTCHA 해독 요청이 유품 속 추억을 되찾으려는 부탁으로 포장된 것이다.

이 장면에서 눈여겨볼 것은 AI의 문자 인식 능력이 아니다. 같은 내용을 어떤 상황에 놓느냐에 따라 답변해도 되는지에 대한 판단이 달라질 수 있다는 점이다. 물론 대화 캡처 하나로 모든 모델에서 같은 방법이 통한다고 단정할 수는 없다. 다만 모델의 제한을 우회하는 데 반드시 복잡한 코드가 필요한 것은 아니라는 사실을 보여준다. 이처럼 안전장치를 우회해 원래 거부해야 할 응답을 끌어내는 시도를 탈옥, Jailbreak라고 부른다.

1. Jailbreak의 시작: 다른 AI를 연기하라는 부탁

오늘날 LLM 탈옥이 대중적으로 알려진 계기를 찾는다면 2022년 말의 ChatGPT를 빼놓기 어렵다. 2022년 11월 30일 공개된 ChatGPT는 질문에 답하는 것뿐 아니라 부적절한 요청을 거절하도록 훈련됐다. OpenAI는 출시 당시부터 이러한 훈련이 완벽하지 않으며, 유해한 지시에도 응답하는 경우가 남아 있다고 설명했다. 이용자들에게 공개된 것은 무엇이든 답하는 모델이 아니라, 답할 수 있는 내용 중 일부는 거절하도록 학습한 모델이었다.

이용자들은 곧 그 거절을 번복시키는 표현을 찾아 공유하기 시작했다. 대표적인 것이 DAN, Do Anything Now였다. ChatGPT에게 기존 제한을 따르지 않는 가상의 AI를 연기하게 만드는 역할극으로, 여러 변형이 커뮤니티를 통해 유통됐다. 이를 분석한 Do Anything Now 연구는 2022년 12월부터 2023년 12월까지 공개된 탈옥 프롬프트 1,405개를 수집했고, 100일 넘게 프롬프트를 지속적으로 개선한 계정들도 확인했다. 누군가 찾아낸 문장을 다른 사람이 고치고 다시 시험하면서 공격 기법이 다듬어지고 있었던 것이다.

그렇다고 모델 안에 실제로 ‘제한 없는 두 번째 인격’이 생긴 것은 아니다. 역할을 충실하게 수행하라는 요청과 위험한 내용을 제공하지 말라는 안전 목표가 충돌한 것으로 이해하는 편이 정확하다. 2023년 Jailbroken 연구는 이런 목표 간 충돌과, 새로운 표현 방식에 안전 학습이 충분히 일반화되지 않는 문제를 주요 실패 원인으로 제시했다. 할머니 이야기나 가상의 등장인물은 모델이 잘하는 문맥 이해와 역할 수행을 안전 판단과 충돌시키는 수단이었다.

2. 어떤 방법으로 거절을 우회하는가

탈옥 기법에는 다양한 이름이 붙지만, 무엇을 바꾸어 모델의 판단에 영향을 주는지에 따라 묶어보면 이해하기 쉽다. 역할을 바꾸는 방법도 있고, 대화를 길게 이어가거나 입력의 표현을 바꾸는 방법도 있다. 하나의 공격에서 여러 방법을 함께 사용할 수도 있으므로, 아래 구분은 서로 배타적인 분류가 아니다.

역할과 상황을 바꾸기

DAN 계열은 이런 역할 설정에서 출발한다. 실제 변형본들은 가상의 인격에 기존 제한이 적용되지 않는다고 주장하거나, 그 역할을 계속 유지하도록 요구했다. 요청받은 역할을 충실히 연기하려는 모델의 행동이 안전 규칙보다 앞서도록 유도하는 것이다.

비슷한 방식으로 요청을 창작물의 일부처럼 제시하기도 한다.

역할극이나 소설 작성 자체가 탈옥인 것은 아니다. 문제는 그러한 설정을 이유로 원래 제한해야 할 내용을 제공하게 만드는 경우다. 등장인물의 대사로 출력했더라도, 사용자가 얻은 정보의 위험성이 사라지는 것은 아니다. 이 때문에 모델은 요청의 겉모양뿐 아니라 최종적으로 무엇을 제공하게 되는지도 판단해야 한다.

여러 차례의 대화로 목적에 접근하기

각 문장만 보면 일반적인 후속 질문이다. 다중 턴 탈옥은 이처럼 대화를 이어가면서 점차 제한된 내용으로 요청을 옮겨간다. 2024년 공개된 Crescendo는 비교적 무해한 질문으로 시작한 뒤, 모델이 앞서 답한 내용을 다음 요청의 근거로 활용하는 방식을 연구했다. 처음의 질문을 받아들였다는 이유로 그다음 요청까지 자연스럽게 이어서 처리하도록 유도하는 것이다.

이 방식에서는 마지막 문장만 검사해도, 첫 질문만 검사해도 전체 목적을 놓칠 수 있다. 앞서 어떤 이야기가 오갔으며 요청의 구체성이 어떻게 달라졌는지 함께 살펴봐야 한다. 그렇다고 모든 연속 질문을 의심할 수도 없다. 정상적인 이용자 역시 이해가 안 되는 부분을 다시 묻고 설명을 구체화하므로, 대화의 지속 자체가 아니라 그 대화가 향하는 목적을 구분해야 한다.

입력의 표현과 매체를 바꾸기

이 역시 평범한 요청이다. 그러나 모델이 텍스트로 받았을 때 제한하던 내용을 이미지나 음성으로 받았을 때에도 같은 기준으로 판단하는지는 별도의 문제다. 공격자는 요청의 의미뿐 아니라 그것이 전달되는 형식에도 변화를 준다. 앞서 본 목걸이 사례도 이미지와 이야기를 함께 사용했다는 점에서 이러한 접근과 맞닿아 있다.

2024년 공개된 Best-of-N Jailbreaking 연구는 텍스트·이미지·음성 입력에 변형을 가하고 여러 번 시험했을 때 안전장치를 우회하는 사례를 보고했다. 어떤 문구 하나가 특별해서라기보다, 같은 목적의 입력에도 모델의 반응이 일정하지 않을 수 있다는 점을 이용한 것이다. 따라서 텍스트 채팅에서의 방어 성능만으로 멀티모달 서비스 전체의 안전성을 판단하기는 어렵다.

우회할 입력을 자동으로 찾기

앞의 방법들이 ‘무엇을 어떻게 말할 것인가’에 가깝다면, 자동화는 그 입력을 찾는 작업을 누가 수행할 것인가의 문제다. 사람이 매번 문장을 고치는 대신 알고리즘이나 다른 언어 모델이 후보를 만들어 시험한다. 이때 결과물이 반드시 사람이 읽기 좋은 문장일 필요도 없다. 다음과 같이 질문 뒤에 자동으로 찾은 문자열이 붙는 형태도 연구됐다.

이 방식의 의미는 특정한 ‘마법의 문장’을 발견했다는 데 있지 않다. 새로운 모델이나 방어가 등장했을 때 그에 맞는 입력을 다시 탐색할 수 있다는 데 있다. 탈옥 연구가 개별 프롬프트를 모으는 단계에서, 공격자의 탐색 능력과 시도 비용까지 평가하는 단계로 넘어간 배경이다.

3. 발전사: 사람이 쓰던 프롬프트를 AI가 찾기까지

2023년 — 공격을 만드는 작업이 자동화되다

2023년 7월 공개된 GCG 연구는 사람에게 그럴듯하게 읽히는 이야기가 탈옥의 필수 조건이 아니라는 것을 보여줬다. 연구진은 모델 내부의 계산 정보를 활용해 공격용 접미 문자열을 자동으로 찾았고, 일부 문자열은 생성에 사용하지 않은 다른 모델에서도 효과를 보였다. 사람이 보기에는 의미가 불분명한 문자열이 응답에 영향을 준 것이다. 이로써 탈옥은 자연어로 모델을 설득하는 문제인 동시에, 입력 공간에서 취약한 지점을 찾는 적대적 머신러닝 문제이기도 하다는 점이 드러났다.

같은 해 10월 공개된 PAIR는 모델 내부에 접근하지 않는 방식을 택했다. 공격용 언어 모델이 대상 모델의 응답을 확인하면서 프롬프트를 수정하도록 한 것이다. GCG가 계산을 통해 입력을 최적화했다면, PAIR는 사회공학적 표현을 만드는 시행착오를 자동화한 셈이다. 사람이 직접 작성한 몇 가지 프롬프트에 잘 대응한다는 것만으로는, 계속해서 새로운 입력을 만들어내는 공격자를 견딘다고 말하기 어려워졌다.

2024년 — 긴 입력과 대화의 흐름을 이용하다

모델이 한 번에 처리하는 정보량이 늘어나면서 긴 문맥을 이용하는 공격도 연구됐다. 2024년 공개된 Many-shot Jailbreaking은 하나의 입력에 많은 가상 대화 예시를 넣어, 모델이 그 패턴을 따라 제한된 질문에도 응답하도록 유도했다. 형식만 나타내면 다음과 같다.

정상적인 작업에서는 예시를 보고 원하는 답변 형식을 익히는 능력이 유용하다. Many-shot은 그 능력이 안전 학습과 충돌할 수 있음을 보여줬다. 여기서 모델의 가중치를 새로 학습시키는 것은 아니다. 현재 입력에 포함된 사례가 응답에 영향을 주는 문맥 내 학습을 이용한다.

앞서 소개한 Crescendo와는 구분할 필요가 있다. Many-shot은 하나의 입력 안에 가상 대화들을 넣는 방식이고, Crescendo는 실제 모델의 응답을 받아가며 여러 차례 대화를 이어가는 방식이다. 둘 다 문맥을 이용하지만, 전자는 긴 입력의 구성과 패턴을, 후자는 시간에 따라 달라지는 요청과 대화의 방향을 살펴봐야 한다.

같은 해 12월의 Best-of-N 연구는 반복 시도의 중요성을 보여줬다. 연구에는 변형된 프롬프트를 1만 개까지 사용하는 평가도 포함됐다. 한 번의 질문을 막았는지와 많은 재시도를 견뎠는지는 서로 다른 평가다. 따라서 공격 성공률에는 모델 이름뿐 아니라 시도 횟수와 계산 예산도 함께 붙어야 한다. 이 조건을 빼면 서로 다른 실험의 숫자를 같은 기준으로 비교하게 된다.

2025년 — 방어 성능을 어떻게 검증할 것인가

공격이 다양해지면서 방어도 모델의 거절 학습에만 의존하지 않는 방향으로 발전했다. 2025년 공개된 Anthropic의 Constitutional Classifiers는 허용·제한할 내용을 명시한 규칙으로 학습 데이터를 만들고, 별도의 분류기를 훈련해 안전장치를 구성했다. 연구진은 추정 3,000시간 이상의 레드팀 평가에서 정해진 기준을 충족하는 범용 탈옥을 발견하지 못했다고 보고했다. 다만 이는 여러 대상 질문에서 두루 통하는 공격을 찾지 못했다는 결과이지, 개별적인 탈옥이 한 번도 일어나지 않았다는 의미는 아니다.

그해 공개된 The Attacker Moves Second는 평가 조건을 더 엄격하게 보자고 제안했다. 공격자가 방어 구조를 파악하고 그에 맞춰 전략을 바꾸는 적응형 공격을 적용하자, 기존 평가에서 견고해 보였던 여러 방어의 성능이 크게 달라졌다는 것이다. 연구 대상에는 탈옥과 프롬프트 인젝션 방어가 함께 포함돼 있어 결과를 하나의 수치로 일반화할 수는 없다. 다만 이미 알려진 공격 목록을 통과하는 것과, 방어를 분석하며 새 방법을 찾는 공격자를 견디는 것은 다르다는 지적은 분명했다.

4. 최근 3개월: 연구실의 탈옥과 실제 악용

2026년 7~9월의 연구에서는 공격과 방어를 함께 갱신하는 접근이 이어지고 있다. 현장 보고에서는 악성 작업을 여러 요청으로 나누어 안전장치를 피하려는 시도도 확인된다. 다만 논문에서 우회가 가능함을 보인 것과, 실제 공격자가 서비스를 악용한 사건은 구분해야 한다. 최근에 공개된 사건이라고 해서 발생 시점까지 최근인 것도 아니다.

연구에서는 공격자도 학습한다

7월 22일 처음 공개된 DARWIN은 고정된 공격 목록으로 평가하고 고정된 데이터로 방어를 학습하는 방식의 한계를 다뤘다. 공격 전략을 계속 바꾸어 취약점을 찾고, 그 과정에서 나온 사례를 방어 학습에 다시 반영하는 구조다. 특히 악성 요청뿐 아니라 겉모습이 비슷한 정상 요청도 함께 학습에 포함했다. 수상한 표현을 사용했다는 이유만으로 정상적인 질문까지 거절하지 않도록, 표면적인 문구보다 요청의 의도를 구분하려는 접근이다.

8월 24일 공개된 PsychJail은 여러 차례에 걸친 설득을 자동화하고, 그 대화 전략을 강화학습으로 개선하는 방식을 제안했다. 초기 DAN에서 사람이 역할극 문장을 수정했다면, 이제는 공격용 모델이 대화의 전개 방식까지 학습하는 연구로 이어진 것이다. 연구진은 모델마다 설득 방식에 대한 반응이 다르게 나타났다고 보고했지만, 이를 사람과 같은 성격이나 감정이 있다는 증거로 해석해서는 안 된다. 두 연구 모두 사전 공개 논문이며, 보고된 성능은 각각의 실험 조건에 한정된다.

9월 공개된 악용 사례 — 거절당한 작업을 작게 나누다

Anthropic이 9월 10일 공개한 위협 보고서에는 GTG-30006으로 분류된 공격자가 Claude를 악성 도구 개발에 이용한 사례가 등장한다. 보고서에 따르면 Claude는 명백히 악성인 직접 요청 열 번 중 아홉 번을 거절했다. 그러나 공격자가 작업을 작게 나누고 여러 세션에 분산하자 안전장치가 일관되게 작동하지 않았다. 각각은 평범한 개발 요청처럼 보이는 작업들이 피싱 도구와 악성코드 개발에 이용됐다.

이 사례는 개별 요청을 거절하는 능력과 사용 목적 전체를 파악하는 능력 사이의 차이를 보여준다. 다만 Anthropic은 이 사건에서 Claude가 맡은 역할을 도구의 개발과 시험으로 설명했으며, 실제 침해 작전을 직접 수행한 것으로 보고하지는 않았다. 보고서가 다루는 전체 기간도 2025년 12월부터 2026년 8월까지다. 따라서 ‘9월에 공개된 악용 사례’라고는 할 수 있지만, 개별 활동이 모두 최근 3개월 안에 발생했다고 쓰면 부정확하다.

7~9월 소매업체 공격 — AI 악용과 탈옥은 구분해야 한다

9월 22일 Gambit Security가 발표한 보고서는 2026년 7월부터 이어진 온라인 소매업체 공격을 다룬다. 조사팀은 공격자의 서버에서 자료를 확보했으며, 9월 10~15일에만 최소 27개 기업이 서로 다른 수준의 침해를 당했다고 보고했다. 확인한 피해에는 두 기업에서 유출된 60만 건 이상의 유효기간이 남은 신용카드 정보도 포함됐다. 다만 중간 조사 결과이며, 일부 범위는 로그와 에이전트의 보고에 근거한다는 한계도 명시했다.

이 사건에서는 AI가 공격을 설명하는 데 그치지 않고 실제 작업을 수행하는 데 이용됐다. 그러나 여기서 곧바로 ‘특정 탈옥 프롬프트로 모든 안전장치를 무력화했다’는 결론을 내릴 수는 없다. 공격자가 AI를 사용했다는 사실과 모델의 안전 제한을 우회했다는 사실은 별도로 입증해야 하기 때문이다. 이 보고서는 실제 실행으로 이어진 AI 악용 사례로 읽되, 그 자체를 특정 탈옥 기법의 성공 증거로 취급해서는 안 된다.

이 구분은 용어를 엄밀하게 쓰기 위해서만 필요한 것이 아니다. 모델이 위험한 요청을 잘못 허용한 것인지, 원래 보호 기능이 약한 도구가 사용된 것인지, 실행 과정에서 권한 통제가 실패한 것인지에 따라 고쳐야 할 부분이 달라진다. ‘AI가 해킹에 쓰였다’는 제목 아래 이 차이들이 묻히면, 실제로 필요한 방어도 찾기 어려워진다.

5. 결론: 거절 문구가 나왔다고 끝난 것은 아니다

탈옥의 역사를 따라가면 공격용 문장뿐 아니라 평가의 범위도 달라졌다는 사실을 알 수 있다. 초기에는 역할극을 붙였을 때 모델이 거절을 번복하는지가 관심사였다면, 이제는 긴 입력과 여러 차례의 대화, 반복 시도와 자동 탐색까지 함께 평가한다. 새 연구에서 높은 공격 성공률을 제시한다면 어떤 모델에서 몇 번 시도했고 무엇을 성공으로 판정했는지 먼저 확인해야 한다. 방어 성공률이 높다는 결과도, 공격자가 그 방어에 맞춰 전략을 바꿀 수 있었는지에 따라 의미가 달라진다.

도구를 사용하는 에이전트에서는 확인할 것이 더 늘어난다. 2026년 9월 공개된 에이전트 탈옥 연구는 최종 답변의 공격 성공률이 낮더라도 중간의 계획·메모리·도구 사용 과정에는 문제가 남을 수 있다고 지적했다. 사용자에게 마지막으로 보여준 문장이 안전하다고 해서 그전에 수행한 행동까지 안전했다고 볼 수는 없다는 뜻이다. 답변 필터와 함께 실제 호출된 도구, 변경된 상태, 외부로 전달된 데이터도 점검해야 한다.

목걸이 속 CAPTCHA를 읽어준 장면은 한 장의 대화 캡처로 이해할 수 있다. 반면 파일을 다루고 프로그램을 실행하는 에이전트의 판단 실패는 마지막 답변만 봐서는 알기 어렵다. 앞으로 탈옥 사례를 볼 때에는 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