ARTEX(아르텍스)는 거대언어모델(LLM)을 연결해 보안 점검의 계획과 도구 실행을 조율하는 공개 소프트웨어입니다. 모델 자체의 이름이 아니라, 모델·실행 도구·작업 기록을 묶는 시스템입니다. 최근 금융권 개인정보 유출 보도에 등장하면서 관심이 커졌지만, 관련 흔적을 발견했다는 사실과 공격 전체를 AI가 혼자 수행했다는 주장은 구분해야 합니다.
도입할 때도 같은 구분이 필요합니다. 보안 분석을 돕는 소프트웨어라도 파일을 읽고 명령을 실행하며 외부 모델에 내용을 보내면, 사용하는 조직이 새로운 위험을 떠안을 수 있습니다. 이 글은 공개 사건 자료와 공식 저장소를 읽어 ARTEX의 구조, 개발 이력, 내부 검토 시의 위험, 외부 평가에서 지켜야 할 경계를 설명합니다. 설치하거나 실행해 성능을 측정한 사용 후기는 아닙니다.
대표 이미지: AI 생성 개념도. 실제 ARTEX 화면이나 금융기관 시스템을 재현한 그림은 아닙니다.
1. 금융권 사건에서 어디까지 확인됐나
사건의 존재, ARTEX 관련 관측, 사용 흔적에 관한 취재, 최종 기술적 입증은 서로 다른 층위입니다. 자료가 나온 날짜까지 함께 읽어야 초기 보도와 후속 보도가 충돌하는 것처럼 보이는 문제를 줄일 수 있습니다.
금융위원회는 2026년 10월 2일 자료에서 신한은행 정보유출 사고에 이어 국민은행 등에서 추가 피해가 발생했고, 신고 후 현장조사와 공격 IP·유형 공유를 진행하고 있다고 밝혔습니다. 외부에 노출된 서비스 전체를 파악하고 인증·접근통제를 점검하도록 주문했습니다. 이 공식 자료에는 ARTEX라는 이름이나 완전 자율 AI 공격이라는 판정이 없습니다. 금융위원회 발표
10월 2일 서울경제는 공격에 쓰인 것으로 추정되는 서버의 HTML 제목에서 ARTEX의 중국어 침투테스트 콘솔 표식이 관측됐다고 보도했습니다. 당시 기사에는 실제 공격 도구로 사용됐는지는 확인되지 않았다는 단서가 있습니다. 이는 관련 환경이 있었을 가능성을 보여주는 관측으로 읽는 것이 적절합니다. 서울경제 초기 보도
10월 3일 헤럴드경제는 금융보안원 관계자를 인용해 신한은행 로그와 공격 IP 역추적에서 ARTEX 활용 흔적을 확인했다고 전했습니다. 같은 관계자는 사람의 개입 없이 AI가 독자적으로 공격한 것은 아니라고 설명했습니다. 따라서 후속 취재를 무시한 채 사용 근거가 전혀 없다고 쓰는 것도 부정확합니다. 헤럴드경제 후속 취재
다만 공개된 원시 로그나 최종 기술보고서를 확보해 독립적으로 재현·검증한 것은 아닙니다. 어떤 버전과 모델이 사용됐는지, 어느 기능이 어느 은행의 사건에 얼마나 관여했는지, 자동화 비중이 어느 정도였는지는 이 자료만으로 확정할 수 없습니다. 도구의 중국어 화면이나 개발 계정으로 공격자의 국적을 추정할 근거도 충분하지 않습니다.
이 구분은 사건을 축소하기 위한 것이 아닙니다. 무엇을 방어해야 하는지 정하려면 확인된 피해와 도구에 관한 추정을 섞지 않아야 합니다. 실제 요청에 대한 서버 측 접근통제와 외부 서비스 목록 점검은 특정 AI 도구의 관여 여부와 관계없이 필요합니다.
2. 모델 하나가 아니라 여러 구성 요소를 연결한 시스템
이 글에서 분석하는 프로젝트는 GitHub의 Autumn-27/ARTEX입니다. 공식 저장소는 Go 백엔드, Next.js 화면, PostgreSQL 데이터베이스와 여러 LLM 에이전트를 결합한 시스템으로 소개합니다. 에이전트란 모델의 답변을 작업 도구 호출과 이어 붙이는 프로그램입니다. 공식 저장소
큰 구조는 계획을 세우는 부분, 작업을 수행하는 부분, 결과를 저장하는 부분, 사람이 검토하는 부분으로 이해하면 됩니다. 계획 에이전트는 다음에 확인할 일을 나누고, 실행 에이전트는 맡은 작업을 도구로 처리합니다. 화면은 진행 상태와 결과를 보여 줍니다. 자동화라는 말은 이 반복을 뜻하며, 사람의 목표 지정·설정·검토까지 사라진다는 뜻은 아닙니다.
기록은 두 관점으로 나뉩니다. 자산 그래프는 어떤 대상과 서비스가 있는지 나타내는 연결 목록이고, 탐색 그래프는 이번 작업에서 어떤 생각·관측·발견이 이어졌는지 나타내는 기록입니다. 대상을 아는 것과 그 대상에 대해 무엇을 확인했는지를 분리해 관리합니다. 두 그래프는 연결되지만 같은 데이터 구조는 아닙니다.
공식 문서를 바탕으로 재구성한 개념도. README의 시스템 구조와 실행 에이전트 소스를 근거로 단순화했습니다. 공격 경로를 제시하는 그림은 아닙니다.
공개 소스의 실행 에이전트는 파일 읽기·쓰기·편집과 Bash 같은 도구를 구성합니다. Bash는 운영체제 명령을 실행하는 통로입니다. 각 작업의 전용 디렉터리를 만들지만, 디렉터리를 나누는 것만으로 프로세스가 다른 파일이나 네트워크에 접근하지 못하도록 막는 것은 아닙니다. 이 때문에 실행 환경의 권한이 중요한 검토 대상입니다. worker.go
3. 공개 이력에서 보이는 발전과 보안 수정
GitHub 메타데이터상 이 저장소의 생성 시각은 2026년 7월 26일이며, 릴리스 목록에도 같은 날 v0.1.0이 있습니다. 이것은 현재 공개 저장소와 배포 기록의 시작점이지, 개발 착수일을 입증하는 자료는 아닙니다. 대회 우승 프로젝트라는 설명은 저장소의 자기소개에 있으며, 이 글에서는 별도의 대회 결과 원문까지 검증하지 않았습니다. 저장소 메타데이터 · 릴리스 목록
조사 시점의 최신 정식 릴리스는 2026년 9월 24일 공개된 v0.3.14입니다. 분석한 main 브랜치는 커밋 b55ceb1로, 이후 변경을 포함합니다. 따라서 main의 현재 동작을 v0.3.14 배포본의 동작으로 그대로 설명하면 안 됩니다. 실제 검토에서는 릴리스·커밋·이미지 식별자를 고정하고 해당 버전의 설정을 확인해야 합니다.
변경 이력에는 안전 통제가 왜 계속 검증되어야 하는지 보여 주는 항목들이 있습니다. 아래 내용은 프로젝트가 기록한 과거 문제와 수정이며, 현재 모든 버전이 취약하다거나 사건의 원인이 이것이었다는 주장으로 읽어서는 안 됩니다. 공식 CHANGELOG
핵심은 수정 항목의 개수가 아닙니다. 모델 출력 해석, 작업 범위 조회, 네트워크 노출처럼 서로 다른 계층에서 문제가 생길 수 있다는 점입니다. 업데이트는 필요한 개선이지만, 한 번 업데이트했다는 사실이 전체 실행 환경의 안전성을 보장하지는 않습니다.
4. 내부에서 사용하면 조직도 공격 대상이 될 수 있다
보안 도구를 도입하는 위험은 특정 프로젝트에 백도어가 있다는 뜻과 다릅니다. 이번 읽기 분석에서 악성 백도어를 확인한 것은 아닙니다. 위험은 실행 권한, 외부 연결, 기록의 민감도와 공급망을 함께 살펴보면 구체적으로 드러납니다.
설치 경로와 공급망
공급망은 프로그램뿐 아니라 의존성·컨테이너·업데이트 등 실행물을 가져오는 경로를 뜻합니다. 공식 구성은 외부 컨테이너 이미지와 PostgreSQL을 사용하고, 로컬 데이터 및 스킬 디렉터리를 컨테이너에 연결합니다. 기본 이미지 태그가 바뀌면 같은 설정을 재사용해도 실행물이 달라질 수 있습니다. docker-compose.yml
학습 검토 환경에서도 출처·버전·해시를 확인하고, 검토하지 않은 설치 스크립트를 평소 업무 장비에서 바로 실행하지 않는 것이 좋습니다. 조직의 소스 저장소, SSH 키, 클라우드 자격증명, 브라우저 세션을 학습용 실행 환경과 공유하지 않아야 합니다. 이는 ARTEX가 그런 정보를 훔친다는 주장이 아니라, 변조되거나 과도한 권한을 받은 실행물의 피해 범위를 줄이는 일반 통제입니다.
모델 연결과 상세 기록
모델 연결 소스는 API 키와 사용자 지정 API 주소·프록시 설정을 다룹니다. 외부 모델을 연결하면 요청에 넣은 내용이 선택한 제공자나 중계 지점으로 전달될 수 있습니다. 어떤 공급자와 주소를 승인하는지, 필요한 내용을 얼마나 줄이는지, 보관 정책이 무엇인지 확인해야 합니다. 소스에 연결 기능이 있다는 사실만으로 특정 설치의 실제 전송 내용을 확정할 수는 없습니다. provider.go
상세 LLM 기록 기능은 설정에 따라 요청·응답과 원시 통신 본문을 데이터베이스에 저장합니다. 본문 기록과 토큰 사용량 기록은 별개입니다. 실행 중 화면에 보이지 않는 정보도 기록에 남을 수 있으므로 보존 기간, 접근 권한, 삭제·백업 정책을 따로 정해야 합니다. llmrec.go
실제 고객 응답, 운영 로그, 계약 자료, 계정과 키를 넣지 않고 합성 자료만 사용하는 이유가 여기에 있습니다. 기록 버튼을 끄는 것만으로 외부 모델에 내용을 보내지 않게 되는 것은 아닙니다. 외부 전송과 로컬 저장은 서로 다른 확인 항목입니다.
도구 권한과 프롬프트 인젝션
프롬프트 인젝션은 읽어야 할 자료 안의 문장을 에이전트에 대한 명령처럼 받아들이게 만드는 위험입니다. 공개 페이지나 저장소 내용, 도구 응답이 작업 자료인 상황에서 특히 주의해야 합니다. 이 부분은 ARTEX에서 재현한 취약점 보고가 아니라, 외부 자료를 읽고 실제 도구를 호출하는 구조에서 고려해야 할 위협 모델입니다.
예를 들어 학습 자료에 실행을 유도하는 문장이 섞여 있어도, 그 문장은 사람의 승인이나 조직 정책을 대신할 수 없습니다. 파일·프로세스·네트워크 권한을 밖에서 제한하고, 실행 전 승인과 기록을 검증해야 합니다. 프롬프트에 주의사항을 써 두는 것은 필요한 설명이지만 운영체제의 권한 경계를 만들지는 못합니다.
웹 화면과 네트워크 경계
Compose 예시는 화면/API 포트와 localhost로 제한된 프록시 포트를 별도로 지정합니다. 화면/API에 대한 노출 범위는 호스트 방화벽과 배포 설정까지 봐야 합니다. 컨테이너를 쓴다고 기본적으로 외부 통신이 차단되거나 조직 네트워크에서 격리되는 것도 아닙니다. 학습용 네트워크는 업무망과 분리하고, 승인된 모델 연결 외의 통신을 제한할 수 있어야 합니다. 공식 Compose 설정
5. 승인 화면이 있어도 모든 행동이 자동으로 차단되는 것은 아니다
분석한 main 소스에는 도구 호출을 허용·차단·사람에게 요청하는 규칙이 있습니다. 그러나 규칙을 적용하는 도구의 목록과 심사 기능 설정에 따라 동작이 달라집니다. 규칙에 맞지 않는 호출에서 모델 심사가 꺼져 있거나 연결되지 않으면 허용 경로가 있으며, 모델 실패나 해석 불가 결과는 설정된 실패 정책을 따릅니다. guard.go · intercept.go
따라서 “승인 기능이 있으니 안전하다”는 확인으로 끝내면 안 됩니다. 어떤 호출이 심사 대상인지, 승인 대기 중에는 실제 실행이 멈추는지, 심사 실패와 시간 초과에는 무엇이 일어나는지, 중단 후 이미 시작한 작업은 어떻게 처리되는지를 격리 환경에서 검증해야 합니다. 본문에서는 심사 기능을 끄거나 우회하는 방법을 다루지 않습니다.
공식 코드를 바탕으로 재구성한 운영 검토도. 승인 소스, 모델 연결, 기록 저장이 근거입니다. 모든 통제가 기본 제공·활성화된다는 의미는 아닙니다.
조직의 판단 기준은 명확하게 만들 수 있습니다. 업무 장비나 운영 계정 연결을 요구하는 검증이면 범위를 다시 줄이고, 승인되지 않은 목적지 통신을 막을 수 없다면 실행 검토를 보류합니다. 실제 고객 데이터가 필요한 설계라면 합성 자료로 바꿀 수 있는지 먼저 확인합니다. 보안 도구의 편리함과 그 도구를 사용하는 환경의 안전성은 별도로 평가해야 합니다.
6. 외부 모의해킹에는 어떤 방식으로 활용할 수 있나
여기서는 도구의 사용 제한이 먼저입니다. README의 저자 선언은 개인 학습·코드 연구·로컬 격리 원리 검증만을 허용 범위로 설명합니다. 자산을 소유했거나 허가를 받았더라도 웹사이트·온라인 서비스·네트워크 시스템에 실제 테스트를 수행하는 것과 실전 침투테스트·운영환경 사용을 금지한다고 명시합니다. 따라서 이 글은 ARTEX를 외부 실서비스에 투입하는 절차를 권하지 않습니다. README 사용 제한
저장소 라이선스는 AGPL-3.0이고, README도 오픈소스 라이선스 자체와 별도의 저자 사용 선언을 구분합니다. 서로 다른 문서를 한 문장으로 합쳐 상업적 사용이 전부 금지된다거나 서면 허가만 받으면 문제없다고 결론내려서는 안 됩니다. 별도 선언의 법적 효력이나 적용 관계는 이 기술 글이 판단할 범위가 아닙니다. 조직의 법무·보안 검토에서 두 문서를 함께 확인해야 합니다. LICENSE 원문
외부 평가 업무에는 ARTEX의 구조에서 얻을 수 있는 일반적인 운영 원칙을 적용할 수 있습니다. 실제 사용은 해당 목적을 허용하는 도구와 계약을 별도로 선택한 뒤 진행해야 합니다. 다음은 도구와 무관한 평가 계획의 예이며, ARTEX를 실대상에 실행하는 지침이 아닙니다.
- 서면 범위를 정한다. 자산 소유자의 승인, 대상 목록, 시간, 허용 활동과 제외 활동, 담당자, 중단 권한을 문서로 고정합니다. 계약 고객의 운영 데이터를 모델에 보낼 권한까지 자동으로 포함된다고 보지 않습니다.
- 환경을 분리한다. 업무용 계정과 장비를 재사용하지 않고, 승인된 테스트 계정·합성 자료·별도 워크스페이스를 사용합니다. 필요 없는 파일과 목적지에는 접근할 수 없도록 합니다.
- 실행 전에 사람이 판단한다. 모델의 제안과 실제 도구 실행을 나눕니다. 범위와 영향을 검토한 행동만 진행하고, 실패·불확실한 결과는 중단 또는 사람 검토로 넘깁니다.
- 증거를 최소화해 남긴다. 시간, 대상, 승인 근거, 관측 결과, 수정 후 재확인 결과를 연결합니다. 보고서에 원본 개인정보나 불필요한 통신 내용을 붙이지 않습니다.
- 중단 조건을 먼저 정한다. 범위 밖 대상, 실제 개인정보 노출, 승인되지 않은 통신, 서비스 이상, 로그 누락이 확인되면 멈춥니다. 결과는 검증됨·미확인·재확인 필요로 나누고 담당자에게 전달합니다.
ARTEX 자체를 학습한다면 로컬 격리 환경에서 합성 자산과 기록을 사용하는 범위로 제한합니다. 승인 대기, 범위 밖 요청 차단, 기록 보존·삭제, 중단 동작처럼 운영 경계를 확인하는 것이 학습 목표가 될 수 있습니다. 기능을 학습한다는 이유로 실제 금융기관이나 고객의 시스템을 대상으로 시험할 필요는 없습니다.
7. 금융권 방어에서 먼저 바뀌어야 할 것
특정 도구의 이름을 차단 목록에 추가하는 것만으로 문제를 해결하기는 어렵습니다. 사람이 쓰든 자동화 도구가 쓰든 서버는 요청자가 해당 정보에 접근할 자격이 있는지 판단해야 합니다. 인증은 누구인지 확인하는 과정이고, 인가는 그 사람이 특정 정보나 기능을 사용할 수 있는지 확인하는 과정입니다.
금융위가 주문한 외부 서비스 전수 파악과 접근통제 점검은 이 기본 문제와 연결됩니다. 직원·협력사용 서비스라도 외부에서 접근할 수 있으면 관리 대상입니다. 정상 로그인이 있었다는 사실만으로 모든 데이터 조회를 허용해서는 안 되며, 불필요한 응답 정보와 비정상 조회를 함께 검토해야 합니다. 이는 개별 사건의 최종 원인을 단정하는 설명이 아니라 공개 대응 방향을 실무 관점에서 해석한 것입니다. 금융위 대응 방향
ARTEX의 공개 구조는 AI가 반복 작업의 계획과 실행을 연결할 수 있음을 보여 줍니다. 그러나 이번 사건에서 정확히 어떤 기능이 작동했는지와 별개로, 방어 조직은 외부 자산의 접근통제와 자동화된 요청의 관측 능력을 강화해야 합니다. 도구를 내부에서 연구하는 조직은 모델 데이터와 실행 권한을 줄이고, 사람 승인과 독립된 격리를 함께 검증해야 합니다. 이 두 방향을 구분하면 사건 보도를 과장하지 않으면서도 실제 대비에 필요한 질문을 만들 수 있습니다.
참고 자료와 확인 범위
- 금융위원회, 금융권 침해위협 대응 발표: 사건 대응과 외부 시스템 점검의 공식 근거.
- 서울경제, 10월 2일 ARTEX 콘솔 표식 보도 · 헤럴드경제, 10월 3일 사용 흔적 취재: 관측과 후속 취재를 날짜별로 구분.
- Autumn-27/ARTEX · 릴리스 · 고정 커밋 CHANGELOG: 구조·배포 이력·수정 맥락.
- 고정 커밋의 소스 트리: 파일·도구·모델·승인·기록 연결에 대한 읽기 분석. 사건 증거를 재현한 자료는 아님.
- AGPL-3.0 LICENSE: README의 별도 사용 선언과 함께 검토할 원문.
공식 자료와 공개 저장소만 사용했습니다. 실제 내부 로그·고객 귀속 자료·공격 명령·침해 절차는 포함하지 않았습니다. 릴리스와 main 브랜치를 구분했으며, 후속 조사에서 사건의 도구 관여 범위가 달라지면 해당 설명도 갱신해야 합니다.
'일반IT > IT보안' 카테고리의 다른 글
| Presidio 한국어 탐지, 회귀 테스트로 검증하기 (0) | 2026.10.04 |
|---|---|
| AI 스킬, 회사에서 안전하게 쓰려면? 악성 스킬 검사부터 권한 통제까지 (0) | 2026.10.01 |
| Presidio와 NeMo Guardrails, AI DLP라고 불러도 될까? (0) | 2026.09.15 |
| 증거에서 대응까지: LLM 보안 사고 조사 (0) | 2026.09.03 |
| 소프트웨어 공급망 보안 입문: 무엇을 공부하고 어떤 도구로 검증할까 (0) | 2026.09.02 |
