MuRing-KB 개발기 3 (사용량 편)

지난 글에서는 쌓아둔 지식을 다시 분류하고, 검색해서 실제 작업에 쓰이는지 확인했다. 그런데 그다음 질문에서 막혔다. 그렇게 정리한 뒤 정말 작업이 나아졌는지는 어떻게 알 수 있을까.

Codex와 Claude를 쓰면서 사용량을 줄여보려고 한 적은 있었다. 중복으로 읽는 파일을 줄이고, 긴 출력을 그대로 가져오지 않도록 규칙도 적었다. 문제는 시간이 지나고 나니 그 전후를 비교할 기준이 흐릿했다는 것이다.

이번 주에 토큰을 덜 썼다고 해도, 일을 덜 했을 수 있다. 반대로 어려운 문제를 끝내느라 더 썼을 수도 있다. 숫자 하나만 보고 잘하고 있다고 말하기에는 빠진 설명이 너무 많았다.

"최적화는 했다고 하는데, 뭘 보고 좋아졌다고 하지?"

그래서 사용량을 한 번 조회하는 데서 끝내지 않기로 했다. 같은 기준으로 계속 모으고, 작업 결과와 연결하고, 바꾼 내용도 같이 남기기로 했다. 이번에는 그 기록을 블로그의 AI 활용 페이지까지 연결했다.

---

적게 썼다는 것만으로는 부족했다

모델보다 반복 작업부터 줄이기로 했다

사용량을 줄이는 방법부터 바꾸고 싶지는 않았다. 모델이나 추론 수준을 낮추면 숫자는 달라질 수 있지만, 내가 원했던 건 지금의 작업 품질을 유지하면서 불필요한 반복을 줄이는 것이었다.

그래서 이번 범위에서는 모델·추론 수준과 필요한 검증을 유지했다. 대신 같은 파일을 이유 없이 다시 읽는 일, 필요한 부분보다 훨씬 긴 도구 출력을 가져오는 일, 짧은 간격으로 상태를 계속 확인하는 일부터 줄이기로 했다.

검색에서 정확한 이름을 알고 있으면 그 이름으로 좁혀 찾고, 결과가 있는 구간만 읽도록 했다. 독립적으로 확인할 수 있는 자료는 묶어서 조회했다. 긴 실행 결과는 로컬 로그에 남기고 요약과 실패 구간을 확인하도록 했다.

물론 같은 호출이 두 번 나왔다고 전부 낭비는 아니다. 수정 전후를 비교하거나 실패를 재현하려면 다시 실행해야 한다. 필요한 재검증까지 없애서 줄어든 숫자는 내가 원한 개선이 아니었다.

전체 토큰을 한 덩어리로 보지 않았다

처음에는 주별 합계만 있으면 될 것 같았다. 그런데 입력과 출력, 캐시를 함께 보지 않으면 그 합계가 왜 달라졌는지 설명하기 어려웠다. 화면에서 보는 기준도 나눴다.

지표	이번 기록에서 보는 의미	이것만으로 판단하지 않는 것
전체 토큰	관측된 입력과 출력의 합계	생산성이나 결제 금액
캐시 제외 입력	캐시 읽기를 제외한 입력량	불필요하게 읽은 양의 확정치
출력	관측된 응답 출력량	결과물의 품질
캐시 읽기 비율	입력 중 캐시로 읽은 비중	작업을 잘 끝냈는지 여부

캐시는 입력에 포함된 값이다. 전체 토큰에 캐시를 다시 더하면 같은 양을 두 번 세게 된다. 기록 형식에 따라 특정 필드를 관측하지 못한 경우도 있어서, 값이 없다는 이유로 0을 넣지 않도록 했다.

이 수치는 로컬 요청 기록에서 확인한 사용량이다. 서비스의 청구 내역이나 구독 잔여량을 조회한 결과가 아니다. 숫자는 정확해 보여도, 무엇을 센 숫자인지부터 붙여두는 편이 낫다고 봤다.

