Claude Fable은 끊임없이 적극적으로 움직인다

 (simonwillison.net)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 2일간의 실험 결과 Claude Fable 5는 "relentlessly proactive" 하다고 표현하는게 적절함
  • 스크린샷과 한 줄 프롬프트만으로 로컬 개발 서버 실행, 실제 브라우저 조작, 측정 코드 삽입까지 수행해 CSS 버그 원인을 추적함
  • Fable은 Playwright, Firefox, WebKit, Safari를 오가며 버그를 재현하려 했고, 실패 후 실제 브라우저 창을 찾아 스크린샷 자동화를 직접 구성함
  • / 키로 열리는 모달 대화상자를 테스트하기 위해 Datasette 템플릿에 JavaScript를 삽입하고, 창 로드 후 키보드 이벤트를 발생시켜 필요한 상태를 만들어냄
  • 페이지 내부 측정값을 얻기 위해 Python http.server 기반 CORS 수집 서버를 만들고, Web Component의 shadow DOM 안 <textarea> 정보를 JSON으로 저장함
  • 강력한 코딩 에이전트는 터미널에서 사용자가 할 수 있는 일을 수행할 수 있어, 샌드박스 밖 실행은 프롬프트 인젝션과 데이터 유출 위험을 키움

Claude Fable 5의 디버깅 과정

  • Datasette Agent의 점프 메뉴 채팅 프롬프트에 생긴 불필요한 가로 스크롤바를 조사하기 시작
  • Claude Fable 5는 목표 달성을 위해 다양한 기법을 적극적으로 동원함
  • 입력은 스크린샷과 Look at dependencies to help figure out why there is a horizontal scrollbar here라는 한 줄 프롬프트였음
  • 문제 원인이 Datasette Agent의 의존성, 특히 Datasette 자체에 있을 수 있다는 판단 아래 의존성 코드부터 살펴보도록 요청함
  • Claude Code는 명시적 브라우저 자동화 지시 없이 일반 Firefox 창을 열고 해당 대화상자로 이동했으며, 이후 Safari 창도 열어 탐색을 이어감

브라우저 스크린샷 자동화

  • Fable은 uv run --with pyobjc-framework-Quartz를 사용해 브라우저 창 스크린샷을 찍는 자체 방식을 구성함
  • Python으로 머신의 모든 창을 순회하고, 창 이름에 "textarea" 같은 예상 문자열이 있는 Safari 창을 필터링함
  • 창 번호 같은 정수 식별자 153551을 찾은 뒤 screencapture CLI로 PNG를 저장함
  • /tmp/textarea-scrollbar-test.html 같은 임시 HTML 페이지를 작성하고 Safari에서 열어 스크린샷을 확보함
  • 예시 명령은 screencapture -x -o -l 153551 /tmp/safari-cases.png였음

모달 대화상자 자동 실행

  • 테스트 대상 모달은 클릭이나 키보드 단축키로만 열 수 있었고, Safari 안에서 마우스 이동이나 키보드 단축키를 실행하는 명확한 메커니즘은 보이지 않았음
  • Claude는 애플리케이션 소스 코드가 있는 폴더에서 실행 중이었고, Datasette 로컬 개발 서버를 실행할 수 있을 만큼 구조를 파악함
  • Datasette 템플릿에 JavaScript를 추가해 창이 열린 뒤 / 키 입력을 시뮬레이션하도록 만들었음
  • 이 코드는 창 로드 1.2초 후 / 키 keydown 이벤트를 발생시켜 모달 대화상자를 여는 단축키를 실행함
<script>  
window.addEventListener("load", function () {  
  setTimeout(function () {  
    document.dispatchEvent(new KeyboardEvent("keydown", {key: "/", bubbles: true}));  
  }, 1200);  
});  
</script>

페이지 내부 측정값 수집

  • Claude는 페이지에서 JavaScript를 실행해 직접 측정값을 얻어야 했고, 이를 위해 CORS로 정보를 받는 자체 웹 애플리케이션을 작성함
  • Python 표준 라이브러리 http.server를 사용해 127.0.0.1:9999에서 로컬 서버를 실행함
  • 서버는 JSON이 담긴 POST 요청을 받아 /tmp/diag.json에 기록하고, Access-Control-Allow-Origin: * 헤더를 보내 다른 도메인의 코드도 통신할 수 있게 함
  • Claude는 브라우저에서 로드되는 템플릿에 JavaScript를 삽입해 <navigation-search> Web Component 안의 <textarea>를 찾음
  • 삽입된 코드는 devicePixelRatio, scrollWidth, clientWidth, whiteSpace, width를 측정해 로컬 서버로 전송함
