같은 AI 도구를 썼는데 왜 어떤 팀은 10배까지 빨라졌을까 — Frontier Development의 다섯 습관

TL;DR

  • 같은 도구에서도 일하는 방식에 따라 성과가 크게 갈렸다.
  • Frontier 팀은 다섯 가지 습관으로 Agent의 자율성을 높였다.
  • 코드 다음 병목은 리뷰와 의사결정이었다.

시작하며

최근 CTS-SW 글을 정리하면서 AI 코딩 도구가 실제 전달 속도를 얼마나 바꾸는지 관련 자료를 찾아봤다.

사례마다 숫자의 편차가 꽤 컸다. 어떤 팀은 조금 빨라졌다고 하고, 어떤 팀은 몇 배에서 10배가 넘는 개선을 이야기한다.

그러다 같은 조직 안에서 이 차이가 왜 생겼는지를 꽤 구체적으로 설명하는 영상을 보게 됐다.

AWS Senior Principal Engineer Clare Liguori가 Amazon 내부 팀들을 관찰하면서 발견한 Frontier Development의 특징을 정리한 발표다.1

발표에는 30명이 18개월 동안 만들 것으로 예상한 시스템을 6명이 76일 만에 만든 사례부터, 기존 코드베이스를 운영하는 50개 팀을 비교한 결과까지 나온다.

같은 AI 도구를 사용한 팀들의 성과가 왜 크게 갈렸는지를 다섯 가지 습관으로 설명하는 부분이 특히 흥미로웠다.

1. AI 코딩은 네 번째 단계로 들어가고 있다

Clare는 AI 코딩의 흐름을 네 단계로 나눈다.

첫 번째는 다음 줄이나 함수를 제안하는 inline code completion이다.

두 번째는 코드에 관해 질문하고 답을 받는 chat이고, 세 번째는 높은 수준의 요구를 Agent와 대화하며 구현하는 Vibe Coding이다.

Clare 개인은 이 세 단계에서 체감한 생산성 향상이 대략 10~20% 정도였다고 말한다.

그리고 지금 막 시작된 네 번째 단계를 Frontier Development라고 부른다.

기존 단계에서는 사람이 한 줄, 한 함수, 한 번의 대화를 계속 제어했다. Frontier Development에서는 검증 방법까지 포함한 작업 전체를 Agent에게 넘긴다.

flowchart LR
    C1["1. Inline Completion<br/>다음 줄 · 함수"] --> C2["2. Chat<br/>코드에 대한 질문"]
    C2 --> C3["3. Vibe Coding<br/>대화로 구현"]
    C3 --> C4["4. Frontier Development<br/>작업 전체를 위임"]
    C1 -. "사람이 계속 제어" .-> C3
    C4 -. "Agent가 실행·검증" .-> OUT["검증된 결과"]

Clare는 Frontier Developer를 사용하는 제품이나 모델이 아니라 세 가지 행동으로 정의한다.

  1. 자신이 직접 작성하는 코드는 전체의 1~2% 정도다.
  2. Agent가 사람의 개입 없이 몇 시간씩 작업하게 만든다.
  3. 여러 Agent가 backlog를 병렬로 처리하게 해 idle time을 줄인다.

이 숫자는 모든 개발자가 따라야 할 기준이 아니다.

Amazon 내부에서 단계적인 생산성 향상을 보인 초기 사용자들의 행동을 설명하기 위한 정의에 가깝다.

발표는 이 정의에 오래 머무르지 않고, 실제 팀에서 이런 행동이 어떻게 나타났는지 세 가지 사례로 넘어간다.

2. 6명이 76일 만에 만들었지만, 그대로 믿을 수는 없었다

발표에서 처음 소개한 팀은 Bedrock Mantle 팀이다.

Bedrock 팀은 새로운 inference data plane이 필요하다고 판단했고, 처음에는 30명이 18개월 정도 걸릴 것으로 예상했다.

새 시스템을 만들고, 고객과 모델을 기존 시스템에서 옮겨야 하는 큰 작업이었다.

