도구는 변수가 아니었다 — 같은 도구를 쓴 50개 팀이 갈린 지점

1. 이 글은 무엇에 관한 글인가?

AWS의 Clare Liguori가 발표한 From AI-Assisted to AI-Native: Building a Frontier Development Team을 보고 정리한 글입니다. 한 줄로 요약하면 이렇습니다.

50개 팀 중 90%가 같은 코딩 어시스턴트를 썼습니다. 절반은 3배 미만이었고, 절반은 중앙값 4.5배, 때로는 10배를 넘겼습니다. 도구가 같았으니, 도구는 변수가 아니었습니다.

AI 네이티브 SDLC 플레이북이 "프로세스를 어떻게 다시 짤 것인가"에 대한 제안이었다면, 이 발표는 그 제안을 실제로 1년 가까이 관찰한 결과 입니다. 제안과 관찰이라 성격이 다릅니다.

이 발표가 다른 이유

AI 생산성 이야기는 대부분 두 종류입니다. 잘 된 사례 하나 를 확대하거나, 안 된다는 회의론 을 확대하거나. 이 발표가 흥미로운 건 둘 다 아니기 때문입니다.

관찰 대상:  평범한 팀 50개 (시니어리티 구성도 평범, 기존 코드베이스에서 일함)
기간:      거의 1년
같은 것:    90%가 동일한 코딩 어시스턴트
다른 것:    일하는 방식
결과:      절반은 3배 미만 · 절반은 중앙값 4.5배

그린필드도 아니고, 뽑아온 슈퍼스타 팀도 아니고, 두 주짜리 파일럿도 아닙니다. 평범한 팀들을 오래 지켜본 것 이고, 그래서 갈림의 원인이 도구가 아니라는 결론이 나옵니다.

2. 파일럿이 실제로 측정한 것

발표는 화려한 숫자부터 꺼낸 뒤, 그 숫자를 스스로 깎습니다. 이 순서가 중요합니다.

화려한 쪽

개인 생산성으로 환산하면 20배에 가까운 숫자입니다. 여기서 멈추면 딱 좋은 홍보 자료가 됩니다.

그런데 재현되지 않는다

발표는 곧바로 왜 그 팀이 재현 가능한 사례가 아닌지 를 설명합니다. 선발된 인원, 새로 시작하는 코드베이스, 집중된 스코프, 조직의 전폭적 지원 — 조건 자체가 특별했습니다. 열흘짜리 스프린트 사례에도 비슷한 각주가 붙습니다.

이게 제가 이 발표를 신뢰하게 된 지점입니다. 자기가 방금 보여준 숫자에 각주를 다는 발표는 흔치 않습니다. 그리고 각주를 달았기 때문에, 그 다음에 나오는 50개 팀 이야기가 무게를 가집니다.

파일럿은 가능성 을 보여주고, 50개 팀은 재현 조건 을 보여줍니다. 조직이 알아야 하는 건 후자입니다.

3. 진짜 갈림은 도구 밖에 있었다

50개 팀의 결과를 나란히 놓으면 이렇게 됩니다.

   ┌─ 절반 ──────────────────────────────┐
   │ 배포 속도 개선 3배 미만               │  ← 기존 방식 위에 에이전트를 얹음
   └─────────────────────────────────────┘
   ┌─ 나머지 절반 ────────────────────────┐
   │ 중앙값 4.5배 · 최대 10배 이상         │  ← 일하는 방식 자체를 바꿈
   └─────────────────────────────────────┘
             ↑ 90%가 같은 도구를 씀

발표의 표현이 정확합니다. 뒤처진 쪽은 이미 일하던 방식 위에 에이전트를 뿌린(sprinkled) 것 이고, 앞선 쪽은 일하는 방식을 의도적으로 바꾼 것 입니다.

"뿌린다"가 무슨 뜻인가

익숙한 그림입니다.

• 스프린트 구조는 그대로, 티켓 크기도 그대로, 리뷰 큐도 그대로
• 에디터에만 어시스턴트가 붙음
• 사람이 짜던 코드를 에이전트가 짜고, 나머지 단계는 전부 그대로

이러면 한 단계만 빨라집니다. 지난 글에서 정리한 그 이야기가 여기서 실측치로 확인됩니다 — 한 단계만 빨라지면 전체는 빨라지지 않고, 병목이 옮겨갈 뿐입니다. 3배 미만이라는 숫자가 그 옮겨간 병목의 크기입니다.

4. 프론티어 개발은 태도가 아니라 행동이다

발표는 "프론티어 개발"을 마음가짐으로 정의하지 않습니다. 관찰 가능한 행동 으로 정의합니다.

이 정의 방식이 좋은 이유는 자기 팀이 어디쯤인지 즉시 알 수 있기 때문 입니다. "우리도 AI 잘 쓰고 있어요"는 판정이 불가능하지만, 위 세 줄은 판정이 됩니다.

