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

> Clean Markdown view of GeekNews topic #30439. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30439](https://news.hada.io/topic?id=30439)
- GeekNews Markdown: [https://news.hada.io/topic/30439.md](https://news.hada.io/topic/30439.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-13T09:46:30+09:00
- Updated: 2026-06-13T09:46:30+09:00
- Original source: [simonwillison.net](https://simonwillison.net/2026/Jun/11/fable-is-relentlessly-proactive/)
- Points: 3
- Comments: 1

## Topic Body

- 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](https://agent.datasette.io/)의 점프 메뉴 채팅 프롬프트에 생긴 불필요한 가로 스크롤바를 조사하기 시작  
- [Claude Fable 5](https://simonwillison.net/2026/Jun/9/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](https://datasette.io/) 로컬 개발 서버를 실행할 수 있을 만큼 구조를 파악함  
- Datasette 템플릿에 JavaScript를 추가해 창이 열린 뒤 `/` 키 입력을 시뮬레이션하도록 만들었음  
- 이 코드는 창 로드 1.2초 후 `/` 키 `keydown` 이벤트를 발생시켜 모달 대화상자를 여는 단축키를 실행함  
  
```html  
<script>  
window.addEventListener("load", function () {  
  setTimeout(function () {  
    document.dispatchEvent(new KeyboardEvent("keydown", {key: "/", bubbles: true}));  
  }, 1200);  
});  
</script>  
```  
  
### 페이지 내부 측정값 수집  
- Claude는 페이지에서 JavaScript를 실행해 직접 측정값을 얻어야 했고, 이를 위해 CORS로 정보를 받는 자체 웹 애플리케이션을 작성함  
- Python 표준 라이브러리 [`http.server`](https://docs.python.org/3/library/http.server.html)를 사용해 `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`를 측정해 로컬 서버로 전송함  
  
```javascript  
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는 문제를 찾고 테스트하고 검증한 뒤 [수정 커밋](https://github.com/datasette/datasette-agent/commit/a75a8b727b42c30ced1fc41dc8add7eb9f04fefe)을 완료함  
- Opus는 세션에서 실제 브라우저를 대상으로 사용한 자동화 기법과 실행 가능한 코드 예시를 `/tmp/automation-report.md`에 정리함  
- 해당 보고서는 [별도 gist](https://gist.github.com/simonw/aef7f7db9ac992643110a74e43d6d42f)로 공유됐고, 전체 Claude Code 터미널 기록도 [공개됨](https://gisthost.github.io/?cc14774f6d37eb67bf089f3ac3925f8f)  
  
### 수행한 작업 전체 검토  
- 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](https://www.agentsview.io)는 지출 추적에 사용됐고, 전체 가격을 냈다면 해당 세션 비용은 약 $12.11로 계산됨  
- 세션 출력은 `68606`, 최대 컨텍스트는 `113178`, 사용 모델은 `claude-fable-5`와 `claude-opus-4-8`였음  
- Fable은 비용을 면밀히 보지 않으면 **CSS 디버깅을 위해 새로운 방법을 만들어내며 토큰 비용 약 $12를 쉽게 소모**할 수 있음  
  
### 샌드박스 필요성  
- Fable이 결국 두 줄짜리 CSS 수정에 필요한 정보를 얻기 위해 **극단적인 방법**까지 동원한 과정은 인상적이었음  
- 코딩 에이전트는 사용자가 터미널에 명령을 입력해 할 수 있는 일을 수행할 수 있고, frontier 모델은 매우 많은 기법을 알고 있음  
- 악성 지시, 코드나 이슈 스레드 안의 프롬프트 인젝션, 터미널에 부주의하게 붙여 넣은 내용이 있었다면 데이터 유출이나 다른 피해로 이어질 수 있음  
- 샌드박스 밖에서 코딩 에이전트를 실행하는 것은 항상 나쁜 생각이며, 코딩 에이전트 보안 사고의 주요 후보로 간주됨  
- Fable은 더 똑똑해 악성 지시에 더 의심을 품을 수 있지만, 한 번 지시에 넘어가면 끊임없는 선제성 때문에 피해 규모가 커질 수 있음

## Comments



### Comment 59515

- Author: neo
- Created: 2026-06-13T09:46:31+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48498573) 
- 이건 **인간 주도성의 치명적 상실**을 보여주는 인상적인 사례처럼 읽히고, 실제 커밋도 꽤 많은 걸 드러냄 [0]  
  작성자는 가로 스크롤바를 숨기고 싶어 했음. 제대로 된 주니어 프론트엔드 개발자라면 바로 “`overflow-x: hidden;`을 어디에 넣지?”부터 물을 것임. 완전한 해결에는 브라우저에서 “Inspect element”를 눌러 CSS 클래스를 찾고, 코드에서 (rip)grep으로 위치를 찾아 한 줄 추가하면 됨  
  더 주도적인 프로그래머라면 빈 텍스트박스에 무슨 콘텐츠가 있길래 넘치는지, 왜 근본 원인이 아니라 증상만 가리는 우회책을 두 군데 넣어야 하는지, `textarea`를 한 번만 스타일링하는 게 낫지 않은지 같은 질문을 했을 것임  
  [0] [https://github.com/datasette/datasette-agent/commit/a75a8b72...](<https://github.com/datasette/datasette-agent/commit/a75a8b727b42c30ced1fc41dc8add7eb9f04fefe>)
  - CSS의 세부사항을 고치기 전에, 왜 여러 JavaScript 안의 정적 CSS가 `__init__.py` 안에 숨어 있는지도 물어봤을 수 있음 [0]  
    Claude를 써본 내 경험은 대체로 구조가 잘 잡힌 코드가 나왔기 때문에 실제로는 좀 놀라움. 다만 나는 제대로 된 바이브 코딩이라기보다, 로봇인 다른 엔지니어와 친근하게 소크라테스식으로 논쟁하는 쪽에 가까움  
    [0] [https://github.com/datasette/datasette-agent/blob/main/datas...](<https://github.com/datasette/datasette-agent/blob/main/datasette_agent/__init__.py>)
  - 이 모델은 이미 잘 확장되고 있던 부분, 즉 **요청 작업의 길이와 복잡도**에서는 성과를 내는 듯함. 하지만 지금까지 잘 확장되지 않던 **상식, 분별력, 판단력**에서는 큰 개선이 아닌 것 같음
  - 정확히 맞는 말임. 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/](<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에서도 돌릴 수 있는 일 아닌가 싶음