부고문 4종에 35크레딧 쓰던 일, 한 참여자가 0.2크레딧으로 줄였다

저녁 5시49분, 방에 노트북 하나를 놓고 질문이 올라왔다. 맥북 프로로 코딩을 해왔는데 m5 프로 대신 다른 노트북을 살 만한 게 있는지 묻는 짧은 물음이었다.

"맥북 프로 코딩용으로 쓰고잇엇는데 m5 프로대신 살만한 노트북잇을까요.."

곧이어 다른 참여자가 자신의 사례를 보탰다. 최근 윈도우 작업이 늘어 회사에서 리스가 끝난 노트북을 받아 쓰는데, 요즘은 맥보다 이쪽을 더 자주 켠다는 이야기였다. 맥과 윈도우를 오가며 작업하는 게 불편해 Synergy라는 프로그램으로 하나의 키보드·마우스를 두 기기에 공유하고 있다는 설명도 뒤따랐다.

"윈도우에서 작업할 일이 최근 많아져서 회사에서 리스 끝난 Lenovo ThinkPad P1 Gen 7 모델 얻어와서 사용중인데, 요즘 맥보다 더 자주 많이 사용하는거 같아요."

대화는 곧 노트북 이야기를 벗어나 LLM 활용법 쪽으로 넘어갔다. 한 참여자가 문서를 잘게 쪼개 검색하는 청크 기반 RAG(검색증강생성) 대신, 링크로 이어진 위키를 탐색하며 추론하는 "LLM Wiki" 아티클을 공유했다.

"Retrieval as Reasoning - LLM Wiki가 RAG보다 나은 이유에 대한 | GeekNews https://news.hada.io/topic?id=32164"

이날 대화에서 가장 무거운 발언은 따로 있었다. 한 참여자가 LLM 비용을 줄이는 자신만의 방법론을 "EGLE"(Eval-Gated Lean LLM Engineering, 평가 관문형 경량 LLM 엔지니어링)이라는 이름으로 소개했다. 품질을 평가로 먼저 고정하고, 안정된 규칙은 코드로 옮기고, 남은 판단만 그 평가를 통과하는 가장 저렴한 모델에 맡긴다는 접근이었다.

"LLM 비용을 줄이는 새로운 방법: EGLE 먼저 품질을 평가로 고정하고, 안정된 규칙은 코드로 옮기고, 남은 판단만 평가를 통과하는 가장 저렴한 모델에 맡기는 것. 저는 이 방식을 EGLE 라고 이름 붙였습니다."

바로 다음 메시지에서 이 참여자는 실제 업무에 적용한 수치를 공개했다. 동문회 부고문 4종을 작성하는 테스트에서, 적용 전 LLM 중심 처리는 35.9876크레딧이 들었다. 안정된 부분을 코드화한 뒤에는 2.5768크레딧으로, 모델까지 저가형으로 바꾼 뒤에는 0.1995크레딧으로 줄었다. 세 단계 모두 품질 평가는 통과했다고 밝혔다.

"적용 전 Sol medium + LLM 중심 처리 → 35.9876 credits 코드화 후 Sol medium 유지 → 2.5768 credits 모델 최적화 후 Luna low 채택 → 0.1995 credits 품질 평가는 모두 통과했다. 결과: 총 LLM 비용 99.45% 감소 같은 업무를 약 180배 저렴하게 수행 하였습니다."

총 감소폭은 99.45%, 같은 업무를 약 180배 저렴하게 처리했다는 결론이었다. 다만 이 수치는 제3자가 검증한 벤치마크가 아니라, 이 참여자가 자신의 업무 하나를 놓고 직접 측정한 개인 테스트 결과다. 업무 종류나 모델 조합이 달라지면 감소폭도 달라질 수 있다는 뜻이다.

그럼에도 이 대화가 눈에 띄는 건 접근 방식 자체다. 무작정 더 좋은 모델을 쓰는 대신, 어디까지가 코드로 대체 가능한 반복 작업이고 어디서부터 LLM의 판단이 정말 필요한지를 먼저 가르는 순서를 제안했기 때문이다. 노트북 한 대를 고르는 질문에서 시작한 대화가 개발 환경 공유 도구를 거쳐 LLM 비용 구조를 다시 짜는 방법론까지 이어진 셈이다. 하드웨어·연결·비용이라는 서로 다른 층위의 이야기였지만, 결국 더 적은 리소스로 같은 결과를 내는 방법이라는 하나의 질문으로 수렴하는 흐름이었다.