그리고 세 줄이 서로 물려 있습니다.

직접 짜는 코드가 1~2%가 되려면
   → 에이전트가 몇 시간씩 혼자 돌아야 하고
   → 몇 시간씩 혼자 돌리려면 옆에 붙어 있으면 안 되고
   → 옆에 안 붙어 있어야 여러 개를 동시에 돌릴 수 있다

거꾸로도 성립합니다. 에이전트 옆에 붙어서 대화하고 있으면 위 세 줄 중 어느 것도 달성되지 않습니다. 이게 다섯 가지 습관 중 세 번째의 근거입니다.

5. 다섯 가지 습관

발표의 본론입니다. 그리고 다섯 개 다 화려하지 않습니다.

습관 1 — 머릿속에 있는 걸 적어둔다 (그리고 계속 쳐낸다)

에이전트가 쓸 컨텍스트를 자산으로 취급합니다. 컨벤션, 코딩 표준, 테스트 패턴, 저장소 구조. Bedrock 팀은 모노레포를 쓰고 에이전트가 남긴 주석을 지우지 않고 지속 메모리처럼 유지 했습니다.

여기서 발표가 한 겹 더 들어갑니다.

모델이 좋아지면 컨텍스트를 쳐내라. 예전 모델의 약점을 우회하려고 적어둔 지침이 그대로 남아 컨텍스트를 부풀린다.

덜어내는 컨텍스트 엔지니어링에서 다뤘던 이야기와 정확히 같습니다. 다만 여기서는 정리 시점 이 명확히 지정됩니다 — 모델 업그레이드가 곧 컨텍스트 감사 시점입니다. 대부분의 팀은 지침을 더하기만 하고 지우지 않습니다.

습관 2 — 먼저 느려질 각오를 한다

가장 언급이 적고 가장 결정적인 습관입니다.

브라운필드 코드베이스에 에이전트를 넣으면
   → 처음엔 느려진다
   → 여기서 그만두는 팀은 가속을 영영 못 본다
   → 밀고 나간 팀만 복리 가속을 본다

그리고 "느려지는 동안 무엇을 하는가"가 핵심입니다. 발표가 든 예가 구체적입니다 — 에러 메시지를 개선하고, 없던 도구를 만들고, 저장소 구조를 아예 다시 짭니다.

이 목록이 흥미로운 이유는, 전부 에이전트를 위한 작업이 아니라 원래 했어야 하는 작업 이기 때문입니다. 에이전트는 그걸 안 한 대가를 사람보다 정직하게 드러낼 뿐입니다. 사람은 나쁜 에러 메시지를 경험으로 우회하지만, 에이전트는 그냥 막힙니다.

습관 3 — 돌보지 말고 먹인다

발표에서 가장 인상적인 진단입니다.

대화를 이어가고 있으면 당신은 계속 루프 안에 있고, 루프 안에 있으면 병렬화가 불가능하다.

에이전트와 주고받는 게 협업처럼 느껴지지만, 실제로는 사람이 스케줄러가 된 상태 입니다. 그래서 앞선 팀들은 방식을 바꿉니다 — 잘 쪼개진 작업 백로그를 유지하고, 여러 에이전트를 동시에 돌리고, 리뷰는 비동기로 합니다. 밤새 돌려두는 팀도 있습니다.

한 엔지니어는 "연속된 시간 두어 시간" 만으로 변경 하나를 완결했다고 합니다. 연속 시간이 줄어드는 게 아니라, 연속 시간이 필요 없어지는 쪽으로 일이 재구성된 것 입니다.

습관 4 — 코드와 싸우기 전에 의도를 문서에 고정한다

생성된 코드를 놓고 "이게 아니라..." 하며 고쳐나가는 건 가장 비싼 방식 입니다. 앞선 팀들은 코드가 나오기 전에 구조화된 스펙·요구사항 문서로 의도를 확정합니다.

느린 쪽:  프롬프트 → 코드 → "아니 이거 말고" → 코드 → "그것도 아니고" → ...
빠른 쪽:  의도 문서 확정 → 코드 → (문서와 대조)

차이는 다투는 대상 입니다. 코드를 놓고 다투면 매번 처음부터 다시 읽어야 하고, 문서를 놓고 다투면 한 번 합의한 게 남습니다. Agent Skills 글에서 정리한 "검증 가능한 산출물"과 같은 축입니다.

습관 5 — 테스트를 왼쪽으로 당긴다

에이전트가 스스로 고칠 수 있을 만큼 피드백 루프가 빨라야 합니다. 그래서 앞선 팀들은 로컬 결정론적 목(mock)으로 통합 테스트를 돌릴 수 있게 만들어둡니다. 파이프라인에 올려서 20분 뒤에 결과를 보는 구조로는 에이전트가 자기 교정을 못 합니다.

부수 효과가 하나 따라옵니다 — 코드 리뷰가 스타일이 아니라 아키텍처를 보게 됩니다. 스타일은 이미 로컬에서 걸러졌기 때문입니다.

