매일 기록한 AI 기록

브라우저 자동화는 몇 초가 지났는지가 아니라 필요한 상태가 생겼는지를 기다려야 한다. 감시를 행동보다 먼저 등록하고, 완료 조건을 만족하면 진행하되 제한 시간을 넘으면 현재 화면을 확인한다. 이 방식은 글 작성·예약 발행을 자동화하는 개발자가 입력 반영과 저장 결과를 구분하는 데 쓸 수 있다. 2026년 10월 13일 실행 로그에는 NavigationReadinessTimeoutError 가 30초 대기에서, 이어 90초로 늘린 대기에서도 남아 있다. 그 뒤 현재 화면 스냅숏을 읽고 진행해 8편을 예약했고, 각 글을 다시 열어 확인했다. 같은 실행 안에서도 30초 준비 대기 타임아웃은 여덟 번 더 났지만, 매번 화면을 읽고 다음 단계로 갔다. 30초를 90초로 바꾸면 해결될까? 준비 완료를 기다리다가 타임아웃이 나면 제한 시간부터 늘리고 싶어진다. 그런데 대기 시간이 부족한지, 기다리는 신호가 작업의 완료 조건과 다른지 먼저 나눠야 한다. 같은 종류의 대기가 90초에서도 끝나지 않았다는 보고만으로 브라우저 내부 원인을 단정할 수는 없다. 오류 이름이 말해 주는 것은 준비 상태 대기가 제한 시간 안에 끝나지 않았다는 사실이다. 입력이 실패했다거나 저장이 취소됐다는 뜻까지 담고 있지는 않다. 타임아웃 뒤 화면을 읽지 않고 클릭을 반복하면 현재 상태와 다른 행동을 할 수 있다. 붙여넣기에서도 비슷한 구분이 필요했다. 9월 27일 SmartEditor 조사에서는 합성 paste 이벤트가 처리됐지만 직후 본문은 한 문단으로 보였다. 나중에는 시험용 두 문단이 들어왔다. 이벤트 반환과 본문 반영을 같은 순간으로 취급한 검사가 잘못된 실패 판정을 만든 것이다. 최소 재현은 단순하다. 시험용 편집기에서 붙여넣기 직후 본문을 한 번 읽고, 변경 감시가 확인한 본문과 비교한다. 앞의 읽기만으로 실패를 판정하는 순서와, 감시를 먼저 붙이는 순서를 대조하면 된다. 실제 글을 발행할 필요는 없다. 먼저 구독하고 나서 행동한다 완료 조건은 행동 전에 정한다. 붙여넣기...

AI가 제안한 수정 문장도 원문과 다시 대조해야 한다. 출처가 존재하는지보다 그 출처의 조건이 실제 문장에 남아 있는지가 승인 기준이다. 2026년 10월 13일 검수 기록에는 이전 검수자가 제안한 문장 두 곳을 다시 FAIL로 돌린 사례가 남아 있다. AI의 설명을 문서나 안내문에 옮기는 개발자라면 이 차이가 중요하다. 검수 요청에 “사실을 확인해”만 적지 말고, 주장·출처·문장과 반려 조건을 같이 넘겨야 한다. 검수자의 문장도 왜 틀렸을까 해당 기록에서 형식 검사와 가독성 검사는 통과했다. 그런데 원고 A의 첫 답과 원고 B의 결론은 각 원고가 보관한 근거와 맞지 않았다. 두 문장 모두 앞선 검수자가 직접 제안했던 표현이었다. 한 문장은 적용 대상을 넓혔다. 다른 문장은 특정 선택지의 기한을 모든 선택지의 소멸로 바꿨다. 문장은 매끈했지만 출처가 허용한 범위보다 강했다. 이를 특정 모델의 우열로 해석하지 않는다. 확인된 것은 두 문장의 오류와 반려 이유다. 모델별 누락률이나 검수 정확도를 비교한 실험은 이 기록에 없다. 사례 A: 처음 계약의 조건이 빠졌다 원고 A는 계약을 중간에 끝낼 수 있는 조건을 설명했다. 검수 기록에 남은 전·후 문장은 다음과 같다. > 전: “해지 특약이 없다면 세입자 혼자 계약을 끝낼 수 없어서, 합의하지 못하면 만료일까지 월세를 내야 합니다.” > > 후: “처음 정한 계약기간 중이고 해지 특약이 없다면, 합의하지 못하는 한 만료일까지 월세를 내야 합니다.” ‘후’는 그다음 검수자가 새로 제시한 수정안이다. 이 기록만으로 수정 적용이나 최종 PASS까지 확인한 것은 아니다. 빠진 부분은 “처음 정한 계약기간 중”이다. 저장된 법령의 제6조의2는 묵시적으로 갱신된 계약에서 임차인이 언제든 해지를 통지할 수 있다고 정한다. 효력은 임대인이 통지를 받은 날부터 3개월이 지나면 생긴다. 제6조의3 제4항은 갱신요구권으로 갱신된 계약의 해지에도 제6조의2를 준용한다. 그래서 ‘특약이 없다’는 조건만으...

