은행권 해킹에 등장한 ARTEX(아르텍스), 우리 회사는 안전할까?

ARTEX(아르텍스·아텍스)는 LLM과 실행 도구를 연결해 보안 점검을 수행하는 오픈소스 자율 침투 테스트 시스템입니다. 2026년 9월 말 국내 은행권 개인정보 유출 사건에서 사용 흔적이 보도되며 주목받았습니다. 기업이 먼저 돌아볼 곳은 고객 정보를 읽는 관리자 화면, 직원용 조회 서비스, 협력사 포털과 API입니다.

“은행도 당했는데 작은 회사가 막을 수 있을까?” 위협은 현실적입니다. 다만 어떤 도구가 등장했는지와 실제로 어떤 보안 경계가 무너졌는지를 함께 봐야 대응할 수 있습니다. 이 글은 2026년 10월 4일까지의 공개 자료를 기준으로 작성했습니다.

30초 요약 — 로그인 다음의 권한이 핵심입니다. ARTEX는 특정 AI 모델명이 아닌 침투 테스트 시스템입니다. 은행권 사건에서는 사용 흔적이 확인됐다는 후속 보도가 나왔습니다. 우리 회사는 직원·협력사 화면에서 다른 고객의 자료까지 읽을 수 있는지 먼저 살펴야 합니다.

ARTEX는 어떤 도구인가? AI 모델과 구분해야 합니다

ARTEX는 개별 AI 모델의 이름이 아닙니다. 개발자 Autumn-27이 공개한 프로젝트로, LLM을 연결해 탐색과 검증 작업을 계획하고 실행하는 시스템입니다. 공개 문서에는 Anthropic·OpenAI 및 호환 인터페이스의 모델을 설정하는 구조가 설명돼 있습니다. 어떤 LLM을 연결했는지는 설치 환경에 따라 달라집니다. ARTEX 흔적만으로 공격에 사용된 기반 모델까지 특정할 수는 없습니다. ARTEX 공식 저장소

개발자는 작업을 계획하는 Plan과 개별 도구 작업을 수행하는 Work를 나누고, 실행 결과를 바탕으로 계획을 갱신하는 흐름을 소개합니다. 자산과 요청·응답 기록을 연결해 탐색 이력을 관리하고, 사람이 개입할 수 있는 승인 기능도 설명합니다. 이는 프로젝트가 설명하는 설계이며, 은행 사건에서 모든 기능이 실제 사용됐다는 증거는 아닙니다. 개발자 직접 소개

기업 입장에서 경계할 변화는 탐색·판단·반복 작업을 이어서 수행하는 자동화입니다. 취약한 기능을 발견한 뒤 다른 요청을 살펴보는 작업까지 이어질 수 있다는 점을 방어 설계에 반영해야 합니다.

은행권 해킹에서 어디까지 확인됐나?

초기 기사와 후속 보도의 확인 수준이 다릅니다. “정황만 있다”는 첫 보도에 머물러도, “AI가 혼자 모든 은행을 뚫었다”고 확대해도 사건을 잘못 전달하게 됩니다.

각 행의 근거: 신한금융 SEC 공시, 연합뉴스 10월 2일 보도, 헤럴드경제 10월 3일 후속 보도.

따라서 현재 자료에 맞는 표현은 “ARTEX 활용 흔적이 조사에서 확인됐다는 후속 보도가 나왔다”입니다. 이 글이 은행의 원본 로그나 최종 포렌식 보고서를 확보해 독립 검증한 것은 아닙니다. 각 은행에서 ARTEX가 수행한 세부 작업과 연결된 모델까지 공개된 것으로 볼 수도 없습니다.

또한 중국어 기반 도구라는 이유만으로 공격자의 국적을 확정할 수 없습니다. 연합뉴스도 공개된 소프트웨어의 사용 흔적과 공격자 신원 추정을 구분했습니다.

뚫린 곳은 고객정보를 조회하는 업무 접점이었다

Korea Times의 영문 보도는 직원·영업지원 시스템과 고객용 인터넷·모바일뱅킹을 구분합니다. 당시 보도된 피해와 공격 시도를 나누면 다음과 같습니다.

고객정보와 직원정보는 서로 다른 집계이며, 위 표가 모든 은행의 ARTEX 사용을 개별 입증하지는 않습니다. 수치는 보도 시점 기준입니다. Korea Times 원문, 10월 2일 게재·3일 수정

우리 회사에 대입할 질문: 고객이 보는 메인 페이지뿐 아니라 직원과 협력사의 조회 화면도 같은 수준으로 관리하고 있나요?

홈페이지가 잘 열리고 관리자 로그인이 있다는 사실만으로 고객자료의 접근 권한까지 검증됐다고 볼 수는 없습니다.

