도구를 얹은 팀과 방식을 바꾼 팀이 갈렸다 - 아마존 50개 팀이 찾은 다섯 가지 습관

도구를 얹은 팀과 방식을 바꾼 팀이 갈렸다

TL;DR

• Clare Liguori는 자기 체감부터 밝히는데, 인라인 완성과 챗, 바이브 코딩을 거치며 순전히 개인 경험에 근거해 10~20% 정도만 더 생산적이라고 느꼈다는 것이다. 그런데 사내 파일럿에서는 중간값 4.5배 생산성 향상, 때로는 10배 넘게 나왔다.
• 프런티어 개발자를 세 행동으로 정의한다. 직접 코드를 1~2%만 쓰고 나머지는 에이전트가 쓰며, 에이전트와 드물게 상호작용해 개입 없이 최대 몇 시간씩 돌리는 것을 목표로 하고, 여러 에이전트를 병렬로 돌려 유휴 시간을 최소화한다.
• 가장 결정적인 발견이 50개 팀 관찰에서 나오는데, 절반은 3배 미만에 머물고 나머지가 큰 향상을 얻었다. 차이는 도구가 아니었다. 90%가 같은 도구를 썼고 갈림길은 의도적으로 방식을 바꿨는가 아니면 기존 방식 위에 도구를 뿌렸는가였다.
• 다섯 습관 중 가장 반직관적인 것이 속도를 내려고 속도를 줄이는 것이다. 인터뷰한 거의 모든 팀이 새 방식을 의도적으로 채택하면서 생산성이 실제로 떨어졌다고 보고했고, 이유가 명확하다. 에이전트가 성공하려면 코드베이스에서 먼저 진짜 작업을 해야 한다.
• 새 병목으로 의사결정 속도가 지목되는데 산수가 분명하다. 새 제품 만드는 데 9~12개월 걸릴 때는 결정에 두 달, 출시 승인에 두 달이 크게 문제되지 않았다. 그런데 이제 코드는 1~2개월이면 쓰인다.

Source

_{Source: From AI-Assisted to AI-Native - Building a Frontier Development Team — Clare Liguori (AWS), AI Engineer, 20분 57초}

Knowledge

개인 체감과 사내 실측의 격차

발표는 발표자의 배경으로 시작한다. AWS 수석 주임 엔지니어이고 주로 사내 에이전트 코딩 조수를 다루며 에이전틱 AI를 3년 넘게 해 왔다는 것이다. 그래서 업계 진화 단계를 직접 겪었다고 밝힌다. 처음에는 다음 줄이나 다음 함수를 쓰도록 돕는 인라인 코드 완성이 있었고 다음이 코드에 대해 질문하는 챗이었고 작년 어느 시점에 모두가 바이브 코딩을 시작했다. 그리고 현재 단계가 규정된다. 이제 우리가 프런티어 개발이라고 부르는 것의 초기 채택자 국면을 보기 시작했다.

여기서 가장 정직한 진술이 나오는데 이 고백이 발표 전체의 문제 설정이 된다. 완전히 개인 경험에 근거해서 말하면, 앞서 온 이 모든 국면으로 아마 10~20% 정도만 더 생산적이라고 느꼈다.

그런데 사내 측정이 다른 숫자를 보여 준다. 회사 전반의 여러 팀과 파일럿을 돌려 왔는데 중간값 4.5배 생산성 향상을 봤고 때로는 10배가 넘었다. 판정이 붙는다. 여기서 뭔가 정말로 바뀌었다.

개인 체감과 조직 실측이 이렇게 벌어진다는 것이 이 발표의 출발점이다. 같은 도구를 쓰면서도 어떤 사람은 20%를, 어떤 팀은 450%를 얻는다면 차이는 도구가 아닌 곳에 있다는 뜻이 된다.

프런티어 개발자의 세 행동

정의가 능력이나 태도가 아니라 관찰 가능한 행동으로 제시된다. 첫째가 직접 손을 대지 않는 코딩이다. 수치가 구체적이다. 프런티어 개발자는 자기가 생산하는 코드의 아마 1~2%를 쓰고 나머지는 에이전트가 쓴다.

