2026년 7월 30일 | AI 최신 트렌드
문서 안의 숨은 지시가 다음 문서로 복제되고, 메모리에 다 올릴 수 없던 MoE 모델은 필요한 expert만 SSD에서 읽기 시작했다. 음악 생성은 한 번의 결과보다 가사·보컬·편집 제어를 제품 중심에 놓고, 안전 분류기는 고정 카테고리 대신 배포 정책을 질문으로 받는다. 7월 30일 아침에 확인한 네 소식은 서로 다른 영역처럼 보이지만 모델이 읽고, 저장하고, 판단하는 경계를 어떻게 바깥에서 설계할지라는 한 문제로 이어진다.
Word 문서의 숨은 지시가 Copilot 출력으로 복제됐다
Enklype Security의 coordinated disclosure 보고서는 Microsoft Copilot for Word를 대상으로 문서 기반 cross-domain prompt injection, 즉 XPIA가 어떻게 이어질 수 있는지 보여 준다. 외부 Word 문서에 흰색·작은 글꼴로 숨긴 지시를 넣으면 사람이 보지 못해도 Copilot이 서식을 걷어 낸 텍스트를 읽을 수 있었다. 실험에서는 재무 수치를 바꾸고, 공격 지시를 첨부 텍스트와 함께 새 출력 문서에 다시 넣는 흐름이 재현됐다.
핵심은 한 번 잘못 답한 것으로 끝나지 않는다는 점이다. 오염된 문서를 Copilot으로 편집한 결과물이 다음 분기의 입력이 되면, 원래 공격 문서가 없어도 숨은 지시가 일상적인 업무 흐름을 따라 이동할 수 있다. 연구자는 이를 self-propagating AI worm으로 설명했다. 다만 이 표현을 일반적인 실행 파일 악성코드와 같다고 읽으면 과장이다. 복제되는 대상은 바이너리가 아니다. AI가 신뢰하는 문서 컨텍스트 안의 지시가 이동하며, 전파 조건도 Copilot을 통한 읽기·편집 과정에 묶여 있다.
Microsoft는 보고된 특정 페이로드를 완화했다고 연구자에게 알렸지만, 저자는 출판 시점에도 같은 취약점 클래스가 남아 있다고 주장한다. 고객이 설정 하나로 완전히 막을 수 있는 해법도 없다고 적었다. 따라서 실무에서는 “문서는 데이터이고 프롬프트는 명령”이라는 구분만 믿기 어렵다. 외부 문서에서 온 숨은 텍스트를 별도 신뢰 등급으로 표시하고, Copilot이 생성한 파일에 원문에 없던 숨은 텍스트가 생겼는지 검사하며, 다음 자동화 단계로 넘기기 전에 재오염 여부를 확인해야 한다.
나는 이 사례에서 최종 답변 필터보다 입력 출처와 출력 계보가 더 중요하다고 봤다. 누가 만든 문서인지, 어떤 숨은 레이어와 첨부가 있었는지, AI가 어느 내용을 새 파일로 복사했는지를 로그로 남겨야 한다. 에이전트가 문서를 단순히 요약할 때보다 편집하고 저장할 때 위험이 커지는 이유도 여기에 있다. 읽기 권한과 쓰기 권한을 한 번에 주지 않고, 새 문서의 숨은 콘텐츠 diff를 승인 단계에 넣는 편이 현실적인 방어선이다.
조직 차원의 점검도 파일 업로드 차단만으로는 부족하다. 외부 문서를 연 뒤 생성된 문서가 다시 검색 인덱스, 메일 첨부, 협업 저장소로 들어가는 경로를 그려 보고, 각 경계에서 숨은 텍스트와 비정상 첨부를 검사해야 한다. 특히 자동 요약 결과를 원문과 같은 신뢰 등급으로 저장하지 않는 것이 중요하다. AI가 만든 파생 문서는 검증을 마친 사본으로 간주할 수 없으며, 새 입력으로 다뤄야 한다.
TurboFieldfare는 MoE expert를 SSD에서 토큰별로 읽는다
TurboFieldfare는 Gemma 4 26B-A4B의 14.3GB 전체 가중치를 메모리에 올리지 않고 약 2GB 예산으로 실행하려는 오픈소스 런타임이다. 1.35GB 공유 core와 FP16 KV cache를 메모리에 상주시킨 뒤, Mixture of Experts 구조에서 현재 토큰에 필요한 expert만 SSD에서 스트리밍한다. Swift와 Metal로 구현했고, 8GB Apple Silicon Mac도 대상으로 삼는다.
이 접근은 모델을 더 작게 양자화하는 방법과 방향이 다르다. 총 가중치를 모두 RAM에 적재하는 전제를 버리고 메모리와 SSD 사이의 계층 자체를 추론 런타임으로 사용한다. MoE는 토큰마다 일부 expert만 활성화하므로 이론상 필요한 부분만 가져올 수 있다. 대신 어떤 expert가 다음에 필요할지, 페이지 캐시에 무엇이 남아 있는지, SSD가 얼마나 빨리 읽는지가 지연시간을 직접 결정한다.
제작자가 공개한 측정에서 8GB M2 MacBook Air의 decode 속도는 초당 5.1~6.3토큰, 24GB M5 Pro는 초당 31~35토큰이었다. 같은 모델이라도 하드웨어, 프롬프트 길이, 생성 길이, page-cache 상태에 따라 결과가 달라진다고 명시했다. 프로젝트 자체 측정에 해당하므로 수치의 절대값보다, 103개 실험 기록을 kernel·cache·I/O·prefill·decode로 나눠 공개한 방식에 더 주목할 만하다.
저메모리 실행이 곧 빠른 실행을 뜻하지는 않는다. SSD에서 expert를 자주 읽으면 저장장치 수명, 발열, 동시 I/O, 긴 컨텍스트에서 커지는 KV cache가 새 병목이 된다. 그래도 이 프로젝트는 로컬 LLM의 하한을 RAM 용량 하나로만 정하지 않게 만든다. 앞으로는 모델 파일 크기와 최대 메모리에 더해 expert cache 적중률, SSD 읽기량, 첫 토큰 지연, 지속 decode 속도를 함께 봐야 한다.
이 구조가 범용 런타임으로 바로 옮겨진다고 단정할 수도 없다. TurboFieldfare는 Gemma 4 26B-A4B에 맞춘 구현이고, expert 배치와 라우팅 구조가 다른 모델에서는 캐시 전략부터 다시 짜야 한다. 그래도 GPU나 RAM을 무조건 늘리는 대신 저장장치와 활성 가중치의 이동을 함께 최적화하는 방향은 선명하다. 로컬 추론 경쟁이 양자화 비트 수에서 메모리 계층 스케줄링으로 넓어지고 있다.
Lyria 3.5는 음악 생성보다 수정 가능한 제어를 앞세웠다
Google은 Lyria 3.5를 Flow Music에 적용하며 음악성, 가사, 보컬 품질, 창작 제어의 개선을 발표했다. 공식 설명은 더 자연스럽고 복잡한 멜로디 구조, 프롬프트를 더 잘 따르는 가사, 풍부한 보컬을 전면에 놓는다. 생성 모델의 품질 업데이트이지만, 제품 관점에서는 한 번에 그럴듯한 곡을 뽑는 것보다 사용자가 원하는 방향으로 조정할 수 있는지가 더 중요한 변화다.
음악 생성은 이미지보다 시간축이 길다. 도입부가 좋더라도 후렴의 가사나 보컬 톤이 어긋나면 전체를 다시 만들기 쉽고, 그렇게 되면 원하는 부분까지 함께 바뀐다. Flow Music이 이전부터 Replace와 Extend 같은 구간 편집을 강조했던 이유도 같다. Lyria 3.5의 품질 개선은 부분 수정이 가능한 작업 표면과 결합될 때 실제 창작 도구에 가까워진다.
평가 기준도 단일 선호 점수로 줄이기 어렵다. 멜로디 자연스러움, 가사와 프롬프트의 의미 일치, 보컬 발음, 장르 유지, 구간을 바꾼 뒤 앞뒤 연결이 각각 다른 문제다. 저작권과 스타일 모방, 생성 음원의 식별 정보도 제품 밖의 부가 조건이 아니다. 모델이 좋아질수록 어떤 데이터와 허용 범위로 결과가 만들어졌는지, 수정 이력이 남는지까지 창작 워크플로의 품질에 포함된다.
나는 생성 음악 도구를 볼 때 완성본 데모보다 두 번째 요청을 먼저 본다. “후렴 가사만 바꾸되 리듬은 유지해 달라”처럼 서로 충돌하는 제약을 얼마나 안정적으로 처리하는지가 장기 사용성을 가른다. Lyria 3.5의 다음 검증 포인트도 첫 생성의 화려함보다 재편집 성공률, 버전 간 변화 범위, 보컬·반주 stem 제어처럼 사용자가 결과를 소유하고 다듬을 수 있는 정도에 있다.
팀 작업에서는 생성 시점의 프롬프트와 모델 버전, 교체한 구간, 사람이 직접 고친 가사를 함께 보존할 필요가 있다. 같은 프로젝트를 며칠 뒤 다시 열었을 때 어느 부분을 재생성할 수 있는지가 재현성을 가른다. 음악 AI의 버전 관리는 코드 diff처럼 단순하지 않지만, 최소한 편집 구간과 입력 조건을 남기면 우연히 얻은 결과를 반복 가능한 제작 과정으로 바꿀 수 있다.
Shieldstral은 안전 정책을 고정 라벨 대신 질문으로 받는다
Shieldstral은 30억 파라미터 규모의 정책 적응형 멀티모달 안전 분류기다. 고정된 유해 카테고리를 바로 예측하는 대신, 자연어로 적은 안전 정책과 텍스트 또는 이미지를 함께 받고 yes·no 문제로 바꾼다. 사이버보안 연구 도구와 정신건강 서비스처럼 같은 문장도 배포 맥락에 따라 다르게 다뤄야 한다는 점을 모델 입력에 명시하려는 설계다.
저자들은 서로 다른 taxonomy를 가진 안전 데이터셋을 하나의 이진 질의응답 형식으로 합치고, 약 5,410만 개 샘플을 구성했다고 보고했다. 텍스트 안전 벤치마크에서는 약 7배 큰 모델과 맞먹거나 앞섰고, 멀티모달 안전 분류에서는 새로운 최고 성능을 기록했다고 주장한다. 이 수치는 논문 저자들의 실험 범위 안에서 읽어야 하지만, 작은 분류기를 별도 계층으로 두려는 방향은 서빙 비용과 지연 측면에서 실용적이다.
흥미로운 지점은 “안전한가”를 한 번 묻는 것이 아니라 어떤 정책에 비춰 안전한가를 입력으로 만든 데 있다. 서비스마다 금지 범위가 다를 때 모델을 매번 다시 학습하기보다 정책 문장을 바꿔 적용할 수 있다. 반대로 정책 문구가 모호하거나 서로 충돌하면 분류 결과도 흔들릴 수 있다. 배포 전에 정책 문장 자체의 회귀 테스트와 경계 사례를 함께 관리해야 하는 이유다.
멀티모달 안전에서는 이미지와 텍스트를 따로 검사해서 놓치는 조합이 많다. 평범한 이미지에 위험한 캡션이 붙거나, 문장만 보면 무해하지만 이미지 속 세부와 합쳐져 의미가 바뀔 수 있다. Shieldstral 같은 별도 분류 계층은 생성 모델 앞뒤에 붙이기 쉽지만, 분류기 한 개를 최종 판단자로 두면 새로운 우회 패턴에 취약하다. 정책별 임계값, 사람이 재검토할 구간, 거짓 양성으로 막힌 정상 요청, 배포 뒤 정책 변경 이력을 같이 남겨야 한다.
운영 환경에서 필요한 평가는 평균 F1 하나보다 정책별 오류 비용에 가깝다. 아동 안전, 의료 조언, 보안 연구처럼 영역이 달라지면 거짓 음성과 거짓 양성의 부담도 달라진다. 배포 정책을 바꾼 날에는 같은 회귀 세트를 다시 돌리고, 이전 결과와 달라진 사례를 사람이 읽을 수 있어야 한다. 정책 적응형 분류기의 장점은 정책 변경이 쉬운 데 있지만, 그만큼 변경 이력과 승인 책임도 분명해야 한다.