ARTEX는 어떤 도구인가: 금융권 논란과 AI 자율 침투테스트의 기능
최근 금융권 침해 사고 보도에서 ‘ARTEX’라는 이름이 등장했다. 이름만 보면 사고의 원인이 확정된 것처럼 느껴지지만, 공개된 정황과 실제 사용 사실은 구분해야 한다. 이 글은 최근 보도의 확인 범위를 짚고, ARTEX 공식 GitHub 저장소가 설명하는 기능과 설계상 장점을 살펴본다. 실제 시스템을 설치·운영하거나 성능을 재현한 리뷰는 아니다.
최근 이슈: 금융권 사고와 시연 결과는 다른 이야기
10월 초 국내 금융사 침해 사고를 다룬 보도에서는 공격에 연관된 것으로 추정되는 서버에 ARTEX 관련 문자열이 발견됐다고 전한다. 그러나 이 문자열만으로 해당 도구가 실제 침입 과정에서 실행됐거나, 특정 사고의 원인이 ARTEX였다고 입증할 수는 없다. ZDNet Korea는 금융당국·금융기관의 공식 조사에서 실제 사용 사실이 확인되지 않았다고 명시했고, YTN의 10월 6일 인터뷰에서도 전문가가 AI 활용 여부는 아직 확인되지 않았다고 말했다. 따라서 ‘금융권을 ARTEX가 뚫었다’는 단정은 피해야 한다.
전자신문의 10월 5일 기사에는 에버스핀의 별도 재현 실험이 나온다. 금융 사이트와 유사하게 만든 시연용 샘플 웹앱에서 ARTEX로 자동 조회 작업을 실행했고, 기사에 따르면 6라운드·22초 동안 약 4만4000토큰을 사용했다. 약 0.88달러는 특정 모델 가격을 기준으로 한 추산 비용이다. 이 수치는 실제 금융사 공격 소요 시간이나 실제 침해 비용이 아니다. 실험 조건과 다른 사이트에 결과를 그대로 일반화할 수도 없다.
이 사례가 시사하는 핵심은 ‘새로운 만능 공격 기술’이라기보다, 노출된 조회 기능을 자동화하면 반복 요청의 규모를 키우기 쉽다는 점이다. 따라서 방어 측면에서는 미인증 조회 경로·권한 검증·반복 접근·개인정보 노출 범위를 점검할 필요가 있다. 이는 기사와 공개 정황을 바탕으로 정리한 점검 포인트이며, 특정 금융사 취약점을 직접 확인했다는 뜻은 아니다.
ARTEX의 기능: 목표 설정부터 실행 기록까지
공식 GitHub 저장소의 README에 따르면 ARTEX는 Go 백엔드, Next.js 프런트엔드와 PostgreSQL을 사용하는 LLM 기반 다중 에이전트 시스템이다. 외부 LLM을 설정해 탐색을 수행하도록 설계됐다. 주요 기능을 작업 흐름으로 보면 다음과 같다.
- 자산 관리와 범위 지정: 도메인·IP·서비스·엔드포인트 등을 자산 그래프에 정리하고, 작업 범위 및 자산 허용·차단 규칙과 연결한다. ScopeSentry 자산을 가져오는 연동 기능도 문서에 소개돼 있다.
- 계획과 실행의 역할 분리: planner가 현재 발견한 사실과 목표를 보고 다음 작업 의도(intent)를 만들고, worker가 의도 하나를 받아 도구를 실행한다. 결과가 기록되면 planner가 다시 판단하는 이벤트 기반 흐름이다.
- 과정·결과 추적: 별도의 탐색 그래프에 목표·의도·사실·발견 사항의 연결 관계를 기록하고 자산과 앵커로 이어 붙인다. worker는 다른 worker의 실행 흔적을 검색해 정식 사실로 정리되지 않은 관찰도 참고할 수 있다.
- 검토와 증거 관리: README에는 사람이 개입하는 대화·승인 화면, 도구 실행 승인 게이트, 트래픽 기록 프록시, 발견 사항·보고서 화면이 나온다. 기능이 있다는 사실과 모든 잘못된 동작을 예방한다는 보장은 다르다.
어디가 유용하고, 무엇을 확인해야 하나
이 설계의 장점은 단일 스캐너처럼 결과 목록만 내놓는 데 그치지 않고, 어떤 자산을 대상으로 어떤 의도가 실행됐으며 어떤 사실로 다음 판단을 이어갔는지를 따라갈 수 있다는 점이다. 여러 worker의 관찰을 재사용하고, 선행 사실이 확보된 뒤 다음 작업을 진행하도록 공유 todolist를 둔 점도 연속적인 작업을 설계할 때 유용하다. 자산 범위, 승인 기록, 트래픽 기록을 한곳에서 살펴볼 수 있다는 점은 운영자가 검토할 지점을 제공한다. 모두 저장소 문서로 확인한 설계상 이점이지, 탐지율·오탐률·안전성을 측정한 결과는 아니다.
한편 공개 GitHub 이슈에는 운영상 과제도 남아 있다. #192는 Windows 환경의 메모리 부족 종료를 보고하지만 원인은 아직 확정되지 않았다. #186은 DB 백업 기능, #162는 테스트 중 만들어진 임시 파일의 기록·정리를 제안한다. 이는 각 사용자의 신고·제안이며 모든 환경에서 재현된 결함이라는 뜻은 아니다. 도입 판단에는 자원 사용량, 결과 복구, 산출물 관리도 별도로 검토할 필요가 있다.
저장소는 AGPL-3.0 라이선스를 표기하면서 README에서 개인 학습·코드 연구·로컬 격리 환경 검증을 허용 범위로 설명하고 온라인 시스템 대상 테스트를 금지하는 별도 문구를 두고 있다. 라이선스와 추가 문구의 법적 관계는 여기서 단정하지 않는다. 사용 전 LICENSE와 README의 사용 조건을 직접 확인해야 한다.
금융권 사고에서 ARTEX의 실제 관여 여부는 추가 조사 결과를 기다려야 한다. 다만 시연용 환경에서 보여준 자동화 속도와 ARTEX의 설계를 함께 보면, 관심의 초점은 ‘AI가 모든 것을 뚫는다’보다 자동화된 탐색을 어떻게 통제하고, 그 과정과 근거를 어떻게 검증할 것인가에 있다.
출처: ARTEX 공식 저장소 · 전자신문 2026-10-05 기사 · ZDNet Korea 2026-10-04 보도 · YTN 2026-10-06 인터뷰