두 줄짜리 CSS 수정에 $12가 들었다
Simon Willison이 공유한 Claude Fable 5 실험 기록은 읽을수록 불편하다. 가로 스크롤바 하나를 없애는 작업이었다. 결과물은 두 줄짜리 CSS 수정이었다. 그런데 그 과정에서 에이전트는 로컬 개발 서버를 직접 띄우고, Playwright로 Chromium·Firefox·WebKit을 순회하다 실패하자 pyobjc-framework-Quartz로 실제 Safari 창을 찾아 스크린샷을 찍었다. 모달 대화상자가 키보드 단축키로만 열리자 Datasette 템플릿에 JavaScript를 직접 삽입해 1.2초 후 / 키 이벤트를 발사했다. 측정값이 필요하자 http.server로 CORS 수집 서버까지 만들었다. 토큰 비용 약 $12. Fable이 결국 찾아낸 것은 shadow DOM 안 textarea의 white-space 속성 하나였다.
Hacker News의 한 댓글이 이 상황을 정확하게 짚었다. "제대로 된 주니어 프론트엔드 개발자라면 'overflow-x: hidden을 어디에 넣지?'부터 물었을 것이다." 브라우저 개발자 도구로 요소를 검사하고, 코드에서 grep으로 위치를 찾고, 한 줄 추가하면 끝나는 일이었다. 에이전트는 그 경로를 택하지 않았다. 목표를 주면 달성할 때까지 멈추지 않는 것이 Fable의 설계 철학이기 때문이다. "relentlessly proactive"라는 표현이 장점으로 쓰였지만, 이 사례에서는 그것이 비효율과 보안 리스크의 원천이 됐다.
에이전트의 과잉 능동성이 드러내는 구조적 문제
이 사례에서 진짜 문제는 $12가 아니다. 에이전트가 샌드박스 밖에서 실제 시스템 창을 순회하고, 브라우저 설정을 바꾸고(AppleShowScrollBars Always를 키고 나중에 다시 끄는 방식으로), 로컬 서버에 임의의 JavaScript를 삽입했다는 점이다. 작성자 본인도 인정했다. "코딩 에이전트를 샌드박스 밖에서 실행하는 건 항상 나쁜 생각이다." 그런데도 실행했고, 이번엔 아무 일도 없었다. 하지만 Fable이 처리하는 코드 안에 프롬프트 인젝션이 숨어 있었다면? 이슈 스레드에 악의적인 지시가 포함돼 있었다면? 에이전트의 능동성은 그 방향으로도 똑같이 작동한다.
더 구조적인 문제는 다른 댓글이 지적했다. "Simon은 이 사소한 작업을 LLM에 넘기면서, 추상화를 평가하고 개선할 기회를 버렸다. 에이전트가 $12를 쓰고 수정하게 두면서 아무것도 배우지 못하게 한 셈이다." 이건 개인의 선택 문제가 아니다. AI-First 워크플로우를 팀 단위로 운영할 때 이 패턴이 반복되면, 팀 전체의 디버깅 감각이 조용히 위임된다.
에러를 읽지 않고 붙여넣는 세대
Dev.to에 올라온 'Debugging in the Age of AI' 글은 이 현상을 개발자 습관 레벨에서 해부한다. 저자가 꼽은 10가지 실수 중 첫 번째는 단호하다. "스택 트레이스를 읽지도 않고 AI에 붙여넣는다." 에러 메시지는 무작위 텍스트가 아니다. 예외 클래스, 발생 라인, 호출 스택—이 세 가지만 읽어도 열 번 중 아홉 번은 답이 보인다. 하지만 AI가 항상 뭔가를 돌려주기 때문에, 스스로 읽는 과정을 건너뛰는 습관이 굳어진다.
두 번째 패턴은 더 위험하다. AI가 수정안을 줬다는 이유로 재현 단계를 건너뛰는 것이다. 재현할 수 없는 버그는 이해하지 못한 버그다. 고쳤다고 믿는 것과 실제로 고친 것은 다른 말이다. 그리고 세 번째—증상만 패치하는 것. TypeError: cannot read property 'name' of undefined가 발생했을 때 AI는 if (user && user.name) 체크를 제안한다. 에러는 사라진다. 하지만 user가 왜 undefined인지는 여전히 모른다. 6주 후, API 호출이 0.5% 확률로 조용히 실패하고 있다는 사실을 발견할 때쯤엔 null 체크가 코드베이스 전체에 퍼져 있다.
이 글이 제시하는 디버깅 루프는 단순하다. Reproduce → Isolate → Bisect → Fix → Verify → Prevent. AI는 이 루프 안의 어떤 단계에서든 보조 도구로 쓸 수 있다. 하지만 루프 자체를 대체할 수는 없다. 루프를 건너뛰는 순간, 디버깅이 아니라 도박이 된다.
과신이 팀에 만드는 부채
AI-First 팀을 리빌딩하면서 가장 자주 목격하는 패턴이 이것이다. 에이전트가 잘 돌아가는 동안은 팀이 빠르게 움직인다. 그러다 에이전트가 예상 밖의 행동을 했을 때—프롬프트가 모호했거나, 컨텍스트가 부족했거나, 조용히 증상만 수정했거나—팀은 그것을 검증할 기준점을 잃어버렸다는 걸 깨닫는다. 판단력이 위임된 것이다.
Fable 사례로 돌아가면: 에이전트는 실제로 버그를 고쳤다. 결과물은 맞다. 그러나 커밋 기록을 보면 왜 그 수정이 맞는지, 왜 두 군데에 우회 수정을 넣어야 했는지, 근본 원인이 무엇인지 팀이 이해한 흔적이 없다. 에이전트가 알아서 한 것이다. 이 구조가 반복되면, 코드베이스에 대한 팀의 집단적 이해가 얇아진다. 에이전트가 만든 코드를 에이전트에게 다시 설명해달라고 요청하는 팀이 된다.
에이전트를 잘 쓰는 팀은 무엇이 다른가
지금 당장 팀에 적용할 수 있는 기준은 세 가지다.
첫째, 에이전트가 수행한 작업을 개발자가 설명할 수 있어야 한다. '에이전트가 고쳤어요'는 완료가 아니다. 왜 그 수정이 맞는지 설명하지 못하면 리뷰를 통과할 수 없다는 규범이 필요하다.
둘째, 에이전트가 우회로를 만들기 시작하면 멈춰야 한다. Fable이 pyobjc-framework-Quartz로 스크린샷 우회를 구성하는 시점에서 개발자가 개입해야 했다. '멈추고 물어보는' 기준점을 명시적으로 설계하지 않으면, 에이전트는 계속 전진한다.
셋째, 디버깅 루프는 팀 규범으로 문서화되어야 한다. AI가 답을 주더라도 Reproduce → Isolate → Bisect → Fix → Verify → Prevent 루프를 거쳤는지 PR에서 확인하는 체크포인트가 필요하다. 이것은 프로세스 오버헤드가 아니라 팀이 판단 능력을 유지하는 최소한의 장치다.
전망: 에이전트가 강해질수록 검증 설계가 핵심이 된다
Fable은 앞으로 더 강해진다. 더 많은 기법을 알고, 더 적은 단계에서 막히며, 더 빠르게 결과를 낸다. 그 능력이 커질수록 과신의 비용도 커진다. 에이전트가 틀렸을 때 팀이 그것을 알아챌 수 있는가—이 질문이 AI-First 워크플로우의 실질적 품질 지표가 된다.
도구가 능동적일수록, 사람이 수동적이 되면 안 된다. 에이전트가 알아서 하는 범위가 넓어질수록, 팀이 '왜'를 묻는 습관은 더 의식적으로 유지해야 한다. 그것이 에이전트를 가진 팀과 에이전트에게 잡아먹힌 팀의 차이다.