어리석은 모델은 이제 그만 사용하라

URL: https://www.youtube.com/watch?v=iBrAWpjXNxs 날짜: 2026-09-18 채널: aiDotEngineer

---

메타데이터

• video_id: iBrAWpjXNxs
• title: 어리석은 모델은 이제 그만 사용하라
• title_original: Please stop using stupid models
• published_at: 2026-09-18
• source_name: YouTube
• source_channel_verified: Theo - t3․gg (작업 식별자: aiDotEngineer)
• category: ai-llm
• thumbnail_url: https://i.ytimg.com/vi/iBrAWpjXNxs/maxresdefault.jpg
• transcript_language: English (auto-generated)

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==최신 프런티어 모델의 진짜 가치는 가장 어려운 문제를 푸는 최고점이 아니라, 긴 작업을 수행하는 동안 어리석은 실수를 덜 하는 높은 바닥에 있다.==

• 짧고 명확한 Jira 티켓에서 특정 파일을 고치는 일은 Opus, Fable, Gemini도 대체로 처리할 수 있지만, 모호한 버그 제보에서 테스트·영상 증명·PR·리뷰 대응까지 이어지는 작업에서는 모델의 실패율 차이가 누적된다.
• Fable·Astra 같은 최신 모델을 높게 평가하는 이유는 새로운 과학을 발명해서가 아니라, 더 오래 실행되고 더 적은 안내로 더 자주 올바른 결과를 내기 때문이다.
• 단위 시간의 실패율을 조금만 낮춰도 실행 시간이 길어질수록 성공 확률이 지수적으로 커지므로, 모델을 천장(최고 성능)보다 바닥(최저 성능과 실패 빈도)으로 비교해야 한다.

모델 성능의 실무적 척도는 화려한 3D 게임이나 새로운 수학 문제를 만들어 내는 능력만이 아니다. 사람이 개입하지 않고 얼마나 오래 맥락을 유지하며 실행되는지, 사람이 돌아왔을 때 이미 작동하는 결과일 확률이 얼마나 되는지, 그리고 준비·검증에 들어가던 엔지니어 시간을 얼마나 줄이는지가 더 중요하다. 이를 위해 개발자는 파일명을 미리 지정하는 좁은 프롬프트에서 벗어나 문제의 증상부터 검증과 배포·리뷰 대응까지 수평적으로 넓은 작업을 한 번에 맡기고, 에이전트가 반복해서 막히는 지점은 프롬프트보다 코드베이스와 시스템을 고쳐야 한다.

1. “낮은 모델로도 차이가 없다”는 주장과 반박

짧고 잘 정리된 작업에서는 구형 모델도 충분할 수 있지만, 작업의 시작점과 종료점 사이가 넓어지면 모델 세대와 티어의 차이가 실패 확률로 드러난다.

1.1. David Kramer의 모델 다운그레이드 주장

1. 논쟁의 출발점

   1. David Kramer(Zeg)의 배경: Sentry 창업자 David Kramer가 Fable이나 Astra를 쓰는 사람 대부분은 구독료를 감당하기 어려워서 사용한다고 보고, Opus나 Soul 같은 다른 고추론 모델로 돌아가 보라고 제안했다.
   2. 주장의 결론: Opus나 Soul로 바꿔도 실제 작업은 별로 달라지지 않을 것이므로, 비싼 최신 모델을 쓸 이유가 크지 않다는 취지다.
   3. 첫 반응: 이 주장은 Kramer의 과거 발언 중에서도 최악이며, 그렇게 느끼는 사람은 프롬프트를 제대로 쓰지 못하고 있다는 강한 반박이 나왔다. 단순히 “차이가 없다”고 느낀 경험은 반증 가능성이 약하지만, 어떤 작업을 시키면 차이를 직접 확인할 수 있다는 뜻이다.

2. 주장을 일부 인정할 수 있는 조건

   1. 좁은 Jira 티켓: 파일 위치와 현재 잘못된 동작이 정확히 적힌 Jira 티켓에서 특정 파일을 찾아 한 부분을 수정하고 완료 사실을 알려 달라는 요청은 Opus, Fable, 심지어 Gemini도 크게 어려워하지 않는다.
   2. 품질 기준이 낮은 짧은 창: 목표와 종료 조건이 이미 정리되어 있고 사람이 바로 테스트할 준비가 되어 있다면 Opus가 충분히 좋은 결과를 내므로, 그 범위에서는 Kramer의 관찰이 맞을 수 있다.
   3. 논쟁의 실제 범위: 문제는 단순한 작업 자체가 아니라, 단순한 작업을 매번 짧게 잘라 사람이 다음 단계와 검증을 직접 맡는 방식이다.

1.2. 문제의 시작점과 결과의 종료점

