메타의 새 모델, 카카오의 에이전트…AI가 답변에서 실행으로 넓어진다

메타의 이번 발표는 모델의 능력과 제품 제공 방식을 함께 보여준다. 일반 원더를 서비스에 연결하는 개발자와 Full을 코딩 도구에서 쓰는 이용자는 같은 출시 소식을 접해도 실제 선택지가 다르다. 성능 표를 읽기 전에 어느 모델을 어떤 경로로 이용할 수 있는지를 구분해야 하는 이유다.

메타는 AI 개발 체계를 전면 개편한 뒤 14개월 동안 기반을 다시 구축하고 상위 모델로 확장했다고 설명했다. 원더 계열은 프로메테우스 데이터센터에서 훈련됐으며, 이전 뮤즈 스파크에서 이어지는 확장 전략의 다음 단계로 소개됐다. 회사가 강조하는 방향은 전문 지식을 답하는 모델에서 개인과 업무의 여러 작업을 수행하는 에이전트로 이어진다.

맥락을 기억하고, 막힌 작업을 이어간다

Active Memory는 대화 사이의 중요한 정보를 유지하고 현재 작업과 관련된 내용을 다시 찾는 능력을 가리킨다. 단순히 긴 대화가 입력에 들어간다는 설명과는 구분된다. 핵심은 이전 정보 중 무엇이 지금 필요하고, 어떤 조건이 이후 대화에서 바뀌었는지를 작업에 반영하는 데 있다.

Active Focus는 목표를 향해 작업을 지속하는 능력이다. 메타는 다른 접근을 시도하고, 장애물과 새 정보에 대응하며, 필요할 때 질문하거나 중요한 행동 전에 확인하는 흐름으로 설명했다. 모든 행동을 확인 없이 실행한다는 발표는 아니다. 기억과 실행을 함께 강조한 것은 여러 도구와 수정 과정이 연결되는 업무를 겨냥한 접근으로 읽힌다.

공식 시연에는 이미지에서 게임을 만드는 작업, 개인 조건을 반영하는 달리기 계획, 여러 요구사항을 맞추는 결혼식 좌석 배치 등이 등장한다. 이는 메타가 공개한 시연이며 이 글에서 재현한 결과는 아니다. 서로 다른 자료와 조건을 연결하는 장면을 제시했다는 데 의미가 있지만, 시연만으로 일반 업무의 성공률을 판단할 수는 없다.

평가 범위도 길고 복잡한 과제로 확장됐다. 모델 카드의 MemoryBench는 6만 4천~10만 토큰의 대화에서 중요한 정보를 회수하는 내부 평가다. 방해가 되는 대화와 기존 사실을 수정하는 정보가 포함된다. 장기 개발 평가인 SWE-Marathon은 실제 프로젝트 테스트로 결과를 확인한다. 기억의 정확성과 작업의 완수를 서로 다른 과제로 다루는 구성이다.

공식 제품 페이지에 게시된 DeepSWE 1.1 점수는 원더 Full 79.0%, 일반 원더 78.8%다. 같은 표의 클로드 오퍼스 5.5는 74.2%다. 다만 모델 카드는 외부 코딩 결과에 각 제공자의 실행 도구가 남아 있다고 명시한다. SWE-Marathon에서 Full은 xhigh 추론 설정을 사용했다. 수치 자체와 통제된 동일 환경 비교는 별개의 정보다.

API 가격과 구독 제공은 별개의 선택지

두 모델의 컨텍스트 창은 공식 안내 기준 100만 토큰이다. 일반 원더 API 가격은 입력·출력·캐시 입력에 각각 책정됐다. 여기서 캐시 입력 단가는 모든 입력에 자동으로 적용되는 가격이 아니며, 토큰당 단가는 작업 하나를 끝내는 총비용과도 다르다. 재시도와 출력량에 따라 청구 규모가 달라질 수 있다.

Full은 Muse Code의 Power Usage와 Maximum Usage 요금제에 포함된다. 공식 페이지에 표시된 월 가격은 각각 50달러와 200달러이며 Full의 별도 API 가격은 공란이다. 따라서 일반 원더의 API 단가를 Full에 그대로 적용하거나, Full을 외부 서비스에 같은 방식으로 연결할 수 있다고 해석하면 제공 범위를 벗어난다.