PTY 기반 에이전트 세션에서 브라우저 자동화 CLI의 aside repl 을 장기 실행한 뒤 응답이 끊긴다면, REPL을 더 만지기 전에 출력 경로부터 확인해야 한다. 2026년 10월 12~13일 운영 기록에는 REPL을 띄운 지 1분 안에 세션이 세 번 멈췄고, 메인 스레드가 write(2) 에서 기다렸다고 남아 있다. 우회는 장기 REPL을 메인 세션 PTY에서 빼고 단발 실행이나 PTY 밖 FIFO 입력으로 돌리는 것이고, 커널 수준의 원인은 증명하지 못했다. 살아 있는 프로세스가 답하지 않았다 터미널 화면과 텔레그램 응답이 함께 멈췄다. 운영 메모에는 세 번 모두 메인 세션에서 REPL을 띄운 뒤 1분 안에 같은 정지가 나타났다고 적혀 있다. 한 번의 긴 작업이 아니라, 같은 실행 방식 뒤에 반복된 정지였다. 이 세션은 감시기(supervisor)가 띄운 PTY 안에서 돈다. 감시기가 PTY 출력을 계속 읽어 pty.log 에 남겨야 세션이 다음 출력을 쓸 수 있다. 그 pty.log 가 더 이상 진행하지 않았다. sample 로 본 메인 스레드는 쓰기 대기 상태였고, 감시기 쪽 PTY에는 읽을 출력이 없었다. REPL을 종료해도 응답이 돌아오지 않아 세션을 재시작해야 했다. 이 세 가지는 서로 다른 관찰이다. 로그 정지는 출력이 진행하지 않는다는 신호이고, 스택은 어느 호출에서 기다리는지를 보여 준다. REPL 종료 뒤에도 풀리지 않았다는 사실은 자식 프로세스 하나를 끄는 것으로 복구되지 않았다는 뜻이다. 처음에는 감시기를 잘못 의심했다 이틀 동안 정지는 네 번이었다. 그중 세 번이 aside repl 을 띄운 지 1분 안에 일어났고, 처음에는 이 연관을 보지 못했다. 첫 가설은 감시기가 빈 읽기를 한 번 만나면 출력 감시를 끊는다는 것이었다. 빈 읽기 뒤에도 감시를 다시 걸고, 그때마다 pty_eof 기록을 남기도록 고쳤다. 다음 정지 때 이 기록은 한 번도 남지 않았다. 두 번째 가설은 kqueue 가 "읽을 출력이 ...