1. 모호한 버그에서 출발하는 작업

   1. 현장 입력: T3 Code 사용자가 휴대폰으로 버그 화면을 보내면 개발자는 파일명·원인·구현 위치가 없는 스크린샷만 받는다.
   2. 한 문장 지시: 스크린샷을 T3 Code 에이전트에 붙여 넣고 “고쳐라, 테스트하라, 이제 작동하는 모습을 보여 주는 영상을 녹화하라, PR 링크를 보내라, 리뷰에서 생기는 이슈가 모두 해결될 때까지 돌봐라”라고 요청한다.
   3. 핵심 능력: 문제의 증상에서 실제로 작동하는 수정, 테스트, 시각적 증명, PR, 리뷰 대응까지 사람의 추가 개입 없이 이어 가는 능력이 모델 차이를 만든다.

2. 시간이 지난 뒤 확인하는 결과

   1. 맥락 유지: 개발자가 다른 일을 하고 한 시간 뒤 돌아왔을 때 에이전트가 무엇을 하던 중인지 잊지 않고 있어야 한다.
   2. 토큰과 엔지니어 시간: 이 방식은 토큰을 더 쓰지만 토큰만 비싼 것이 아니다. 엔지니어의 시간도 비싸므로, 토큰 절약을 위해 사람이 준비와 확인을 반복하는 방식이 항상 경제적이지 않다.
   3. Julius 사례: Julius 같은 희소한 인재가 자신의 연봉에 해당하는 토큰을 사용해 생산성을 세 배 높일 수 있다면 합리적인 선택이다. 그를 세 배 더 생산적으로 만드는 편이, 그의 작업을 방해할 가능성이 있는 엔지니어 두 명을 추가 채용하는 것보다 낫다.

2. 코드 실행으로 검증하는 리뷰 에이전트

코드는 텍스트를 읽는 것만으로 모든 고장 방식을 드러내지 않으므로, 리뷰 에이전트도 실제 컴퓨터와 샌드박스를 사용해야 한다.

2.1. 코드만 읽는 AI 리뷰의 맹점

1. 정적 독해의 한계

   1. 큰 PR 검증: 준비가 됐는지 확신하기 어려운 큰 PR을 만났다면 에이전트가 해당 변경을 내려받고 직접 실행하며 테스트하게 해야 한다.
   2. 보이지 않는 고장: 코드를 눈으로만 읽으면 런타임에서만 나타나는 고장, 실제 상호작용 순서에서 발생하는 문제, UI 흐름의 끊김을 놓치기 쉽다.
   3. 기존 리뷰 봇의 실수: 많은 AI 코드 리뷰 봇은 코드를 읽는 것만으로 동작 방식을 모두 알 수 있다고 가정한다. 그러나 코드는 텍스트에 명확히 보이지 않는 방식으로도 깨진다.

2. 실행 기반 판단

   1. 실제 컴퓨터의 가치: 코딩 에이전트가 실제 컴퓨터를 사용할 때 훨씬 잘 작동하듯 리뷰 에이전트도 실행 환경을 사용할 때 더 많은 사실을 확인할 수 있다.
   2. 승인 이상의 증거: 단순한 승인 또는 거부보다 드롭다운이 올바르게 사라지는 이미지, 회원가입 흐름이 처음부터 끝까지 작동하는 영상이 배포 확신을 높인다.

2.2. Greptile의 T-Rex 샌드박스 방식

1. 변경 맥락과 실행 검증의 결합

   1. T-Rex by Greptile: Greptile의 T-Rex는 변경 사항을 남기 전에 샌드박스에서 실제 코드를 실행하고 테스트하는 리뷰 시스템이다.
   2. 코드베이스 전체 맥락: Greptile은 전체 코드베이스를 알고, 밀접하게 모니터링하며, 광범위하게 인덱싱해 변경 사항의 맥락을 파악한다.
   3. 검토의 확장: 기존의 맥락 이해 능력에 실행 검증을 더해 코드에 대한 추측이 아니라 동작 사실에 기반한 리뷰를 만든다.

2. 오케스트레이터와 하위 에이전트

   1. 가설별 샌드박스: 리뷰 오케스트레이터는 문제가 있을 수 있다는 여러 가설에 따라 샌드박스를 만들고 하위 에이전트를 실행할 수 있다.
   2. 필요한 만큼의 실행: 어떤 리뷰는 샌드박스가 전혀 필요 없고, 어떤 리뷰는 열 개가 필요할 수 있으며, 오케스트레이터가 변경 검증에 필요한 수를 결정한다.
   3. 결과물: 검증 결과는 엄지손가락을 올리거나 내리는 표시만이 아니라, 실제로 테스트한 장면의 이미지와 영상으로 돌아온다.

3. 모델의 천장보다 바닥이 중요한 이유

모델 응답을 분포로 보면 최신 프런티어 모델의 가장 실용적인 개선은 최고점 상승보다 최저점 상승과 최고·최저 간격의 축소다.

3.1. Astra와 Fable의 응답 분포