Muse 앱에도 원더를 적용하겠다는 계획은 발표됐지만 구독자부터 순차 적용하는 일정으로 표현됐다. API 공개, 코딩 도구 제공, 개인용 앱 반영이 하나의 시점에 모든 이용자에게 완료된 것은 아니다. 출시 소식에서 모델 공개와 실제 서비스 배포를 나눠 볼 필요가 있다.

남은 쟁점은 강화된 기억과 실행 능력이 다양한 실제 환경에서도 유지되는지다. 모델 카드는 다단계 추론 오류, 언어별 평가 범위, 시각·공간 추론의 한계를 밝힌다. 제공 경로와 가격은 구체화됐지만, 업무의 완수율과 전체 비용은 사용하는 도구와 자료에 따라 달라진다. 이번 출시의 의미는 모델 성능과 서비스 이용 조건을 함께 비교해야 할 경쟁이 본격화됐다는 데 있다.

카카오의 발표는 AI 모델 하나의 성능보다 이용자가 AI를 만나는 장소와 작업의 연결을 앞세웠다. 카카오톡은 요청을 전달하는 입구가 되고, PC는 에이전트가 여러 도구를 사용하는 실행 공간이 되는 구상이다. 일상 대화와 실제 작업이 이어지는 인터페이스를 만든다는 점에서 모델 출시와 다른 층위의 뉴스다.

카나나라는 이름이 이번에 처음 등장한 것은 아니다. 카카오는 2025년 11월 카나나의 웹 버전을 출시하면서 모바일 앱의 개인 AI 메이트를 PC에서도 이용하도록 했다. 당시의 변화가 기존 대화 서비스를 웹으로 확장하는 데 있었다면, 이번 발표는 카카오톡과 PC의 작업 도구를 연결하는 방향을 제시했다. 기존 서비스와 새 계획을 구분하면 발표의 변화가 더 분명해진다.

카나나 스페이스의 설명에는 카카오톡 화면에서 두 손가락으로 쓸어 AI를 부르고 음성이나 텍스트로 요청하는 방식이 포함됐다. 현재 소개한 범위는 메시지와 일정, 검색, 설정 등이다. 주문·선물·예약·송금은 앞으로 기능을 넓히겠다는 계획으로 제시됐다. 이 기능들을 모두 지금 사용할 수 있는 목록으로 읽으면 출시 단계를 혼동하게 된다.

칸바스는 이용자가 원하는 에이전트를 설명하면 필요한 도구와 스킬을 연결하는 PC 서비스다. 카카오는 이용자가 허용한 범위 안에서 에이전트가 일을 수행하도록 구성하겠다고 밝혔다. 에이전트를 직접 만들고 나중에 공유하는 흐름을 준비한다는 점에서, 정해진 질문에 답하는 서비스보다 이용자 목적에 따른 실행 구성을 강조한다.

카카오톡 연결은 다음 단계의 계획

카나나 스페이스의 비공개 베타 테스트는 12월부터 일부 사전 신청자를 대상으로 진행한다. 칸바스도 이르면 연내 소규모 시험을 계획한다. 카카오톡에 에이전트 팀을 연결하는 새로운 공간은 2027년 상반기를 목표로 제시했다. 공개 발표, 제한된 시험, 서비스 연결이 순서대로 진행되는 일정이다.

이 일정은 이용자가 경험할 변화의 범위를 판단하는 정보다. 서비스 이름이 발표됐다는 사실과 자신의 계정에서 작업을 맡길 수 있다는 사실은 다르다. 공식 발표에는 정식 서비스의 전체 기능과 모든 이용자의 제공 시점이 확정돼 있지 않아, 오늘의 뉴스는 완성된 제품의 이용 후기보다 개발 방향과 시험 계획으로 읽는 것이 맞다.

기술 방향에서는 스마트폰이 처리할 요청과 대형 모델이 맡을 복잡한 작업을 나누는 전략을 소개했다. 모델과 도구, 실행 순서를 조율하는 역할도 함께 설명했다. 모든 요청을 하나의 큰 모델에 보내는 구성에서 벗어나 작업별로 실행 경로를 정하려는 접근이다. 이는 성능뿐 아니라 응답 속도와 운영 자원을 함께 다루는 문제로 연결된다.

