들어가며
양세종의 블로그에 오신 것을 환영합니다.
본문
‘GPU의 시대가 지고 CPU의 시대가 온다’는 말은 반은 맞고 반은 틀리다. 에이전틱 AI는 GPU를 덜 쓰는 기술이 아니라, GPU가 낸 답을 실제 업무로 연결하기 위해 CPU·메모리·스토리지·네트워크를 더 많이 붙이는 기술에 가깝다. 이 글에서는 먼저 CPU와 GPU가 일을 나누는 구조를 보고, 그 구조가 에이전트 런타임과 기업 실적으로 어떻게 이어지는지, 마지막으로 이미 크게 오른 종목들 사이에서 Intel이 왜 상대적으로 다시 볼 만한지 살펴본다.
CPU와 GPU는 무엇이 다른가
CPU는 적은 수의 강한 코어로 복잡하고 순서가 자주 바뀌는 일을 빠르게 처리하도록 설계된다. 큰 캐시, 정교한 분기 예측, 비순차 실행 같은 장치를 사용해 “다음에 무슨 일이 생길지 모르는 작업”의 지연시간을 줄인다. 운영체제, 데이터베이스, 웹 서버, API 호출, 파일 입출력, 보안 검사처럼 조건문과 예외가 많은 일이 CPU에 잘 맞는다.
GPU는 반대 방향에서 발전했다. 하나하나가 CPU 코어만큼 다재다능하지는 않지만, 수많은 연산 유닛이 같은 종류의 계산을 동시에 수행한다. NVIDIA의 CUDA 모델에서는 GPU가 여러 Streaming Multiprocessor(SM)로 구성되고, 스레드들은 묶음 단위로 병렬 실행된다. 행렬곱처럼 동일한 연산을 방대한 데이터에 반복하는 학습과 추론에 강한 이유다. GPU 옆에 HBM 같은 고대역폭 메모리가 붙는 것도 연산 유닛에 데이터를 끊임없이 공급하기 위해서다.
비유하면 CPU는 소수의 숙련된 실무자다. 갑자기 규정이 바뀌거나 예외가 생겨도 각자 판단해 일을 이어간다. GPU는 같은 계산을 놀라운 속도로 반복하는 대규모 전문 작업반이다. 일이 일정하게 쪼개질수록 강하지만, 작업마다 다른 사이트에 로그인하고 오류 메시지를 읽고 다음 행동을 바꾸는 일에는 맞지 않는다.
둘은 경쟁자라기보다 한 시스템의 서로 다른 기관이다. 실제 CUDA 프로그램도 CPU에서 시작한다. CPU가 데이터를 준비하고 GPU 커널을 실행한 뒤 결과를 기다리거나 다음 일을 배정한다. 현대 CPU에는 Intel AMX 같은 행렬 연산기가 들어가고 GPU도 캐시와 제어 기능이 고도화되면서 경계가 흐려지고 있지만, CPU는 지연시간과 제어 흐름, GPU는 처리량과 데이터 병렬성에 강하다는 큰 차이는 남아 있다.
그림 1. CPU가 제어·도구 실행을 맡고 GPU가 모델의 병렬 연산을 맡는 에이전트 런타임의 개념도. 직접 제작.
AI가 일을 시작하면 CPU도 바빠진다
에이전틱 AI가 키우는 범용 컴퓨팅 수요와, 투자에서 봐야 할 이익의 귀속
본문
최근에 LinkedIn, GitHub, 홈페이지와 블로그를 한꺼번에 놓고 보았다.
각각에는 나름 열심히 살아온 흔적이 있었다. LinkedIn에는 경력이 있고, GitHub에는 그동안 만든 코드가 있고, 홈페이지에는 논문과 프로젝트가 있다. 블로그에는 대학원 생활부터 이런저런 생각들이 쌓여 있다.
그런데 묘하게도 네 곳이 지금의 같은 사람을 가리키고 있지는 않았다.
LinkedIn은 과거의 이력을 보여주고, GitHub은 한동안 멈춘 프로젝트가 많고, 홈페이지는 논문 목록에 가깝다. 블로그에는 내가 무슨 생각을 하는지는 있지만, 요즘 어떤 기술적 질문을 붙잡고 있는지는 잘 보이지 않는다.
퍼스널 브랜딩을 해야겠다는 생각은 여기서 시작했다. 그렇다고 갑자기 “AI 전문가가 알려주는 최신 기술” 같은 글을 쓰고 싶지는 않았다. 이미 공개된 발표를 요약하면서 아는 척하는 것도 영 내키지 않고, 회사에서 하는 일을 내 성과처럼 꺼내놓는 것은 더더욱 안 된다.
그럼 회사 일을 말하지 않고도, 내가 어떤 연구자이고 엔지니어인지를 어떻게 보여줄 수 있을까?
내가 내린 답은 공개 모델을 직접 실험하는 것이었다.
Personal Rebranding
공개된 EXAONE 모델을 개인 환경에서 검증하고, 블로그와 LinkedIn에 남기는 실험 기록

