AI 속도 멀미: 팀이 10배 빨라져도 성과가 안 나는 이유와 의사결정 계층 해법

핵심 메시지

• AI로 산출물이 갑자기 늘어나면 '속도 멀미', 즉 성과 없는 산출량 증가가 나타난다.
• 가장 위험한 증상은 중요한 판단을 에이전트에 넘겨 코드와 제품의 주인 자리를 잃는 것이다.
• 해법은 구현 계층과 의사결정 계층을 분리하고, 의사결정 계층의 기본 단위를 채팅이 아닌 문서로 두는 것이다.
• 문서에 상태를 두면 에이전트는 사실상 무상태가 되어 여러 개를 같은 맥락에서 병렬로 돌릴 수 있다.
• 코드 속도가 아니라 아이디어 속도로 지표를 옮겨야 탐색의 폭이 넓어진다.

쉽게 이해하기

AI 엔지니어 콘퍼런스 발표에서 연사는 개별 엔지니어는 빨라졌는데 팀 전체는 그만큼 빨라지지 않는 현상을 문제로 꺼냈습니다. 그가 관찰한 증상은 네 가지입니다. 병합할 수 없을 만큼 쌓이는 풀 리퀘스트, 서로 다른 방향으로 동시에 달리는 작업, 아침에 돌아와 어제 열어둔 열두 개의 터미널을 알아보지 못하고 전부 버리는 '에이전트 파산', 그리고 중요한 결정이 에이전트 손에서 내려지는 상황입니다.

그는 이 묶음을 '속도 멀미'라고 부릅니다. AI 덕분에 산출량이 갑자기 늘면서 생기는 스트레스인데, 결과는 임팩트 없는 산출량입니다. 예시로 든 것은 개발자가 아니라 뉴스레터 필자였습니다. 에이전트 파이프라인으로 자기 목소리를 증폭시키는 데 성공했고 사실상 매주 책 한 권 분량을 쓰고 있었지만, 독자가 매주 책 한 권을 읽고 있지는 않았습니다. 쓰인 페이지 대부분은 읽히지 않은 채 남았습니다.

연사는 작업의 모양이 바뀐 것이 원인이라고 봅니다. 과거 소프트웨어 작업은 앞단의 계획, 긴 구현, 마지막 다듬기로 이어졌고 IDE를 비롯한 도구는 그중 '구현'에 맞춰 설계됐습니다. 지금은 구현 상당 부분이 에이전트에게 넘어가고, 사람에게 남은 창의적·협업적 구간은 계획과 다듬기 둘입니다. 특히 계획 구간은 복잡한 시스템의 윤곽을 이해하고 무엇이 중요한지 골라내며 엔지니어의 취향을 드러내는 자리라, 구현용 도구로는 감당되지 않는다는 것입니다.

그래서 제안하는 것이 '의사결정 계층'이고, 그 계층의 도구는 채팅이 아니라 문서여야 한다고 말합니다. 채팅은 구현 시대의 유산이라 고립적이고 휘발성이 큽니다. 그 안에서 내려진 결정은 팀에 공유되지 않은 채 사라지고 코드만 남습니다. 반대로 문서는 오래 남고 공유되며, 상태는 문서가 갖고 행동은 에이전트가 맡는 구조가 됩니다. 이렇게 하면 여러 에이전트가 같은 맥락에서 출발할 수 있고, 잃어버린 이해는 문서를 다시 읽는 것으로 복구됩니다.

이 방식이 자리 잡을 때 나타나는 신호로 그는 '계획만 쓰고 구현하지 않는 사람들이 생기는 것'을 꼽았습니다. 아이디어를 펼쳐 본 뒤 만들 가치가 있는 것만 골라 다음 단계로 넘긴다는 뜻이기 때문입니다. 발표는 지금 당장 할 수 있는 세 가지로 끝납니다. 계획과 다듬기라는 두 가지 기어를 구분해 인식할 것, 계획 문서를 시스템을 들여다보는 창구로 쓸 것, 그리고 계획을 에이전트가 아니라 동료에게 먼저 보여줄 것.

주요 인사이트

• 속도 멀미의 판별 기준은 '얼마나 많이 만들었나'가 아니라 '만든 것이 누구에게 닿았나'다. 매주 책 한 권을 써도 읽히지 않으면 성과가 아니다.
• 리뷰 지점을 코드가 아니라 계획으로 앞당기면 PR 폭증 문제가 완화된다. 코드 리뷰에서 가장 어려운 '무엇이 중요한가'를 미리 합의해 두기 때문이다.
• 에이전트를 무상태로 다루면 '에이전트 파산' 자체가 성립하지 않는다. 작업 결과가 문서에 남아 있으므로 이해를 복구하는 비용이 파일 한 번 읽기로 줄어든다.
• 연사는 플랜 모드와 명세 기반 개발 사이의 중간 지대를 이야기한다. 플랜 모드는 여전히 고립된 채팅 메시지에 가깝고, 명세 중심 접근은 엔지니어링 현실에서 너무 떨어져 있다는 진단이다.
• 결정의 소유권이 사람에게 남아 있어야 코드와 제품의 소유권도 남는다. 개인 차원에서 넘겨준 판단은 조직 차원에서 제품 통제력 상실로 누적된다.

자주 묻는 질문

관련 AI 소식