전체 글
-
안 만든 것이 규율이다 — 절제로 끌고 간 토이 프로젝트 회고 (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)식 함축에 기대고 있었다. 토큰을 줄이는 영리한 트릭이지만, 그 트릭을 읽어내려면 독자가 그 언어 문화의 소양을 갖고 있어야 한다. 압축된 출력이 누군가에게는 더 읽기 어려..
-
Next.js v14 → v15 마이그레이션 작업기Next.js 2026. 6. 6. 12:20
1. 도입부 (Why This Matters)메이저 버전 업그레이드는 보통 하나씩 한다. Next.js 먼저 올리고, 안정화되면 React, 그다음 Node. 교과서적이고 안전하다. 그런데 우리는 Next.js 14→15, React 18→19, Node.js 20→24, ESLint 8→9를 단일 PR로 동시에 올렸다. 88개 파일이 한 번에 바뀌었고, 프로덕션 에러율은 0%를 유지했다.이게 무모해 보인다면 정확한 직관이다. 다만 이 네 축은 서로 강하게 결합돼 있어서 따로 떼면 오히려 "중간 상태"가 더 위험해진다. React 19 타입은 Next.js 15가 요구하고, Next.js 15의 비동기 API는 Node 런타임과 맞물리고, ESLint 9는 그 위에서 새 코드를 검증한다. 절반만 올린 브..
-
개발자 원칙(확장판) - 박성철 , 강대명 , 공용준 , 김정 , 박미정 , 박종천 , 장동수 , 이동욱(향로) , 이동욱(네피림)서평 2026. 6. 3. 12:27
이 책은 "좋은 개발자란 누구인가"라는 질문에 기술 스택이 아니라 업(業)의 원칙으로 답하는 책입니다. 컬리·카카오·무신사·몰로코·인프런 등에서 일해온 국내 테크 리더 9인이 각자 한 가지 원칙을 에세이로 풀어냈고, 확장판은 여기에 0장 「선배와의 인터뷰」와 각 장 말미의 「출간 후 2년, 그다음 이야기」를 더했습니다.그래서 이 책은 "무엇을 코딩할까"보다 "어떻게 개발자로 살아갈까"에 가까운, 일종의 직업 정체성 안내서입니다.0장. 선배와의 인터뷰핵심 개념: 확장판에 새로 들어간 부분으로, 9인 저자 전원에게 같은 질문 세 가지를 던집니다. "좋은 개발자(좋은 개발 조직)란 무엇인가", "언제 가장 즐거웠나", "이 일을 계속하게 하는 원동력은 어디서 오는가"입니다.주요 사례/에피소드: 각자의 답이 본..