AI 보조를 넘어 AI 네이티브로 — 일하는 방식을 바꾸는 5가지 습관 (Clare Liguori, AWS)

출처: https://www.youtube.com/watch?v=Ry0WHNxDbYA&t=96s · 채널: TechBridge-KR / AI Engineer World’s Fair (2026.08.28) · 길이: 00:20:28 연사: Clare Liguori — Senior Principal Engineer, AWS (에이전트 기반 코딩 도우미 Kiro 개발) 다운로드 자막: raw/transcripts/2026-08-30-clare-liguori-ai-native-five-habits.ko.srt (ko 자동, 97KB · 927 cue) · en 자동 raw/transcripts/2026-08-30-clare-liguori-ai-native-five-habits.en.srt 병행 확보

한눈에 보는 요약

AI 4단계 진화: 인라인 코드 완성 → 코드에 질문하는 채팅 → Vibe coding → Frontier development. 앞 3단계까지는 사용자가 느낀 생산성이 10~20%에 그친 반면, 마지막 단계에서만 단계함수적 도약이 나타났다. — 정의·3경로·5습관 체계는 frontier-development 개념 노트에 정리.
선구자 사례는 극단적: Amazon Bedrock Mantle(추론 데이터 플레인)은 30명·18개월 예상 프로젝트를 6명·76일에 완수(86% 빠름, 80% 적은 인원, 커밋 2→40개/주·20배). Prime Video 금융 시스템도 6명이 10일간 밀폐 스프린트로 검증.
진짜 실험은 평범한 50팀: 2025년 brownfield(기존 시스템) 50개 팀을 1년간 관찰. 절반은 도구를 기존 방식에 뿌리기만 해 <3배, 나머지 절반은 미디어 4.5배·중 10배 이상의 배포 속도 향상을 기록했다. 측정 지표는 커밋이 아니라 production deployment velocity다.
갈린 이유는 도구가 아니라 일하는 방식: 5가지 습관을 의도적으로 체화한 팀만 도약했다 — (1) 에이전트 컨텍스트 투자 (2) 가속을 위한 감속 (3) 돌보지 말고 먹이기 (4) 의도의 명문화 (5) 테스트의 좌측 이동. 이는 harness·mcp를 비롯한 에이전트 실행 환경과 직결되며, 특히 (4)·(5)는 BDD(행위 주도 개발)의 실행 가능한 명세·빠른 검증 루프와 같은 뿌리를 공유한다.
새로운 병목은 의사결정 속도: 코드 작성은 1~2개월로 줄었지만 검토·승인에 2개월씩 걸리면 전체 병목이 된다. 조직 전체가 2개월의 습관 형성 기간을 감수하고 의사결정 프로세스를 바꿔야 한다. 같은 AI Engineer 무대의 2026-07-26-garry-tan-ai-native-company-brain가 말한 ‘브레인은 소유’ 메시지와 짝을 이루며, 전체 맥락은 frontier-development에서 5습관·측정·병목으로 재구성했다.

핵심 한 줄: 같은 Kiro를 써도 성과가 3배와 10배로 갈리는 이유는 도구가 아니라 ‘매일 반복하는 5가지 습관’을 바꿨는지 — 코드를 빨리 짜는 팀보다 결정을 빨리 내리는 팀이 이긴다.

장면별 상세 설명

[00:00] 1. 왜 이 발표를 하는가 — From AI-Assisted to AI-Native

장면 1 — 타이틀 슬라이드. From AI-Assisted to AI-Native, Building a Frontier Development Team

발표는 AI Engineer World’s Fair 무대다. Clare Liguori는 “3년 넘게 에이전트형 AI를 연구했고, Kiro를 만들면서 아마존 내부에서 이제껏 본 적 없는 단계함수적 생산성 향상을 목격했다”고 운을 뗀다. 기존 AI로는 체감 10~~20% 개선에 머물렀지만, 일부 팀은 같은 도구로 4.5~~10배를 냈다 — 그 간극의 원인을 풀어내는 것이 오늘의 주제다.

[00:00:45] 2. AI 개발 지원의 진화 4단계

장면 2 — Evolution of AI for development. Inline code completion / Ask questions about my code / Vibe coding / Frontier development 4칸

발화 핵심은 진화사다. (1) Inline code completion — 다음 줄을 채워주기, (2) Ask questions about my code — “내 코드에 대해 물어보는 채팅”, (3) Vibe coding — 프롬프트로 즉흥 코딩, (4) Frontier development — 에이전트가 자율적으로 계획·실행·검증까지 하는 방식. Clare는 자신이 4단계를 모두 겪으며 앞선 3단계까지는 10~20% 개선에 머물렀다고 솔직히 말한다.