하지만 실제로는 6명이 Kiro를 사용해 76일 만에 만들었다.

Amazon 내부에서도 처음 보는 결과였고, commit을 기준으로 약 20배의 개선을 보인 Pathfinder 사례가 됐다.

문제는 이 6명이 평범한 팀이 아니었다는 점이다.

두 명의 Distinguished Engineer를 포함해 분산 시스템, LLM과 해당 아키텍처를 잘 아는 최상위 엔지니어들이었다. 기존 코드의 제약 없이 새 시스템을 처음부터 만들 수 있는 greenfield 프로젝트이기도 했다.

가능성을 증명하기에는 좋은 사례였지만, 다른 팀이 일상적인 환경에서 재현할 수 있는지는 알 수 없었다.

다음 실험은 Prime Video에서 진행됐다.

6명의 엔지니어가 10일 동안 Kiro를 제한 없이 사용했고, 진행 상황을 바탕으로 프로젝트 예상 기간을 90주에서 24주로 줄였다.

이번에는 Bedrock Mantle과 다른 엔지니어들이 비슷한 결과를 낼 수 있다는 것을 보여줬다.

하지만 이 실험에도 조건이 있었다.

팀은 당직과 회의가 거의 없었고, 평소 엔지니어를 방해하는 일이 제한됐다. 시니어 엔지니어 한 명은 실험 전에 3주 동안 작고 구체적인 태스크와 요구사항을 준비했다.

일상적인 개발팀이라기보다 Agent가 일하기 좋은 환경을 의도적으로 만든 sprint였다.

그래서 Amazon Stores는 더 현실적인 pilot을 진행했다.

경력 분포가 평범하고, 기존 시스템과 코드베이스를 운영하는 50개 팀을 상당 기간 관찰했다.

측정 기준도 commit 수가 아니라 변경이 운영 환경까지 전달되는 속도였다.

결과는 두 집단으로 갈렸다.

  • 절반은 배포 속도가 3배 미만으로 개선됐다.
  • 나머지 절반은 중앙값이 4.5배였고, 일부는 10배를 넘었다.

90%의 팀이 Kiro를 포함해 거의 같은 내부 도구를 사용했다.

도구가 주요 변수가 아니었다.

성과가 크게 오른 팀은 AI 도구를 기존 개발 방식 위에 추가하는 데서 끝나지 않고, 일하는 방식을 의도적으로 바꿨다.

세 사례는 화려한 결과를 하나 더 나열하기보다, 재현 가능한 조건을 좁혀가는 과정으로 볼 수 있다.

flowchart LR
    B["Bedrock Mantle<br/>6명 · 76일"] --> P["Prime Video<br/>6명 · 10일 sprint"]
    P --> S["Amazon Stores<br/>기존 시스템의 50개 팀"]
    B --> BC["최상위 전문가 · greenfield"]
    P --> PC["회의·당직 제한<br/>3주간 태스크 준비"]
    S --> L["절반: 3배 미만"]
    S --> H["절반: 중앙값 4.5배<br/>일부 10배 초과"]

발표의 숫자는 Amazon 내부 관찰을 공유한 것이며 원자료와 팀별 측정 방법이 모두 공개된 연구는 아니다.

따라서 4.5배를 다른 조직에서도 기대할 수 있는 수치로 받아들이기보다, 같은 도구를 사용한 팀 사이에서 차이를 만든 행동에 주목하는 편이 낫다고 생각한다.

3. Frontier 팀이 만든 다섯 가지 습관

Amazon은 Bedrock Mantle, Prime Video와 50개 pilot 팀을 인터뷰해서 공통된 다섯 가지 습관을 찾았다.

Clare가 practice보다 habit이라는 표현을 사용한 이유는 한 번의 특별한 sprint가 아니라, 매일 반복하는 일하는 방식이 결과를 만들었기 때문이다.

1) Agent Context에 투자한다

사람의 머릿속에는 문서에 없는 정보가 많다.

