피터의 개발이야기

TL;DR로컬 LLM 환경에서 가장 먼저 부딪히는 벽은 연산 성능보다 메모리다.작은 모델은 “문장을 생성”하지만,큰 모델은 “컨텍스트를 유지하며 추론”한다.결국 로컬 AI 머신의 핵심은 CPU 속도가 아니라,얼마나 큰 모델과 Context를 메모리에 안정적으로 올릴 수 있는가에 가깝다. ㅁ 들어가며오늘 한 크루가 맥미니를 구매해서 로컬 LLM 기반 서비스를 직접 만들어 보고 싶다고 이야기했다.그러면서 자연스럽게 이런 질문이 나왔다.“맥미니를 산다면 CPU가 중요할까, GPU가 중요할까?”처음에는 보통 코어 수나 GPU 성능을 먼저 보게 된다.그런데 실제로 로컬 LLM을 구성해보면 병목은 생각보다 다른 곳에서 먼저 나타난다. 좀 더 자세한 글) [AI] GPU vs PIM vs NPU - 내 시스템의..

ㅁ 들어가며 예전에 읽었던 세이노의 가르침에서 추천했던 책이다.나는 책을 읽을 때 단순히 내용을 따라가기보다, 작가와 대화하듯 읽으려고 한다. 그래서 먼저 작가가 어떤 사람인지 이해하고, 어떤 경험과 관점으로 자신의 생각을 전달하려 하는지 살펴본다. 그리고 각 챕터가 그 핵심적인 생각을 어떤 방식으로 풀어내고 있는지 작가의 입장에서 따라가며 읽으려 노력한다. ㅁ ChatGPT 작가의 사고방식을 이해하며 읽기허브 코헨을 이해하기 위해 단순히 책의 내용만 따라가지는 않았다.책을 읽다가 생기는 궁금한 점이나 이해되지 않는 관점들을 계속 정리하며, 작가가 왜 이런 사례를 들었는지, 결국 어떤 생각을 전달하려 하는지 스스로 해석해보려 했다.특히 허브 코헨은 일반적인 자기계발서처럼 핵심 이론을 먼저 설명하는 방식..

TL;DRGPU와 PIM은 같은 축의 다음 세대가 아니라, 서로 다른 병목을 푸는 도구다.GPU는 FLOPS를 늘리고, PIM은 Byte 이동을 줄인다 — 경쟁재가 아니라 조합재.ㅁ 들어가며[AI] 인공지능에 대한 이해(2017에 정리한 리포트)에서 PIM을 언급하고,[AI] PIM(Processing In Memory)란?에서 PIM을 단독으로 정리한 적이 있다.이번에는 GPU·NPU와 함께 놓고 '병목 위치' 관점에서 다시 본다. AI 모델에 GPU를 쓰는 이유에 대한 글을 읽다가 자연스럽게 PIM(Processing In Memory)이 떠올랐다.처음에는 "GPU 다음 세대" 정도로 막연하게 묶어 두고 있었는데,정리하다 보니 둘은 같은 축이 아니었다. 결론부터 말하면 GPU는 연산을 빠르게 하는 구..

ㅁ 들어가며ㅇ 언제 어디서든 브라우저 VS Code로 정보를 입력하면, 모든 것이 쌓이는 개인 지식 숲을 만들었습니다.노트는 한 번만 작성합니다. 분류·요약·교차참조·인용 부착·모순 표시는 LLM 이 알아서 — 영속 위키에 계속 누적되도록. ㅁ 문제: 매번 0 부터 발견LLM 으로 문서를 다루는 가장 흔한 패턴 — PDF 나 노트를 챗 인터페이스에 붙여 넣고 질문, 답을 받고, 닫는다. 다음에 같은 주제가 또 떠오르면 같은 문서를 다시 붙이고, 같은 추론을 다시 하게 시킨다.같은 자료에 10번 질문하면 LLM 은 그 자료를 10번 처음부터 발견한다. 토큰값과 시간이 든다. 더 큰 문제는 이전에 얻은 통찰이 어디에도 누적되지 않는다는 것이다. 다음에 비슷한 주제를 마주쳐도 처음 만나는 것과 같다. ㅁ 발상..

ㅁ TL;DR약한 청크 = moc/·entities/·concepts/의 "관련 포스트", "주요 태그", 연도 그룹, 순수 링크 목록본문 없고 키워드만 풍부 → 임베딩 유사도가 가짜로 높게 나온다해법: 경로·헤딩 한 줄 필터 (새 모델·인덱스·리랭커 0개)실측 기준:청크 수: 118 → 93 (-25, -21%)MRR(Mean Reciprocal Rank): 0.794 → 0.947 (+0.15)R@3(Recall@3): 0.933 → 1.000결론: 모델을 바꾸기 전에 청크를 봐야 한다ㅁ 왜 이 문제를 발견했나폰에서 "쿠버네티스에서 graceful shutdown이란?"을 물었다.top-3에 정답 블로그 183번 글과 함께, MOC 파일의 "관련 포스트" 링크 목록이 두 개 섞여 들어왔다.그 목록 청..