둘째가 상호작용 빈도다. 에이전트와 드물게 상호작용한다. 목표도 명시된다. 코딩 조수가 개입 없이 최대 몇 시간씩 돌아가도록 하는 것을 목표로 한다.

셋째가 유휴 시간이다. 유휴 시간을 최소화한다. 방법이 붙는다. 여러 에이전트를 병렬로 돌려 과제 백로그를 갈아 나가는 경향이 있다.

세 행동이 서로 맞물린다는 점이 중요하다. 코드를 직접 쓰지 않아야 여러 개를 동시에 돌릴 수 있고 개입 빈도가 낮아야 병렬이 실제로 가능해진다. 반대로 하나라도 어긋나면 나머지도 성립하지 않는다.

세 단계의 사례와 각각의 한계

발표의 구조에서 가장 인상적인 부분이 사례를 제시하면서 매번 그 한계를 스스로 짚는다는 점이다.

첫 사례가 베드록 맨틀 팀이다. 상황이 이랬다. 모델 호스팅 서비스가 새 추론 데이터 플레인을 만들어야 한다는 것을 알았고 30명이 18개월 걸릴 것으로 추정했다. 규모도 설명된다. 아주 큰 서비스이고 새것을 만들고 고객을 이전하고 모델을 이전하는 데 시간이 걸릴 예정이었다.

그런데 결과가 달랐다. 한 걸음 물러서서 여섯 명을 데려와 76일에 만들었다. 평가가 붙는다. 아마존 안에서 그런 종류의 것을 본 첫 번째였고 진정한 개척자 팀으로 최대 20배 향상이 가능하다는 것을 증명했다.

그런데 곧바로 한계가 지목된다. 문제가 하나 있었는데, 여섯 명으로 만들었지만 문자 그대로 회사 최고 엔지니어들이었고 두 명의 디스팅귀시드 엔지니어가 포함돼 있었다. 그래서 판정이 붙는다. 그냥 아무 여섯 명이 아니었다. 분산 시스템 전문가, LLM과 그 구조 전문가들이었다. 결과도 정직하게 인정된다. 이야기는 놀라웠고 산불처럼 퍼졌지만 많은 팀에게는 아주 도달 불가능했다.

두 번째 사례가 프라임 비디오 조직의 실험적 스프린트다. 설계가 이랬다. 10일 스프린트를 잡고 다시 여섯 명을 방에 넣고 도구로 마음껏 하게 했다. 결과도 수치로 제시된다. 프로젝트 인도 시간 추정을 90주에서 24주로 내렸다. 측정 방식도 밝혀진다. 커밋 이력을 봤고 이 스프린트 전에 하던 것과 이 10일에 생산한 커밋 수를 비교했다.

그런데 여기서도 한계가 짚인다. 방에 여섯 명이었지만 온콜 의무가 없었고 회의가 제한되고 방해가 거의 없었다. 그리고 대비가 붙는데 이 지적이 정확하다. 우리 모두 그것이 엔지니어의 일상에서 일상적이라는 것을 안다. 준비 작업도 밝혀진다. 팀의 시니어 엔지니어가 앞선 3주를 아주 상세하고 작고 잘 범위 잡힌 과제를 상세 요구사항과 함께 만드는 데 썼다. 판정이 정직하다. 다시 반드시 실제 삶은 아니었다. 구조화된 스프린트였다.

세 번째가 가장 중요한 사례인데 아마존 스토어즈의 더 구조화된 파일럿이다. 조건이 앞의 두 사례와 다르다. 완전히 정상 분포인 50개 팀을 관찰했는데 초기 경력자, 중간 경력자, 시니어 엔지니어가 섞여 있었다. 대상 코드도 다르다. 맨틀 팀이 바닥부터 만든 것 같은 그린필드가 아니라 기존 코드베이스를 가진 기존 시스템이었다. 기간도 길다. 작년 대부분 동안 관찰했다.