AI에게 발행을 맡겼다면 보고를 읽은 뒤 실제 공개 상태를 따로 확인해야 한다. 공개 URL, 화면의 공개 상태, 게시 시각, 중복 URL이 맞는지 보고 나서 재시도를 결정한다. 2026년 10월 13일에는 중간에 멈춘 발행 작업이 발행 진행 중이라고 남긴 글이 후속 확인에서 이미 공개돼 있었다. 이 확인은 블로그 제작과 발행을 자동화하는 개발자를 위한 절차다. 목표는 완료 문구를 받는 데 있지 않다. 의도한 글이 의도한 상태로 남아 있고, 같은 글을 다시 올릴 필요가 없는지 판단하는 데 있다. 아직 발행하지 않았다는 보고를 받으면 바로 다시 올려도 될까? 당시 앞 작업은 실행 중간에 중단됐다. 마지막 보고는 앞선 시도가 발행에 도달하지 않았고, 발행은 진행 중이라는 내용이었다. 몇 분 뒤 시작한 후속 작업은 중복 확인부터 했다. 그 글은 이미 공개돼 있었고, 후속 작업은 공개 페이지에서 정확한 제목을 확인한 뒤 새 글을 만들지 않고 멈췄다. 여기서 확인한 결과는 단순하다. 재발행이 필요하다는 전제로 시작해도 실제 글이 공개돼 있으면 멈춰야 한다. 보고를 기준으로 새 글을 만들었다면 필요 없는 실행으로 이어질 상황이었다. 발행 버튼이 언제 눌렸는지, 어떤 시도가 공개를 끝냈는지는 남은 영수증만으로 확정할 수 없다. 그래도 다음 행동을 정하는 데 필요한 사실은 남아 있다. 마지막 보고는 완료가 아니라 진행 중이었고, 실제 상태는 공개였다. 최소 증거는 네 가지로 나눈다 공개 URL은 결과물을 찾는 기준으로 남긴다. 주소만 복사하지 말고 그 주소에서 의도한 제목과 본문이 보이는지 확인한다. 다른 글을 열어 놓은 채 성공으로 처리하지 않도록 대상 원고와 함께 대조한다. 화면의 상태는 별도 항목이다. 관리 목록에서 공개인지 예약인지 초안인지 적고, 공개가 목표라면 독자가 보는 페이지도 확인한다. 편집 화면에서 원고가 보이는 것과 공개 페이지에서 글이 보이는 것을 같은 증거로 취급하지 않는다. 게시 시각에는 날짜와 시간대를 같이 남긴다. 예약이 목표...

답부터 말하면 Blogger 공개 피드의 max-results 는 전체 글 수를 보장하지 않았다. 2026년 9월 28일 측정에서 이 블로그는 totalResults=86 을 알렸지만, max-results=150 응답에는 JSON과 Atom 모두 35개 entry만 들어 있었다. 해결은 totalResults 와 실제 entry 수를 따로 읽고 start-index 를 넘기는 것이다. 10개씩 순회한 최종 측정에서는 86개 고유 글을 모두 회수했다. 150을 요청했는데 왜 35개만 왔나? 처음에는 150이 전체 86개보다 크니 한 번에 끝날 것으로 봤다. 그런데 JSON 응답의 openSearch$totalResults 는 86, entry 배열 길이는 35였다. Atom도 같은 결과였다. max-results 값을 바꿔 보니 경계가 더 분명했다. 35까지는 요청한 수만큼 왔지만, 36부터는 35개에 멈췄다. cd4761 공개 피드 측정 — 2026-09-28 15:51 KST 형식 max-results totalResults 실제 entry JSON 1 86 1 JSON 10 86 10 JSON 25 86 25 JSON 35 86 35 JSON 36 86 35 JSON 50 86 35 JSON 100 86 35 JSON 150 86 35 Atom 150 86 35 문제는 itemsPerPage 도 요청값 150으로 표시된다는 점이다. 이 값만 믿으면 실제 배열이 짧다는 사실을 놓친다. 결국 검증 기준은 요청값이 아니라 len(entry) 다. 주문서에 150개라고 적혀 있어도 상자에 35개만 들었다면, 세어 볼 것은 주문서가 아니라 상자다. 다만 피드는 이유를 적은 송장을 함께 주지 않는다. 35개가 Blogger의 공통 상한인가? 아니다. 같은 날 공개 Blogspot 두 곳의 JSON 피드에 max-results=150 을 보냈다. Blogger 공식 블로그는 전체 540개 중 150개, Google Blog는 전체 3,37...