1. Astra의 양면성

   1. 높은 천장: Astra는 역사상 어떤 모델도 하지 못한 일을 해낼 정도로 뛰어난 결과를 낸다.
   2. 낮은 바닥: 동시에 2025년에 Gemini를 진지하게 사용하던 때 이후로 보지 못한 수준의 이상하고 성가신 실수를 한다. Astra에서 벗어나 Soul로 돌아가는 일이 단순히 나쁘지 않고 실제로 편하게 느껴질 수 있다는 점은 인정된다.
   3. 무작위 급락: Astra의 문제는 가끔 발생하는 멍청한 판단과 가정이 너무 무작위적이고 급격해 안전하게 맡길 수 있는 작업 범위를 가늠하기 어렵다는 데 있다.

2. 프런티어 모델의 장점

   1. 바닥 상승: Anthropic과 OpenAI 계열 프런티어 모델은 오픈 웨이트 모델이나 일부 다른 연구소 모델보다 최악의 응답이 덜 나오는 높은 바닥을 제공한다.
   2. 간격 축소: 최저점과 최고점 사이의 간격이 줄어들어 긴 작업에서 중간에 맥락을 잃거나 엉뚱한 결정을 내릴 확률이 낮아진다.
   3. 실무 우선순위: 새로운 수학 문제를 풀더라도 사용자가 말한 revert의 뜻을 이해하지 못하면 가치가 낮다. Blender에서 3D 환경을 훌륭하게 만들어도 div 안의 아이콘을 중앙 정렬하지 못하면 기본적인 개발 요구를 충족하지 못한다.

3.2. 최고점과 최저점에 대한 두 가지 오판

1. 천장만 보는 오판

   1. Opus 5 사례: 한때 Opus 5의 최고점에 매료되어 실제보다 훨씬 좋은 모델이라고 판단했지만, 당시 알던 것보다 훨씬 자주 잘못 행동했다.
   2. 성능 과대평가: 화려한 성공 사례만 보면 실제 운영에서 반복되는 낮은 품질을 놓치고 모델의 신뢰도를 잘못 추정하게 된다.

2. 바닥만 보고 버리는 오판

   1. Gemini의 반복 읽기: Gemini는 같은 파일을 26번 읽고도 변경하지 않는 낮은 바닥을 일관되게 보여 주었다.
   2. 특정 영역의 천장: 그럼에도 스케이트보드 기술의 이름을 맞히는 일처럼 독특한 영역에서는 아주 뛰어나다.
   3. 균형 잡힌 평가: 낮은 바닥만 보고 모델 전체를 폐기하면 실제 강점을 놓치므로 최고점과 최저점을 함께 봐야 한다.

3.3. Astra를 Gemini 3.8 Hey, Flash로 다시 표시한 도표

1. 모델 이름을 지운 비교
   1. 도표의 재명명: Astra의 이름을 도표에서 지우고 Gemini 3.8 Hey, Flash로 바꾸면 응답 분포에 대한 실제 인상이 더 정확해진다는 주장이 제시된다.
   2. Flash 수준의 급락: Astra가 Flash만큼 낮은 성능을 낼 수 있다는 사실은 심각한 결함이며, 관련 엔지니어가 고쳐야 할 문제다.
   3. 벤치마크 스파이크: Flash의 짧은 성능 급등은 몇몇 벤치마크를 좋아 보이게 했지만 전체 품질을 대표하지 못했다. 그런 스파이크 때문에 평균적인 바닥을 잘못 평가하면 안 된다.

3.4. Fable과 Opus의 현실적인 비교

1. 낮은 기준을 넘는 좁은 작업

   1. 티켓에서 코드까지: “이 티켓을 읽고 파일을 찾아 이 변경을 한 뒤 완료됐다고 알려 달라”는 프롬프트는 두 모델 모두 품질 기준을 크게 넘을 가능성이 높다.
   2. 차이가 작아 보이는 이유: 짧은 실행 창에서 두 모델이 모두 기준을 통과하면 Fable과 Opus의 차이는 거의 느껴지지 않는다.

2. 작업 폭과 실패 누적

   1. 실패가 만드는 기대치 하락: 모델에게 일을 시켰는데 실패하면 사용자는 실제로 화가 나고, 더 어려운 요청이 실패하면 모델이 그 일을 할 수 없다고 믿게 된다.
   2. 폭의 정의: 프롬프트의 폭은 지적 난이도나 문제의 깊이가 아니라, 시작점에서 종료점까지 모델이 책임지는 일의 양과 거리다.
   3. 넓은 프롬프트의 요구: 작업 단계와 시간이 늘어날수록 모델이 한 번이라도 잘못된 선택을 할 가능성이 커지므로 높은 바닥이 필요하다.

4. 에이전트에게 더 넓은 작업을 맡기는 개발 방식

에이전트를 짧은 명령의 실행기로만 쓰지 않고 문제 발견부터 작동 증명까지 맡겨야 최신 모델의 차이가 드러난다.

4.1. 새 프런티어 모델을 시험하는 방법

