Everything we knew about software has changed — Theo Browne, @t3dotgg ​

한 줄 핵심

AI 모델이 도구 호출에서 장기 실행·오케스트레이션·자율 재구성 단계로 진화하면서, 소프트웨어는 기존 관성보다 더 크게·더 넓게 다시 설계해야 한다는 주장이다.

시간별 요약

1. 0:01
   Sonnet 3.5는 안정적인 tool call 시대를 열었고, Opus 4.5는 몇 시간짜리 작업을 끝까지 수행하는 장기 실행 단계로 넘어가게 했다. Mythos는 단순한 코딩 향상을 넘어 모델이 스스로 작업을 분해하고 다른 모델을 불러 오케스트레이션하는 단계로 보인다.
2. 3:00
   이제 필요한 것은 모델의 한계를 탓하는 대신 더 큰 문제를 맡기고, 개발자의 오래된 습관과 기준을 내려놓는 일이다. 모델이 더 빨리 발전하므로 인간이 기존 방식에 머무르면 이득을 놓치게 된다.
3. 4:00
   iOS 7이 장식적 모방에서 유용한 인터페이스로 이동했듯이, 소프트웨어 개발도 터미널과 익숙한 도구를 최고의 형태로 착각하는 skeuomorphic 단계에서 벗어나야 한다. Git, 언어 정체성, 환경 파일, 삭제를 두려워하는 습관 같은 관성은 지금의 문제를 푸는 데 오히려 방해가 된다.
4. 9:01
   예전에는 side project, startup, too big로 나뉘던 개발 과제가 모델 덕분에 한 단계씩 아래로 내려왔다. 예전엔 대규모 시스템처럼 보이던 일도 지금은 markdown file과 cron, Codex나 Claude만으로 자동화될 수 있다.
5. 13:00
   이제 경쟁의 기준은 더 넓은 범위를 덮는 것이 아니라 특정 영역에서 더 깊고 빠르게 가치를 제공하는 방향으로 바뀌고 있다. 동시에 충분히 넓은 범위를 하루나 이틀 만에 구현해 사용자가 직접 확장하게 만드는 제품 구조도 가능해졌고, Slack처럼 플랫폼이 되어 에이전트와 확장 기능이 자라나는 형태가 유리해진다.
6. 15:01
   결국 AI 시대의 좋은 제품은 처음부터 사용자를 모두 만족시키려 하기보다, 사용자가 필요한 부분을 스스로 채울 수 있는 틀을 제공한다. 아이디어가 우스꽝스럽게 느껴질 정도로 커야만 지금의 변화에 맞는 문제를 풀 수 있다.

실무 인사이트

• 기존 개발 관성보다 모델의 능력을 기준으로 작업 크기를 재정의하면, 사람이 직접 하던 업무 상당수를 markdown file 수준의 자동화로 바꿀 수 있다.
• 제품 전략은 전 범위 커버보다 핵심 영역의 깊이와 확장 가능한 구조에 집중해야 하며, 부족한 기능은 사용자와 에이전트가 메우게 설계하는 편이 유리하다.
• 팀 운영에서는 삭제·재작성·재분해를 더 쉽게 허용해야 하며, 언어·도구 정체성보다 결과 중심으로 의사결정하는 문화가 필요하다.