CLAUDE CODE의 시스템 프롬프트를 80% 제거하면 성능은 왜 달라질까

TL;DR

시스템 프롬프트의 대폭 제거로도 성능은 유지되거나 개선될 수 있다. Opus 5 등장 당시 프롬프트를 대폭 지우고 실작업을 돌려보면 모델이 더 자유롭게 작동하는 모습을 확인할 수 있었다. 다만 실제 제품화에선 사용 편의와 안전성의 균형을 다시 점검해야 한다.

Transcript

AI한테 일을 시킬 때 우리가 하는 건 되게 더하는 쪽이죠. 규칙을 더 적어주고 예시를 더 붙이고 하지 말고 목록을 늘리고요. 지난 달에 클로드 코드를 만든 사람이 무대에 올라서 정 반대 얘기를 했습니다. 새 모델이 나오자마자 시스템 프롬프트의 80%를 지웠다고요. 그리고 지웠더니 더 잘했습니다.이 영상은 그 35분짜리 대담을 따라가면서 왜 지금은 더 주는 쪽이 아니라 덜 주는 쪽이 정답이 됐는지 정리해 봅니다. 영상 중간중간 대담 클립이 들어갑니다. 한국어 자막 같이 띄울게요.이 대담이 열린 자리는 Y 콤비네이터가 여는 스타트업 스쿨 2026년 무대입니다. 에어 BNB 스트라이프 드롭스 레디을 배출한 그 엑셀러레이터예... Read More

Key Insights

• 시스템 프롬프트의 과다한 규칙은 모델의 자유도를 제한할 수 있다, 그리고 Opus 5에서 이를 대폭 제거해도 성능이 크게 떨어지지 않는 사례가 있다.
• 에블레이션은 각 문장이 실제로 어떤 차이를 만드는지 하나씩 제거하며 확인하는 평가 방법으로, 모델이 필요한 부분만 남겨두는 데 활용된다.
• 하블링은 모델이 할 수 있는데도 우리가 만든 틀 때문에 길이 막히는 현상을 가리키고, 프로덕트 오버행은 오늘의 모델이 이미 할 수 있는 여유를 제품에서 아직 꺼내지 못한 상태를 뜻한다.
• 프롬프트를 자주 제거하는 전략은 실험적이며, 모델이 실제로 필요로 하는 최소한의 지시만 남겨두는 접근이 생산성에 더 잘 맞을 때가 많다.
• 6개월마다 CLAUDE_MD를 비우고 스킬과 훅도 재점검하라는 조언은 지속적 재평가의 중요성을 강조한다.
• Bun 런타임의 Zig에서 Rust로의 이식 사례는 11일 만에 코드 베이스를 재구성해 작동하는 제품이 탄생한 실례를 보여준다.
• 하나의 규칙을 남길지 말지 판단하는 기준은 해당 문장이 모델이 매번 읽게 될 필요가 있는지와 비용 효율성이다.
• 진짜 자산은 평가 세트가 아니라 방법이며, 모델의 세대가 바뀌면 이전 평가가 충분하지 않을 수 있음을 시사한다.

Questions & Answers

Q: CLAUDE CODE의 시스템 프롬프트를 대폭 지운 이유는 무엇인가요?

주요 이유는 새 모델이 등장할 때마다 프롬프트를 과도하게 채워두면 모델의 자유도가 줄고 기본 수행 능력이 제한될 수 있기 때문입니다. Opus 5에서 80%를 제거한 뒤에도 성능 저하가 없었고, 이는 프롬프트의 필요 여부를 재평가하는 실험적 접근의 효과를 보여줍니다.

Q: 에블레이션이란 무엇이며 어떻게 활용하나요?

에블레이션은 시스템 프롬프트의 일부를 제거하고 하나씩 되돌려가며 어떤 문장이 실제로 성능에 기여하는지 확인하는 방법입니다. 의학의 조직 제거 개념에서 차용된 용어로, 한 줄씩 제거해 보며 영향력을 평가하는 과정입니다.

Q: 하블링과 프로덕트 오버행의 개념은 무엇인가요?

하블링은 모델이 할 수 있는데도 우리가 만든 틀 때문에 길이 막히는 상태를 말합니다. 프로덕트 오버행은 모델이 이미 할 수 있는 여유를 아직 제품에서 꺼내 쓰지 못한 상태를 뜻합니다. 두 개념은 모델의 잠재력과 현재 구현 간의 간극을 나타냅니다.

Q: 6개월마다 CLAUDE_MD를 비우고 다시 평가하라는 조언의 의도는 무엇인가요?

이는 모델이 빠르게 발전하는 특성을 반영한 것으로, 매 세대마다 기존의 규칙과 도구를 제거하고 필요한 것만 재적용해 본질적 능력을 재발견하도록 하는 전략입니다. 다만 완전히 지우는 것이 아니라 필요한 부분만 재점검하는 방식이 강조됩니다.

Q: Bun 런타임 사례에서 어떤 교훈을 얻을 수 있나요?

Zig에서 Rust로의 전면 재작성은 11일 만에 작동하는 코드로 이식되었고, 고도화된 시스템에서의 생산성 향상을 보여주는 사례로 제시됩니다. 이는 모델의 한계를 넘어서는 해결책을 어떻게 개발자 진영이 찾아낼 수 있는지의 예시입니다.

Q: 프롬프트 제거가 항상 최선의 전략인가요?

그렇지 않습니다. 제거 후 무엇을 다시 넣을지 신중하게 판단하고, 모델이 실제로 필요로 하는 최소한의 지시만 남겨두는 것이 중요합니다. 프롬프트를 과도하게 제거하면 필요한 지시가 없어져 성능 저하가 올 수 있기 때문입니다.

Q: Opu5의 학습에서 중요한 포인트는 무엇인가요?

중요한 포인트는 프롬프트가 아니라 검증 체계이며, 모델이 실제로 실패하는 지점을 관찰하고 같은 문제에서 반복적으로 실패하는 경우에만 부분을 되돌리며 재구성하는 방식이 핵심이라는 점입니다.

Q: 클로드 코드의 현재 한계는 어디에 있나요?

현재로서는 아주 깊은 시스템 코드나 분산 시스템 같은 영역에서 어려움이 있지만, 언어 런타임 이식이나 동적 워크플로우 구성 등 특정 영역에서 놀라운 성과를 보이고 있습니다.

Summary & Key Takeaways

• 시스템 프롬프트의 과다 규칙이 모델의 수행을 제약하는 경우가 많다는 점을 실험으로 확인했다. Opus 5에서 80%를 제거해도 기능은 유지되었고, 필요시 한 줄씩 되돌리며 영향력을 평가하는 에블레이션 기법을 활용한다.

• 프롬프트 제거의 실제 효과를 판단하려면 단순 제거가 아니라 제거 후 무엇을 다시 넣고 어떤 규칙이 남아야 하는지 신중히 재구성해야 한다. 하블링과 프로덕트 오버행 관점도 함께 고려한다.

• 실무 교훈으로는 모델의 성격이 세대마다 다르고, 매번 프롬프트를 재구성하기보다 실제 사용 시나리오에서 실패 지점을 관찰하고 필요한 부분만 점진적으로 보강하는 것이 중요하다는 점이다.