1. 기존 실패 작업을 재시험

   1. 초기화: 새 모델이 나오면 과거에 성공했던 프롬프트만 반복하지 말고, 다른 모델에서 실패했던 작업 세트를 먼저 돌려야 한다.
   2. 새 능력의 지도: 기대보다 잘한 작업이 발견되면 이전 모델로는 할 수 없었던 새로운 작업의 범위를 정할 수 있다.

2. 모델 선택에 대한 조건부 인정

   1. 좁은 범위의 정답: 명확히 포맷된 Jira 티켓에서 파일을 찾아 코드를 고치는 목표라면 Zeg의 판단이 맞을 수 있다.
   2. 수평 확장의 차이: 같은 난이도의 단순한 수정이라도 문제의 모호한 증상, 구현 위치 탐색, 테스트, 배포, 시각적 증명, 리뷰 대응을 연결하면 실행 시간과 실패 가능성이 달라진다.

4.2. 짧고 집중된 프롬프트와 실시간 감시

1. 일반적인 개발자 패턴

   1. 작은 프롬프트: 많은 개발자의 프롬프트는 작고 집중되어 있으며 모델이 의사결정하는 시간과 책임 범위가 짧다.
   2. 스레드 감시: 개발자는 에이전트가 일하는 동안 스레드를 계속 보고 작은 단계마다 방향을 조정한다.
   3. 모델 능력의 축소 사용: 이런 방식은 모델이 실제로 얼마나 오래 맥락을 유지하는지, 어떤 작업까지 혼자 해낼 수 있는지 확인할 기회를 줄인다.

2. 감시를 줄이고 실패에서 배우기

   1. 신뢰 한계 시험: 에이전트를 계속 지켜보지 말고 더 먼 한계까지 맡겨야 모델의 실제 자율 실행 범위를 알 수 있다.
   2. 좋은 감시 기준: 첫 결과가 끔찍하게 틀렸을 때만 살펴보는 태도가 유용하다. 감시는 실패를 막기 위한 것만이 아니라 실패 원인을 배우기 위한 것이기 때문이다.
   3. 원인 질문: “이렇게 하기를 기대했는데 왜 다른 일을 했나?”라고 물으면 모델이 자신의 내면적 원인을 완벽히 알 수는 없어도, 어떤 신호·도구·파일이 잘못된 방향으로 이끌었는지는 대체로 지적한다.

4.3. 야간 자율 실행과 코드베이스 개선

1. Jamon의 접근

   1. 목표: 밤새 에이전트를 돌리는 목적은 코드를 최대한 많이 쓰게 하는 것이 아니라 실패 사례를 많이 만나는 것이다.
   2. 장애물 증폭: 코드베이스에 평균 두 시간마다 에이전트가 부딪히는 장애물이 있다면 다섯 시간 실행 동안 평균 두세 번 만난다.
   3. 학습 순환: 긴 실행으로 실패를 빨리 드러내고, 나쁜 실행에서 배우고, 그 결과를 바탕으로 시스템과 아키텍처를 고치면 이후 한두 시간짜리 작업의 장애물이 줄어든다.

2. 프롬프트보다 코드베이스를 고치는 원칙

   1. 수정 비율: 프롬프트도 조금 조정해야 하지만 코드베이스는 훨씬 크게 조정해야 한다.
   2. 새 개발자 테스트: 에이전트가 특정 코드베이스에서 계속 실수한다면 그 코드를 처음 접한 숙련 개발자도 같은 문제를 겪을 가능성이 높다.
   3. 책임의 위치: 경험 많은 개발자가 하루가 끝날 때까지 기여하지 못한다면 에이전트 탓이 아니라 코드베이스와 시스템 설계의 문제일 수 있다.

4.4. 파일명을 지정하지 않는 수평적 프롬프트

1. T3 Code에서 얻은 경험

   1. 운영 규모: T3 Code는 12,000개의 PR과 300,000명의 사용자를 다루므로 작은 실수도 즉시 비판받는다.
   2. 일반화: 그린필드 T3 Code에서 파일명을 직접 지정하지 않고 문제를 설명하는 방식이 효과를 냈고, 다른 대규모 코드베이스 유지보수에서도 좋은 결과를 냈다.
   3. 설문 반응: 파일명을 자주 쓰는 개발자와 거의 쓰지 않는 개발자가 나뉘었으며, 후자의 비중이 예상보다 높아 안도감을 줬다.

2. 개발자 유형에 따른 모델 체감

   1. Atlassian 개발자: 파일명과 구현 위치를 자주 지정하는 사람들은 좁은 작업을 Opus에 맡길 때 더 편하고, Ael·Aster 같은 최신 모델이 왜 좋은지 의아해할 가능성이 높다.
   2. 현실적인 개발자: 파일명을 거의 지정하지 않고 문제를 설명하는 사람들은 최신 모델이 덜 어리석고 오래 실행된다는 차이를 더 잘 체감할 가능성이 높다.
   3. 모델의 실제 장점: 최신 모델은 극한의 능력으로 새로운 과학을 만들어서가 아니라, 덜 자주 멍청해지고 더 적은 안내로 올바르게 행동하기 때문에 유용하다.

