에이전트는 더 주관적이어야 한다

원문: Agents Should Be More Opinionated

2025년 11월 25일

최고의 에이전트 제품은 가장 유연한 것이 아니라, 가장 주관적인 것입니다. 이 글에서는 그 이유에 대해 논의하겠습니다. 요약하자면 다음과 같습니다:

주관적인 에이전트를 만드세요. 도구 설계와 프롬프트에 대한 입장을 확실히 하세요. 모든 작업이 아니라 여러분의 작업에서 성공하는 것이 목표입니다. 커스터마이징 기능은 나중에 추가하세요.

이 글에서 탐구할 내용:

• 유연성의 함정 - 왜 에이전트는 더 많은 설정이 아니라 더 적은 설정이 필요한가?
• 오늘날 제품에서의 주관적인 에이전트 설계 원칙. 주관적이라는 것이 제한적이라는 의미는 아닙니다.
• 범용 에이전트의 신화. 모델은 하네스 안에서 대체 불가능합니다. 모델의 뾰족한 지능을 중심으로 설계하는 것이 좋은 하네스 엔지니어링입니다.

지능의 미래는 매우 똑똑한 모델로부터 만들어진 초특화된 에이전트입니다.

주관적인 에이전트 설계 원칙

에이전트 제품의 목표는 다른 모든 제품과 마찬가지로 사용자에게 즐거운 경험을 제공하는 것입니다. 실제로 작동하는 에이전트의 좋은 기준선은 너무 많은 설정을 조정하지 않고도 모든 것이 안정적으로 작동하는 것입니다. 좋은 제품 디자인은 크리에이터들이 자신의 비전을 그냥 작동하는 직관적인 인터페이스로 정제해온 역사입니다.

주관적인 에이전트 설계를 위한 원칙들을 정리해보겠습니다:

1. 에이전트는 더 많은 설정이 아닌 더 적은 설정이 필요합니다. 사용자들이 감사할 것입니다.
2. 사용자를 대신해서 많은 작업을 수행하세요.
3. 프롬프트와 도구에 집착하세요. 이것이 팀의 지식과 의견을 제품에 전달하는 가장 쉬운 방법입니다.
4. 도그푸딩과 평가는 현재 의견 세트의 효과를 측정하는 방법입니다.

의견, 제품 피드백, 평가가 에이전트 설계와 제품 피드백의 플라이휠을 구성합니다

실전에서의 원칙

어떤 사용자가 온도(temperature)와 청킹 전략(chunking strategy)을 조정하는 것에 흥분할까요? 아무도 없습니다… 말 그대로 아무도요. 이것이 바로 유연성의 함정입니다. 사용자가 선택을 원한다고 생각하지만, 실제로는 결과를 원합니다. 스티브 잡스와 아이폰의 순간은 인터페이스 디자인의 천재적인 사례였습니다 - 버튼 하나, 화면 하나. 하지만 이것이 실제로 기능을 제한한 것은 아니었습니다. 단지 제품과의 사용자 상호작용 표면적을 제한했을 뿐입니다. 마법은 몇 안 되는 사용자 터치포인트만으로도 제품이 여전히 안정적으로 작동한다는 것입니다.

Cursor의 작업 방식에서 나온 훌륭한 인용구:

“이 설정이 필요한가요?”, “더 적은 클릭으로 도달할 수 있을까요?”, “어떻게 간소화할 수 있을까요?”, “누가 사용하나요? 제거할 수 있을까요?”

이것이 바로 AI 에이전트를 사용한 제품 디자인에서 원하는 에너지입니다. 기준선 에이전트가 훌륭하도록 사전에 엄청난 양의 작업을 수행해야 합니다.

그 작업에는 무엇이 포함될까요?

• 사용자가 하지 않아도 되도록 모든 모델을 테스트하세요. 제품의 실제 사용 사례에서 테스트하고, 벤치마크를 믿지 마세요! 사용자는 Terminal Bench 2.0에 대해 들어본 적이 없으니, 소개하지 마세요.
• 성공이 무엇인지, 그리고 어떻게 도달하는지 에이전트에게 알려주는 상세한 프롬프트를 작성하세요. 그들이 말하는 것을 믿지 마세요… 프롬프트 엔지니어링은 죽지 않았습니다
• 설정 옵션을 테스트하세요. 모든 필수 사용자 옵션은 사용자를 대신해 결정을 내리지 못한 실패입니다. Claude Opus 4.5가 여러분의 작업에 최고의 모델이라는 것을 안다면, 기본값으로 만드세요. 검색 도구를 항상 먼저 호출해야 한다는 것을 안다면, 강제하세요.