ㅁ TL;DRRTK는 github.com/rtk-ai/rtk 의 실존 OSS다. 아키텍처 개념이 아니라 단일 Rust 바이너리로 배포되는 CLI 프록시.AI 에이전트(Claude Code, Cursor, Gemini CLI 등)가 실행한 터미널 명령 출력을 가로채, 60~90% 압축한 뒤 LLM에 전달한다.동작 방식은 shell hook 이 git status 를 rtk git status 로 자동 치환. 에이전트 코드 수정 없이 붙는다.오버헤드는 ㅁ 왜 이게 필요한가AI 코딩 에이전트는 매 작업마다 아래를 실행한다.npm installpytestgit statusdocker build .출력은 대부분 진행바, 다운로드 로그, 성공 라인 이다. LLM은 이 노이즈를 전부 context window 에 ..

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며ㅇ LiteRT-LM — 온디바이스 LLM을 실제로 “돌리게” 만드는 런타임 ㅁ TL;DRLiteRT-LM = 온디바이스 LLM 추론 런타임핵심 차별점: .litertlm (모델 + 토크나이저 + 템플릿 번들)서버 런타임(vLLM/Ollama)은 모바일에 그대로 못 옮긴다실제 기준:Galaxy S23 UltraGemma 4 E2B약 40초/응답모델 크기 약 2.4GB결론: 모델만큼 런타임 선택이 초기에 결정된다 ㅁ 왜 LiteRT-LM까지 오게 됐는가Gemma 4 E2B를 폰에서 돌리는 데 48시간을 썼다.시간의 대부분은 모델이 아니라 런타임에서 막혔다.llama.cpp → Android NDK / NPU 활용 제한서버 구조(vLLM/Ollama)..

TL;DR#원칙핵심1목표 축소완벽한 RAG ❌ → 끝까지 도는 최소 사이클 1개2모델 통일서버/모바일 분리 ❌ → 동일 임베딩 모델3데이터가 성능모델보다 청크 품질이 MRR을 움직인다4청크는 제거추가 ❌ → 약한 청크 제거로 R@3 올리기5검색은 단순하게N brute-force가 정답6배포 단위모델 ❌ → 모델 + 토크나이저 + 설정 세트7양자화는 필수선택 ❌ → 배포 조건8프롬프트 욕심 금지작은 모델 → 짧고 단순하게9속도 기대치 현실화40초 느림 = 독립성과 바꾼 비용10제약을 받아들여라장애 ❌ → 설계 기준한 줄 요약: 작게 만들고, 단순하게 유지하고, 끝까지 동작시킨다. ㅁ 들어가며서버·네트워크 없이, Galaxy S23 Ultra에서 40초 뒤 두 문장으로 답하는 RAG를 만들었다.기술 다섯..