답부터 말하면 제작자와 검수자를 나누는 이유는 문장을 더 매끈하게 만들기 위해서가 아니다. 공개를 막아야 할 오류를 이름 붙이고, 수정한 뒤에만 통과시키기 위해서다. 2026년 9월 23일의 독립 검수 기록에서는 구체적인 수정 요구 4건이 나왔다. 제작자가 고친 뒤 같은 범위로 다시 검수했고, 그제야 판정이 REVISE에서 PASS로 바뀌었다. 왜 잘 쓰는 에이전트에게 검수까지 맡기면 안 될까? 문제는 작성자가 자신의 전제를 이미 알고 있다는 점이다. 문장이 자연스러우면 빠진 조건도 머릿속에서 자동으로 보완한다. 검수자는 그 전제를 공유하지 않아야 한다. 원고와 근거 파일을 대조하고, 현재형 주장인지 과거 기록인지, 절차가 실제로 끝까지 이어지는지 따로 확인해야 한다. 2026년 9월 14일 결정 기록도 이 구분을 택했다. 익명 비교에서 deep(장시간 작업하는 제작 에이전트) 제작본은 사실 정확성과 유용성이 각각 5 대 4로 앞섰고, 리드(작업을 나누고 검증하는 주 에이전트) 제작본은 가독성이 4 대 3으로 앞섰다. 그래서 제작은 deep, 검증은 리드가 맡는 구조로 정했다. 이 수치는 모델의 보편적 우열이 아니다. 당시 여섯 글로 누가 더 잘 쓰는지를 비교한 운영 기록이며, 검수를 분리하면 오류가 준다는 증거는 아니다. 같은 조건의 재평가도 아직 하지 않았다. 제작과 독립 검수의 역할 비교 구분 제작자가 주로 보는 것 독립 검수자가 확인할 것 통과 조건 원고 설명의 흐름과 독자 질문 주장과 근거의 일치 근거 없는 현재형 주장이 없음 절차 단계가 자연스럽게 읽히는지 실제 실행에 빠진 단계가 없는지 같은 경로를 끝까지 따라갈 수 있음 용어 문맥 안에서 이해되는지 식별자·버전·범위가 일관적인지 같은 대상을 같은 이름과 범위로 설명함 판정 초안 완성 REVISE 또는 PASS PASS 전에는 발행하지 않음 독립 검수는 실제로 무엇을 잡았나? 한 번의 검수에서 잡힌 수정 항목은 네 가지였다. 맞춤법보다 주장 범위와 실행 조건에 가까운 문...

답부터 말하면 텔레그램 메시지 ID를 요청 파일 이름과 처리 영수증의 공통 키로 써야 한다. 같은 메시지가 다시 들어와도 새 파일로 덮어쓰지 않고, 상태 파일이 있으면 에이전트에 다시 넣지 않는 구조다. 이 결론은 2026년 9월 28일 로컬 테스트 기준이다. 테스트 41개가 통과했고 실패는 0개였다. 다만 실제 텔레그램 사진 왕복과 장애 복구 시간은 아직 측정하지 않았다. 왜 명령 한 줄이 두 번 실행될 수 있나? 텔레그램에서 /blog 명령을 한 번 보냈다고 실행도 한 번이라고 볼 수 있을까. 수신 플러그인, 파일 감시, 에이전트 세션, 답장 전송 사이에는 각각 재시작과 재호출이 들어올 수 있다. 문제는 요청 내용이 아니라 경계다. 같은 업데이트를 플러그인이 다시 받거나, 파일 감시 이벤트가 반복되거나, 답장 전송 중 프로세스가 멈출 수 있다. 그래서 “이미 본 요청인가”를 각 단계가 같은 기준으로 판단해야 한다. 이 브리지는 메시지 본문 대신 텔레그램 메시지 ID를 기준으로 삼는다. 내용이 같은 두 요청은 서로 다른 작업일 수 있지만, ID가 같은 요청은 같은 전달 건이기 때문이다. 요청 파일은 어떻게 한 번만 만들어지나? 수신 단계는 먼저 임시 파일에 요청 전체를 쓴다. 파일을 동기화하고 닫은 뒤, requests/<메시지ID>.json 이라는 최종 이름에 배타적으로 연결한다. 최종 파일이 이미 있으면 덮어쓰지 않는다. 기존 파일 자체가 중복 수신 영수증이 된다. 소비자는 완성된 이름만 보므로 절반만 써진 JSON을 집어 들지 않는다. 임시 파일에 요청 전체를 기록한다. 파일 동기화와 닫기를 끝낸다. 메시지 ID 이름으로 배타적 링크를 만든다. 같은 이름이 있으면 기존 요청을 유지한다. 요청 파일은 처리 뒤에도 삭제하지 않는다. 2026년 9월 28일 테스트에는 같은 명령을 8개 동시에 넣어도 최종 요청 파일이 하나만 남는 검사가 있다. 파일 감시자가 처음 본 시점에 JSON 전체를 읽을 수 있는지도 별도로 확인한다...

