🤖
1214 in / 4576 out / 5790 total tokens
오늘 건진 두 소식이 묘하게 대척점에 있다. 한쪽은 클라우드 기반 LLM이 '사고'라는 영역을 어떻게 정복하려는지 보여주고, 다른 한쪽은 그걸 로컬에서 얼마나 빨리 돌릴 수 있는지 실험한다. 클라우드 vs 엣지, 거대 모델 vs 경량 에이전트—결국 같은 문제를 다른 각도에서 파고드는 셈이다.
🔥 핫 토픽
Claude is a space to think — Anthropic의 Project Glasswing 확장
https://www.anthropic.com/news/expanding-project-glasswing
Anthropic이 "Project Glasswing"이라는 내부 프로젝트를 공식적으로 확장한다고 발표했다. 핵심 메시지는 단순하다: Claude를 단순한 채팅봇이 아니라 **사고의 공간(space to think)**으로 만들겠다는 거다. 이건 단순한 마케팅 문구가 아니다. 확장된 컨텍스트 윈도우, 개선된 추론 체인, 그리고 사용자가 프롬프트 사이사이에서 Claude가 '생각하는 과정'을 들여다볼 수 있는 인터페이스 변화까지 포함된 종합적인 업데이트다.
왜 중요한가. 지금까지 LLM 경쟁은 '누가 더 긴 컨텍스트를 처리하나' 싸움이었다. 100K, 200K, 1M... 숫자 경쟁에 가까웠다. 근데 Anthropic이 노리는 건 다음 단계다. 컨텍스트가 길어진 게 아니라, 그 안에서 모델이 어떻게 사고하는지를 구조화하겠다는 거다. 게임 개발에 비유하자면, 맵 크기를 늘리는 게 아니라 AI의 행동 트리를 더 정교하게 짜는 셈이다. 경쟁 구도에서 보면, OpenAI의 o1 시리즈가 '추론 모델'이라는 카테고리를 열었다면, Anthropic은 그걸 '작업 공간' 차원으로 끌어올리려는 거다. 단발성 질문-답변이 아니라, 장기적인 프로젝트 단위에서 Claude가持续的으로 맥락을 유지하고 사고하는 환경을 제공하겠다는 거.
개발자에게 어떤 영향이 있나. 실무 관점에서 가장 큰 변화는 '세션 영속성'이다. 지금까지는 IDE에서 Claude Copilot 쓸 때, 대화 맥락이 길어지면 앞부분을 잊어버리는 일이 다반사였다. Project Glasswing은 이걸 프로젝트 단위의 메모리 구조로 관리하겠다는 거다. 언리얼 엔진 프로젝트에서 블루프린트 변환 작업을 Claude에게 맡긴다고 치자. 지금은 세션을 껐다 켜면 처음부터 다시 설명해야 한다. Glasswing 구조에서는 프로젝트 공간 자체가 Claude의 작업 메모리에 남는다. 마치 VS Code의 워크스페이스 설정이 .vscode/settings.에 저장되는 것과 비슷한 원리다.
기술 배경. '사고 공간'이라는 건 구체적으로 뭘까. 추측이 섞이긴 하지만, 핵심은 **구조화된 중간 표현(intermediate representation)**에 있다. LLM이 바로 답을 생성하는 게 아니라, 내부적으로 문제를 분해하고, 각 단계를 검증하고, 최종 답을 조립하는 과정을 거친다. o1이 chain-of-thought를 강제하는 방식이라면, Anthropic의 접근은 사용자가 그 사고 과정을 인터랙티브하게 들여다보고 수정할 수 있는 환경을 제공하는 쪽에 가깝다. 게임 서버 아키텍처에 비유하면, o1은 백엔드에서 비동기 처리를 돌리고 결과만 클라이언트에 쏴주는 방식이고, Glasswing은 클라이언트가 서버의 처리 과정을 실시간으로 모니터링하고 중간에 개입할 수 있는 방식이다. 당연히 후자가 구현 난이도가 높지만, 사용자 경험은 압도적으로 좋다.
한 가지 우려도 있다. '사고 공간'이 클수록 비용도 올라간다. API 호출 관점에서 토큰 사용량이 어떻게 측정될지가 핵심이다. 추론 과정 전체를 토큰으로 계산하면, 현재 가격 구조에서는 프로젝트 단위 작업이 현실적으로 어려울 수 있다. Anthropic이 이 부분을 어떻게 풀지가 실제 도입의 분기점이 될 거다.
출처: Anthropic News
📰 뉴스
Holo3.1: 빠르고 로컬에서 도는 컴퓨터 사용 에이전트
https://huggingface.co/blog/Hcompany/holo31
HuggingFace 블로그에 Hcompany에서 만든 Holo3.1이 소개됐다. 핵심은 로컬 환경에서 빠르게 동작하는 컴퓨터 사용 에이전트라는 거다. 클라우드 API를 호출하지 않고, 사용자의 PC에서 직접 화면을 인식하고 마우스/키보드 조작까지 수행하는 에이전트다. 'Computer Use'라는 건 Anthropic이 Claude 3.5 Sonnet으로 처음 대규모로 선보인 개념인데, Holo3.1은 그걸 경량화해서 로컬에서 돌리겠다는 야심 찬 프로젝트다.
왜 중요한가. Computer Use 에이전트는 2024년 하반기 AI 업계의 가장 뜨거운 주제 중 하나다. 근데 문제가 하나 있다. 클라우드 기반 에이전트는 렌더링 지연이 치명적이다. 화면을 캡처해서 클라우드로 보내고, 거기서 모델이 판단하고, 다시 명령을 보내면 최소 500ms~2초가 걸린다. 사람이 마우스를 움직이는 건 실시간인데, 에이전트는 1초에 한 번씩 화면을 보고 행동하는 셈이다. 게임 개발자로서 말하면, 이건 핑 1000ms로 멀티플레이어 게임을 하는 거다. 플레이 불가능하다. Holo3.1이 로컬에서 돈다는 건 이 지연을 50ms 이하로 줄일 수 있다는 뜻이다. 실시간 게임이 가능해지는 거지.
개발자 관점에서 뭘 의미하나. 두 가지 측면이 있다. 하나는 프라이버시다. 화면 캡처 데이터를 클라우드로 보내지 않아도 된다. 회사에서 내부 툴 자동화할 때, 화면에 민감한 정보가 나오면 클라우드 기반 에이전트는 쓰기 어렵다. 근데 로컬 에이전트는 그 걱정이 없다. 다른 하나는 비용이다. 클라우드 API는 호출할 때마다 돈이 나간다. 하루 종일 에이전트를 돌리면 API 비용만 수십 달러가 나올 수 있다. 로컬 모델은 전기비만 든다. 하드웨어 투자비는 있지만, 장기적으로는 압도적으로 저렴하다.
기술 배경. 로컬에서 Computer Use 에이전트를 돌린다는 게 기술적으로 왜 어려운가. 세 가지 병목이 있다. 첫째, 비전 모델의 크기다. 화면을 이해하려면 멀티모달 모델이 필요한데, 이게 보통 7B~70B 파라미터급이다. 로컬 GPU 메모리에 다 들어와야 한다. 둘째, 추론 속도다. 화면을 60fps로 캡처해서 실시간으로 처리하려면, 프레임당 16ms 안에 추론을 끝내야 한다. 현재 기술로는 불가능에 가깝다. 그래서 Holo3.1은 프레임 단위 처리가 아니라 이벤트 기반 처리를 하는 걸로 보인다. 화면에 의미 있는 변화가 있을 때만 추론을 돌리는 거다. 게임으로 치면 틱 기반 처리가 아니라 이벤트 드리븐 아키텍처인 셈이다. 셋째, 액션 매핑이다. 모델이 '여기를 클릭해라'라고 판단해도, 실제 마우스 이벤트로 변환하는 건 또 다른 문제다. 좌표 변환, 윈도우 포커스 관리, 권한 문제 등등. 언리얼에서 UMG 버튼 클릭을 처리할 때 버튼마다 클릭 가능 영역을 계산하는 것과 비슷한 복잡도다.
Holo3.1이 HuggingFace 블로그에 올라왔다는 것 자체도 시사하는 바가 크다. 오픈소스 생태계에서 Computer Use 에이전트가 활발하게 개발되고 있다는 증거다. 앞서 언급한 Anthropic의 클라우드 기반 사고 공간과 맞물려 보면, 2025년 AI 생태계는 고성능 클라우드 모델과 경량 로컬 에이전트의 양극화가 더 심해질 거라는 걸 알 수 있다. 둘 다 필요하다. 복잡한 추론은 클라우드에서, 빠른 반응은 로컬에서. 게임으로 치면 전용 서버와 클라이언트 사이드 예측의 관계와 비슷하다.
아쉬운 점도 있다. Holo3.1의 구체적인 벤치마크가 부족하다. '빠르다'는 데 얼마나 빠른지, 정확도는 클라우드 모델 대비 얼마나 되는지, 어떤 GPU에서 어느 정도 성능이 나오는지. 이런 걸 직접 테스트해봐야 알 수 있을 거다. 주말에 한 번 돌려봐야겠다.
출처: HuggingFace Blog
오늘의 한 줄: 클라우드에서 사고의 깊이를 파고, 로컬에서 반응의 속도를 쥐어짠다. 2025년 AI는 이 두 축에서 동시에 진화 중이다.