완료 여부와 다시 한 일도 남겼다

효율을 비교하려면 사용량 옆에 결과가 있어야 했다. 어떤 프로젝트에서 어떤 작업을 했고, 끝났는지, 검증을 했는지, 수정 요청으로 다시 손댔는지를 함께 기록하도록 했다.

완료한 작업만 골라 보면 통계가 좋아 보이기 쉽다. 중간에 멈춘 작업이나 실패한 시도의 비용이 빠지기 때문이다. 그래서 완료·부분 완료·진행·중단 상태를 구분하고, 연결하지 못한 사용량도 미분류로 남겼다.

세션을 작업에 연결할 근거가 없으면 임의로 붙이지 않았다. 검증 결과를 모르면 통과로 채우지 않았고, 재작업 여부가 불분명하면 미상으로 뒀다. 빈칸을 채우는 것보다 빈칸이 왜 생겼는지 아는 쪽을 택했다.

비교 기준도 같은 프로젝트·모델·추론 수준과 유사한 작업으로 좁혔다. 그래도 작업 연결이 부족한 현재 자료에 성공률이나 효율 점수를 붙이지는 않았다. 우선은 비교할 수 있는 근거를 쌓는 단계다.

---

보고서보다 수집 기준이 먼저였다

같은 저장소에 데이터 전용 자리를 뒀다

기기는 많아야 두세 대를 생각하고 있었다. 그렇다고 매번 각 기기의 보고서를 열어서 숫자를 옮기고 싶지는 않았다. 수집 기준이 다르거나 같은 기록이 중복되면 나중에 합친 숫자부터 의심해야 한다.

별도 저장소를 만드는 대신 기존 private KB 저장소에 usage-data 브랜치를 뒀다. 그 브랜치는 일반 작업 폴더와 다른 디렉터리의 전용 worktree에서 다룬다. 저장소는 같고, 작업 중인 파일과 데이터를 모으는 파일의 자리는 다른 구조다.

일반 작업 폴더
  main: 지식 문서, 템플릿, 운영 규칙

데이터 전용 worktree
  usage-data: 기기별 수집 수치, 작업 결과

각 기기의 원본 로그
  로컬에 유지

자동 동기화가 일반 작업 폴더를 건드리지 않도록 범위를 제한했다. 자기 기기의 데이터 파일만 다루고, 잘못된 브랜치나 예상하지 못한 수정·충돌을 만나면 멈추게 했다. 데이터가 갱신됐다는 이유로 작성 중인 문서까지 같이 커밋되는 구조는 피하고 싶었다.

오프라인이면 로컬 기록을 유지한 뒤 다시 시도한다. 충돌을 강제로 덮어서 맞추지는 않는다. 데이터 자동화와 일반 코드·문서의 커밋 권한은 따로 두었다.

주의 경계와 미관측 상태를 정했다

시각은 UTC로 보존하고, 보고서의 한 주는 월요일 00시 KST를 기준으로 정했다. 기기마다 그때그때 다른 시간대 기준으로 합치면 같은 요청이 서로 다른 주에 들어갈 수 있기 때문이다.

연초도 예외가 있었다. 1월 초의 기록이 작년 월요일에 시작한 주에 속하면 작년 보고서에서 확인해야 한다. 연도 숫자만 바꿔서 자르면 주 단위 비교가 어긋날 수 있었다.

처음에는 1년마다 초기화하는 방법도 생각했다. 최종적으로는 과거 자료를 지우는 대신 조회 연도를 바꾸는 쪽으로 정리했다. 아직 충분히 쌓이지 않은 상태에서 연간 용량을 단정하지 않고, 저장량과 실행 시간을 관측하기로 했다.

상황	처리 방식
기록을 정상 수집한 주	관측된 수치 표시
아직 끝나지 않은 주	집계 중으로 표시
일부만 관측된 기간	부분 관측 표시
기록이 없는 주	사용량 0과 구분
원본 감소나 손상이 의심되는 경우	기존 정상 자료를 유지하고 정정 검토