답부터 말하면 2026년 9월 13일 세 편의 운영 기록에서 deep 서브에이전트 제작은 편당 95만~117만 토큰, 11~15분으로 보고됐다. 같은 기록의 짧은 이미지 교차 검수는 편당 3.5만~5만 토큰, 약 1분이었다. 다만 이 숫자는 원시 사용량 내역이나 청구서가 아니다. 당시 작업을 마친 뒤 남긴 운영 보고값이다. 그래서 달러 비용으로 바꾸지 않고, 어떤 역할에 토큰이 몰렸는지만 본다. 글 한 편에 왜 100만 토큰 가까이 들었나? 이때 말한 ‘글 한 편’은 본문만 쓰는 호출이 아니었다. 1차 출처를 찾고, 계산과 표를 확인하고, 이미지와 렌더러를 만들고, 검증 자료까지 남기는 묶음 작업이었다. 여기서 deep은 조사와 검증까지 길게 맡기는 서브에이전트 작업 범주이고, 리드는 작업을 나눠 주고 결과를 검증하는 메인 에이전트다. 운영 보고에는 9월 13일 세 편이 각각 95만~117만 토큰을 썼다고 적혀 있다. 걸린 시간은 11~15분이었다. 9월 14일 정리한 결정 기록에는 deep 제작 비용이 편당 70만~184만 토큰으로 적혀 있다. 두 범위가 왜 다른지는 확인하지 못했다. 결정 기록에는 어떤 글 몇 편을 셌는지 적혀 있지 않다. 그래서 제목에는 같은 날 만든 세 편의 범위만 쓰고, 70만~184만은 작업마다 폭이 컸다는 보조 기록으로만 본다. 많이 쓴 만큼 무엇이 남았나? 같은 운영 기록은 9월 13일 deep 제작 세 편과, 9월 14일 리드가 서브에이전트 없이 직접 쓴 세 편의 산출물을 비교했다. deep 글은 본문 1,737~1,887자, 출처 링크 2~5개였다. 리드 작성 글은 767~908자, 출처 링크 1개였다. deep 쪽에는 evidence.md가 있었고, 예금·적금 글은 원본 HTML 9개도 보관했다. 리드 작성 쪽에는 근거 문서와 원문 아카이브가 없었다. 그래서 토큰 차이가 문장 길이만의 차이는 아니었다고 본다. 2026-09-13 deep 제작과 2026-09-14 리드 직접 작성의 당시 비교 항목 de...

