[Docker] 빌드가 갑자기 404로 실패할 때: Debian 11 bullseye EOL 대응
·
개발 (Development)/Docker
몇 달째 문제없이 돌던 Dockerfile이 어느 날부터 apt-get upgrade 단계에서 404 Not Found를 쏟아내며 빌드가 깨지기 시작했습니다. 코드도 베이스 이미지 태그도 건드린 적이 없었기 때문에 처음에는 사내 네트워크나 프록시 문제로 의심했습니다. 결론부터 말하면 원인은 Debian 11 bullseye의 지원 종료였고, 베이스 이미지를 bookworm으로 교체해서 해결했습니다.증상python:3.9-slim-bullseye 기반 이미지에서 패키지 업데이트를 수행하는 RUN 레이어가 실패했습니다.Get:1 http://deb.debian.org/debian bullseye InRelease [75.1 kB]Get:2 http://deb.debian.org/debian-security ..
[Docker] Docker Desktop(WSL2)에서 빌드 캐시가 21GB까지 쌓였을 때 정리하는 방법
·
개발 (Development)/Docker
Windows에서 Docker Desktop(WSL2 백엔드)으로 이미지를 자주 빌드하다 보니 디스크 여유 공간이 눈에 띄게 줄어들었습니다. 원인을 찾아보니 이미지나 컨테이너가 아니라 빌드 캐시가 21.4GB를 차지하고 있었습니다. 이 글에서는 빌드 캐시 사용량을 확인하고 정리한 과정을 정리합니다.증상C 드라이브 여유 공간이 계속 줄어들어 docker system df -v로 Docker의 디스크 사용량을 확인했습니다. 이미지와 컨테이너는 크지 않았는데, Build Cache 항목이 21.4GB로 비정상적으로 크게 잡혀 있었습니다.docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages ... ..
[General] Claude Code의 컨텍스트 윈도우, 대체 뭘 하는 물건인가
·
개발 (Development)/General
클로드 코드로 작업하다 보면 세션이 길어질수록 응답이 미묘하게 어긋나기 시작합니다. 분명 처음에 말해둔 규칙을 무시하거나, 방금 고친 파일을 다시 읽겠다고 하거나, 어느 순간 "Conversation compacted"라는 메시지가 뜨고 맥락이 헐거워집니다. 원인은 대부분 하나, 컨텍스트 윈도우입니다. 이 글에서는 컨텍스트 윈도우가 정확히 무엇을 담는 공간인지, 왜 차오르는지, 차기 전에 무엇을 해야 하는지를 정리합니다.증상세션이 길어지면 다음과 같은 현상이 나타납니다.대화 초반에 지정해둔 컨벤션이나 금지 사항을 뒤로 갈수록 지키지 않습니다.이미 읽었던 파일을 다시 읽습니다.터미널에는 Read auth.ts 한 줄만 찍혔는데 토큰 사용량이 훨씬 빠르게 올라갑니다.어느 순간 자동으로 압축이 실행되고, 그 ..
[Python] TensorFlow 설치 후 numpy 충돌과 venv 활성화 실패 해결기 (Windows + VS Code)
·
개발 (Development)/Python
Windows에 설치한 Python 3.10.11 전역 환경에서 pip install tensorflow를 실행했다가 numpy 버전이 바뀌면서 scipy와 충돌이 났습니다. 게다가 설치는 성공했는데 정작 주피터 노트북 셀에서는 ModuleNotFoundError가 계속 떴습니다. 결국 가상환경으로 옮기는 과정에서 PowerShell 실행 정책까지 걸려 한 번 더 막혔는데, 그 전체 과정을 정리합니다.증상VS Code에서 .ipynb 파일을 열고 아래 셀을 실행했습니다.import pandas as pdimport plotly.graph_objects as gofrom plotly.subplots import make_subplotsimport osimport jsonimport picklefrom pa..
[Docker] C드라이브 80GB를 먹어치운 덤프의 진범: 도커 헤드리스 Chromium과 /dev/shm 64MB
·
개발 (Development)/Docker
어제 이전 글에서 윈도우 C드라이브 용량이 갑자기 80GB 넘게 줄어든 원인을 추적했습니다. Docker부터 시작해 Windows 시스템 영역, AppData 순으로 범위를 좁힌 끝에 %LOCALAPPDATA%\Temp\wsl-crashes\ 안에서 _usr_lib_chromium_chromium-5.dmp(약 80GB)를 포함한 총 81.35GB의 WSL 크래시 덤프를 찾아냈고, 삭제 후 여유 공간이 103GB로 회복됐습니다.다만 "누가 Chromium을 띄웠는가"에는 답을 내지 못했습니다. Docker 안에서 Chromium이 실제로 실행 중이었는지, Playwright나 Puppeteer 같은 자동화 도구가 개입했는지 확인하지 못한 채 의문으로 남겨뒀습니다. 이번 글은 그 후속편이고, 결론부터 말하..