AI 보안·개인정보

ARTEX 분석 — AI 보안 프로젝트가 주목받은 이유와 원본 저장소의 비공개 전환

mhtsec/ARTEX는 원본 프로젝트의 소스 백업입니다. 이중 그래프와 에이전트 구조, 한국 금융권 공격 관련 보고서, 원저자의 10월 8일 성명과 현재 저장소 상태를 대조해 관심의 배경과 공개 중단 경위를 정리합니다.

작성 AI Tools Lab 운영자오류 제보·정정 요청

최근 ARTEX를 찾으면 두 가지 이야기를 함께 만나게 됩니다. AI가 보안 테스트의 다음 작업을 계획하고 실행한다는 기술 소개와, 실제 공격에 악용됐다는 보고 이후 원본 저장소가 사라졌다는 소식입니다.

먼저 구분할 사실이 있습니다. 현재 공개된 mhtsec/ARTEX는 스스로 ‘마지막 버전 소스 백업’이라고 설명하는 저장소입니다. 원저자 Autumn-27은 10월 8일 악용을 이유로 업데이트 중단과 비공개 전환을 선언했습니다. 백업 저장소, 원저자의 성명

ARTEX가 주목받은 배경은 보안 업무를 에이전트의 계획·기억·실행 흐름으로 묶은 설계와, 그 기술이 현실에서 어떻게 사용됐는지를 둘러싼 논란이 겹친 데서 읽을 수 있습니다. 다만 도구의 사용이 확인됐다는 사실, 개발자의 책임, GitHub의 조치는 각각 별도의 증거가 필요한 주장입니다.

원본과 백업은 서로 다른 저장소입니다

2026년 10월 15일 18:31 KST에 공개 GitHub API와 웹 주소를 조회했습니다.

구분 주소 확인한 상태
원본 저장소 Autumn-27/ARTEX 웹과 공개 API 모두 HTTP 404
소스 백업 mhtsec/ARTEX 공개 API HTTP 200, README에 마지막 버전 소스 백업으로 명시
원저자 안내 Autumn-27 프로필 ARTEX 공개 중단 성명 게시

같은 시각 백업 저장소의 API 표시값은 Stars 4,198개, Forks 6,449개였습니다. 백업 생성일은 10월 8일이며, 이는 ARTEX 프로젝트 자체의 최초 공개일을 뜻하지 않습니다. 숫자는 이후 달라질 수 있습니다. GitHub — 백업 저장소 메타데이터

mhtsec를 원저자 계정과 같은 운영자라고 단정하거나, 백업을 원저자가 유지하는 공식 후속 프로젝트로 소개해서는 안 됩니다. README의 백업 설명과 원저자의 지원 중단 성명을 따로 읽어야 합니다.

ARTEX는 새로운 AI 모델이 아닌 작업 실행 시스템입니다

ARTEX는 외부 언어 모델을 연결하는 시스템으로, Go 백엔드·Next.js 프런트엔드·PostgreSQL로 구성됩니다.

중심에는 역할 분담이 있습니다. Planner는 현재까지의 결과를 읽고 다음 탐색 방향을 정합니다. Worker는 배정받은 작업을 수행하고 결과를 기록합니다. 사람이 개입하는 대화와 승인 기능도 별도로 둡니다. ARTEX — 시스템 기술 구조

이 구조에서 모델의 답변은 작업 과정의 한 부분입니다. 실행 대상, 이전 결과, 진행 상태와 검토 기록을 애플리케이션이 관리해야 여러 단계의 작업을 이어갈 수 있습니다. 일반적인 에이전트의 구조와 비교하려면 AI 에이전트와 챗봇의 차이를 함께 읽어 보세요.

두 개의 그래프에 무엇을 기록하나요

README가 설명하는 특징은 자산 그래프와 탐색 그래프를 분리한 설계입니다.