웹사이트가 견적서·계약서·고객 목록·외부 CRM과 연결되어 있다면, 그 연결 지점도 점검 목록에 들어가야 합니다. 정보 유출과 예금 인출은 별개의 피해입니다. 이 사건을 고객 계좌에서 돈이 빠져나간 사례로 표현할 근거는 이 글이 확인한 자료에 없습니다.

ARTEX 같은 AI 도구가 악용될 수 있는 영역

아래 표는 개발자가 설명한 탐색·실행 구조를 기업 서비스에 대입한 방어 관점의 위협 분석입니다. ARTEX가 표의 모든 공격을 성공시켰다는 실측 결과나, 이번 은행 사건의 확정된 침해 목록은 아닙니다.

위험 범위는 연결된 모델의 능력뿐 아니라 실행 도구, 네트워크 접근, 확보한 계정 권한, 대상의 취약점에 따라 달라집니다. “오픈소스 AI를 받으면 어떤 사이트든 뚫린다”는 설명은 이 조건들을 생략합니다.

고객 A가 정상 로그인했더라도 고객 B의 자료를 읽을 수 있다면 문제가 남습니다. 로그인 여부 확인과 자료별 접근 허용 판단을 각각 구현해야 합니다. OWASP 접근 통제 지침

어떤 방식으로 정보가 유출됐을까? 예상 흐름과 확인 사실

헤럴드경제는 금융보안원 관계자의 설명을 통해 시스템 전체 장악보다 조회 기능을 통한 정보 취득에 초점을 맞췄습니다. 아래 흐름은 그 보도를 참고한 점검용 가정이며, 실제 공격 요청을 재현한 분석은 아닙니다.

1. 외부에서 닿는 업무 서비스를 찾습니다. 직원용·협력사용이라는 이름과 별개로 인터넷에서 접근되는 기능이 있을 수 있습니다. 회사는 이런 접점을 자산 목록에 포함해야 합니다.
2. 신원 확인과 자료 접근 경계를 시험합니다. 올바른 로그인 상태가 있어야 하는지, 로그인 이후에도 해당 자료를 볼 자격을 확인하는지가 갈립니다. 점검할 때는 계정별 허용·거부 결과를 기록합니다.
3. 조회가 허용된 범위보다 넓게 이어질 수 있습니다. 권한 확인이 빠진 기능에서는 반복 조회가 자료 수집으로 번질 수 있습니다. 요청량뿐 아니라 같은 계정이 접근한 자료의 범위도 살펴야 합니다.
4. 결과를 보며 다음 작업을 조정할 수 있습니다. AI 도구는 응답 분석과 작업 선택을 보조할 수 있습니다. 방어자는 이상 징후를 탐지하고 세션·계정·연동 권한을 회수할 수 있어야 합니다.

일부 초기 보도에는 크리덴셜 스터핑이라는 용어도 나옵니다. 이 용어는 일반적으로 다른 곳에서 유출된 아이디·비밀번호 조합으로 로그인을 시도하는 행위를 뜻합니다. 조회값 반복 대입이나 권한 검증 누락과 같은 말로 쓰면 원인과 대응이 흐려집니다. 이 글은 유출 비밀번호 재사용이 모든 은행의 최초 침투 원인이었다고 단정하지 않습니다. OWASP 크리덴셜 스터핑 정의·방어 지침

NQ는 무엇을 확인했나: 관리자·고객·문서의 경계

이번 글을 준비하며 엔큐솔루션(NQ Solution) 웹사이트 저장소의 관리자 인증, 고객 포털, 계약 문서 조회, 세션 처리, 인사이트 렌더링 코드를 확인했습니다. 은행권 사건에서 주목한 접근 통제 문제를 자사 웹서비스에서는 어떻게 다루는지 살펴본 것입니다.

NQ 확인 범위: 로컬 코드의 인증·권한·문서·세션·본문 렌더링 구현을 확인했습니다. ARTEX를 실행한 모의침투나 운영 시스템 전체 전수조사를 완료했다는 결과는 아닙니다.

실제 도구 기반 점검을 성과로 공개하려면 도구 버전·연결 모델·실시일·대상 목록·발견 사항·조치 후 재검증 기록이 필요합니다.

NQ가 이 사례에서 정리한 대응 기준은 “로그인한 사람이 이 자료를 읽어도 되는가”를 매 요청에서 확인하는 것입니다. 관리자 화면, 고객 포털, 계약서 다운로드를 하나의 로그인 성공 여부로만 판단하지 않고, 각각의 권한 경계를 확인하는 구조가 필요합니다.

우리 회사가 먼저 확인할 보안 점검표