측정 지표가 바뀐 점도 눈여겨볼 만하다. 커밋을 얼마나 생산하는지가 아니라 프로덕션까지의 배포 속도를 썼다는 것이다. 질문 형태로도 제시된다. 얼마나 빠르게 변경을 고객에게 내보내는가, 얼마나 빠르게 출하할 수 있는가.

도구가 아니라 방식이었다

50개 팀 관찰에서 나온 결과가 이 발표의 핵심이다. 절반의 팀과 나머지 절반 사이에 얻은 생산성 향상에 큰 차이가 있었다. 수치가 갈린다. 절반은 3배 미만 향상을 얻었다. 나머지가 중간값 4.5배, 어떤 경우 10배 넘게였다.

그런데 차이의 원인이 도구가 아니라는 점이 확인된다. 이 팀들의 90%가 사내 다른 도구들과 함께 같은 도구를 썼다. 그래서 결론이 나온다. 도구에 관한 것이 아니라 그들이 일하는 방식에 관한 것이었다.

두 집단의 차이가 한 문장으로 규정되는데 이 대비가 이 발표에서 가장 인용할 만하다. 계단 함수 같은 향상을 이룬 팀들은 의도적으로 일하는 방식을 바꿨고 다른 쪽은 그냥 기존 일하는 방식 위에 도구를 뿌렸다.

그리고 발표자 자신의 깨달음이 붙는다. 적어도 나에게는 이것이 큰 아하 모먼트였다. 왜 내가 AI가 약속한 엄청난 생산성 향상을 느끼지 못했을 수 있는지에 대한 것이었다. 답이 짧다. 우리가 일하는 방식을 바꾸는 것에 관한 것이다.

다섯 습관이 어떻게 도출됐는지도 밝혀진다. 파일럿에 참여한 팀들과 베드록 맨틀 팀, 프라임 비디오의 다른 팀들을 인터뷰해서 다섯 습관을 찾았다. 용어 선택도 의도적이다. 습관이라는 단어를 아주 구체적으로 쓰는데, 다시 그 한 번의 스프린트에 관한 것이 아니라 매일 하는 것에 관한 것이기 때문이다. 어려움도 인정된다. 일하는 방식을 바꿀 때 이런 습관을 만들기는 어렵고 시간이 걸린다.

습관 1과 2, 맥락 투자와 감속

첫 습관이 에이전트 맥락에 투자하는 것이다. 문제 진단이 좋다. 우리는 머릿속에 많은 것을 갖고 있고 그 모든 것을 다른 사람에게 전달하는 경향이 있다. 전달 경로가 열거되는데 슬랙 대화, 온보딩, 멘토, 코드 리뷰, 스탠드업과 스프린트 계획이다. 그런데 요구가 달라진다. 그 모든 것을 적어야 했다.

습관의 형태가 구체적이다. 에이전트가 실수하거나 내가 했을 방식과 다르게 할 때마다 내 스킬 파일에서 무엇이 빠졌는지, 내 스티어링 파일에서 에이전트에게 필요했던 무엇이 빠졌는지 묻는 것이다.

그런데 반대 방향의 습관도 함께 제시되는 점이 실무적이다. 모델 개선 이력이 근거로 쓰인다. 작년 중반의 어떤 모델은 스티어링 파일에 하지 말라는 항목을 많이 넣어야 하는 특이점이 많았는데, 이제는 그렇게 많이 하지 않아도 된다. 그래서 새 질문이 생긴다. 이것이 여전히 스티어링 파일에 필요한가, 아니면 그냥 맥락을 부풀리고 있는가. 맥락을 쌓는 것만이 아니라 걷어내는 것도 습관이라는 뜻이다.

둘째 습관이 속도를 내려고 속도를 줄이는 것이고 이 발표에서 가장 반직관적인 부분이다. 관찰이 강하다. 인터뷰한 거의 모든 팀에서 새 일하는 방식을 의도적으로 채택하면서 생산성이 실제로 떨어졌다고 보고했다. 그리고 스스로 인정한다. 반직관적이지 않은가.

논리가 명확하다. 생산성 향상의 하키 스틱 곡선을 보기 전에 의도적인 엔지니어링 작업을 해야 한다. 이유가 붙는다. 에이전트가 거기서 성공하려면 코드베이스에서 먼저 진짜 작업을 해야 하고 특히 브라운필드 기존 코드베이스에서 그렇다.

