Mythos와 일하는 느낌은 이렇습니다

 (oneusefulthing.org)
9P by GN⁺ | ★ favorite | 댓글 1개
  • 일반 공개된 첫 Mythos급 모델 Claude 5 Fable은 다단계 사양서를 받아 최대 십수 시간 동안 스스로 작업을 수행하며, 이전에 사용해 본 모든 모델을 상당한 격차로 능가
  • 단일 프롬프트와 한 차례 피드백만으로 정교한 사회과학 논문과 모든 단어가 s로 시작하는 10페이지 운율시까지 생성
  • 작업 중 다른 AI(주로 저렴한 Claude Sonnet)를 직접 실행해 연구·코딩·검증을 분담시키며, 2,200건 이상의 항공편과 철도 시간표, 국가별 도로 속도 데이터를 수집
  • 사용자의 역할은 지시와 결과 판정으로 축소되고, 모델의 의사결정 과정은 노출되지 않아 궁극의 블랙박스로 작동
  • AI와의 관계가 직접 작업하는 '마법사'에서 결과를 의뢰·판정하는 '후원자(patron)'로 전환 중이며, 능력이 강할수록 인간이 개입할 여지가 줄어들 가능성 제기

Claude 5 Fable의 성능과 사용감 - Ethan Mollick

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

Fable의 성능과 출력물

  • 진행한 모든 실험에서 공개된 다른 모델들을 상당한 차이로 능가했고, 전 과업에 걸쳐 전반적 성능 향상 확인
  • 단일 프롬프트와 한 번의 피드백으로 지금껏 AI가 만든 것 중 가장 정교한 학술 사회과학 논문 생성
  • Claude Code에서 모호한 초기 프롬프트와 "make it better" 같은 약간의 추가 피드백만으로 플레이 가능한 게임들을 제작
  • 더 진지한 작업에 들어갈수록 도구 사용 경험은 즐거움과 불안감 사이에 위치 — 무언가를 요청하면 그대로 이루어지기 때문

Maps and Methods — 등시선 지도 제작 사례

  • 등시선 지도(isochrone map) 는 주어진 시간 안에 이동 가능한 거리를 보여주는 지도로, 첫 사례는 1881년에 런던 출발 이동 시간을 보여주기 위해 만들어짐
  • 이전 모델들은 이런 지도를 절반이라도 유용하게 만들지 못했는데, 수천 개의 잠재 이동 거리 조사와 많은 작은 판단이 필요했기 때문임

  • 작업 진행 방식

    • 도시 선택과 공항·기차·도보·운전을 반영한 실제 데이터 기반의 고유 디자인 지도를 요청하는 프롬프트 입력, 데이터는 실시간일 필요 없이 조사 기반의 실데이터일 것을 지시
    • 모델이 먼저 1881년 원본 스타일로 제작할 것을 제안, 동의 후 작업 시작
    • 여러 시간에 걸친 빌드 세션에서 다수의 다른 AI(주로 저렴한 Claude Sonnet)를 실행해 이동 시간 조사 진행
      • TGV부터 Shinkansen까지의 철도 시간표, 여러 학술 논문 기반 국가별 도로 속도, 2,200건 이상의 구체적 항공편 데이터 확보
    • 조사 에이전트가 도는 동안 코딩을 시작하고, 코드 검증을 위한 추가 에이전트와 테스트를 실행하며 진행 상황 기록

  • 원격지 보정과 토큰 사용

    • Greenland 같은 원격지가 정확한 수치 대신 추정치만 담고 있어 실제 이동 시간을 확보하도록 수정 지시
    • 이번에는 연구하고 서로 결과를 검증하는 적대적 에이전트 그룹(adversarial groups) 워크플로 실행
    • Pacific의 Pitcairn Island로 배가 운항하는 빈도, Ottawa에서 Grise Fjord까지 가는 경로를 산출
    • 짧은 시간에 막대한 양의 토큰 소비
  • 사용자가 한 일은 야심 찬 지시와 약간의 피드백뿐, 모델이 수백 개의 작은 판단을 직접 내렸고 그 선택을 이해하거나 개입할 기회는 없었음
    • 작업량뿐 아니라 모델의 방식·접근 선택·결과 깊이에 대한 통제력도 제한됨
  • 결과물은 클릭해 볼 수 있는 등시선 지도로 제공되며, 그래프 하단에서 방법과 출처를 확인할 수 있음