동료에게는 Slack 대화, 온보딩, 멘토링, 코드리뷰, 스탠드업과 스프린트 계획을 통해 전달한다. Agent에게는 이런 정보를 파일로 적어줘야 한다.

Frontier 팀은 Agent가 실수하거나 팀이 원하지 않은 방식으로 일할 때마다 아래 질문을 반복했다.

Agent가 필요했던 내용 중 Skill이나 Steering 파일에 빠진 것은 무엇인가?

잘못된 결과를 그 자리에서 한 번 고치고 끝내지 않고, 다음 실행에서도 사용할 컨텍스트로 남겼다.

반대로 컨텍스트를 계속 추가하기만 해서는 안 된다.

예전 모델의 특이한 행동을 막기 위해 넣었던 하지 말 것이 최신 모델에서는 필요 없을 수 있다. 오래된 workaround가 남아 있으면 Agent가 읽어야 할 컨텍스트만 늘어난다.

따라서 새로운 실패에서 규칙을 추가하는 습관과, 모델이 좋아졌을 때 필요 없어진 규칙을 지우는 습관이 함께 필요하다.

2) 빨라지기 위해 먼저 느려진다

인터뷰한 거의 모든 팀은 Frontier 방식으로 바꾼 초기에 생산성이 오히려 떨어졌다고 답했다.

특히 기존 코드베이스에서는 Agent에게 코딩 도구만 지급한다고 바로 빨라지지 않는다.

팀들은 먼저 Agent가 성공하기 좋은 환경을 만들었다.

  • 실패 이유를 알 수 있도록 기존 도구의 오류 메시지를 개선했다.
  • Agent가 필요한 작업을 수행할 수 있도록 새로운 도구와 MCP 서버를 만들었다.
  • Agent가 탐색하기 어려운 코드 구조를 정리했다.
  • 린터와 테스트를 보강했다.
  • 필요하면 타입과 컴파일러가 더 많은 피드백을 주는 언어로 옮겼다.

발표에서는 Python이나 JavaScript에서 TypeScript로 이동하거나, 컴파일러 오류가 구체적인 Rust를 선택한 사례도 나온다.

모든 팀이 언어를 바꿔야 한다는 이야기는 아니다.

Agent가 추측해야 하는 영역을 줄이고, 실패했을 때 무엇을 고쳐야 하는지 알려주는 피드백을 늘리기 위해 꽤 큰 엔지니어링 투자를 했다는 뜻이다.

3) Agent를 돌보지 말고 먹이를 준다

Clare가 가장 강조한 표현 중 하나는 feeding agents, not babysitting agents다.

Vibe Coding처럼 Agent와 하루 종일 짧은 대화를 주고받으면 사람은 계속 루프 안에 있다.

Agent가 코드를 만드는 30초에서 1분 동안 기다리고, 결과를 검토한 뒤 다시 지시한다. 이 방식으로는 여러 Agent를 병렬로 실행하기 어렵다.

Frontier 팀은 Agent에게 아래 내용을 먼저 제공했다.

  • 무엇을 해야 하는가
  • 어떤 제약을 지켜야 하는가
  • 무엇으로 스스로 검증해야 하는가
  • 어느 품질 기준을 만족해야 돌아올 수 있는가

Agent가 코드를 실행하고, 컴파일하고, 테스트와 coverage를 확인한 뒤 품질 기준을 만족할 때만 돌아오게 만든다.

반복되는 지시는 Steering 파일에 넣어서 다음 작업부터는 별도로 설명하지 않는다.

이렇게 해야 Agent가 실패를 스스로 수정하고, 사람은 기다리는 대신 다른 일을 하거나 다른 Agent를 실행할 수 있다.

4) 코드를 만들기 전에 의도를 명시한다

일반적인 Vibe Coding에서는 높은 수준의 프롬프트를 주고 많은 코드를 만든 뒤, 결과를 보면서 의도를 수정한다.

"내가 원한 건 이게 아니야", "요구사항을 잘못 이해했어", "이런 구조를 원한 게 아니야"라는 대화가 코드가 만들어진 뒤에 이어진다.