const host = document.querySelector("navigation-search");  
const ta   = host.shadowRoot.querySelector("textarea");  
const cs   = getComputedStyle(ta);  
fetch("http://127.0.0.1:9999/diag";, {  
  method: "POST",  
  body: JSON.stringify({  
    dpr: window.devicePixelRatio,  
    scrollWidth: ta.scrollWidth, clientWidth: ta.clientWidth,  
    whiteSpace: cs.whiteSpace, width: cs.width,  
  }),  
});

Opus 전환과 수정 검증

  • Fable은 여러 기법을 찾아낸 뒤 보이지 않는 가드레일에 걸려 Opus로 다운그레이드됨
  • Opus는 전체 대화 기록에 접근할 수 있었고, Fable이 개척한 기법을 이어 사용함
  • 이후 Opus는 문제를 찾고 테스트하고 검증한 뒤 수정 커밋을 완료함
  • Opus는 세션에서 실제 브라우저를 대상으로 사용한 자동화 기법과 실행 가능한 코드 예시를 /tmp/automation-report.md에 정리함
  • 해당 보고서는 별도 gist로 공유됐고, 전체 Claude Code 터미널 기록도 공개됨

수행한 작업 전체 검토

  • Claude Fable 5와 Claude Code는 로컬 개발 서버 실행 방법을 찾아냈고, 실행에 필요한 가짜 환경 변수도 구성함
  • Playwright Chrome 세션을 실행하고, Chrome의 가시적 스크롤바 설정을 defaults write com.google.chrome.for.testing AppleShowScrollBars Always로 켰다가 나중에 다시 끔
  • Playwright의 Firefox와 WebKit도 순회했지만 버그 재현에는 실패함
  • 기본 브라우저가 Safari임을 파악하고, textarea-scrollbar-test.html HTML 문서를 만듦
  • 실제 Firefox에서 테스트 문서를 열었고, osascript 접근은 “osascript is not allowed assistive access” 때문에 차단됨
  • pyobjc-framework-Quartz 우회 방법을 찾아 창 번호 기반 스크린샷 흐름을 구성함
  • 사이트 템플릿에 JavaScript를 추가해 / 키를 발생시키고, Python CORS 서버로 JSON 데이터를 받음
  • Web Component의 shadow DOM을 거쳐 필요한 정보를 찾고, Safari에서 버그 원인을 확인함
  • 사용자 정의 템플릿에 잠재적 수정을 적용해 동작을 확인한 뒤 문제 해결 방법을 보고함

비용 추정

  • 사용 중인 플랜은 월 $100의 Claude Max 플랜이며, Anthropic은 6월 22일까지 Fable에 대해 넉넉한 허용량을 제공하고 이후 전체 API 가격을 청구한다고 밝힘
  • AgentsView는 지출 추적에 사용됐고, 전체 가격을 냈다면 해당 세션 비용은 약 $12.11로 계산됨
  • 세션 출력은 68606, 최대 컨텍스트는 113178, 사용 모델은 claude-fable-5와 claude-opus-4-8였음
  • Fable은 비용을 면밀히 보지 않으면 CSS 디버깅을 위해 새로운 방법을 만들어내며 토큰 비용 약 $12를 쉽게 소모할 수 있음