ㅁ 들어가며이전 글에서 맥미니 위에 RAG 서버를 올려 내 블로그 1,000편을 검색하게 만들었다.그 글 마지막에 "문서 1,000개는 보유만으로는 창고. 검색이 붙는 순간 두 번째 뇌가 된다"고 썼다.그런데 그 뇌는 맥미니가 켜져 있을 때만 일했다.와이파이가 없으면, 서버가 내려가면, 내 지식에 닿지 않았다.그래서 질문을 바꿨다 — 내 기억을 내 주머니로 옮길 수 있을까.Galaxy S23 Ultra를 비행기 모드로 둔 채 물어봤다."쿠버네티스에서 graceful shutdown이란?"40초 뒤 폰이 내 블로그 183번 글의 청크를 인용하며 두 문장으로 답했다.서버 없이, 네트워크 없이, 내 손 안에서.이 글은 그 한 번의 응답까지 가기 위해 검토해야 했던 다섯 가지 기술의 요약이다.상세한 벤치마크·시..

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며지난 글, [AI] 1,000개 블로그 글 Wiki에 로컬 RAG 챗봇 붙이기 — peterica-blog-chat에서 sqlite-vec에 대해서 언급하였다.sqlite-vec는 파일 하나(wiki.db)가 벡터 스토어의 전부이다.ㅁ 왜 sqlite-vec를 선택하였는가?ㅇ DB와 인덱스가 파일 하나(`data/wiki.db`)로 구성된다. → 별도의 서버 없이도 하나의 파일만으로 데이터와 검색 구조를 함께 관리할 수 있다.ㅇ 백업과 복구가 단순하다. → 백업은 파일을 복사(`cp`)하면 끝이고, 문제가 생기면 파일을 교체하는 방식으로 롤백이 가능하다. 운영 복잡도가 매우 낮다.ㅇ 별도의 서버나 런타임이 필요 없다. → sqlite 확장 형..

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며나는 AI를 잘 운영하는 개발자로 성장하기위해 노력하고 있다.그래서 지난 글 [AI] 1000개 블로그 글을 LLM Wiki로 만든 이야기 — Karpathy의 아이디어를 실전에 적용하다에서1,000개 문서짜리 제 Obsidian Wiki를 만들었다.이번엔 그 위에 로컬 RAG 챗봇을 올렸다.이 글은 그 구축 기록이고, 동시에 왜 Vercel을 버리고 맥미니 + Cloudflare Tunnel로 갔는지에 대한 기록이다. 내가 공부한 llm모델의 임베딩, 로컬 시스템으로 연동하여 나에게 필요한 백터디비의 사양을 파악하는 연습을 하기 위해서다. 우리집 맥미니 M1 8GB에서 local LLM으로 가동 중이다. peterica-blog-chat ㅁ 요..

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며예전에 "Claude Code를 소프트웨어처럼 설계하기 — 프롬프트 하네스 아키텍처" 라는 글에서 정리한 적이 있다.프롬프트가 코드이고, 스킬이 함수이며, 에이전트가 마이크로서비스라는 관점이다.그 위에서 블로그 1,000편을 스크래핑하고 위키로 변환하는 파이프라인을 운영했다. 시간이 지나니 스킬이 17개, 18개, 20개로 늘어났다.한편으로는 좋았지만, 다른 한편으로는 "어떤 스킬을 언제 불러야 하는지" 를 나조차 자주 잊어버렸다. "이 초안 팩트체크도 하고 폴리싱도 하고 발행준비도 해줘"라고 말하면,Claude가 어떤 스킬을 어떤 순서로 부를지 매번 다르게 해석했다. 그래서 하나 더 만들었다.이번엔 스킬을 부르는 스킬 - FDE(Forward D..

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며오늘 회의 시간에 나온 질문이다. "왜 Argo CD로 다 안 하고 Jenkins로 빌드하죠?" 쿠버네티스 도입 초기 팀에서 자주 나오는 질문이다.Argo CD 이름에 "CD"가 박혀 있으니 CI/CD 풀스택으로 오해하기 쉽지만, 실제로는 그렇지 않다. 결론부터 말하면 이미지 빌드는 Jenkins, 클러스터 배포는 Argo CD 다.둘은 경쟁재가 아니라 조합재다. 이 글은 그 역할 분리가 왜 자연스러운 설계인지 정리한다. ㅁ 역할이 애초에 다르다 — CI vs CD Jenkins와 Argo CD는 파이프라인에서 서로 다른 영역을 책임진다.Jenkins — 코드 변경 → 빌드 → 테스트 → Docker 이미지 생성 → 레지스트리 푸시. CI (Con..

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며이 문서는 이전 글 Claude Code를 소프트웨어처럼 설계하기 - 프롬프트 하네스 아키텍처 에서 설명한 각 설계 패턴을 실제로 구현할 때 사용한 프롬프트 예시를 모아둔 것이다.그대로 복사해서 쓸 수 있도록 작성했다. 1. CLAUDE.md — 글로벌 행동 규칙 정의프롬프트: 글로벌 규칙 파일 작성 요청~/.claude/CLAUDE.md에 다음 규칙을 추가해줘:1. 코드 수정 전 반드시 해당 파일을 Read 한 후 Edit 한다2. git commit은 명시적 요청 없이 절대 하지 않는다3. 임시 파일은 작업 완료 후 반드시 삭제한다4. 테스트가 있는 프로젝트에서는 코드 수정 후 테스트를 실행한다5. feature 브랜치에서만 작업하고, main..

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며Claude Code를 처음 쓸 때는 대화창에 "이거 만들어줘"라고 치면 됐다.하지만 1,000개 블로그 글을 자동으로 스크래핑하고, 요약하고, 위키로 변환하는 파이프라인을 만들면서 한계를 느꼈다.매번 같은 맥락을 설명해야 했고, 세션이 바뀌면 전부 잊어버렸고, 반복 작업에 비싼 모델의 토큰을 낭비했다. 그래서 접근을 바꿨다. Claude를 "대화 상대"가 아니라 "프로그래밍 가능한 실행 엔진"으로 설계하기로 했다.프롬프트가 코드이고, 스킬이 함수이며, 에이전트가 마이크로서비스인 구조다. 이 글에서 그 설계를 정리한다. 1. 계층적 프롬프트 주입 — 설정 파일처럼 쓰는 CLAUDE.mdClaude Code는 대화 시작 시 여러 레벨의 설정 파일을..