정의
Frontier development(프론티어 개발) 는 AI를 자동완성·채팅 보조가 아니라 소프트웨어를 만드는 기반(foundation) 으로 놓고, 인간 전문가가 에이전트에게 방향을 주면 에이전트가 계획 → 실행 → 검증을 자율적으로 수행하는 개발 방식이다. AWS가 “frontier teams”라 부르는 팀들이 쓰는 운영 규율이며, 2026-08-30-clare-liguori-ai-native-five-habits가 아마존 50팀 관찰로 체계화했다.
핵심 한 줄: 같은 Kiro를 써도 3배와 10배로 갈리는 이유는 도구가 아니라 일하는 방식 — 코드를 빨리 짜는 팀보다 결정을 빨리 내리는 팀이 이긴다.
AI 개발 지원의 4단계 진화
Clare Liguori가 정리한 진화사 — 앞 3단계까지는 체감 10~20%, 마지막 단계에서만 단계함수적 도약이 나타났다.
| 단계 | 방식 | 인간의 역할 | 체감 생산성 |
|---|---|---|---|
| 1 | Inline code completion | 다음 줄 승인 | 10~20% |
| 2 | Ask questions about my code | 코드에 대해 질문 | 10~20% |
| 3 | Vibe coding | 프롬프트로 즉흥 코딩, 반복 보정 | 10~20% |
| 4 | Frontier development | 목표·의도·품질 바를 주고 에이전트가 자율 루프 | 미디어 4.5배, 일부 10배+ |
AWS 블로그 정식 표현: “Frontier teams are not just using AI to code faster. They’re redesigning how software gets built.” — frontier는 모델의 최전선이 아니라 워크플로우의 최전선이다.
세 가지 경로 — 같은 통찰로 수렴
아마존은 서로 다른 구조의 실험 3개를 돌렸고, 결론은 같았다: 도입이 아니라 재설계가 조건이다.
| 경로 | 팀·조건 | 과제 | 결과 | 한계·전제 |
|---|---|---|---|---|
| Pathfinder | Bedrock Mantle, 6명(디스팅귀시드 2명 포함) | Bedrock 추론 데이터 플레인 신규 구축(원래 30명·18개월 예상) | 76일에 완수 — 86% 빠름, 80% 적은 인원, 커밋 2→40/주(20배) | 최정예·그린필드 |
| Structured Sprint | Prime Video Finance, 6명·10일간 한 방·외부 차단 | 90주 예상 프로젝트 | 24주로 단축(6배 throughput, 4배 가속, 556 vs 96 커밋) | 시니어 3주간 사전 작업 분해, on-call·미팅 제거 |
| In-situ Pilot | Amazon Stores 50팀, 경력 정상분포·brownfield | 기존 백로그 그대로 | 미디어 4.5배(일부 10배+) — 절반은 <3배에 머뭄 | 측정 지표는 deployment velocity |
Stores 파일럿이 결정적이다 — 90%가 같은 Kiro를 썼는데도 절반은 <3배, 절반은 4.5배+였다. 갈림길은 sprinkle on top vs intentionally change the way of working였다.
Prime Video 팀은 이득을 세 배수의 곱으로 분해했다: (1) 저판단 업무 가속 1.5배 × (2) 컨텍스트 스위칭 제거로 고판단 집중 1.5배 × (3) 에이전트에 포착된 도메인 전문성 즉시 접근 1.5배 = 3.375배. 하나라도 빠지면 무너진다.
5가지 습관 — 도약의 충분조건
도구는 필요조건, 습관이 충분조건이다. 매일 반복되는 규율이라 “habits”라 부른다.
| # | 습관 | 한 줄 | 실천 |
|---|---|---|---|
| 1 | Invest in agent context | 머릿속 암묵지를 글로 옮겨 에이전트가 참조하게 한다 | 스티어링/스킬 파일에 컨벤션·코딩 표준·테스트·코드베이스 탐색법을 명문화. 실수할 때마다 “파일에 뭘 빠뜨렸나?” — 모델이 좋아질수록 불필요해진 규칙은 pruning(Sonnet 3.7→Opus 4.5 이후 가지치기 필수) |
| 2 | Slow down to speed up | 가속을 위해 2개월 감속을 감수한다 | 에러 메시지 개선(모델이 실패를 이해하도록) + 도구·mcp 서버 신설 + 코드베이스 재구조화 + 언어 전환(타입 없는 Python/JS → TypeScript/Rust) — 아마존 팀 전체가 이 구간을 거쳤다 |
| 3 | Feed agents, don’t babysit | 돌보지 말고 한 번에 먹여라 | 할 일 + 검증 방법 + 품질 기준(컴파일/테스트 통과/커버리지)을 한 프롬프트에 담아 에이전트가 30분~수시간 자율 보정하게 한다. 병렬 에이전트·비동기 리뷰가 가능해진다 — harness 검증 루프와 짝 |
| 4 | Make intent explicit | 코드 전에 의도를 합의한다 | [[behavior-driven-development |
| 5 | Shift testing left | 테스트를 앞단으로 당겨 빠른 로컬 피드백을 준다 | 린터·mock 서비스·unit/integration/performance/security 테스트를 노트북에서 한 커맨드로 돌게 한다. 클라우드 의존 없이 에이전트가 스스로 고칠 수 있는 신호를 준다 |
Kiro가 5습관을 제품에 내장한 방식: 자연어 → 구조화된 요구사항·수락 기준·아키텍처·의존성 순 작업 분해 → 스티어링 파일·에피소드·학습 패턴 3층 메모리 → property-based 테스트로 의도 대비 검증. 이는 loop-engineering의 “정지 조건·작성자/검사자 분리·상태 외부화” 원칙과 겹친다.
Spec-driven / BDD와의 관계
Frontier development는 vibe coding(“프롬프트 → 코드 생성 → 왔다갔다 수정”)과 대비된다. 의도가 틀렸을 때 코드 반복은 가장 비싼 반복이다. 아마존식 해법은 문서에서 먼저 합의하는 것이다 — behavior-driven-development의 Given-When-Then이 바로 이 “실행 가능한 명세” 역할을 하며, Kiro는 이를 자동 생성하되 인간이 의도를 검증한 뒤에 구현을 시작한다.
측정 — 무엇으로 도약을 판정하는가
- 이전: 커밋 수·개인 체감
- Frontier 이후: production deployment velocity(프로덕션 배포 속도), normalized commit velocity(repo 복잡도·팀 규모 정규화), features deployed per sprint(과거 대비 정규화), lines deployed to production. Perfect Order Experience는 2주→반나절, WW Grocery는 설계 문서 5일→수시간으로 단축됐다.
새로 생기는 병목 — 코드가 병목이 아니게 된 뒤
코드 작성이 912개월→12개월로 줄자, 기존엔 반올림 오차였던 것이 병목이 됐다.
- 의사결정 속도: “Frontier teams spend more time making decisions than writing code.” — 되돌릴 수 있는 결정은 빠르게. 2개월짜리 검토 게이트가 전체 리드타임을 지배한다.
- 출시 승인 게이트: 전통적 릴리즈 리뷰·거버넌스를 에이전트 속도에 맞게 재설계해야 전체 속도가 올라간다.
- 조직 확산: 한 번에 전사 확산하면 실패 — pathfinder → sprint → 50팀 → (2026년) 2,000팀으로 단계적 확장, 2개월 습관 형성 기간 필요.
아직 어려운 것
- Burnout·FOMAT(Fear Of Missing Agent Time): 밤새 도는 에이전트를 놓칠까 늦게까지 프롬프트를 다듬는 두려움
- 인지 부하: 병렬 에이전트 수만큼 터미널 탭·상태 추적 부하 증가
- 리뷰 난도: AI 출력을 검증하는 게 직접 쓰는 것보다 어렵다 — 특히 주니어는 리뷰 근육이 아직 없다(2026-08-22-code-review-intent-verification 관점)
관련 노트
- 2026-08-30-clare-liguori-ai-native-five-habits — 본 개념의 1차 출처(영상·AWS 블로그·Kiro 주제 페이지 종합)
- 2026-07-26-garry-tan-ai-native-company-brain — 같은 무대의 ‘브레인은 소유’ — 스킬 파일을 직원으로 보는 관점, 습관 1의 전제
- 2026-08-30-imad-touil-ai-native-skills-governance — 같은 AI Engineer World’s Fair, 스킬의 점진적 공개·중앙 거버넌스 — 습관 1·4의 조직 확장판
- behavior-driven-development — 습관 4·5의 방법론적 뿌리(CD Pipeline·Device Farm·godog 사례 포함)
- loop-engineering — 습관 3·5를 운영 루프(정지 조건·검증·핸드오프)로 설계하는 상위 개념
- harness — 에이전트 실행을 감싸는 scaffolding — feeding·shift-left가 동작하는 런타임 경계
- mcp — 습관 2의 도구 신설 레이어 — 에이전트가 실제 작업을 수행하도록 하는 프로토콜
- burnout-flow-matrix — 병렬 에이전트 시대의 번아웃 진단 프레임
- moc-ai-agents · moc-ai-coding · moc-ai-agents-harness
출처
- Clare Liguori, From AI-Assisted to AI-Native: Building a Frontier Development Team — AI Engineer World’s Fair 2026 (영상 https://www.youtube.com/watch?v=Ry0WHNxDbYA, 20:28)
- Swami Sivasubramanian, How frontier teams are reinventing AI-native development — AWS Machine Learning Blog, 2026-06-11
- Kiro, Frontier teams & spec-driven development — https://kiro.dev/topics/frontier-teams/
- Finance BigGo 팟캐스트 요약 — Bedrock Mantle/Prime Video/Stores 3사례·5습관 상세