기록이 없는 주에 막대가 없다고 해서 일을 하지 않은 것은 아니다. 기기가 꺼져 있었거나 수집 범위가 빠졌을 수도 있다. 수집기의 상태가 좋지 않은데 보기 좋은 숫자를 만드는 것부터 막아야 했다.

수집할 때마다 모델을 부르지는 않는다

정기적으로 돌아간다고 하니, 이 작업에도 계속 토큰이 필요한지가 궁금했다. 여기서는 로그를 읽고 수치를 합치는 일을 Python 프로그램이 맡는다. 수집·집계·보고서 생성 자체는 모델을 호출하지 않는다.

현재 WSL 기기에서는 정기 수집과 데이터 동기화를 활성화했다. 환경이 꺼져 있을 때 강제로 시작하는 방식은 아니다. 다른 기기의 설치와 예약 실행은 그 환경에서 따로 확인해야 한다.

HTML 보고서도 매번 새로 디자인하지 않도록 했다. 실제 데이터가 들어간 양식을 확인한 뒤 승인하고, 템플릿·렌더러·지표 버전의 지문을 남겼다. 이후 양식이 달라지면 HTML 갱신을 보류하되 JSON 수집은 계속하는 구조다.

생성된 HTML과 JSON 보고서는 다시 만들 수 있으므로 Git에서 제외했다. 대신 집계 데이터와 템플릿, 개선 이력을 남겼다. 화면을 보존하는 일과 숫자를 다시 계산할 근거를 보존하는 일을 나눈 셈이다.

---

숫자를 블로그 밖에 두지 않았다

공개 화면은 사용 비중보다 변화를 보여줬다

보고서를 만들고 나니 평소 AI를 어떻게 쓰고 관리하는지도 보여주고 싶어졌다. 그때마다 포스트를 발행하는 것과, 현재 상태를 확인할 수 있는 페이지를 두는 것은 용도가 달랐다. 그래서 공개 AI 활용 화면과 설명을 담는 글을 함께 두기로 했다.

처음에는 Codex와 Claude를 어느 정도 비중으로 썼는지 보여주는 방식이 있었다. 하지만 비중만 보면 이번 주에 두 도구의 사용량이 같이 늘었는지, 한쪽만 줄었는지는 잘 드러나지 않았다.

주별로 두 도구의 막대를 같은 눈금에서 비교하도록 바꿨다. 전체 토큰·캐시 제외 입력·출력을 전환하고, 기간을 바꾸면 같은 기준에서 다시 볼 수 있게 했다. 두 도구 중 어느 쪽이 우수한지 순위를 매기는 화면은 만들지 않았다.

숫자가 바뀔 때 그래프가 갑자기 튀는 것도 다듬었다. 다만 애니메이션보다 먼저 챙겨야 하는 것은 관측 여부와 단위였다. 기록 없음과 실제 0을 구분하지 못하면 막대가 아무리 부드럽게 움직여도 해석은 틀린다.

공개할 데이터는 서버에서 골랐다

내가 분석할 상세 자료를 그대로 공개 페이지에 내려보낼 수는 없었다. 프로젝트·모델·추론 수준·작업·기기 식별 정보는 내부에서 확인하고, 공개 화면에는 필요한 주별 합계만 제공하도록 나눴다.

원문 대화와 도구 출력, 명령 인수도 블로그로 보내지 않는다. 공개 여부를 화면에서 숨기는 것으로 끝내지 않고, 서버가 공개 응답에 넣을 필드를 직접 고르는 구조로 했다.

private KB의 예약 작업은 이미 동기화된 자료를 집계해서 블로그에 전송한다. 내보내기에 사용할 코드 버전도 고정했다. 데이터 갱신 때마다 블로그를 다시 배포하거나 모델에게 보고서를 쓰게 하지는 않는다.

