영상: Is Your AI Coding Agent Gaslighting You?
채널: Jason Weimann (GameDev)
길이: 15m 55s
출처: 자막 (수동, 영어)
스크립트:
무엇부터 시작할까요? 테스트 주도 개발(test-driven development)을 위해 흥미로운 커스텀 하네스를 사용하고 계신 것 같네요. 그 후에 제가 하고 있는 게임 개발 관련 내용을 보여드리고 싶습니다. 재미있을 거예요. 네. 어, 저 최근에 이와 관련해서 작은 YouTube 영상을 만들었는데요, 덴버에서 열린 Domain-Driven Design Conference에 갔었습니다. 거기에서는 에이전트를 제어하는 것에 대한 이야기가 많았고, 그들이 테스트 주도 개발을 할지, 아니면 심지어 테스트 주도 개발을 하는 것이 가치가 있는지에 대한 이야기였습니다.
그리고 음, 그래서 AI 가스라이팅이라는 주제가 많이 나왔는데, AI가
음, 그리고 정말 흥미로운 점은요. 왜냐하면 제가 비교적, 음, 똑똑하지 않은 작은 모델들로도 에이전트 코딩을 할 수 있게 하는 것을 볼 수 있기 때문입니다. 그래서 비디오에서는 Gemma 4 모델을 사용했는데, 이 모델은 VRAM 8기가 안에 들어가는 정도의 크기예요. 저는 16기가 VRAM 카드를 가지고 있지만, 제 YouTube 영상에서는 본질적으로 TDD(테스트 주도 개발)로 tic-tac-toe 카타를 수행할 수 있었습니다. 이건 일종의 간단한 문제지만, 저는 심지어 이게 에이전트 코딩과 하네스에 대해 안다고 주장하는 사람에게 면접 질문이 될 수도 있다고 생각했어요. 예를 들어, '가장 좋아하는 하네스를 골라 Gemma 4로 TDD를 수행하게 하고 결과물을 보세요' 같은 식으로요. 하지만 네, 그래서 저는... 정말 이상한 엣지 케이스 문제인 것 같아요—
당신과 다른 여섯 명이 이 면접 질문을 통과할 거라고 생각해요. 네, 맞아요. 음, 이건 하네스의 내부 구조에 대해 너무 많이 알아야 하는 것에 가깝습니다. 만약 그런 것에 관심이 있다면, 그것을 보여줄 멋진 방법이에요. 컨퍼런스에 있던 사람 중 한 명은 pi 하네스를 사용하고 있었는데, 이게 그냥 미니멀리스트 하네스라고 합니다. 이것은 많은 벤치마킹에서 사용되며 심지어 MCP 서버가 기본적으로 제공되지 않습니다.
MCP 지원을 추가하려면 별도의 패키지를 다운로드해야 해요. 그리고 YOLO 모드 등 모든 것이 기본적으로 그렇습니다. 그래서 컨텍스트를 많이 포함하고 있지 않아요. 대부분의 에이전트 시스템은 시작하는 것만으로도 60K 토큰, 심지어 40K 토큰을 요구합니다. 그런데 이 pi 하네스는 매우 최소한적인 내용들로 구성되어 있어요. 그래서 저는 pi 하네스를 TDD MCP와 위험 인지 커밋 노트 MCP와 결합하고, '시작'이라고 말할 수 있게 만들었습니다. 그리고 만약 잘못된 행동을 한다면, '현재 상태가 잘못되었습니다.'라고 부드럽게 알려줄 수 있습니다.
‘이런 식으로 통과시키거나, 이 정도의 코드 커버리지를 확보해야 한다’는 식입니다. 그리고 Claude Sonnet 같은 것에 적용했을 때는 정말 테스트를 연달아 돌리는 것 같았습니다. 제가 알아차린 한 가지 점은 AI 에이전트들이 여러 개의 도구 호출(tool calls)을 큐에 쌓는다는 것입니다. 만약 이 에이전트가 연속으로 작동하는 10개의 도구 호출을 추측하고, 그 모든 것이 성공적이라면 테스트 주도 개발(TDD)의 결과를 만들어내고 MCP를 가능한 한 빨리 통과시킬 수 있습니다. 그런데 어떤 환경에서는 실제로 예상치 못한 결과가 나올 때만 리디렉션을 시도합니다.
그래서 저는 이것이 정말 흥미롭다고 생각했습니다. 온갖 것들을 TDD 하려고 시도하고, 여러 명령을 실행한 다음 ‘네, 이제 성공입니다’라고 말하는 식이었지만, 실제로는 초기에 오류가 발생했던 것입니다. 그래서 일부 환경에서는 어떤 도구 호출이 사용될지 미리 예측하여 보여주기 때문에, 여전히 사용자에게 일종의 가스라이팅을 하는 것 같습니다. 그래서 이 부분에 대해 두 가지 질문이 있습니다. 첫 번째는 Uri와 많이 이야기해 봤는데, Uri가 당신에게 실제로 가치를 제공하는 작업을 하고 있는지 물어봤습니다.
그리고 당신은 테스트 프로젝트나 예시 테스트 프로젝트를 수행하도록 시키는 것에 대해 이야기하고 계신 것을 알고 있습니다. 그리고 다른 하나는 AI가 테스트 주도 개발(TDD)을 하는 것이 중요하거나 필수적인지, 아니면 그럴 필요가 없는지에 대한 생각입니다. TDD라는 것이 꼭 필요한 것일까요? 그냥 모든 것에 표준 통합 테스트(integration tests)를 수행하면 될까요? 제가 모르는 다른 종류의 테스트를 해야 할까요? 저는 이것이 지금 정말 인기 있는 주제라고 생각합니다. 어떤 사람들은 시스템이 너무 커지고 있어서 결국에는 테스트 주도 개발을 원한다고 믿는 반면, 또 다른 사람들은 정반대의 입장에 있습니다.
어떤 기사를 봤는데, 지금 링크를 가지고 있진 않지만, 아, 여러 저명한 저자들이 참여한 논문이 있었어요. 그들이 에이전트 개발에 대한 패턴들에 대해 이야기하고 있었거든요. 핵심은요, 코드를 검토해야 할 풀 리퀘스트(pull requests)가 너무 많이 들어오고 있다는 거예요. 어떻게 하면 리뷰어의 시간이 낭비되지 않도록, 같은 내용을 반복해서 검토하는 상황을 피할 수 있을까요?
그래서 이런 자동화 작업들이 많아요. 사전에 체크하는 것들 말이에요. 그래서 당연히 테스트 주도 개발(test-driven development)이 되겠죠. 컨퍼런스에서 나온 아이디어는 AI 가스라이팅이, 그러니까 필요한 테스트 세트를 예측한다는 거예요. 그래서 실제로 테스트 주도 개발을 하든 안 하든 상관없다는 거죠. 하지만 인간의 경우, 그리고 제가 이야기하는 많은 사람들의 입장에선, '이 테스트가 존재해야 한다'는 사실 자체가 저에게 문제에 대해 다르게 생각하게 만들고, 더 확장하도록 만듭니다.
그래서 질문은요, 에이전트가 모듈성(modularity)과 장기적인 유지보수 측면에서 문제를 다르게 생각하도록 할 수 있냐는 거예요. 이게 실험의 핵심이고, 제가 Gemma 4 같은 성능이 낮은 모델로 내려가는 이유도 바로 그거예요. 그 모델들에서는 실수를 많이 하는 것을 정말 잘 볼 수 있거든요. 그래서 질문은요, 이들이 실수를 덜 하도록 만들거나, 혹은 실수로부터 수정할 수 있게 할 수 있냐는 거예요. 그런데 모델들이 계속 좋아지면 이게 과연 유용할까요?
예를 들어, 1년 후에도 이것이 유용한 것일지 아니면 단지 조금 배우고 실험해 본 것에 그칠지가 궁금합니다. 음, 그래서 저는 좋은 하네스(harnesses)와 제어권을 갖는 것에 대해 더 많이 배우는 데 특히 관심이 있습니다. 하지만 저에게는 여정 자체만으로도 유용합니다. 왜냐하면 저는 이런 것들의 내부 작동 방식에 대해 아는 것을 좋아하기 때문입니다. 음, 제가 오늘 말씀드리려고 보내드린 다른 링크에서도 LLM 스케일링의 한계와 우리가 과연 LLM이 우리를 위해 할 수 있는 것에 대한 한계에 도달하고 있는지 여부에 대해서도 이야기하고 있었습니다.
그래서 저는 하네스 분야에서 발전할 공간이 많다고 생각합니다. 하지만 모델들은 정점 성능(peak capability)에 가까워지고 있습니다. 그리고 흥미로운 점은, MIT의 Dan Grib 유튜브 영상 같은 것인데요. 그가 'MIT가 LLM 스케일링의 근본적인 한계를 발견했으며, 돈으로 해결할 수 없다'고 말합니다. 그래서 영상 말미에는 사람들이 작업하고 있는 다른 모델들이 있다고 이야기합니다. 하지만 그것은 흥미로웠습니다...
아시다시피, 그 영상에서는 능력의 재정적 상한선뿐만 아니라 이러한 것들의 수학적 상한선에 대해서도 이야기합니다. 따라서 우리가 이 모델들의 스케일링 능력의 논리적인 끝점에 도달했다고 가정한다면, 큰 성능 향상은 정말 좋은 하네스와 더 많은 양의 컨텍스트(context)를 처리할 수 있도록 만드는 것에서 나올 것입니다. 그래서 저는 이것에 아마 가치가 있다고 생각합니다. 왜냐하면 아무리 초능력 AI가 있어도, 그것이 마땅히 해야 할 일을 하고 있는지, 그리고 그 이유가 무엇인지 알기 때문입니다.
음, 그리고 음... 어, 그래서 주목도(saliency)와 제어(control)가 앞으로는 역량 강화(capability enhancements)보다 동등하게 중요하거나 아니면 더 중요해질 것입니다. 특히 예를 들어 모델을 인간의 관심사에 맞춰 정렬하는 것이요. 음- 음- 그래서, 그 효율성에 대해 이야기하고 있는데, 음- 음- Gemini 4, 당신이 아는지 모르겠지만, 혹시 이 게시물들에서 이것이 아레나(arena)에 있고 테스트되고 있으며 경쟁사 대비 비용이 현저히 낮다는 내용들을 다 봤다고 가정하겠습니다.
맞아요. 만약 그들이 그것을 할 수 있다면, 엣지 근처에서는 어떻게 연결되나요? 그냥- 네, 그래서... 더 많은 하네스 작업인가요, 아니면 다른 종류의 것인가요, 아니면- 두 가지가 있어요... 그게 엣지인가요? 네, 그래서 그 비디오에는 제가 정말 눈에 띄었던 부분이 두 군데 있습니다. 음, 아시다시피, 약 2분쯤에서, 단어들의 중첩(superposition)에 대해 이야기하고, 그리고 약 4분 50초쯤에서는 모델의 비용에 대해 이야기합니다.
음, 그래서 모델의 비용이 모델에서 모호성을 제거하려고 할 때마다 두 배가 된다는 겁니다. 음, 그리고 그것은 자라고, 그리고, 그리고 기본적으로- 잠깐만요, 그걸 조금 설명해 주시겠어요? 네. 저는 고개를 저었지만, 제가-- 확실해요. 모호성을 제거하고 싶을 때마다 두 배가 되나요? 네, 그래서, 그래서 기본적으로, 음, 그가 비디오에서 중첩에 대해 이야기할 때, 공간을 보존하기 위해 모델은 특정 무관한 용어 그룹의 벡터 크기를 줄일 것이라고 말합니다.
그리고 그들이 더 가까이 있을 때는 모델이 혼란을 겪게 되는데, 왜냐하면 다른 단어들을 부분적으로 활성화시키기 때문이죠? 음, 그래서 어떻게 하냐면 모델의 크기를 두 배로 늘리고, 그러면 그 단어들에 대한 중첩(superposition)이 증가합니다. 그리고- 음- 그러니까 작은 모델들은 다양한 용어들 때문에 더 혼란을 겪고, 큰 모델들은 그렇지 않다는 겁니다. 왜냐하면 벡터 공간에 실제로 단어들 사이에 더 큰 거리를 둘 수 있는 공간이 많기 때문에 모호성이 제거되기 때문이죠.
흥미롭네요. 그래서 그는 기본적으로 비용 상한선(cost upper limit)에 대해 이야기하고 있고, 저는 여기 큐브 모양의 작은 그래픽을 보고 있어요. 하지만, 음, 아시다시피,