Clare는 의도 자체가 잘못된 상태에서 코드로 대화하는 것이 비효율적이라고 설명한다.

Amazon 팀들은 복잡하거나 모호한 기능일수록 BDD(Behavior-Driven Development) 형태의 specification을 먼저 만들었다.

사람이 문서를 처음부터 모두 작성하는 것은 아니다.

Agent가 specification 초안을 만들고, 사람과 Agent가 코드보다 수정하기 쉬운 문서 위에서 요구사항과 기술 설계를 조정한다. 의도가 맞춰진 뒤에 코드를 생성한다.

5) 테스트를 왼쪽으로 옮긴다

Agent가 사람의 개입 없이 몇 시간 동안 일하려면 빠른 피드백이 필요하다.

Agent는 실수해도 괜찮다. 실패를 바로 확인하고 스스로 수정할 수 있어야 한다.

Frontier 팀은 린터, unit test, integration test, performance test와 security test를 추가했다.

모두 이전부터 좋다고 알려진 엔지니어링 관행이다. 달라진 점은 투자수익이다.

테스트 하나를 추가하면 이후 모든 Agent의 재시도 루프에서 반복해서 사용된다. 코드베이스를 기계가 읽고 고치기 좋은 형태로 만드는 투자의 가치가 커졌다.

특히 여러 팀이 외부 서비스를 로컬의 결정적인 mock으로 바꾸는 데 투자했다.

매번 클라우드 서비스와 실제 환경을 연결하면 피드백이 느리고 결과가 흔들릴 수 있다. 로컬에서 같은 입력에 같은 응답을 받으면 Agent는 짧은 시간에 더 많은 수정 루프를 돌 수 있다.

다섯 습관을 하나의 흐름으로 묶으면 아래처럼 볼 수 있다.

flowchart LR
    subgraph BABY["Agent를 계속 돌보는 방식"]
        P["짧은 프롬프트"] --> W["Agent 결과를 기다림"]
        W --> C["사람이 오류·의도를 수정"]
        C --> P
    end

    subgraph FEED["Agent에게 필요한 것을 주는 방식"]
        I["명시한 의도·컨텍스트"] --> A["Agent 작업"]
        T["도구·로컬 테스트"] --> A
        A --> V{"스스로 검증"}
        V -->|실패| A
        V -->|통과| R["검증된 결과 반환"]
    end

4. Frontier Development도 사람을 힘들게 한다

Clare는 다섯 습관을 적용하면 모든 문제가 해결된다고 말하지 않는다.

아직 초기 도입 단계이고, 팀들도 새로운 일하는 방식을 배우는 중이다.

먼저 burnout 위험이 있다.

밤새 실행될 완벽한 프롬프트를 만들기 위해 늦게까지 일하고, 아침에 완성된 코드가 나오기를 기대하는 엔지니어들이 생긴다.

여러 Agent를 병렬로 실행하면 terminal tab 사이를 계속 이동해야 한다. 구현 중에 줄어든 인지부하가 Agent의 상태를 관리하고 결과를 검토하는 쪽으로 이동한다.

AI가 만든 코드를 리뷰하는 일이 직접 작성하는 것보다 어렵게 느껴질 수도 있다.

특히 다른 사람의 코드를 검토한 경험이 적은 초기 경력 엔지니어는 작성보다 리뷰에서 더 큰 인지부하를 느낄 수 있다.

조직도 바뀌어야 한다.

팀이 코드베이스와 도구를 정비하고 새로운 습관을 만드는 동안에는 생산성이 먼저 떨어질 수 있다.

그런데 리더가 "좋은 AI 도구를 줬는데 왜 더 빨라지지 않는가"라고 묻고 이전과 같은 기능 출시량을 계속 요구하면, 팀은 이 선행 투자를 할 수 없다.

Clare는 팀이 코드베이스와 일하는 방식을 바꾸는 데 두 달 정도를 투자해야 할 수도 있다고 말한다.

