← gw

25_토큰절약법

근거: CONSTITUTION.cst.md 소관: 클로드 세션(들)이 작업 중 토큰(비용)을 불필요하게 소모하지 않도록 하는 전 영역 공통 원칙 — 이미 개별 메모리로 흩어져 확립돼있던 원칙들을 한 법으로 통합·성문화한다.

제정 배경: 이 세션에서 이미 여러 차례 독립적으로 확립된 토큰절약 원칙 (조사위임, raker 표준화, 최소확인 등)이 메모리 파일에 산발적으로만 남아있어 법적 구속력 있는 원칙으로 통합할 필요가 있었음. 또한 2026-09-22 골든이미지 클론 작업 중 dd status=progress류 장시간 명령의 verbose 출력이 대화 컨텍스트를 크게 잠식하는 문제를 실측 — 이를 계기로 장시간 작업의 출력 관리 원칙도 함께 제정한다.

제1조 (조사 위임 원칙)

① 새로운 소스·정보를 탐색적으로 찾는 작업(WebSearch 반복 등)은 비용이 비싼 이 세션이 직접 하지 않고, ChatGPT/Gemini 등 외부 LLM에 위임한다 ([[feedback_research_delegation_to_other_llms]]).

② 이 세션의 역할은 raker 실제 제작·수집·문서화·인프라 운영에 한정한다 — 탐색 자체가 목적인 리서치 태스크는 위임 대상이다.

③ 조사보고서에 의문이 생기면 SSH/curl로 직접 재검증하기보다, 먼저 위임받은 LLM에 재질문한다(대개 훨씬 빠르고 저렴함, [[feedback_verify_via_gemini_not_self]]).

제2조 (표준 템플릿 재사용 원칙)

① raker 등 반복 개발되는 프로그램은 매번 자유형식으로 새로 설계하지 않고, 검증된 표준 템플릿(공용 라이브러리 패턴)을 확정해두고 그 안에서만 구현한다 — 신규 설계에 드는 토큰을 표준화로 절감한다 ([[project_brain9_pc_verified_raker_bundle]] 토큰절약 전략 참고).

② 신규 raker 착수 전에는 타 세션·기존 폴더에 이미 있는지 먼저 확인해서 중복 발굴 자체를 막는다([[feedback_check_before_collect_dedup_gate]]).

제3조 (최소 확인 원칙)

① 일상적·가역적 작업은 매번 승인을 구하지 않고 진행한다 — 확인은 비용이 크거나 안전에 직결되는 사안에만 요청한다([[feedback_minimal_confirmation]]).

② 승인 요청 한 번에 여러 선택지를 몰아서 묻지 않고, 정말 갈림길인 지점만 간결하게 확인한다.

제4조 (장시간 작업 출력 관리 원칙 — 2026-09-22 신설)

① dd, rsync, 대량 find 등 장시간 실행되는 명령은 백그라운드로 돌리고, 완료 알림을 받은 뒤 필요한 부분만 결과를 조회한다 — 실행 중 진행률을 실시간으로 계속 들여다보지 않는다.

② 진행률 표시(status=progress, --progress 등) 옵션은 긴 로그를 대화 컨텍스트에 그대로 쌓이게 만들어 토큰을 낭비시킨다 — 로그 파일로 리다이렉트하고, 조회할 때도 tail -c로 필요한 끝부분만 잘라서 본다(전체 파일을 한번에 읽지 않는다).

③ 반복적으로 같은 배경작업 상태를 확인해야 할 때는 폴링(sleep 후 재확인을 반복)하지 않고, 백그라운드 알림을 기다린다 — 시스템이 완료 시 자동으로 알려준다.

제5조 (조사-실행 분리 원칙)

이미 조사·검증이 끝난 사안을 다시 조사하지 않는다 — 메모리·그룹웨어 문서에 이미 결론이 있으면 그것부터 조회하고([[feedback_lookup_order_groupware_first]]), 재조사가 꼭 필요한 경우(정보가 오래됐거나 상태가 바뀌었을 가능성이 명확한 경우)에만 재확인한다.

제6조 (프로그래밍-실행 분리 원칙 — 2026-09-22 신설)

① 이 세션(들)의 본업은 프로그래밍(코드·스크립트·자동화 작성)이지, 실제 실행(장시간 반복 작업의 수동 수행)이 아니다. raker·동기화·모니터링 등 반복적으로 돌려야 하는 작업은 스크립트로 작성해서 함대 기기들(x1, linux3, lin2, sam1 등)에 배포하고, 그 기기들이 자체적으로 실행하게 한다.