4.5. 한 번의 프롬프트가 맡아야 할 범위

1. 문제에서 파일까지

   1. 기존 방식: 사람이 코드베이스를 조사하고 수정할 파일을 찾아 에이전트에 알려 준다.
   2. 수평적 방식: 사람은 문제의 증상과 원하는 결과만 말하고, 에이전트가 파일을 찾고 변경 범위를 결정하게 한다.

2. 수정에서 사용자 검증까지

   1. 빌드 전달: 변경이 끝나면 개발자에게 직접 빌드하라고 알리는 대신 에이전트가 휴대폰으로 빌드를 보낸다.
   2. 시뮬레이터 선검증: 에이전트가 먼저 시뮬레이터에서 실행하고 검증한 다음 휴대폰으로 보내게 한다.
   3. 영상 증명: 여전히 걱정된다면 PR에 작동 영상을 첨부해 사람은 이미 검증된 결과를 마지막으로 확인하게 한다.

3. Maria의 provider history PR

   1. 문제 영역: 여러 하네스에서 rewind 기능을 사용할 때 발생하던 provider history 문제를 수정하는 PR이 있었다.
   2. 모델의 기여: Maria는 PR의 코드를 직접 쓰지 않았지만, 모델이 변경 내용을 시각화하고 검증했기 때문에 PR이 빠르게 병합됐다.
   3. 사람의 개입 시점: 사람이 PR을 열어 변경 내용을 보는 시점에는 모델이 이미 많은 검증을 끝냈으므로 결과가 작동할 가능성이 높아졌다.

5. 자율 실행 시간과 사람 개입 시 성공 확률

모델 평가의 핵심은 작업이 얼마나 화려한지가 아니라, 고장 없이 실행되는 시간과 사람이 돌아왔을 때 이미 쓸 수 있는 결과를 갖고 있을 확률이다.

5.1. 두 가지 운영 지표

1. 사람 입력 없이 실행되는 시간

   1. 첫 번째 질문: 모델이 사람의 입력 없이 얼마나 오래 실행될 수 있는지 측정해야 한다.
   2. 평가 대상: 3D 세계를 다시 만들거나 Electron을 Rust로 포팅하는 능력보다 실행 중 어리석은 실수를 내지 않는지가 중요하다.

2. 사람이 개입할 때 작동할 확률

   1. 두 번째 질문: 사람이 개입하는 시점에 결과가 이미 작동하고 있을 가능성을 측정해야 한다.
   2. 실행 사례: 30분 동안 거의 항상 버그를 만나는 에이전트는 그 상태를 고쳐야 한다. 반대로 여섯 시간 동안 개입 없이 실행하고 PR 제출 10분 뒤 병합된 작업은 이 목표에 부합한다.
   3. 공통 목표: 일정한 시간 창에서 모델이 실패할 확률을 줄여 두 지표를 함께 높여야 한다.

5.2. 작업을 더 어렵게 하지 않고 더 넓게 만들기

1. 짧은 작업 창

   1. 낮은 차이: Fable과 Opus가 모두 품질 기준을 크게 넘는 짧은 작업에서는 둘의 차이가 작다.
   2. 단순함의 가치: 단순한 일을 에이전트에 맡기는 것은 좋은 사용법이다. 문제는 단순함이 아니라 단순한 일을 짧게 쪼개 사람이 전체 연결을 담당하는 방식이다.

2. 긴 작업 창

   1. 누적 위험: 문제를 지적으로 더 어렵게 만들지 않아도 작업을 더 넓게 만들면 단계와 시간이 늘고, Opus가 한 번이라도 잘못된 선택을 할 가능성이 높아진다.
   2. Fable의 가치: Fable이 더 똑똑해서가 아니라 덜 멍청하기 때문에 유용하다. “똑똑함”과 “덜 멍청함”은 서로 다른 축이며 거의 반대쪽 끝에 가깝다.
   3. 세대별 변화: 모델 세대가 올라갈수록 모델이 50% 확률로 어리석은 행동을 할 때까지 걸리는 시간이 줄어든다.

5.3. Maria의 추적 분석과 스킬 개선

1. 실행 기록에서 학습
   1. 3~4일의 분석: Maria는 모델이 무엇을 잘하고 무엇을 못하는지 트레이스에서 확인하고 스킬 등을 다듬는 데 3~4일을 썼다.
   2. 결과: 조정이 끝난 뒤에는 단일 프롬프트를 보내고 PR을 즉시 랜딩할 수 있게 됐다.
   3. 공로의 정정: Maria는 자신이 만든 개선을 발표자의 공로가 아니라 Potato의 공로로 돌렸고, 발표자는 이를 인정했다.

6. 실행 시간 증가와 실패율의 지수적 효과

단위 시간의 작은 실패율 차이는 작업 창이 길어질수록 누적되어 자율 실행 가능 시간을 크게 바꾼다.

