시스템 프롬프트를 줄여 연 2,000만 달러를 절감한 러버블

규칙을 더할수록 에이전트가 흐트러진다는 원리는 지침 예산 글에서 다뤘습니다. 이번에는 그 원리를 실제 제품에 적용해 성과를 낸 사례를 살펴봅시다. 러버블(Lovable)의 엔지니어 Benjamin Verbeek는 2025년 연말 연휴 기간에 시스템 프롬프트 전체를 재정비했고, 그가 공개한 수치에 따르면 응답 속도가 약 4% 빨라지고 연간 LLM 비용이 2,000만 달러 규모로 절감됐습니다.¹ 프롬프트에 무언가를 더한 게 아니라 덜어낸 결과입니다.

프롬프트가 비대해진 경위

러버블의 시스템 프롬프트가 처음부터 비대했던 건 아닙니다. 여러 엔지니어가 각자 맡은 기능을 최적화하면서 지침이 하나씩 추가되며 비대화가 발생했습니다. 누군가 'X를 더 잘하게 하려면 이 문장을 넣자'며 지침을 추가하면, 나중에 다른 사람이 'Y가 약해졌다'며 또 다른 문장을 추가했기 때문이죠. Benjamin은 연휴 기간에 LLM 트레이스를 처음부터 끝까지 다시 읽으며 이 악순환을 발견했습니다. 프롬프트에는 엔지니어들의 사고 과정이 그대로 쌓여 있었고, 그 결과는 중복과 모순, 장황한 표현이었습니다.

개별 기능만 보면 각 지침은 나름의 근거가 있습니다. 문제는 전체입니다. 지침이 쌓일수록 모델이 지침을 따르는 능력 자체가 고르게 떨어지기 때문에, 부분의 합이 전체 성능을 갉아먹는 구조가 되었습니다. CLAUDE.md가 진흙 덩어리가 되는 경로와 정확히 같은 패턴이 프로덕션 시스템 프롬프트에서도 재현된 셈입니다.

새 기법이 아니라 기본기

개선 방법에 특별한 발명은 없었습니다. 중복을 제거하고, 언어를 간결하게 다듬고, 특정 기능만 강조하다 전체 균형이 무너지지 않도록 프롬프트 전체를 한 번에 보는 관점을 유지했습니다.

Benjamin의 작업 방식엔 흥미로운 지점이 있었습니다. Benjamin은 처음 몇 단락은 직접 수작업으로 정리해 기준을 만들고, 나머지는 '내가 정리한 스타일과 톤을 따라 정리해줘'라는 지시와 함께 개선 작업을 Claude Opus에 위임했습니다. 그리고 생성된 결과물을 한 줄씩 직접 리뷰하면서 중요한 부분은 수동으로 복원하거나 보강했습니다. 사람이 기준을 세우고 모델이 규모를 감당하고 사람이 다시 검수하는 흐름이었습니다. 프롬프트 길이를 상당히 줄이면서도 기존 지침의 핵심 의도를 유지할 수 있었던 이유가 여기에 있었습니다.

실험 물리학자의 배포 방식

실험 물리학 배경을 가진 Benjamin은 배포 과정도 실험처럼 설계했습니다. 연휴 기간을 택한 것부터 의도적입니다. 다른 변경 사항이 거의 없는 시기라 회귀가 생기면 원인을 프롬프트 변경으로 특정할 수 있기 때문입니다. Benjamin은 연휴 기간에 새 시스템 프롬프트를 기준으로 엣지 케이스를 직접 테스트하고, 내부 벤치마크와 eval 세트를 실행하고, 소규모 사용자 그룹에 먼저 롤아웃한 뒤 지표를 모니터링하며 점진적 배포를 진행했습니다.

프롬프트 수정 자체보다 이 검증 체계가 우리가 배워야 할 점입니다. 안전하게 실험할 수 있는 환경이 없으면 시스템 프롬프트는 손대기 두려운 코드가 되고, 아무도 정리하지 않은 채 계속 쌓이기만 합니다.

결과와 교훈

러버블 팀은 전체 사용자를 대상으로 새 시스템 프롬프트가 배포된 후 응답 속도가 약 4% 빨라지고 디자인 품질이 눈에 띄게 향상되며 AB 테스트에서 지시 준수 정확도도 개선된 것을 확인했습니다. 토큰 사용량이 줄면서 연간 LLM 비용은 2,000만 달러 규모로 절감됐습니다.¹ 프롬프트를 '줄였는데' 성능이 '좋아졌다'는 점이 핵심입니다. 모델이 소화할 수 있는 지침 총량에는 한계가 있으므로, 불필요한 지침을 걷어내는 일은 러버블 팀의 사례처럼 남은 지침의 준수 품질을 회복시킵니다.

Benjamin이 정리한 교훈은 세 가지입니다.

• 프롬프트 품질은 규모에서 복리로 작용한다. 소규모에서는 미미한 개선이 대규모 트래픽에서는 비용과 성능의 큰 격차를 만든다.

• 전체를 보는 관점이 '더 강하게 지시하기'를 이긴다. 개별 부분을 계속 강화하는 것보다 전체에서 중복과 비효율을 제거하는 편이 효과적이다.

• 빠르고 안전한 실험 환경이 최고의 자산이다. 좋은 eval과 점진적 배포가 있어야 과감한 정리가 가능하다.

정리

시스템 프롬프트는 한 번 만들고 끝나는 산출물이 아니라 주기적으로 전체를 다시 봐야 하는 자산입니다. 특히 에이전트형 제품처럼 시스템 프롬프트가 제품의 핵심인 경우, 진짜 최적화는 지시를 더 추가하는 쪽이 아니라 불필요한 것을 제거하고 명확하게 만드는 쪽에 있습니다. 규모가 크다면 그 효과는 응답 속도와 비용이라는 숫자로 돌아옵니다.

내 프로젝트의 CLAUDE.md·AGENTS.md에 같은 원리를 적용하는 방법은 지침 예산 글에서 확인하세요.

1. Benjamin Verbeek (@benjaminvrbk), X 스레드, 2026년 1월. 응답 속도·비용 수치는 스레드에서 본인이 공개한 값이다.

   ↩