TechToast

GB10 에서 배운 것 — 속도는 대역폭을 활성 파라미터로 나눈 값이다

이 시리즈의 3부는 에이전트가 창고를 쓰는 이야기였다. 그리고 그 마지막 편에서, 나는 하나의 빚을 남기고 3부를 닫았다. 그 무렵 Hermes 의 브레인은 27B 였고, 그 27B 가 왜 그렇게 느렸는지는 다음 부에서 풀겠다고 했다. 그보다 더 일찍, 12편에서도 같은 질문을 접어둔 적이 있다. 모델이 느리다는 것 자체는 확인했는데, 왜 하필 그 모델이 그렇게 느린지는, 모델의 문제라기보다 그것을 올린 기계가 초당 얼마를 읽어낼 수 있느냐의 문제라며, 그 자리에서는 접어두었다. 이제 4부가 시작됐으니 그 빚을 갚는다. 이 편의 주제는 하드웨어다. 창고도, 에이전트도, 도구도 아닌, 그 모든 것이 올라가 있는 박스 하나의 물리적 특성이, 왜 모델 선택을 지배했는지에 대한 이야기다. 결론을 먼저 말하면, ..

AI 직원 11명 고용기.

2023년 7월, 중국 칭화대학 NLP 연구소가 챗GPT만으로 게임회사를 하나 세웠다. 쑨마오쑹 교수 지도 아래 만든 시연인데, 회사 이름은 ChatDev, 게임타이쿤에나 나올 법한 구성을 그대로 갖췄다. CEO부터 CTO, CPO, CRO, 프로그래머, 디자이너까지, 회사의 모든 직원이 전부 ChatGPT 봇이다. 회사에 아이디어 하나만 던져주면 설계부터 프로그래밍, 테스트, 문서화까지 전 과정을 AI가 알아서 완성하고, 사람이 개입하는 유일한 지점은 초기 아이디어 제공뿐이라는 게 이 시연의 핵심이었다. 게임 하나를 만드는 데 평균 409.84초, 약 7분이 걸렸고, 가장 빠를 때는 3분도 안 걸렸다. 게임당 평균 48.5K 토큰, 비용은 평균 0.2967달러. 30센트도 안 되는 돈으로 게임 한 편이..

이번 편은 메일이다. 교직원 포털의 그룹웨어는 대학 생활의 온갖 것이 지나가는 길인데, 회의 안내와 행정 공지가 오고, 동료의 메일이 오고, 학생의 질문이 온다. 이 흐름을 브레인에 넣어 두면, 브레인이 내가 하는 일의 적지 않은 부분을 저절로 알게 되는데, 그게 이 자동화를 시작한 이유였다. 메일 하나가 곧 업무 기록 하나라, 긁어 두면 기록이 되고 놓치면 흔적도 없다. 회의록은 지나간 일을 남기는데, 메일은 지금 일어나는 일을 남긴다. 그런데 막상 만들어 보니 메일을 긁어오는 일 자체는 어렵지 않았다. 어려웠던 것은 쌓인 메일을 어떻게 나누느냐였고, 그 나눔이 이 편의 전부다. 수집은 도구의 일이고, 나눔은 사람의 일이다. 어떤 기준으로 나뉘었는지, 하나씩 보자. 포털을 열고, 편지함을 걷는다그룹웨어..

지난 편의 마지막에서, 전사가 전사대로 싸움을 준비하고 있다고 했는데, 그 싸움의 상대는 소리가 아니었다. 회의 녹음을 글로 바꾸는 brain-transcribe 라는 작업이, 죽어 있었다. 녹음기는 소리를 받는 법을 고쳤는데, 정작 그 소리를 받아야 할 다음 관문이 넘어져 있었다. 그달 중반의 기록에는, numpy 와 numba 의 충돌이라는 진단 한 줄이 남아 있다. 버전 두 개가 싸운 흔적을, 하나씩 보자. 전사가 하는 일은 단순한데, 16k 모노 wav 를 받아서 텍스트로 바꾸는 것 하나다. 그 일을 하는 도구는 mlx-whisper 인데, large-v3-turbo 라는 모델을 맥의 통합 메모리 위에서 도는 애플 실리콘 전용 음성 인식이다. 만들어진 텍스트는 회의록 폴더에 전사 문서로 떨어지고,..

메뉴바 회의 녹음기부터 본다. 여덟 개로 시작해 열한 개가 된 파이프라인에, 첫 번째로 붙은 것이 이 녹음기다. 회의가 시작되면 클릭하고, 끝나면 또 클릭하는, 그게 전부인 앱이다. 5분마다 도는 동기화나 10분마다 도는 전사와 달리, 이건 손가락이 눌러야 시작되는 트리거 방식이다. 트리거로 산다는 점은 끝까지 그대로였는데, 소리를 받는 방식만 이상하게 무너졌다. 열 초를 녹음했는데 2.73초짜리 파일이 나오는, 소리가 줄어드는 실패였다. 무엇이 줄었는지, 하나씩 보자. 그달 중반에 붙은 세 개는 성격이 저마다 달랐다. 매일 새벽 세 시에 도는 정리 작업, 매주 월요일 아홉 시의 논문 리캡, 그리고 버튼이 눌릴 때 도는 녹음기였다. 셋 중에서 가장 손에 가까운 곳에 있는 것이 이 녹음기였다. 이 녹음기가..

