작전 기록을 쓴 것은 공격자가 아니었습니다 : 기록을 지우면 에이전트는 덜 똑똑해집니다

크라우드스트라이크가 현지시각 10월 7일 「Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance」 보고서를 공개했습니다. 9월 말부터 10월 초까지 한국 금융회사 여러 곳에서 고객과 직원의 정보가 빠져나간 일에, 중국에서 만들어진 오픈소스 AI 침투시험 도구가 쓰였다는 내용이에요.

국내에서 확인된 피해부터 적어 두는 편이 좋겠습니다. 신한은행은 외부에서 접근할 수 있던 대출모집인용 조회 서비스가 뚫려 약 2만 5천 명분의 개인정보와 대출 정보가 나갔고, KB국민은행은 직원용 모바일 업무지원시스템에서 119명, 하나은행은 영업지원시스템에서 89명이었습니다. BNK부산은행에서는 외주 개발자 11명의 정보가 노출됐고, 9월 30일 침입 정황을 확인한 예가람저축은행에서는 이름과 생년월일, 연락처가 빠져나간 것으로 보이는데 그 규모가 4만 명으로 추정됩니다. 우리은행과 NH농협은행도 공격을 받았지만 지금까지 고객 정보 유출은 확인되지 않았습니다. 국회 정무위원회는 10월 8일 5대 시중은행장을 19일 금융감독원 국정감사 증인으로 부르기로 의결했고, 금융위원회와 금융감독원은 유출된 정보를 이용한 피싱과 대출 사기를 조심하라고 당부했습니다.

그런데 이 사건이 "AI 에이전트가 한국 은행을 뚫었다"로 요약되어 돌아다니는 것에 비하면, 보고서가 실제로 적어 둔 내용은 결이 조금 다릅니다.

국회 정무위원회가 10월 19일 금융감독원 국정감사 증인으로 5대 시중은행장을 부르기로 했습니다. 은행장들이 함께 증인석에 서는 것은 2022년 이후 4년 만입니다. 출처: Wikimedia Commons, Ox1997cow

▸ 모델은 일의 종류에 따라 갈아 끼워졌습니다

ARTEX는 여러 에이전트가 역할을 나눠 자동으로 침투시험을 수행하는 오픈소스 도구입니다. GitHub 핸들 Autumn-27이 공개했어요. 공격에 쓰인 ARTEX 인스턴스의 주 백엔드 모델은 DeepSeek v4.1-flash였고, 일부 세션에서 GLM-5.3과 Grok 4.6이 보조로 쓰였습니다. 크라우드스트라이크는 공격자가 LLM API 리셀러를 거쳐 DeepSeek에 접근한 것으로 봅니다.

그럼 Claude Code는 어디에 있었을까요? 노출된 파일 가운데 Claude Code 세션 기록이 있었습니다. 그 기록에서 공격자는 한국에서 유출된 데이터가 보통 어디서 거래되는지, 한국 텔레그램 데이터 판매 그룹은 어떻게 찾는지를 물었습니다. 자기 이력서를 써 달라고 한 세션도 있었고, 텔레그램의 NFT 기프트 마켓플레이스에서 취약점을 찾는 세션도 따로 있었어요. 보고서는 Claude Code가 은행 침투를 수행했다고 적지 않습니다.

더 정확한 표현은, 한 사람이 일의 종류에 따라 서로 다른 회사의 모델을 갈아 끼우며 작업했다는 것입니다. 자동 탐색은 값싼 중국 모델에 맡기고, 조사와 문서 작성은 다른 창구에서 했고요. 침투와 유출, 판매처 물색까지를 하나의 작전으로 묶어낸 것은 모델이 아니라 그 앞에 앉아 있던 사람이었겠죠.

사정거리도 그어 두는 편이 좋겠습니다. 크라우드스트라이크는 이 활동을 알려진 조직에 귀속하지 않았습니다. 중국어 사용자이고 금전적 동기라는 평가도 중간 수준의 확신이고요. 세션에 등장한 이름과 대학, 지역, 나이 같은 신상 정보에 대해서도 "공격자의 것일 가능성이 높다"고만 적고 확정하지 않습니다. 입력된 나이와 생년월일이 서로 맞지 않는다는 점도 보고서가 함께 적어 두었어요. 영향받은 조직이 모두 몇 곳인지는 확인하지 못한다고 명시했고, 국내 경찰 역시 은행별 사건이 서로 연결된 것인지 아직 확인하지 못한 단계입니다.

