HN이 이 글을 붙잡은 이유

Hacker News는 이 글을 "비행기에서 AI로 코딩했다"는 자랑으로 읽지 않았다. 인터넷이 사라졌을 때 로컬 추론이 실제로 어디까지 버티는지를 숫자로 보여준 현장 보고서로 읽었다. 원문에서 Dmitri Lerko는 128GB unified memory와 40코어 GPU를 갖춘 M5 Max MacBook Pro에 Gemma 4 31B와 Qwen 4.6 36B를 LM Studio로 올리고, 런던에서 라스베이거스로 가는 10시간 비행 동안 DuckDB 기반의 클라우드 비용 분석 도구를 만들었다고 적었다. 작은 리팩터링, CLI 골격 작업, 문서화까지 합치면 약 4M 토큰도 처리했다고 한다.

여기까지는 "생각보다 된다"는 이야기다. HN이 더 오래 본 건 그다음이다. 실제 업무가 데모를 넘어가면 무엇이 먼저 무너지는가.

글의 무게를 만든 숫자

원문은 구체적이다. 지속 부하에서 배터리는 분당 약 1%씩 줄었고, 잘못 고른 케이블 때문에 좌석 전원에 꽂아도 실제 공급 전력은 60W에 머물렀다. 반면 작업 중 노트북은 70~80W 수준으로 달아올라 무릎에 바로 올리기 어렵고, 결국 담요와 베개로 열을 버텼다고 적었다. 문맥 길이도 100k 토큰을 넘기기 시작하면 지연과 처리량이 눈에 띄게 나빠졌다. 몇몇 프롬프트는 로컬 에이전트 스택을 무한 루프로 몰아 manual intervention이 필요했다고도 했다.

이 글이 더 설득력 있었던 이유는 계측 도구까지 직접 만들었다는 점이다. 저자는 powermonitor로 Mac 전력 telemetry를 읽고, lmstats로 LM Studio의 토큰 처리량과 지연을 추적했다. 그리고 결정적 발견도 했다. 문제는 모델만이 아니었다. iPhone 케이블을 쓰면 60W, MacBook 케이블을 쓰면 94W가 들어왔다. 귀국편 테스트의 핵심 변수는 모델 변경이 아니라 케이블이었다.

HN 댓글이 더한 해석

댓글 흐름은 냉정했다. 어떤 사용자는 이코노미석에서는 전력보다 공간이 더 큰 병목이라고 했다. 또 다른 반응은 발열과 루프였다. 로컬 LLM이 분명 인상적이긴 하지만, 의미 있는 작업에 들어가면 여전히 너무 쉽게 뜨거워지고, 쉽게 꼬인다는 경험담이 이어졌다. 특히 Qwen과 Gemma 계열을 로컬에서 돌릴 때 agentic task가 루프로 빠진다는 반응은 원문의 한계 인식과 맞물렸다.

왜 이 글이 올라왔나

이 스레드가 강하게 반응한 이유는 로컬 LLM 논쟁을 추상론이 아니라 와트, 열, 문맥 길이, 사용자 인내심으로 끌어내렸기 때문이다. 글 자체도 로컬이 클라우드를 대체한다고 주장하지 않는다. 범위는 더 좁고 더 믿을 만하다. 짧은 코딩, 탐색형 도구 제작, 굳이 클라우드 추론비를 쓰기 아까운 작업에는 로컬이 충분히 쓸 만하다. 하지만 긴 컨텍스트 추론, 불안정한 도구 호출, 오래 이어지는 에이전트 세션에서는 아직 매끈하지 않다. HN은 바로 그 거칠음이 현실이라고 봤다.

출처: 원문 블로그 · Hacker News 토론

#offline

10시간 비행기 오프라인 LLM 실험, HN이 본 건 전력·발열·루프의 현실