데이터는 그 자체로 가치가 없다
데이터 품질에 관한 어떤 글을 읽고 — 섀넌부터 AI까지, 가치가 '만들어지는' 자리에 대하여

777이 없는 룰렛과 과녁을 나중에 그리는 사람들
확률 조작 사건과 부정선거 의혹으로 배우는 통계적 문해력

사랑에도 운용 능력이 필요하다
사랑은 감정의 총량이 아니라 역량의 총합이다
1. 조선은 왜 전쟁 한 번 제대로 못하고 무너졌을까?
조선 말기의 멸망을 설명할 때 흔히 나오는 이야기가 있다.
조선은 성리학적 문치주의에 빠져 군대를 천시했고, 양반 지배층은 신분제를 지키는 데만 몰두했으며, 결국 근대 제국주의 국가인 일본 앞에서 전면전 한 번 치르지 못하고 무너졌다는 설명이다.
이 설명은 일정 부분 맞다. 조선 후기 군역 제도는 점차 실제 군사 복무보다 군포를 걷는 재정 제도처럼 변했고, 양반층은 여러 방식으로 군역 부담에서 빠져나갔다. 임진왜란 이후 훈련도감과 오군영 같은 군사 개혁이 있었지만, 그것이 근대적 국민군이나 재정군사국가로 발전하지는 못했다. 대한제국기에도 군사력 강화와 징병제 구상이 있었지만, 이미 일본과 러시아가 한반도를 둘러싸고 각축하던 시기였고 시간과 자원이 부족했다.
그러나 이 설명을 “조선 지배층이 멍청하고 이기적이어서 망했다”는 식으로 밀어붙이면 너무 단순하다. 조선의 문제는 도덕성의 문제가 아니라, 더 깊은 구조의 문제였다. 한반도는 산지가 많고 경작지가 제한적이었다. 조선은 낮은 농업 생산성과 좁은 세원 위에서 운영되는 국가였다. 근대 군대는 병력만 있으면 되는 것이 아니라, 인구 파악, 조세 행정, 장교단, 무기, 탄약, 군복, 훈련소, 교통망, 군수산업, 금융 시스템을 필요로 한다. 조선은 이런 체계를 만들기에는 물질적 기반도, 제도적 동원력도, 정치적 합의도 부족했다.
따라서 조선의 멸망은 단순히 “성리학 때문에 군대를 싫어해서”가 아니라, 낮은 생산 기반, 약한 재정 추출력, 신분제적 이해관계, 늦은 개혁, 제국주의 국제질서, 일본의 단계적 주권 해체가 겹친 결과였다.
2. 조선의 신분제는 왜 그렇게 오래 버텼을까?
조선의 신분제는 왜 오래 버텼고, 오늘날 한국은 무엇을 배워야 하는가
척박한 생산 기반, 지위 경쟁, 엘리트 재생산, 그리고 “현대판 양반화”의 위험