실제로 한 작업들이 열거되는데 이 목록이 준비 작업의 성격을 보여 준다. 에이전트 맥락을 쌓았고 기존 도구의 오류 메시지를 개선해서 실패할 때 모델이 무슨 일인지 알게 했고 모델이 필요한 것을 실제로 하도록 돕는 새 도구와 MCP 서버를 만들었다. 그리고 구조 변경도 있었다. 많은 팀이 에이전트가 더 쉽게 탐색할 수 있도록 코드베이스를 재구조화했다.

가장 급진적인 변경도 언급된다. 코드베이스의 프로그래밍 언어를 바꾸는 것 같은 과감한 변화도 봤다. 이유가 구체적이다. 타입이 없는 언어라 팀들이 어려움을 겪는 것을 자주 봤는데, 테스트하기 어렵고 컴파일러 오류가 없어서 모델이 추측해서 돌려준다. 그래서 이동 방향이 제시된다. 타입 있는 언어로 옮기는 팀들을 봤고 사내에서 특정 시스템 언어가 아주 인기 있어졌는데 컴파일러가 훌륭한 오류 메시지를 준다. 다만 강제는 아니라고 단서를 붙인다. 그렇게 해야 하는 것은 아니다.

습관 3, 먹이 주기와 돌보기의 차이

셋째 습관이 발표자가 두 번째 아하 모먼트로 꼽는 것이다. 에이전트에게 먹이를 주고 돌보지 않는 것.

문제 진단이 산수로 설명된다. 바이브 코딩을 하고 있다면, 하루 종일 에이전트와 왔다 갔다 대화하고 있다면, 당연히 4~5배 생산성 향상을 보지 못할 것이다. 이유가 명확하다. 당신이 그 시간 전체에 루프 안에 있기 때문이다. 구체적 대기 시간도 제시된다. 코드를 생성하고 검토할 코드를 갖고 돌아오는 데 30초에서 1분 앉아 기다리고 있을 것이다.

그리고 연쇄 효과가 지목되는데 이 지적이 병렬화 불가의 이유를 설명한다. 거기 앉아 기다리고 있으면 다른 일을 하러 갈 수 없다. 에이전트를 병렬로 돌리기가 정말 어렵고 자신을 여러 에이전트로 복제하기가 아주 어렵다.

대안의 형태도 규정된다. 필요한 것과 스스로 검증할 방법을 먹이는 것이다. 그리고 목적이 명시되는데 이 조건이 자율 실행의 핵심이다. 에이전트가 스스로 교정할 수 있고 특정 품질 기준을 만족할 때만 당신에게 돌아오게 하는 것이다. 기준도 구체적이다. 실제로 실행되고 컴파일되고 테스트를 통과할 때, 테스트 가능할 때, 실제로 높은 커버리지를 가질 때.

다음 단계도 제시된다. 이 모든 내용을 스티어링 파일에 넣어서 프롬프트하지 않아도 매번 그렇게 하도록 하는 것이다. 매번 지시하는 것에서 한 번 정의해 두는 것으로 옮기는 방향이다.

습관 4와 5, 의도 명시와 테스트 좌측 이동

넷째 습관이 의도를 명시적으로 만드는 것이다. 사내 관행이 배경으로 언급된다. 아마존에서 행동 주도 개발을 많이 실천하고 제품에 그것을 넣어 뒀다.

문제 양상이 구체적이다. 바이브 코딩에서 흔한 것이 아주 고수준 프롬프트를 주고 에이전트가 코드를 대량 생성하게 한 다음 왔다 갔다 대화하는 것이다. 그 대화 내용도 인용된다. 아, 그건 내가 뜻한 게 아니고 요구사항을 정확히 잡지 못했고 아니 나는 그렇게 만들려던 게 아니었고 여기 기술 설계가 있다.

그래서 판정이 나오는데 이 문장이 이 습관의 근거다. 의도 자체가 틀렸을 때 코드를 두고 에이전트와 반복하는 것이 덜 생산적이라고 느낀다.