개인화와 작업 실행이 결합되면 AI가 어떤 맥락을 알고 누구의 권한으로 행동하는지도 중요해진다. 카카오는 프로젝트 모자이크와 안전 플랫폼의 개발 방향을 제시했다. 공개 설명은 필요한 정보를 허용한 범위 안에서 전달한다는 구상이며, 실제 서비스에서 모든 조건이 검증됐다는 결과 발표는 아니다.

이번 발표의 의미는 국내 메신저가 AI 기능을 별도의 메뉴로 추가하는 데서 더 나아가, 여러 작업을 연결하는 접점을 지향한다는 것이다. 성공 여부는 기능의 개수만으로 결정되지 않는다. 시험 이용자의 실제 경험과 서비스 간 연결, 작업이 끝나는 과정이 공개돼야 구상의 구체적인 가치도 판단할 수 있다.

로컬 AI 모델은 파일을 보관할 공간과 실행 중 사용할 메모리를 모두 필요로 한다. 모델이 크면 더 큰 장비를 선택하거나 실행할 모델을 줄이는 판단으로 이어지기 쉽다. 자나스의 공개 결과는 일부 데이터를 저장장치에 두고 필요한 순간 가져오는 방식이 이 제약을 어느 범위까지 바꿀 수 있는지를 보여주는 실험이다.

자나스-LLM은 여러 전문가를 가진 MoE 모델에서 현재 계산에 필요한 가중치를 NVMe SSD로부터 읽는다. 반복해서 사용되는 부분은 메모리에 남겨 다시 읽는 부담을 줄인다. 모든 가중치를 동일하게 사용하는 모델과 구분되는 방식이며, 어떤 모델이든 메모리 제한 없이 같은 속도로 실행할 수 있다는 의미는 아니다.

제작자가 공개한 대표 사례는 파일 크기 48.4GB의 Qwen3-Next-80B-A3B다. 32GB 메모리 장비에서 답변 생성은 초당 24토큰, 비교한 llama.cpp는 2.8토큰이라고 보고했다. 긴 이름의 모델 수치보다 중요한 점은 메모리보다 큰 파일을 가진 모델의 실행 결과를 구체적인 장비 조건과 함께 공개했다는 데 있다.

비교 수치에는 같은 장비와 다른 실행 조건이 들어 있다

측정 장비는 Debian 13, Intel Core Ultra 9 185H, 내장 Arc GPU, 32GB 메모리와 NVMe SSD 구성이다. 공개된 비교는 10월 9~11일 측정에 기반한다. 10월 12일 릴리스 날짜와 측정 날짜는 같지 않으며, 릴리스 버전만 보고 그날 모든 시험이 이뤄졌다고 해석할 수는 없다.

큰 모델의 llama.cpp 실행에는 메모리 사용을 바꾸는 별도 빌드·옵션이 쓰였다. 제작자는 두 도구가 답변을 생성하기 전에 프롬프트를 다루는 측정 방식도 완전히 같지는 않다고 적었다. 따라서 24와 2.8을 나눠 얻는 값은 해당 비교의 숫자일 뿐, 모든 모델과 모든 컴퓨터에서 반복되는 개선 배수는 아니다.

토큰 생성 속도와 사용자가 작업 결과를 기다리는 전체 시간도 구분된다. 모델을 처음 준비하고 입력을 읽는 과정, 이후 응답을 만드는 과정은 각각 다른 자원을 쓴다. 이번 결과가 직접 보여주는 것은 특정 환경의 실행 지표이며 문서 처리나 개발 업무의 전체 생산성을 측정한 결과는 아니다.

Linux와 Windows 패키지를 제공한다는 점은 실행 경로가 공개됐다는 정보다. 지원 환경의 이름이 적혀 있어도 모든 CPU·그래픽카드 조합의 안정성을 시험한 것은 아니다. 제작자는 다른 하드웨어에서의 속도와 동작을 확인하지 못했다고 밝혔고, 운영용 제품이라는 표현도 피했다.

