검색엔진이 쓰는 dense 벡터와 sparse 벡터가 각각 무엇을 잘 찾고 무엇을 놓치는지, 두 검색 결과를 순위로 합치는 RRF가 어떻게 계산되는지 설명합니다. 의류 상품 1만 개를 작은 임베딩 모델로 검색한 실측에서 모델번호 검색어의 상위 10개 안에 정답을 찾은 비율은 dense 0.8, 하이브리드 1.0이었습니다.
204줄 파일의 help 문구 한 줄을 필요한 부분만 고치게 한 경우와 Write로 전체를 다시 쓰게 한 경우를 `claude -p`로 다섯 번씩 돌리고 세션 로그를 분해했습니다. 결과 diff는 같았지만 출력 토큰 중앙값은 736 대 4,055로 약 5.5배였고, 늘어난 몫은 거의 다 Write로 끝난 응답이었습니다.
같은 조사 과제와 버그 수정 과제를 haiku, sonnet, opus에 `claude -p`로 다섯 번씩 시키고, sonnet에서는 `MAX_THINKING_TOKENS=0`으로 사고를 꺼 봤습니다. 조사 과제 비용 추정치는 haiku가 opus의 약 31분의 1, 버그 수정의 성공당 비용은 약 22분의 1이었고, 사고를 끄는 환경 변수는 효과가 없었습니다.
같은 한 줄 수정을 지시만 바꿔 `claude -p`로 조건마다 5번씩 시켰더니, 설명 생략은 마지막 보고만 줄여 출력 중앙값이 713에서 598토큰이 됐습니다. 코드 리뷰에 '파일:줄 / 문제 / 수정안' 형식을 걸면 출력은 6,227에서 1,886토큰으로 줄었고, 지적 수도 8개에서 4개로 줄었지만 빠진 것은 주로 테스트·성능·스타일 같은 부차 지적이었습니다.
codebase-memory-mcp 0.12.1을 `claude -p`에 붙여 rich 저장소 질문 4개를 3번씩 물었습니다. 정답은 두 조건 모두 12/12였지만 그래프 도구는 12번 중 2번만 쓰였고 입력 토큰 중앙값은 19% 늘었으며, 늘어난 몫의 약 68%는 요청마다 붙는 1,522토큰이었습니다.
GitNexus 1.6.12 코드 그래프를 붙인 Claude Code와 기본 도구만 쓴 Claude Code에 rich 저장소의 코드 탐색 질문 4개를 `claude -p`로 3번씩 보냈습니다. 자동 판정 정답은 12번 중 12번 대 11번이었고 Read로 연 파일은 줄었지만, 불러온 MCP 도구 설명이 요청마다 다시 실려 입력 토큰 중앙값은 50,988에서 94,520으로 늘었습니다.
graphify 0.9.95를 공식 방법대로 Claude Code에 붙이고 rich 저장소 질문 4개를 `claude -p`로 조건별 12번씩 물었습니다. 매번 graphify를 먼저 불렀고 정답 수도 같았지만, 호출과 턴이 늘어 입력 토큰 중앙값은 51,530에서 86,766으로 68% 늘었습니다.
context-mode 1.0.169를 `claude -p`에 붙여 30번 잰 결과, 도구만 따로 부르면 pytest 출력이 137,851바이트에서 5,936바이트로 줄었지만 세션에서는 잘린 결과를 받은 뒤 다시 실행해 입력 토큰이 줄지 않았고 비용 추정은 2.2배였습니다.
Headroom 0.41.0 프록시를 압축만 끈 같은 프록시와 `claude -p`로 28번 비교했습니다. 실패한 테스트 출력은 Claude Code가 이미 1만 자로 잘라 입력 중앙값이 2.0%만 줄었고, 숨은 원문 재요청까지 더한 합계는 0.8% 늘었으며, 자유 과제에서는 압축할 출력이 거의 없었습니다.
lean-ctx 3.11.4 Bash hook을 `claude -p`로 30번 잰 결과, pytest 출력은 5,524바이트에서 524바이트로 줄었지만 빠진 값을 다시 조회하느라 입력 토큰 중앙값이 29,918에서 47,252로 늘었고, 명령을 맡기면 압축이 한 번도 일어나지 않았습니다.
Token Optimizer 5.13.57 hook을 `claude -p`로 30번 잰 결과, Bash 결과는 44,482자에서 17,093자로 줄었지만 답을 일부러 잘리는 줄에 둔 질문을 다시 찾느라 입력 토큰 중앙값이 8% 늘었고, 명령을 맡기면 압축이 한 번도 일어나지 않았습니다.
응답을 짧게 만든다는 7줄짜리 CLAUDE.md, claude-token-efficient를 빈 디렉터리와 나란히 두고 Claude Code `claude -p`와 Opus 5.5로 버그 원인 질문 3개를 3번씩 돌려 출력 토큰, 단어 수, 입력 토큰, 비용 추정, 답의 품질을 스크립트로 쟀습니다. 출력 토큰은 16.9% 줄고 9개 답 모두 원인과 수정을 담았지만, 요청마다 입력이 325토큰 늘어 처음 보내는 질문의 비용 추정은 11.6% 늘었고, 한 질문에서는 오류 처리 주의가 3번 중 2번 빠졌습니다.
token-optimizer-mcp 7.6.0을 Claude Code `claude -p`에 붙이고 700줄 로그를 질문마다 다시 읽게 해 보니, 도구 정의가 요청마다 10,313토큰을 더했고 smart_read는 5번 중 1번만 불려 입력 토큰 중앙값이 1.6배가 됐으며 다시 읽기 캐시는 한 번도 쓰이지 않았습니다.
함수 단위로 코드를 찾아 주는 Token Savior MCP를 Claude Code `claude -p`에 붙여 보니, 내장 도구와 같이 두면 Claude는 주로 Read와 Grep을 쓰고 요청마다 도구 정의 3,335토큰이 더해졌습니다. Token Savior만 남기면 호출 경로 질문에서 탐색으로 쌓인 입력이 9,142에서 3,462토큰으로 줄었습니다.
같은 주문 데이터를 들여쓴 JSON, 공백 없는 JSON, TOON으로 Claude Code `claude -p`에 넣어 보니 균일한 주문 150건이 차지한 입력 토큰은 13,259, 9,203, 4,872였고 네 질문은 세 형식 모두 매번 맞혔습니다. TOON CLI 추정치와 Claude 실측이 갈린 점, 고정 부분과 프롬프트 캐시가 절감 폭을 어떻게 바꾸는지도 봅니다.
System One 결정 모델 Liquid AI d1-3B와 생성 모델 LFM2.5-1.2B에 고객 문의 200건을 질문 1·3·10개로 보내, 결정 모델은 입력 토큰과 지연이 약 10배, 생성 모델은 지연 4.35배로 느는 것, 예시 한 줄이 JSON 형식 실패를 거의 없애는 것, 확률 보정이 질문마다 다른 것을 잽니다.
태스크 100개짜리 DAG를 Airflow 3.3.2에서 돌려 동시에 running인 태스크가 몇 개에서 멈추는지, 어느 설정이 그 숫자를 막는지 확인합니다. parallelism과 max_active_tasks를 바꿔 가며 상태별 태스크 수와 scheduler 로그를 기록하고, pool과 slot으로 여러 DAG의 동시 실행 수를 묶어 봅니다.
서울 타임존으로 매일 0시에 도는 DAG에서 ds가 서울 날짜보다 하루 이르게 찍히는 이유를 Airflow 3.3.2에서 직접 확인합니다. 템플릿 날짜가 UTC로 남는 문제와, data interval timetable에서 하루 더 어긋나는 경우, in_timezone으로 바로잡는 방법을 기록합니다.
복제본 3개짜리 Cassandra 5.0 노드 세 대에서 ONE, QUORUM, ALL로 쓰고 읽으며, ONE으로 쓴 값이 성공 뒤에도 옛 값으로 읽히는 상황을 만듭니다. 쓰기 수준과 읽기 수준의 합이 복제본 수보다 클 때 옛 값 읽기가 사라지는지 확인합니다.
Cassandra 5.0에 주문을 10만, 50만, 100만 건으로 늘려 가며 파티션 키 없는 조회를 ALLOW FILTERING으로 실행하고, 결과가 2~27행이어도 읽은 행이 매번 테이블 전체와 같다는 것을 tracing으로 확인합니다. 조회 전용 테이블은 결과만큼만 읽는 것도 봅니다.