Mythos와 함께 일한다는 느낌

 (oneusefulthing.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Claude 5 Fable은 공개되는 첫 Mythos급 AI 모델로, 다양한 작업에서 이전에 사용한 공개 모델들을 큰 차이로 앞섰고 AI와 일하는 관계의 변화를 드러냄
  • Fable은 다중 페이지 명세를 바탕으로 최대 12시간가량 작업을 이어갔고, 단일 프롬프트와 한 번의 피드백으로 학술 사회과학 논문과 10쪽 분량의 운율시를 생성함
  • 게임 제작 실험에서는 Claude가 이미지를 생성하지 못하는 제약 속에서도 외부 자산 없이 수학만으로 아트와 3D 오브젝트를 구성함
  • 등시선 지도와 Concord 프로젝트에서 Fable은 연구, 코딩, 검증 에이전트를 동원했지만, 사용자는 세부 의사결정 과정과 판단 근거를 거의 보지 못함
  • Mythos급 모델은 결과 중심의 작업 방식을 강화하며, 인간의 역할이 직접 수행에서 의뢰와 검수로 이동함

Claude 5 Fable의 성능과 사용감

  • Claude 5 Fable은 공개되는 첫 Mythos급 AI 모델이며, 소프트웨어 보안 영향에 대한 논의가 많았지만 테스트는 그 영역을 제외하고 진행됨
  • Fable의 가드레일은 사이버보안 용도로 거의 사용하지 못하게 막는 수준으로 작동함
  • 여러 실험에서 Fable은 이전에 사용한 거의 모든 공개 모델보다 상당히 높은 성능을 보였음
  • Fable은 여러 문제에서 역량을 보였고, 다중 페이지 명세를 바탕으로 최대 12시간가량 작업을 실행함

인상적인 출력 사례

Maps and Methods

  • 등시선 지도는 주어진 시간 안에 이동할 수 있는 거리를 보여주는 지도이며, 첫 사례는 1881년에 런던 출발 이동 시간을 보여주기 위해 만들어짐
  • 이전 모델들은 이런 지도를 절반이라도 유용하게 만들지 못했는데, 수천 개의 잠재 이동 거리 조사와 많은 작은 판단이 필요했기 때문임
  • Fable에는 실제 데이터 기반 등시선 지도, 도시 선택 기능, 독특한 디자인, 공항 이동 시간, 기차, 도보, 운전 고려가 요구됨
  • Fable은 원본 1881년 지도 스타일로 만드는 방식을 제안했고, 이후 작업을 시작함

등시선 지도 제작 과정

  • Fable은 여러 보조 AI를 실행해 이동 시간 조사를 맡겼고, 주로 더 저렴한 Claude Sonnet을 사용한 것으로 보임
  • 보조 에이전트들은 2,200개가 넘는 구체적 항공편, TGV부터 Shinkansen까지의 철도 일정, 여러 학술 논문의 국가별 도로 속도를 가져옴
  • 에이전트들이 조사하는 동안 Fable은 코딩을 시작했고, 이후 더 많은 에이전트와 테스트를 실행해 코드를 검증함
  • 완성된 지도는 1881년 원본과 비슷한 외형을 가진 작동 가능한 결과물이었지만, Greenland 같은 원격 지역에는 정확한 숫자 대신 이동 시간 추정치가 들어감
  • 원격 공항과 장소의 실제 이동 시간을 가져오라는 요청 뒤 Fable은 적대적 그룹의 에이전트들이 조사하고 서로의 결과를 테스트하는 워크플로를 실행함
  • Fable은 Pacific의 Pitcairn Island로 가는 선박 운항 빈도와 Ottawa에서 Grise Fjord로 가는 방법을 파악함
  • 결과물은 클릭해 볼 수 있는 등시선 지도로 제공되며, 그래프 하단에서 방법과 출처를 확인할 수 있음

Concord 프로젝트

  • 인간이 만든 지저분한 답변을 분석하려면 답변을 올바르게 분류해야 하며, 예시로 아이디어의 혁신성이나 사람들이 특정 책을 좋아하는 이유가 제시됨
  • 기존 방식은 인간 연구자가 정보를 판단하고, 그 판단을 다른 사람의 답변과 통계적으로 비교해 데이터 신뢰도를 평가함
  • 최근 연구는 AI가 이 중요한 작업을 할 수 있음을 보여줬지만, AI와 인간 판단을 보정하는 일은 어렵고 비용이 많이 듦
  • Fable은 먼저 19쪽짜리 복잡한 설계 문서를 생성한 뒤 실행에 들어감
  • Fable은 9시간 30분 동안 작업함
  • 결과물인 Concord는 여러 데이터셋을 받아 인간과 AI 응답을 보정하고, 결과에 대해 복잡한 데이터 분석을 수행하는 소프트웨어임
  • Concord는 완벽하지 않았고, 전문 지식으로 일부 오류와 누락을 찾아 수정하도록 했음
  • Concord 코드는 GitHub 저장소에서 사용하거나 수정할 수 있음

한계와 비용

  • Fable의 강력함은 낯섦과 한계를 동반함
  • Fable은 Opus보다 두 배 비싸고, 토큰을 매우 빠른 속도로 사용함
  • 더 저렴한 모델에 작업을 위임하는 방식은 실제 비용을 상당히 낮출 수 있음
  • Fable의 가드레일은 보안 문제의 아주 작은 조짐에도 작동하며, 더 약한 Claude 4.8 Opus로 기본 전환되는 일이 너무 자주 발생함
  • 모델의 들쭉날쭉한 경계는 여전히 남아 있으며, Fable이 만든 소프트웨어와 진행 보고서에는 Claude 특유의 표현 흔적이 남음

인간 역할의 변화

  • Fable을 쓰는 경험은 요청하면 결과가 생긴다는 점에서 즐겁지만, 같은 이유로 불안하게 느껴짐
  • 등시선 지도 프로젝트에서 사용자의 역할은 매우 제한적이었고, 야심 찬 지시와 몇 가지 작은 피드백만 제공함
  • 모델이 어떤 방식으로 일하는지, 왜 특정 접근을 택했는지, 결과가 얼마나 깊어질지에 대한 통제도 제한됨
  • AI의 의사결정 세부사항은 사용자에게 보이지 않으며, 과정을 따라가기에는 너무 길어질 수 있음
  • 작업은 과정에서 결과로 이동했고, 사용자는 직접 조종하기보다 의뢰하는 위치에 가까워짐
  • Fable은 지시를 매우 잘 따르며, 더 야심 찬 지시일수록 더 나은 결과를 냄
  • 조종은 여전히 가능하지만, 조종이 직접 수행과 같지는 않음
  • Fable은 연구하고 쓰고 서로의 작업을 점검하는 자체 에이전트를 실행하며, 사용자는 완성된 결과를 검토하는 쪽에 가까워짐

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글에서 생성된 코드의 품질과 매체에 대한 실질적인 내용이 거의 없다는 점이 흥미로움
    코드에 문서와 테스트가 있는지, 이해·확장이 가능한지, 안전한지, 어떤 언어·프레임워크·데이터베이스를 썼는지 궁금함. 저자가 판단력과 취향을 말했는데, 실제 코드도 취향 있게 작성됐는지 모르겠음. 새 기능을 추가해 달라고 하면 모델이 전체 구조를 다시 짜면서 또 9.5시간어치 토큰을 쓰게 될지도 의문임. 연구 부분은 도메인 지식, 즉 여행 유형별로 시간을 어떻게 환산해 보기 좋게 만들었는지일 텐데, 저자가 이를 어떻게 검증했는지도 궁금함
    이런 질문은 AI에만 해당하지 않음. 사람 에이전시에 돈을 주고 “작동한다”는 결과물을 받았다면 똑같이 물어볼 것임. 평가할 줄 모르면 평가할 사람을 고용했을 것임. LLM에서 가장 걸리는 부분은 검증임

    • 이런 글은 소프트웨어 엔지니어가 쓰는 경우가 거의 없고, 대개 기술 임원, 은퇴한 엔지니어, VC가 씀
      이 저자는 Wharton School of Management 교수인 듯함. 이런 사람들은 실제 제품을 출시하거나 유지보수할 필요가 없고, 그냥 사이드 프로젝트를 만드는 것에 가까움
      제대로 된 소프트웨어 엔지니어링 관점은 Mitchell Hashimoto에게서 본 것이 거의 유일했음
    • LLM은 위험도가 낮은 프로젝트를 만드는 데 정말 강하다는 걸 깨닫기 시작함
      위 질문들은 대체로 더 높은 위험도를 전제로 함. 소프트웨어가 오래 유지되고, 요구사항이 진화하며, 실수를 용납할 수 없다는 식임
      소프트웨어에 LLM을 잘 쓰는 요령은 모든 프로젝트를 낮은 위험도로 만드는 법을 배우는 것 같음
    • 지난 2년가량의 모든 LLM 논의가 이런 식이었음
      실질적인 내용을 요구하면 “사람도 이걸 잘 못하잖아!”라는 말이 쏟아짐. 정량적 근거는 매우 적고, 순수한 수사만 많음
    • 모델이 좋아질수록 코드가 어떻게 생겼는지는 정말 중요하지 않을 수도 있다는 생각을 하게 됨
      소프트웨어의 관찰 가능한 동작이 좋다면 그 소프트웨어는 좋은 것임. 어떤 종류의 버그든 모델이 바이브 코딩된 코드베이스에서 고칠 수 있다면 고칠 수 있는 버그임. 악용 가능한 취약점이 없다면 안전한 코드이고, 성능이 충분하면 성능 좋은 코드임
      바깥에서 해야 할 일을 하고, 안쪽에서 문제가 발견됐을 때 모델이 고칠 수 있다면 코드 모양은 중요하지 않음. 소프트웨어 엔지니어링은 그 어느 때보다 코드가 의도대로 동작하는지 확인하는 일이 됐음
      설령 코드 모양이 중요하더라도, 그것도 모델에게 고치게 할 수 있음
    • 예시 중 하나인 “뱀이 자의식을 갖고 이상한 일이 벌어지는 스네이크 게임”을 눌러 봤는데, 1~2분 해 보니 그냥 1980년대식 스네이크 게임이었음
      뭘 놓친 건지 모르겠음. “자의식”이라는 게 화면 아래쪽의 웃긴 메시지 몇 개를 말하는 건가? “이상한 일”은 무엇인지도 모르겠음

  • Fable에 내가 손으로 검증하던 모델들을 넣어 봤음
    대략 Opus에게 시나리오를 모델링하게 하고, 수학을 보여 달라고 한 뒤, 고치고 반복하고, 마지막으로 코드가 모델 논리와 맞는지 다시 확인하는 방식임. Fable은 내가 찾은 오류를 거의 다 찾아냈고, 추가 변수에 대한 흥미로운 제안도 했음
    다만 사용량 한도를 90년대 말 Hummer처럼 태워 버렸음

    • Max 5x 구독 중인데, Fable이 40분짜리 코드 리뷰 세션에서 주간 한도의 16% 를 써 버렸음
      리뷰를 끝내지도 못했고, 정작 Fable이 필요했던 중요한 메모리 안전성 부분에서는 Opus 4.8로 되돌아갔음
      곧 이런 모델들을 가격 때문에 못 쓰게 될 것 같은 느낌임. 6월 22일까지 Fable을 최대한 뽑아먹어야 할 듯함
    • 가장 중요한 질문은 이것임: 여기서 투자 대비 수익은 얼마나 나오나?

  • 오늘 Fable로 개인 프로젝트를 해 봤는데 꽤 탄탄해 보이지만 4.8과 아주 멀리 떨어져 있지는 않음
    같은 환각, 같은 유형의 버그, 큰 프로젝트에서 요청한 것만 하고 그게 건드리거나 깨뜨리거나 영향을 줄 수 있는 부분은 무시하는 경향도 같음. 처음에는 테스트를 돌리지만 맥락이 커지면 “나중에 돌리겠다”고 하고, 욕을 섞어 지시하지 않는 한 결국 끝까지 안 돌림
    계속 쓰긴 하겠지만 지금 보기에는 점진적 개선이지, “OMG OMG OMG Mythos가 왔다!” 수준은 아님

    • 내 경험은 반대임. Fable은 모든 걸 예상하고 묻지 않아도 다 해 주는 것처럼 보였음
      매우 인상적이고 같이 일하기 좋았음
      이상한 현상은 아닌 게, 처음 구독했을 때 Opus도 딱 이랬음. Anthropic이 용량 부족 때문에 Opus를 약화시켰다는 밈이 널리 퍼져 있는데 사실인지는 모름. 다만 Fable도 같은 운명을 맞을지 궁금함
    • 내 프로젝트에서는 4.8이 놓친 것들을 Fable이 즉시 명확히 봤음
      하지만 그 문제들을 계단식으로 넘어가며 크게 감탄하게 만든 뒤 얼마 지나지 않아, 평소처럼 뭔가를 하기보다 말만 계속하는 무한 루프에 빠졌고, 가끔 멈춰서 내가 다시 재촉해야 했음
      그래서 AGI는 아님. 그래도 확실한 개선은 맞음

  • 글의 이 짧은 문장이 무서움: “하지만 소프트웨어 엔지니어가 내가 빠르게 찾지 못한 남은 잠재적 버그를 다듬을 것이다”
    모든 소프트웨어 개발자는 이게 매우 위험하고 비현실적인 가정이라는 걸 앎

    • 이건 사실상 모든 진짜 작업을 손쉽게 넘겨 버리는 작은 문장임

  • 저자가 “AI가 만든 가장 정교한 학술 사회과학 논문”이라고 부른 글의 첫 몇 단락을 읽어 봤는데 기대만큼 인상적이지 않았음
    “시장 수요에 대한 사후 믿음은 순전히 기준점 의존적이다. 모금액을 일정하게 유지하면, 창업자가 스스로 정한 목표 대비 성과만 추적한다. 임계값에서 표준편차 절반만큼 뛰고, 그 이후 첫 10점에는 가파르게 반응하며, 이후 평평해진다” 같은 식임
    사람은 보통 데이터를 이런 식으로 말로 풀지 않음. 요약 문서도 꽤 내용이 부풀려진 느낌임

  • 문제가 가장 완벽하게 드러나는 지점임
    저자는 모든 데이터가 실제이고 검증돼야 한다고 프롬프트를 넣은 뒤, 그냥 그렇다고 믿어 버렸음. 데이터 기반 프로젝트에서조차 그랬음. 사람들은 무수히 많은 일, 심지어 중요한 일에서도 똑같이 할 것임

    • 살면서 더 일찍 알았으면 좋았을 텐데, 아무도 확인하지 않을 거라면 훨씬 더 많이 그럴듯하게 꾸며낼 수 있었음

  • “9시간 반 동안 작업했다”는 대목과 “완벽하진 않았다. 전문가로서 몇 가지 오류와 누락을 발견했고 AI에게 고치게 했다”는 부분이 눈에 띄었음
    하루에 한 문제에 그렇게 오래 쓸 거라고 기대하지도 않고, 핵심 보상 루프가 몇 시간짜리인 결과물을 다시 고치는 데 그렇게 오래 쓰리라고도 기대하지 않음
    내 고객들은 현재 에이전트 응답 시간을 85초에서 20초 아래로 낮추라고 요구하고 있음
    동시에 업계가 에이전트를 통한 한 시간 이상짜리 작업 흐름으로 향하는 걸 보면 매우 부조화하게 느껴짐

    • Claude를 변호하자면, 믿기지 않지만 변호하게 되는데, 19쪽짜리 설계 문서에서 Concord 같은 걸 9.5 근무시간 안에 만들 수 있는 단일 개발자는 모름
      예전처럼 상사가 왜 앉아만 있냐고 묻는 시절로 돌아갈 것임. 다만 “컴파일 중입니다” 대신 “Claude 기다리는 중입니다”라고 말하게 될 뿐임
    • 이 시점에서는 돈을 훨씬 더 주면 내가 하겠음
    • 내 Opus 4.8은 사소하지 않은 단일 코딩 요청에도 정기적으로 10분 이상 작업함
    • 작업 시간은 그다지 가치 있는 측정치가 아님
      보통은 과정을 직접 코드로 정의하고, 그 코드가 작업 덩어리를 모델들에게 위임하게 하는 편이 낫음. 유일한 실제 문제는 제공업체의 구독 할인을 활용하기 어려워진다는 점임
      반대로 직접 모델 라우팅을 하기는 쉬워짐. 일반 챗봇이 며칠·몇 주 단위의 작업 흐름에서 일관성을 유지하는 방법은 아직 보지 못했음
    • QWEN 모델들이 나왔을 때 이미 시그모이드 구간에 들어갔다고 봄
      프로젝트를 제대로 구조화하면 원하는 확장 지점을 가리키고 30분 정도 돌려 기능을 확장하게 할 수 있음. 전체 코드를 대상으로 ‘신 모드’를 효과적으로 수행하진 못하지만, 신중한 관찰자이자 코드 전문가로서 128GB VRAM 이상이 꼭 필요하진 않음
      최신 모델 비대화가 이렇게 멀리 온 게 놀라운데, 중국이 이런 모델용 실리콘을 찍기 시작하면 끝낼 것 같음

  • 시 프롬프트가 무엇이었는지 몹시 궁금함
    아이디어가 익숙해서 파고들다 보니 14년 전 reddit의 시를 찾았음: [https://www.reddit.com/r/RedditDayOf/comments/tjjw2/may_12_a...]
    저자가 공유한 것만큼 길지는 않지만 같은 아이디어임
    이건 폴란드 작가 Stanislaw Lem의 SF 우화집 “The Cyberiad”에서 나온 것임. 한 이야기에서 로봇 제작자 Trurl이 시 쓰는 기계를 만들고, 질투심 많은 경쟁자 Klapaucian이 그 기계에게 “이발에 관한 시! 하지만 숭고하고, 고귀하고, 비극적이고, 영원하며, 사랑과 배신, 응징, 조용한 영웅주의, 확실한 파멸 앞에서의 시! 여섯 줄, 영리하게 운율을 맞추고, 모든 단어가 s로 시작해야 한다!”고 요구함
    컴퓨터는 이렇게 답함:
    “Seduced, shaggy Samson snored.
    She scissored short. Sorely shorn,
    Soon shackled slave, Samson sighed.
    Silently scheming,
    Sightlessly seeking
    Some savage, spectacular suicide”
    저자는 Fable/Mythos에 도전 과제를 던질 때 이 장면을 참조했을 수밖에 없어 보임. 정확한 프롬프트가 궁금함

    • 흥미로운 점은 이게 영어 번역의 난도라는 것임
      영어 번역은 폴란드어 원문과 다른 시작 글자와 다른 단어를 씀:
      Cyprian cyberotoman, cynik, ceniąc czule
      Czarnej córy cesarskiej cud ciemnego ciała,
      Ciągle cytrą czarował. Czerwieniała cała,
      Cicha, co-dzień czekała, cierpiała, czuwała...
      ... Cyprian ciotkę całuje, cisnąwszy czarnulę!!
      번역가의 일을 LLM과 비교해 볼 수 있음. 둘 다 파생 작업이고, 제약 속에서 일하지만 창의성을 발휘할 여지가 있음
    • 저자가 그 장면을 참조한 게 아니라, Anthropic이 reddit 댓글 라이선스를 받았으니 학습 데이터에서 빨아들였을 수도 있음

  • 한 시간도 안 써 봤으니 새 기술에 흥분한 상태라는 점을 감안해야 함
    내 프로젝트(https://github.com/tsz-org/tsz) 같은 경우, 모델들이 충분히 조사하지 않고 다른 상황을 고려하지 않는 데 계속 좌절했음. 모델은 한 가지를 고치는 코드를 만들고, “관련 없어 보이는” 테스트 두 개를 깨뜨리는 일을 반복했음
    Fable은 작업이 훨씬 오래 걸리는 것 같고 아직 Fable 세션에서 풀 리퀘스트를 본 적은 없지만, 세션 기록을 읽어 보면 돌 하나도 빠뜨리지 않으려는 방식으로 옳은 일을 하고 있는 게 보임
    글에서도 말하듯 이런 모델의 “느낌”은 프로젝트마다 너무 달라 전달하기 어렵지만 공유해 봄

    • 그건 프로젝트가 기능을 점진적으로 추가하기 쉬운 구조가 아닐 수도 있다는 신호 아닌가?

  • 다들 Mythos와 Opus 사이에서 그렇게 큰 차이를 느낄 만큼 뭘 작업하고 있는지 궁금함
    나도 꽤 고급 작업을 한다고 생각하는데, Deepseek만으로도 충분할 때가 더 많음. 여기 있는 사람들은 왜 다 천재인 건가?

    • 무엇을 작업하느냐에 달렸음
      Hades나 Baazar 같은 괜찮은 인디 게임 수준의 비디오 게임을 만들고, 유기적·상호작용적·애니메이션 느낌의 UI 요소, 시각 효과, 복잡한 셰이더 등을 만들려 하면 어떤 모델도 쉽게 끝낼 만큼은 전혀 충분하지 않음. 상위 3% 게임에서 나오는 문제의 상당수는 단순 프롬프트로는 어떤 모델에도 정말 어려움
      개인적으로는 직접 코딩하고 배우는 걸 좋아해서 별로 신경 쓰지 않고, DeepSeek Flash 정도면 충분함. 그래도 최고 모델들이 전혀 가까이 가지 못하는 벤치마크를 많이 만들기는 아주 쉽고, 그런 문제로 모델이 얼마나 좋아지는지 테스트하는 걸 좋아함
      참고로 Fable 5는 4.8보다 확실히 조금 더 나음
    • 새 노트북이 발표되면 직원들이 갑자기 모두 업그레이드가 필요하다고 하는 것과 비슷함
      실제로는 90%가 Macbook Neo로도 충분히 버틸 수 있을 텐데도 그럼
    • 최근 Rust로 흔한 웹 인프라 유형의 프로젝트를 구현하고 있음
      rustls, Tokio 같은 Rust의 좋은 기본 요소를 많이 써서 메모리 안전하거나 그에 가까운 nginx 대체품을 만들려는 시도임
      이 작업의 일부로 고품질 Lua in Rust 저장소도 만들고 있음. gpt 5.5와 Opus 4.8이 막혔던 내 Lua 인터프리터의 성능 문제를 Mythos로 고치고 있음
      Mythos가 이걸 풀 수 있을지는 모르겠지만, 몇 시간째 실행 중이고 꽤 유망한 결과가 있음
      궁금하면 성능 차트는 여기 있음: https://github.com/ianm199/lua-rs
    • 직접 프로그래밍 언어를 만들고 있음
      기여할 만한 오픈소스 프로젝트도 둘러보고 있음. 취미 개발자에서 전문가로 전환하는 데 도움이 될 만한 무언가를 찾는 중인데, 요즘 시대에 그런 게 가능한지도 모르겠음
      Fable 5는 코드 리뷰에서 Opus 4.8이 놓친 문제를 꽤 많이 찾았음. 멍청한 사이버보안 관련 제한 때문에 모델이 낮아졌는데도 그랬음. 더 말하긴 어려운 게 Max 5x에서 5시간 창마다 세션 하나만 받을 수 있음. 지금까지 세션 두 번만 돌렸음
    • 요구 수준을 계속 올리면 어떤 모델이든 한계까지 몰아붙이는 건 어렵지 않을 것임
      극단적으로 프롬프트가 “기능이 완전하고 완성도 높은 Facebook 클론을 만들어라”라고 해 보자. Facebook은 복잡하지만 기술적으로 아주 난해하진 않을 가능성이 큼. 그래도 상당한 토큰을 태우고 나면, 그 프롬프트에 대한 여러 모델의 결과물에서 여러 측면의 상당한 차이를 보게 될 것임
      물론 위 요청은 실제로 유용하진 않음. 하지만 한계에 가까워질 때까지 더 큰 덩어리를 맡기지 못할 이유가 뭐가 있나? 어느 시점에는 경계에 닿고, 차이가 분명해질 것임
답변달기