메모리가 부족할 때 저장장치를 활용하는 방식은 모델 실행의 경계를 넓힐 수 있지만, 저장장치의 처리량과 다른 프로그램의 자원 사용도 영향을 준다. 이는 큰 모델을 돌릴 수 있느냐와 일상적인 작업 중 안정적으로 돌릴 수 있느냐가 다른 질문임을 보여준다. 공개 숫자를 장비 구매의 보편적인 기준으로 삼기에는 검증 범위가 좁다.

이번 소식은 새로운 대형 모델 출시보다 실행 방식의 변화에 가깝다. 실제 장비에서 큰 모델을 다루는 방법을 공개하고 한계를 함께 제시했다는 점이 뉴스 가치다. 앞으로 여러 장비와 다양한 입력에서의 결과가 쌓이면, 메모리와 저장장치를 함께 설계하는 로컬 AI의 선택지도 더 구체적으로 평가할 수 있다.

코딩 AI가 저장소를 수정하려면 먼저 관련 코드를 찾아야 한다. 함수 이름을 검색하고 호출 경로를 따라가면서 여러 파일을 읽는 과정은 최종 수정과 별개로 반복될 수 있다. 콜그렙 에이전트는 이 탐색을 주 코딩 모델이 모두 수행하는 대신 별도의 작은 모델이 맡도록 만든 구성이다.

제품 이름이 비슷하지만 ColGrep과 ColGrep-Agent는 역할이 다르다. ColGrep은 코드의 의미를 바탕으로 찾는 검색 엔진이다. 에이전트는 이 검색과 읽기 전용 터미널을 이용해 후보를 확인하고, 요청과 관련된 파일·줄 범위·코드를 반환한다. 검색 결과를 한 번 나열하는 도구와 탐색을 이어가는 모델을 구분할 수 있다.

공식 모델 카드는 2B 규모의 검색 모델을 로컬에서 실행하는 흐름을 설명한다. 주 코딩 에이전트가 질문을 보내면 소형 모델이 저장소를 탐색하고 정리한 결과를 돌려준다. 큰 모델 하나가 모든 파일을 읽는 대신 역할별로 실행 주체를 나누는 설계다. 주 에이전트 자체를 대체하는 모델로 소개되지는 않았다.

줄어든 것은 검색 과정의 API 사용량

제작자는 Claude Code의 Sonnet 5.5를 주 에이전트로 사용하고 학습에서 보지 않은 저장소 13개를 평가했다고 설명했다. 검색 질문은 52개이며 네 가지 구성에서 각 질문을 세 차례 실행했다. 합계는 624개 세션이다. 평가의 크기와 실행 구성을 공개했다는 점은 결과의 적용 범위를 읽는 데 필요한 정보다.

발표된 자체 결과는 grep 기반 비교 구성보다 API 토큰 사용량 34%, 캐시를 고려한 API 비용 40% 감소다. 검색 정확도의 차이는 통계적으로 유의하지 않았다고 보고했다. 이 문장은 정확도가 모든 조건에서 완전히 같다는 뜻은 아니다. 해당 평가에서는 유의한 차이를 확인하지 못했다는 범위로 읽어야 한다.

평가 질문은 코드 위치를 찾는 검색 과제였다. 기능 개발이나 오류 수정, 테스트와 배포까지 완료하는 과제를 대상으로 한 전체 비용 비교는 아니다. 검색 이후 필요한 정보가 빠져 다시 탐색하거나 수정을 되돌리는 과정이 생길 수 있으므로, 이 수치를 개발 업무 전체의 절감률로 옮기면 측정 대상이 달라진다.

모델을 로컬에서 실행하는 자원도 결과 해석의 일부다. 주 API의 토큰이 줄어도 검색 모델과 인덱스를 준비하고 실행하는 시간은 따로 든다. 제작자가 제시한 지표는 외부 API 사용의 변화이며, 모든 장비 비용과 초기 준비를 합친 총비용을 대표하는 숫자는 아니다.