6.1. 실제 에이전트 실행 로그의 변화

1. 세대 변화에 따른 실행 시간

   1. 과거의 한계: 몇 달 전에는 에이전트를 15분 이상 믿고 돌리기 어려웠다.
   2. GBD55와 56: GBD55는 에이전트 작업에서 대체로 좋았지만 자주 멈춰 전체 실행 시간이 짧았다. 55에서 56으로 넘어가며 훨씬 오래 맡길 수 있게 됐다.
   3. 극단값의 변화: 평균 실행 시간은 약 두 배가 됐고, 가장 긴 상위 1% 실행은 최소 열 배 길어졌다. 과거에는 한 시간도 버티기 어려웠지만 이틀 동안 문제없이 실행된 작업도 생겼다.

2. 로그 수치

   1. 중앙값: 3월 이후 남은 로그에서 중앙 프롬프트 실행 시간은 53초에서 2분 20초로 늘어났다.
   2. P95: 95번째 백분위 실행 시간은 7분보다 조금 짧은 수준에서 16분 20초를 넘는 수준으로 늘어났다.
   3. 상위 5%의 월별 변화: 3월에는 가장 긴 5% 요청이 9분이었고, 이후 11분과 12분으로 늘었다. Fable과 Soul이 등장한 5월에서 6월 사이에는 12분에서 22분으로 거의 두 배가 됐다.
   4. 데이터 한계: 컴퓨터를 옮기면서 과거 에이전트 기록을 백업하지 않아 3월 이후 로그만 남아 있었으므로, 더 긴 기간의 비교는 하지 못했다.

6.2. 5% 실패율을 긴 작업에 누적하기

1. 기본 실패율

   1. 10분: 10분 창에서 실패율이 5%라면 성공률은 95%다.
   2. 30분: 독립적인 10분 창 세 개가 모두 성공할 확률은 0.95³이며 약 86%다. 실패율은 약 14~15%로 오른다.
   3. 1시간: 여섯 개 창의 성공률은 0.95⁶으로 약 73%가 되고 실패율은 약 27%가 된다.
   4. 2시간: 열두 개 창의 성공률은 약 54%가 되어 실패율이 약 46%가 된다.
   5. 4시간: 스물네 개 창의 성공률은 약 29%로 떨어져 실패율이 약 71%가 된다.

2. 실패율을 2% 낮춘 경우

   1. 10분: 실패율을 5%에서 3%로 낮추면 10분 성공률은 97%가 된다.
   2. 4시간: 0.97²⁴의 성공률은 약 48%로 올라간다. 같은 4시간에서 기존 약 29%보다 크게 높아진다.
   3. 차이의 확대: 10분 단위의 2% 개선이 4시간 규모에서는 실패율 약 71%와 약 52%의 차이로 증폭된다.
   4. 일반 원리: 바닥을 10~15% 개선하는 것이 단위 창에서 선형적으로 보이더라도, 긴 실행 거리에서는 중단 없이 달릴 수 있는 시간이 지수적으로 늘어난다.

7. 장시간 에이전트 작업을 가능하게 만든 모델의 변화

과거에는 긴 실행을 위해 사람이 상세한 스펙과 반복 루프를 준비해야 했지만, 최근 모델은 준비와 감시를 줄여도 더 긴 작업을 유지한다.

7.1. 스펙과 Ralph 루프만으로 부족했던 시기

1. 48시간 실행의 조건

   1. AD guy의 사례: 2월에 48시간 연속 실행을 시도한 사람은 시작 전에 여러 시간 동안 상세한 스펙을 작성해야 했다.
   2. 즉흥성의 한계: 짧은 준비와 즉흥적인 지시만으로 모델이 48시간 안정적으로 일하기는 어려웠다.

2. 일관성 부족

   1. 기억 관리: 과거 모델은 압축(compaction)을 제대로 수행하지 못했고, 이미 한 일과 시도한 일을 추적하거나 다음 작업을 위한 알림을 남기는 능력이 부족했다.
   2. Ralph 루프: Ralph 루프는 멋진 접근이었지만 높은 실패율을 충분히 낮추지 못했다.
   3. 8시간의 결과: 상세한 스펙을 아무리 많이 만들고 8시간 실행해도 결과가 T3 Code처럼 안정적이지 않았다. Cursor 2와 Cursor 3은 자세히 들여다보는 순간 모든 것이 무너지는 결과를 냈다.

7.2. 최근 모델과 Cursor의 안정화

1. 자율 실행의 전환

   1. 루프 밖으로 나가려는 모델: 최신 모델은 사람의 루프 안에 계속 머무르기보다 4~8시간 동안 스스로 실행되는 방향으로 발전했다.
   2. Cursor의 회복: 4~8시간 실행이 좋은 결과로 끝날 가능성이 높아지면서 Cursor가 다시 안정적으로 기능하기 시작했다.
   3. 추가 기여: Cursor를 만든 Lawrence의 기여도 안정화에 일정 부분 영향을 줬다.

