scrooge
-
안 만든 것이 규율이다 — 절제로 끌고 간 토이 프로젝트 회고 (Scrooge 5편)AI 엔지니어링 2026. 6. 16. 17:53
🔗 scrooge1. 도입부 — 토이 프로젝트가 망하는 진짜 이유개인 프로젝트는 보통 기능 부족으로 망하지 않는다. 하고 싶은 게 너무 많아서 망한다. "이왕 만드는 김에 이것도", "나중에 필요할 테니 미리", "더 일반적으로 추상화해두면" — 이런 충동이 쌓이면, 정작 핵심은 미완인 채로 곁가지에 짓눌려 프로젝트가 무거워진다. 혼자 쓰는 도구일수록 이 제동장치가 없다. 리뷰어도, 데드라인도, 말려줄 동료도 없으니까.scrooge는 약 2주, 57개 커밋으로 v0.6.1까지 굴러간 작은 도구다(2026-05-25 첫 커밋 ~ 06-02). 이 회고에서 말하고 싶은 건 그동안 만든 기능 목록이 아니다 — 그건 0~4화에서 충분히 다뤘다. 대신 "안 만든 것"이 어떻게 이 도구를 가볍게 유지했는가를 말하..
-
켰는데 왜 안 먹지 — 하나의 모드를 Claude Code와 Codex 두 호스트에 (Scrooge 4편)AI 엔지니어링 2026. 6. 15. 17:50
🔗 scrooge1. 도입부 — "같은 기능"이 호스트마다 다른 표면을 갖는다압축 모드 하나를 Claude Code에서 잘 돌렸다고 하자. 이걸 Codex에도 태우려 한다. 기능은 "똑같다" — 사용자 입력에 압축 지시를 끼워 LLM이 짧게 답하게 만든다. 그런데 막상 옮기려 보면, 두 호스트가 개입하는 메커니즘 자체가 다르다. 같은 기능인데 표면이 갈린다.여기에 더 음험한 문제가 겹친다. "scrooge가 켜졌다"는 말이 실은 세 가지 다른 의미로 쓰이고 있었다는 점이다. 설치됐다는 뜻인지, 지금 활성이라는 뜻인지, 이 세션에만 거는 지시라는 뜻인지. 이 셋을 섞으면 "분명 켰는데 왜 안 먹지" 같은 혼란이 반드시 생긴다.이 글에서 당신이 얻어갈 것은 두 가지다. 하나는 같은 기능을 다른 hook 메..
-
재현 안 되는 버그의 정답은 버그가 아니었다 — 비자명한 디버깅 기록 (Scrooge 3편)AI 엔지니어링 2026. 6. 14. 17:46
🔗 scrooge1. 도입부 — 가장 비싼 버그는 "버그가 아닌 버그"다디버깅의 교과서적 함정은 존재하지 않는 버그를 쫓는 것이다. 코드 어딘가가 틀렸다고 확신한 채로 가설을 세우고 검증하고 또 세우는데, 알고 보니 코드는 멀쩡했고 내 전제가 틀렸던 경우다.scrooge를 굴리며 만난 두 버그가 정확히 이 결을 가졌다. 하나는 "무응답"으로 보였지만 사실 정상 동작이었고, 다른 하나는 "압축 때문"으로 보였지만 압축은 원인이 아니었다. 둘 다 표면 증상이 엉뚱한 범인을 가리키고 있었다.이 글에서 당신이 얻어갈 것은 두 가지다. 하나는 가설을 체계적으로 배제해 "버그 아님"에 도달하는 절차, 다른 하나는 여러 원인이 겹친 현상에서 "진짜 원인"과 "가중 요인"을 분리하는 분석법이다. 둘 다 에이전트 툴링..
-
안 깎는 것이 실력이다 — 압축 도구가 거부해야 할 출력 (Scrooge 2편)AI 엔지니어링 2026. 6. 13. 17:42
🔗 scrooge1. 도입부 — 압축 도구의 진짜 위험은 "덜 압축"이 아니다압축 도구를 만들 때 본능적으로 좇는 목표는 "최대한 깎기"다. 그런데 출력 압축에는 일반적인 성능 최적화에 없는 위험이 하나 있다. 너무 잘 깎으면 사람이 다친다.예를 들어 LLM이 이런 출력을 내야 하는 상황을 생각해 보자. "이 명령은 데이터베이스를 복구 불가능하게 삭제합니다. 실행 전 백업을 확인하세요." 압축 규칙이 이걸 "DB 삭제 주의"로 깎았다고 하자. 토큰은 줄었다. 하지만 복구 불가능이라는 사실과 백업 확인이라는 행동 지시가 사라졌다. 사용자가 이 경고를 가볍게 보고 명령을 실행하면, 줄인 토큰 몇 개가 데이터 전체와 맞바꿔진다.그래서 잘 만든 압축 도구의 핵심 설계는 "어떻게 더 깎을까"가 아니라 "무엇을 ..
-
측정하지 않으면 압축이 아니다 — 출력 압축 도구의 효과를 재는 법 (Scrooge 1편)AI 엔지니어링 2026. 6. 12. 15:53
🔗 scrooge1. 도입부 — "더 압축하자"가 위험한 이유압축 도구를 며칠 굴리다 보면 자연스러운 다음 생각이 떠오른다. *"영문 출력을 좀 더 깎을 수 있지 않을까?"* 규칙을 한두 줄 더 공격적으로 쓰면 토큰이 더 줄 것 같다.이 충동은 합리적으로 보이지만, 실은 방향을 모르는 최적화다. 더 깎았을 때 토큰이 정말 줄어드는지, 줄어든다면 얼마나 줄어드는지, 그 대가로 무엇이 깨지는지 — 이걸 모르는 채로 규칙만 더 공격적으로 쓰는 건 도박이다. 압축 도구에서 "규칙을 더 공격적으로"는 곧 출력의 명료성(auto-clarity)과 안전 register를 깎는 쪽으로 압력을 주는 일이기 때문이다. 이득은 불확실한데 위험은 확실하다.그래서 scrooge 개발 중 "더 압축하자"는 plan을 의도적으로..
-
토큰은 돈이다 — 한국어를 위한 LLM 출력 압축 도구 (Scrooge 0편)AI 엔지니어링 2026. 6. 10. 13:30
🔗 scrooge1. 도입부 — 왜 이 이야기가 중요한가LLM에게 길게 답하지 말라고 시켜본 적 있을 것이다. "간결하게", "불릿으로", "200자 이내로". 이게 단순한 취향 문제가 아닌 이유는, 출력 토큰이 곧 비용이자 지연시간이기 때문이다. 같은 정보를 절반의 토큰으로 전달할 수 있다면, 그건 API 청구서와 응답 속도에 직접 꽂히는 최적화다.그래서 "LLM 출력을 압축하자"는 도구들이 등장했다. 그런데 이들을 들여다보다가 한 가지가 걸렸다. 압축의 상당 부분이 영어의 약어 관습, 심하면 한문(Classical Chinese)식 함축에 기대고 있었다. 토큰을 줄이는 영리한 트릭이지만, 그 트릭을 읽어내려면 독자가 그 언어 문화의 소양을 갖고 있어야 한다. 압축된 출력이 누군가에게는 더 읽기 어려..