코드 전달 범위 역시 주 에이전트의 구성에 달려 있다. 검색은 로컬에서 하더라도 결과를 외부 모델에 전달하면 선택된 코드가 외부 요청에 포함될 수 있다. 로컬 검색 기능과 전체 개발 환경의 데이터 경로를 같은 것으로 이해할 수는 없다. 어떤 정보를 넘기는지를 결정하는 연결 방식이 남는다.

이번 발표는 코딩 AI의 경쟁이 큰 모델의 능력에 더해 필요한 정보를 효율적으로 공급하는 구성으로 확장되고 있음을 보여준다. 소형 모델이 맡을 역할을 명확히 정한 사례라는 점에서 의미가 있다. 앞으로의 쟁점은 검색의 비용 감소가 실제 수정의 정확성과 전체 작업 시간에도 이어지는지다.

문서 자동화에서 글자를 읽는 일과 내용을 올바른 순서로 구조화하는 일은 연결돼 있지만 같은 작업은 아니다. 여러 단의 본문, 표의 머리글, 차트의 축과 숫자가 섞이면 텍스트를 추출해도 다음 집계나 검색에 필요한 관계가 사라질 수 있다. 라이트온 OCR 3의 발표는 이 관계를 출력에 포함하는 방향을 보여준다.

세 모델은 텍스트 추출과 grounding의 두 모드를 제공한다. 기본 모드는 문서를 텍스트로 옮기고, grounding은 영역 종류와 경계 좌표를 붙인다. 이미지에는 짧은 설명을, 차트에는 데이터 표를 함께 출력한다. 글자의 인식 결과에 문서의 위치·시각적 요소를 연결하는 구성이다.

모델 카드에 설명된 좌표는 페이지를 기준으로 0~1000 범위로 정규화한다. 서로 다른 페이지 크기에서도 위치를 일정한 표현으로 다루기 위한 방식이다. 다만 위치가 붙었다고 숫자와 단위까지 정확하다는 뜻은 아니다. 영역을 찾는 정확성과 영역 안의 내용을 읽는 정확성은 별도로 평가해야 한다.

1B 모델은 이전 라이트온 OCR 2의 구조를 유지한다. 0.8B와 4B는 Qwen3.5의 시각·언어 구조를 채택했다. 크기 차이만 있는 세 모델이라고 보기 어렵고, 기존 배포와의 연결 방식도 선택에 영향을 준다. 공식 안내는 1B를 기존 구성의 교체 경로로, 다른 모델을 별도의 속도·품질 선택지로 설명한다.

공개 점수에서도 문서 유형별 차이가 나타난다

제작자가 제시한 olmOCR-Bench 전체 점수는 4B 모델 86.3, 0.8B 85.5, 1B 84.5다. 4B가 가장 높은 전체 점수를 얻었지만 세부 항목에서는 1B가 여러 단으로 된 페이지, 0.8B가 작은 글자가 길게 이어진 문서에서 강점을 보였다. 가장 큰 모델이 모든 종류의 문서에서 같은 순서로 앞선 결과는 아니다.

비교표에는 이전 OCR 2의 전체 점수가 일부 항목을 제외해 계산됐다는 주석도 있다. 새 모델과 이전 모델의 전체 숫자를 그대로 빼면 평가 항목의 차이가 섞인다. 출력 형식의 정규화와 이미지 해상도도 결과에 영향을 준다고 설명돼 있어, 점수와 함께 평가 구성 자체를 확인할 필요가 있다.

문서 구조를 출력에 넣으면 사람이 원본을 다시 확인하는 경로를 만들 수 있다. 어떤 페이지와 영역에서 얻은 값인지 남기는 것이 그 출발점이다. 이는 모델이 오류를 없앴다는 주장이 아니라 결과와 근거를 연결할 수 있는 정보가 늘었다는 변화다. 검색과 요약에서의 활용 가능성도 이 연결에 달려 있다.

모델들은 연구와 상업적 이용을 허용하는 Apache 2.0 라이선스로 공개됐다. 공개 라이선스는 이용 조건의 한 요소이며 실제 문서 처리의 장비·운영 비용을 결정하지는 않는다. 개인정보가 담긴 자료의 저장과 전달은 연결한 서비스의 구성에 따라 달라진다.