[00:01:20] 3. 내부 파일럿이 보여준 숫자의 도약

장면 3 — 같은 4단계 슬라이드에 주석 추가. Internal pilot study shows 4.5x median productivity improvement; some teams more than 10x

화면에 같은 4칸 아래에 괄호가 생긴다: “Internal pilot study shows 4.5x median productivity improvement; some teams more than 10x”. 아마존 내부 파일럿에서 Frontier development 구간에만 미디어 4.5배, 일부 팀은 10배 이상이 찍힌 것이다. 이후 이야기는 “왜 같은 도구를 쓴 팀끼리도 이렇게 갈렸는가”로 이어진다.

[00:02:35] 4. 선구자 — Amazon Bedrock Mantle

장면 4 — The pathfinder: Amazon Bedrock Mantle. 86% faster / 80% fewer people / 20x increase in commits

첫 번째 선구자 사례는 Bedrock Mantle — Claude/GPT 같은 LLM을 호스팅하는 추론 데이터 플레인을 Kiro로 처음부터 다시 만든 프로젝트다. 예상은 30명 18개월이었는데 실제로는 6명이 76일 만에 끝냈다.

86% faster — 76 days vs. 18-month projection
80% fewer people — 6 vs. 30
20x increase in commits — 주당 2개 → 40개

다만 Clare는 “이건 6명의 최정예(그 중에서 두 명은 distinguished engineers)가 처음부터 새로 만든 그린필드”라서 일반 팀에 그대로 적용하기 어렵다고 선을 긋는다.

[00:04:50] 5. 두 번째 검증 — Prime Video Finance 10일 스프린트

장면 5 — The sprint: Prime Video Financial Systems. 10-day experiment with six engineers in one room

두 번째는 좀 더 재현 가능한 실험이다. Prime Video 금융 시스템 팀 6명을 한 방에 모아 외부 방해를 차단하고 10일간 Kiro를 마음껏 쓰게 했다. 결과는 Mantle에 근접했다.

슬라이드의 별표 조건이 핵심이다: No on-call duties. Limited meetings. Senior engineer spent 3 weeks prior creating well-scoped tasks with detailed requirements. 즉, 방해 없는 환경 + 사전에 작고 범위가 명확한 작업 분해가 전제였다. 역시 “이 조건을 일반 팀에 항상 줄 수 없다”는 한계가 남는다.

[00:06:15] 6. 진짜 질문 — 평범한 50팀은 어떻게 됐나

장면 6 — The pilot: Amazon Stores. 2025 study of AI adoption across 50 normal teams

그래서 2025년, 아마존 스토어의 평범한 50팀을 관찰했다. 경력 분포는 주니어~시니어 정상 분포, 대상은 신규가 아니라 brownfield(기존 시스템과 레거시 코드베이스) 다. 측정 지표는 커밋 수가 아니라 **production deployment velocity(프로덕션 배포 속도)** 로 바꿨다 — 실제 고객에게 가치가 전달되는 속도이기 때문이다.

[00:07:10] 7. 같은 도구, 정반대 결과 — 50%의 벽

장면 7 — 같은 50팀 슬라이드, 두 박스 상세. 50% <3x vs 50% 4.5x median

결과는 극명했다.

왼쪽 50% (25팀): <3배 — Sprinkled Kiro and other internal AI tools on their existing way of working — 기존 방식 위에 도구를 뿌리기만 함
오른쪽 50% (25팀): 미디어 4.5배 — Intentionally adopted a new way of working with Kiro — 일하는 방식을 의도적으로 바꿈

Clare의 결론은 한 문장이다: *“중요한 것은 도구가 아니라 일하는 방식이었다.”*

[00:08:20] 8. 습관 1 — 에이전트 컨텍스트에 투자하기

장면 8 — Habit 1: Invest in agent context. What am I missing in my skills files? / Do I still need this?

5가지 습관 중 첫째다. 머릿속 암묵지를 슬랙 대화로 전수하지 말고 스티어링 파일(skills/steering files)에 명문화하라. 2026-07-26-garry-tan-ai-native-company-brain가 “스킬 파일=직원”이라고 한 것과 같은 맥락이다.

에이전트가 실수할 때마다: “What am I missing in my skills files?”
새 모델이 나올 때마다: “Do I still need this in my skills?”

모든 것을 글로 써서 에이전트가 스스로 참조하게 하는 것이 출발점이다. 구두 전달·1:1 멘토링에 의존하면 에이전트는 맥락을 잃는다.