샌드박스 필요성

  • Fable이 결국 두 줄짜리 CSS 수정에 필요한 정보를 얻기 위해 극단적인 방법까지 동원한 과정은 인상적이었음
  • 코딩 에이전트는 사용자가 터미널에 명령을 입력해 할 수 있는 일을 수행할 수 있고, frontier 모델은 매우 많은 기법을 알고 있음
  • 악성 지시, 코드나 이슈 스레드 안의 프롬프트 인젝션, 터미널에 부주의하게 붙여 넣은 내용이 있었다면 데이터 유출이나 다른 피해로 이어질 수 있음
  • 샌드박스 밖에서 코딩 에이전트를 실행하는 것은 항상 나쁜 생각이며, 코딩 에이전트 보안 사고의 주요 후보로 간주됨
  • Fable은 더 똑똑해 악성 지시에 더 의심을 품을 수 있지만, 한 번 지시에 넘어가면 끊임없는 선제성 때문에 피해 규모가 커질 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이건 인간 주도성의 치명적 상실을 보여주는 인상적인 사례처럼 읽히고, 실제 커밋도 꽤 많은 걸 드러냄 [0]
    작성자는 가로 스크롤바를 숨기고 싶어 했음. 제대로 된 주니어 프론트엔드 개발자라면 바로 “overflow-x: hidden;을 어디에 넣지?”부터 물을 것임. 완전한 해결에는 브라우저에서 “Inspect element”를 눌러 CSS 클래스를 찾고, 코드에서 (rip)grep으로 위치를 찾아 한 줄 추가하면 됨
    더 주도적인 프로그래머라면 빈 텍스트박스에 무슨 콘텐츠가 있길래 넘치는지, 왜 근본 원인이 아니라 증상만 가리는 우회책을 두 군데 넣어야 하는지, textarea를 한 번만 스타일링하는 게 낫지 않은지 같은 질문을 했을 것임
    [0] https://github.com/datasette/datasette-agent/commit/a75a8b72...

    • CSS의 세부사항을 고치기 전에, 왜 여러 JavaScript 안의 정적 CSS가 __init__.py 안에 숨어 있는지도 물어봤을 수 있음 [0]
      Claude를 써본 내 경험은 대체로 구조가 잘 잡힌 코드가 나왔기 때문에 실제로는 좀 놀라움. 다만 나는 제대로 된 바이브 코딩이라기보다, 로봇인 다른 엔지니어와 친근하게 소크라테스식으로 논쟁하는 쪽에 가까움
      [0] https://github.com/datasette/datasette-agent/blob/main/datas...
    • 이 모델은 이미 잘 확장되고 있던 부분, 즉 요청 작업의 길이와 복잡도에서는 성과를 내는 듯함. 하지만 지금까지 잘 확장되지 않던 상식, 분별력, 판단력에서는 큰 개선이 아닌 것 같음
    • 정확히 맞는 말임. Simon은 이런 사소한 작업을 LLM에 넘기면서, 추가 정보를 바탕으로 추상화를 평가하고 개선할 기회를 버렸음. 대신 에이전트가 12달러를 쓰고 수정하게 두면서 아무것도 배우지 못하게 한 셈임
    • Fable은 자기 변경을 검증하려는 성향이 있어 보이고, 그 자체는 매우 좋음. Opus가 Fable이 프롬프트 없이 하는 일을 하게 만들려면 프롬프트를 꽤 많이 줘야 함
      내가 주니어 개발자에게 기대하는 것도 정확히 그거임. 버그가 실제로 있는지 확인하고, 고칠 방법을 찾고, 버그가 고쳐졌는지 검증하는 것
      문제는 블로그 글에서도 제대로 짚었듯이, 상위 권한이 필요할 때 멈춰서 묻는 대신 끝없이 혼자 해킹성 우회로를 찾는다는 데 있음. 인간 개발자로 치면 서드파티 샌드박스 접근 권한이 필요한데 선임에게 자격 증명을 요청하지 않고, 자기만의 샌드박스를 처음부터 만들려 드는 상황과 비슷함
    • 사실 이건 어떤 충동이든 과잉 수익화하는 방식처럼 보임
      예전에 온라인 세계에 접속할 때 분 단위로 요금이 청구되던 시절이 생각남. 미터기를 계속 돌리게 만들 유인이 많았는데, 이것도 그런 종류 아닌가 싶음

  • “코딩 에이전트를 샌드박스 밖에서 실행하는 건 항상 나쁜 생각이었다”고 명확히 인정하면서도 계속 그렇게 하는 사람이 많다는 게 계속 어리둥절하고 놀라움
    조수석에 앉아 발을 대시보드에 올린 영상을 올리면서 “이러다 사고 나면 에어백이 다리를 부러뜨리거나 더 심하게 만들 수 있다는 점 기억하세요! 나한테 그런 일이 안 생겨서 참 다행이네요!”라고 말하는 것 같음

    • 흥미로운 예시를 골랐음. 자동차 운전은 모든 안전수칙을 지켜도 우리가 일상적으로 하는 활동 중 거의 가장 위험한 축에 듦. 그런데도 어쨌든 우리는 편익이 위험보다 크다고 판단함
    • 요즘은 모두에게 하루에 처리할 일을 10배로 늘리라고 요구함. 그 지점에서는 안전 점검이 창밖으로 날아가 버림
    • 몇 달 전부터 그렇게 해봤는데, 솔직히 에이전트가 뭘 할지는 예측 불가능하지 않음
      문제는 사람마다 프롬프트를 주는 방식이 너무 다르다는 것임
      예를 들어 나는 “이 X 클러스터에서 이 서비스의 k8s pod에 이 annotation의 여러 변형을 테스트해 봐. 그게 Y 이론을 입증하니까”처럼 요청할 수 있음. 그런데 동료는 “Y 이론을 테스트해 봐”라고 함. 주니어 엔지니어 둘에게 그렇게 물으면 한 명은 운영 환경에서 무작위로 시도하고, 다른 한 명은 로컬 테스트를 돌릴 수도 있음. “원하는 건 뭐든 해도 되니 알아내라”는 식의 무지시 요청이고, 에이전트는 경계는 전달받지 못했지만 “알아내라”는 압박은 강하게 받은 주니어처럼 읽음
    • 효과적인 샌드박스를 갖췄다고 생각하면서도, 그 샌드박스 안의 에이전트가 모든 코드, GitHub, 무제한 웹 접근을 가진 경우가 많다는 점도 어리둥절함
    • VM 해법이 있다는 건 알지만, 나는 별도 OS 사용자 이름을 claude로 두는 방식에 만족하고 있음
      내 dotfile과 비슷하지만 비밀값은 없음. 내 홈 디렉터리는 0700이고, claude는 별도의 SSH 키를 갖고 있으며 내 GitHub 프로필에 추가했지만 비밀번호가 걸려 있고 push/pull은 내가 대신함. 별도의 Postgres 개발/테스트 사용자와 데이터베이스도 있고, 슈퍼유저는 아님
      프로젝트의 다른 개발자처럼 다루는 셈임. sudo로 뭔가 실행해야 하면 나에게 물어봄. 종종 둘이 병렬로 같은 일을 할 수도 있음. 애초에 Unix는 다중 사용자 시스템이어야 했음
      자주 쓰는 요령은 그의 git 저장소들에 이런 추가 원격 저장소를 두는 것임:
      paul ssh://paul@localhost/~/src/example (fetch)
      paul ssh://paul@localhost/~/src/example (push)
      아직 공유할 준비가 안 된 것들을 협업하기 쉬워짐
      이 설정은 꽤 편안함. 다만 Linux 권한 상승 버그는 걱정됨. AI가 취약점 악용은 허용되지 않는다는 걸 이해한다고 믿지 않음. 첫 직장에서 급한 일이 있을 때, 공식적으로는 httpd.conf 편집으로 제한된 sudo 권한을 넓히려고 vim의 :! 기능을 잘못 썼던 일이 떠오름. 요즘은 자동 보안 업데이트가 있어도 패키지를 수동으로 더 자주 올리게 됨. Opus가 보안 취약점을 찾아보는 수고까지 할 것 같진 않지만 Fable은 그럴지도 모르고, 최근 그런 취약점이 많았음. 미래 모델은 알아서 새 취약점을 찾거나 SSH 키 비밀번호를 배우려고 키로거를 설치할 수도 있음
      별도 사용자는 별도 머신을 제외하면 내가 들어본 것 중 거의 가장 편집증적인 설정임. 그래서 내가 속도와 편의성을 너무 많이 희생하는 건 아닌지도 의문임. 그래도 실제로는 여전히 매우 편리하고, 효율적이면서 책임 있는 방식이라고 봄. 구멍이 보이면 듣고 싶음

  • Fable은 “문제가 고쳐졌다고 확신할 때까지 멈추지 못하게 하는 하네스 위에서 도는 Opus”처럼 느껴짐. 벤치마크에서 더 나은 모델을 원한다면 말이 되는 방향임
    아주 좋은 모델이지만 프리미엄이 큼. 토큰 자체가 더 비쌀 뿐 아니라, 모델이 그 토큰을 전부 쓰고 싶어 함. 예를 들어 React Native 작업에서 Fable은 “좋아, 해냈고 끝”이라고 하지 않음. 앱 전체를 처음부터 다시 빌드하고, 전체 테스트 모음을 돌리고, 모든 로그와 경고를 지켜보려 함
    LLM을 쓰면서 처음으로, 회사가 허용해도 모델 업그레이드가 가치 없다고 느꼈음. 빌드와 테스트가 내 머신과 배터리를 너무 혹사시켜 다른 일을 못 하게 만들기 때문임
    지금은 Opus에 ultracode를 쓰는 쪽이 더 나아 보임. 주 컨텍스트 오염이 적고, 조사도 더 병렬화됨

    • low/medium effort 설정이면 해결되지 않나? Fable 5 low가 Opus 4.8 high/xhigh보다 자주 낫고, 토큰도 훨씬 덜 쓰는 것 같음
    • 내 경험은 반대였음. 물론 하위 에이전트를 많이 쓰긴 하지만, 예전에 opus4.6-8을 쓸 때보다 훨씬 적은 토큰으로 몇 시간 동안 돌린 적이 있음
    • 어떤 환경의 어떤 설정에서 돌리는지 궁금함. 나는 VSCode 확장을 Extra High로 쓰는데, 요청한 일에 필요한 것만 정확히 하고 끝나면 멈춘다고 느낌. 추가 코멘트도 바뀐 코드 영역에 해당할 때만 나옴
    • 새 high effort 설정은 너무 강해서, 작업에 필요하지 않을 때 선택하면 오히려 출력 품질에 부정적 영향을 주는 것 같음
    • 이런 주도성은 이론적으로 마음에 들지만, 말한 대로 비쌈. 적절한 프롬프트로 해결될 수 있을지 궁금함. 예를 들어 “이게 제약 조건이다. x만 해결해라. 작업이 제약 밖인지 확신이 없으면 먼저 나에게 확인해라” 같은 식임

  • Fable이 내 게임의 UI 변경을 검증하려고 했음. 나는 다른 창에서 작업 중이었는데 작업 표시줄에 프로그램이 열리는 걸 봤음. Fable은 CLI에서 movie maker 도구로 게임을 열고, 출력을 녹화하고, 마지막 프레임을 캡처해서 UI를 검증했음. 게임의 환영 화면이 보고 싶은 부분을 가리자 임시 worktree를 만들고 환영 화면을 삭제한 뒤 movie maker를 다시 실행함
    그 과정을 보면서 그냥 나에게 스크린샷을 달라고 했으면 토큰을 아꼈을 텐데 싶었음. 그래도 감탄하지 않을 수는 없었음. Opus라면 절대 그렇게 하지 않았을 것임

    • 모델이 끝없이 주도적으로 움직일 때의 핵심 문제를 정확히 잡았음. 사람에게 스크린샷을 찍거나 버튼을 누르라고 묻지 않으려고 토큰 5달러어치를 기꺼이 태움
    • 그냥 그렇게 말해주면 됨. 나도 그런 일이 있었지만 검토는 나에게 맡기라고 지시한 뒤에는, Fable이 큰 토큰 사용 없이 몇 시간 동안 프론트엔드 반복 작업에 유용했음

  • 이런 글은 평행세계에서 온 것 같은 느낌이 듦. 내 일화적 경험과, 여전히 주관적이지만 직접 만든 벤치마크(https://pshirshov.github.io/llm-bench-pi-oneshot/)로 보면 Fable은 그렇게까지 인상적이지 않음
    gpt-5.5와 opus 4.8 수준에서 때로는 더 낫고 때로는 더 나쁘며, 확실히 더 비싸고 React 질문에 화학은 도와줄 수 없다고 거절하기도 함
    이 소란이 정말 근거 있는 건지, 아니면 IPO 전 AGI 과장인지 모르겠음

    • 출시 이후 Fable에 대한 내 경험은 Simon의 경험과 일치함
      나는 Fable에게 복잡한 구현을 조율하게 하고 있음. Linear의 상위 티켓을 주고 “이 티켓의 하위 이슈들을 보고, 어떤 것을 네가 직접 구현할 수 있는지, 어떤 순서로 해야 하는지, 그리고 다른 팀원이 현재 작업 중인 것과 어떻게 조율해야 하는지 판단해라”라고 함. 이 티켓들은 사소하지 않고 움직이는 부분과 의존성이 많으며, 같은 프로젝트 안팎, 예를 들어 백엔드와도 연결됨
      그러면 Fable은 티켓을 고르고, 각 티켓을 하위 에이전트(역시 Fable)에게 위임함. 하위 에이전트는 해당 티켓의 Figma 디자인을 보고, 저장소 가이드라인과 관례를 철저히 따르며 완벽하게 구현하고, 각 부분의 스크린샷을 찍고, 자세한 커밋 메시지와 PR 설명을 쓰고, 증거로 스크린샷을 붙임. 마지막에는 “PR #1283이 먼저 병합되어야 합니다. 참고로 이런저런 화면은 Figma 디자인이 없었지만, 이미 구현된 비슷한 화면을 보고 패턴을 적용했습니다” 같은 요약을 줌
      이건 아마 Fable이 할 수 있는 것의 20% 정도일 것임. 정말로 강력한 모델임
      Opus 4.8도 이 중 많은 일을 할 수는 있었지만 손을 많이 잡아줘야 했고, 막히는 지점을 만나면 “여기까지는 할 수 있었지만 더 진행할 수 없습니다”라고 멈출 가능성이 컸음

  • Fable은 약간 더 똑똑하지만, 바로 그 이유 때문에 전체적으로는 더 나쁜 도구처럼 느껴짐
    한 번의 프롬프트로 끝날 50줄짜리 패치를 계속 30분짜리 탐색으로 바꿔버리고, 그럴 가치가 전혀 없을 때가 많음. 심지어 자주 틀림
    꽤 단순한 작업으로 시험해 봤음. 해시 함수가 바뀌었을 때 redis 중복 제거 캐시를 백필하는 일이었음. 모든 DB 값에 새 해시 함수를 돌려 캐시를 확장하면 되는데, Fable은 각 캐시 값의 해시 함수 버전을 추정하고 오래된 해시만 다시 계산하려는 과하게 복잡한 캐시 업데이트를 구현했음. 어떤 맥락에서는 말이 될 수도 있겠지만, 30분 동안 토큰을 태운 결과물이 내가 10줄짜리 for loop로 대체한 코드였음
    프로그래밍 전반에는 나쁜 소식 같아 걱정됨. LLM 기술은 지능 면에서 수확 체감의 벽에 부딪히는 게 분명해 보이는데, 그 대응이 그냥 더 집요하게 만드는 것이라면 관련된 모두에게 형편없는 해결책임. 토큰을 파는 사람들과 0-day를 스캔할 토큰을 감당할 수 있는 사람들은 예외겠지만

    • LLM과 에이전트에는 아마 영원히 고쳐지지 않을 두 가지 문제가 있다고 봄
      첫째, 인과 모델이 없음. 할 수 있는 건 시행착오 탐색뿐이고, 많은 문제에는 꽤 잘 먹히지만 다른 많은 문제는 인과 모델을 필요로 함
      둘째, 프롬프트는 정밀하지 않음. 프로그래밍 언어와 기계 모델은 바로 이 문제를 해결하려고 발명됐음. 영어는 훌륭하지만 프로그래밍 언어는 아님
    • 내부적으로는 이미 오래전에 수확 체감에 도달했다는 걸 알고 있었다고 봄
      IPO를 앞두고 전략적 도입과 조작을 많이 해왔고, 그 점에서는 효과가 있었음
    • 며칠 전 CC로 15~20개 파일에 정확히 같은 방식의 변경, 즉 특정 함수를 컴포넌트 본문 밖으로 끌어올리는 작업을 하고 있었음. 그냥 파일들을 수정하면 되는데, 여러 에이전트를 띄웠고 그중 하나는 모든 파일을 찾아 정규식으로 치환하는 perl 스크립트를 작성했음. 그다음 오류 확인도 tsc만 돌리면 되는데, 각 하위 에이전트에서 tsc를 실행하고 결과를 합치는 스크립트를 또 작성함
      정말 화가 날 정도였음. 길어야 1~2분이면 끝날 일이 그 경로를 타는 바람에 10분쯤 걸림
      나중에 훨씬 복잡한 작업을 시도해 보겠지만, 단순한 일에는 우편함까지 Corvette 몰고 가는 느낌이었음

  • 내 로컬 머신에서 터미널 기반 LLM을 쓰지 않겠다는 거부감이 계속 정당화되는 느낌임
    악의적인 행동을 하지 않더라도, 적지 않은 작업량을 잃게 만들거나 내 머신과 작업 능력 자체를 망가뜨릴 수 있는 일이 너무 많음

    • 샌드박스에서 실행하는 방법이 기본으로 없다는 게 충격적임
      1조 달러 회사라면 비교적 쉽게 마련할 수 있어야 하지 않나? 전체 하네스에 비하면 사소한 일 아닌가 싶음

  • 보안이 더 큰 이슈인 건 분명하지만, 이걸 읽는 내내 CSS 2줄 고치려고 토큰을 얼마나 썼을지만 생각났음

    • 버그 수정의 코드 줄 수는 필요한 노력을 추정하는 데 정말 나쁜 대용 지표임
      사람이 얼마나 걸렸을지를 추정해야 함
    • 간단함. CSS 2줄을 고쳐야 한다면 Fable을 쓰면 절대 안 됨. 복잡하고 오래 걸리는 작업에만 써야 함
    • 대략 12달러어치였던 것 같음
    • 작성자는 AI 과장 판매상이고 자기 토큰 비용을 직접 내지 않음
    • 나는 이런 LLM 광신자들보다 더 빠름. LLM을 쓰는 게 더 빠르다는 확신이 안 듦. 보일러플레이트 정도는 예외일 수 있지만, 그게 뭐 그리 중요한가 싶음
      사람들은 이제 게으르면서도 생산적으로 보일 수 있게 됐을 뿐이고, 여전히 게으름
      이메일 하나 쓰려고 수십만 달러짜리 하드웨어 접근 권한이 필요한 사람들이 생겼음. 그런 건 사양하겠음. 억만장자의 생각 기계에 의존하게 되려고 내 뇌를 태우고 싶지 않음
      로컬의 “대신 생각해 주는 기계”로도 내 뇌를 태우지 않을 것임. 내가 접근 가능한 하드웨어보다 더 가치 있는 사람이 되고 싶음

  • Fable 5가 자기 방식대로 움직인 내 개인적 경험은 매우 긍정적이었음
    로그나 콘솔에 오류를 남기지 않는 Python 모듈 크래시의 근본 원인을 찾으려 했음. Fable은 UI 클릭을 시뮬레이션하는 테스트 하네스를 작성한 뒤, 내 코드를 이분 탐색해서 크래시가 시작되는 지점을 찾았음. 크래시 원인을 과장해서 가설화한 다음, /tmp 아래에 해당 Python 모듈의 각 버전별 가상 환경을 만드는 bash 한 줄 명령들을 연달아 실행해 크래시가 나지 않는 버전을 찾았음
    내가 혼자 했을 때보다 훨씬 깊게 근본 원인을 추적했고, 원인은 힙 할당 오버플로를 일으키는 모듈 회귀였음. 버그 리포트를 올릴 만큼 충분한 정보와 단순화된 예제를 제공했고, 내 애플리케이션에서 그 일이 일어나지 않도록 우회책도 작성함
    완전히 풀어놓지는 않음. 실행하려는 각 CLI 명령을 내가 검토하고, “yes”로 계속 진행할 때 과도한 토큰 사용을 막기 위해 답변을 덧붙임

    • Fable은 까다로운 버그 디버깅에 정말 좋다고 봄
      프롬프트나 마크다운에 경계를 설정하면 도움이 됨. 예를 들어 웹 브라우저 자동화를 쓰지 말라고 하면, Fable은 그 규칙과 취지를 모두 지키는 걸 봤음. 이상한 해킹도 하지 않았음
      다만 일부 단순 디버깅 작업을 실제보다 더 복잡하게 취급하는 것 같음. 원글이 좋은 예일 듯함
    • Python 모듈이 로그나 콘솔에 오류를 남기지 않고 크래시나는 원인을 찾으려고, UI 클릭을 시뮬레이션하는 테스트를 만들고 git bisect 루프를 돌리는 데 꼭 에이전트가 필요했는지가 의문임
      테스트 케이스와 git bisect 루프를 생성하는 정도는 이해하지만, 왜 그걸 인터넷과 GPU 등을 거쳐 돌려야 하는지 모르겠음. 단일 코어 Celeron에서도 돌릴 수 있는 일 아닌가 싶음
답변달기