최근 금융권 정보유출 기사에 ARTEX(아르텍스)라는 이름이 부쩍 자주 보입니다. 이름만 들으면 새로 나온 AI 모델 같지만, 실제로는 대형 언어모델과 실행 도구, 작업 기록을 하나로 엮어 보안 점검 과정을 자동으로 굴리게 만든 공개 소프트웨어입니다. 이 글은 공개된 뉴스와 공식 저장소를 읽고 정리한 것이며, 제가 직접 설치해 성능을 따져 본 후기는 아니라는 점을 먼저 말씀드립니다.
사건 보도, 어디까지가 사실일까요?
금융위원회는 2026년 10월 2일 자료에서 신한은행에 이어 국민은행 등에서도 추가 피해가 확인됐다고 밝혔습니다. 현장조사와 공격 IP 공유를 진행 중이고, 외부에 열린 서비스를 전부 파악해 접근통제를 살피라는 주문도 담겼습니다. 그런데 이 발표문에는 ARTEX라는 이름도, AI가 단독으로 공격했다는 판단도 없습니다.
같은 날 서울경제는 공격에 쓰인 것으로 추정되는 서버 화면에서 ARTEX 콘솔 표식이 보였다고 전했습니다. 다만 실제로 쓰였는지는 확인되지 않았다는 단서가 붙어 있었습니다. 이튿날 헤럴드경제는 금융보안원 관계자의 말을 빌려 로그와 IP 추적에서 활용 흔적이 나왔다고 보도했습니다. 같은 관계자는 사람 손을 거치지 않고 AI가 혼자 공격한 것은 아니라고 설명했습니다. 정리하면 흔적이 있다는 말과 AI가 다 했다는 말은 전혀 다른 이야기입니다. 원시 로그나 최종 보고서가 나오지 않았으니 사용 버전, 모델, 자동화 비중은 지금으로선 알 수 없습니다.
ARTEX는 어떤 구조의 프로그램인가
GitHub의 Autumn-27/ARTEX 저장소는 Go 백엔드, Next.js 화면, PostgreSQL, 여러 LLM 에이전트를 묶은 시스템이라고 소개합니다. 계획을 세우는 쪽, 도구로 일을 처리하는 쪽, 결과를 저장하는 쪽, 사람이 확인하는 화면으로 나누어 보시면 이해가 빠릅니다. 기록은 두 갈래입니다. 어떤 대상이 있는지 정리한 자산 그래프, 이번 작업에서 무엇을 관측했는지 남기는 탐색 그래프입니다.
실행 쪽 소스에는 파일 읽기·쓰기와 Bash 같은 도구가 들어 있습니다. 작업마다 전용 폴더를 만들긴 하지만, 폴더를 나눴다고 다른 파일이나 네트워크로의 접근까지 막히는 것은 아닙니다. 그래서 실행 환경의 권한 설정이 중요합니다.
공개 이력으로 본 개발 흐름과 보안 수정
저장소 생성일은 2026년 7월 26일이고 v0.1.0도 같은 날 올라왔습니다. 이는 공개 기록의 출발점일 뿐 개발 착수일을 뜻하지는 않습니다. 조사 시점의 최신 정식 릴리스는 9월 24일의 v0.3.14인데, 제가 본 main 브랜치(커밋 b55ceb1)는 그 이후 변경까지 포함하고 있어 둘을 같은 동작으로 보시면 안 됩니다.
변경 이력에는 9월 중순 사이 다른 작업의 자산이 섞여 조회되던 문제, 기록 프록시를 localhost로만 열도록 바꾼 일, 모델 심사 출력이 잘릴 때 엉뚱하게 허용되던 경로를 줄인 일이 적혀 있습니다. 어디까지나 과거에 고친 내용이지, 지금 버전이 취약하다거나 이번 사건의 원인이라는 뜻은 아닙니다.
내부에서 시험해 볼 때 챙길 부분
이번에 소스를 읽으면서 악성 백도어를 발견한 것은 없습니다. 그래도 외부 컨테이너 이미지의 태그가 바뀌면 같은 설정이라도 실행물이 달라질 수 있으니 버전과 해시를 고정해 두셔야 합니다. 업무용 PC, SSH 키, 클라우드 자격증명은 시험 환경과 완전히 떼어 놓으시기 바랍니다.
외부 모델을 연결하면 입력한 내용이 제공자나 중계 지점으로 넘어갑니다. 상세 기록 기능을 켜면 요청과 응답 본문이 데이터베이스에 쌓일 수도 있습니다. 실제 고객 정보 대신 합성 자료만 쓰는 이유입니다. 읽어 들인 자료 속 문장을 명령으로 오해하는 프롬프트 인젝션도 염두에 두셔야 하고, 승인 기능이 있더라도 심사 설정에 따라 그냥 통과하는 경로가 있을 수 있어 격리된 곳에서 동작을 직접 확인해야 합니다.
사용 제한과 방어 쪽에서 먼저 할 일
README는 허용 범위를 개인 학습, 코드 연구, 로컬 격리 환경의 원리 검증으로 못 박고, 실전 침투테스트와 운영환경 사용은 금지한다고 밝힙니다. 라이선스는 AGPL-3.0인데 저자의 별도 선언과 어떻게 맞물리는지는 법무 검토가 필요한 부분입니다.
방어 측면에서는 특정 도구 이름을 차단하는 것보다 서버가 요청자의 권한, 즉 인가 여부를 매번 판단하는 일이 우선입니다. 외부에 노출된 서비스를 빠짐없이 파악하고, 응답에 담긴 불필요한 정보를 줄이고, 비정상적인 조회를 가려낼 관측 체계를 갖추는 것이 금융위가 주문한 방향과도 맞닿아 있습니다. 보도를 부풀리지도 줄이지도 않고 이렇게 차분히 나눠 보는 것이 실제 대비에는 가장 도움이 되지 않을까 싶습니다.