[00:09:25] 9. 모델이 좋아질수록 규칙을 가지치기하라

장면 9 — 같은 Habit 1 슬라이드, 발화는 프루닝 강조

Sonnet 3.7 시절에는 주의사항을 많이 박아야 했지만, Opus 4.5(2025년 11월) 이후로는 그런 수고를 크게 줄일 수 있었다. 모델이 발전하면 이전에 넣어 둔 우회 규칙이 오히려 컨텍스트를 부풀리는 빚이 된다. 그래서 습관은 “추가”만큼이나 “제거·가지치기(pruning)” 다. 컨텍스트를 낭비하는 오래된 지침을 주기적으로 덜어내야 한다.

[00:10:40] 10. 습관 2 — 더 빨리 가기 위해 먼저 느려지기

장면 10 — Habit 2: Slow down to speed up. 5가지 체크리스트

둘째 습관은 선행 투자다. 성과가 난 팀들은 2개월의 감속 구간을 계획했다:

Build agent context
Improve existing tools’ error messages (모델이 오류 원인을 이해하도록 메시지 개선)
Build new tools and MCP servers (모델이 실제로 필요한 작업을 수행하도록 도구 신설 — mcp 참조)
Restructure codebase (에이전트가 탐색하기 쉬운 구조로 재구성)
Change programming language — 많은 팀이 TypeScript로 전환 (타입 정보가 에이전트에게 훨씬 명확하기 때문)

당장 기능 개발을 멈추고 이 부채를 갚는 결정이, 이후 4.5~10배의 레버리지를 만든다.

[00:11:30] 11. 습관 3 — 에이전트를 돌보지 말고 먹이를 주라

장면 11 — Habit 3: Feed agents, don't babysit. Babysitting vs Feeding 비교표

“Feeding, not babysitting.” 가장 시각적으로 대비되는 슬라이드다.

Babysitting(뒤돌아보는 방식): Add authorization to this API → Add tests → The tests don't pass → The tests still don't pass → We don't have enough test coverage → Add integration tests → The integ tests don't pass — 30초~1분씩 생성 대기하며 한 단계마다 끼어든다.

Feeding(한 번에 먹이는 방식): Add authorization to this API. Add unit tests. Run the unit tests; ensure they pass and achieve 90% coverage for the new code. Add integ tests to validate authorization and ensure they pass.

차이는 **“할 일 + 검증 방법 + 품질 기준”을 한 번에 넘겨 에이전트가 스스로 루프를 돌게 하느냐**다. Clare는 품질 바(quality bar)를 명시한다: 실제로 실행·컴파일되고, 테스트를 통과하고, 테스트 가능하며 높은 커버리지를 확보했을 때만 결과를 반환하라. 그래야 에이전트가 30분~수 시간 동안 자율 보정하며 돌아갈 수 있고, 당신은 다른 에이전트를 병렬로 띄울 수 있다. 이 패턴은 harness의 검증 루프와도 통한다.

[00:12:50] 12. 습관 4 — 의도를 명문화하라

장면 12 — Habit 4: Make intent explicit. Feature Specification 템플릿

네 번째는 코드를 짜기 전에 의도를 합의하는 일이다 — BDD에서 시나리오를 먼저 정의하고 그 뒤에 구현을 채우는 것과 같은 원리다. “아, 내가 의도한 건 이게 아닌데”를 코드 반복으로 메우는 것은 생산성이 최악이다.

Kiro에서 많이 쓰는 Feature Specification 템플릿을 보여준다:

# Feature Specification
## Objective
What is the main objective or purpose of the project
## Use Cases
Who are the users and how will they use the feature
## Key Functionality
What are the key elements, style, and design approach required
## Technical Requirements and Design
What specific technical or quality requirements must be met and how should the feature be implemented

모호한 기능일수록 에이전트와 사양서를 먼저 반복 개선하고, 그 뒤에 코드 구현을 맡긴다. 사람 사이의 합의도, 사람-모델 사이의 합의도 같은 원리다.

[00:13:55] 13. 습관 5 — 테스트를 왼쪽으로 당겨라

장면 13 — Habit 5: Shift testing left. Give the agent a fast, local feedback loop

다섯째는 Shift testing left — 테스트를 개발 앞단으로 당겨 빠르고 로컬한 피드백 루프를 주는 것이다. BDD의 Given-When-Then 시나리오가 바로 이런 로컬·결정론적 검증 신호가 된다.

