에이전트 활용에 필요한 다양한 정보들을 접하면서 여러 에이전트 기능들을 추가합니다. 그러다 보니 시스템 프롬프트가 늘어나거나 에이전트 구조를 더 복잡하게 만들었는데요. 이런 형태는 오히려 토큰 낭비와 성능 저하를 일으킨다고 합니다.
Code with Claude 세션에서 Evals 83%짜리 인벤토리 관리 에이전트를 92%까지 끌어올린 3가지 원칙을 공유했습니다. 위 내용을 정리해봤습니다🙌
———
✅시스템 프롬프트는 항상 필요한 것만 써야 합니다.
시스템 프롬프트에는 클로드가 어떤 작업을 하든 반드시 알아야 할 정보만 남겨야 한다고 합니다. 문제는 요구사항이 쌓일수록 정책, 절차, 도메인 지식이 모두 시스템 프롬프트 안으로 들어온다는 것입니다. 클로드는 지금 작업과 무관한 정보에 둘러싸여 혼란을 겪고, 서로 충돌하는 정책 사이에서 엉뚱한 판단을 내리기 시작합니다. 실제로 한 세션에서는 시스템 프롬프트 내 충돌하는 정책 때문에 프로모션 배수를 잘못 계산하는 오류가 발생했다고 합니다.
이런 문제의 해결책으로 스킬을 제안합니다. 가끔 필요한 정보는 스킬로 분리해 클로드가 필요하다고 판단할 때만 꺼내 쓰게 하는 방식인데요. 항상 필요한 정보는 시스템 프롬프트에 가끔 필요한 정보는 스킬로 패키징하는 것을 권장합니다. 실제로 이 방법을 적용하고 시스템 프롬프트가 상당히 많이 줄었고 Evals에서 반복되던 정책 충돌 오류가 사라졌다고 합니다.
✅툴은 인간형 기본 도구부터 시작해야 합니다.
커스텀 툴을 만들기 전에 먼저 자문해봐야 한다고 합니다. “사람이 이 일을 한다면 어떤 도구를 쓰겠는가?” 파일 시스템, 코드 실행, 웹 검색, 할일 목록 등 클로드 코드가 성능이 좋은 이유는 클로드에게 이 인간형 기본 도구를 그대로 쥐어줬기 때문이라고 합니다.
예를 들어 CSV 분석이 필요할 때, 파일 전체를 컨텍스트에 올리는 대신 클로드가 파이썬을 직접 작성하고 실행하게 하면 특정 작업 기준으로 토큰 사용량이 극적으로 감소했고 비용과 실행 시간도 함께 내갔다고 합니다.
기본 도구 > 에이전트 전용 커스텀 툴 > MCP(여러 에이전트 공통 사용)을 권장합니다(Good👍)
✅서브 에이전트는 꼭 필요할 때만 써야 합니다.
서브 에이전트는 두 가지 상황에서만 쓰는 것을 제안합니다.
첫째, 많은 클로드를 병렬로 투입해야 할 때입니다. 딥 리서치나 광범위한 코드 탐색처럼 여러 인스턴스가 동시에 달려드는 게 유리한 작업이 여기에 해당됩니다.
둘째, 독립적인 시각이 필요할 때입니다. 코드를 쓴 인스턴스와 리뷰하는 인스턴스를 분리하는 것처럼, 기존 컨텍스트에 오염되지 않은 판단이 필요한 경우인데요. 이 세션에서도 예측 모델링 서브 에이전트는 메인 컨텍스트의 영향을 받지 않아야 한다는 이유로 유지했다고 합니다.
메인 오케스트레이터가 흡수하는 것을 권장합니다. 최신 모델은 생각보다 훨씬 많은 것을 혼자 처리할 수 있고, 서브 에이전트가 늘어날수록 오케스트레이터와의 소통 오류와 로깅의 복잡성도 함께 늘어나기 때문입니다. (사실 전 이렇게 많이 썼습니다😓)
———
하지말아라 하는 행동을 많이 했어서 당황스럽네요😂. 에이전트의 시스템 프롬프트를 조금씩 덜어내 보고 테스트해보고 있습니다. 직접 써보면서 느낀 점은, 에이전트의 창의성을 넓히되 정말 하지 말아야 할 지침만 걸어주는 것이 가장 좋은 아웃풋이 나온다는 것입니다.
출처: Code with Claude
해시태그#Claude 해시태그#AI