1부의 끝에서, 2부는 자료가 끊기지 않고 흘러들게 만드는 이야기라고 적었다. 자동화 8개를 붙였고, 그중 몇 개는 이상한 방식으로 실패했다고도 적었다. 이제 그 여덟 개가 무엇이고, 왜 그 간격으로 도는지부터 본다. 1부에서 만든 것은, 정확히는 소화 기관이다. 문서를 읽어 위키로 합성하고, 임베딩으로 색인하고, 질문이 오면 거기서 답을 찾는. 그런데 그 어느 것도, 재료가 들어오지 않으면 시작되지 않는다. 합성할 소스가 없으면 합성할 게 없고, 색인할 파일이 없으면 색인할 게 없다. 이걸 만들고 며칠 만에, 일이 실제로 어디에 있는지가 보였다. 합성이 아니라, 끊기지 않는 유입이었다. 유입 경로는 네 갈래였다. 손으로 쓰는 노트, 회의에서 나는 소리, 포털에 오는 메일, 그리고 일정. 넷 다 손이 닿..

1부의 마지막 편이다. 앞 세 편에서 세컨드브레인을 LLM-Wiki 패턴으로 시작하고, 문서 2만 개를 만나 벡터 검색 계층을 얹고, 온갖 파일 포맷에서 텍스트를 꺼내는 이야기를 썼다. 이 편은, 그렇게 만든 위키를 열어봤을 때 생긴 일이다. 2주쯤 지나 브라우징 화면을 붙였고, 페이지를 넘겨보다가 이상한 걸 발견했다. 일부 페이지가 영어로 쓰여 있었다. 내 자료는 거의 전부 한국어인데, 합성된 페이지가 영어라니, 아무도 부탁하지 않은 번역이다. 왜 그랬는지부터 보자. 원인은 금방 찾았는데, 프롬프트를 열어보니 ingest 시 LLM 에 주는 시스템 프롬프트에 한국어로 작성 지시가 이미 있었다. 지금 규칙은 맞고, 영어 페이지는 초기 버전의 잔재다. 처음엔 프롬프트가 영어였고, 모델이 영어로 답했는데,..

앞 편에서 문서 2만 개를 만나 설계를 고친 이야기를 썼다. 벡터 검색 계층을 얹고, 청크로 쪼개서 임베딩하면 된다고 적었는데, 그 문장에는 앞 단계가 하나 빠져 있다. 파일에서 텍스트를 꺼내는 일. 이게 이 프로젝트에서 제일 지루하고, 제일 오래 걸리고, 블로그에서 아무도 안 쓰는 부분이다. RAG 튜토리얼은 대부분 PyPDFLoader 한 줄로 끝난다. 실제 자료는 그렇게 생기지 않았고, 공문 하나만 열어봐도 한글 파일이 나오고, 구형 오피스 파일이 나오고, 스캔 이미지가 나온다. 이 글이 그 삽질을 반복하지 않게 해주면 좋겠다. 처리해야 했던 포맷드라이브에서 당겨온 파일의 확장자를 세어보고 정리한 목록이다. pdf docx pptx xlsx csv txt mdhwp hwpx..

앞 편에서, 개인 연구용 세컨드브레인을 벡터 RAG 없이 시작한 이야기를 썼다. 소스가 들어올 때 LLM 이 한 번 읽고 링크 걸린 마크다운으로 다시 쓰는 방식(Karpathy 의 LLM-Wiki 패턴)이고, 근거 중 하나가 "개인 규모에서는 사전합성이 RAG 를 이긴다" 였다. 2026년 6월 2일에 그게 엔드투엔드로 돌아가는 걸 확인했다. 같은 날 설계가 깨졌다. 이 편은 그 이야기고, 시리즈에서 제일 중요한 편이라고 생각한다. 산수 한 줄로 끝났다구글드라이브에는 대학 두 곳에서 일하며 만든 자료가 예전부터 쌓여 있었다. 브레인에 넣을 대상으로 그 폴더를 지정하고, 규모를 세어봤다. 폴더 두 개를 합쳐 문서 20,500개에, 약 53 GiB 였다. 이하 이 글에서는 약 2만 개라고 부르자. 앞 편에..

의료영상 AI 연구를 하다 보니, 논문이며 회의록, 연구계획서, 강의자료, 과제 문서가 몇 년치 쌓였는데, 어느 순간부터는 어디에 뭐가 있는지 내 머리로 감당이 안 되기 시작했다. 검색을 해도 파일명이 기억나야 찾아지고, 파일명은 당연히 기억나지 않고. 그래서 개인 연구용 세컨드브레인을 만들기로 했다. 2026년 6월 2일이었다. 이 글은 그 첫날에 내린 설계 결정 하나에 관한 이야기다. 요즘 이런 걸 만든다고 하면 거의 자동으로 나오는 답이 있는데, 문서를 청크로 쪼개 임베딩하고 벡터DB에 넣어두고, 질문이 들어오면 비슷한 조각을 꺼내 LLM에 물리는 방식, 그러니까 RAG다. 나는 그걸 안 하기로 시작했다. 두 달 뒤에 이 시스템은 "아무짝에도 쓸모없다"는 말을 듣게 되는데, 미리 밝혀두면 그 원인은..