전사에 너무 빨리 확산하는 것도 위험하다.

Amazon은 Pathfinder 한 팀의 결과를 곧바로 모든 팀에 적용하지 않았다. 제한된 sprint와 50개 팀 pilot을 통해 습관과 제약을 찾았고, 이제 다음 2,000개 팀으로 확장하는 문제를 다루고 있다.

5. 코드 다음에는 의사결정이 병목이 된다

발표의 마지막에는 Frontier 팀이 새롭게 만난 병목이 나온다.

예전에는 새로운 제품의 코드를 만드는 데 9~12개월이 걸렸다.

제품을 만들지 결정하는 데 두 달, 출시를 승인하는 데 두 달이 걸려도 전체 일정에서는 상대적으로 덜 두드러졌다.

그런데 코드 작성이 1~2개월로 줄면 앞뒤의 두 달이 가장 긴 단계가 된다.

Clare는 Frontier 팀이 코드를 작성하는 시간보다 의사결정에 더 많은 시간을 쓰는 경우가 많다고 말한다.

같은 과정을 기존 개발과 Frontier Development에 놓으면 병목의 이동이 더 잘 보인다.

flowchart LR
    subgraph BEFORE["기존 개발"]
        BD["제품 결정<br/>약 2개월"] --> BC["코드 작성<br/>9~12개월"]
        BC --> BL["출시 승인<br/>약 2개월"]
    end

    subgraph AFTER["Frontier Development"]
        AD["제품 결정<br/>약 2개월"] --> AC["코드 작성<br/>1~2개월"]
        AC --> AL["출시 승인<br/>약 2개월"]
    end

    BC -. "가장 긴 단계" .-> AC
    AD -. "새 병목" .-> AL

코드 생성이 빨라지면서 아래 과정이 새로운 병목으로 드러난다.

  • 어떤 제품을 만들지 결정한다.
  • 제품과 기술 설계를 검토한다.
  • 보안과 운영 조건을 확인한다.
  • 출시를 승인한다.

특히 쉽게 되돌릴 수 있는 결정까지 오래 검토하면, 코드가 빨라진 효과를 조직의 의사결정이 흡수해버린다.

그래서 Clare가 발표에서 남긴 가장 큰 메시지는 특정 프롬프트나 도구 사용법이 아니다.

Frontier Development는 AI 도구를 추가하는 일이 아니라, 팀과 조직이 일하는 방식을 의도적으로 바꾸는 일이다.

6. 조직에 적용하려면 현재 상태부터 확인한다

발표를 보고 나니 우리 조직에 적용할 때 무엇부터 확인해야 하는지가 남았다.

아래는 발표 요약이 아니라 기존에 쓴 글들을 바탕으로 정리한 내 제안이다.

현재 업무의 기준선을 만든다

먼저 AI 도구 사용률이나 생성한 코드의 양을 보지 않는다.

한 팀의 한 업무를 골라 요구사항이 운영 환경에 도달하기까지의 흐름을 펼친다.

  • 요구사항을 정하는 데 얼마나 걸리는가
  • 구현과 리뷰에서 사람이 어디에 개입하는가
  • CI와 배포에서 얼마나 기다리는가
  • 재작업, rollback과 장애 대응이 얼마나 발생하는가
  • Agent가 일을 끝내는 데 필요한 데이터, 도구와 권한이 있는가

도입 전 기준선이 없으면 코드 생성에서 줄어든 시간이 리뷰나 운영으로 이동해도 알아차리기 어렵다.

한 팀에서 연결하고, 실패를 하네스로 바꾼다

그다음 Agent가 업무를 끝까지 수행하는 데 필요한 컨텍스트, 도구, 권한과 검증 기준을 연결한다.

처음부터 여러 Agent와 여러 팀으로 넓히기보다, Agent 하나가 작은 작업 하나를 사람 없이 끝내는 것부터 확인하는 편이 낫다고 생각한다.