• 업무 접점 목록: 홈페이지 외에 관리자, 직원용 웹, 협력사 포털, API, 자동화 연동을 적습니다. 각 기능의 담당자도 정합니다.
• 신원과 권한: 관리자 다중 인증과 계정 회수 상태를 확인합니다. 고객·프로젝트·문서마다 허용되는 읽기·수정 범위를 적습니다.
• 거부 동작: 정상 로그인 테스트에 더해, 다른 고객의 자료를 요청했을 때 서버가 거부하는지 확인합니다.
• 조회와 다운로드: 비정상적인 로그인·조회·다운로드를 기록하고, 계정 또는 세션을 중단할 절차를 마련합니다.
• 업데이트와 비밀키: 외부에 연결된 구성요소를 관리하고 연동 계정의 권한을 줄입니다. 발견한 문제는 수정 후 같은 조건으로 다시 확인합니다.

IP 차단, 다중 인증, 자료별 접근 통제는 서로 다른 문제를 다룹니다. IP 차단 하나만으로 대응을 마무리하거나, 다중 인증이 있다는 이유로 문서 접근 검증을 생략해서는 안 됩니다. OWASP 자동화 로그인 공격 방어 지침

홈페이지를 새로 만들거나 업무 시스템을 고칠 때는 화면 목록과 함께 계정·자료·권한표도 준비해 두세요. 홈페이지·웹서비스 개발, 업무 시스템·AI 자동화의 범위를 정할 때 함께 검토할 수 있습니다. 현재 사이트와 운영 기능을 정리해 프로젝트 문의로 보내 주세요.

자주 묻는 질문

ARTEX(아르텍스·아텍스)는 중국 AI 모델인가요?

중국어권 개발자가 공개한 LLM 기반 침투 테스트 시스템입니다. 독립 모델명과는 구분해야 합니다. 연결하는 모델은 설정에 따라 달라지며 이번 사건에서 사용된 기반 모델은 이 글이 확인한 자료로 특정할 수 없습니다.

ARTEX가 은행 해킹에 쓰였다는 것이 확인됐나요?

10월 2일에는 사용 정황 보도가 나왔고, 3일에는 헤럴드경제가 금융보안원 관계자를 인용해 사용 흔적 확인을 보도했습니다. 해당 후속 보도와 모든 은행의 공격 과정이 담긴 최종 조사 결과는 구분해야 합니다.

ARTEX는 비밀번호 없이 모든 사이트를 해킹할 수 있나요?

그런 범용 성공 능력을 입증하는 자료는 확인하지 못했습니다. 가능한 작업은 대상의 취약점, 실행 도구, 네트워크 접근과 계정 권한에 좌우됩니다. 모델이나 도구의 분석 결과도 실제 재현 여부를 확인해야 합니다.

우리 회사가 AI를 쓰지 않아도 위험한가요?

공격자가 AI 도구를 사용하는 상황에서는 대상 기업의 AI 도입 여부와 별개로 웹서비스의 보안 경계를 점검해야 합니다. 관리자 계정과 고객자료를 다루는 API·파일 기능부터 확인할 수 있습니다.

직원용·협력사용 페이지도 보안 점검이 필요한가요?

외부에서 접근 가능하거나 고객정보를 다룬다면 점검 대상입니다. 내부 업무용이라는 이름만으로 접근이 제한되지는 않습니다. 실제 접속 경로와 사용자별 권한을 확인해야 합니다.

AI 도구로 보안 전수조사를 했다는 말은 어떻게 확인하나요?

전체 대상 목록과 실제 점검 범위, 제외 항목, 실행 기록, 발견 사항, 조치 후 재검증 결과를 확인해야 합니다. 일부 코드 검토나 자동 생성 보고서 하나만으로 모든 시스템 점검이 완료됐다고 볼 수는 없습니다.

출처와 확인 기준

• ARTEX 공식 저장소와 개발자 소개: 시스템 구조·모델 연동 설명의 원출처.
• 신한금융의 2026년 10월 1일 SEC 공시: 회사가 밝힌 사고·조사 사실.
• 연합뉴스, 2026년 10월 2일: 초기 ARTEX 사용 정황 보도.
• 헤럴드경제, 2026년 10월 3일: 금융보안원 관계자의 후속 설명을 직접 취재한 보도.
• Korea Times 영문 보도: 피해 대상·업무 시스템 구분.
• OWASP 접근 통제, 크리덴셜 스터핑 방어: 기술 용어와 일반 방어 기준.

사건 보도, 개발자 설명, 방어 관점의 가정, NQ 코드 확인 결과를 구분했습니다. 자료 기준일은 2026년 10월 4일이며 후속 조사에 따라 세부 내용이 달라질 수 있습니다.