전송이 실패하거나 자료가 늦게 도착하면 마지막 정상 집계를 유지한다. 다만 전송에 성공했다는 사실만으로 모든 기기의 최신 로그까지 모였다고 말할 수는 없다. 수신 시각과 실제 자료 범위를 함께 봐야 한다.

현황 화면을 블로그 관리에서 분리했다

상세 화면을 처음에는 블로그 관리 탭에 넣었다. 만들 때는 관리자가 보는 화면이라는 공통점이 먼저 보였다. 그런데 포스트·댓글·이미지를 관리하는 곳에 AI 작업 현황이 섞이니 역할이 어색했다.

그래서 별도 경로로 옮겼다. 공통 헤더의 관리 버튼은 원래 블로그 관리로 연결하고, 공개 AI 페이지 안에 관리자만 볼 수 있는 ‘AI 현황’ 버튼을 두었다. 기존 주소로 들어온 경우도 새 화면으로 이동하도록 했다.

화면에서 버튼을 숨기는 것과 접근 권한은 별개다. 실제 페이지와 API에서는 기존 관리자 검사를 유지했다. 메뉴 위치를 옮기다가 권한 검사까지 느슨해지는 일은 없어야 했다.

---

저장한 기준을 또 놓쳤다

KB에 있다는 것과 적용했다는 것은 달랐다

이번 작업에서 제일 아쉬웠던 부분은 새로운 기술이 아니었다. 이미 저장한 화면 기준을 다시 놓친 일이었다. 모바일 배치, 화면 고정과 표 내부 스크롤, 공통 컨트롤과 스크롤 디자인은 KB에 적혀 있었다.

그런데 실제 화면에서는 상단 컨트롤이 여러 줄을 차지했고, 모바일 데이터 영역이 좁아졌다. 공통 스크롤 스타일을 쓰지 않은 부분도 있었다. 문서를 읽었다고 끝내고 화면과 대조하지 않으면 같은 지적을 다시 받는다는 것을 확인했다.

"저장까지 해놨는데, 왜 같은 말을 또 하고 있지?"

이미 있는 선호를 새 후보로 한 번 더 저장할 문제는 아니었다. 이번 구현에서 어디를 빠뜨렸는지 확인하고 고쳐야 했다. 상단 배치를 줄이고, 사용량 요약은 항상 보이게 두고, 표와 편집 영역이 안에서 스크롤하도록 다시 정리했다.

짧게 적은 문장이 다른 뜻으로 읽혔다

설명문의 줄바꿈도 그랬다. ‘가능한 한 마침표 뒤에서 줄을 나눈다’고 적어둔 기준이 매 문장마다 강제로 개행하는 방식으로 구현됐다. 짧은 설명까지 여러 줄이 되니 화면이 길어졌다.

내가 원한 것은 문장마다 줄을 하나씩 주는 것이 아니었다. 공간이 있으면 이어 쓰고, 다음 문장이 들어가지 않을 때 문장 경계에서 줄을 바꾸는 방식이었다. 문장 자체가 화면보다 길면 문장 안에서 자연스럽게 줄바꿈해야 했다.

그래서 선호 문서의 표현도 교정했다. 구현을 고치고 끝내면 다음 작업에서 같은 문장을 다시 오해할 수 있기 때문이다. 표 머리글과 고정 형식 값의 정렬, 라이트·다크 양쪽 확인 기준도 함께 보완했다.

검색과 적용을 다른 기록으로 남겼다

KB가 도움이 됐는지 보려면 검색 횟수만으로는 부족했다. 검색했지만 필요한 문서를 못 찾았을 수도 있고, 읽었지만 실제 작업에는 쓰지 않았을 수도 있다.

그래서 검색 실행, 문서 선택, 실제 적용을 구분했다. 적용은 기존 지식을 어떤 작업에 사용했고 어떤 결과로 확인했는지 명시적으로 기록한다. 같은 작업을 이어서 했다는 이유로 적용 횟수가 계속 늘어나지 않도록 식별 기준도 유지했다.