구분 기록하는 내용 답하려는 질문
자산 그래프 도메인·서비스·엔드포인트 등 대상의 관계 무엇을 알고 있는가?
탐색 그래프 목표·작업 의도·관찰 사실·발견 결과의 연결 어떤 근거에서 다음 작업이 나왔는가?

자산 그래프는 여러 작업에서 공유하는 대상 정보를, 탐색 그래프는 개별 작업의 진행 과정을 담습니다. 두 그래프를 연결해 특정 대상에 대해 어떤 작업과 결과가 있었는지 추적합니다. ARTEX — 이중 그래프 설명

이 설계의 의미는 대화가 길어질수록 필요한 상태를 모델의 대화 기억에만 의존하지 않는다는 점입니다. 장기 조사나 품질 검토에서도 대상 정보와 판단 과정을 나누면, 다음 담당자가 무엇을 확인해야 하는지 찾기 쉬워집니다. 이는 구조를 바탕으로 한 활용 해석이며, ARTEX의 정확성이나 작업 성공률을 측정한 결과는 아닙니다.

최근 관심이 커진 배경

보안 업무를 연결된 에이전트 작업으로 보여줬습니다

보안 도구 하나를 실행하는 기능보다, 관찰 결과에 따라 다음 작업을 계획하고 기록을 이어가는 구성이 관심을 끌 만한 부분입니다. 작업이 길어지면 반복 실행, 맥락 손실, 근거 누락을 어떻게 줄일지가 중요해집니다. ARTEX는 그 문제를 상태와 역할을 나누는 방식으로 다룹니다.

실제 악용 관련 보고서가 나왔습니다

CrowdStrike는 10월 7일 한국 금융기관을 겨냥한 활동을 분석하면서 ARTEX와 언어 모델의 사용을 보고했습니다. 이후 Reuters도 원저자의 비공개 전환을 보도했습니다. 기술 커뮤니티 밖에서도 이 프로젝트를 살펴볼 계기가 생긴 것입니다. CrowdStrike 보고서, Reuters 보도 — Investing.com 재전재

원본 접근 중단으로 백업의 존재도 주목받았습니다

원본이 공개되지 않는 상황에서는 남아 있는 소스와 기록을 찾는 관심이 생길 수 있습니다. 많은 Forks도 이 맥락에서 읽을 여지가 있습니다. 다만 보존 목적, 개발 참여, 실제 사용이 각각 얼마나 차지하는지는 이 숫자만으로 알 수 없습니다.

이 세 가지는 공개 자료를 종합한 배경 해석입니다. Stars 증가 원인을 항목별로 계량한 조사나, 현재 GitHub 전체 인기 순위를 뜻하지 않습니다.

공개 중단까지의 시간순 기록

날짜 확인할 수 있는 기록 출처
9월 말부터 10월 초 한국 금융기관을 겨냥한 활동이 있었다는 분석 CrowdStrike
10월 7일 ARTEX와 언어 모델 사용을 다룬 보고서 발표 CrowdStrike
10월 8일 백업 저장소 생성과 원저자의 공개 중단 성명 기록 GitHub API·프로필 커밋
10월 9일 원저자의 비공개 전환과 원본 접근 중단 보도 Reuters 기사 본문 날짜
10월 15일 원본 404, 백업 공개 상태를 다시 조회 공개 GitHub 웹·API

원저자의 성명은 프로필 README의 10월 8일 변경 기록에서도 확인할 수 있습니다. 백업 생성과 성명이 같은 날 기록돼 있다는 사실만으로, 정확히 어떤 순서로 원본의 접근 상태가 바뀌었는지까지 확정할 수는 없습니다.

원본 저장소가 사라진 이유는 무엇인가요

원저자가 밝힌 이유는 도구의 악용입니다. 10월 8일 성명은 다음 내용을 담고 있습니다.

  • ARTEX는 학습·연구와 허가받은 자산의 보안 테스트를 목적으로 만들었다.
  • 악의적인 공격은 개발자와 무관하며, 무단 사용을 반대한다.
  • 악용 상황을 고려해 업데이트를 중단하고 비공개로 전환한다.
  • 이후 버전 공개와 유지보수 지원을 제공하지 않는다.