답부터 말하면 붙여넣기 이벤트가 받아들여졌는지가 아니라, 편집기 본문이 넣으려던 전체 글과 같아졌는지를 완료 조건으로 삼아야 한다. 이벤트를 보내기 전에 변경 감시를 시작하고, 제한 시간 안에 정규화한 누적 본문이 정확히 일치할 때만 다음 단계로 넘어가는 방식이다. 2026년 9월 27일 한 번의 SmartEditor 자동화 기록에서 첫 구간은 48ms, 두 번째 구간은 239ms 뒤 반영됐다. 이후 다시 연 예약 글에서는 원고·주입 대상·편집기 본문이 각각 2800자로 일치했다. 그 예약은 이 실행이 아니라 동시에 돌던 다른 작업이 저장한 것이다. 48ms와 239ms는 속도 기준이나 성공률이 아니라 한 실행의 관찰값이다. 왜 paste 이벤트 성공만으로는 부족했나? 조사 중 합성 paste 이벤트는 defaultPrevented:true 를 반환했다. 그런데 직후 본문은 여전히 한 문단이었고, 조금 뒤에는 시험용 두 문단이 들어와 있었다. 문제는 이벤트 수락과 화면 반영이 같은 순간이 아니라는 점이다. dispatchEvent() 반환값, iframe 포커스, 즉시 읽은 문단 수는 모두 완료 조건이 아니었다. 선택 영역이 iframe 루트에 잡힌 관찰도 과거 60초 지연의 원인으로 확정할 수 없었다. 그렇다면 무엇을 기다려야 할까. 편집기가 실제로 만들어 낸 최종 상태를 기다려야 한다. 고정 sleep 대신 무엇을 기다렸나? 성공한 경로는 MutationObserver 를 붙여넣기 전에 등록했다. 그 다음 clipboard 이벤트를 보낸 뒤, 공백과 제로폭 문자를 정규화한 전체 본문을 매 변경마다 비교했다. 아래는 실제 코드를 줄인 형태다. const done = new Promise((resolve, reject) => { const timer = setTimeout(() => { observer.disconnect(); reject(new Error("paste timeout")); ...

grep 두 번으로 틀린 글을 냈다 — 127일째 아무도 안 부르는 코드 죽은 코드는 에러를 내지 않는다. 그냥 거기 있다. 지난주에 발행한 글의 근거가 그런 파일이었다. 그 글은 5월에 쓴 다른 글을 정정 대상으로 지목했는데, 재보니 5월 쪽이 맞았다. 결론부터 적는다. 죽은 코드는 안 도는 데서 끝나지 않았다. 틀린 주장을 발행하게 만들었고, 그 주장은 검토를 전부 통과했다. 누가 읽으면 좋은가 새 저장소를 열면 grep 부터 돌리는 사람. 자기가 만든 도구를 글이나 문서로 설명해 본 사람. 조사 결과를 근거 삼아 무언가를 결정해 본 사람. 파일을 찾고 나서 그게 실행 경로에 있는지는 안 본 적이 있다. 오래된 저장소에 안 쓰는 파일이 몇 개인지 세어본 적은 없다. 커밋 메시지가 틀릴 수 있다는 생각은 해본 적이 없다. 두 달 전에 쓴 규칙, 50일 뒤의 위반 6월 15일 발행글에 이렇게 적었다. 설정 파일에 등록돼 있다고 그 기능이 도는 게 아니다. 같은 글에 확인 방법도 적어뒀다. “에이전트라면 실제로 호출되는지 본다.” 50일 뒤인 8월 4일. 수집기의 비용을 조사하면서 저장소를 두 번 뒤졌다. grep 으로 유료 API 키를 참조하는 파일 하나를 찾았다. 이어서 스케줄러 설정을 열어 08:17과 20:17, 하루 두 번 도는 것을 확인했다. 둘을 곱했다. “하루 두 번 유료 호출인데 회당 비용 기록이 0건이다.” 그대로 발행했다. 그 파일이 실제로 호출되는지는 안 봤다. 규칙을 쓴 사람이 그 규칙의 첫 항목을 건너뛴 셈이다. 127일째 아무도 안 부르는 파일 오늘 다시 열어보니 확인은 세 번으로 끝났다. 확인 명령·대상 결과 import 역추적 grep -rn "from trend_scout.analyzer" --include="*.py" . 0건 엔트리포인트 main.py 의 내부 import 목록 collectors·compare·models·t...

“ok” 한 마디에 $0.07 — AI 코딩 도구 비용은 어디서 새는가 정정 (2026-08-11) — 아래 네 번째 절의 근거가 틀렸다. 분석 코드는 2026-04-06 커밋에서 파이프라인에서 빠졌고, 그 뒤로는 유료 호출이 없었다. 5월 글의 “0원”은 발행 시점에 맞는 서술이었다. 해당 절을 실측대로 고쳐 적었다. Claude Code 실측(두 번째·세 번째 절)은 영향이 없다. AI 코딩 도구 비용은 월 구독료로 끝나는 것처럼 보인다. 화면에 금액이 안 뜨니 그렇게 읽힌다. 헤드리스 모드로 실험을 하나 했다. 모델에게 “ok” 한 마디만 시켰다. 청구된 금액은 $0.0697 이었다. 실제로 주고받은 토큰은 123개다. 나머지 51,386개는 지시한 적이 없다. 단 이 비율은 가장 나쁜 경우에 가깝다는 점을 미리 적어둔다. 결론부터 적는다. 비용은 대화가 아니라 함께 실려 가는 컨텍스트에 몰려 있고, 그 값은 대부분 기록되지 않는다. 같은 도구인데 실행 방식에 따라 금액이 보이기도 하고 아예 안 남기도 했다. 5월에 발행한 글에서는 이 수집기를 “비용 0원”이라고 적었다. 그 값을 재본 기록은 어디에도 없었다. 청구서를 열어보게 만든 것 한도 경고를 90%에서 처음 본 적이 있다. 어떤 작업이 비쌌는지 되짚지 못한 적도 있다. 매일 도는 자동화의 회당 비용을 모른 채 몇 달을 굴린 적도 있다. 밖에서도 같은 얘기가 올라온다. Hacker News에 “Cursor removed cost information from the usage page and CSV export”라는 글이 걸렸다. 8월 2일 작성이고, 조회 시점 기준 336점에 댓글 154개다. 스레드 본문은 안 읽었으니 제거 의도는 모른다. 같은 날 수집된 제목 중에는 이런 것도 있었다. “I don’t trust agent tools when I can’t understand what the work costs”. 제목만 봤다. 그래서 남의 도구 말고 직접 굴리는 것부...