Working with a Mythos-class model — Concord 사례

  • 가장 야심 찬 프로젝트는 인간이 만들어내는 지저분한 답변을 적절히 분류하는 연구 과업 — 아이디어가 얼마나 혁신적인지, 사람들이 왜 특정 책을 좋아하는지 등을 판단
    • 기존에는 인간 연구자가 판단을 내리고 다른 답변과 통계적으로 비교해 데이터 신뢰도를 확인했음
    • AI와 인간 판단의 보정(calibration)은 어렵고 비용이 큼
  • Fable에게 이 문제 해결을 요청, 먼저 19페이지 복잡한 설계 문서 를 생성한 뒤 실행
    • Fable은 이를 가지고 9시간 30분 동안 작업함
  • 결과물은 AI가 Concord라 명명한 소프트웨어로, 다중 데이터셋을 입력받아 인간·AI 응답을 보정하고 복잡한 데이터 분석 수행
    • 완벽하진 않았고 전문가 입장에서 일부 오류와 누락(일부는 요청한 설계에서 기인)을 발견해 수정 지시
    • 전달 범위는 이전에 본 어떤 것도 넘어섰고, 연구자들이 수년간 필요로 했으나 수익성이 없어 만들어지지 않던 소프트웨어
    • 남은 잠재적 버그는 소프트웨어 엔지니어가 해결할 수 있으며, 새로운 소프트웨어 활용 폭증에 대응하려면 코더가 더 많이 필요할 수 있음
    • Concord 코드는 GitHub 저장소에서 사용하거나 수정할 수 있음

한계와 제약

  • Fable의 강력함은 낯섦과 한계를 동반함

  • 토큰 비용

    • Fable은 Opus 대비 2배 비싸고, 프로덕션 비용은 "상당히 많은(a lot)" 수준으로 토큰을 빠르게 소진
    • 다만 저렴한 모델로의 영리한 위임이 실제 비용을 상당히 낮출 가능성 있음

  • 가드레일과 스타일

    • 보안 문제의 아주 미세한 기미에도 가드레일이 작동해 성능이 낮은 Claude 4.8 Opus로 전환되며, 이런 일이 지나치게 자주 발생
    • Mythos 논의는 주로 소프트웨어 보안 영향에 집중되었으나, Fable의 가드레일은 사이버보안 용도 사용을 사실상 차단
    • 여전히 들쭉날쭉한 프런티어(jagged frontier) 가 존재하며, 산출물과 진행 보고서에 특유의 "Claudism" 식 문체가 남아 있음

마법사에서 후원자로 — 인간 역할의 변화

  • 작년에는 이 경험을 '주문을 외우면 무언가 일어나는' 마법사(wizard) 에 비유했음
  • Fable에서는 주문이 충분히 강력해져 사용자 스스로가 마법사라기보다 후원자(patron) 에 가까워짐
    • 원하는 것을 묘사하고, 비용을 지불하고, 결과를 판정 — 실제 작업(conjuring)은 볼 수 없는 곳에서 수백 개의 작은 선택을 통해 진행됨
    • 작업이 과정에서 결과로 이동, 더 이상 조종(steer)하지 않고 의뢰(commission)함

  • 두 가지 가능성

    • 인터페이스가 따라잡지 못한 일시적 현상일 수 있으며, 모델 동작을 들여다보고 중간에 조종하는 더 나은 방법이 나올 가능성
    • 반대로 모델이 유능할수록 인간이 의미 있게 할 일이 줄고 블랙박스가 그 능력의 대가일 가능성이 더 크다고 봄
  • 명백한 의미의 통제 상실은 아니며, 여전히 조종 가능하고 지시를 매우 잘 따름 — 지시가 야심 찰수록 결과가 더 좋아짐
    • 그러나 조종은 더 이상 직접 수행과 같지 않으며, 모델이 자체 에이전트를 띄워 조사·작성·상호 검증을 끝내 완성본을 돌려줌
    • 후원자가 한 명의 예술가에게 의뢰하는 것이 아니라, 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은 복잡하지만 기술적으로 아주 난해하진 않을 가능성이 큼. 그래도 상당한 토큰을 태우고 나면, 그 프롬프트에 대한 여러 모델의 결과물에서 여러 측면의 상당한 차이를 보게 될 것임
      물론 위 요청은 실제로 유용하진 않음. 하지만 한계에 가까워질 때까지 더 큰 덩어리를 맡기지 못할 이유가 뭐가 있나? 어느 시점에는 경계에 닿고, 차이가 분명해질 것임
답변달기