기술
230개의 포스트
LLM은 도약하지 못한다: 아인슈타인의 낙서 한 장이 2026년 AI에게 던진 질문
구글 딥마인드 톰 자하비의 ICML 2026 포지션 페이퍼 「Position: LLMs can't jump」를 정면으로 뜯어본다. 아인슈타인이 친구에게 그려 보낸 낙서 한 장에서 출발해, 왜 오늘의 AI가 정리를 증명하면서도 전제를 만들지 못하는지, 벌컨 행성과 엘리베이터 사고실험과 2026년의 월드 모델 경쟁까지 — 5개의 인터랙티브와 함께 끝까지 따라간다.
당신의 AI, 빌린 겁니까 가진 겁니까 (1부): '인텔리전스 오너십'이라는 새 승부수
2026년 7월, Fermisense가 올린 한 편의 글이 AI 업계를 흔들었다. 90억 파라미터짜리 작은 오픈소스 모델을 강화학습으로 훈련시켰더니, 세계 최고 프런티어 모델을 전부 이기고도 비용은 최대 340배 싸더라는 것이다. 이 특집 1부는 '인텔리전스를 소유한다'는 개념이 왜 지금 등장했는지를 ChatGPT 이후의 역사와 2026년의 AI 경제학으로 추적한다.
당신의 AI, 빌린 겁니까 가진 겁니까 (2부): SFT에서 GRPO까지, '디지털 트윈'이라는 훈련장
'강화학습으로 모델을 훈련한다'는 말은 정확히 무슨 뜻일까? 사전학습·SFT·RLHF·RLVR로 이어지는 개념의 사다리를 밟아 오르고, 요즘 화제인 GRPO를 '커브로 채점하는 시험'에 빗대 직관적으로 푼다. 그리고 모델이 실제로 업무를 연습하는 '디지털 트윈'과 보상 설계까지, Fermisense의 카탈로그 실험을 해부한다.
당신의 AI, 빌린 겁니까 가진 겁니까 (3부): 90억 모델이 프런티어를 이긴 날, 그리고 판별법
이론은 충분하다. 이제 숫자다. Fermisense의 90억 파라미터 모델은 e커머스 카탈로그 검수에서 프런티어 5종을 어떻게 이겼고, 비용은 왜 최대 340배 저렴했나. 브리지워터부터 링크드인·체커까지 11개 회사의 성적표를 펼치고, 마지막엔 '우리 회사의 어떤 업무가 이 방식의 후보인가'를 직접 판별하는 체크리스트로 특집을 닫는다.
넷플릭스는 왜 LLM을 직접 서빙하는가 (3부): 제약 디코딩, 규모의 벽을 넘다
이 특집의 클라이맥스. 넷플릭스는 모델이 '아마도 유효한' JSON을 뱉고 나서 검사하는 대신, 애초에 규칙을 어길 수 없도록 생성 과정 자체를 제약한다. 이 제약 디코딩이 왜 필요하고 어떻게 작동하는지, 그리고 그것을 '규모'에서 돌리려다 vLLM V0의 GIL 벽에 부딪혀 V1으로 넘어간 넷플릭스의 실전 분투기를 따라간다. 직접 서빙해야만 가능한, 커스터마이징의 끝판왕.
실리콘 뇌가 깨어난다 — GPU가 태우는 전기의 250분의 1로, 뉴로모픽 컴퓨팅이 실험실을 나오다
2026년, AI 데이터센터는 지구 전기의 약 2%(500 TWh 이상)를 삼킨다. 전력망은 이 속도를 못 따라간다. 근본 원인은 놀랍게도 1945년에 정해진 76년 된 설계 결함 — 폰 노이만 병목이다. 기억과 계산을 따로 두고 그 사이로 데이터를 쉴 새 없이 실어 나르느라 전기가 타는 것이다. 인간의 뇌는 같은 문제를 20와트로 푼다. 기억과 계산을 한 곳에 두고, 필요할 때만 '스파이크'로 발화하기 때문이다. 이 글은 뇌의 설계를 실리콘에 옮긴 뉴로모픽 컴퓨팅을 폰 노이만 병목부터 스파이킹 신경망(SNN)·인메모리 컴퓨팅까지 쉽게 풀고, 2026년 실험실을 나온 Intel Loihi 3(GPU의 250분의 1 전력)·IBM NorthPole·BrainChip Akida의 실물 성적과 그 한계까지 짚는다.
넷플릭스는 왜 LLM을 직접 서빙하는가 (2부): vLLM과 Triton, 서빙 엔진을 해부하다
1부에서 '왜'를 봤다면 2부는 '어떻게'다. 넷플릭스 서빙 스택의 심장인 vLLM과 Triton을 뜯어본다. KV 캐시가 왜 메모리를 잡아먹는지, PagedAttention이 어떻게 그걸 운영체제의 페이징으로 해결했는지, 연속 배칭이 왜 처리량을 몇 배로 끌어올리는지 — 생소한 용어를 하나씩 그림으로 풀고, 넷플릭스가 TensorRT-LLM에서 vLLM으로 갈아탄 진짜 이유까지 따라간다.
넷플릭스는 왜 LLM을 직접 서빙하는가 (1부): '그냥 API 쓰면 되잖아'에 대한 대답
2026년 7월, 넷플릭스가 자사 LLM 서빙 스택을 공개했다. 요약하면 '우리는 OpenAI API를 쓰지 않는다. 모델 배포부터 추론까지 전 과정을 우리 손으로 굴린다'이다. 대부분의 회사가 API 한 줄로 끝내는 시대에, 넷플릭스는 왜 굳이 인프라를 통째로 짊어졌을까? 이 특집 1부는 그 '왜'를 추천 시스템의 역사부터 2026년 인퍼런스 경제학까지 따라가며 답한다.
AWS 인프라 구성도 실무 가이드 (Part 5): 도구·시각 디자인·평가 — 구성도를 팀 표준으로 만들기
개인기로 그린 구성도는 그 사람이 나가면 끝난다. 2026년 기준 도구 9종 비교, 16:9 슬라이드 영역 배분과 글자 크기 하한, 범례·메타데이터 표준, /architecture 파일 구조와 ADR, 그리고 100점 평가표로 3부의 완성본을 실제 채점한다.
AWS 인프라 구성도 실무 가이드 (Part 4): AWS에서 가장 많이 틀리는 배치, 그리고 레퍼런스 읽는 법
S3 버킷은 서브넷 안에 없다. Lambda는 고객 VPC에서 실행되지 않는다. 그림이 읽히는 것과 맞는 것은 다른 문제다. 배치 오류 다섯 가지를 바로잡고, AWS 공식 레퍼런스 수십 장이 수렴하는 여섯 가지 레이아웃 패턴과 생성형 AI 수명주기 축까지 정리한다.
AWS 인프라 구성도 실무 가이드 (Part 3): draw.io를 열기 전에 — Architecture Brief와 7단계
툴을 먼저 열면 요구사항이 아니라 익숙한 AWS 서비스에 설계를 끼워 맞추게 된다. 그리기 전에 작성하는 Architecture Brief 16항목, 그리고 기능 블록에서 시작해 아이콘 감량으로 끝나는 7단계. 1부에서 예고한 '같은 사업, 다르게 그린 한 장'의 완성본이 여기서 나온다.
AWS 인프라 구성도 실무 가이드 (Part 2): 한 장 말고 여섯 장 — 제안서 구성도 세트 설계
종합 구성도 한 장으로 모든 독자를 만족시키려는 시도는 반드시 실패한다. 실패의 원인은 욕심이 아니라 줌 레벨이 섞였기 때문이다. C4 모델로 확대 수준을 정하고, arc42로 누락을 점검하고, 제안서에 들어갈 6장 세트를 설계한다.