[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 같은 자동화 도구가 개입했는지 확인하지 못한 채 의문으로 남겨뒀습니다. 이번 글은 그 후속편이고, 결론부터 말하..
[Docker] Windows 디스크 용량이 갑자기 80GB 줄어든 원인 추적기: Docker를 의심했지만 범인은 WSL Crash Dump였다
·
개발 (Development)/Docker
Windows를 사용하다 보면 분명 별다른 대용량 파일을 저장한 기억이 없는데도 C 드라이브의 여유 공간이 갑자기 크게 줄어드는 경우가 있습니다.이번에는 실제로 디스크 용량이 최근 갑자기 증가한 것처럼 보여 원인을 추적해 보았습니다.처음에는 개발 환경에서 사용하고 있던 Docker를 의심했습니다. 하지만 Docker 이미지나 볼륨 자체는 생각보다 용량이 크지 않았고, 최종적으로 확인된 원인은 다음 경로에 생성된 WSL Crash Dump 파일이었습니다.C:\Users\\AppData\Local\Temp\wsl-crashes해당 폴더에는 무려 약 79GB 크기의 Chromium Dump 파일 하나와 약 2GB 크기의 추가 Dump 파일이 생성되어 있었습니다.결과적으로 약 81GB의 디스크 공간을 차지하고 ..
[Linux] 좀비 프로세스 240개, 이거 지워야 하나요
·
개발 (Development)/Linux
Docker로 스트리밍 파이프라인을 돌리는 Ubuntu 서버에 접속했더니 로그인 메시지에 좀비 프로세스가 240개 있다고 떠 있었습니다. 처음에는 당연히 정리해야 하는 줄 알고 kill 명령을 찾아봤는데, 알고 보니 좀비는 지우는 대상이 아니었습니다. 궁금해서 찾아본 김에 좀비 프로세스가 무엇이고 왜 쌓이는지 정리해두려 합니다.증상SSH 접속 직후 MOTD에 출력된 시스템 정보입니다.System load: 5.35Usage of /: 83.6% of 876.15GBMemory usage: 28%Swap usage: 97%Processes: 1227=> There are 240 zombie processes.마지막 줄이 눈에 들어왔습니다. 전체 프로세스 1227개 중 240개가 좀비였습니다...