2. 핵심 차이

   1. 안내 감소: Opus가 충분한 짧은 작업에서도 Fable·Astra의 장점은 새로운 과학을 발명하는 데 있지 않다.
   2. 덜 어리석은 장기 실행: 최신 모델은 덜 자주 멍청해지고, 더 오래 실행되며, 올바른 결과에 필요한 안내가 줄어든다.

8. 숙련된 리더가 최신 모델의 가치를 놓치는 이유

코딩 자체보다 코딩 전의 준비와 코딩 후의 검증이 중요해진 리더일수록, 그 양쪽을 에이전트에게 넘기는 일을 더 불편해한다.

8.1. 개발자에서 리더로 성장하며 굳어진 습관

1. 기존의 성공 공식

   1. 준비의 증가: 좋은 기여자에서 좋은 리더로 성장하려면 코드를 쓰기 전에 더 많이 준비해야 했다.
   2. 검증의 증가: 코드를 쓴 뒤에도 더 많은 검토와 검증을 해야 안정적인 결과를 얻을 수 있었다.
   3. 위임의 불편함: 오랫동안 성공을 만든 준비와 검증을 에이전트에게 넘기는 일은 코딩 자체를 넘기는 것보다 더 불편하다.

2. 낡은 평가 대상

   1. Zeg와 David K의 방식: 두 사람은 여전히 2월의 방식처럼 프롬프트를 쓰고, 시작 전과 종료 후에 직접 투입하는 시간을 충분히 가치 있게 보지 않는다는 비판을 받는다.
   2. 이미 자동화된 영역: 코딩을 일상에서 크게 줄인 리더들은 자신들이 6개월 전부터 하지 않던 코딩 작업에만 모델을 시험한다.
   3. 보이지 않는 경계: 모델이 그 코딩 작업을 이미 충분히 수행하더라도, 코딩 전후의 더 넓은 영역까지 맡기면 최신 모델의 경계를 훨씬 분명하게 볼 수 있다.

8.2. 구독료와 총비용

1. 서구권 전업 개발자를 위한 비용 계산

   1. 구독료: 전업 개발자는 Claude 구독 200달러와 Codex 구독 200달러를 감당할 수 있고, 회사가 비용을 지불하는 경우도 많다.
   2. 토큰 여유: 해당 구독으로 Claude 토큰 약 8,000달러분과 OpenAI 토큰 약 12,000달러분을 얻을 수 있어, 비교적 적은 비용으로 많은 실험 여지를 확보한다.
   3. 적용 범위: 서구권 밖의 사용자, 전업 개발자가 아닌 사람, 젊은 개발자, 학생에게 400달러는 큰 비용이므로 같은 판단을 그대로 적용하지 않는다.

2. 싼 모델이 더 비싸지는 경우

   1. 시간의 가격: 저렴한 모델이 항상 저렴한 것은 아니다. 실행 전후에 사람이 더 오래 준비하고 확인해야 하면 총비용이 높아진다.
   2. David K의 사례: XState를 만든 David K가 대부분의 작업에 Astra·Soul·Fable이 필요 없다고 말하는 것은 어느 정도 맞지만, 모델 가격보다 개발자의 시간이 더 가치 있을 수 있다.
   3. 더 넓은 위임: 저렴한 모델로 다운그레이드하면 작업 전과 중단 시점에 사람이 더 많이 투입될 수 있다. 모델이 작업의 양쪽 끝을 더 많이 처리하고 사람을 나중에 끌어들일수록 전체 결과가 좋아진다.

주요 발언 모음

“Fable이 더 똑똑해서 좋아하는 게 아니다. 덜 멍청해서 좋아한다.”

“새 모델의 가치는 가장 어려운 문제를 풀어내는 데 있지 않고, 같은 일을 더 오래 하면서 실수를 덜 하는 데 있다.”

“프롬프트를 더 어렵게 만드는 것이 아니라 더 넓게 만들어야 한다.”

“모델이 30분마다 버그를 만난다면 그 버그를 고쳐서 모델이 그렇게 행동하지 않게 만들어야 한다.”

“토큰은 비싸지만 엔지니어의 시간도 비싸다.”

“높은 바닥을 2%만 올려도 네 시간 규모에서는 실행 가능성이 크게 달라진다.”

“사람이 개입할 때 이미 작동하는 결과일 가능성과 사람 없이 실행되는 시간을 함께 높여야 한다.”

핵심 데이터 & 수치

• 영상 길이: 27분 9초.
• T3 Code 규모: 12,000개 PR과 300,000명 사용자.
• 과거와 현재의 실행 시간: 평균 실행 시간 약 2배 증가, 상위 1% 최장 실행은 최소 10배 증가.
• 중앙 실행 시간: 53초에서 2분 20초로 증가.
• P95 실행 시간: 7분보다 조금 짧은 수준에서 16분 20초 초과로 증가.
• 월별 상위 5% 실행 시간: 3월 9분 → 이후 11분 → 12분 → 5~6월 22분.
• 단위 실패율 예시: 10분마다 5% 실패하면 4시간 성공률은 약 29%, 3% 실패로 낮추면 약 48%.
• 장기 실행 사례: 6시간 무개입 실행 후 PR 제출 10분 뒤 병합, 일부 작업은 2일 연속 문제없이 실행.
• 구독 비용 예시: Claude 200달러와 Codex 200달러, 각각 약 8,000달러·12,000달러분 토큰 여유.