“The agent is going to make mistakes and that’s fine.” 실수는 전제다. 적절한 신호(린터·목 서비스·테스트)가 있으면 에이전트가 스스로 고친다. 그동안 “어차피 해야 했던” 테스트 부채의 ROI가 이제는 충분히 높아졌으니, 에이전트 시대에 비로소 투자할 이유가 생겼다.

[00:15:05] 14. 왜 피드백 속도가 생산성을 가르는가

장면 14 — 같은 Habit 5 슬라이드, 발화는 루프 속도 강조

같은 슬라이드에서 Clare가 덧붙인다: “에이전트가 더 빨리 피드백을 받을수록 더 많은 루프를 돌 수 있고, 더 생산적이 된다.” 클라우드 서비스를 여러 개 띄우거나 외부 시스템에 연결하지 않고 노트북 안에서 모든 루프를 닫는 것이 핵심이다. 그래서 mock 서비스가 중요하다.

[00:16:20] 15. 여전히 어려운 것 — 번아웃

장면 15 — What is still hard: Burnout. FOMAT / Cognitive load / Reviewing AI output

장밋빛만은 아니다.

FOMAT: Fear Of Missing Agent Time — 에이전트가 밤새 돌아가는데 자고 있으면 뒤처질까 봐 밤늦게까지 완벽한 프롬프트를 다듬는 두려움
Cognitive load increases with number of parallel agents — 병렬 에이전트가 늘어날수록 터미널 탭을 오가며 상태를 추적하는 인지 부하가 폭증
Reviewing AI output sometimes harder than writing it — 직접 쓰는 것보다 AI 출력을 검증하는 게 더 어렵다. 특히 주니어는 그 근육이 아직 없다. — 2026-08-22-code-review-intent-verification의 ‘의도·증거 검증’ 관점과 연결된다.

모든 습관을 들이면 열반에 이르는 것은 아니라고 Clare는 경고한다.

[00:19:35] 16. 조직이 바뀌지 않으면 앞으로 나아갈 수 없다

장면 16 — What is still hard: Organizational change. Slowing down / Too broad too fast / New bottlenecks

마지막 난관은 조직 변화다.

Accepting slowing down to speed up — 경영진이 “AI 있는데 왜 더 빨리 못 하냐”고 재촉하면, 코드베이스에 투자할 2개월이 사라진다. 습관 형성 자체에 2개월이 필요하다.
Going too broad, too fast — 한 번에 전사 확산하면 실패한다.
New bottlenecks — 의사결정 속도 — Clare의 가장 날카로운 관찰: “Frontier 팀은 코드를 짜는 시간보다 의사결정을 내리는 데 더 많은 시간을 쓴다.” 예전엔 개발이 9~~12개월이라 2개월짜리 검토가 병목이 아니었지만, 이제 개발이 1~~2개월로 줄면 그 2개월 검토가 병목이 된다. 프로덕트 결정·출시 승인 같은 전통적 게이트를 에이전트 속도에 맞게 재설계하지 않으면 전체 속도는 안 올라간다.

결론: “AI 네이티브로 가는 것은 도구를 도입하는 일이 아니라, 업무 방식을 바꾸는 일이며 시간이 걸리는 일이다. 모든 엔지니어뿐 아니라 조직 전체가 바뀌어야 한다.”

부록 — 실전 체크리스트

이 영상을 보고 다음 주부터 바로 적용할 수 있는 항목들이다.

내 팀의 스티어링/스킬 파일을 만든다. 에이전트가 실수할 때마다 “파일에 뭘 빠뜨렸나?”를 먼저 묻는다.
분기마다 프루닝 리뷰를 잡는다. 새 모델이 나온 뒤 불필요해진 규칙을 지워 컨텍스트 비대화를 막는다.
다음 스프린트를 Slow down to speed up 스프린트로 지정한다. 린터 에러 메시지 개선 + MCP/도구 신설 + 코드베이스 재구조화 중 하나를 선택해 투자한다.
언어 스택을 점검한다. 에이전트 친화성 관점에서 TypeScript 전환 같은 선택을 검토한다.
모든 작업을 Feeding 형식으로 넘긴다: 할 일 + 검증 방법 + 품질 기준(컴파일/테스트 통과/커버리지)을 한 프롬프트에 담는다.
기능 시작 전 Feature Specification(Objective/Use Cases/Key Functionality/Technical Requirements)을 에이전트와 함께 합의한다.
로컬 mock 서비스와 린터·단위/통합/성능/보안 테스트를 노트북에서 한 커맨드로 돌 수 있게 만든다.
병렬 에이전트 수에 상한을 둔다. 인지 부하·FOMAT를 팀 룰로 관리하고, 리뷰 역량은 주니어 멘토링으로 키운다.
배포·출시 의사결정 게이트를 지도화한다. 코드가 1개월 만에 준비돼도 2개월 검토가 병목이면 게이트를 먼저 줄인다.