Agent가 같은 실수를 반복하면 프로젝트 규칙에 남긴다. 필요한 일을 못 하면 CLI, Skill이나 MCP를 연결한다. 실패를 스스로 발견하지 못하면 린터와 테스트를 추가한다.

이 과정을 실제 프로젝트에 적용한 순서는 실전 하네스 엔지니어링 글에 정리해뒀다.2

조직 단위에서는 이 흐름을 세 단계로 나눠볼 수 있다.3

  • 먼저 업무 경계와 데이터·도구·권한을 연결한다.
  • 한 팀의 pilot에서 실패와 리뷰 피드백을 하네스로 바꾼다.
  • 검증된 방식을 다른 팀과 요구사항에 재사용한다.
flowchart LR
    B["현재 상태<br/>업무 경계 · 기준선"] --> S1["업무 연결<br/>컨텍스트 · 도구 · 권한"]
    S1 --> S2["한 팀에서 학습<br/>실패를 하네스로 반영"]
    S2 --> S3["검증된 방식 확산<br/>다른 팀과 업무에 재사용"]

    B --> BM["Lead Time · 리뷰 대기<br/>CI · 장애 · 사람 개입"]
    S2 --> M1["반복 실패 감소<br/>자율성 · 검증 증거 · 신뢰성"]
    S3 --> M2["전체 전달 비용<br/>고객 가치 · 재사용 · 신뢰성"]

단계에 따라 다른 효과를 확인한다

초기 pilot에 바로 비용 절감과 비즈니스 성과를 요구하면, 영상에서 말한 slow down to speed up 구간을 실패로 판단하기 쉽다.

한 팀에서 학습하는 동안에는 같은 실패가 다시 발생하는지, 사람이 모든 코드를 다시 읽어야 하는지, 정상 경로를 Agent가 스스로 닫는지 확인한다.

검증된 방식을 확산할 때는 질문이 달라진다.

요구사항이 고객에게 도달하는 시간이 줄었는지, 같은 품질을 유지하면서 개발·리뷰·운영을 포함한 전체 비용이 낮아졌는지, 앞선 투자가 다른 업무에도 재사용되는지 본다.

이 두 단계에서 확인할 질문은 별도 글에 조금 더 자세히 정리해뒀다.4 CTS-SW는 고객에게 도달한 소프트웨어 한 단위의 전체 전달 비용을 보는 출발점으로 사용할 수 있다.5

영상의 50개 팀 사례는 일하는 방식을 바꾸면 배포 속도가 크게 달라질 수 있다는 것을 보여준다.

조직에 적용한 뒤에는 여기서 한 단계 더 나아가, 빨라진 배포가 전체 전달 비용과 고객 가치의 개선으로 이어졌는지 확인해야 한다.

토큰 가격이 내려갈 때까지 기다리면 늦는다

발표에서 제안한 방식으로 일하려면 평소에도 토큰이 계속 들어간다.

코드 수정과 테스트뿐 아니라, 작업에서 얻은 내용을 컨텍스트·도구·테스트에 반영하고 오래된 규칙을 걷어내는 하네스 관리에도 토큰이 필요하다.

이 비용은 도입 초기에만 발생하는 실험비가 아니라, 워크플로우를 유지하고 개선하는 운영비에 가깝다.

최근 연구들을 보면 같은 수준의 성능을 얻는 가격은 빠르게 낮아지고 있다. 측정 방법에 따라 하락 속도의 차이는 크고, 긴 reasoning을 사용하는 최상위 작업의 총비용은 오를 수도 있지만 가격 하락 추세는 여러 자료에서 공통적으로 나타난다.678

가격만 내려가는 것도 아니다. Agent가 안정적으로 끝낼 수 있는 소프트웨어 작업의 길이도 빠르게 늘고 있다.9

이 연구들이 토큰당 비즈니스 가치를 직접 측정한 것은 아니다. 그래도 같은 성능을 더 싸게 얻고, 모델이 더 긴 작업을 끝내게 되면서 주어진 토큰 예산으로 전달할 수 있는 비즈니스 가치는 커지는 방향이라고 생각한다.

