APScheduler 예약이 재시작마다 날아갈 때, DB를 진실의 원천으로

이 글에서는 APScheduler 예약이 재시작마다 날아가는 근본 원인과, 잡스토어를 바꾸는 것만으로는 왜 부족한지, 그리고 DB를 진실의 원천(source of truth)으로 두는 틱 루프 구조로 이 문제를 근본적으로 우회하는 방법을 확인하실 수 있습니다. 핵심 답부터 말씀드리면, APScheduler의 잡 저장소를 영속화하는 것보다 “예약 정보는 DB에만 두고, APScheduler는 주기적으로 DB를 훑는 틱(tick) 하나만 담당하게” 구조를 바꾸는 편이 재시작에 훨씬 … Read more

Hugging Face 모델이 매번 다시 다운로드되는 이유와 캐시·오프라인 설정

이 글에서는 허깅페이스 모델 캐시가 실제로 어디에 저장되는지 확인하는 방법과, 캐시 경로를 원하는 위치로 고정하고 오프라인 모드까지 켜는 절차를 순서대로 정리합니다. 핵심만 먼저 말씀드리면, Hugging Face 모델이 매번 다시 다운로드되는 것은 캐시가 진짜로 사라져서가 아니라 실행할 때마다 캐시 경로(HF_HOME)가 다르게 잡히거나, 캐시가 아예 없는 새 컨테이너·세션에서 스크립트가 돌아가기 때문인 경우가 대부분입니다. 캐시 경로를 명시적으로 고정하고 … Read more

Docker에서 GPU가 안 잡힐 때, 점검 순서대로 풀어보기

엔비디아 드라이버만 설치하면 Docker 컨테이너에서도 GPU가 저절로 잡힌다고 생각하는 분들이 의외로 많습니다. 실제로는 호스트 드라이버, nvidia-container-toolkit, Docker 런타임 설정이라는 세 개의 층이 각각 맞물려야 컨테이너 안에서 GPU가 인식됩니다. Docker에서 GPU가 안 잡히는 문제는 대부분 이 세 층 중 어디가 빠졌는지 순서대로 확인하면 원인을 좁힐 수 있어요. 이 글에서는 실무에서 흔히 놓치는 지점을 순서대로, 그리고 어떤 … Read more

uv로 파이썬 의존성 관리하기 — pip·poetry에서 뭐가 달라지나

pip이나 poetry로 프로젝트를 돌리다가 “uv로 파이썬 의존성 관리하기”가 요즘 자주 언급돼서 검색해 보셨다면, 결론부터 말씀드릴게요. uv는 pip·pip-tools·venv·pyenv·poetry가 각각 하던 일을 명령어 하나로 묶은 도구이고, 실제로 옮길 때 달라지는 건 속도보다 “파일 구조”와 “명령어 습관” 쪽입니다. requirements.txt나 poetry.lock에 익숙하다면 처음 며칠은 명령어를 새로 외워야 하지만, 프로젝트 구조 자체는 pyproject.toml 하나로 단순해집니다. 이 글은 uv를 처음 써보는 … Read more

pandas read_csv가 파일 크기의 3배를 먹는 이유와 해결법

pandas read_csv가 파일 크기의 3배씩 메모리를 먹는 이유가 궁금해서 검색하셨다면, 원인은 크게 두 가지입니다. 문자열 컬럼이 object dtype으로 저장되면서 파이썬 객체 오버헤드가 그대로 붙고, 숫자 컬럼도 실제 필요한 범위보다 훨씬 큰 int64·float64로 자동 지정되기 때문입니다. dtype을 미리 지정하고 필요하면 chunksize로 나눠 읽으면 이 부풀림을 상당 부분 줄일 수 있습니다. 이 글은 pandas 2.x, CPython 3.10 … Read more

LLM 배치 API로 비용 절반 줄이기, 되는 작업과 안 되는 작업 구분법

매달 초 API 청구서를 열어보고 생각보다 커진 금액에 한숨 쉬어보신 적 있으신가요? 실시간 응답이 필요 없는 작업이라면 LLM 배치 API로 비용을 절반까지 줄이는 방법이 이미 마련돼 있습니다. 다만 모든 작업에 무작정 적용할 수 있는 건 아니어서, 어떤 작업이 되고 어떤 작업이 안 되는지부터 구분하는 게 순서입니다. 배치 API가 정확히 뭘 절반으로 깎아주는 걸까요? OpenAI와 Anthropic이 … Read more

파인튜닝, RAG, 프롬프트 엔지니어링 — 어디서 갈리나

프롬프트 엔지니어링으로 안 되면 RAG, RAG로도 안 되면 파인튜닝이라는 순서가 정답은 아닙니다. 세 가지는 애초에 해결하는 문제가 다르기 때문에, 비용과 유지보수 부담을 기준으로 먼저 갈라 보는 편이 실무에서는 더 빠릅니다. 이 글에서는 파인튜닝을 중심에 놓고 RAG, 프롬프트 엔지니어링과 어떤 지점에서 선택이 갈리는지 구체적인 조건으로 정리해 보겠습니다. 세 기술이 각각 바꾸는 대상이 다릅니다 프롬프트 엔지니어링은 모델의 … Read more

벡터 DB를 pgvector로 버틸 수 있는 규모, 어디까지일까요

벡터 DB를 pgvector로 시작한 프로젝트라면 언젠가 이런 순간을 만납니다. CREATE INDEX 한 번에 걸리는 시간이 분 단위에서 시간 단위로 넘어가고, 쿼리 응답이 예전 같지 않다고 느껴지는 시점입니다. 이 글은 pgvector가 실제로 버틸 수 있는 규모의 조건과, 전용 벡터 DB로 옮겨야 한다는 신호를 구체적인 설정값과 함께 정리합니다. 결론부터 말하면 pgvector는 행 수보다 차원 수·인덱스 종류·쓰기 패턴 … Read more

한국어 임베딩 모델 고르는 기준, 차원 수·컨텍스트 길이·라이선스로 좁히는 법

임베딩 모델은 차원 수가 높을수록 무조건 성능이 좋다고 생각하시는 분들이 많은데, 실제로는 그렇지 않습니다. 한국어 임베딩 모델을 고르는 기준은 차원 수 하나가 아니라 차원 수, 컨텍스트 길이, 라이선스라는 세 가지 조건을 순서대로 확인하는 것이고, 이 세 가지만 체크해도 후보군을 몇 개 안 되는 수준으로 좁힐 수 있습니다. 아래에서 각 기준이 실무에서 어떤 차이를 만드는지 실제 … Read more

RAG 청킹 전략 비교, 고정 길이·문장 경계·시맨틱 분할이 갈리는 지점

결론부터 말씀드리면, RAG 청킹 전략은 문서 성격에 따라 답이 갈립니다. 정형화된 매뉴얼이나 로그성 텍스트는 고정 길이 분할로도 충분하지만, 논리 흐름이 중요한 기술 문서나 법률·의료 텍스트는 문장 경계나 시맨틱 분할을 써야 검색 품질이 눈에 띄게 달라집니다. 이 글에서는 세 방식이 실제로 어떤 조건에서 갈리는지, 그리고 각각의 트레이드오프를 코드와 함께 짚어보겠습니다. RAG 파이프라인을 운영해본 분이라면 임베딩 모델이나 … Read more