6. 왜 4.5배인가 — 곱셈 구조

AWS 블로그가 이 숫자의 출처를 이렇게 분해합니다.

1.5배  판단이 적게 드는 일의 가속
  ×
1.5배  판단이 많이 드는 일에 집중 (컨텍스트 스위칭 제거)
  ×
1.5배  에이전트에 담긴 도메인 지식에 즉시 접근
  =
약 3.4배 → 실측 중앙값 4.5배

이 분해가 유용한 이유는 어느 항이 비어 있는지 스스로 점검할 수 있기 때문 입니다.

곱셈이라서 한 항이 1이면 전체가 그 항에 갇힙니다. 세 항을 다 1.5로 만드는 것보다, 1인 항이 있는지 찾는 게 먼저입니다.

7. 이 블로그 저장소에 대보면

늘 하던 대로, 남 얘기로 두지 않고 이 저장소에 대봅니다.

솔직하게 적으면, 3번이 완전히 비어 있습니다. 그리고 6절의 곱셈 구조대로면 3번이 1인 순간 저판단 가속과 고판단 집중 두 항이 동시에 갇힙니다. 이 저장소에서 체감 생산성이 기대만큼 안 오르는 이유를 찾자면 도구가 아니라 여기입니다.

1번도 정직하게는 미흡합니다. CLAUDE.md에 배포 특이사항과 콘텐츠 규약이 적혀 있지만, 모델이 바뀔 때 이 문서를 다시 읽고 지운 적은 한 번도 없습니다. 습관 1의 후반부 — 쳐내기 — 를 아예 안 하고 있는 셈입니다.

한 가지는 오히려 잘 되어 있습니다. 새 글을 추가하면 깨지는 하드코딩된 테스트가 네 곳 있는데, 이게 로컬에서 즉시 실패로 드러납니다. 성가시지만 습관 5가 말하는 그 구조입니다 — 에이전트가 파이프라인을 기다리지 않고 스스로 고칠 수 있습니다.

8. 오해하기 쉬운 지점

오해 1 — "4.5배는 우리 팀 얘기가 아니다"

절반은 맞습니다. 다만 3배 미만이었던 나머지 절반도 같은 회사, 같은 도구, 평범한 코드베이스 였습니다. 조건이 다른 게 아니라 방식이 달랐던 것 이 이 연구의 요지입니다.

오해 2 — "20배 사례가 목표다"

발표가 직접 부정합니다. Bedrock 사례는 조건이 특별해서 재현되지 않습니다. 재현 가능한 목표치는 4.5배이고, 그건 다섯 가지 습관의 결과 입니다.

오해 3 — "직접 코드를 1~2%만 쓴다는 건 실력이 필요 없다는 뜻"

반대입니다. 습관 4와 5가 요구하는 건 의도를 정확히 쓰는 능력과 검증 구조를 설계하는 능력 입니다. 타이핑이 사라진 자리에 판단이 들어옵니다. 발표의 마지막 문장이 그걸 못박습니다.

새로운 병목은 의사결정 속도다.

오해 4 — "느려지는 구간은 스킵할 수 있다"

습관 2가 정확히 이걸 막습니다. 브라운필드에서 에이전트가 성공하려면 코드베이스 쪽이 먼저 준비돼야 합니다. 그 구간에서 그만둔 팀이 3배 미만 그룹입니다.

오해 5 — "이건 도구 도입 문제다"

발표 전체가 반박입니다. 90%가 같은 도구를 썼습니다. 도구를 바꾸는 건 이미 다들 한 일이고, 갈린 건 그 다음 입니다.

9. 정리

앞선 글들과 이어보면 축이 하나 더 늘어납니다.

• AI 네이티브 SDLC — 프로세스를 어떻게 다시 짤 것인가 (제안)
• 코드 품질은 제약에 있다 — 에이전트를 둘러싸는 것
• Agent Skills — 에이전트에게 집어넣는 것
• 이번 글 — 그래서 실제로 뭐가 갈렸는가 (관찰)

앞의 세 글은 전부 "이렇게 하는 게 맞다"는 주장이었습니다. 이 발표는 평범한 팀 50개를 1년 지켜본 뒤의 보고 라서 성격이 다릅니다. 그리고 보고의 결론이 주장과 같은 방향을 가리킨다는 게, 이 시리즈에서 얻은 가장 실용적인 확인입니다.

도구는 이미 같습니다. 남은 변수는 일하는 방식뿐입니다.

참고 문서

• Clare Liguori, From AI-Assisted to AI-Native: Building a Frontier Development Team — AI Engineer World's Fair 2026
• AWS, How frontier teams are reinventing AI-native development
• Kiro, Frontier teams & spec-driven development
• 이전 글 — Agent Skills · 코드 품질은 제약에 있다 · AI 네이티브 SDLC 플레이북