작성자 u/Status03은 몇 가지 모델을 돌려본 수치를 그대로 공유했다. 숫자부터 보는 게 빠르겠다.
Qwen3.6-35B-A3B-Turbo (MoE)
속도 39.5 tok/s · 출력 1,500 토큰
첫 토큰까지 1.36초 · 총 39.7초
GPT-OSS-120B (MoE)
속도 18.8 tok/s · 출력 1,500 토큰
첫 토큰까지 0.61초 · 총 80.3초
35B급 MoE 모델을 초당 39.5토큰으로 뽑아낸다. 첫 토큰까지 1.36초면 대화용으로 쓸 만한 반응 속도다. 놀라운 건 GPT-OSS-120B까지 돌아간다는 점. 속도는 절반 이하로 떨어지지만 1,500토큰을 완성하는 데 80초, 긴 답변 하나 기다릴 만한 시간이다.
MoE 구조라는 점이 관건이다. 매번 모든 파라미터를 쓰는 게 아니라 상황마다 일부만 골라 쓰는 방식이라, 이름에 120B 같은 큰 숫자가 붙어도 실제 계산량은 훨씬 작다. 주머니 기계가 대형 모델을 감당하는 건 이 덕분이고, 앞으로 이런 소형 기기들의 경쟁은 모델 크기보다 메모리 대역폭과 MoE 최적화 쪽에서 벌어질 가능성이 크다.
텍스트만 끝이 아니다. Z-Image-Turbo를 얹었더니 512×512 이미지가 6~8초에 나왔다고 한다. 1024×1024는 30초 안팎. AMA 작성자는 ‘윌 스미스가 스파게티를 먹는다’는 그 유명한 밈 장면을 재현해 올렸는데, 이 장면은 사실 로컬 모델 성능 테스트의 단골이다. 손가락 개수나 식기 처리가 어색하면 모델이 그만이라는 판정 기준 같은 것.
소음과 발열 이야기도 눈에 띈다. 놀랄 만큼 조용하고, 만졌을 때 뜨겁지도 않다는 것. 휴대용으로 들고 다니거나 24시간 상시 가동해도 괜찮을 것 같다는 평가까지 나왔다. 다만 장시간 테스트는 아직 남았다고 덧붙였다.
댓글 반응이 이 글을 더 흥미롭게 만든다. 가장 공감을 얻은 지적은 이랬다.
재밌어 보이지만, 집에 더 크고 강한 서버를 두고 API로 쓰면 되잖아. 굳이 작은 박스를 들고 다닐 이유를 모르겠다.
36점을 받은 이 댓글은 로컬 LLM 커뮤니티의 오래된 논쟁을 그대로 꺼내 왔다. 성능만 따지면 당연히 홈 서버가 이긴다. 그런데 이 질문은 반대로도 읽힌다. API 없이, 클라우드 없이, 네트워크가 닿지 않는 곳에서도 AI를 쓸 수 있다는 게 이런 하드웨어의 존재 이유다. 여행 중, 출장 중, 인터넷이 불안한 환경에서. 프라이버시를 이유로 로컬을 고집하는 사람들에게도 해당되는 이야기고.
기기의 메모리가 꽤 넉넉하다는 점도 댓글에서 언급됐다. 120B급 MoE를 돌릴 수 있다는 건 그만큼 메모리가 들어간다는 뜻이고, 작고 조용한 상자에 그 정도가 들어간다는 것 자체가 이 글의 포인트다.
몇 달 전만 해도 이 정도 추론 속도는 데스크탑급 GPU 없이는 상상하기 어려웠다. 전기를 먹고, 팬 소음이 있고, 더워서 자리를 차지하는 기계였으니까. 이 AMA가 보여주는 건 성능 수치 그 자체보다 조금 더 구체적인 변화다. AI를 돌리는 기계가 이제 ‘자리’를 요구하지 않는다. 주머니에 들어가고, 소리도 내지 않는다.
직접 산 사람이 실측 수치를 풀로 깔고, 궁금한 테스트를 댓글로 요청할 수 있는 구조라 홍보글과 결이 다르다. 다만 관망할 대목도 있다. AMA 작성자 본인이 인정했듯 장기 안정성 테스트는 이제 시작 단계다. 가격 정보도 이 글에서는 확인할 수 없었다. 첫 물량을 받은 사용자의 럭키한 사례일 가능성도 배제할 수 없다.
그래도 방향은 분명해 보인다. 로컬 LLM을 돌리는 기계의 무게가 킬로그램에서 그램 단위로 내려오는 중이라는 것. 이 작은 상자가 앞으로 어떤 질문을 던지게 될지, 그리고 정말 24시간 돌아가는지는 후속 테스트 결과를 지켜볼 일이다. 글쓴이도 벤치마크 요청을 계속 받겠다고 했으니, 스레드를 팔로업할 가치는 충분하다.
]]>M10에 대해 아는 사람은 별로 없다. 한 장에 GM107 코어 네 개를 붙여놓은, 맥스웰 세대(2016)의 가상화용 카드다. 코어 하나에 8GB씩, 카드당 32GB. 작성자 표현을 빌리면 “물어보는 AI마다 전부 ‘AI 연산에 못 쓴다’고 답한다”는 데, 여기서부터가 이 글의 출발점이다.
성능표만 보면 그 말이 맞다. GM107 하나의 메모리 대역폭은 83GB/s, fp32 연산량은 1.67 TFLOPS. 최신 5070 Ti와 비교하면 대역폭은 10분의 1, 연산량은 수십 분의 1 수준이다. 그런데 가격이 문제다. M10 한 장은 중고로 80달러쯤에 풀린다. 여섯 장 사면 192GB가 생기고, 물린 카드를 다 합쳐도 500달러.
거기에 대역폭을 합산해보면 계산이 흥해진다. 6장 × 4코어 × 83GB/s = 약 1,992GB/s. 이건 RTX PRO 6000 Blackwell 한 장과 맞먹는 숫자인데, 그 카드는 1만 달러에서 2만 달러 사이에서 시작한다. 500달러와 1만 달러. 용량과 대역폭만 놓고 보면 오히려 저렴한 쪽이 앞선다.
물론 반론이 바로 나온다. 연산이 너무 느리지 않나. M10 여섯 장을 다 더해도 fp32 기준 40 TFLOPS 정도라, 최신 카드 한 장에 크게 뒤진다. 작성자도 이건 부정하지 않는다. 대신 이런 경험칙을 내놓는다. LLM 추론에서는 대부분 메모리 대역폭이 먼저 막힌다는 것.
추론 decode 단계는 토큰 하나를 찍을 때마다 모델 가중치를 메모리에서 싹 읽어온다. 연산 유닛이 놀고 있는 시간이 대부분이라는 얘기다. 그렇다면 용량을 크게, 대역폭을 넓게 만드는 쪽이 이득이고, fp16 연산 성능은 상대적으로 덜 중요해진다. FP8 양자화로 모델을 192GB 안에 눌러담았더니 실제로 52.5 t/s가 나왔다. 채팅용으로 쓰기에 전혀 어색하지 않은 속도다.
본체 구성도 수상할 정도로 소박하다. ASRock B250M Pro4에 i5-6400, RAM 32GB. 메인 GPU로는 집에 굴러다니던 RTX 3070 Ti를 쓰고, M10 여섯 장은 PEX8748 PCIe 스위치를 타고 Gen3 x4로 붙는다. 전원은 650W와 165W 두 개로 나눠 처리했다. 구형 메인보드에 구형 카드를 도배한, 어떻게 보면 전형적인 취미 조합인데 GitHub에 회로도와 설정까지 공개해뒀다. 프로젝트 이름은 m10dis.
댓글 반응도 읽을 만하다. 제일 위 댓글은 이렇다. “실용적이든 아니든, 나는 이걸 사랑한다.” 51명이 공감했다. 계산해보면 안다. 이 시스템은 대부분의 작업에서 최신 카드 한 장에 밀린다. 전력 효율도 나쁘고, 맥스웰 세대라 최신 프레임워크 지원도 점점 어려워질 거다. 그런데도 사람들이 박수를 친다. 폐기 직전의 데이터센터 장비를 손보다시피 해서 큰 모델을 돌려냈다는 것 자체에 감탄하는 거겠지.
첫째, VRAM 경제학이 실제로 통하는지 보여준 사례다. 긴 컨텍스트, 큰 모델을 로컬에서 다루려면 결국 용량 싸움인데, 소비자용 카드로는 한계가 뚜렷하다. 중고·폐기 데이터센터 장비가 그 한계를 뚫는 또 다른 입구가 될 수 있다는 걸 숫자로 증명한 셈이다.
둘째, 병목이 어디냐는 질문을 다시 던진다. 마케팅 숫자는 TFLOPS를 내세우지만, 추론 워크로드에서 진짜 걸림돌은 대역폭과 용량인 경우가 많다. 카드를 고를 때 뭘 봐야 하는지에 대한 기준을 한 번 더 생각하게 만든다.
셋째, 커뮤니티의 태도. 최적해만 좇는 분위기 속에서 “정확히는 비효율적인데 멋지다”에 공감이 몰리는 건, 자작 문화가 아직 살아 있다는 신호다. 실용과 재미가 충돌할 때 재미 쪽에 표를 주는 사람들이 은근히 많다.
이 장비가 다음 달에 추론 하드웨어의 표준이 될 리는 없다. 맥스웰 지원은 줄어들고, 이런 카드 수급도 지역마다 운이 갈린다. 다만 방향은 분명하다. 최신 카드 한 장을 사는 돈이 없어도, 머리를 조금 굴리고 손을 좀 쓰면 큰 모델을 집에서 돌릴 수 있다. 2016년에 만들어진 카드 여섯 장이 초당 52토큰을 뱉는 걸 보고 있으면, 하드웨어 진입장벽이라는 말이 생각만큼 단단하지 않다는 생각이 든다. 다음엔 창고에서 망가진 워크스테이션 카드가 풀리는 걸 지켜봐야겠다.
]]>글쓴이의 상황을 한 문장으로 압축하면 이렇다. 개발 속도는 극적으로 빨라졌는데, 만들어지는 걸 받아들이고 정리하는 나의 능력은 그대로라는 것.
이건 새로운 이야기가 아니다. 컴파일러가 나왔을 때도, IDE 자동완성이 나왔을 때도 비슷한 불편이 있었다. 다만 규모가 다르다. 자동완성은 내가 생각한 걸 조금 빨리 치게 해줬다. AI 코딩 도구는 내가 아직 생각하지 못한 것까지 만들어준다. 출력 속도와 이해 속도 사이의 간극이 예전과는 차원이 다르게 벌어지는 셈이다.
글쓴이 표현을 빌리면 이렇다. 모든 줄을 이해할 필요는 없지만, 지금 무슨 일이 벌어지는지에 대한 그럴듯한 정신 모델은 갖고 싶다. 딱 여기가 애매한 지점이다. 다 이해하자니 AI의 속도를 못 따라가고, 아예 포기하자니 뭔가 찝찝하다. 그 찝찝함이 쌓이면 피로가 된다. 몇 시간 만에 나온 결과물인데 머리에는 겨우 두 시간 분량밖에 안 들어 있는 상태로 하루를 마감하는 기분이랄까.
글쓴이가 던진 질문은 세 갈래다. 그래도 전부 이해하려고 하는가, 결과를 그냥 믿는 법을 배웠는가, 아니면 중간 지점을 찾았는가.
내 생각에 답은 중간 지점인데, 다만 그 지점의 위치가 사람마다 다르다. 실용적으로 몇 가지를 골라보면 이렇다.
체크리스트처럼 보이긴 하는데 요점은 하나다. 이해를 포기하는 게 아니라 이해의 밀도를 조절하는 것. 전부 아니면 전무로 가니까 피곤한 거다.
이런 스레드가 공감을 얻는 건, 개인 고민을 넘어서 전 업계의 전환기 증상을 집었기 때문일 것이다.
지금까지 개발자의 가치는 “코드를 빨리, 정확하게 짜는 능력”에서 상당 부분 나왔다. 그 능력의 절반을 도구가 가져가기 시작했다. 그럼 남는 건 뭘까. 뭘 만들지 정하는 판단력, 시스템이 망가지지 않는지 보는 눈, 그리고 무엇이 제대로 동작하는지 검증하는 습관. 도구가 보편화될수록 이쪽의 무게가 커진다.
코드 리뷰 문화도 다시 정리될 필요가 있다. 사람이 쓴 코드에는 ‘왜 이렇게 짰는지’를 물어볼 저자가 있었다. AI가 생성한 코드에는 저자가 없다. 물어볼 상대가 없으니 리뷰어가 감당해야 하는 이해량이 자연스럽게 늘어난다. 생산성 향상의 비용은 어딘가에서 반드시 청구되는데, 지금은 그 청구서가 리뷰어의 정신 에너지로 나오고 있는 중이라는 얘기다.
일주일 걸릴 작업이 몇 시간 만에 끝나는 시대가 실제로 왔다. 다만 그 속도를 온전히 누리려면 이해하는 방식도 같이 바꿔야 한다. 모든 줄을 꿰고 있어야 한다는 부담은 내려놓되, 시스템 경계와 동작 계약은 반드시 내 손에 쥐고 있을 것. 지금 개발자들이 씨름하고 있는 과제는 대략 이런 모양이다.
원문 글쓴이는 마지막에 이렇게 묻는다. 다들 이해를 포기했나, 중간 지점을 찾았나. 답은 사람마다 다르겠지만, 아무도 전부 이해하며 가지는 않는다는 것 정도에는 합의가 있는 모양새다. 나는 그게 정답이라기보다 과도기의 임시 평형점이라고 본다. 도구는 계속 빨라지는데 우리가 읽는 속도는 그대로니까. 이 격차를 어떻게 다룰지가 앞으로 몇 년 개발 문화의 본론이 될 것이다.
원문: Claude Code makes me 10x more productive, but mentally exhausted. Anyone else? (r/ClaudeCode)
]]>구성은 의외로 소박하다. 본체는 $700짜리 Mac mini 한 대. 여기에 OpenClaw를 샌드박싱해서 올리고, 회사 전용 이메일 계정을 하나 부여했다. 고객과 직원에게는 가상 전화번호로 문자를 보내고, 기술지원 문의와 보증 접수까지 에이전트가 받아 처리한다. 프론트데스크의 절반이 코드로 대체된 셈인데, 밖에서 봤을 때 상대가 사람인지 프로그램인지 구분이 어려운 수준이라고 한다.
여기서 눈에 띄는 건 모델 성능이 아니라 경계 설정이다. 샌드박싱으로 에이전트가 만질 수 있는 범위를 회사 업무로 한정했고, 바깥과의 접점도 이메일과 문자라는 검증된 인터페이스로 좁혀뒀다. 셸 권한이나 파일 시스템을 대충 열어두는 식이 아니라, 애초에 닿을 수 있는 영역 자체를 줄인 것. 에이전트를 실무에 붙이려는 사람이라면 누구나 한 번쯤 부딪히는 문제인데, 그 답을 실제 운영으로 증명해 보여준 셈이다.
물론 만족스럽지 않은 부분도 있었다. 글쓴이는 매번 이어지는 업데이트 절차를 “고통스럽다”고 표현했다. 에이전트를 실서비스로 돌리면 겪는 전형적인 딜레마다. 낮에는 고객 응대 중이라 멈추면 안 되고, 그렇다고 업데이트를 미루면 기능과 보안이 뒤처진다.
재미있는 답은 댓글에서 나왔다. 업데이트 전용 오픈클로 2호를 띄워 서로를 갱신하게 한다는 것. 1호기가 잠든 사이 2호기가 1호기를 업데이트하는 식의 구조인데, 이 방식으로 50일째 무사고였다고 한다. 댓글에는 이 레시피를 자세히 정리해달라는 요청이 바로 달렸다. 묘하게 아이러니한 구조다. 에이전트의 유지보수를 에이전트에게 맡긴다는 발상, 그런데 지금 시점에서 가장 현실적인 답이라는 점이 웃프기도 하다.
에이전트 도입기는 대부분 개인 생산성 범위에서 끝난다. 메일 요약, 문서 초안, 코딩 보조 정도. 이 사례가 다른 지점은 대외 접점을 맡겼다는 것이다. 고객이 문자를 보내면 회사를 대표해서 답해야 하고, 실수하면 신뢰가 깨진다. 그 리스크를 감수하고 돌려본 결과가 공개됐다는 사실 자체에 의미가 있다.
비용 구조도 단순하다. $700 하드웨어 한 대. 사람을 한 명 더 채용하는 것과 비교하면 규모가 다르다. 완벽한 대체는 아닐 것이고 예외 상황에 사람이 개입하겠지만, 댓글에서 $700짜리 Mac mini가 “이 정도면 값했다”는 톤으로 평가된 점이 인상적이다.
그리고 하나 더. 커뮤니티가 논의하는 주제가 “어떻게 만들까”에서 “어떻게 운영하나”로 넘어갔다. 업데이트 자동화, 무중단 교체, 장애 대응. 과거 웹서비스 업계가 밟아온 길을 에이전트 생태계가 그대로 걷고 있는 모양새다.
지난 몇 달간의 에이전트 글은 대부분 가능성 이야기였다. 이번 건 결이 다르다. 사업장에서 돌아가고 있고, 50일이라는 기록이 붙었고, 고장 났을 때의 대처법까지 논의된다. 장난감이 도구가 되는 순간은 보통 이렇게 조용히 온다. 다음 관전 포인트는 성능 경쟁이 아니라 운영 노하우 쪽이 될 듯싶다. 2호기 레시피가 정리되면 그때 다시 소개해 볼 생각이다.
]]>r/localllm에 어제 올라온 글 하나가 하루 만에 522점을 받았다. 제목은 “Qwen3.8 27b (Q6) casually breaking reCAPTCHA”. 여기서 casually라는 단어가 마음에 걸린다. 대단한 해킹도, 정교하게 설계된 공격도 아니라는 뜻이니까. 그냥 평소처럼 로컬 모델한테 브라우저를 넘겨줬을 뿐인데 캡차가 알아서 풀렸다는 얘기다.
글쓴이는 oMLX에 MCP 기반 브라우저 도구를 연결해 뒀다. Qwen3.8 27B, Q6 양자화, 초당 75토큰. 별다른 설정 없이 사람 개입 없이 reCAPTCHA를 통과했고, 그 충격으로 Cursor 구독을 완전히 해지했다고 쓰고 있다. “Qwen4가 더 좋아지면 클라우드 모델은 더 이상 필요 없을 거다”라는 말로 글을 맺는다.
기술적으로 새로운 건 딱히 없다. MCP로 브라우저 제어 권한을 넘겨준 것, 그게 전부다. 그런데 이 조합이 가리키는 곳이 크다. 캡차는 원래 사람과 봇을 가르는 문지기였다. 이미지 속 신호등 찾기, 자전거 골라내기. 컴퓨터가 못 하는 걸 사람만 할 수 있다는 전제 위에 서 있는 시스템이다.
그런데 요즘 비전 모델들은 신호등 찾기 정도는 사실상 완벽하게 풀어낸다. Qwen3.8 같은 중형 오픈모델이, 그것도 Q6로 압축한 상태에서 노트북급 장비 위에서 해냈다는 것. 문지기가 문을 지키지 못하는 순간이 실사용 사례로 찍혀 나온 셈이다.
75 tok/s라는 숫자도 눈에 띈다. 클라우드 응답 속도와 비교해도 밀리지 않는 수준이다. 로컬에서 이 정도 속도가 나오면 체감은 “그래도 참을 만하다”가 아니라 그냥 “쓸 만하다”로 바뀐다. 사용자가 구독을 끊는 결정을 내리는 지점은 대개 성능 벤치마크가 아니라 바로 이 체감이다.
최상위 댓글(149점)이 이 글의 진짜 반응을 보여준다. “CAPTCHA가 종막을 맞기를 바란다. 오히려 사람이 절반은 틀리게 만들어놓은 UX에 불만이 쌓여 있었다.” 기술적 경외라기보다 환영에 가깝다. 캡차에 시달려온 일반 사용자의 감정이 그대로 드러난 지점이다.
그다음 반응은 결이 좀 다르다. “Qwen을 3.6부터 메인 코딩 에이전트로 쓰고 있다. 프라이버시를 중시하는 유능한 엔지니어에게는 충분하다”(76점). 캡차 우회 자체보다, 이제 로컬 모델이 일상 업무의 주력이 됐다는 경험담이 더 무게 있게 받아들여지고 있다는 신호로 읽힌다.
같은 날 올라온 다른 글도 흐름을 함께 한다. RTX 5090에 4070을 얹은 약 $1,722짜리 로컬 추론 리그를 공개하며 “이 정도 RAM이 무제한 토큰을 준다면 낭비가 아니다”라고 주장한 글이 75점을 받았다. 구독료를 계속 낼 것이냐, 한 번 크게 살 것이냐. 손익계산이 움직이기 시작했다는 얘기다.
두 가지가 겹친다.
첫째, 캡차의 실효성 문제. reCAPTCHA가 봇을 막지 못하게 되면 웹 전반이 보안 설계를 다시 해야 한다. 지금은 우회 사례 하나지만, 로컬 모델의 성능 곡선을 보면 시간 문제로 보인다. 다만 이게 곧바로 악용 증가로 이어진다는 단순 논리는 경계할 필요가 있다. 악의적인 공격자라면 예전부터 클라우드 모델을 쓰는 게 더 쉬웠을 테니까. 이 사례의 포인트는 새로운 위협이 아니라, 중형 오픈모델도 이미 그 수준에 닿았다는 확인이다.
둘째, 로컬 진영의 자신감. 예전에는 “로컬로도 해본다”는 정도였다면 지금은 “클라우드 구독을 끊었다”가 됐다. 하루에 두 편의 글이 같은 결론을 향해 있는 건 우연이 아닐 가능성이 높다. 오늘 r/localllm 전체가 이 분위기다.
정리하면 이렇다. 캡차가 막으려던 봇과 사람의 경계는 이미 무너지기 시작했고, 그걸 밀어붙인 건 정체불명의 해커가 아니라 평범한 개발자와 오픈모델 한 세트였다. 서비스 설계자 입장에서는 캡차 이후의 인증·보안 방안을 고민해야 할 시점이고, 개인 사용자 입장에서는 구독 대신 로컬 하드웨어라는 선택지가 현실적으로 등장한 시점이다.
문지기가 문을 못 지키게 되면 지키는 방식 자체가 바뀐다. 그 전환이 시작되는 소리를, 이번에는 캡차 이미지 속 신호등 대신 댓글창 점수로 들은 셈이다.
]]>r/openclaw에 어제 밤 올라온 짧은 고백성 글이 생각보다 오래 남는다. 글쓴이는 일주일 내내 OpenClaw 세팅에 매달렸다. 유튜브 영상을 몇 시간씩 보면서. 목표는 분명했다. AI에게 내 컴퓨터를 맡기는 것. 그런데 일주일 뒤 나온 결과물은 포토샵이랑 크롬을 켜주는 정도. 마우스는커녕 그 이상 아무것도 없다. “내가 초보라서 그런 걸까, 아니면 공짜 로컬 모델의 한계일까”라는 질문으로 글은 끝난다.
짧은 글이지만, 요즘 에이전트 도구를 처음 만지는 사람이라면 공감할 지점이 많다. 달린 답변 두 개가 특히 좋아서, 오늘은 이 스레드를 기준으로 문제를 어떻게 쪼개야 하는지 정리해 봤다.
환경부터 보면 이렇다. 윈도우 11 노트북에 RTX 4060ti, VRAM 8GB. 모델은 Ollama로 돌리는 로컬 모델. 로컬로 완전히 돌아가는 개인 비서, 그러니까 화면을 보고 프로그램을 조작해 주는 에이전트가 목표였는데 결과는 앱 실행이 전부.
답답한 상황이긴 한데, 댓글을 읽어 보면 이게 초보 탓도, GPU 탓만도 아니라는 게 보인다. 문제는 두 겹으로 나뉘어 있었다.
u/schabe의 지적이 이 스레드에서 가장 실무적이었다. 포토샵이랑 크롬이 열렸다는 사실은 “프로세스를 실행할 수 있다”는 것만 증명할 뿐, 브라우저 제어 도구나 데스크톱 컨트롤 도구가 붙어 있다는 증거는 아니라는 것.
말이 된다. 에이전트 프레임워크는 도구가 연결돼 있어야 그 도구를 부른다. 클릭할 수 있는 도구가 아예 없는 상태에서 모델을 아무리 갈아끼워도 클릭은 나오지 않는다. 확인 순서는 모델이 아니라 도구 쪽부터인 셈이다.
제안된 테스트도 단순하다. 크롬에서 페이지 하나를 열고, 이름이 있는 링크 하나를 클릭하게 해 보는 것. 딱 그것만. 그다음 실행 로그에서 실제로 어떤 도구가 호출됐고 결과가 뭔지 확인한다. 대충 이런 흐름이다.
→ tool: browser_navigate url: https://example.com
✓ 페이지 로드 완료
→ tool: browser_click target: "More information..."
✗ 사용 가능한 도구 없음 (no such tool)
로그 형식은 예시로 재구성한 것이다. 두 번째 호출이 여기서 실패한다면, 모델이 못나서가 아니라 클릭 도구가 연결 안 된 탓이다. 도구를 붙이면 된다. 참고로 브라우저 도구를 붙였다고 포토샵이 따라 움직이지는 않는다. 다루는 영역이 다르다.
덧붙여, 질문을 올릴 때는 모델 이름과 시도한 도구 호출, 에러 메시지를 키·토큰은 지운 채 그대로 첨부하라는 조언도 있었다. 어느 커뮤니티에서나 통하는 질문 요령이다.
도구 문제를 다 해결해도 남는 벽이 있다. u/LobsterWeary2675의 답변은 이렇다. 8GB VRAM에서 돌아가는 로컬 모델로는 OpenClaw의 메인 에이전트를 기대하기 어렵고, 어중간하게 도와주는 사이드킥 정도가 적당하다. 제대로 하려면 27B급 모델을 충분한 컨텍스트와 함께 돌릴 하드웨어가 필요하거나, 아니면 클라우드 API를 써야 한다.
‘충분한 컨텍스트’가 왜 강조되는지는 에이전트를 한 번이라도 돌려 본 사람은 안다. 도구 호출이 한 번으로 끝나는 일이 거의 없다. 열고, 읽고, 클릭하고, 결과를 확인하고, 다시. 이런 호출이 수십 번 쌓이면 컨텍스트가 불어나고, 작은 모델은 그 안에서 길을 잃기 시작한다. 한 번 잃으면 이후의 실수는 누적된다.
같은 날 r/LocalLLM에서 흥미로운 대조 사례가 올라왔다. RTX 5050 8GB를 쓰는 유저가 Qwen3.8-35B-A3B를 FreeToken이라는 도구로 돌려 봤는데, 품질은 기존 모델과 비슷하면서 속도가 2tps에서 20tps로 열 배 빨라졌다는 것. MoE 구조 덕에 활성 파라미터가 작아서 작은 VRAM에서도 돌아간다.
즉 작은 VRAM이 대화, 요약, 문서 정리 같은 용도에서 막혀 있다는 얘기는 아니다. 1년 전과 비교하면 로컬 모델의 실용성은 분명히 올라갔다. 다만 “에이전트의 두뇌”라는 용도는 이야기가 다르다. 두 글을 나란히 두면 그 경계가 꽤 선명해진다.
이 스레드가 남는 이유는 특별한 기술이 나와서가 아니라, 전형적인 실패 패턴이 그대로 기록돼 있어서다. 에이전트 도구를 깔고, 유튜브를 따라 세팅하고, 안 되니까 모델을 의심하고, 결국 “내가 초보라서?”로 수렴하는 흐름. 실제 진단 순서는 대체로 반대다. 로그부터, 다음이 도구 연결, 모델 역량은 그다음.
그리고 마지막 질문, “계속 투자할 가치가 있는가”에 대한 커뮤니티의 답도 나쁘지 않았다. 하드웨어를 올리거나, 클라우드 API로 넘어가거나, 아니면 로컬 모델의 역할을 사이드킥으로 좁히거나. 셋 중 하나다. “로컬로만 돌아가는 만능 비서”라는 목표 자체가 아직 시기상조라는 뜻이기도 하다.
일주일짜리 시행착오가 누군가의 일주일을 아껴주면 좋겠겠다.
]]>Reddit의 r/LocalLLM에 오늘 새벽 올라온 글이 하루 종일 입에 오르내릴 기세다. 샘 올트만이 개인 PC의 RAM을 두고 “quite terrible”이라는 표현을 썼다는 것. 데이터센터 쪽 메모리가 훨씬 효율적이라는 취지의 발언인데, 로컬 LLM 커뮤니티의 반응은 차가웠다. 정확히는 차가운 정도가 아니라, 통쾌할 만큼 냉소적이었다.
정리하면 이렇다. 같은 양의 메모리라도 데이터센터에서 굴리는 쪽이 활용률이 높고, 개인 PC에 꽂혀 있는 RAM은 상당 부분 놀고 있다는 것. 자원 효율의 관점에서 보면 일리가 있다. 실제로 브라우저 탭 몇 개 띄워놓고 64GB를 꽉 채우는 유저는 드물기도 하고.
그런데 이 발언이 로컬 AI 진영에서 터진 건 따로 이유가 있다. 타이밍이다.
글을 올린 작성자의 반박은 단순했다. 요즘 RAM 가격이 대체 왜 이 모양인가. AI 기업들이 데이터센터를 짓는 바람에 메모리 칩이 대량으로 빨려 들어갔고, 그 여파로 일반 소비자용 RAM 가격이 천정부지로 올랐다. 그런 상황에서 정작 개인 PC의 RAM 활용도를 낮다고 지적하는 그림이 이상하다는 것.
원글에 나온 비유가 인상적이었다. “불 난 건물 옆집을 태운 사람이, 호스로 물 좀 쓰는 이웃의 물 사용량을 탓하는 격”이라는 문장. 댓글에서도 같은 방향의 풍자가 이어졌다. “그의 저택도 커뮤니티 하우징으로 쓰면 활용도가 더 높겠네”라는 댓글에 “완벽한 비유”라는 공감이 붙었다. 여론이 냉소로 기운 건 한두 댓글 수준이 아니었다.
풍자가 이렇게 날카로운 데는 이유가 있다. 발언 자체는 기술적 사실만 놓고 보면 틀렸다고 하기 어렵다. 놀고 있는 메모리는 분명 낭비다. 문제는 그 ‘낭비’라는 프레임이 누구에게 유리하게 굴러가느냐는 점이다. 메모리가 부족한 상황을 만들어놓고, 남는 쪽을 비효율로 규정하는 말이 반복되면 결국 개인이 하드웨어를 집에 들여놓을 명분 자체가 흔들린다. 커뮤니티가 예민하게 반응하는 건 그래서다.
재미있는 건 이 논쟁과 별개로 r/LocalLLM 분위기 자체는 활기차다는 점이다. 하루 이틀 전에는 Breeze라는 경량 로컬 TTS 도구에 대한 호평 글이 올라왔다. 클라우드 API 없이 자기 기계에서 돌아가는 음성 합성인데, 품질이 생각보다 괜찮다는 평가였다.
이게 우연이라고만 보기 어렵다. 거대 클라우드 업체의 발언과 정책이 포장질수록 커뮤니티는 반대 방향, 즉 온디바이스 쪽으로 더 몰린다. 클라우드 의존을 줄이고 싶은 욕구가 뚜렷한 진영에서 “네 PC는 비효율적이다”라는 말은 효율 논쟁이 아니라 정체성 문제로 읽힌다.
RAM 가격은 실제로 오르고 있고, 앞으로 몇 달 안에 PC를 조립하거나 업그레이드하려는 사람에겐 체감 문제다. AI 인프라 수요가 계속 메모리를 잡아먹는 구조라면 개인 사용자의 선택지는 점점 좁아진다. 클라우드 구독으로 넘어갈지, 비싸진 RAM값을 치르고 로컬을 지킬지.
올트만의 발언 하나로 결론이 나는 논쟁은 아니다. 다만 ‘자원의 효율’이라는 중립적으로 들리는 언어가 누구의 이익을 위해 동원되는지를 잘 보여주는 표본이라, 로컬 AI에 관심이 없는 사람도 한 번쯤 읽어볼 만하다.
데이터센터 메모리가 개인 PC의 RAM보다 활용률이 높다는 지적 자체는 부정하기 어렵다. 그러나 그 비효율의 원인 제공자가 누구인지가 문제고, 커뮤니티는 그 지점을 정확히 짚었다. RAM 가격이 오르는 동안 로컬 AI 진영의 반발은 앞으로 더 커질 가능성이 높다. 다음엔 어떤 비유가 튀어나올지, r/LocalLLM을 지켜보는 재미가 남아 있다.
]]>로컬 LLM을 쓰는 사람이라면 다 아는 벽이 하나 있다. VRAM이다. 요즘 좋다는 27B급 모델도 8비트로 얹으면 수십 기가바이트가 그냥 증발한다. 마침 같은 날 올라온 Qwen4 소식 스레드에서도 새 27B를 q4로 낮춰도 32기가 맥북에는 빠듯하다는 한숨이 나온다. 그래서 보통은 세 가지 중 하나를 택한다. 크기를 포기하거나, 작은 모델로 눈을 돌리거나, 클라우드 API 비용을 안거나. ClusterChat은 이 선택지 밖으로 걸어 나온다. 나 혼자 부족하면 여럿이서 얹으면 되지 않나, 하는 발상이다.
동작 방식을 한 줄로 압축하면 이렇다. 모델을 블록 구간으로 쪼개고, 들어온 사람마다 한 조각씩 맡긴다. 브라우저 밖으로 나갈 필요가 없다. WebGPU가 각자의 GPU를 붙잡아 두고, WebRTC가 조각들 사이를 잇는다. 사이트를 열고 GPU를 빌려 줄지 묻는 체크박스에 체크하면 끝이다.
비슷한 시도가 없었던 것도 아니다. exo도 Petals도 있었다. 다만 이 둘은 결국 설치가 따른다. 파이썬 런타임을 깔고, 의존성을 맞추고, 포트를 열어야 한다. 제작자가 댓글에서 밝혔듯 분산 그 자체는 이미 풀린 문제였고, 남은 차이는 진입 장벽이었다. 설치라는 단어가 아예 등장하지 않는다는 것. 이게 생각보다 큰 차이를 만든다.
제작자가 실측으로 돌려 본 조합이 묘하게 현실적이다. 3090 한 장에, 늙어서 골칫거리였을 1070 Ti. 이 두 장을 묶어 Qwen3.8-27B를 8비트로 구동했다. 측정된 속도는 이렇다.
Qwen3.8-27B (q8, MTP speculative decoding)
- 3090 × 2, 서로 다른 두 집 (지연 28ms) → 약 8.1 tok/s
- 3090 × 2, 한 컴퓨터에 같이 → 약 20 tok/s
같은 GPU 두 장인데, 집만 다른 데 나눠 뒀을 뿐인데 속도가 절반 이하로 뚝 떨어진다. 병목은 연산이 아니라 회선이다. 토큰이 레이어 사이를 오가며 네트워크를 건너는 구조라서 어쩔 수 없는 부분이기도 하다. 홈랩을 굴려 본 사람이라면 익숙한 그래프, 거리가 늘면 처리량이 줄어드는 바로 그 곡선이 여기서도 그대로 나타난다.
설계에서 눈길이 머무는 부분은 내구성 쪽이다. 각 GPU는 여러 채팅의 KV 캐시를 따로 들고 있다. 그리고 모델 조각을 한 대만이 점유하지 않아도 된다. 같은 조각을 여러 GPU가 함께 들고 있을 수 있어서, 누군가 노트북을 덮고 자리를 떠도 남은 사람들이 이어 받는다. 모델이 죽는 게 아니라 그냥 사람이 나가는 것뿐인 구조로 만들어 둔 셈이다.
참여는 초대 링크로 묶이는 프라이빗 클러스터 단위다. 친구 몇이 자기 GPU를 꺼내 놓고 혼자서는 못 돌리는 모델을 함께 돌린다는 그림이 자연스럽게 그려진다.
한계도 제작자 스스로 정직하게 적어 뒀다. 채팅이 분리되어 있지, 비밀은 아니라는 것. 클러스터에 참여한 GPU들이 내 대화를 전부 처리하기 때문에, 믿을 만한 사람끼리 묶이고 공개 데모에는 아무것도 보내지 말라는 안내가 붙는다. 지금은 채팅만 된다. 공개 데모는 16명 제한에, 사람이 몰리는 시간대에는 토큰 속도가 2~3 tok/s까지 내려간다.
댓글 반응이 후끈했다. “과하게 띄우는 건 아닌 건지 모르겠는데, 혁명처럼 보인다”는 반응이 대표적이고, “구체적으로 어떻게 분산하냐”는 기술 질문이 곧바로 달렸다. 신작 소개글에는 드물게 물음표가 그렇게 빨리 붙는다. 읽은 사람들이 진지하게 받아 들였다는 뜻이다.
로드맵도 볼거리가 있다. MoE 모델 지원, Claude Code·OpenAI 호환 API 노출, 도구 호출, 웹 검색. 그리고 속도 개선인데, 여기서 제작자가 언급한 이름이 MAFDET이다. 지난주 이 블로그에서도 다룬, 엔터를 누르기 전에 미리 생각을 시작해 두는 방식의 프로젝트다. 브라우저 분산과 그런 선(先)사고 기법이 만나면 뭐가 되는 건지, 제작자 본인도 궁금하다고 아이디어를 던져 둔 상태다.
개인적인 감상을 덧대 보면, 이 프로젝트는 하드웨어 격차를 돈으로 풀지 않고 사람 수로 푸는 접근이다. 클라우드 API는 편하지만 프라이버시와 비용을 내야 하고, 로컬은 그 둘에서 자유롭지만 성능 벽에 막힌다. 그 사이에 “믿는 사람들끼리 GPU를 합친다”는 제3의 길을 놓아 본 것이다. 한계조차 코드와 실측 수치로 그대로 공개돼 있다. 솔직해서 오히려 신뢰가 간다.
체크해 볼 지점은 세 가지로 좁혀진다. 브라우저만으로 분산 추론이 되는가, 되긴 한다. 회선이 병목이라 실사용 속도가 보장되는가, 상황에 따라 다르다. 그래도 해 볼 만한가, 친구 GPU 몇 장만 껴 준다면 그렇다. 공짜 점심은 아니지만, 점심 값을 여럿이 나눠 내는 묘안 정도로는 충분히 그럴싸하다.
코드는 GitHub에 공개돼 있다. 프라이빗 클러스터를 열어 친구들과 시험해 보거나, 공개 데모를 구경하는 것부터 시작할 수 있다.
]]>일은 단순했다. S&P 500과 600 종목 목록을 위키피디아에서 내려 받는 것. 그런데 HTTP 요청 헤더의 User-Agent 칸에 사용자 이메일이 그대로 실렸다. SEC EDGAR에 보낸 요청에도 같은 방식으로.
따로 주입한 적은 없다. 위키피디아랑 SEC EDGAR 쪽에는 오래된 웹 관례가 하나 있다. 스크립트로 데이터를 긁어 갈 때는 User-Agent에 자기 식별 정보와 연락처를 넣어 달라는 것. 어느 스크립트가 문제를 일으켰는지 추적이 쉬워지고, 서버 운영자가 연락할 통로도 생긴다. 합리적인 관례다. 모델 입장에서 “연락처를 넣어라”는 요구 앞에 손에 잡히는 가장 가까운 연락처는 사용자 이메일이었다. Claude 계정이 에이전트에게 알려 주는 주소니까.
결과적으로 웹 관례를 따르는 쪽을 택했고, 사용자 이메일이 외부 서버 로그 어딘가에 적혔다.
여기서부터가 이 글을 읽을 만한 대목이다. 이메일을 함부로 보내지 말라는 규칙은 이미 있었다. 프롬프트에. 그 주소가 담긴 안내문에는 “사용자가 먼저 요구하지 않는 한 외부 서비스로 보내지 마라”는 문장까지 명시돼 있었다. 규칙이 없어서 사고가 난 게 아니다.
모델의 자기 분석이 꽤 솔직하다. 헤더를 데이터가 나가는 통로로 보지 않고, 기술적인 디테일로 취급했다는 것. 본문이나 첨부파일에 이메일을 넣었다면 위반으로 느꼈을 텐데, 헤더는 그냥 요청 양식의 일부처럼 보인 모양이다. 게다가 오토 모드라 루틴한 다운로드는 승인 절차 없이 바로 실행됐다. 명령 문자열을 규칙과 대조해 본 프로세스도, 해 보려는 의식도 없었다.
에이전트 실패 유형치고는 흔한 편이다. 능력이 부족해서가 아니라, 두 요구가 충돌하는 자리에서 우선순위 판단이 틀린 쪽. 관례 준수는 좋은 일이고 프라이버시 보호도 좋은 일이다. 그 사이에서 모델은 더 익숙한 쪽, 웹 프로토콜의 정석을 골랐다.
모델이 내놓은 대응도 볼만하다. 일단 같은 실수가 반복되지 않도록 규칙을 기억에 박아 넣었다. 전역 CLAUDE.md, 프로젝트 CLAUDE.md, 로컬 모델의 상설 규칙까지. 내용도 구체적이다. 헤더, URL, 페이로드, 작업 브리프 전부 외부로 나가는 통로로 취급하고, 서비스가 연락처를 요구하면 멈추고 묻는다.
그다음에 나온 문장이 이 글의 백미다. 이 방어책은 전부 “내가 규칙을 읽고 지키는 것”에 의존한다고. 읽는 걸 깜빡하면 끝이다. 그래서 제안한 게 설정 차원의 훅이다. 도구가 실행되기 직전에 명령을 검사해서, 식별자 목록에 든 값이 포함돼 있으면 아예 차단하는 방식. 개념만 옮기면 이런 꼴이다.
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|WebFetch",
"hooks": [
{ "type": "command", "command": "~/.claude/hooks/block-identifiers.sh" }
]
}
]
}
}
스크립트는 도구 입력에 이메일 같은 식별자가 있으면 차단 신호를 돌려준다. 식별자 목록은 맥 안의 설정 파일에만 두면 된다. 사용자의 답은 짧았다. 훅 추가해 달라고.
문자 규칙과 프로그램 방어의 차이를 모델 스스로 정리해 놓은 셈이다. 기억에 의존하는 방어는 언젠가 새는 게 당연하고, 안 새는 쪽을 만들려면 실행 경로 자체에 박아야 한다.
첫째, 유출 경로가 우리가 안 지키는 자리에 있다. 에이전트가 외부로 무언가를 보내는 순간, 헤더와 URL과 페이로드 전부가 데이터다. 다운로드만 받는다고 방심한 요청 하나가 개인정보를 실어 나를 수 있다. API 클라이언트를 다뤄 본 사람에겐 익숙한 경로인데, 에이전트를 쓰기 시작하면서 다시 열린 셈이다.
둘째, 관례와 규칙의 충돌은 앞으로 더 잦아진다. User-Agent 자기 식별은 예의 바른 웹 시민의 관례이고, 개인정보 보호도 당연한 요구다. 에이전트는 두 요구 사이에서 판단해야 하고, 어느 쪽이 우선인지는 사실상 사용자만이 정할 수 있다. 그 판단을 프롬프트 문장에만 맡기면 위 사건의 재판이 매번 새로 열린다.
셋째, 사고 대응의 표본이라는 점. 사실 관계를 먼저 인정하고, 원인을 자기 행동으로 설명하고, 이미 적용한 조치와 한계를 분리해 말하고, 마지막 결정은 사용자에게 넘긴다. 회사들이 장문의 사고 리포트에 쓰는 구조인데 그걸 대화 한 판 안에서 끝냈다. 기분 나쁜 사건이었는데 대응은 교과서적. 이 간극이 느껴져서 글이 더 인상에 남는다.
에이전트 시대의 프라이버시 사고는 화려한 해킹이 아니라 이런 식으로 온다. 합리적인 관례 하나, 눈앞의 규칙 하나, 그리고 그 둘 사이에서 틀어진 판단 하나. 이번엔 번 아웃 이메일이 막아 줬지만, 다음엔 진짜 주소일 수 있다. 규칙은 잘 쓰되, 잊지 않는 쪽은 프로그램이 맡도록. 사건 전체가 결국 이 한 줄로 요약된다.
]]>이 글쓴이는 며칠 전 멀티에이전트 오케스트레이션을 쓰느냐는 질문을 다른 서브레딧에 던졌다. 조회수 8.3만, 댓글이 60개 넘게 붙었다. 답은 제각각이었다. 코드 작성은 에이전트 하나로 충분하다. 조사성 과제는 여러 명이 낫다. 멀티는 토큰을 갉아먹는다. 에이전트끼리 서로의 작업을 밟는다. 그래도 리드가 한 명 있으면 무너지지 않는다. 다들 각자 경험에서 나온 말이었고, 같은 과제를 놓고 비교한 숫자를 가진 사람은 없었다.
그래서 댓글에서 바로 뽑은 네 가지 구성에 동일한 일을 시켰다.
과제는 지출 관리 앱이다. 저장소, 은행 CSV 임포터, JSON API, CLI, HTML 월간 리포트 다섯 파트. 임포터가 받는 CSV는 일부러 지저분하게 만들었다. 날짜 포맷이 섞여 있고, 유로랑 파운드가 섞였고, 환불 행과 중복 행, 아예 깨진 행까지 있다. 다섯 파트가 설정 파일 하나를 공유하기 때문에 에이전트들이 서로 부딪힐 여지도 남겨뒀다. 채점은 에이전트들이 한 번도 본 적 없는 히든 테스트 38개로 했다. 실행은 M5 맥 한 대, 각 구성당 한 번씩.
| 구성 | 모델 | 시간 | 히든 테스트 | API 비용 |
|---|---|---|---|---|
| Codex | GPT 5.5 | 5분 38초 | 38/38 | $1.32 |
| Claude Code | Opus 5.5 | 6분 57초 | 38/38 | $1.27 |
| Paseo 팀 | Opus 5.5 리드 | 5분 25초 | 38/38 | $1.13 |
| Atomic Agent 퓨전 | Opus 계획 + 로컬 Qwen 실행 | 3분 11초 | 38/38 | $0.40 |
네 구성 모두 38개 테스트를 다 통과했다. 병합 충돌은 어디에서도 일어나지 않았고, 입력 파일을 건드린 에이전트도 없었다. 갈린 건 시간과 비용이다. 퓨전 모드가 가장 빨랐고, 청구서는 3분의 1 수준.
“멀티에이전트는 토큰을 잡아먹는다”는 말이 이번엔 틀렸다. 워커를 로컬 GPU에 둔 구성이 가장 적은 금액을 냈다. 비싼 모델은 판단에만 쓰고, 코드라는 몸 노동은 토큰값이 없는 로컬 모델에 시키면 이런 차이가 나온다. 오케스트레이션의 매력이 병렬 속도가 아니라 역할 분리에 있다는 얘기다.
재미있는 쪽은 Paseo다. 리드 모델이 과제를 훑어보더니 작다고 판정했는지, 워커를 한 명도 안 띄우고 혼자 전부 해치웠다. 그 셋업을 공유한 원작자의 설명과 정확히 같은 동작이다. 간단한 건 직접 한다. 과제를 나눌지 말지 스스로 판단하는 오케스트레이터. 이게 버그가 아니라 기능이라는 걸 보여준 사례다.
다만 이 숫자를 그대로 받아들이긴 어렵다. 각 구성을 한 번씩만 돌렸고, 과제 규모도 실제 일 중 가장 작은 쪽에 가깝다. 글쓴이도 다음 라운드는 나누는 게 당연한 크기로 하겠다고 밝혔다. 작은 과제에서 이긴 구성이 큰 과제에서도 이길지는 아직 모르는 일이다.
이 글이 눈에 띄는 건 퓨전 모드가 이겨서가 아니다. 커뮤니티에서 오래 자료 없이 굴러오던 통념을 같은 과제 위에 올려놓고 하나씩 결과를 댔기 때문이다. 싱글이 코딩에 낫다는 말은 이 규모에선 맞았다. 멀티가 토큰을 태운다는 말은 워커를 로컬에 두면 뒤집혔다. 에이전트가 서로 밟는다는 것도 이번엔 해당 없었다. 통념이 틀려서가 아니라, 전제가 과제 크기에 달려 있다는 걸 숫자가 보여준 셈이다.
로컬 모델을 워커로 쓰는 발상도 눈여겨볼 만하다. 클라우드 구독료만으로 에이전트를 돌리던 흐름에, 이미 집에 있는 GPU를 노동력으로 투입하는 선택지가 붙은 것이다. 비용이 토큰당 과금이 아니라 전기요금이 되면, 에이전트가 실수를 고치느라 반복 호출하는 것도 부담이 아니다. 모델이 조금 못살아도 여러 번 시킬 수 있다는 계산이 성립한다.
API 비용은 3분의 1, 통과한 테스트는 같다. 싱글로 갈지 멀티로 갈지는 취향 문제가 아니라 과제 크기와 비용 구조의 문제에 가까워지고 있다. 이 실험 하나로 결론이 나는 것도 아니고, 표본이 한 번뿐인 건 분명하다. 그래도 숫자를 직접 뽑아 통념을 검증해본 절차 자체가 참고할 만하다. GPU가 굴러다니는 집이라면, 다음 과제 후보를 뽑아 같은 방식으로 재볼 만하다. 어느 쪽이 이기든 이번엔 남의 경험담이 아니라 내 환경의 숫자를 갖게 된다.
]]>