이번 소식은 OCR의 범위가 글자 인식을 넘어 문서의 위치와 시각적 내용을 함께 다루는 쪽으로 넓어지고 있음을 보여준다. 공개된 결과는 유용한 비교 자료지만 조직마다 쓰는 양식과 언어, 스캔 품질은 다르다. 현 단계에서 확인된 변화는 새로운 출력 구조와 모델 선택지이며, 모든 문서 처리의 정확성이나 자동화 완성을 보장하는 결과는 아니다.

AI 에이전트가 프로그램을 실행하고 파일을 고치는 작업에서는 답변의 정확성뿐 아니라 실제 행동의 범위가 중요해진다. 읽어야 할 자료와 바꿀 결과, 접속할 서비스가 많아질수록 권한의 경계를 정하는 일이 운영의 일부가 된다. MXC는 이 경계를 모델의 응답 밖에서 다루려는 구성이다.

공식 저장소는 MXC를 앱에 연결하는 SDK와 실행 환경으로 설명한다. 앱은 실행할 작업과 정책을 지정하고 격리 방식은 해당 환경에 맞춰 적용된다. 전체 컴퓨터에 자동으로 보호 기능을 덧씌우는 서비스보다, 개발자가 자신의 앱에서 실행을 구성하는 기반에 가깝다.

정책에는 파일의 읽기와 쓰기, 금지할 경로, 네트워크 접근 등을 정의한다. 같은 파일이라도 읽을 수 있는지와 바꿀 수 있는지를 나눠 다룰 수 있다. 어떤 행동을 하도록 지시했는지와 실제로 어떤 행동까지 가능한지를 분리한다는 점이 핵심이다. 작업 목적과 실행 권한이 서로 다른 설정으로 남는다.

공식 안내는 Rust와 .NET, Node 계열의 연동 경로를 제공한다. 기존 앱에서 AI 도구 실행을 연결하는 구성이므로, 사용하는 개발 환경과 운영체제의 지원 조건이 함께 맞아야 한다. SDK의 존재와 실제 서비스에 연결된 상태는 다르며, 정식 제공 발표가 기존 앱의 권한 구성을 자동으로 바꿔 주는 것은 아니다.

운영체제별 지원과 향후 관리 기능은 구분된다

Microsoft는 Windows·macOS·Linux에서 사용할 수 있는 실행 방식을 구분해 소개했다. 각 방식의 보안 특성과 적합한 작업이 다르다고 명시한다. Windows 전용 세션 격리와 실험 단계 MicroVM도 같은 표 안에서 별도 조건으로 다뤄진다. 운영체제 이름만 확인해 기능이 동일하다고 판단하기 어렵다.

에이전트 활동을 구분하는 Entra 연동과 일부 Intune 정책 관리 기능은 앞으로 제공할 항목으로 표현됐다. 현재 SDK로 할 수 있는 일과 조직 차원의 관리 체계에 추가될 기능을 나눠 읽어야 한다. 정식 제공이라는 한 문구만으로 모든 관리 기능의 준비 상태를 설명할 수는 없다.

외부 정책이 다루는 것은 접근의 경계다. 경계 안에서 실행된 코드가 잘못된 보고서를 만들거나 잘못된 계산을 하는 문제까지 자동으로 해결하는 것은 아니다. 접근 제한과 산출물의 정확성이 다른 관리 항목으로 남는 이유다. 격리의 효과를 모델의 판단 능력과 같은 성능으로 평가할 수는 없다.

에이전트가 맡는 작업의 규모가 커질수록 실행 권한을 어디에서 정의하고 변경할지에 대한 책임도 분명해져야 한다. 모델이 제안한 행동을 앱이 실행하는 구조에서는 모델의 출력, 앱의 판단, 운영체제의 제한이 연결된다. MXC의 공개는 이 중 실행 환경의 통제 지점을 공통 정책으로 다루는 선택지를 추가했다.

이번 발표는 에이전트의 기능 확대를 뒷받침하는 운영 기반에 관한 소식이다. 중요한 변화는 더 많은 작업을 수행하는 능력과 함께 그 작업이 가능한 범위를 명시하려는 도구가 공개됐다는 점이다. 실제 적용 범위는 현재 지원하는 실행 방식과 관리 기능, 앱의 구성에 따라 달라진다.