00:00:00지난 몇 달 동안 저희는 BMAD, GSD, SpecKit, Superpowers를 포함한 많은 AI 코딩 프레임워크를 다루었으며, 실제로 많은 분이 이를 사용하기 시작했습니다.
00:00:08하지만 앤스로픽(Anthropic)은 최근 자체 하네스에서 구성 요소를 하나씩 제거하며 무엇이 정말 중요한지 측정하는 실험을 진행했습니다.
00:00:14그들의 결론은 대부분의 구성 요소가 이제는 불필요한 짐(dead weight)이 되었다는 것입니다.
00:00:17프레임워크의 각 구성 요소는 모델이 스스로 할 수 없는 일에 대한 가정을 담고 있는데, Opus 4.6에 이르러 그러한 가정들은 이제 낡은 것이 되었습니다.
00:00:25저희는 전체 내용을 검토하여 무엇이 여전히 중요한지, 무엇을 걷어낼 수 있는지, 그리고 현재 여러분의 설정이 실제로 어떤 모습이어야 하는지 정리했습니다.
00:00:32에이전트 하네스는 에이전트가 장기적인 과업에서 실질적으로 더 잘 작동하도록 만드는 데 중요한 역할을 합니다.
00:00:37앤스로픽은 이미 에이전트 하네스를 출시했으며, 저희는 이전 영상에서 이를 설정하고 사용하는 방법을 자세히 다룬 바 있습니다.
00:00:43같은 맥락에서 다른 프레임워크들도 다루었는데, 구현 방식은 다르지만 모두 동일한 목적을 달성하려 노력합니다.
00:00:50하지만 이러한 프레임워크들이 출시되었을 때 모델의 능력은 지금의 Opus 4.6만큼 뛰어나지 않았습니다.
00:00:55예를 들어, GSD와 같은 프레임워크는 컨텍스트 격리(context isolation)에 집중하지만, Opus 4.6에서는 그것이 더 이상 문제가 되지 않습니다.
00:01:01백만 토큰에 달하는 컨텍스트 창 때문만이 아니라, 잠시 후에 설명해 드릴 또 다른 이유 때문이기도 합니다.
00:01:06따라서 이전에 구현된 많은 프레임워크는 이제 새로운 모델 기능에 있어 오히려 오버헤드가 되고 있습니다.
00:01:11앤스로픽은 실제로 하네스의 다양한 측면을 테스트하며 각 요소를 제거했을 때의 영향력을 측정하는 실험을 진행했습니다.
00:01:17그 결과, 에이전트 하네스에 실제로 필요한 것은 기획, 생성, 평가를 위한 에이전트뿐이라는 결론을 내렸습니다.
00:01:24나머지는 현재 모델의 능력을 고려할 때 그저 불필요한 짐이 되어버린 방식들일 뿐입니다.
00:01:29핵심 이론은 어떤 에이전트 하네스를 사용하든 모든 구성 요소가 동일한 원칙에 기반한다는 것입니다.
00:01:35각 구성 요소는 모델이 스스로 무엇을 할 수 있는지에 대한 가정을 전제로 설계됩니다.
00:01:38이러한 가정들은 틀릴 수도 있고 모델이 발전함에 따라 낡아질 수 있기 때문에 스트레스 테스트를 거쳐야 하며, 기사 전체에서 그 작업을 수행했습니다.
00:01:46따라서 모델의 진화와 함께 하네스도 진화해야 하며, 몇 달 전의 원칙을 그대로 고수하고 있다면 흐름을 따라가지 못하고 있는 것입니다.
00:01:54기획(Planning)은 모든 프레임워크에서 변하지 않는 첫 단계이지만, 더 유능한 모델을 위해서는 기획 방식이 바뀌어야 합니다.
00:02:01앤스로픽의 이전 장기 실행 하네스는 사용자가 사전에 상세한 사양(spec)을 제공해야 했습니다.
00:02:06BMAD나 SpecKit 같은 프레임워크는 과업을 더 작은 조각과 마이크로 태스크로 세분화하여 AI 에이전트가 쉽게 구현할 수 있도록 돕습니다.
00:02:14이것은 단순한 작은 작업이 아니라, 에이전트가 생각할 필요 없이 그대로 따르기만 하면 되는 말 그대로 상세한 단계들이었습니다.
00:02:20당시 모델들은 충분히 유능하지 않았기에 사용자가 원하는 대로 수행하려면 아주 세밀한 안내가 필요했기 때문입니다.
00:02:27하지만 Opus 4.5와 4.6에 와서 상황이 바뀌었습니다.
00:02:30앤스로픽의 테스트 결과, 기획자가 사전에 세부적인 기술 명세를 지정하려 할 경우 단 하나의 오류가 모든 구현 단계로 전이되어 에이전트가 스스로 경로를 수정하기 어렵게 만든다는 것을 발견했습니다.
00:02:43모든 것이 기획안이 얼마나 잘 작성되었는지에만 의존하게 되는 것입니다.
00:02:45따라서 이제 기획은 상세한 기술적 구현보다는 높은 수준(high-level)의 가이드가 되었습니다.
00:02:50에이전트들은 이제 스스로 훨씬 똑똑해졌으므로, 여러분은 어떤 결과물이 필요한지만 말해주면 됩니다.
00:02:55그들은 목표에 도달하는 경로를 스스로 찾아낼 수 있습니다.
00:02:57이러한 변화로 인해 BMAD나 SpecKit 같은 기획 방식은 더 이상 예전만큼 유효하지 않습니다.
00:03:02기술적인 세분화 과정 없이 PRD(제품 요구 사양서) 생성까지만 BMAD를 기획 단계에 제한적으로 활용할 수 있습니다.
00:03:08이전에 언급했듯이 BMAD를 통한 PRD 생성은 효과적인데, Claude 단독보다 제품 요구 사항을 더 잘 이해하도록 특화된 에이전트를 보유하고 있기 때문입니다.
00:03:18이는 해당 에이전트들이 제작자에 의해 추가된 특정 과업에 대한 외부 컨텍스트를 가지고 있기 때문입니다.
00:03:23또는 Superpowers의 질의응답 세션을 사용할 수도 있는데, 이는 예외 사례를 식별하도록 설계되어 다단계 작업 문서화보다 더 효과적일 수 있습니다.
00:03:32하지만 지나치게 상세한 기획의 핵심 문제는 에이전트를 제약하여 AI가 스스로 무언가를 발견하고 해결할 여지를 남기지 않는다는 점입니다.
00:03:40앤스로픽은 기획자 에이전트가 생성한 기획안 예시도 제공했는데, 이를 참고하여 여러분만의 기획자 에이전트를 설정할 수 있습니다.
00:03:46이 예시는 기획안이 범위를 크게 잡고 여러분이 제공한 앱 아이디어의 경계를 확장해야 함을 명확히 보여줍니다.
00:03:52핵심 아이디어는 프로젝트를 구현 수준이 아닌 제품 수준(product level)에서 유지하는 것입니다.
00:03:56프로젝트 기획 내에서 구현 세부 사항을 기획하려 들면 기술적 디테일에만 너무 매몰되어 완전한 제품에 필요한 실제 요소를 놓칠 수 있기 때문입니다.
00:04:06Claude의 자체 '플랜 모드'도 질문을 던지고 상세 기획을 제공하니까 비슷하다고 생각하실 수 있습니다.
00:04:12하지만 차이점이 있습니다. Claude에도 기획 에이전트가 있지만 여전히 구현 세부 사항에 크게 치중하며, 제품 수준에서 진정으로 작동하지 않아 앤스로픽의 발견과는 상충됩니다.
00:04:22따라서 이 시스템을 갖추고 나면 Claude에게 직접 만든 에이전트를 사용하여 앱을 기획하라고 요청하기만 하면 됩니다. 그러면 전체 기획안을 생성하고 진행에 따라 폴더에 문서화할 것입니다.
00:04:31이 기획안은 제품 수준의 전체 기능 분석을 포함하며, 각 단계에는 사용자의 관점을 보여주는 사용자 스토리(user stories)가 포함됩니다.
00:04:40이는 Claude가 사용자가 실제로 기대하는 올바른 워크플로우를 구현하는 데 도움을 줍니다.
00:04:44다음으로 넘어가기 전에, 저희 후원사인 Minimax에 대해 잠시 말씀드리겠습니다.
00:04:47AI 에이전트를 설정하는 것은 악몽과도 같습니다. API 키, 서버 설정, Docker 구성까지 마쳤는데도 탭을 닫는 순간 어시스턴트가 모든 걸 잊어버리곤 하죠.
00:04:56해결책은 바로 손끝에서 만나는 클라우드 기반 AI, MaxClaw입니다.
00:04:59복잡한 설정이나 고민 없이 여러분만의 OpenClaw를 배포할 수 있습니다.
00:05:02배포 버튼만 누르면 10초 안에 활성화됩니다. 간단한 텍스트 프롬프트만으로 웹사이트를 구축하고, 코드를 작성하며, 조사를 수행하고 반복적인 업무를 자동화합니다.
00:05:12MaxClaw는 Telegram, Slack, Discord 등과 직접 연결되어 간단한 채팅만으로 워크플로우를 자동화하고 웹을 검색하며 이미지나 영상까지 생성할 수 있게 해줍니다.
00:05:21누구나 에이전트 디자이너가 될 수 있는 AI 네이티브 작업 공간인 Minimax Agent의 일부입니다.
00:05:27Mac과 Windows에서 작동하며, SWE-bench에서 Claude Opus 4.6과 대등한 성능을 보이는 M 2.7 모델을 기반으로 합니다.
00:05:33복잡한 설정과 씨름하지 마시고 MaxClaw에 맡기세요. 고정 댓글의 링크를 클릭하여 시작해 보세요.
00:05:39코드를 작성하는 에이전트가 그 코드를 직접 평가해서는 안 됩니다.
00:05:42이것은 두 번째로 흔한 문제임에도 불구하고 평소에는 잘 논의되지 않는 부분입니다.
00:05:46자기 평가는 문제가 될 수 있습니다. 코드를 쓴 에이전트가 직접 평가하게 하면 품질이 분명히 떨어지는데도 매우 자신 있게 응답하며 자신의 작업물을 칭찬하는 경향이 있기 때문입니다.
00:05:56구현된 API가 실제로 작동하는지 여부와 같이 정량적 지표가 있는 작업에서는 관리가 쉬울 수도 있습니다.
00:06:03하지만 명확하게 검증 가능한 결과가 없는 작업에서는 이 문제가 훨씬 더 두드러집니다.
00:06:08가장 큰 예가 바로 UI입니다.
00:06:10무엇이 좋은 UI인지는 주관적이며, AI는 여러분의 의도를 완전히 파악하지 못할 수도 있습니다.
00:06:15여러분의 기준에 미치지 못하더라도 AI는 자신의 구현이 잘 되었다고 판단할 수 있습니다.
00:06:19이 문제는 이미 여러 프레임워크 제작자들에 의해 인식되었으며, 이를 해결하기 위해 자체적인 평가 메커니즘을 도입했습니다.
00:06:26저희가 다룬 GSD, BMAD, Superpowers와 같은 모든 프레임워크는 코드를 작성한 에이전트가 품질 평가를 직접 하지 않도록 보장합니다.
00:06:34이러한 접근 방식은 에이전트 평가의 정확성과 신뢰성을 크게 향상시킵니다.
00:06:39따라서 기존 프레임워크를 사용하든 직접 구축하든, 평가자(evaluator)와 구현자(implementer)를 완전히 분리해야 합니다.
00:06:47구현이 시작되기 전에 생성자 에이전트와 평가자 에이전트는 계약을 맺어 작업의 "완료" 기준이 무엇인지 합의합니다.
00:06:54이는 두 에이전트 모두 무엇을 달성해야 하고 무엇을 검증해야 하는지 명확히 알 수 있게 해주어 도움이 됩니다.
00:06:58상위 수준의 기획에서도 여전히 실행 가능하고 구현 가능한 단계들이 필요합니다.
00:07:02하지만 하네스 테스트 중에 '스프린트 계약' 단계를 제거해 보았습니다.
00:07:06그 결과 Opus 4.5는 평가자가 여전히 개입하여 문제를 잡아내야 했기에 효율성이 떨어지는 것으로 나타났습니다.
00:07:12그러나 Opus 4.6에서는 모델의 능력이 크게 향상되어 이러한 계약 단계가 더 이상 필요하지 않았습니다.
00:07:18생성 에이전트가 대부분의 작업을 스스로 처리할 수 있을 정도로 유능해졌기 때문입니다.
00:07:22따라서 Sonnet이나 Haiku 같은 작은 모델의 경우에는 여전히 작업 문서화가 필요합니다.
00:07:27작업을 스프린트 구조로 적절히 나누고, 각 에이전트가 "완료"의 정의에 합의하도록 해야 합니다.
00:07:32하지만 더 유능한 모델을 사용한다면 이러한 추가 단계 없이도 Opus가 상위 기획을 실행하도록 믿고 맡길 수 있습니다.
00:07:38앞서 컨텍스트 격리가 중요한 이유가 있다고 말씀드렸습니다.
00:07:42그 이유는 작은 모델들이 '컨텍스트 불안(context anxiety)'을 겪기 때문인데, 이는 컨텍스트 창이 채워짐에 따라 긴 작업에서 일관성을 잃기 시작하는 현상입니다.
00:07:51이런 현상이 발생하면 모델은 작업을 조기에 마무리하고 실제로는 구현하지 않았으면서도 올바르게 완료했다고 주장하곤 합니다.
00:07:57도움이 되었던 해결책은 '컨텍스트 리셋'으로, 구현을 시작하기 전에 컨텍스트 창을 비우는 것이었습니다.
00:08:02컨텍스트가 초기화되었기 때문에 리셋 후에도 유지되는 외부에 문서화된 작업 명세에 의존할 수 있었습니다.
00:08:08하지만 모델들이 겪는 컨텍스트 불안이 너무 심해서 압축(compaction)만으로는 충분하지 않았습니다.
00:08:13긴 작업에서 발생하는 문제를 방지하기 위해 추가적인 조치가 필요했습니다.
00:08:17그러나 Opus 4.5부터는 모델들이 더 이상 이런 행동을 보이지 않습니다.
00:08:21이 에이전트들은 전체 세션 동안 지속적으로 실행될 수 있으며, Claude의 압축 처리 방식만으로도 충분히 작동 가능합니다.
00:08:28따라서 컨텍스트 리셋은 더 이상 필요하지 않으며, BMAD나 SpecKit과 같은 상세한 작업 분류도 필요 없이 상위 수준의 가이드만으로 충분합니다.
00:08:37생성자(generator) 에이전트는 기능을 하나씩 실제로 구축하는 주된 구현자입니다.
00:08:42기획안의 사양을 가져와 지속적으로 구현하며, 버전 관리를 위해 Git과 통합됩니다.
00:08:47생성자는 평가자 에이전트와 협력하여 작업합니다.
00:08:50기능을 빌드한 후 테스트를 위해 넘기고, 구현을 개선하기 위한 피드백을 받습니다.
00:08:56워크플로우는 작업 이해, 구현, 구현 정제의 여러 단계로 조직되어 있습니다.
00:09:02구현 단계 내에서도 작업은 다양한 측면을 다루는 네 가지 하위 단계로 나뉩니다.
00:09:07디자인 방향을 따르고, 작업을 검증한 다음 평가자에게 전달합니다.
00:09:11이는 구조화된 단계별 패턴을 만들어 에이전트가 독립적이고 체계적으로 앱 전체를 구현할 수 있게 합니다.
00:09:18평가자 에이전트는 생성자에 대한 적대자(adversary) 역할을 합니다.
00:09:21그 임무는 앱이 올바르게 구현되었는지 확인하는 것인데, 단순히 일반적인 "버그 찾기"를 하는 것이 아니라 버그가 반드시 존재한다는 비판적인 관점으로 접근합니다.
00:09:30Playwright와 같은 도구를 사용하여 사용자 상호작용을 시뮬레이션함으로써 앱을 테스트하고, 사전 정의된 기준에 따라 버그를 식별하여 생성자에게 피드백을 보낼 수 있습니다.
00:09:39평가자는 기획안을 읽음으로써 "완료"가 어떤 모습이어야 하는지 명확히 이해하고 승인 전에 모든 것을 철저히 확인합니다.
00:09:46프레임워크마다 자체 검증 도구가 있지만 접근 방식은 상당히 다릅니다.
00:09:50BMAD는 테스트를 생성하고 실행하는 전문 코드 리뷰 및 QA 에이전트를 사용하여 다각도로 코드를 평가합니다.
00:09:57GSD는 구현 내용을 기존 기획안과 대조하여 확인하고 문서 보고서를 작성하는 검증 하위 에이전트를 사용합니다.
00:10:04Superpowers는 새로운 하위 에이전트들에 의존하며, 테스트 케이스 작성 전에는 어떤 코드도 쓸 수 없는 엄격한 TDD를 강제합니다.
00:10:10에이전트가 이를 우회하려고 하면 차단됩니다.
00:10:13SpecKit은 사양(spec)을 진실의 원천으로 여기며 에이전트가 문서를 바탕으로 코드를 검증하도록 합니다.
00:10:18하지만 이러한 프레임워크 중 어느 것도 앤스로픽이 지향하는 수준의 엄격한 점수 산정 메커니즘을 제공하지 않습니다.
00:10:24따라서 앤스로픽 하네스의 평가자는 Ralph Loop의 엄격한 Claude 구현 강제 방식과 가장 유사하며, 적절한 등급 평가 메커니즘을 통해 에이전트가 필요한 결과물을 실제로 인도하도록 보장합니다.
00:10:35또한 저희 콘텐츠가 마음에 드신다면 하이프(hype) 버튼을 눌러주세요. 더 많은 콘텐츠를 제작하고 더 많은 분께 다가가는 데 큰 도움이 됩니다.
00:10:43에이전트는 특히 구현 내용이 정량화할 수 없는 경우 무엇이 여러분에게 적합한 출력물인지 알 방법이 없습니다.
00:10:49따라서 등급 기반 평가 메커니즘을 사용하여 에이전트가 여러분에게 올바른 출력물의 기준이 무엇인지 알게 해야 합니다.
00:10:54앤스로픽이 프런트엔드 평가 지표의 예시를 들었을 때, AI가 대부분의 경우 유사한 출력물로 수렴하는 경향이 있다고 언급했습니다.
00:11:02그들은 생성자와 평가자 에이전트 모두를 위해 네 가지 등급 기준을 설정했습니다.
00:11:06첫 번째는 디자인 품질로, 필드가 일관성이 있는지 아니면 그저 별개의 컴포넌트들을 나열한 것뿐인지 확인하도록 지시합니다.
00:11:12다음은 독창성입니다. AI가 대부분의 UI에서 동일한 보라색과 흰색 그라데이션 패턴을 기본값으로 사용하는 경향이 있기 때문에 매우 중요합니다.
00:11:19이는 인간의 디자인 방식과 상충됩니다. 인간에게 디자인 선택은 의도적이며, 그렇기에 웹사이트가 좋지 않아 보일 때 쉽게 식별할 수 있기 때문입니다.
00:11:27세 번째는 완성도(craft)로 타이포그래피, 간격의 일관성, 색상 조화 같은 미세한 디테일을 의미하며, 단순히 대비율을 기술적으로 맞추는 것을 넘어 창의적인 느낌을 주는지 확인합니다.
00:11:37마지막은 기능성입니다. UI 측면에서 각 컴포넌트는 사용자 경험을 향상시키는 시각적 역할을 수행하기 때문입니다.
00:11:44Claude는 이미 완성도와 기능성에서는 좋은 점수를 받지만 나머지 부분에서 주로 어려움을 겪으므로, 최고의 디자인은 품질에서 나온다는 점을 강조하여 프롬프트로 몰아붙여야 합니다.
00:11:54따라서 앱을 빌드할 때 코드 아키텍처, 프런트엔드, UX 사용자 흐름 등 원하는 만큼 많은 기능에 대해 유사한 기준을 설정할 수 있습니다.
00:12:02기준에 언급된 각 부분에 전용 점수를 부여하여 모델이 성과에 따라 중요도를 식별할 수 있도록 하세요.
00:12:10이 파일들은 평가자 에이전트에서 참조됩니다. 평가자의 역할은 점수를 매기는 것이므로 어떤 루브릭(rubric)을 따라야 하는지 알아야 하기 때문입니다.
00:12:17지금까지 다룬 내용을 바탕으로 이제 무엇을 해야 할지 궁금하실 것입니다.
00:12:21설정을 더 쉽게 만들어줄 프레임워크를 원한다면 GSD를 선택하세요. GSD는 기본적으로 기획-생성-평가 루프를 사용하지만, 평가자가 코드를 기존 계획과 대조만 하며 사용자 수용 테스트에 의존합니다.
00:12:35이는 점수 기반 구현이 아닌 통과/실패 방식입니다. 따라서 앤스로픽 프레임워크의 장점을 가져와 GSD와 결합할 수 있습니다. 예를 들어 평가자 에이전트를 바꾸고 기준표와 결합하여 에이전트가 올바른 구현이 무엇인지 알게 하는 식입니다.
00:12:49하지만 앤스로픽의 프레임워크를 직접 설정하여 사용하고 싶다면, 각 역할에 따른 에이전트를 생성하고 '에이전트 팀' 기능을 사용하여 협업하게 함으로써 구현할 수 있습니다.
00:12:58에이전트 팀원 중 한 명은 생성자로, 다른 한 명은 평가자로 활용할 수 있습니다.
00:13:03에이전트 팀을 사용하는 이유는 에이전트끼리 서로 소통할 수 있기 때문입니다. 하위 에이전트들은 직접 소통할 수 없어 문서에 써야 하므로 오버헤드가 발생합니다.
00:13:10따라서 Claude는 상위 기획에서 작업을 생성하고 두 에이전트를 동시에 만듭니다. 하나는 구현을 하고 다른 하나는 브라우저와 Playwright MCP를 사용하여 테스트를 실행하며, 생성자의 업데이트를 기다려 테스트 프로세스를 시작합니다.
00:13:24평가자는 지속적으로 작업을 검증하고 생성자와 문제를 소통하며, 이들은 협력하여 여러분의 기준에 맞는 전체 앱을 구현해 나갑니다.
00:13:33이번 영상에서 사용된 모든 에이전트와 리소스는 AI Labs Pro에서 이용 가능하며, 이전 영상들의 자료도 다운로드하여 여러분의 프로젝트에 활용하실 수 있습니다.
00:13:43저희의 활동이 가치 있다고 느끼시고 채널을 후원하고 싶으시다면 이것이 가장 좋은 방법입니다. 링크는 설명란에 있습니다.
00:13:48이것으로 이번 영상을 마칩니다. 채널을 지원하고 이런 영상을 계속 제작하는 데 도움을 주고 싶으시다면 아래 'Super Thanks' 버튼을 이용해 주세요.
00:13:57언제나 시청해 주셔서 감사드리며, 다음 영상에서 뵙겠습니다.