어제 All Day AI 컨퍼런스에서 발표를 했어요. 꽤 좋았고, 아, 놓쳤네요. 너무 많은 것이 일어나고 있어요. 제가 그걸 놓치다니 믿기지 않아요. 저거도 보세요. 제 AI 에이전트가 그거에 대해 모르는 것 같아요. 한번 소리 질러볼게요. 네, 정확해요. 잠깐만요. 왜 저에게 그것을 상기시켜 주지 않았나요? 대체 뭐야? 네, 저는 정말로 제가 찾고 있던 것 중 하나였거든요. 그리고 알고 보니 놓쳤네요. 어땠어요? 좋았어요. 네. 다른 발표들에서도 꽤 흥미로운 내용들이 있었습니다.
한 회사 이름이 기억나지 않지만 찾아보겠습니다. 그들은 시연에서 뇌의 작은 다이어그램과 활성화되는 노드들을 보여주는 것을 했습니다. 그리고 폭탄을 만드는 방법을 입력하자 빨간색 영역들이 모두 빛났습니다. 그러다가 '초콜릿'이라는 단어를 깜빡했다고 해서, 초콜릿 폭탄을 만드는 방법으로 변경했습니다. 그랬더니 요리나 과자류 같은 다른 것들도 모두 불이 켜졌어요.
그래서 이건 LLM saliency(LLM 현저성)에 대한 정말 흥미로운 시연이었고, 대규모 언어 모델에서 발생하고 있는 나쁜 일들을 감지하는 것이었습니다. 하지만 이게 어떻게 유용할까요? 그러니까... 저는 이해가 가요. 실제로 Claude는 이미 무언가를 하고 있습니다. 지난주에 봤는데, 'Claude Code'를 보면 '프롬프트 분류기(prompt classifier) 덕분에 제가 이걸 할 수 없었어요' 또는 '행동 분류기(actions classifier) 덕분에 제가 이걸 할 수 없었어요'라고 말하는 것을 보았거든요. 그래서 그들은 실제로 모든 도구 호출을 읽고 있는 또 다른 모델을 가지고 있습니다.
그리고는 '오, 이건 위험하다'거나 '이것은 나머지 컨텍스트 창(context window)에 맞지 않는다'고 말합니다.
그래서 저는 이것을 아마도 Jev 모델과 같은 결정론적 출력(deterministic outputs)으로 생각합니다. 예를 들어, '이 프롬프트가 악의적인가? 참인가 거짓인가?'와 같이 질문할 수 있습니다. 그러면 Jev는 항상 참 또는 거짓을 알려주고, 그에 기반하여 무언가를 차단하는 식입니다.
그래서 저는 마치 "내가 전체 경로 디렉터리(entire route directory)를 RM RF 할 거야"와 같은 상황에 대한 방지책이 있다고 생각합니다.
그냥 "헤이, 사용자가 너에게 그렇게 하라고 요청하지 않았어. 그러지 마."라고 말할 것입니다. 네, 맞습니다. 그래서 저는 이 많은 것들이 예측 불가능한 모델의 본질적인 특성을 통제하려는 시도이며, 마치 감시하는 것과 같은 또 다른 예측 불가능한 도구를 통해 이루어진다고 생각합니다.
하지만 그것은 정말 멋진 것이었습니다. 그리고 또 다른 발표는 보안 관점에서 AI가 자격 증명(credentials)을 사용하는 것에 관한 것이었습니다. 그래서 1Password 출신의 사람이 있었는데, 저는 실제로 1Password나 LastPass 같은 것을 많이 사용합니다.
그런데 1Password에는 사용자의 기기에 저장되지 않는 자격 증명을 제공할 수 있는 MCP 서버로 보이는 것이 있었습니다. 에이전트(agent)는 그것들을 사용할 수는 있지만 컨텍스트 창에서 볼 수는 없습니다. 그래서 이는 자격 증명 유출을 방지하는 정말 멋진 방법이었습니다. 저도 이것을 매우 흥미롭게 생각했습니다.
하지만 컨퍼런스의 대부분은 사람들이 'vibe coded' 같은 것들로 스스로 문제를 일으키고 있고, 이를 방지하기 위한 도구들이 있다는 내용이었습니다. 흥미롭습니다. 어떤 종류의... 그러니까 다른 부분도 그렇지만, 어떤 종류의 도구들이 있었나요?
네, 첫 번째 예시는 그냥 들어갈 수 있는 또 다른 분류기(classifier) 같은 것이었습니다. 하지만 1Password의 예시를 봅시다. 네, 비밀번호 관련해서는 1Password나 LastPass 또는 이 기능을 수행하는 다른 모든 공급업체에서 하는 방식과 같습니다. 클라우드에 비밀번호를 저장할 수 있습니다. 그런데 이것이 하는 일은 에이전트(agent)가 환경을 볼 수 없도록 비밀번호를 요청하고 전달받게 한다는 것입니다. 다시 말해서, 만약 자체 서버와 같은 엔터프라이즈급 업무를 하거나 아니면 집에서 사용하는 경우에도 마찬가지입니다.
네, 정확합니다. 예를 들어 Azure 계정이나 AWS 계정이 있다고 가정해 봅시다. 그리고 모델이 실수로 제 관리자 권한(admin privileges)을 사용해서 500개의 리소스를 생성하고 우편으로 $50,000 청구서를 받는 것을 원하지 않는다고 할 때 말입니다. 이때 1Password를 통해 읽기 전용 자격 증명(read-only credentials)을 제공할 수 있습니다. 그러면 그 호출은 들어올 수 있고, 이제 에이전트가 실수로 사용할 수 있는 것이 기기에 아무것도 없다는 보장이 생깁니다. 청구 한도(billing limit)를 설정하고 변경되지 않도록 해야 합니다. 네, 정확합니다.
무엇에 따라 다르겠지만요. 하지만 설령 어떤 이유로든 에이전트가 관리자 자격 증명을 얻게 된다고 해도, '오, 이 청구 한도를 없애야겠다'라고 할 수 있습니다. 저는 그 아래의 자격 증명(credentials)은 읽기 전용일 필요는 없을지 몰라도, 회사 전체를 파괴할 수 있는 능력은 절대 주어서는 안 된다고 생각합니다. 네. 그래서 컨퍼런스 자체도 꽤 흥미로웠습니다. 제가 연 날리기와 접시 돌리기를 했습니다. 그리고 제 블로그에 에이전트의 MD(Master Directory)를 설정하고 스킬 파일과 MCP 서버를 연결하는 구성기(configurator)를 추가했습니다.
거기서 활동은 많이 보지 못했지만, 참석률은 정말 높았습니다. 그냥 네, 청중과 상호작용하는 것이 좀 이상했어요. 어떤 사람들은 이모티콘 같은 것을 사용하더라고요. 하지만 전반적으로 재미있었고, 이 발표를 할 수 있어서 좋았습니다. 다음에는 호주로 가고 그 다음엔 일본으로 갈 예정입니다. 그래서 저는 연 날리기나 접시 돌리기 같은 것들로 여기저기 돌아다닙니다. 네, 정말 정보가 많았어요. 사이버 보안 관련 내용이 많았고요. 그리고 '다크 팩토리(dark factories)'도 요즘 정말 큰 주제입니다.
그래서 있잖아요, 사람이 아무것도 보지 않는 가상의 '다크 소프트웨어 팩토리'에서 자신 있게 솔루션을 엔지니어링할 수 있는 방법에 대한 아이디어 말이에요. 그런데 결과물로 나오는 소프트웨어는 완전히 테스트되었고 통합 검증까지 완료된 상태여야 합니다. 그래서 저는 피처의 비디오 출력과 함께 단위 테스트(unit tests), 보안 스캔(security scans) 등을 많이 진행해서 모든 것을 최종적으로 뽑아내는 작업을 해왔습니다. 그리고 이게 최근에 정말, 정말 인기 있는 주제가 되었습니다.
그게 혹시 '바이브 코딩(vibe coding)'의 새로운 용어인가요? 네, 저는 '바이브 코딩'이라는 것이 있다고 생각합니다. 이건 제가 뭘 하고 있는지 전혀 모르는 상태에서 진행하는 거예요. 그리고 그 결과 보안 침해가 발생해서 모든 사람이 제 은행 계좌에 접근할 수 있게 되는 식이죠. 반면에 다크 팩토리에서는 안전한 것을 '바이브 아웃(vibe out)' 할 수 있습니다. 네, 흥미롭네요. 저는 이게 그냥 모든 것과 모든 것에 붙이는 일종의 유행어처럼 느껴집니다. 네, 제가 생각하기에 어떤 애플리케이션이나 게임을 만들든, 만약 지금 엉성해 보인다면, 그것은 그저 '바이브 코딩'으로 만들어졌다고 가정되는 것입니다.
그리고 저는 그것에 대한 엉성함(jank jankiness)이 있다고 생각해요. 네, 맞아요. 정말로 품질 기준 자체가 높아졌다고 생각합니다. 예를 들어 인디 게임이나 소규모 SaaS 앱 같은 것들이요. 2022년쯤에는 '여기에 어느 정도 시간과 노력을 들였구나'라는 느낌을 줄 수 있었고, 조금 어설펐더라도 사람들이 그것을 받아들일 수 있었습니다. 하지만 자금과 리소스가 충분하다면 훨씬 더 멀리 갈 수 있다는 걸 알았죠. 그 품질 기준이 엄청나게 높아졌습니다. 그런데 이제 사람들은 만약 아주 작은 약점이라도 발견하면 바로 '끝'이라고 생각합니다. 왜냐하면 그것을 보기 위해 5분 정도 들였을 법한 노력이 없었다고 즉시 무시하기 때문이에요.
그래서 저는 사람들이 예전보다 훨씬 더 비판적이 되고 있다고 생각해요. 이제는 한 사람이 할 수 있는 것에 대한 기대치가 훨씬 높아졌기 때문이죠. 네, 제가 방금 이 이야기를 하고 있었는데... 혹시 이에 대해 더 아시는 게 있나요? 하지만 사람들은 AI를 가지고 어떤 것을 만들어야 하는지에 대해 조금 이야기하고 싶었어요. 많은 사람들이 여전히 예전과 같은 규모로 구축하는 데 초점을 맞추고 있다고 느끼거든요. 그리고 AI와 함께라면, 다음 해에 정말 눈에 띄기 위해 필요한 범위(scope)와 품질은 엄청나게 높아질 것이라고 생각합니다.
작은 게임으로는 만들 수 없습니다. 그저 귀여운 작은 메커니즘만 가진 게임을 만들어도 상업적으로 큰 성공을 거두기는 어렵다고 생각합니다. 왜냐하면 내년 중반쯤에는 아홉 살짜리 아이가 구글 기기에 원하는 것을 말하기만 하면 됩니다. 그러면 휴대폰에 팝업으로 나타나죠. 여러분은 정말 한계를 밀어붙이고, 이전에 할 수 있을 거라고 전혀 생각지 못했던, 더 인상적이고 규모가 큰 것들을 해야 합니다. '오, 만약 나에게 무한한 돈이 있고 친구들 모두를 고용해서 이것을 만들 수 있다면, 나는 이걸 만들 거야'라고 생각할 만한 것들이요.
지금 AI로 만들어야 하는 것이 바로 그런 것입니다. 한계를 밀어붙이고 정말 새로운 것을 해야 합니다. 단순히 작은 것을 만들려고 시도하지 마세요. 적어도 그것이 제 의견입니다. 저는 어떤 작고 사소한 것도 30분 안에 더 나은 버전으로 복제될 것이라고 느낍니다. 실제로 매우 인상적인 무언가를 만들기 위해서는요. 예, 제가 본 유튜브 영상 중 하나가 스팀 넥스트 페스트 게임에 관한 내용이었는데, 누군가가 아주 공들여서 '건초더미 속에서 바늘 찾기' 게임을 만들었다고 하더라고요.
그래서 건초 더미가 1,500만 조각에 바늘이 하나 있는 식이었죠. 그러자 다음 날에는 수백 개의 유사한 코드가 복제된 클론들이 생겨났습니다. 그래서 저는 여기에 몇 가지 점이 있다고 생각합니다. 첫째는 정교화(refinement)가 사라지지 않는다는 것입니다. 만약 여러분에게 단일 개념이 있고, 그것을 반복적으로 개선할 수 있는 것이라면, 계속해서 다듬고, 다듬고, 다듬어야 합니다. 아니면 광범위하게 접근해야 하죠. 깊게 파거나(go deep) 넓게 퍼져야 합니다(go broad). 하지만 토큰 개수와 관련하여 벤치마크는 개인 한 명 기준으로, 에이전트 최대 구독료를 기준으로 볼 때, 프론티어 에이전트(frontier agent)가 정교화에 대한 기준점이라고 할 수 있습니다.
만약 하나의 Claude Max 구독으로 세 개의 게임을 개발하는 것이라면, 이는 단일 Claude Max 구독으로 토큰 제한(token limit)을 최대로 사용하는 하나의 게임을 개발하는 것과는 다릅니다. 그리고 이것이 아마도 솔로 또는 파트타임 개발자가 할 수 있는 합리적인 노력 수준일 것입니다. 반면 기업 환경에서는 토큰 사용량이 훨씬 더 많아질 것입니다. 예를 들어, 45개 정도요. 만약 당신이 전업으로 단 하나의 게임만 작업한다면, 45개의 Claude Max 에이전트 또는 구독을 관리하고, 이들이 끊임없이 작동하며, 당신은 지속적으로 주의를 기울여야 합니다.
하지만 저는 그 규모에서 따라가고 범위를 유지할 수 있을지 궁금합니다. 많은 에이전트들이 단순히 개선(refinement)과 점진적 향상(incremental improvement)을 수행하고, 이야기, 디자인, 게임 플레이 등 실제로 주의를 기울여야 하는 한두 가지 새로운 개발 경로를 추적하는 것으로는 가능할 것 같습니다. 네, 그래서 품질 기준(quality bar)은 그곳에서 나오는 복제품이나 저품질 콘텐츠(slop)보다 더 높습니다. 저는 이 복제품과 저품질 콘텐츠가 품질 기준에 의해 빠르게 무시될 것이라고 생각합니다.
그래서 저는 항상 그래왔다고 생각합니다. 맞습니다. 에셋 스토어(asset store)가 나왔을 때, 엔진이 무료가 되었을 때처럼, 우리는 한 무리의 복제품과 저품질 콘텐츠를 받기 시작했습니다. 지금도 그저 더 빠른 버전일 뿐이지만, 다르지 않습니다. 예전에는 사람이 검토하던 Steam Greenlight 같은 단계에서 시작했죠. 그리고 나서 "아무나 100달러만 내면 스팀에 진출할 수 있다"고 말했고, 이후로는 마치 틱톡 스타일의 알고리즘을 도입하여 순 추천 지수(net promoter score)를 얻게 했습니다.
이제 사람들의 리뷰를 받게 되고, 더 많은 관심이 쏠리면서 매우 가혹해질 겁니다. 알고리즘들이 너무 높은 품질 기준을 요구해서 제품이 즉시 묻히고 아무도, 심지어 인간조차 볼 수 없게 될 것입니다. 그래서 저희가 나아갈 방향은 기본적으로, 저는 Steam이 빌드를 받아서 AI에게 플레이하게 하는 방식으로 시작할 것이라고 의심합니다. 그리고 만약 최소 품질 기준을 충족하지 못하면, 애초에 인간이 전혀 보지 못할 가능성이 높습니다.