이상적으로는 팀이 목표 고객층을 정확히 반영해야 합니다. 이것이 사실일 때, 도그푸딩을 통한 놀라운 제품 반복 플라이휠을 얻게 됩니다. 다시 한 번, Cursor가 훌륭한 예입니다. 제품을 도그푸딩하여 어디서 작동하고 어디서 작동하지 않는지 감을 잡으세요. 모든 유용한 것이 쉽게 측정될 수 있는 것은 아니지만, 팀이 그 격차를 메우는 인간 다리가 될 수 있습니다.

진정한 “범용” 에이전트의 신화

간단한 멘탈 모델로 시작해봅시다:

에이전트 = 주관적인 하네스 + 모델

모델 하네스에 여러분의 의견을 구워 넣으세요. 에이전트가 여러분의 작업을 잘 수행하도록 만드는 가장 빠른 방법입니다.

이전 글에서 하네스에 대해 논의했지만, 요약하자면, 하네스는 모델을 감싸서 여러분의 작업에 최적으로 유용하게 만듭니다: 프롬프트, 도구, 컨텍스트 관리 + 문서, 서브에이전트 등. 하네스는 여러분의 의견이 존재하는 곳이며 “좋은” 것이 무엇인지 인코딩하는 곳입니다. 사람들이 “범용” 에이전트를 원한다고 말할 때, 실제로 설명하는 것은 트레이드오프입니다:

하네스 엔지니어링에 시간을 덜 쓰는 대신 낮은 작업 성능을 기꺼이 받아들이겠습니다. 이 기본 하네스로 많은 작업에 이 에이전트를 사용할 수 있다면 좋겠습니다.

이것은 타당한 선택입니다. 때로는 빠르게 프로토타입을 만들어야 하거나, 너무 많은 커스텀 엔지니어링 없이도 기본 성능이 충분히 좋을 수 있습니다. 하지만 함정은 다음과 같습니다: 대부분의 빌더들이 “범용”을 기본값으로 선택하는 이유는 의식적으로 이러한 트레이드오프를 한 것이 아니라, 아직 자신만의 의견 세트를 선택하지 않았기 때문입니다.

모델은 대체 불가능하다

과감한 주장… 하네스와 분리된 모델을 실제로 평가할 수는 없습니다. 그들은 상호 의존적입니다.

모델의 지능은 뾰족합니다. 하네스를 설계할 때, 여러분은 암묵적으로 모델의 강점과 약점을 중심으로 설계하고 있습니다. 이것은 새로운 모델로의 “업그레이드”가 종종 기존 하네스를 망가뜨린다는 것을 의미합니다. 왜냐하면 새 모델은 다른 뾰족한 부분을 가지고 있기 때문입니다. 세심하게 조정된 프롬프트가 더 이상 같은 동작을 생성하지 않고, 도구 호출이 갑자기 새로운 실패 모드를 초래할 수 있습니다… 이해하시겠죠.

중요한 유일한 질문은: 이 하네스 + 모델 쌍이 내 작업에서 성공하는가?

이것은 “최신 벤치마크 점수에 기반했을 때 이 새 모델이 작동해야 하는가?”와는 현저히 다른 질문입니다. 여러분의 작업에서, 여러분의 사용자와, 여러분의 데이터로 안정적으로 작동하나요? 진지한 도그푸딩과 세련된 평가가 여기서 중요합니다. 벤치마크가 아닌 실제 문제에서의 성능을 측정하기 위해서입니다.

시작 스위트 스팟은 깊고 좁다

그렇다면 “범용”이 트레이드오프이고 작업 성능이 중요하다면, 어디에 시간을 투자해야 할까요? 깊고 좁은 에이전트로 시작하세요. 작업을 선택하고, 중요한 소수의 동작으로 표면적을 줄이고, 그 동작들이 안정적으로 작동하도록 만드세요.

초기 팀들이 종종 빠지는 두 가지 실패 모드가 있습니다:

1. 넓은 에이전트는 너무 많은 다른 종류의 작업을 처리하려고 합니다. 추가되는 모든 기능은 버그, 엣지 케이스, 혼란스러운 동작을 위한 표면적입니다. 넓은 에이전트는 데모에서는 인상적이지만, 프로덕션에서는 좌절스럽습니다. 작업이 신뢰할 만큼 충분히 안정적으로 작동하지 않기 때문입니다.
2. 얕은 에이전트는 에이전트가 될 만큼 충분히 복잡하지 않습니다. 종종 사용자와의 반복이 없고, 판단이 필요하지 않고, 다단계 추론이 필요하지 않다면, 이것은 에이전트가 아니어야 할 수도 있습니다. 이전 글에서 에이전트와 워크플로에 대해 썼는데, 에이전트 vs. 워크플로를 언제 어떻게 사용할지 생각하는 데 도움이 될 수 있습니다.

최고의 지점은 무자비하게 최적화할 수 있을 만큼 충분히 좁고, 복잡성이 투자를 정당화할 만큼 충분히 깊습니다. 시작하려면, 대부분의 가치를 제공하는 작업의 10%를 찾아 잠재적으로 “에이전트화”하고 나머지는 무시하세요.