대안이 문서 우선이다. 모호하고 복잡한 기능에 대해 명세를 쓰는 과정을 거치는 것을 자주 본다. 그리고 도구의 역할도 언급된다. 명세 전체를 직접 쓸 필요는 없고 모델이 생성하게 할 수 있다. 근거가 비교로 제시되는데 이 대비가 정확하다. 문서를 두고 왔다 갔다 대화하며 모델과 반복하는 것이 코드베이스 전반에 퍼진 코드 변경을 두고 하는 것보다 훨씬 쉽다.

다섯째 습관이 테스트를 왼쪽으로 옮기는 것이다. 목적이 명확하다. 에이전트에게 빠른 피드백 루프를 주는 것이 핵심 중 하나다. 그리고 그것이 무엇을 가능하게 하는지가 규정된다. 그것이 에이전트가 몇 시간씩 나가서 스스로 교정하게 해 주는 것이다.

실수에 대한 태도도 명확하다. 에이전트는 실수할 것이고 그것은 괜찮다. 조건이 붙는다. 올바른 신호를 주면 스스로 교정할 수 있고 그것을 하는 데 한동안 쓸 수 있다.

추가된 것들이 열거되는데 목록이 익숙하다. 린터, 단위 테스트, 통합 테스트, 성능 테스트, 보안 테스트. 그리고 정직한 인정이 붙는다. 이것들은 우리가 애초에 해야 했다고 모두 아는 것들이고 좋은 엔지니어링 위생과 관행이다. 무엇이 달라졌는지도 규정된다. 이제 실제로 투자할 만큼 투자수익률이 마침내 충분히 높아졌다.

가장 구체적인 실천이 목 서비스다. 기존 방식이 이랬다. 통합 테스트에서 살아 있는 서비스를 포함해 전체 시스템을 종단 간으로 테스트했다. 그런데 방향이 바뀐다. 결정적 응답을 가지고 완전히 로컬로 돌아가는 목 서비스에 많이 투자해 왔는데, 에이전트가 모든 것을 로컬로 할 수 있게 해 주기 때문이다. 이유가 명확하다. 다른 서비스를 여럿 띄우고 클라우드 서비스에 연결하지 않고 노트북에서 모든 것을 하는 것이 훨씬 빠르다. 그리고 논리가 닫힌다. 에이전트가 빠른 피드백을 더 많이 얻을수록 더 많은 루프를 돌 수 있고 더 생산적일 수 있다.

여전히 어려운 것들

발표가 낙관으로 끝나지 않는 점이 이 발표의 신뢰도를 만든다. 선을 먼저 긋는다. 이 습관들을 모두 채택하면 열반에 이르고 세계가 본 가장 생산적인 엔지니어링 조직이 될 것이라고 말한다면 태만할 것이다. 상태가 규정된다. 여전히 어렵고 우리는 아직 초기 채택자 국면에 아주 많이 있고 팀들은 아직 알아내는 중이다.

첫 어려움이 번아웃 위험이다. 용어가 인용된다. 이 용어를 내가 만들지 않았고 누가 어느 학회에서 했는지 잊었지만 플로 매트는 실재한다. 현상이 구체적이다. 엔지니어들이 밤늦게까지 깨어 있으면서 에이전트를 밤새 몇 시간 돌게 만들어 아침에 코드 변경이 준비된 상태로 깨어나게 할 완벽한 프롬프트를 얻으려 하는 것을 봤다.

인지 부하도 지목된다. 여러 에이전트를 병렬로 돌릴 때 인지 부하가 증가하고 터미널 탭 사이를 계속 옮겨 다닌다.

그리고 경력 단계별 차이가 나오는데 이 관찰이 가장 실용적이다. AI 산출물을 검토하는 것이 실제로 쓰는 것보다 어떤 사람에게는 더 어렵고 특히 경력 초기에 그렇다. 이유가 설명된다. 시니어 엔지니어는 경력의 큰 부분을 이미 남의 코드를 검토하는 데 써 왔다. 그런데 초기 경력자는 다르다. 그 근육이 아직 없어서 검토가 익숙한 것보다, 그리고 실제로 쓰는 것보다 훨씬 많은 인지 부하로 느껄질 수 있다.