천재성의 민주화와 인지부채의 함정
Agentic Coding 시대에 우리는 무엇을 AI에게 맡기고, 무엇을 끝까지 직접 생각해야 하는가
Sequoia의 Julien Bek이 쓴 Services: The New Software를 읽고, 한 발짝 더 나가보고 싶었다. 이 글은 "AI가 SaaS 시장이 아니라 서비스 시장을 먹는다"는 인사이트를 개인/커리어/국가 레벨로 확장한 개인적인 노트다.
1. 원문의 핵심만 다시 짚고 가자
세쿼이아의 주장은 단순하다.
•
SaaS는 도구를 팔았다. 인간이 그 도구로 "일"을 해야 결과가 나왔다.
•
AI 시대의 승자는 **결과(outcome)**를 파는 회사다. 소프트웨어의 탈을 쓴 서비스 회사.
•
기업이 소프트웨어에 $1 쓸 때 서비스에는 $6를 쓴다. AI는 이 $6 시장을 먹는다.
•
지능(intelligence, 반복 가능한 작업)은 AI로 빠르게 대체되고, 판단(judgement, 맥락·직관)은 당분간 인간의 영역. 단 이 경계선은 데이터가 쌓일수록 계속 뒤로 밀린다.
소프트웨어가 서비스를 삼킬 때: 개인, 커리어, 그리고 소버린 AI
Do not Fight or Sell the Model
본문 (Claude Code Generated)
논문: FileGram: Grounding Agent Personalization in File-System Behavioral Traces
저자: Shuai Liu, Shulin Tian, Kairui Hu 외 (NTU S-Lab, Synvo AI)
날짜: 2026년 4월 6일
링크: arXiv:2604.04901 | Project Page | GitHub | Dataset
TL;DR
AI 에이전트가 사용자의 파일 시스템 작업 패턴(파일 읽기, 생성, 편집, 정리 등)을 기억하고 개인화에 활용하는 프레임워크. 기존 대화 요약 기반 메모리 시스템(Mem0, Zep 등)이 행동 구분 정보를 잃어버리는 문제를 지적하고, 원자적 행동 로그에서 직접 프로파일을 구축하는 bottom-up 메모리 아키텍처를 제안한다.
왜 이 연구가 필요한가?
OS-level AI 에이전트(Claude Code, Cursor, Devin 등)가 단순 명령 실행을 넘어 파일 시스템 코워커로 진화하고 있다. 그런데 사용자마다 작업 방식이 완전히 다르다.
FileGram: 파일 시스템 행동 흔적으로 AI 에이전트를 개인화하다
AI와 유저의 상호작용만 중요한 게 아니라… 결국 AI가 File System, 즉 Environment와 어떻게 상호작용했느냐가 더 중요한 힌트일수도 있다 
최근 LG 인화원에서 기획 강의를 들었다.
강의가 끝나고 남은 것은 기획을 더 잘 "쓰는 법"이 아니었다.
기획을 완전히 다르게 "생각하는 법"이었다.
그 변화의 핵심을 정리해 본다.
하지만 이 뒤로는 ChatGPT 5.4와 Claude Opus 4.6의 도움으로 작성되었다.
1. 기획은 논문이 아니다
그동안 나는 연구자로서 기획을 해왔다.
문제를 정의하고, 분석하고, 방법을 제시하고, 검증한다.
이 구조는 익숙하고 논리적으로도 완벽하다.
하지만 기획서를 받아든 사람의 반응은 항상 같았다.
"그래서… 어쩌라고?"
기획은 설득이다: 연구자에서 기획자로 사고가 바뀌는 순간
논문처럼 쓰던 기획서에서, 사람을 움직이는 기획으로
Load more