원문 인용 모음

[00:24] “AI 기술에서 볼 수 없었던 생산성 향상이라는 놀라운 결과 — results of productivity increases that are step function improvements since what we’ve been seeing with AI so far.”
[00:42] “코드 자동 완성 기능이 있어서 다음 줄이나 다음 토큰을 제안하는 것부터 시작했습니다.”
[01:11] “하지만 현재 아마존 내부에서는 회사 내 여러 팀과 함께 시범 운영을 진행해 왔으며… 중간값 기준 4.5배, 많게는 10배 이상 향상되었습니다 — median of 4.5x productivity improvement and sometimes more than 10x.”
[02:29] “기반 팀이 작년 어느 시점에 Bedrock Mantle을 6명이 76일 만에 만들었습니다. 초기 예상은 30명이 18개월.”
[04:40] “Prime Video 팀은 6명을 한 방에 모아 10일간 Kiro를 마음껏 쓰게 했습니다. Senior가 3주간 작고 범위가 명확한 작업들을 분해했습니다.”
[06:10] “정상적인 경력 분포의 50개 팀을 brownfield 시스템에서 1년간 관찰했습니다.”
[07:10] “중요한 것은 도구가 아니라 일하는 방식이었다 — What matters is not the tool but the way of working.”
[08:14] “첫 번째 습관은 에이전트 컨텍스트에 투자하는 것입니다.”
[08:35] “머릿속 지식을 전부 글로 써야 했습니다 — We have a lot of stuff in our head.”
[09:11] “새 모델이 나올 때마다 ‘이게 내 스티어링 파일에 여전히 필요한가, 아니면 컨텍스트만 부풀리는가’ — do I still need this in my steering files or is this just bloating context?”
[10:40] “많은 팀들이 코드베이스를 재구성하고, TypeScript로 전환했습니다 — And so I’ve seen teams moving to TypeScript.”
[11:30] “30초에서 1분씩 화면을 쳐다보며 코드 생성을 기다리게 되죠 — You’re sitting there for 30 seconds to a minute waiting for it to generate code.”
[12:10] “특정 품질 기준을 충족할 때만 결과를 반환하라 — 코드가 실행·컴파일되고 테스트를 통과하며 높은 커버리지를 확보했을 때만.”
[12:24] “네 번째 습관은 의도를 명확히 밝히는 것입니다 — Habit 4: Make intent explicit.”
[13:49] “에이전트에게 빠른 피드백 루프를 주는 것이 핵심이다.”
[16:04] “여러 에이전트를 병렬로 실행할수록 인지 부하가 증가한다 — Cognitive load increases with number of parallel agents.”
[16:14] “주니어는 아직 그런 근육이 형성되지 않았다 — early career engineers don’t have that muscle yet and so reviewing can be harder than writing.”
[19:23] “지금 그것들이 바로 병목 현상이다 — 전체 시스템을 새로 짜는 데 한두 달밖에 안 걸리니, 2개월짜리 검토가 병목이 됐다.”
[19:40] “Frontier 팀은 코드를 짜는 시간보다 의사결정을 내리는 데 더 많은 시간을 쓴다 — frontier engineering teams spend more time making decisions than they do writing code.”

연결 메모 — frontier-development

이 노트의 Frontier development는 4단계 중 마지막 단계의 이름이자 운영 규율 전체를 가리킨다. 상세 정의·3경로 비교표·5습관 체크리스트·측정 지표·새 병목·Kiro의 spec-driven 구현은 개념 노트 frontier-development 에 모아 두었다. 반대로 개념 노트는 이 영상을 1차 출처로 하며, AWS 블로그(2026-06-11)·Kiro 주제 페이지·팟캐스트 교차 검증으로 보강했다. 함께 보면 좋은 짝: 2026-07-26-garry-tan-ai-native-company-brain(브레인 소유), 2026-08-30-imad-touil-ai-native-skills-governance(스킬 거버넌스), behavior-driven-development(의도 명문화), loop-engineering(루프 설계), harness·mcp(실행 환경).

description	AWS Clare Liguori가 아마존 50팀 관찰로 도출한 AI 네이티브 5가지 습관과 Frontier 개발의 단계함수적 생산성 조건을 정리한다.
tags	ai-agents, ai-coding, productivity, youtube

LLM Wiki

탐색기