둘째 어려움이 조직 변화다. 두 층이 구분된다. 엔지니어로서 일하는 방식을 바꾸는 것이 이미 어렵고 프런티어 엔지니어일 때 하루를 쓰는 방식이 완전히 바뀐다. 그런데 조직도 바뀌어야 한다. 조직도 프런티어 엔지니어링 팀을 가능하게 하려면 바뀌어야 한다.

가장 흔한 문제가 지목되고 발표자가 자기 책임도 인정한다. 감속해서 가속하는 것을 받아들이는 것인데, 나 자신도 이것에 죄가 있었다. 문제 발언이 인용된다. 이제 AI 도구가 있고 모델이 이렇게 놀라운데 왜 더 빠르게 가지 않는가. 그리고 답이 제시된다. 코드베이스에 투자하고 팀의 최선 관행을 알아내고 팀에서 어려운 습관 변화를 만드는 데 두 달을 써야 하기 때문이다. 외부 압력도 언급된다. 하루에 20개 PR을 출하한다고 말하는 회사들을 소셜에서 보면서 매달 기능 출하를 계속 기대한다면 문제가 된다는 것이다.

둘째가 너무 빠르게 조직 전반으로 넓히는 것이다. 반사실 논거가 제시된다. 거대 조직의 모든 팀이 즉시 프런티어 팀이 되기를 기대했다면, 개척자 팀과 스프린트 실험, 파일럿 팀에서 얻은 배움을 얻지 못했을 것이다. 그리고 다음 과제가 규모로 제시된다. 2026년이 아마존에게는 이것을 어떻게 확장하는가에 관한 것이고 50개 팀 대신 다음 2,000개 팀으로 어떻게 넓히는가다. 성급한 확대의 결과도 지목된다. 너무 빠르게 전개하면 자기가 뭘 하는지 모르는 팀이 많아지고 자기 조직의 최선 관행과 필요한 맥락을 찾을 시간을 갖지 못한다.

새 병목은 의사결정이다

마지막 어려움이 가장 구조적이다. 새 병목을 찾게 될 것이다. 이전 상태가 규정된다. 전에는 수동으로 코드를 쓰는 것이 병목이었다.

새 병목이 지목되는데 이 발견이 발표의 결론과 이어진다. 사내에서 의사결정 속도가 새 병목이 된다는 것을 발견했다. 기제가 설명된다. 새 제품을 실제로 만들겠다는 결정을 검토하는 데 더 많이 쓸수록 이제 제품을 만드는 것이 더 느려지는데, 코드는 1~2개월만 걸리기 때문이다. 승인 절차도 포함된다. 제품 출시와 관련된 모든 검토 절차가 병목이 된다.

산수가 명확하게 제시된다. 새 제품을 만드는 데 9~12개월 걸릴 때는 결정하는 데 두 달, 출시를 승인하는 데 두 달이 전체적으로 크게 문제되지 않았다. 그런데 지금은 다르다. 이제 그것들이 병목이고 가장 긴 막대다.

그래서 관찰이 하나 더 붙는데 이 문장이 프런티어 팀의 실제 모습을 보여 준다. 프런티어 엔지니어링 팀이 코드를 쓰는 것보다 결정을 내리는 데 더 많은 시간을 쓰는 것을 자주 본다. 처방도 제시된다. 빠른 결정을, 특히 되돌리기 쉬운 결정을 더 많이 내릴수록 좋다.

마지막 요약이 발표 전체를 한 문장으로 압축한다. 프런티어 엔지니어링은 의도적으로 일하는 방식을 바꾸는 것에 관한 것이다. 그리고 난이도가 함께 인정된다. 그것은 어렵고 시간이 걸리며 새 습관과 새 일하는 방식을 형성하는 것이다. 범위도 명시된다. 어떤 엔지니어링 팀에도, 그리고 조직에도 적용된다. 청중에게 남기는 요구가 짧다. AI 도구와 어떻게 상호작용하고 있는지, 그것이 루프 안에 있는 상태에서 스스로를 해방하도록 어떻게 바뀔 수 있는지 생각해 보라.