▸ 적발한 것도 AI가 아니었습니다

어떻게 들켰는가를 보면 이 사건의 실질적인 교훈이 나옵니다. 탐지한 쪽이 영리한 AI를 돌린 것이 아니었어요. 공격자가 쓰던 서버의 디렉터리 목록이 그냥 열려 있었습니다. 한 IP의 노출된 디렉터리에서 중국어로 쓰인 지시 파일이 나왔고, 그것을 따라가니 홍콩에 있는 두 번째 서버가 나왔고, 거기에 Claude Code 세션 기록과 메모리 파일, 그리고 ARTEX 설정 파일이 들어 있었습니다. 설정 파일에는 테스트 행동을 지시하는 중국어 펜테스트 프롬프트가 그대로 담겨 있었고요.

그러니까 이 작전의 가장 자세한 기록을 공격자의 도구가 대신 써 두었던 셈입니다. 예전 같으면 침투에 쓴 도구의 흔적은 작전이 끝나는 대로 지우는 것이 수순이었습니다. 에이전트는 다릅니다. 다음 세션에서 맥락을 이어 붙이려면 앞선 대화와 판단을 적어 두어야 하니까, 기록을 쌓는 일 자체가 설계의 일부예요. 지우면 도구가 덜 똑똑해집니다. 공격자가 그 기록을 지우지 않은 것이 게으름이라기보다 도구를 제대로 쓰는 방식에 가까웠다는 점이, 이 사건에서 가장 눈에 밟히는 대목입니다.

▸ 같은 파일이 우리 쪽 디스크에도 쌓입니다

여기까지는 남의 이야기입니다. 그런데, 사내에서 코딩 에이전트를 돌리는 팀의 작업 디렉터리에도 같은 종류의 파일이 매일 쌓이고 있거든요. 세션 기록에는 어떤 파일을 열어 무엇을 고쳤는지가 들어가고, 메모리 파일에는 다음에도 기억해야 할 사내 규칙이 들어갑니다. 설정 파일에는 그 팀이 에이전트에게 시키는 일이 문장으로 적혀 있고요. 그 안에는 내부 호스트명, 테이블 이름, 배포 절차, 아직 고치지 못한 결함의 목록 같은 것이 자연스럽게 섞여 들어갑니다. 소스 코드만큼 민감한데 소스 코드만큼 관리되지는 않습니다. 적어도 지금은요.

확인할 것들은 평범합니다. 에이전트의 작업 디렉터리가 어디에 생기는지, 그 경로가 .gitignore에 들어 있는지, 컨테이너 이미지를 만들 때 COPY 범위에 딸려 들어가지는 않는지, 개발 서버의 디렉터리 목록 기능이 꺼져 있는지, 백업과 스냅샷의 보존 정책이 그 경로를 포함하는지, 그리고 그 파일들을 사내에서 누가 읽을 수 있는지. 전부 새로운 질문은 아닙니다. 적용해야 할 대상이 한 종류 늘었을 뿐이에요.

ARTEX 개발자는 10월 8일 프로젝트를 더 이상 업데이트하지 않고 클로즈드소스로 전환하겠다고 밝혔습니다. 학습과 인가된 보안 테스트를 위한 도구였고 이번 악용은 의도에 반한다는 설명이었어요. 이해가 가는 결정이지만 그것으로 되돌릴 수 있는 범위는 넓지 않습니다. 이미 받아 간 복사본은 그대로 남아 있고, 이번 공격이 ARTEX가 아니면 불가능했는지는 보고서가 답하지 않거든요. 쓰인 모델은 전부 상용 API로 호출한 것이었고요.

그래서 소스를 닫는 일로 정리되지 않는 질문이 남습니다. 이번에는 공격자가 자기 작전 기록을 통째로 흘린 덕분에 전모가 비교적 빨리 드러났는데요. 다음 공격자가 같은 실수를 반복하리라고 기대할 수는 없겠죠. 반대로 우리 쪽 에이전트는 오늘도 성실하게 기록을 쌓고 있습니다. 그 파일에 무엇이 들어가는지, 어디까지 열어 둘 것인지에 대해서는 고민이 필요합니다.

커버 이미지: 서울 여의도 금융가 — Wikimedia Commons, S h y numis