[연재] 무엇을 세고 무엇을 안 세나 — 토큰·회차 신호등·나만의 눈금
화면에 3,475M 이라고 떠 있었습니다. 진짜는 10.1M 이었어요
지난 편에서 만든 현황판 이야기를 이어갑니다. 화면 위에 이번 주에 얼마나 썼는지가 뜨거든요. 그 숫자가 처음엔 3,475M 이었습니다. M이 백만이니까 삼십사억쯤 되는 셈이죠.
말이 안 되는 숫자였습니다. 그런데 말이 안 된다는 걸 알아채는 데도 시간이 좀 걸렸어요. 워낙 큰 숫자를 다루는 물건이라 "많이 썼나 보다" 하고 넘어갈 뻔했거든요.
공식 사용량 화면과 맞춰봤습니다. 진짜는 10.1M 이었어요. 344배쯤 부풀어 있었던 겁니다.
원인은 허무할 만큼 단순했습니다. 합계에 넣지 말아야 할 걸 넣고 있었어요.
이 편은 그 뒤로 이어진 이야기입니다. 세 배로 부풀고, 90만이 옆 칸에서 넘어오고, 평범한 편이 52배로 찍히고, 6분 사이에 2회 늘어난 게 시간당 18회로 펴지고. 전부 계산이 틀린 게 아니라 무엇을 셀지를 잘못 정한 것이었습니다.
그래서 이 편의 제목이 저렇습니다. 세는 방법 이야기가 아니라, 무엇을 셀지 고르는 이야기예요.
무엇을 합에 넣을 것인가 — 캐시를 뺐습니다
AI한테 뭘 시키면 오가는 글자 수가 기록에 남습니다. 그런데 그 기록에는 네 종류의 숫자가 있어요. 내가 보낸 것, 받은 것, 새로 저장해둔 것, 저장해둔 걸 다시 읽은 것.
마지막 게 문제였습니다.
대화가 길어지면 AI는 매번 앞의 대화 전체를 다시 읽습니다. 그래야 앞 얘기를 알고 답하니까요. 그 다시 읽는 양이 원본 합계의 99%를 차지합니다. 실제로 7일치를 두 방식으로 재봤어요.
- 다시 읽은 것까지 다 더하면 — 5,745M
- 보낸 것과 받은 것만 더하면 — 17.6M
그럼 어느 쪽이 맞느냐. 공식 사용량 화면이 같은 기간을 17.3M 이라고 하더라고요. 뒤쪽입니다.
여기서 그냥 "비슷하네" 하고 넘어가지 않았어요. 하루치를 콕 집어서 대조했습니다. 7월 25일에 특정 모델로 쓴 양이 공식 화면에서 184.6k 였는데, 우리가 센 값이 소수점까지 같았습니다. 그제야 단위를 확정했어요.
지금도 오차는 남습니다. 전체를 재면 우리는 57.60M, 공식 화면은 59.1M 이라고 해요. 그런데 남는 오차가 늘 한쪽 방향입니다 — 우리가 덜 셉니다. 다른 기기에서 쓴 것, 웹으로 쓴 것, 지워버린 기록은 셀 방법이 없거든요.
오차가 한쪽으로만 난다는 건 좋은 신호입니다. 양쪽으로 흔들리면 원인을 모르는 거고, 한쪽으로만 나면 원인을 아는 거예요. 그래서 이 오차는 안 고치고 뒀습니다. 대신 "덜 세는 쪽"이라는 걸 알고 봅니다.
같은 걸 두 번 세고 있었습니다
단위를 고치고 이틀쯤 뒤에 또 이상한 게 나왔어요. 5시간 사용량이 61.6M 이라고 떴는데, 아무리 봐도 그렇게 쓴 적이 없었습니다.
세어보니 실제는 23.7M. 딱 세 배 가까이 부풀어 있었어요.
원인은 이랬습니다. 이 화면은 기록 파일을 읽은 데까지 표시해두고 그다음부터만 읽습니다. 매번 처음부터 다 읽으면 느려지니까요. 그런데 제가 장부 파일을 한 번 지웠어요. 지우면 "어디까지 읽었나"도 같이 지워지니까 처음부터 다시 읽습니다. 여기까진 맞아요.
문제는 다른 파일에 이미 읽은 결과가 남아 있었다는 겁니다. 그래서 같은 대화가 두 번 더해졌어요. 기록 3,689개 중 2,427개가 겹쳐 있었습니다.
고친 방식이 마음에 들어서 적어둡니다. "장부를 지우면 저것도 같이 지우자"로 안 고쳤어요. 그렇게 고치면 다음에 또 다른 경로로 겹칩니다. 대신 합계를 낼 때 겹친 걸 걷어내게 했습니다. 어디까지 읽었든, 같은 대화는 한 번만 셉니다.
"이 순서로 하면 안 겹친다"는 규칙보다, "겹쳐도 한 번만 센다"는 규칙이 셉니다. 순서를 지키는 건 사람이 하는 일이고, 사람은 순서를 안 지키거든요.
어디서 자를 것인가 — 목요일 오후 1시
이 숫자들에는 주기가 있습니다. 매주 목요일 오후 1시에 통이 바뀌어요. 그때부터 새로 0에서 쌓입니다.
그런데 화면에서는 날짜로도 골라 볼 수 있게 만들었어요. 달력 두 개로 시작일과 끝날을 잡는 방식이죠. 여기서 어긋납니다. 날짜는 하루 단위인데 주기 경계는 오후 1시에 있거든요.
목요일을 통째로 더하면 그 목요일 오전에 쓴 몫이 지난 주기에서 넘어옵니다. 실제로 재보니 90만 토큰이 그렇게 넘어와 있었어요.
지금은 이렇게 생겼습니다. '지난 주기'를 눌렀을 때인데, 양 끝의 목요일 두 칸에 회색 덩어리가 얹혀 있는 게 보이시죠. 저게 잘려 나간 몫입니다.
- 왼쪽 8월 6일(목) — 오후 1시 전에 쓴 건 지난 주기 것이라 회색
- 오른쪽 8월 13일(목) — 오후 1시 후에 쓴 건 다음 주기 것이라 회색
지우지 않고 회색으로 남겨두는 게 핵심입니다. 그냥 빼버리면 "왜 목요일만 이렇게 낮지?"가 되거든요. 회색이 얹혀 있으면 "아, 여기가 경계구나"가 됩니다. 숨긴 숫자는 다음 달에 저를 또 헷갈리게 합니다.
그리고 이건 지난 편 이야기와 정확히 같은 문제였어요. 지난 편에서는 로그를 보고 "어디까지가 이번 회차인가"를 못 갈라서 신호등이 초록인데 실패였고, 질문 1건이 44건으로 부풀었습니다. 여기서는 시간을 못 갈라서 90만이 넘어왔고요.
세기 전에 자를 자리부터 정해야 합니다. 자를 자리를 안 정하면 숫자든 색이든 다 틀립니다.
이걸 알고 나니까 신호등도 다르게 보이더라고요. 회차마다 네모를 하나씩 그린 것도 결국 "어디까지가 한 번인가"를 눈에 보이게 못 박은 것이었습니다. 세는 게 먼저가 아니라 자르는 게 먼저였어요.
두 숫자가 같아야 맞는 겁니다
경계를 고쳤다고 끝이 아닙니다. 고쳤는지 확인할 방법이 있어야 하죠.
그래서 화면에 같은 값을 내는 길을 일부러 두 개 뒀습니다.
오른쪽에 주 단위로 쌓아둔 목록이 있어요. 8월 6일 주가 11.23M 입니다. 그리고 그 줄을 누르면 왼쪽 그래프가 그 주기로 맞춰지는데, 날짜별로 하나씩 더한 값도 11.23M 이 나와야 합니다.
이 둘은 만드는 방법이 완전히 달라요. 하나는 토큰이 생길 때마다 주 단위 통에 바로 넣은 값이고, 다른 하나는 날짜별로 쌓아둔 걸 화면에서 다시 더한 값입니다. 경계 처리가 틀리면 여기서 딱 어긋납니다.
이번 주기도 마찬가지예요. 7일치 합계 18.86M, 오른쪽 목록의 이번 주도 18.86M.
숫자 하나만 있으면 맞는지 틀리는지 알 수가 없습니다. 그래서 일부러 두 길로 만들었어요. 손이 좀 더 가는데, 이거 덕분에 90만이 넘어온 걸 잡았습니다. 사실 어긋난 걸 눈치챈 것도 "어? 이 둘이 왜 다르지?"였고요.
누가 쓴 건지를 갈라서 셉니다
여기서 제일 최근에 붙인 게 이겁니다.
메인 · 내가 직접 과 에이전트 · 시킨 것. 지난 주기는 9.39M 대 1.84M, 그러니까 83.6% 대 16.4% 였습니다.
이걸 왜 갈랐냐면요. 합계만 보면 줄일 방법을 못 정하기 때문입니다.
제가 앉아서 직접 쓴 양이 많으면 제 습관을 고쳐야 합니다. 시킨 일이 많으면 시키는 방식, 그러니까 넘기는 지시서를 고쳐야 하고요. 두 개는 완전히 다른 일인데 합쳐 놓으면 어느 쪽인지 알 수가 없어요.
처음엔 모델 이름으로 가르면 되는 줄 알았습니다. 비싼 모델은 내가 쓰고 싼 모델은 시킬 때 쓰니까요. 근데 아니었어요. 30일치를 재보니 시킨 일에 쓴 양의 27%가 비싼 모델이었습니다. 모델로 가르면 그 27%가 통째로 제 몫으로 잘못 붙습니다.
그래서 기록에 남는 파일 위치로 갈랐어요. 내가 직접 한 건 이쪽 파일, 시킨 건 저쪽 폴더 아래 파일. 이건 짐작이 아니라 사실이라 틀릴 수가 없습니다.
그리고 이 주에는 이렇게 떴습니다. 98.1% 대 1.9%. 지난 주기의 83.6% 대 16.4% 와 나란히 놓고 보니까 그제야 알겠더라고요. 이번 주는 제가 거의 다 직접 붙잡고 있었던 겁니다.
이 숫자를 안 갈랐으면 그냥 "18.86M 썼네"로 끝났을 거예요. 갈라 놓으니까 "이번 주엔 왜 안 넘겼지"라는 질문이 생겼습니다. 숫자가 질문을 만들면 그건 잘 고른 숫자입니다.
모델별도 나란히 둡니다. 지난 주기는 네 종류가 섞였네요.
없는 숫자는 만들지 않습니다 — 한도는 '추정'입니다
여기서 좀 곤란한 게 하나 있었어요.
한도가 얼마나 남았는지, 그러니까 "이번 주 할당량의 몇 %를 썼나"는 디스크 어디에도 안 남습니다. 설정 폴더를 전부 뒤져서 확인했어요. 그 값은 응답이 오갈 때 잠깐 붙어 왔다가 화면에 뜨고 사라집니다.
그럼 두 가지 길이 있죠.
1. 대충 그럴듯한 %를 만들어 그린다 2. %를 안 그린다
처음엔 2번을 골랐습니다. 보정점이 하나도 없으면 %를 아예 안 만들고 절대량만 띄웁니다. 지어낸 숫자를 그리느니 비워두는 게 낫다고 봤어요.
그다음에 3번을 만들었습니다. 우리가 세되, 진짜 %를 한 번 알려주면 눈금을 맞추는 방식이에요. 공식 화면에서 47%라고 뜬 걸 보고 화면의 '보정' 을 눌러 47을 넣어주면, 그때 우리가 센 값과 짝을 지어 점으로 저장합니다. 점이 늘수록 눈금이 정확해져요.
지금 그 점이 73개 쌓여 있습니다. 주간 38개, 5시간 31개, 나머지 4개.
그리고 화면의 % 위에 마우스를 올리면 "보정 73점 · 추정" 이라고 뜹니다. 이건 추정이라고 화면에 계속 적어두는 게 중요했어요. 안 적으면 저부터 이걸 공식 숫자로 착각합니다. 자기가 만든 숫자를 자기가 믿게 되는 게 제일 위험하더라고요.
38이라고 알려줬는데 화면은 40을 고집했습니다
이 눈금 맞추는 데서 제일 오래 붙잡은 게 있습니다.
7월 28일 밤이었어요. 공식 화면에 38% 라고 떠 있어서 그대로 알려줬습니다. 그런데 우리 화면은 40% 를 고집하더라고요. 방금 알려준 값인데요.
점이 열넷이나 쌓여 있었는데도 그랬습니다. AI한테 물어보니 "점이 쌓이면 회귀로 맞춰지니 괜찮다"는 식이었어요. 근데 안 맞춰졌습니다. 열넷째 점을 39.6%로 계산하고 있었어요.
여기서 제가 짚은 게 이겁니다.
"그 직선이 왜 반드시 원점을 지나야 하죠?"
설명하자면 이래요. 우리가 센 양과 진짜 %가 비례한다고 보고 직선을 하나 긋는데, 그 직선이 "0을 쓰면 0%" 를 반드시 지나게 강제해뒀던 겁니다. 그럴듯하죠. 안 쓰면 0%인 게 맞잖아요.
그런데 우리 장부가 주간 창보다 늦게 열렸습니다. 세기 시작한 시점에 이미 11%쯤 쓴 상태였어요. 그 11%를 0이라고 우기면 그 몫을 어디서 메꿔야 하는데, 직선의 기울기가 그걸 떠안습니다. 그래서 기울기가 실제보다 가팔라져요.
재봤더니 실측 17점에서 기울기가 47% 과대평가돼 있었습니다(0.0734 대 0.0498). 38이라고 알려줘도 조금만 더 쓰면 40으로 튀어 오르던 이유가 이거였어요.
원점을 안 지나도 되게 풀어주자 붙었습니다. 60M 을 더 써도 실측과 0.3%p 안에서 따라옵니다.
여기서 하나 더 나왔어요. 모델별로 가중치를 배우게 해뒀는데, 한 모델은 배울 수가 없는 상태였습니다. 어느 시점에 279M 에서 멈춘 뒤로 열일곱 점에서 값이 똑같았거든요. 값이 안 변하는 열은 "안 쓴 만큼의 기본값"과 구분이 안 됩니다. 그런데 억지로 풀면 그 몫이 움직이는 쪽으로 쏠려서, 다른 모델의 가중치가 실측의 세 배가 됐어요.
그래서 규칙을 하나 넣었습니다. 움직인 것만 배우고, 안 움직인 건 안 배운다.
이게 이 편에서 사람이 제일 크게 붙잡은 자리입니다. AI는 "점이 쌓이면 나아집니다"라고 아주 그럴듯하게 답했어요. 실제로 대부분의 경우엔 맞는 말이고요. 하지만 방금 38이라고 알려줬는데 40이 떠 있는 건, 점이 모자라서가 아니라 전제가 틀린 겁니다. 그건 화면을 보고 있는 사람만 알 수 있어요.
알려준 값보다 계산을 더 믿을 이유는 어느 창에도 없습니다.
안 세기로 한 것들
세는 이야기만 했는데, 사실 안 세기로 정한 게 더 많습니다.
첫째, 돈으로 환산하지 않습니다. 월정액이라 얼마를 쓰든 나가는 돈이 같거든요. 원화로 바꿔 띄우면 숫자가 커서 눈에는 잘 들어오는데, 그 숫자를 보고 제가 할 수 있는 게 아무것도 없습니다. 행동으로 안 이어지는 숫자는 안 그립니다.
둘째, 이 화면은 AI를 한 번도 안 부릅니다. 지난 편에 적은 것과 같은 이유예요. 3초마다 다시 그리는 화면이 매번 요약을 시키면 켜놓는 것만으로 계속 돈이 나갑니다. 그럼 필요할 때만 켜게 되고, 필요할 때만 켜는 화면은 결국 안 보게 됩니다.
셋째, 검색 순위를 여기서 직접 안 물어봅니다.
색인 탭입니다. 구글이 우리 사이트 글을 몇 장 올려뒀나를 보는 곳인데, 92장 올라갔고 2,450장이 안 걸렸습니다. 4%.
이 숫자는 자동으로 안 셉니다. 구글 쪽 관리 화면은 로그인이 있어야 열리고, 하루에 몇 번 볼 화면도 아니거든요. 손으로 열어본 결과를 파일에 적어두면 이 탭이 읽어서 그립니다. 그래서 여기도 드는 비용이 0이에요.
대신 규칙을 하나 박아뒀습니다. 카드마다 "무엇이 / 왜 문제 / 어떻게" 세 줄을 반드시 쓴다. 문제만 적고 왜 문제인지 안 적으면 다음 달에 같은 조사를 처음부터 다시 하게 되더라고요. 실제로 한 번 그랬습니다.
그리고 이 칸이 '안 세기'의 좋은 예입니다. 안 걸린 2,450장을 이유별로 갈라놨는데, 맨 위 869장은 제가 일부러 뺀 것이에요. 카드 낱개 페이지처럼 검색에 올라갈 필요가 없는 것들입니다.
저걸 안 갈랐으면 "2,450장이나 안 걸렸다"가 됩니다. 갈라놓으니 "진짜 문제는 그 아래 1,329장"이 되고요. 같은 자료인데 읽히는 게 전혀 다릅니다.
견줄 수 없는 걸 견주면 전부 거짓말이 됩니다
탭을 하나 더 볼게요. 올린 쇼츠가 얼마나 돌았나를 보는 곳입니다.
여기서 제일 먼저 막힌 게 "어느 편이 잘 됐나"를 어떻게 재느냐였습니다.
당연히 조회수를 나란히 놓으면 될 것 같잖아요. 안 됩니다. 어제 올린 편과 아까 올린 편을 나란히 놓으면 오래된 쪽이 무조건 이깁니다. 시간을 더 살았으니까요.
그럼 시간으로 나눠서 '시간당'으로 보면 될까요. 이것도 안 됩니다. 쇼츠는 올린 직후에 조회가 몰려요. 그래서 시간당으로 펴면 어린 쪽이 무조건 이깁니다. 방금 올린 편이 언제나 1등이 됩니다.
두 방법 다 답이 정해져 있는 자였어요. 무엇을 재든 같은 답이 나오는 자는 자가 아니라 그냥 눈금 없는 막대입니다.
그래서 이렇게 바꿨습니다. 올린 지 같은 시간일 때끼리만 견줍니다. 6시간·24시간·48시간 세 시점을 정해두고, 모든 편의 그 시점 값을 꺼내 놓는 거예요.
지금 보면 6시간일 때 스위치 리뷰가 301회(68편), 연재 소개가 439회(47편)입니다. 48시간일 때는 391회 대 552회고요. 어느 시점에서 봐도 연재 쪽이 앞섭니다. 이건 비교한 시간이 같으니까 할 수 있는 말이에요.
2,000회짜리가 1등인데, 그게 딱 한 편입니다
이건 몇 시에 올린 편이 잘 도나를 본 겁니다. 48시간 시점 기준이고요.
14시가 2,000회로 압도적입니다. 나머지는 다 400회 안팎인데요.
그런데 옆에 작게 붙은 숫자를 보시면 1편입니다. 딱 한 편이에요. 12시는 704회인데 22편이고, 18시는 443회인데 23편입니다.
저 '1편'을 안 적어두면 저는 지금쯤 모든 쇼츠를 오후 2시에 올리고 있을 겁니다.
그래서 여기 있는 평균에는 전부 몇 편으로 낸 평균인지를 붙여 놨어요. 자리를 먹고 좀 지저분해지는데, 이거 없으면 평균이 거짓말을 합니다. 8시(231회)도 1편, 17시(416회)도 1편, 22시(185회)도 1편이에요. 저 셋은 아직 아무 말도 못 하는 숫자입니다.
평균은 몇 개를 평균했는지를 같이 적어야 숫자가 됩니다. 안 그러면 그냥 인상이에요.
52배로 찍혔는데 평범한 편이었습니다
편별 표입니다. 여기 '다른 편' 이라는 칸이 있어요. 같은 갈래의 다른 편들이 이 편과 똑같은 시간을 살았을 때 몇 회였나, 그 가운뎃값입니다.
맨 위 편을 보시면 올린 지 4.5시간에 조회 0회인데, 다른 편들은 같은 4.5시간일 때 228회였습니다(47편 기준). 빨간 0이 그래서 빨갛습니다.
처음엔 이걸 배수로 접어서 보여줬어요. "다른 편의 3.2배" 같은 식으로요. 한 칸에 들어가고 읽기도 편하니까요.
그런데 죽은 편이 많은 무리에서 사고가 났습니다. 안 도는 편이 많으면 가운뎃값이 확 내려가요. 실제로 8회까지 내려간 적이 있습니다. 그러면 평범한 415회짜리 한 편이 52배로 찍힙니다.
52배라고 뜨면 사람은 "대박 났다"고 읽습니다. 실제로는 그냥 보통 편이었고, 대박은커녕 주변이 다 죽어 있었다는 뜻이었어요. 나눗셈은 맞는데 읽히는 뜻이 정반대입니다.
그래서 접는 걸 그만뒀습니다. 415와 8을 그냥 나란히 놓습니다. 두 숫자가 나란히 있으면 사람이 알아서 읽더라고요. "얘가 잘한 게 아니라 쟤들이 안 됐구나" 하고요.
한 숫자로 접으면 판단까지 접혀 들어갑니다. 그 판단이 틀리면 되돌릴 방법이 없어요.
6분 사이에 2회 늘어난 걸 시간당으로 펴면 18회가 됩니다
표에 '시간당' 칸도 있습니다. 지금 얼마나 도는 중인가를 보려고 넣은 건데, 이것도 한 번 사고가 났어요.
이 값은 최근 두 기록의 차이를 시간으로 나눠서 냅니다. 그런데 기록을 매시간 남기다 보면 가끔 6분 간격으로 두 개가 찍혀요. 그 6분 사이에 조회가 2회 늘었으면 시간당으로 펴서 18회가 됩니다.
조회 9회짜리 죽은 편이 제일 잘 도는 편으로 화면 맨 위에 뜬 겁니다.
고친 건 간단해요. 30분은 넘게 벌어진 기록끼리만 견줍니다. 그만큼 벌어진 짝이 없으면 아예 · 으로 비워두고요.
여기서도 같은 결론이 나옵니다. 모르면 비워둡니다. 억지로 채운 숫자는 없는 것보다 나쁩니다. 없으면 의심이라도 하는데 숫자가 있으면 그냥 읽고 넘어가거든요.
한 가지 더 정해둔 게 있어요. 이 숫자들은 화면에서 만들지 않습니다. 매시간 도는 별도의 프로그램이 계산해서 파일에 적어두고, 이 탭은 그걸 그리기만 해요. 판단하는 자리를 두 곳에 두면 반드시 어긋납니다. 지난 편에서 같은 규칙이 두 군데 적혀 있어서 한 곳만 고쳤던 일을 겪고 나서 정한 규칙입니다.
43회 중 23회가 테스트 파일 한 곳에서 나왔습니다
마지막으로 세는 것에 대해 제일 많이 배운 자리입니다.
현황판에는 도구들이 어떤 구조로 짜였는지 분류해서 보여주는 탭이 있어요. 예를 들면 "이 도구는 중앙이 일을 쪼개 맡기고 결과를 합치는 방식, 근거 43회" 같은 식입니다.
처음엔 이 목록만 있었습니다. 그런데 43회가 어디서 나온 건지 모르면 맞는지 틀리는지 따질 수가 없더라고요. 그럴듯한 분류가 붙어 있으니 그냥 믿게 됩니다.
그래서 카드를 누르면 근거가 파일 단위까지 펼쳐지게 만들었어요.
펼쳐보니 이렇습니다. 43회 중 23회가 test_orchestrator.py 한 파일에서 나왔어요. 주황색으로 칠해진 게 테스트 파일입니다.
테스트 파일은 구조를 설명하는 말이 실제 코드보다 훨씬 많이 나옵니다. "이 함수가 여러 일꾼에게 나눠 맡기는지 확인한다" 같은 문장이 잔뜩 들어 있으니까요. 그러니까 근거의 절반 이상이 테스트에서 나왔다면 그 판정은 의심할 만한 겁니다.
그래서 테스트 파일은 주황으로 칠하고, 그 아래에 한 줄을 박아뒀어요.
주황은 테스트 파일입니다. 거기서 대부분이 나왔으면 판정을 의심할 만합니다.
초록으로 칠한 건 AI를 실제로 부르는 파일이에요. 이게 있으면 도구고 없으면 그냥 프로그램입니다. 지금 제가 만든 것 중 55개는 AI를 한 번도 안 부릅니다. 이름만 봐서는 절대 모를 일이고요.
숫자를 내놓을 거면 그 숫자를 열어볼 수 있어야 합니다. 못 열면 그건 숫자가 아니라 주장이에요.
세는 일은 사람도 AI도 말고 프로그램한테 시킵니다
이 편을 관통하는 게 하나 있습니다. 개수를 세는 일에는 AI를 안 씁니다.
몇 개인지, 겹친 게 있는지, 빠진 게 있는지 — 이런 건 짧은 프로그램이 정확하고 공짜입니다. AI한테 시키면 그럴듯한 숫자를 아주 자신 있게 내놓는데, 그게 맞는지 확인하려면 결국 세어봐야 해요. 그럼 두 번 하는 겁니다.
실제로 한 번 겪었습니다. 일곱 건을 처리하게 시켰더니 "다섯 건 성공"이라는 보고가 왔는데, 세어보니 하나는 두 번 적혀 있고 하나는 아예 빠져 있었어요. 그 이야기는 다음 편에서 제대로 하겠습니다.
이 화면의 모든 숫자는 그래서 파일 개수를 세거나, 줄 수를 세거나, 목록 길이를 재는 게 전부입니다. 요약도 안 시킵니다. 기록에서 그대로 뽑아 이어 붙여요. 문장이 매끄럽진 않은데 틀릴 일이 없습니다.
눈금을 빌리면 남의 질문에 답하게 됩니다
정리하겠습니다.
이 화면을 만들면서 제일 많이 한 일은 계산이 아니었어요. 무엇을 셀지 고르는 일이었습니다. 그리고 그 선택 하나하나가 결국 "내가 무엇을 중요하게 볼 것인가"였더라고요.
- 다시 읽은 양을 안 넣기로 한 것 → 나는 대화 길이가 아니라 실제로 시킨 일의 양을 보고 싶다
- 메인과 에이전트를 가른 것 → 나는 총량이 아니라 "어느 쪽을 고쳐야 하나"를 보고 싶다
- 배수로 안 접기로 한 것 → 나는 결론이 아니라 판단할 재료를 보고 싶다
- 몇 편의 평균인지 같이 적기로 한 것 → 나는 인상이 아니라 믿을 만한지를 보고 싶다
- 못 잰 건 비워두기로 한 것 → 나는 깔끔한 화면보다 정직한 화면을 보고 싶다
처음엔 남들이 쓰는 지표를 그대로 가져오려고 했어요. 조회수, 시간당, 전주 대비 몇 배. 다 이미 있는 것들이니까요.
그런데 그것들은 다른 사람의 질문에 답하려고 만들어진 자였습니다. 하루에 수천 편이 올라가는 곳에서 편끼리 줄 세우려고 만든 눈금은, 하루 다섯 편 올리는 저한테는 아무것도 안 알려줍니다. 52배가 그래서 나왔어요.
눈금을 남의 것에서 빌리면 남의 질문에 답하게 됩니다.
그래서 이 편에서 사람이 남은 자리는 딱 하나로 좁혀집니다. 무엇을 셀지 정하는 자리.
AI는 세는 걸 아주 잘합니다. 자르는 규칙만 정해주면 정확하게 잘라서 세줘요. 원점을 지나는 직선도, 시간당 조회수도, 가운뎃값 대비 배수도 전부 훌륭하게 계산해줍니다. 틀린 적이 거의 없었어요.
틀린 건 늘 무엇을 세라고 시켰는지 쪽이었습니다. 캐시를 합에 넣으라고 한 것도, 목요일을 통째로 더하라고 한 것도, 배수로 접으라고 한 것도 다 사람이 정한 겁니다.
그래서 관제라는 게 결국 내 눈금을 만드는 일이더라고요. 화면을 만드는 일이 아니라요.
다음 편은 조금 불편한 이야기입니다. "다 됐습니다"라는 보고를 받고 나서, 무엇을 보고 됐다고 할 것인가. 세어봤더니 하나는 두 번 적혀 있고 하나는 빠져 있었던 그날 이야기예요.
#현황판 #관제화면 #대시보드 #토큰사용량 #토큰계산 #지표설계 #데이터시각화 #평균의함정 #표본수 #중앙값 #통계읽기 #모니터링 #관측성 #로그분석 #검색색인 #서치콘솔 #유튜브쇼츠분석 #조회수분석 #AB비교 #기준선 #캐시토큰 #선형회귀 #보정 #파이썬 #표준라이브러리만 #AI코딩 #클로드코드 #개발자아닌사람 #1인개발 #휴먼인더루프