이는 원저자의 입장을 요약한 것입니다. Autumn-27 — ARTEX 안전 성명

현재의 404 응답은 공개 접근이 되지 않는다는 사실을 보여줍니다. 하지만 이 응답만으로 저장소의 물리적 삭제와 비공개 전환을 구별할 수는 없습니다. 또한 GitHub가 강제로 삭제했다거나, 당국의 명령으로 내려갔다고 확인할 자료는 이번 조사에서 찾지 못했습니다.

따라서 공개 자료에 맞는 설명은 ‘악용을 이유로 원저자가 공개 중단과 비공개 전환을 선언했고, 원본은 현재 공개 접근이 되지 않는다’입니다. ‘위험한 성능 때문에 GitHub가 금지했다’는 설명으로 바꾸면 확인한 범위를 넘어갑니다.

한국 금융권 공격 관련 보고서가 보여주는 범위

CrowdStrike는 공격자가 통제한 공개 디렉터리에서 Claude Code 세션 기록, ARTEX 설정 파일, 메모리 파일 등을 분석했다고 밝혔습니다. 이 자료를 바탕으로 한국 금융기관을 겨냥한 활동에서 ARTEX와 여러 언어 모델이 사용됐다고 보고했습니다. CrowdStrike — 분석 내용

다만 보고서에는 피해 기관 수가 당시 확정되지 않았다는 설명이 있습니다. 특정한 이름의 공격 집단에 귀속시키지도 않았습니다. 중국어 사용 가능성 등의 판단도 신뢰 수준을 붙인 분석이며, 국가 배후를 확정한 수사 결론으로 읽어서는 안 됩니다.

다음 주장도 구분해야 합니다.

주장 확인한 자료가 뒷받침하는 범위
해당 활동에 ARTEX가 사용됐다 보안업체의 파일·세션 분석 보고가 있음
ARTEX 개발자가 공격에 가담했다 이번에 확인한 자료로 입증되지 않음
모든 관련 피해가 같은 도구와 경로로 발생했다 피해 범위와 사건별 경로를 별도로 확인해야 함
AI가 사람 개입 없이 전 과정을 끝냈다 해당 보고서는 자율 수행 비율을 측정한 평가가 아님

도구가 공격 과정에 사용됐다는 사실과, 개발자의 가담 여부 또는 모델의 독립적인 공격 능력은 서로 다른 질문입니다. 사고 소식을 모델 성능 홍보 문구처럼 소비하면 이 구분이 사라집니다.

승인 기능이 있다는 사실만으로 통제가 보장되지는 않습니다

공개 소스의 intercept 계층은 도구 호출에 대해 허용·차단·사람 확인 요청을 처리합니다. guard 계층은 실행 전 훅과 감사 기록에 연결됩니다. 다만 적용 대상과 규칙은 설정에 영향을 받습니다. ‘위험한 행동은 언제나 사람이 승인한다’고 일반화할 수는 없습니다. 호출 검토 구현, 실행 전 통제 구현

이 점은 일반 업무 에이전트에도 적용됩니다. 승인 화면의 존재와 별개로 어떤 도구 호출을 검사하는지, 검사 실패 시 어떻게 처리하는지, 실제 실행 권한을 어디에서 제한하는지 확인해야 합니다. 자세한 판단 항목은 기업 AI 도입 체크리스트와 연결해 볼 수 있습니다.

증거 관리 문서도 눈여겨볼 만합니다. 요청·응답의 스냅샷과 해시를 보관하고, 일반 트래픽 기록을 지워도 연결된 증거는 별도로 유지하도록 설명합니다. 이는 근거를 보존하는 설계이지, 기록된 취약점 판단이 모두 정확하다는 보증은 아닙니다. ARTEX — 증거 관리 문서