② 이 세션이 SSH로 직접 붙어서 명령을 하나하나 수동 실행·감시하는 방식은 일회성 설정·디버깅·검증 단계에서만 쓰고, 정상궤도에 오르면 반드시 해당 기기의 자체 스케줄(cron, watchdog, systemd 등)로 넘긴다 — 이 세션이 계속 붙어서 진행상황을 지켜보는 구조로 남겨두지 않는다.

③ 이 원칙은 제1조(조사 위임)·제5조(조사-실행 분리)의 연장선이다 — "조사는 외부 LLM에, 반복실행은 함대 기기에, 이 세션은 그 둘을 잇는 프로그래밍만"이

④ 최종 목표(지향점): 함대 기기 자체 스케줄러(cron/watchdog/systemd)로 넘어간 반복작업은 클로드 세션과 무관하게 그 기기의 CPU만으로 영구히 계속 돌아간다 — 이 상태에서는 실제 작업량이 아무리 늘어나도 추가되는 클로드 토큰 비용이 0이다. 즉 "코드를 잘 짜서 한 번 배포해두면, 이후 실제 수집·동기화·모니터링 물량 자체는 토큰 소모와 완전히 분리된다"는 게 이 법이 지향하는 이상적 종착점이다 — 이 세션이 매번 지켜보고 대신 실행해주는 구조가 아니라, 기기들이 스스로 알아서 돌아가는 구조를 목표로 모든 자동화를 설계한다.

제7조 (압축 의존도 차등화 — 2026-09-22 신설)

① 컨텍스트 압축(compaction)은 플랫폼이 자동으로 수행하는 메커니즘이라 세션이 압축 자체를 막거나 스킵할 수는 없다(20_세션대화압축법.law.md 제4조). 본 조는 압축을 막으라는 게 아니라, 압축 결과물에 대한 의존도를 시점에 따라 차등화하라는 원칙이다.

② 오래된 구간(이미 결론이 나서 문서화까지 끝난 부분)은 느슨하게 압축되어도 무방하다 — 그 내용의 정확한 복구는 압축요약이 아니라 법률(_wiki/_laws/)·업무매뉴얼·그룹웨어의 최신 내용이 담당한다. 압축요약이 그 구간을 거칠게 뭉개더라도, 문서를 다시 확인하면 복구된다.

③ 최근 구간(아직 문서화가 안 됐거나 진행 중인 작업)은 압축 시 문맥이 유지되도록 상세하게 보존한다 — 20_세션대화압축법.law.md 제2조④(최근 구간은 압축 강도를 낮춰 상세히 남긴다)와 정확히 같은 방향이며, 본 조는 그 이유를 "오래된 구간은 문서가 대신 커버하기 때문"이라는 근거로 보강한다.

④ 결과적으로: 압축의 실제 부담(의존도)은 오래될수록 낮아지고 최근일수록 높아진다 — 오래된 구간의 낮은 의존도는 법률/업무매뉴얼/그룹웨어가 보완하고, 최근 구간은 압축 자체가 신경 써서 보존한다. 이 비대칭 구조를 평소 문서화(제1~6조)로 뒷받침하는 것이 이 법 전체의 완결점이다.

제8조 (압축 시점 잔여토큰 스냅샷 기록 — 2026-09-22 신설)

① 대화 내용과 압축 자체의 비용을 항목별로 정확히 분리 계량하는 것은 세션의 접근권한 밖이다 — 압축은 세션이 직접 호출하고 결과를 받는 도구가 아니라 플랫폼이 처리하는 불투명한 메커니즘이라, 압축 1회당 비용을 청구내역처럼 받아볼 수 없다.

② 대신 압축이 일어난 것으로 보이는 시점마다, 그때 주어지는 잔여토큰 수치(<total_tokens> 등 시스템이 알려주는 값)를 스냅샷으로 기록한다 — 이전 스냅샷과 비교해 대략적인 소모 추이를 파악하는 차선책으로 삼는다.

③ 이 스냅샷은 "대화 내용 비용"과 "압축 자체 비용"이 섞인 값이라는 한계를 명시하고 보고한다 — 분리된 정밀값인 것처럼 과장하지 않는다.