00:00:00클로드 모델 하나만으로는 충분하지 않습니다. Opus는 추론 능력이 뛰어나지만
00:00:04사용 제한을 금방 소모하죠. Sonnet은 빠르지만 어려운 결정에서는 한계에 부딪힙니다.
00:00:10해답은 하나를 선택하는 것이 아닙니다. 모든 모델을 함께 사용하는 것이죠. 클로드 코드는 이미 어느 정도 이 작업을 수행하고 있습니다.
00:00:14스스로 모델 간의 오케스트레이션을 수행하죠. 하지만 앤스로픽은 최근 토큰을 절약할 뿐만 아니라
00:00:18작은 모델들을 큰 모델만큼이나 유능하게 만드는 기능을 출시했습니다.
00:00:23클로드로 개발할 때 이런 점을 느끼셨을 겁니다. Opus에 작업을 맡겼을 때
00:00:28그만큼의 노력이 필요하지 않다고 판단되면, 모델은 이를 Sonnet이나 Haiku에 넘기고
00:00:32토큰 사용량을 적절히 관리하기 위해 작은 모델들에게 작업을 위임합니다. 하지만 이 방식에는 문제가 있습니다.
00:00:37지난 영상에서 언급했듯이, 앤스로픽은 속도 제한을 낮추고 있어서
00:00:42피크 시간대에는 5시간의 제한 창이 더 빨리 채워집니다. 게다가 Opus는
00:00:47단순한 작업에도 많은 토큰을 소비하므로, Opus를 사용하면 컨텍스트 제한이 더 빨리 소모된다는 의미입니다.
00:00:52앤스로픽은 이 상황을 반전시키기로 결정했고, "어드바이저(Advisor) 전략"이라는 것을 내놓았습니다.
00:00:55이 전략의 작동 방식은 실행자(Executor) 역할을 Sonnet 모델에 맡기고
00:01:00Opus는 순수하게 실행자가 정말로 필요할 때만 상담하는 어드바이저로 사용하는 것입니다.
00:01:05두 명의 에이전트가 참여합니다. 실행자는 Sonnet에서 실행되는 메인 에이전트이며
00:01:10모든 도구 호출, 코드 변경 및 사용자 출력물을 처리합니다. 어드바이저는 Opus에서 실행되며
00:01:15그의 유일한 역할은 실행자가 막혔을 때 가이드를 제공하는 것입니다. 어드바이저는 절대 코드를 작성하거나 변경하지 않습니다.
00:01:20앤스로픽이 이 방식을 실험했을 때, SWE 벤치마크에서 Sonnet 단독 사용보다 성능이 뛰어남을 확인했습니다.
00:01:25이 조합이 성능과 비용 측면 모두에서 Sonnet 단독 사용을 능가한다는 것을 발견한 것이죠.
00:01:31또한 Opus를 메인 에이전트로 실행하는 것보다 비용이 현저히 저렴합니다. Opus는 모든 반복 과정이 아니라
00:01:36실제로 중요할 때만 호출되기 때문입니다. 이미 앱 제작을 위한 훌륭한 프레임워크가
00:01:40많이 준비되어 있는데 왜 굳이 이런 설정을 써야 하는지 의문이 드실 수도 있습니다.
00:01:45그 이유는 대부분의 기존 프레임워크가 비용과 토큰 효율성을 염두에 두고 설계되지 않았기 때문입니다.
00:01:50작업은 완수할지 몰라도, 클로드를 더 오래 그리고 더 효율적으로 작동하게 만드는 데는 부족함이 있습니다.
00:01:54토큰 사용 최적화보다는 앱 구축 자체에 주로 집중하고 있기 때문입니다.
00:01:59이 설정을 사용하면 더 약한 모델을 사용하여 작동하는 앱을 빌드할 수 있어,
00:02:04전체 프로세스를 훨씬 더 토큰 효율적으로 만들 수 있습니다. 그리고 이는 앞서 언급한 제한 문제와 연결됩니다.
00:02:09저희는 이미 클로드의 제한에 관한 영상을 만들었고, 더 오래 사용하려면 더 작은 모델로 전환하라고 말씀드렸습니다.
00:02:13연결 고리는 이렇습니다. Sonnet은 동일한 작업을 수행할 때 Opus보다 훨씬 적은 토큰을 소비하고
00:02:19적은 노력을 필요로 합니다. Opus는 매우 크고 강력한 모델이라서
00:02:24단순한 작업에도 많은 토큰을 소비하죠. Sonnet은 많은 작업을 더 효율적으로 처리할 수 있습니다.
00:02:30따라서 더 어려운 결정에서 발생하는 성능 차이를 메우기 위해서만 Opus를 사용하는 것이 실제 효과를 발휘하는 부분입니다.
00:02:35모든 작업이 아니라 실제로 필요할 때만 그 강력한 힘을 호출하는 것이니까요.
00:02:40이는 전반적인 사용을 더 토큰 효율적으로 만들고, 동일한 제한 내에서 더 많은 일을 할 수 있게 해줍니다.
00:02:45저희는 이 채널에서 AI로 제품을 만드는 것에 대해 발견한 모든 것을 공유하고 있으니,
00:02:50더 많은 영상을 원하시면 구독하시고 다음 영상을 기대해 주세요. 이제 저희는 Sonnet으로 이미 구축된 앱에서
00:02:55이 전략이 실제로 어떻게 작동하는지 테스트해보고 싶었습니다. 클로드 코드 내부에서 이 전략을 사용하기 위해
00:03:00Opus 4.6을 어드바이저 모델로 설정하는 명령어를 입력했습니다. 메인 에이전트는 제가 이미 앱을 빌드할 때
00:03:05사용했던 Sonnet으로 설정된 실행자였습니다. 이 앱은 실시간 동기화 기능이 있어야 했는데,
00:03:10요소를 이동하고 크기를 조정하는 것은 세션 간에 완벽하게 동기화되었지만 삭제 기능은 전혀 동기화되지 않았습니다.
00:03:16Sonnet 단독으로 여러 번 디버깅을 시도했지만, 아무리 문제를 해결하려 해도 이슈는 계속 지속되었습니다.
00:03:20그래서 Opus를 어드바이저로 켠 후, 클로드에게 문제를 설명하는 프롬프트를 주었습니다.
00:03:25Sonnet이 이미 여러 번 실패했었기 때문에, 스스로 다시 시도하는 대신
00:03:30이번에는 어드바이저를 호출하기로 결정했습니다. 어드바이저는 상황을 파악하기 위해 지금까지의 대화를 검토했습니다.
00:03:34그리고 동기화 로직이 어디서 깨지고 무엇을 구체적으로 재구성해야 하는지 짚어내며
00:03:40정확히 변경해야 할 사항을 제공했습니다. 실행자 모델은 그 조언을 받아들여
00:03:45추가적인 대화 없이 해당 수정 사항을 직접 적용했습니다. 저희는 동기화를 확인하기 위해 여러 기기에서 테스트했고
00:03:50문제가 해결된 것을 확인했습니다. 이전에는 불가능했던 것과 달리,
00:03:55한쪽 끝에서 사용자가 항목을 선택하고 다른 쪽 끝에서 삭제가 진행되는 중에도 양쪽 모두 삭제가 제대로 반영되었습니다.
00:04:00만약 Sonnet 단독으로 이를 고치려 했다면, Sonnet은 본질적으로
00:04:05더 약한 모델이고 복잡한 로직을 스스로 처리할 만큼 유능하지 않기 때문에 더 많은 라운드의 프롬프트가 필요했을 것입니다.
00:04:09반면에 Opus 단독 사용은 훨씬 더 많은 토큰을 소비했을 것이고 아마 이렇게 빠르지도 않았을 것입니다.
00:04:15Opus를 어드바이저로 하여 Sonnet을 사용하는 것이 과정을 훨씬 더 효율적으로 만들었습니다.
00:04:20결과적으로 이 전략은 동기화 문제를 이전보다 훨씬 빠르게 디버깅하는 데 도움이 되었습니다.
00:04:25하지만 더 진행하기 전에 저희 스폰서인 JetBrains의 Juni에 대해 한 말씀 드리겠습니다.
00:04:30개발자라면 터미널, IDE, CI 파이프라인 사이에서 컨텍스트 스위칭을 하며 작업을 완료하는 고충을 아실 겁니다.
00:04:36대부분의 코딩 에이전트는 하나의 환경이나 특정 LLM에 가두어 버리곤 하죠.
00:04:41Juni CLI는 다릅니다. 어디서나 작동하는 LLM 불가지론적 코딩 에이전트입니다.
00:04:47터미널, IDE, GitHub, CI/CD 파이프라인, 심지어 작업 관리자에서도요. 하나의 에이전트가 모든 곳에 있습니다.
00:04:54테스트 작성, 백엔드 구축, 리팩토링, 모든 커밋에 대한 자동 코드 리뷰 등 실제 작업을 위임하세요.
00:04:59현재 JetBrains는 에이전트 테스트를 위한 50달러의 Gemini 크레딧을 포함하여 무료 얼리 액세스 프로그램을 운영 중이며
00:05:04선호하는 모델을 사용할 수 있도록 BYOK도 지원합니다. 모든 기능에 대한 전체 액세스권과
00:05:10신기능 우선 사용권, 그리고 제품을 만드는 개발팀의 직접적인 지원을 받으세요. Juni와 함께라면 분명 더 나아질 것입니다.
00:05:15고정 댓글의 링크를 클릭하여 무료로 가입하세요. 이제 저희는 주요 UI 변경 시에도
00:05:20Sonnet이 실제로 어드바이저와 상담하는지 테스트하고 싶었습니다. 이전에 구축한 애플리케이션이 있었고
00:05:25그 UI를 다른 라이브러리로 변환하고 싶었습니다. 게다가 일반적으로 권장되지는 않지만
00:05:31한 번에 여러 UI를 변경하고 싶었습니다. 큰 작업에서 작은 모델이 큰 모델과 어떻게 협력하여 수행하는지 보고 싶었기 때문입니다.
00:05:36먼저 Playwright MCP를 사용하여 현재 UI에 액세스했습니다. 레이아웃을 이해한 후
00:05:41바로 코드 변경에 뛰어드는 대신, 어드바이저와 상담하여 최선의 접근 방식을 결정했습니다.
00:05:46이는 중대하고 치명적인 변경 사항이었고 잘못 다루면 앱이 깨질 수 있었기 때문입니다.
00:05:50어드바이저는 우리가 선택한 새 라이브러리와 이미 프로젝트에서 사용 중인 라이브러리 사이에
00:05:55버전 문제가 있다고 보고했습니다. 따라서 UI 작업을 시작하기 전에 클로드는
00:06:00이 문제부터 해결해야 했습니다. Sonnet이 먼저 이를 처리했고, 종속성이 적절히 적용되었는지 확인하기 위해
00:06:04여러 명령어를 실행한 다음 Playwright를 통해 클라이언트 측 이슈 없이 앱이 여전히 잘 실행되는지 확인했습니다.
00:06:09종속성이 정리되자, 어드바이저가 제안한 대로 변경 사항을 만들기 시작했습니다.
00:06:14각 컴포넌트를 하나씩 작업하며 효과적으로 앱 전체를 재설계했습니다.
00:06:18결과물인 UI는 훨씬 더 인터랙티브했고 이전보다 훨씬 더 세련되어 보였습니다.
00:06:23여전히 몇 가지 문제는 있었지만 전반적인 개선은 분명했습니다. 하지만 여기서
00:06:27한계점이 나타났습니다. 전체 과정에 약 31분이 소요되었습니다. Opus 단독이었다면
00:06:32병렬로 실행할 수 있는 작업을 식별하고 동시에 실행하는 능력이 뛰어나기 때문에 훨씬 더 빨랐을 것입니다.
00:06:37Sonnet은 더 작은 모델이라 작업을 병렬 서브 에이전트로 나누지 않고 모든 것을 순차적으로 처리했습니다.
00:06:43그렇게 복잡하지 않은 앱임에도 31분은 예상보다 긴 시간이었습니다.
00:06:48또한 사소한 수정 사항은 어드바이저를 개입시키지 않고 스스로 처리하는데,
00:06:53이는 마이너한 조정에 있어서는 올바른 동작입니다. 하지만 이처럼 앱 전체에 걸친 대규모 변경의 경우
00:06:58Opus를 직접 사용하는 것이 시간과 노력을 현저히 절약할 수 있어 더 낫습니다.
00:07:03이제 기존 코드베이스에 완전히 새로운 기능을 제대로 구현하는지 테스트해보고 싶었습니다.
00:07:08이미 구축된 앱에 다른 기능을 가진 페이지를 하나 더 추가하려고 했습니다.
00:07:13우리가 원하는 것을 설명하는 프롬프트를 주었고, 이번에는 단순한 작업이 아니었기에
00:07:17당연히 어드바이저를 사용할 것이라 예상했지만, Sonnet은 어드바이저와 상담하지 않고
00:07:22전적으로 혼자서 변경 사항을 구현해 나갔습니다. 기능의 범위를 고려할 때 분명 그렇지 않았음에도
00:07:27모든 것을 일상적인 구현 작업으로 간주한 것입니다. 애플리케이션을 테스트했을 때
00:07:31여러 문제가 발견되었습니다. 무언가를 수정하고 실행 버튼을 누르면
00:07:37제목 업데이트나 색상 조정 같은 변경 사항이 미리보기 창 외부의 컴포넌트에도 반영되었는데, 이는 일어나서는 안 되는 일이었습니다.
00:07:41게다가 모든 변경 후에 다시 실행 버튼을 누를 필요 없이 직접 동기화되기를 원했습니다.
00:07:46그래서 다시 프롬프트를 입력하여 어드바이저를 사용하여 이러한 문제를 해결하라고 지시했습니다.
00:07:51우리의 프롬프트를 받자 모델은 먼저 어드바이저 에이전트를 호출했습니다. 어드바이저는
00:07:56구현 내용을 살펴보고 두 문제의 실제 원인을 파악했습니다. 바로
00:08:00잘못된 컴포넌트 선택이었습니다. 무엇이 바뀌어야 하는지, 그리고 왜 원래의 접근 방식이
00:08:06처음부터 그런 문제들을 야기했는지 설명했습니다. 실행자는 그 가이드를 받아 앱 전체에 적용했습니다.
00:08:10다시 테스트했을 때 스트리밍이 올바르게 작동했습니다. 매번 수정 후 실행을 누를 필요 없이
00:08:16편집하는 즉시 모든 변경 사항이 반영되었습니다. 컴포넌트 간에 변경 사항이 번지는 문제도
00:08:20해결되었고 모든 것이 올바른 경계 내에서 적절하게 업데이트되었습니다. 이처럼
00:08:25의도한 대로 정확히 작동할 때도 있지만, 때로는 실행자가 작업을 충분히 작다고 가정하고
00:08:30어드바이저와 상담하지 않기로 결정하기도 합니다. 그런 경우 의도한 워크플로우를 따르도록 직접 넛지를 주어야 합니다.
00:08:35모델은 항상 작업의 복잡성을 여러분과 똑같이 판단하지는 않으며,
00:08:40오판할 경우 어드바이저가 처음부터 잡아냈을 버그를 마주하게 됩니다. 또한
00:08:44저희 콘텐츠가 마음에 드신다면 하이프(hype) 버튼을 눌러주세요. 더 많은 콘텐츠를 만들고
00:08:49더 많은 사람들에게 다가가는 데 도움이 됩니다. 실시간 분산 상태가 포함된 경우,
00:08:54이 방식도 모든 것이 제대로 작동하기까지 여러 번의 프롬프트가 필요했습니다.
00:08:58전략이 도움이 되긴 했지만, 프로젝트에 도입하기 전에 이해해야 할 한계점이 있습니다.
00:09:02단순하거나 중간 규모의 애플리케이션의 경우, 어드바이저 전략은
00:09:07Sonnet을 혼자서 한계 이상으로 밀어붙이려다 낭비하게 될 여러 라운드의 대화를 줄여줄 수 있습니다.
00:09:11가끔 깊은 추론이 필요하지만 대부분은 직접적인 구현 위주인 것을 만들고 있다면
00:09:16이것은 정말 좋은 구조입니다. 모든 결정마다 모델을 돌보거나 전체 세션을 Opus에 의존하지 않고도
00:09:20토큰 제한 내에서 더 많은 것을 빌드할 수 있습니다.
00:09:25연결된 종속성이 많거나 여러 실패 지점이 있는 복잡한 앱의 경우에는
00:09:30처음부터 Opus를 메인 에이전트로 직접 사용하는 것이 낫습니다. Sonnet이 어드바이저의 가이드를
00:09:36제대로 따르더라도, 여러 접근 방식을 동시에 평가하고 하위 결과를 따져볼 만큼의
00:09:40추론 깊이가 없어서 잘못된 구현 경로를 선택할 수 있기 때문입니다. 어드바이저가
00:09:45그 간극을 좁히는 데 도움은 되지만 완전히 메워주지는 못합니다. 그런 경우 반복되는 대화 비용이
00:09:50처음부터 Opus를 실행하는 것보다 더 많이 들 수 있습니다. 따라서 이 전략은
00:09:54빡빡한 토큰 제한 내에서 작업하고 애플리케이션이 모든 단계에서 Opus 수준의 추론을 필요로 하지 않을 때 유용합니다.
00:09:58빌드하려는 것에 이 두 가지 조건이 모두 해당된다면 설정해 볼 가치가 있습니다. 이것으로
00:10:03이번 영상을 마칩니다. 채널을 지원하고 이와 같은 영상을 계속 만드는 데 도움을 주고 싶으시다면
00:10:08아래의 Super Thanks 버튼을 이용해 주세요. 언제나 시청해 주셔서 감사드리며,
00:10:12다음 영상에서 뵙겠습니다.