원본이 닫혔는데 백업은 왜 남아 있나요

원본 주소를 비공개로 전환하는 것과 이미 복사된 소스를 모두 회수하는 것은 다른 일입니다. 현재 공개된 백업의 존재가 그 차이를 보여줍니다. 다만 백업이 남아 있다는 사실은 원저자가 지원을 재개했다는 뜻이 아닙니다.

백업 README는 원래 Docker 이미지가 유효하지 않으며 별도 이미지를 관리한다고 설명합니다. 남아 있는 소스와 이미지를 원저자의 공식 배포로 취급해서는 안 됩니다. mhtsec/ARTEX — 백업 안내

현재 README는 AGPL-3.0을 표기하면서, 사용은 개인 학습·소스 연구·로컬 검증으로 한정하고 온라인 테스트는 허가 여부와 관계없이 금지한다고 안내합니다. 백업 공개를 운영 환경 도입 권장으로 읽어서는 안 됩니다.

이 사례에서 남는 AI 설계 관점

ARTEX를 살펴볼 때는 자동화된 공격의 인상보다 상태를 어떻게 보존하고, 어떤 근거로 다음 행동을 정하며, 실행을 어디에서 통제하는지를 보는 편이 유용합니다.

살펴볼 설계 일반 업무에 연결되는 질문
대상 정보와 작업 과정의 분리 다음 담당자가 사실과 가설을 구분할 수 있는가?
계획과 실행의 역할 분담 작업이 끝나거나 실패했을 때 상태가 명확하게 돌아오는가?
검토 기록과 원자료 보존 승인자와 검토자가 실제 근거를 다시 확인할 수 있는가?
공개 중단 이후의 배포 상태 누가 현재 버전과 변경 내용을 책임지는가?

이 질문은 AI 공용 작업실 설계와 AI 실행 로그로 문제 찾기에서도 중요합니다. 프로젝트가 주목받았다는 사실과 안정적으로 운영할 수 있다는 판단을 나누고, 원본·백업·보도·실제 구현을 각각 확인하세요.

자주 묻는 질문

Q1. 지금 볼 수 있는 mhtsec/ARTEX가 원본 저장소인가요?

README는 마지막 버전의 소스 백업이라고 설명합니다. 원저자의 저장소 주소는 Autumn-27/ARTEX이며, 이번 확인에서는 웹과 공개 API 모두 404였습니다.

Q2. ARTEX가 강력해서 GitHub에서 강제로 삭제한 건가요?

그렇게 확인되지 않았습니다. 원저자가 밝힌 이유는 도구 악용에 따른 공개 중단입니다. GitHub의 강제 조치나 당국의 명령 여부는 별도의 근거가 필요합니다.

Q3. ARTEX 사용 보고가 곧 개발자의 공격 가담을 뜻하나요?

아닙니다. 도구가 사용된 정황과 개발자의 행위는 별개입니다. 원저자는 공격과 무관하다는 입장을 밝혔으며, 이번에 확인한 자료만으로 가담을 입증할 수 없습니다.

Q4. Forks가 많으면 그만큼 실제로 운영 중이라는 뜻인가요?

Forks는 저장소 복사와 관련된 지표입니다. 코드 보존, 연구, 개발 참여 등 여러 이유가 있을 수 있으므로 실제 운영 조직 수나 성공 사례 수로 바꿔 읽으면 안 됩니다.

공식 자료와 확인 기준일

확인 기준일: 2026-10-15 — 저장소 상태와 Stars·Forks는 같은 날 18:31 KST의 조회 기록입니다. 기술 설명은 공개 문서와 일부 소스를 대조했으며, 설치·모델 연결·보안 테스트를 실행한 사용 후기는 아닙니다. 원저자의 성명, 보안업체의 분석, 기사 보도와 편집 해석을 구분했습니다.