이 기록도 자동으로 모든 행동을 알아내는 것은 아니다. 보고되지 않은 선택이나 연결되지 않은 작업은 미상으로 남는다. KB를 썼다는 말과 KB 덕분에 토큰이 줄었다는 말 사이에는 아직 확인해야 할 단계가 있다.

---

결과

이제 사용량을 한 번 조회하는 것에서, 같은 기준으로 기록을 이어가는 구조로 바뀌었다. 로컬 수집 데이터와 HTML 보고서, 공개 AI 페이지가 연결됐고, 내부에서는 작업 결과와 수집 상태를 따로 볼 수 있게 됐다.

이전의 질문	지금 확인할 수 있는 것
이번 주에 얼마나 썼나	같은 주 경계의 입력·캐시·출력
지난 최적화는 언제 했나	날짜와 범위를 남긴 개선 이력
기록이 비었으면 사용하지 않은 건가	미관측·부분 관측·수집 지연 상태
KB를 많이 검색했나	검색·선택·실제 적용을 구분한 기록
상세 자료를 어디까지 보여줄까	내부 분석과 공개 집계의 분리
정기 보고서가 또 다른 작업이 되지 않을까	모델 호출 없는 수집과 승인된 양식의 재생성

이번 과정에서는 집계·공개 필드 분리·권한 검사를 확인했다. 화면은 모바일과 데스크톱, 라이트와 다크에서 다시 살폈고, 격리된 로컬 DB와 인증 환경에서도 동작을 검증했다. 이 검증을 다른 운영체제의 예약 실행이나 실제 휴대폰 전체 검증으로 확대하지는 않았다.

가장 중요한 결과는 아직 ‘몇 퍼센트 절약했다’가 아니다. 무엇을 비교해야 그 말을 할 수 있는지 정했다는 것이다. 작업 연결이 충분하지 않은 자료로 효율 점수를 만들지 않았고, 기록이 없던 과거 결과를 나중에 추정해 채우지도 않았다.

앞으로는 비슷한 조건의 작업이 쌓일 때 완료 여부·검증·재작업을 함께 보려고 한다. 사용량은 줄었는데 수정 요청이 늘었다면 좋은 변화라고 보기 어렵다. 필요한 검증을 유지하면서 불필요한 반복이 줄었는지를 확인하는 것이 다음 단계다.

---

느낀점

• 숫자보다 정의가 먼저였다. 전체 토큰에 무엇이 포함되는지, 어느 시간대의 한 주인지, 기록 없음이 무엇인지 정하지 않으면 전후 비교부터 흔들렸다.
• 자동화할 범위를 좁히니 관리하기 쉬워졌다. 수집 프로그램은 수치를 모으고 데이터 전용 공간만 동기화한다. 일반 코드와 지식 문서의 변경까지 한꺼번에 맡기지 않았다.
• KB는 읽은 뒤의 확인이 필요했다. 저장된 선호가 있어도 구현과 화면을 대조하지 않으면 빠진다. 문서 수를 늘리는 것보다 적용 누락을 찾는 일이 먼저인 순간이 있었다.
• 모르는 것을 남기는 편이 나았다. 작업 연결이나 관측 범위가 부족하면 미상으로 표시했다. 근거가 없는 절감률보다 그 빈칸이 다음에 해야 할 일을 더 잘 보여줬다.

처음에는 토큰을 조금 덜 쓰는 방법을 찾으려고 했다. 끝나고 보니 사용량을 모으는 방법뿐 아니라, 결과를 해석하고 지식을 다시 적용하는 과정까지 손보게 됐다.

이제는 기록이 쌓인 뒤에도 같은 기준으로 비교하는 일이 남았다. 숫자가 좋아 보이는 날만 고르지 않고, 실패와 재작업까지 함께 남겨보려고 한다. 여기까지 읽어주신 분들께 감사드리며 이번 글을 마친다.