최근 추세를 그대로 외삽할 수는 없지만, 2~3년 뒤 같은 작업 비용이 지금보다 수십 배 낮아지는 경우도 워크플로우를 설계할 때 고려할 만한 시나리오다.

가격이 충분히 낮아진 뒤에야 전환을 시작하면, 이미 몇 년 동안 컨텍스트·도구·테스트와 조직의 습관을 쌓아온 팀을 따라가기 어렵다. 토큰 가격은 빠르게 내려갈 수 있지만 조직의 일하는 방식은 같은 속도로 바뀌지 않기 때문이다.

마치며

이 발표를 Kiro로 10배 빨라지는 방법으로 요약하면 중요한 내용을 놓치게 된다.

같은 도구를 사용했지만 성과가 크게 오른 팀은 컨텍스트, 도구, 의도와 테스트를 함께 고쳤다. 그 과정에서 당장의 기능 출시가 느려지는 것도 받아들였다.

그렇다고 무한한 토큰을 전제로 해야 한다는 뜻은 아니다. 다만 코드 수정과 재시도, 하네스 업데이트에 들어가는 토큰을 일회성 실험비가 아니라 운영비로 받아들여야 한다.

토큰 가격은 내려가고, 같은 예산으로 모델이 끝낼 수 있는 작업의 범위는 넓어지고 있다. 충분히 저렴해질 때까지 기다렸다가 조직의 일하는 방식을 바꾸기 시작하면 늦을 수 있다.

그래서 현재의 토큰 단가만 보고 매 작업을 최적화하기보다, 앞으로 3년의 예상 토큰 단가와 사용량, 토큰 예산당 전달할 비즈니스 가치, 그동안 축적할 하네스를 함께 전제로 워크플로우를 설계해야 한다고 생각한다.

  1. Clare Liguori, From AI-Assisted to AI-Native: Building a Frontier Development Team (2026). Amazon 내부 Pathfinder, sprint 실험과 50개 팀 pilot, Frontier 팀의 다섯 습관을 소개한 발표다. ↩

  2. EncBird에 하네스를 한 겹씩 씌워온 과정 — 반복되는 실수를 컨텍스트, 도구, 테스트와 가드레일로 옮기는 구체적인 순서를 다룬다. ↩

  3. AI 도입은 왜 토큰 절감부터 시작하면 안 될까 — 3S로 단계 나누기 1/2 — 현재 상태를 연결·학습·확산 단계로 나눠 조직에 적용하는 방법을 설명한다. ↩

  4. AI 도입 성과는 언제 비즈니스 지표로 봐야 할까 — AHEAD·LEVER 다시 보기 2/2 — 하네스 학습과 전체 전달 비용·가치 회수를 단계별로 평가하는 질문을 정리한다. ↩

  5. AI 코딩 도구가 정말 개발 비용을 줄였을까 — CTS-SW 시작하기 — 고객에게 도달한 소프트웨어와 개발·리뷰·운영 비용을 연결하는 방법을 다룬다. ↩

  6. Stanford HAI, AI Index 2025: State of AI in 10 Charts — GPT-3.5 수준의 MMLU 성능을 얻는 가격이 약 18개월 동안 280배 이상 낮아졌다고 정리한다. ↩

  7. Epoch AI, LLM inference prices have fallen rapidly but unequally across tasks — 성능 수준을 고정했을 때 benchmark별 가격 하락 속도와 측정상의 한계를 분석한다. ↩

  8. Hans Gundlach et al., The Price of Progress: Price Performance and the Future of AI — reasoning token을 포함한 benchmark 실행 비용으로 품질 조정 가격과 최상위 평가 비용을 분석한다. ↩

  9. METR, Time Horizon 1.1 — Agent가 일정 신뢰도로 완료할 수 있는 작업 길이와 최근 추세를 업데이트한다. ↩

  • #ai
  • #agent
  • #frontier-development
  • #harness-engineering
  • #organization
  • #developer-experience
  • #kiro