[한영자막] 이제 무엇을 만들어야 할까요? — Theo Browne, @t3dotgg

한 줄 핵심

AI 모델이 단순 코딩 보조를 넘어 오케스트레이션과 제품 구축까지 맡는 시대가 왔으니, 개발자는 익숙한 도구와 범주에 묶이지 말고 더 넓은 범위의 제품을 설계해야 한다.

시간별 요약

1. 0:00
   Sonnet 3.5는 도구 호출을 안정적으로 수행하는 시대를 열었고, Opus 4.5는 더 오래 달리는 작업을 자율적으로 끝내는 전환점을 만들었다. Mythos는 작업 분해·모델 분산·사후 검증까지 스스로 수행하는 오케스트레이션 단계로 보이며, 이제는 모델을 더 멀리 밀어야 한다는 관점이 핵심이다.
2. 3:01
   오래 코딩해 온 사람일수록 terminal, Git, 언어 정체성 같은 익숙한 관성에 갇히기 쉽지만, 지금은 그 기준이 오히려 발목을 잡는다. 환경 파일 공유, 코드 삭제, PR 합의 같은 문제는 사람이 귀하게 느껴서 생긴 복잡도이며, AI가 일상화되면 이런 심리적·절차적 부담을 과감히 줄여야 한다.
3. 9:01
   과거에는 side project, startup, too big으로 나뉘던 아이디어의 층위가 모델 성능 향상으로 한 단계씩 내려왔다. 예전에는 큰 제품처럼 보이던 것들이 이제는 markdown 파일과 cron, Codex 또는 Claude만으로도 돌아가는 자동화로 구현될 수 있다.
4. 12:02
   지금은 '더 크게'보다 '더 넓게' 생각해야 하며, 제품의 breadth와 depth를 함께 설계하는 것이 중요하다. AWS처럼 모든 기능을 다 가질 필요는 없지만, 특정 영역에서는 충분히 깊게 들어가면서도 주변 범위를 넓혀 사용자 시작점은 제공할 수 있다.
5. 14:01
   앞으로는 database platform, Slack, Salesforce, AWS 같은 거대한 범주도 작은 팀이 AI를 활용해 점진적으로 위협할 수 있는 영역이 된다. 아이디어가 약간이라도 우습고 과감하게 느껴질 때가 오히려 새 기준에 가까우며, 그만큼 스스로 생각하는 한계를 계속 넓혀야 한다.

실무 인사이트

• 기획 단계에서 '이건 너무 크다'고 버리기 전에, AI가 어느 부분을 자동화·분해·검증할 수 있는지 먼저 확인하면 제품 범주 자체가 달라진다.
• 팀의 작업 단위를 사람 중심이 아니라 모델 중심으로 재설계하면, markdown 파일·cron·간단한 워크플로만으로도 운영 자동화를 빠르게 만들 수 있다.
• 경쟁 전략은 기능 수를 늘리는 것이 아니라, 특정 사용자 흐름에서 더 깊고 넓은 범위를 선점해 시작 장벽을 낮추는 방향이 효과적이다.