월요일에 제가 예전에 즐겨 하던 오래된 게임을 보여주면서, 이 게임에 대한 새로운 아이디어를 어떤 방식으로 낼 수 있을지 물어봤습니다. 그리고 간식을 가지러 아래층으로 내려갔다가 다시 올라왔는데, 그 AI가 이미 게임 데모를 실행하고 있는 것을 발견했습니다. '오, 예전 Xbox 게임인데' 싶었지만, 그래도 확실히 10분도 채 안 되는 시간 동안 진행되고 있었습니다. 그래서 오케스트레이션 채팅(orchestration chat)을 돌렸더니 약 25~27개의 서브 에이전트(sub agents)가 작동하고 있었고, 이들은 모두 각기 다른 작업들을 수행하고 있습니다. 제가 질문을 던지면 되는데, 이 AI는 저에게 비디오를 제공하는 데 너무 익숙해서, 그냥 영상을 녹화해서 제 휴대폰으로 보내게 됩니다.
제가 말씀드린 것처럼, 이건 일종의 틱톡 기반 개발(tick-tock driven development)과 같습니다. 그래서 저는 인스타그램 릴스나 쇼츠, 테크 토크 같은 것들을 계속 해왔습니다. 그리고 이 영상들을 만들어 달라고 요청했습니다. 이제는 게임이 플레이되는 초상화 비디오를 저에게 제공합니다. 제가 사이드 프로젝트로 진행하는 비디오 게임 등에 대해 지속적으로 이런 진척 상황의 비디오들이 저에게 전달되고 있습니다. 심지어 엔터프라이즈(enterprise) 환경에서도 사용하기 시작했습니다.
'이것에 대한 영상을 만들어라', '저것에 대한 영상을 만들어라'와 같이요. 그리고 정말 멋진 점은 영상 요청입니다. 이전에 모델들은 알지 못했던 것들을, 반드시 시도해 보지 않았던 것들까지 돌려준다는 겁니다. 예를 들어 유닛 테스트(unit tests)가 통과된 경우 같은 것이죠. 이제는 비디오의 프레임들을 확인한다는 식입니다. 한 가지 하는 일이 많은 것은 비디오를 프레임 단위로 잘라내고, 그 모든 스크린샷을 띄워준다는 것입니다. 네, 정확합니다. 정말 100장의 스크린샷 같은 것을요.
예를 들어, '이 부분은 스크린샷에서 잘못되었다'고 제가 발견하면, AI가 돌아가서 그것을 반복적으로 수정합니다. 그러면 정말 좋은 루프가 만들어지는데, 즉 프론티어 모델(frontier model)이 무언가를 계속해서 개선하는 과정입니다. 제가 보기에는 토큰 사용량이 매우 적습니다. 왜냐하면 비디오 녹화나 스크린샷 캡처 같은 작업들을 시스템화했기 때문입니다. 이런 것들은 토큰을 많이 소모하지 않습니다. 그저 이중으로 활용되는 것입니다. 스크립트를 한 번 만들면 그것을 계속해서 재사용하는 식이죠.
이것은 정말 큰 장점인데, 저희는 '결정론 추출(extract determinism)'에 대해 많이 이야기합니다. 대규모 언어 모델(LLM)들은 비결정적(non-deterministic)이기 때문입니다. 따라서 여러분이 하고 싶은 것은 반복적으로 수행하는 프로세스에서 결정론을 뽑아내는 것입니다. 만약 대규모 언어 모델이 같은 과정을 다시 생각하도록 한다면, 그것은 아마도 스킬(skill)이나 스크립트에 넣지 않았기 때문일 수 있습니다. 그러면 토큰만 계속해서 소모하게 됩니다. 따라서 항상 해야 할 일은 이러한 반복적인 작업들을 MCP 서버나 기타 중앙 집중식 시스템으로 가져오는 것입니다.
현재 저에게 가장 중요한 것은 클라우드 코드에서 원격 제어하는 것입니다. 저는 휴대폰을 사용하고 단 하나의 채팅만을 이용하는데, 이 채팅이 20개 또는 30개의 서브 에이전트(sub agents)를 분산시켜서 각기 다른 작업들을 수행하게 합니다. 제가 '팬 아웃(fan out)' 방식을 사용하는 것이 좋습니다. 개별적인 에이전트들을 따로 띄워 유지하고, 그들끼리 소통하게 하는 방식이 훨씬 좋다는 것을 알았습니다. 토큰 측면에서도요. 네. 그래서 제 게임의 경우, 아티스트, 프로그래머, 디자이너를 두고 각각 독립적으로 책임을 지게 합니다. 그리고 이들이 개발을 중단하지 않으면서 디자인에 대해 소통하고 아이디어를 주고받도록 하는 것입니다.
그리고 저는 토큰 사용량이 정말, 정말 적다는 것을 알게 되었습니다. 그것을 시도해 보겠습니다. 제가 울트라 코드(ultra code)를 사용하거나 새로운 서브 에이전트를 구동할 때 토큰 사용량을 소모하는 경우, 매우 빠르게 소진될 수 있었는데, 이 모델로 전환하니 속도가 느려졌습니다. 그래서 진행 상황은 동일했습니다. 저는 오케스트레이터에게 토큰 사용량에 대해 이야기했는데, 처음 시도했을 때는 정말 빨리 소진되었기 때문입니다. 그리고 제가 여러 최적화 작업을 추가했습니다. 그래서 이제는 거의 소비하지 않습니다. 음, 시간적인 측면에서요.
그래서 저는 왜 이렇게 많은 토큰을 소모하는지 그것에 대해 이야기하고 있었습니다. 마치 "아, 컨텍스트를 새로 고치고 오래된 채팅 기록 등을 시작하기 때문입니다"와 같이 말입니다. 그래서 그곳에 캐싱 기능이 구현되어 있었습니다. 음, 하지만 저는 다른 채팅들, 그러니까 제가 모든 곳에 이름이 지정된 채팅을 가지고 있는 것을 좋아해서 그것에 대해 생각하고 있었습니다. 그런데 제가 정말 좋아하는 것은 기본적으로 오케스트레이터가 여러 컨텍스트(context)를 관리한다는 것입니다. 물론 인간의 컨텍스트도 포함해서요. 저에게 어떤 작업을 해야 하는지, 예를 들어 결제나 다른 것들에 기반하여 과제를 제공해 줍니다.
그리고 그것이 여러 곳에 위임합니다. 그래서 저는 "논문을 작성하는 데 에이전트 15명을 전담시키고, 두개골 생존자(skull survivor)를 위해 5명을 전담시키겠다"라고 말할 수 있습니다. 그러면 그들이 모두 분산되어 각자의 일을 하고 나중에 자신이 한 일에 대한 비디오로 돌아옵니다. 음, 그리고 네, 무언가를 구동할지 아니면 해제할지를 결정하는 것이 저에게는 매우 큰 부분이었습니다. 그래서 별도의 채팅보다는 서브 에이전트를 사용하는 것입니다. 하지만 저는 별도 채팅 방식에 대해서도 생각하고 있었습니다.
서브 에이전트를 사용함으로써 실제로 속도 향상을 느끼고 계신가요? 제가 관찰했던 것과 다를 수도 있지만, 무언가를 빠르게 구축한 다음에는 그 작업의 시간과 노력을 3~4배 더 들여서 병합하고 나중에 수정하는 데 쓰는 경향이 있었습니다. 모든 것이 일종의 병렬로 진행되었기 때문에, 저는 결국 아티스트만 단독으로 작동하게 하고 개발도 자체적으로 단독 시스템을 운영하게 했을 때, 새로운 기능이나 시스템 같은 것들을 5분, 10분 만에 처리할 수 있었고, 병합 문제나 속도 저하 없이 다음 단계로 넘어갈 수 있었습니다.
네, 잘 모르겠네요. 음, 그래서 병합 자체가 큰 문제는 아닌 것 같습니다. 제가 생각하기에는, 그것이 작업 트리(work trees) 같은 것을 수행하고 모든 것을 다시 통합하는 경향은 있지만, 종종 서로 다른 영역에서 작동합니다. 마치 병합된 후에 병합 때문에 발생하는 버그들이 생기고, 그러면 다시 실행해서 그 버그들을 고치는 식입니다. 그래서 음, 네, 저는 단위 테스트(unit tests)를 엄청나게 많이 돌리고 있어서, 회귀(regression)가 자주 발생하지 않습니다.
모든 것이, 음, 아시다시피, 병합이 들어오면 여러 세트의 테스트가 실패합니다. 만약 둘 다 실패한다면, 모든 것을 통과시키는 '최적의 중간 지점'이 무엇인지 알려줍니다. 그리고 그것을 가지고 앞으로 나아갑니다. 그래서 저는 이것이 어떻게 작동하는지 궁금하네요. 왜냐하면 저도 많은 테스트를 돌리고는 있었지만, 주의 깊게 살펴보지는 않았거든요. 그런데 실패하게 되면, '오, 이 부분을 고치거나, 아니면 이 변경 사항이 여기서 다른 것을 망가뜨렸어'라고 알려주더라고요.
제가 프로젝트당 하나씩 테스트해 봤을 때 코딩하는 것이 적어도 더 빨라진 것 같긴 하지만, 다시 돌아가지는 않았고 아마 한 달 정도 된 것 같아요. 그래서 좀 더 실험해 봐야 할 것 같습니다. 저는 에이전트(agent)의 체크리스트 일부로 커버리지 (coverage)와 뮤테이션 테스트 (mutation testing)를 실행하는 것이 좋습니다. 그렇지 않으면 에이전트가 언제 테스트 작성을 멈출지 결정하게 두는 것보다, 모든 부분이 완전히 다뤄졌다는 안도감을 주기 때문입니다. 저는 이것이 토큰(tokens)을 절약해 준다고 생각합니다. 왜냐하면 회귀(regressions)가 훨씬 적게 발생할 것이기 때문입니다.
그래서 제가 지금까지 해온 방식은 이렇지만, 다음 주에 이걸로 실험해 보고 어떻게 되는지 지켜볼 겁니다. 네, 저는 어떤 애플리케이션이나 게임을 만들든, 만약 지금 조잡하게(janky) 보인다면, 그것은 그냥 '분위기만으로 코딩된' 것이라고 간주될 거라고 생각합니다. 그리고 그 조잡함 말이에요. 네, 정확해요. 정말로 품질 기준 자체가 올라갔다고 생각합니다. 예를 들어 인디 게임이나 작은 SaaS 앱 같은 경우를 보세요. 2022년쯤에는 '이걸 만드는 데 합리적인 시간이 들었지'라는 식이었고, 조금 조잡해도 괜찮았지만 사람들은 미래를 볼 수 있었어요. 충분한 자금과 자원이 있다면 훨씬 더 멀리 갈 수 있다는 것을요. 그 품질 기준이 엄청나게 높아진 겁니다. 그런데 이제는 사람들이 아주 작은 흠집이라도 발견하면 바로 '끝'이라고 생각합니다. 왜냐하면 마치 이 기능을 다른 쪽에서 실제로 작동하는지 확인하는 데 필요한 5분조차 들여놓지 않았다고 즉시 무시해 버리기 때문입니다. 그래서 저는 사람들은 이전보다 훨씬 더 비판적이 되고 있다고 생각합니다. 이제 한 사람이 할 수 있는 것에 대한 기대치가 훨씬 높아졌기 때문에요.
네, 제가 방금 이 이야기를 하고 있다고 생각합니다. 혹시 더 많은 정보가 있는지 모르겠지만, 사람들이 AI로 무엇을 만들어야 할지에 대해 이야기하고 싶었습니다. 왜냐하면 많은 사람들이 여전히 같은 규모로 구축하는 데 초점을 맞추고 있는 것 같기 때문입니다. 그리고 AI와 함께라면, 내년에 정말 두각을 나타내기 위해 필요한 작업의 범위(scope)와 품질은 엄청나게 높아질 것이라고 생각합니다.
작은 게임에 그저 귀여운 메커니즘(mechanic)만 가진 것을 만들어서 상업적인 성공을 거두기는 어렵다고 생각합니다. 왜냐하면 내년 중반쯤에는 9살짜리 아이가 자신의 Google 기기에 그것을 원한다고 말하기만 하면, 그것이 휴대폰에 나타날 수 있을 것이기 때문입니다.
당신은 정말 한계를 넘어서서(push the bounds) 더 인상적이고 규모가 큰 것들을 해야 합니다. 이전에는 절대 할 수 없을 것이라고 생각했던 것들 말입니다. "아, 만약 내가 무한한 돈을 가지고 있고 친구들 모두를 고용해서 이 것을 만들 수 있다면, 나는 이것을 만들 것이다"라고 생각하는 그런 것들이요. 지금 AI로 구축해야 하는 것이 바로 그것입니다. 한계를 넘어서서 정말 새로운 것들을 해야 합니다. 작게만 만들려고 하지 마세요. 적어도 이게 제 의견입니다.
제가 느끼기에는, 당신이 하는 작은 것들은 그저 반나절 만에 더 나은 버전으로 복제될 것이고, 다음 주에는 또 그럴 것입니다. 지금 실제로 정말 인상적인 것을 만들려면요. 예전에 유튜브에서 본 영상이 있었는데, Steam Next Fest 게임에 관한 내용이었어요. 어떤 사람이 아주 공들여서(meticulously) 건초 더미 속의 바늘을 찾는 것에 대한 게임을 만든 것이었습니다. 그래서 건초 조각이 1,500만 개나 있고 바늘은 하나인 식이었죠.
그리고는 다음 날 수백 개의 분위기 복제본(vibe clones), 코딩된 분위기 복제본 같은 것들이 생겨났습니다. 그래서 저는 여기에 몇 가지가 있다고 생각합니다. 첫 번째는 '정제(refinement)'라는 것이 사라지지 않는다는 것입니다. 만약 단일한 개념이 있고, 그것을 반복적으로 개선할 수 있는 것이라면, 계속 정제하고, 정제하고, 정제하는 식입니다. 아니면 광범위하게 나아가거나요. 깊게 파고들거나(deep) 넓게 퍼지거나(broad), 둘 중 하나를 선택해야 합니다.
하지만 보유한 토큰 수에 따라 다릅니다. 그리고 정말로 기준점(benchmark)은 한 사람 기준으로, 에이전트의 최대 구독을 통해, 프론티어 에이전트가 무언가를 정제하는 것이 무엇을 의미하는지에 대한 진정한 기준점이 됩니다.
따라서 단일한 Claude Max 구독으로 세 개의 게임을 만들고 있는 것은, 단일 Claude Max 구독으로 하나의 게임을 만들면서 토큰 한도를 최대로 사용하는 것과는 다릅니다. 그리고 이것이 아마도 개인 개발자나 파트타임 개발자가 할 수 있는 합리적인 노력의 수준일 것입니다.
그리고 기업 환경에서는 토큰 사용량이 훨씬 더 많을 것입니다. 네 개에서 다섯 개 정도요. 만약 풀타임으로 단일 게임에만 전념한다면, 네 개에서 다섯 개의 Claude Max 에이전트나 구독을 관리하고, 그것들이 끊임없이 작동하며, 당신은 지속적으로 주의를 기울여야 합니다.
하지만 저는 그 규모에서 따라가고 범위를 유지할 수 있을지 궁금합니다. 많은 에이전트들이 단순히 정제와 점진적인 개선을 수행하고, 이야기(story), 디자인, 게임플레이 등 실제로 주의를 기울여야 할 한두 가지 새로운 개발 경로를 추적하는 것만으로는 충분하다고 느낍니다. 네, 그래서 품질 기준(quality bar)은 그곳에서 나오는 복제품이나 쓰레기 같은 결과물보다 훨씬 높습니다. 저는 그 복제품과 쓰레기는 품질 기준에 의해 빠르게 무시될 것이라고 생각합니다.
