Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster — Matt Dailey, Ref.

한 줄 핵심

AI로 개인 생산성은 급상승했지만 팀이 함께 의사결정과 상태를 공유하는 구조를 바꾸지 않으면, 더 많은 코드와 혼란만 남는다는 점을 지적하며 문서 중심의 결정 계층으로 전환해야 한다는 주장이다.

시간별 요약

1. 0:12
   개별 엔지니어는 AI로 빨라졌지만 팀 전체는 그렇지 않은 문제가 핵심이며, 이 격차를 줄이기 위한 실전용 청사진을 제시한다.
2. 1:00
   PR 과다, 여러 방향으로의 분산, agent bankruptcy, 그리고 에이전트가 중요한 결정을 대신하는 문제가 velocity sickness의 대표 증상이다. 결국 속도는 올랐지만 영향은 줄어드는 상태가 된다.
3. 6:00
   과거의 개발은 인간이 구현을 중심으로 일하는 구조였지만, 지금은 사람이 계획하고 agent가 구현하며 인간이 다시 다듬는 구조로 바뀌었다. 따라서 기존 IDE 중심 도구만으로는 현재의 일하는 방식을 충분히 지원하지 못한다.
4. 10:01
   핵심 해결책은 chat이 아니라 docs를 중심에 두는 것이다. 문서는 일회성 대화가 아니라 중요한 결정을 공유하고 오래 유지하는 상태가 되며, agent는 action을 담당하고 문서는 state를 담당하는 분리가 필요하다.
5. 15:00
   이 구조로 바꾸면 code velocity 대신 idea velocity를 높일 수 있고, PR은 줄어들며, 방향 정렬이 쉬워지고, 인간이 결정을 소유하게 된다. 더불어 병렬 agent 활용과 협업이 쉬워져 팀 단위 생산성이 실제 영향으로 연결된다.
6. 18:01
   즉시 적용할 일은 세 가지다. 작업을 planning과 polish로 나눠 인식하고, 계획을 소프트웨어 시스템을 비추는 portal로 다루며, 계획을 agent뿐 아니라 팀원과도 공유해 조기 피드백을 받는 것이다.

실무 인사이트

• 팀의 AI 도입 성과는 구현 속도보다 결정의 질과 공유 방식에서 갈리므로, 설계 문서를 먼저 만드는 습관이 가장 큰 레버리지다.
• 에이전트의 상태를 대화에 묶어두지 말고 문서에 분리해 두면, 재시작 비용과 중복 작업을 크게 줄일 수 있다.
• 개인별 실험을 넘어 팀 공용 decision log를 만들면, 병렬 실행과 리뷰 효율이 함께 올라간다.