프롬프트엔지니어링
-
안 깎는 것이 실력이다 — 압축 도구가 거부해야 할 출력 (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)식 함축에 기대고 있었다. 토큰을 줄이는 영리한 트릭이지만, 그 트릭을 읽어내려면 독자가 그 언어 문화의 소양을 갖고 있어야 한다. 압축된 출력이 누군가에게는 더 읽기 어려..