🔗 최근 게시분과의 대조

Clare Liguori (AWS)	최근 노트
도구가 아니라 일하는 방식	Gregor “AI 도입은 도구 문제가 아니라 리더십 문제” — 같은 결론
감속해서 가속한다	Bessemer “인프라가 실재해야 전환이 가능하다” — 준비 작업의 필요
중간값 4.5배, 절반은 3배 미만	Bessemer “상위 1%가 중위값의 46배” — 분포의 두 측정
의사결정이 새 병목	AWS 블로그 “통합 시간 = 전체 사이클 − 코딩 시간” — 병목 이동
초기 경력자가 검토에 더 큰 부하	Bessemer “L2가 AI로 가장 고전한다” — 같은 관찰
먹이 주기 vs 돌보기	DHH “에이전트와 직접 상호작용해야 한다” / Matt Dailey “프로토타입 중력”

특히 Bessemer 플레이북과 같은 현상을 다른 표본으로 확인한다. 그쪽은 스무 곳 넘는 회사 인터뷰로 조직 이득이 50% 아래에서 멈춘다고 했고, 이 발표는 아마존 내부 50개 팀에서 절반이 3배 미만이라고 보고한다. 두 조사 모두 원인을 조직과 방식에서 찾는데, 이 발표는 그것을 다섯 습관으로 구체화한 점이 다르다.

그리고 Gregor 노트와 정면으로 맞물린다. 그쪽은 AI 도입이 도구 문제가 아니라 리더십 문제라고 했고, 이 발표는 기존 방식 위에 도구를 뿌린 팀이 3배 미만에 머물렀다는 실측으로 같은 주장을 뒷받침한다.

더 생각해보기

• 절반이 3배 미만, 절반이 4.5배라는 이분화가 이 발표의 가장 값어치 있는 데이터다. 자기 조직에서 같은 이분화가 보이는지 확인하려면 배포 속도를 팀 단위로 나눠 보는 것만으로 시작할 수 있다.
• 감속해서 가속한다는 습관이 조직 차원에서 가장 어렵다. 발표자 본인이 리더로서 죄가 있다고 인정한 점이 중요한데, 두 달의 감속을 명시적으로 승인하는 절차가 없으면 이 습관은 개인 수준에서 좌초한다.
• 스티어링 파일을 걷어내는 것도 습관이라는 지적이 실무적으로 신선하다. 모델이 개선되면 과거의 금지 항목이 부채가 되므로, 분기마다 지시 파일을 재검토하는 일정이 필요해진다.
• 의도가 틀렸을 때 코드를 두고 반복하는 것이 덜 생산적이다는 판정이 명세 우선을 정당화한다. 다만 어느 복잡도부터 명세를 쓸지 기준이 없으면 모든 작업에 문서를 요구하는 쪽으로 흐를 위험이 있다.
• 목 서비스를 로컬 결정적으로 만든다는 실천이 가장 구체적인 투자 항목이다. 에이전트 루프 횟수가 피드백 속도에 비례한다면, 테스트 실행 시간 단축이 곧 생산성 투자가 된다.
• 초기 경력자에게 검토가 더 큰 부하라는 관찰은 교육 설계를 바꿔야 한다는 뜻이다. 코드를 쓰는 훈련보다 읽고 판정하는 훈련을 먼저 두는 순서가 검토되어야 한다.
• 의사결정이 새 병목이라는 발견은 엔지니어링 조직 밖의 문제다. 코드가 1~2개월이면 나오는데 승인이 넉 달 걸린다면, 개선 여지가 개발 조직이 아니라 거버넌스에 있다.
• 사례마다 한계를 스스로 짚은 발표 구조가 인상적이다. 최고 엔지니어 여섯 명 / 방해 없는 스프린트 / 정상 분포 50개 팀이라는 세 단계는 다른 조직이 자기 사례를 검증할 때도 쓸 수 있는 틀이다.