본문 바로가기

전체 글

 (786)
카프카 파티션과 오프셋 원리 — 세그먼트·인덱스·하이 워터마크 카프카를 쓰다 보면 오프셋이라는 숫자가 계속 나옵니다. 컨슈머 랙, 커밋 오프셋, auto.offset.reset, 하이 워터마크 모두 이 숫자를 가리킵니다. 오프셋을 "메시지 번호" 정도로만 알고 넘어가면 장애가 났을 때 길을 잃습니다. 같은 메시지가 두 번 처리되는 이유, 보존 기간이 지났는데 디스크가 안 줄어드는 이유, 파티션을 늘린 뒤 순서가 어긋나는 이유는 모두 파티션이 디스크에 어떻게 저장되는지에서 나옵니다.기준은 Apache Kafka 4.3 공식 문서와 apache/kafka 저장소의 storage 모듈 소스입니다.카프카가 풀려던 문제 — 큐가 아니라 로그전통적인 메시지 큐는 브로커가 메시지마다 상태를 들고 있습니다. 보냈는지, 확인(ack)을 받았는지, 지워도 되는지를 기록합니다. 카프카..
로컬 LLM 실행 원리 — llama.cpp·Ollama 내부 흐름 ollama run 한 줄이면 노트북에서 LLM 이 대답합니다. 그러다 "GPU 좋은 걸 샀는데 왜 글자 나오는 속도는 그대로지?", "요청마다 왜 몇 초씩 멈추지?" 같은 질문에서 막힙니다. 이 글은 llama.cpp 와 Ollama 가 GGUF 파일 하나를 받아 토큰을 내보내기까지 무엇을 하는지, 소스 코드 기준으로 한 단계씩 따라갑니다. 기준은 2026년 10월 두 저장소의 main·master 브랜치입니다.양자화 자체(INT4·GGUF 블록 구조)는 지난 양자화 글에서 다뤘습니다. 이번 글은 그다음, 그 파일이 메모리에 올라가고 계산되는 과정입니다.왜 나왔나 — 파이토치 서버의 전제가 노트북에 안 맞는다LLM 서빙의 기본형은 파이썬 + 파이토치 + CUDA GPU 입니다. 16비트 가중치가 VRA..
로컬 LLM 실행 원리 — llama.cpp·Ollama 내부 흐름 ollama run 한 줄이면 노트북에서 LLM 이 대답합니다. 그러다 "GPU 좋은 걸 샀는데 왜 글자 나오는 속도는 그대로지?", "요청마다 왜 몇 초씩 멈추지?" 같은 질문에서 막힙니다. 이 글은 llama.cpp 와 Ollama 가 GGUF 파일 하나를 받아 토큰을 내보내기까지 무엇을 하는지, 소스 코드 기준으로 한 단계씩 따라갑니다. 기준은 2026년 10월 두 저장소의 main·master 브랜치입니다.양자화 자체(INT4·GGUF 블록 구조)는 지난 양자화 글에서 다뤘습니다. 이번 글은 그다음, 그 파일이 메모리에 올라가고 계산되는 과정입니다.왜 나왔나 — 파이토치 서버의 전제가 노트북에 안 맞는다LLM 서빙의 기본형은 파이썬 + 파이토치 + CUDA GPU 입니다. 16비트 가중치가 VRA..
LLM 평가 원리 — 벤치마크·LLM-as-a-judge 믿어도 되나 새 모델이 나오면 발표 자료에는 늘 표가 붙습니다. MMLU 몇 점, GSM8K 몇 점, 아레나 몇 위. 그 숫자를 보고 "이 모델이 더 똑똑하다"고 결론 내리기는 쉽습니다. 그런데 그 숫자가 어떤 계산을 거쳐 나왔는지 아는 사람은 많지 않습니다. 같은 모델, 같은 MMLU 인데 점수가 0.637 과 0.488 로 갈린 사례도 있습니다. 이 글은 벤치마크 점수와 LLM-as-a-judge 점수가 내부에서 어떻게 만들어지는지 풀고, 어디서 믿을 만하고 어디서 무너지는지 정리합니다.왜 평가가 어려워졌나예전 NLP 평가는 비교적 단순했습니다. 정답 레이블이 있는 분류 문제라면 정확도를 재면 됩니다. 번역이라면 BLEU 처럼 정답 문장과 겹치는 n-gram 을 셉니다.LLM 은 이 틀에서 두 번 벗어납니다.첫째..
uv·pip·poetry 원리 — 의존성 해석·락파일·캐시 정리 pip install requests 한 줄은 단순해 보입니다. 속에서는 네 가지 일이 차례로 일어납니다. 인덱스에서 후보 버전을 찾고, 각 버전의 의존성 메타데이터를 읽고, 서로 맞는 버전 조합을 고르고, 휠을 받아 가상환경에 풉니다. pip·poetry·uv 는 이 네 단계를 어디서 끊고, 무엇을 파일로 남기고, 무엇을 캐시하느냐가 다릅니다. 이 글은 그 차이를 내부 흐름으로 풉니다.왜 도구가 이렇게 많아졌나파이썬 패키지 설치의 고질적인 문제는 셋입니다.첫째, 재현성입니다. requirements.txt 에 requests>=2.31 만 적으면 오늘과 다음 달의 설치 결과가 다릅니다. 하위 의존성(urllib3, idna 등)은 적지도 않았으니 더 그렇습니다. 그래서 pip freeze 로 전부 ==..
프롬프트 인젝션과 가드레일 원리 — LLM 앱 보안 공격 경로 LLM 앱에 도구를 붙이는 순간 보안 모델이 바뀝니다. 챗봇이 엉뚱한 말을 하는 건 평판 문제입니다. 메일을 보내고 파일을 읽는 에이전트가 엉뚱한 지시를 따르는 건 사고입니다. 이 글은 프롬프트 인젝션이 내부에서 어떻게 성립하는지, 가드레일이 그 흐름의 어디에 끼어드는지, 그리고 왜 "필터 하나 달면 끝"이 아닌지를 정리합니다.왜 이 문제가 생겼나 — 지시와 데이터가 같은 통로를 씁니다전통적인 보안은 코드와 데이터를 나눕니다. SQL 인젝션도 결국 "데이터 자리에 코드가 들어갔다"는 문제였고, 해법은 파라미터 바인딩이었습니다. 쿼리 구조와 값이 서로 다른 통로로 DB 에 전달되니, 값이 아무리 이상해도 쿼리 구조를 바꿀 수 없습니다.LLM 에는 그런 분리 통로가 없습니다. 시스템 프롬프트, 사용자 질문,..
CDC 원리 — Debezium 이 WAL 을 카프카로 흘리는 법 주문 서비스가 주문을 저장합니다. 검색 인덱스도 갱신해야 하고, 정산 서비스에도 알려야 하고, 캐시도 지워야 합니다. 가장 쉬운 방법은 코드에서 DB 에 쓰고 바로 카프카에도 보내는 것입니다. 이것을 이중 쓰기(dual write)라고 부릅니다. 그리고 이 방법은 언젠가 반드시 어긋납니다.DB 커밋은 성공했는데 카프카 전송 직전에 프로세스가 죽으면 이벤트가 사라집니다. 순서를 바꿔 카프카에 먼저 보내면, 이번에는 DB 롤백 뒤에 유령 이벤트가 남습니다. 두 시스템을 한 트랜잭션으로 묶을 수 없으니 생기는 문제입니다.CDC(Change Data Capture)는 질문을 바꿉니다. "애플리케이션이 이벤트를 보낸다"가 아니라 "DB 가 이미 기록한 변경 로그를 읽어서 흘린다"입니다. DB 는 원래 모든 커밋을..
추론 모델과 사고 토큰 원리 — 오래 생각하면 왜 맞히나 같은 모델에 같은 질문을 던져도 "생각 모드"를 켜면 답이 늦게 나오고, 수학·코드 문제는 더 잘 맞힙니다. OpenAI o1, DeepSeek-R1, Qwen3 의 사고 모드가 모두 이 방식입니다. 모델 가중치는 그대로인데 왜 결과가 달라질까요. 답은 "답 앞에 토큰을 더 많이 생성한다"는 아주 단순한 사실에 있습니다. 이 글은 사고 토큰이 생성·소비되는 순서, 그 습관을 강화학습으로 심는 방법, 그리고 생각 길이를 바깥에서 조절하는 기법을 원문 기준으로 풉니다.1. 왜 나왔나 — 토큰 하나에 들어가는 계산은 고정이다트랜스포머는 토큰 하나를 만들 때 정해진 층 수만큼만 계산합니다. 질문이 "2+3" 이든 올림피아드 문제든, 다음 토큰 하나에 쓰는 연산량은 같습니다. 그래서 정답을 바로 한 토큰으로 내야..

티스토리툴바