모델 랩조차도 모두가 더 주관적이 되고 있다

모델은 점점 더 똑똑해지고 있지만, 안정적으로 좋은 작업을 수행하려면 각 작업에 대해 에이전트 하네스에서 다듬어져야 합니다. 왜 Anthropic은 생명과학과 금융을 위한 전담 팀을 두고 있을까요? 오늘날 그것은 금융만을 위한 특화된 기초 모델을 구축하기 위함이 아닙니다. 대신 그들은 문제 공간을 매핑하고, 에이전트 하네스(프롬프트, 도구, 컨텍스트, 서브에이전트)를 최적화하고, 다음 모델 반복이 가치 있는 작업에 대해 기본적으로 훈련되도록 데이터를 설계하고 있습니다. 생명과학 작업을 해결하고 있다면, 해당 도메인을 위해 특별히 구축된 도구와 지침을 갖는 것이 매우 유익합니다. 오늘날 여러분은 작업 하네스 설계에 초집착함으로써 더 나은 작업 성능을 달성할 수 있습니다. 내장된 도구와 컨텍스트 관리를 갖춘 Claude Code와 Codex 같은 에이전트 제품의 하네스에서 유사한 주관적인 설계 원칙을 볼 수 있습니다.

LLM의 첫 번째 물결은 우리에게 엄청난 범용 도구(프레임워크, API 래퍼, 설계 원칙 등)를 제공했습니다. 오늘날 승리하는 좋은 방법은 그 광범위한 스택을 가져와서 여러분의 의견으로 좁히는 것입니다. 예를 들어, LangGraph와 LangChain은 빌더들이 모델 공급자, 프롬프트 템플릿, 노드 기반 오케스트레이션과 같은 유용한 추상화로 LLM 환경을 탐색하도록 도왔습니다. 이제 DeepAgents를 통해, 그들은 파일시스템 지원, 계획을 위한 내장 도구, 프롬프트 등과 같은 유용한 사전 설정을 신중하게 선택하는 주관적인 에이전트 하네스를 가지고 있습니다. 옵션에는 가치가 있지만, 좋고 주관적인 기본값도 중요합니다. 이것이 DeepAgents가 제공하는 것이며, 원한다면 거기서부터 커스터마이징할 수 있습니다.

Amp Code는 유사한 접근 방식을 취합니다. 그들은 단일 사용 사례인 코딩을 추구합니다. 이것을 잘 하기 위해, 그들은 제품을 끊임없이 도그푸딩하고 학습한 것을 제품에 직접 구워 넣습니다. 여기에는 어떤 모델을 사용할지와 어떤 서브에이전트/기능이 유용한지(예: Librarian)가 포함됩니다. 그들은 여러분에게 백만 가지 선택을 주고 싶어 하지 않고, 여러분이 코드 개발에 성공하기를 원하며, 그들이 할 수 있는 최선의 방법은 스스로 시도하고 학습한 것을 제품을 통해 여러분에게 전달하는 것입니다.

오늘날 주관적이 되기

오늘날 에이전트 제품의 불편한 진실이 있습니다: 여러분은 아마도 너무 많은 옵션과 충분하지 않은 의견을 가지고 있을 것입니다.

하지만 그것을 바꿀 마음이 있다면, 오늘 시작할 수 있는 몇 가지 방법이 있습니다.

1. 설정 표면을 감사하세요. 사용자가 할 수 있는 모든 선택에 대해 “우리가 올바른 답을 알고 있나요?”라고 물으세요. 그렇다면 하드코딩하세요. 아니라면 알아내세요… 그것은 여러분의 일이지 그들의 일이 아닙니다.
2. 시작할 작업에 좁게 초점을 맞추세요. “우리는 X를 돕는 에이전트를 만들고 있습니다”는 충분히 구체적이지 않습니다. 단일 워크플로를 선택하고 그것을 위해 무자비하게 최적화하세요.
3. 벤치마크가 아닌 여러분의 작업에서 모델을 평가하세요. 질문은 “Opus 4.5가 Gemini 3 Pro보다 나은가?”가 아니었습니다. 질문은 “이 모델이 이 하네스와 함께 내 작업에서 성공하는가?”입니다. 그 미래를 위해 구축하세요.

“범용” 도구의 아이러니는 그것이 힘든 작업을 사용자에게 떠넘긴다는 것입니다. 주관적인 설계는 우리 빌더들에게 더 어렵습니다. 우리는 결정을 내리고, 트레이드오프를 받아들이고, 때로는 틀리고, 비판에 직면해야 합니다. 하지만 그것이 바로 더 나은 제품을 만드는 이유입니다. 여러분은 매일 힘든 일을 하며 깊이 파고들고 있습니다.