결론 및 시사점

1. 모델 선택 기준: 최고 벤치마크 점수보다 긴 작업 창에서의 실패율과 최저 성능을 우선 평가해야 한다.
2. 프롬프트 설계: 특정 파일을 지정하는 짧은 지시보다 문제·구현 탐색·테스트·배포·리뷰 대응을 연결하는 넓은 지시를 설계해야 한다.
3. 자율성 확대: 에이전트를 계속 감시하지 말고, 실패했을 때 원인을 질문하며 신뢰 가능한 실행 범위를 넓혀야 한다.
4. 코드베이스 개선: 에이전트가 반복해서 막히는 지점을 프롬프트로 덮지 말고 코드베이스와 개발 시스템을 고쳐야 한다.
5. 검증 자동화: 코드만 읽는 리뷰보다 실제 실행, 시뮬레이터 테스트, 이미지·영상 증명을 포함하는 리뷰가 더 높은 확신을 준다.
6. 경제성 판단: 저렴한 모델의 구독료보다 사람이 투입하는 시작 전·종료 후 시간이 더 비쌀 수 있으므로 총비용을 계산해야 한다.
7. 최종 운영 지표: 모델이 사람 없이 얼마나 오래 실행되는지와 사람이 개입할 때 이미 작동할 확률을 함께 높여야 한다.

핵심 요약 (20줄)

1. 최신 AI 모델의 가장 큰 진전은 최고점 상승보다 긴 작업에서 어리석은 실수를 덜 하는 높은 바닥에 있다.
2. David Kramer는 Fable이나 Astra 대신 Opus와 Soul을 써도 작업 결과가 크게 달라지지 않는다고 주장했다.
3. 좁고 명확한 Jira 티켓은 낮은 모델도 처리하지만, 모호한 버그에서 검증된 PR까지 이어지는 작업은 다른 능력을 요구한다.
4. Astra는 Fable이 하지 못하는 일을 해내면서도 기본적인 판단에서 심각하게 흔들리는 양면성을 보인다.
5. Gemini는 같은 파일을 26번 읽고도 바꾸지 않지만 스케이트보드 기술 이름처럼 특정 영역에서는 높은 천장을 보인다.
6. 모델의 천장만 보면 화려한 데모를 과대평가하고 반복 작업을 망치는 낮은 바닥을 놓치게 된다.
7. 사용자는 모델이 한 번 실패하면 기대치를 낮추고 프롬프트의 폭과 맡기는 작업의 범위를 줄이게 된다.
8. 프롬프트의 폭은 난이도가 아니라 시작점부터 종료점까지 모델이 책임지는 작업의 양과 거리다.
9. 새 모델은 과거에 실패했던 프롬프트를 다시 시험해야 이전 모델보다 넓어진 능력의 경계를 발견할 수 있다.
10. T3 Code 에이전트는 휴대폰 스크린샷에서 시작해 수정·테스트·작동 영상·PR·리뷰 대응까지 맡을 수 있다.
11. 토큰 비용은 높아도 엔지니어의 시간이 더 비싸다면 더 강한 모델에 비용을 쓰는 편이 합리적이다.
12. 에이전트를 실시간으로 계속 감시하기보다 첫 결과가 크게 틀렸을 때 원인을 질문하는 편이 학습에 유리하다.
13. 야간 자율 실행은 코드를 많이 쓰기보다 코드베이스의 반복적인 실패 지점을 빠르게 드러내는 데 의미가 있다.
14. 에이전트가 자주 막히는 문제는 프롬프트보다 코드베이스와 개발 시스템을 고쳐야 해결된다.
15. 파일명을 직접 지정하지 않고 문제를 설명하면 에이전트가 코드베이스를 조사하고 수정 범위를 스스로 찾게 된다.
16. T3 Code의 12,000개 PR과 300,000명 사용자 규모는 자동 검증과 시각적 증명의 필요성을 키운다.
17. Maria의 provider history 수정 PR은 모델이 변경 사항을 시각화하고 검증한 뒤 빠르게 병합된 사례다.
18. 실행 실패율이 10분마다 5%면 4시간 성공률이 약 29%지만 3%로 낮추면 약 48%로 올라간다.
19. 최신 모델은 평균 실행 시간을 두 배로 늘렸고 상위 1% 최장 실행을 최소 열 배로 늘렸다.
20. 개발자는 모델이 사람 없이 오래 실행되는 시간과 사람이 개입할 때 이미 작동할 확률을 함께 높여야 한다.