코드 생성이 빨라져도 개발팀이 빨라지지 않는 이유

코드는 빨라졌는데 생산성은 그대로다

개발팀에 코딩 agent 를 도입한 뒤 자주 듣는 말이 있습니다. 코드는 확실히 빨리 나오는데, 팀 전체의 생산성은 체감이 안 된다는 것입니다. 이 글은 그 간극이 어디서 생기는지, 그리고 그 간극을 메운 회사들은 무엇을 바꿨는지를 정리한 글입니다.

출발점은 한 가지 관찰입니다. AI 로 구현 비용이 내려가면, 한 엔지니어가 책임지는 문제와 결정의 범위가 넓어집니다. 예전에는 기획·설계·구현·검증·배포가 여러 사람에게 나뉘어 있었지만, 구현이 싸지면서 한 사람이 문제 발견부터 동작하는 시스템까지 맡아서 진행할 수 있게 됐습니다.

이 변화에 맞는 엔지니어의 일하는 방식을 저는 product engineer 라고 부릅니다. 모든 software engineer 의 직무명이 product engineer 로 바뀐다는 뜻이 아닙니다. 더 많은 software engineer 가 product engineer 처럼 문제의 결과까지 책임지는 방향으로 바뀐다는 뜻입니다.

글은 세 부분으로 이어집니다. 먼저 요즘 회사들이 AI 와 어떻게 협업하는지 네 회사의 사례를 보고, 다음으로 일하는 방식과 역할이 어떻게 바뀌는지를 loop 라는 틀로 정리하고, 마지막으로 그에 따라 엔지니어에게 필요한 역량과 성장 방향을 다룹니다.

---

Part 1. 요즘 회사들은 AI 와 어떻게 협업하는가

네 회사의 현장

Uber 는 PR 의 70% 이상에 local 또는 cloud agent 가 관여합니다. 코드 작성만이 아니라 review, CI, debugging, maintenance 까지 agent 가 맡습니다. 개별 코드베이스만 봐서는 agent 가 시스템 전체의 맥락을 알 수 없기 때문에, 24M 개의 node 와 80M 개의 edge 로 된 context graph 를 구축해 agent 가 시스템 맥락 안에서 판단하도록 지원합니다.

OpenAI 는 직무와 상관없이 coding 을 합니다. product·marketing·ops 인력의 Codex 사용 중 25% 가 engineering 작업이고, finance·bizops 인력은 31% 가 engineering 작업입니다. 엔지니어와 연구 조직은 1시간 이상 걸리는 장기 작업과 병렬 agent 작업을 일상적으로 돌립니다. 복잡한 작업에서는 바로 구현시키지 않고, 현재 시스템과 코드의 context 를 이해시킨 뒤 architecture 와 implementation plan 초안을 쓰고, AI 와 대안과 trade-off 를 논의해 architecture 를 확정한 다음에 구현합니다.

Naver 는 AI 에게 코드 작성을 맡기고, Playwright 기반의 e2e verification harness 를 만들어 agent 가 테스트에 실패하면 스스로 수정하는 loop 를 돌립니다. agent 에게 조직과 서비스의 context 를 제공하는 context provider 를 만들었고, 경험·규칙·기억을 축적하는 agent framework 로 확장하고 있습니다. 여기서 엔지니어의 역할은 좋은 코드를 직접 작성하는 것에서, agent 가 좋은 코드를 작성할 수 있는 환경을 구축하는 것으로 옮겨갑니다.

우아한형제들은 deterministic rules 와 skills 를 적용합니다. 엔지니어링 표준과 컨벤션을 agent 환경에 주입해서 결과를 제어할 수 있는 workflow 를 설계했고, 화면 너머 비즈니스까지 내다보는 Product Engineer 를 지향합니다.

사례가 공통으로 답하는 세 질문

네 사례는 모두 대기업이지만, 회사 크기가 핵심은 아닙니다. 네 회사가 각자 답한 질문을 나란히 놓으면 세 개로 모입니다.

• Context — agent 에게 조직과 시스템의 맥락을 어떻게 줄 것인가. Uber 의 context graph 와 Naver 의 context provider 가 이 질문의 답입니다.
• Verification — agent 의 결과를 어떻게 믿을 것인가. Naver 의 e2e harness 와 우아한형제들의 rules·skills 기반 deterministic workflow 가 이 질문의 답입니다.
• Delegation — 사람과 agent 사이에 일을 어떻게 나눌 것인가. OpenAI 의 장기 병렬 agent 작업이 이 질문의 답입니다.

flowchart LR
    U["Uber<br/>context graph"] --> QC["Context<br/>agent 에게 맥락을 어떻게 줄 것인가"]
    N1["Naver<br/>context provider"] --> QC
    N2["Naver<br/>e2e harness"] --> QV["Verification<br/>agent 의 결과를 어떻게 믿을 것인가"]
    W["우아한형제들<br/>deterministic rules · skills"] --> QV
    O["OpenAI<br/>장기 · 병렬 agent 작업"] --> QD["Delegation<br/>사람과 agent 사이에 일을 어떻게 나눌 것인가"]
    style U fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style N1 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style N2 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style W fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style O fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style QC fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style QV fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style QD fill:#fef3c7,stroke:#f59e0b,color:#1f2937

세 질문은 10명 규모의 팀에도 그대로 적용됩니다. 규모가 작으면 답의 형태가 context graph 대신 잘 정리된 CLAUDE.md 한 장이 되고, e2e harness 대신 테스트 스크립트 몇 개가 될 뿐입니다. 답의 크기는 달라도 질문은 같습니다.

AI 를 쓰면 생산성은 무조건 오르는가

코드 생성 속도와 생산성은 다른 것입니다. 코드는 빠르게 만들 수 있지만, 생산성이 올라가지 않을 수 있습니다. 빨리 만든 코드를 검증하는 시간, 리뷰를 기다리는 시간, 잘못 만든 것을 되돌리는 시간이 그대로면 총 소요 시간은 크게 줄지 않기 때문입니다.

차이는 software engineering loop 를 재설계했는지 여부에서 납니다. 네 회사가 바꾼 것도 코드 작성 도구가 아니라 코드가 만들어지고 검증되고 배포되는 순서와 구조였습니다. 이어서 그 loop 가 어떻게 바뀌는지를 살펴보겠습니다.

---

Part 2. 일하는 방식과 역할의 변화

AI 등장 전과 후

AI 등장 전에도 일하는 방식은 하나가 아니었습니다. 대기업과 전통 조직에서는 architect 가 architecture 를 결정하고 software engineer 가 구현하는 분업이 일반적이었습니다. 테크 기업과 스타트업에는 staff engineer, product engineer 처럼 설계와 구현을 한 사람이 함께 수행하는 역할이 이미 있었습니다.

AI 가 바꾼 것은 구현 비용만이 아닙니다. 시스템을 탐색하고, architecture 를 검토하고, 설계를 고도화하는 비용도 함께 내려갔습니다. 그래서 architecture 초안을 만들고 AI 와 논의하며 고도화한 뒤 확정하고 구현하는 방식이 가능해졌습니다.

다만 architecture A 와 B 를 모두 구현해 보고 고르는 방식이 일반적인 것은 아닙니다. 필요한 경우 불확실성이 높은 일부만 prototype 이나 spike 로 검증합니다. 그리고 구현 context 를 가장 많이 가진 엔지니어가 architecture 논의와 검증에 직접 참여하게 됩니다.

flowchart LR
    B1["AI 등장 전 · 대기업의 분업<br/>architect 가 architecture 를 결정한다"] --> B2["software engineer 가<br/>구현한다"]
    A1["AI 등장 후 · 한 엔지니어의 loop<br/>엔지니어가 architecture 초안을 쓴다"] --> A2["AI 와 대안 · trade-off 를<br/>논의해 고도화한다"]
    A2 --> A3["불확실한 일부만<br/>spike 로 검증하고 확정한다"]
    A3 --> A4["AI 와 함께<br/>구현한다"]
    style B1 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style B2 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style A1 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style A2 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style A3 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style A4 fill:#dcfce7,stroke:#22c55e,color:#1f2937

변하지 않은 것과 변한 것

소프트웨어의 원리는 그대로입니다. 경계, 데이터, 상태, 인터페이스, 의존성, 분산 시스템의 제약은 AI 가 있어도 없어지지 않습니다. 변한 것은 이 원리를 탐색하고 적용하고 검토하고 수정하는 비용과 속도입니다.

이 차이를 일하는 방식 단위로 정리하면 다음과 같습니다.

마지막 행이 이 표의 결론입니다. 산출물이 코드가 아니라 동작하는 시스템 전체가 되면, 한 사람이 책임지는 범위는 자연스럽게 검증과 배포와 운영 관찰까지 넓어집니다.

AI-native 개발팀과 개인 loop

AI-native 개발팀은 문제를 발견한 사람이 agent 와 함께 동작하는 시스템까지 직접 만들고 검증하며, 팀은 그 loop 가 빠르고 안전하게 돌도록 context 와 guardrail 을 함께 설계하는 조직입니다.

이 정의에서 개인의 일은 하나의 loop 입니다. Discover 에서 문제를 발견하고, Design 에서 현실의 문제를 기술적 설계와 architecture 초안으로 바꾸고 AI 와 대안과 trade-off 를 논의해 확정합니다. Build 에서 AI 와 함께 구현하고, Verify 에서 테스트 생성부터 실행, 실패, 수정, 전체 통과까지 이어지는 AI workflow 를 설계하고 구축합니다. Deploy 에서 배포 방식과 인프라를 선택해 구현하고, Observe 에서 logging 과 error 와 사용자 반응을 관찰하고, Learn 에서 architecture 와 context 와 workflow 의 개선점을 배웁니다. Learn 은 다음 Discover 로 이어집니다.

flowchart TB
    D1["Discover<br/>문제를 발견한다"] --> D2["Design<br/>기술 설계 · architecture 초안을 쓰고<br/>AI 와 논의해 확정한다"]
    D2 --> D3["Build<br/>AI 와 함께 구현한다"]
    D3 --> D4["Verify<br/>테스트 생성 → 실행 → 실패 → 수정 → 통과<br/>workflow 를 구축한다"]
    D4 --> D5["Deploy<br/>배포 방식과 인프라를 정해 구현한다"]
    D5 --> D6["Observe<br/>logging · error · 사용자 반응을 본다"]
    D6 --> D7["Learn<br/>architecture · context · workflow<br/>개선점을 배운다"]
    D7 -- "다음 문제로" --> D1
    style D1 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style D2 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style D3 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style D4 fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style D5 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style D6 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style D7 fill:#fef3c7,stroke:#f59e0b,color:#1f2937

일곱 단계 중 Verify 를 따로 색을 준 이유는, 개인 loop 에서 가장 먼저 병목이 되는 단계이기 때문입니다. AI 가 코드를 쓰기 시작하면 Build 는 빨라지지만, 검증을 사람이 눈으로 하는 한 Verify 가 새로운 병목이 됩니다. Naver 가 e2e harness 를 먼저 만든 것도 이 때문입니다.

팀 loop 와 조직 loop

개인 loop 가 여러 개 돌면 같은 문제가 반복해서 나타납니다. 팀 loop 는 그 반복되는 학습을 팀 차원의 환경 개선으로 반영하는 loop 입니다. Execute 에서 각 엔지니어가 개인 loop 를 수행하고, Learn 에서 반복되는 문제와 friction 과 architecture conflict 를 발견하고, Reconcile 에서 architecture 와 boundary 와 contract 를 실제 evidence 에 맞게 조정하고, Equip 에서 다음 개인 loop 가 더 빠르고 안전하게 돌도록 rules 와 skills 와 harness 와 shared context 를 개선합니다.

팀 loop 에는 Bound 도 포함됩니다. 여러 개인 loop 가 서로 충돌하지 않도록 경계와 contract 와 guardrail 을 세우는 일이며, rules 와 skills 와 harness 의 형태로 구축합니다.

조직 loop 는 여러 팀 loop 에서 반복되는 학습과 충돌을 조직 차원에 반영합니다. 단계는 팀 loop 와 같지만 다루는 일이 다릅니다. 여러 팀의 local optimum 이 충돌할 때 조정하고, 아키텍처 원칙과 domain boundary 와 공유 contract 와 보안 정책처럼 위키·리뷰·회의록에 흩어진 조직의 맥락을 agent 가 소비할 수 있는 형태로 모아 제공합니다. Uber 의 context graph 와 Naver 의 context provider 가 바로 이 도구입니다. 검증 인프라도 조직 책임으로 올라갑니다. e2e harness 와 deterministic workflow 를 팀마다 따로 만드는 대신 조직이 제공합니다. 그리고 인력 배치와 팀 책임을 조정하고, 경계를 정할 때 A 팀은 편해지고 B 팀은 불편해지는 것 같은 outcome 과 incentive 의 충돌을 해결합니다.

세 loop 는 같은 learning loop 이고 범위만 다릅니다. 하위 loop 에서 얻은 evidence 와 learning 은 상위 loop 의 architecture 와 context 와 guardrail 개선으로 올라가고, 상위 loop 에서 개선된 환경은 다시 하위 loop 를 빠르고 안전하게 만듭니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 14, "bottom": 14}}}}%%
flowchart TB
    subgraph ORG["조직 loop"]
        direction LR
        O1["팀 간 local optimum<br/>충돌을 조정한다"]
        O2["조직의 맥락을<br/>agent 가 쓰는 형태로 제공한다"]
        O3["검증 인프라를<br/>조직이 제공한다"]
    end
    subgraph TEAM["팀 loop"]
        direction LR
        T1["Execute"] --> T2["Learn"] --> T3["Reconcile"] --> T4["Equip"]
        T5["Bound<br/>경계 · contract · guardrail"]
    end
    subgraph ME["개인 loop"]
        direction LR
        M1["Discover → Design → Build → Verify → Deploy → Observe → Learn"]
    end
    ME -- "evidence 와 learning 이 올라간다" --> TEAM
    TEAM -- "반복되는 충돌과 학습이 올라간다" --> ORG
    ORG -- "context · 검증 인프라 · 경계가 내려온다" --> TEAM
    TEAM -- "rules · skills · harness 가 내려온다" --> ME
    style O1 fill:#e0e7ff,stroke:#6366f1,color:#1f2937
    style O2 fill:#e0e7ff,stroke:#6366f1,color:#1f2937
    style O3 fill:#e0e7ff,stroke:#6366f1,color:#1f2937
    style T1 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style T2 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style T3 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style T4 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style T5 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style M1 fill:#dcfce7,stroke:#22c55e,color:#1f2937

loop 의 속도가 맞지 않을 때

AI 로 가장 먼저 빨라지는 것은 개인 loop 입니다. 개인 loop 는 빨라졌는데 팀과 조직의 조정 속도가 그대로면 새로운 병목이 생깁니다. architecture 문서는 이미 코드와 다르고, rules 는 지난 분기 기준이고, 승인과 조정을 기다리는 시간이 구현 시간보다 길어집니다.

그래서 팀과 조직의 loop 도 하위 loop 의 변화 속도를 감당할 수 있도록 feedback latency 를 줄여야 합니다. 모든 loop 가 같은 속도로 돌아야 한다는 뜻은 아닙니다. 범위가 커질수록 더 신중한 판단이 필요합니다. 다만 상위 loop 가 하위 loop 의 변화 속도를 따라가지 못하면 그 자체가 병목이 됩니다.

역할의 재배치

기존에 architect 가 하던 결정의 일부가 product engineer 에게 내려옵니다. 구현 context 를 가장 많이 가진 사람이 architecture 를 구체적으로 검토하고 구현 결과를 가장 빠르게 확인할 수 있기 때문입니다.

그러나 local context 는 global context 가 아닙니다. 한 팀 안에서 최적인 결정이 30개 팀의 보안과 비용과 규제를 고려하면 최적이 아닐 수 있습니다. 결정은 현장으로 내려오지만, 조직 전체의 technical coherence 를 책임지는 역할은 오히려 더 중요해집니다.

그 역할이 맡는 책임은 domain boundary, platform 전략, data ownership, 공유 contract, reliability, scalability, architecture evolution 입니다. 여기에 agent 에게 context 와 constraints 를 제공하는 일과, 팀 간 local optimum 충돌을 조정하는 일이 새로 더해집니다.

flowchart LR
    R1["architect<br/>domain boundary · platform 전략<br/>data ownership · 공유 contract"]
    R2["architect<br/>reliability · scalability<br/>architecture evolution"]
    R3["architect<br/>agent 에게 context 와<br/>constraints 를 제공한다"]
    R4["architect<br/>팀 간 local optimum<br/>충돌을 조정한다"]
    P1["product engineer<br/>architecture 를 구체적으로<br/>검토하고 결과를 빠르게 확인한다"]
    P2["product engineer<br/>팀 범위의 architecture<br/>결정을 직접 내린다"]
    R1 -- "결정의 일부가<br/>현장으로 내려온다" --> P2
    R3 --> P1
    P2 -. "local context 는<br/>global context 가 아니다" .-> R4
    style R1 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style R2 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style R3 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style R4 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style P1 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style P2 fill:#dbeafe,stroke:#3b82f6,color:#1f2937

이 역할을 맡는 사람도 hands-on 이어야 합니다. 실제 시스템과 agentic engineering 의 capability 와 constraint 를 체감할 만큼은 직접 만들어 봐야 합니다. 그래야 실효성 있는 상위 설계와 정책 결정이 가능합니다. 직접 만들어 보지 않은 사람이 정한 agent 규칙은 현장에서 지켜지지 않습니다.

---

Part 3. 그에 따른 역량과 성장

역량 모델

일하는 방식이 loop 로 바뀌면 필요한 역량도 달라집니다. 세 가지로 정리합니다.

• Product engineering — 고객과 비즈니스의 문제를 발견해 제품으로 만드는 역량입니다. 고객에게 공감하며 진짜 문제를 발견하는 공감 능력, AI 와 함께 feature 와 product 와 system 을 구현하는 구현 능력, 현실 세계의 문제를 기술적 설계로 바꾸는 제품 레벨의 추상화가 여기에 속합니다.
• Architecture engineering — 제품을 확장과 유지보수가 쉬운 시스템으로 만드는 역량입니다. boundary, state, data, interface, dependency, quality attributes, evolution 을 다루고, scope 가 커질수록 조직 전체의 technical coherence 를 책임집니다. 동작하는 시스템을 agentic engineering 으로 만드는 hands-on 역량이 포함됩니다.
• AI engineering — AI 로 engineering 하는 능력과, AI capability 자체를 product 와 system 에 engineering 하는 능력입니다. 앞의 것은 coding agents, context engineering, skills, harness, delegation, evaluation 이고, 뒤의 것은 model, inference, agents, memory, tools, constraints, eval, safety, reliability 입니다.

Verification 은 이 세 역량에 포함하지 않지만, 세 영역 전체를 관통하는 핵심 역량입니다. AI 가 생성한 코드와 agent 의 결과를 믿을 수 있게 만드는 e2e harness 와 deterministic workflow 를 설계하는 일의 중요성이 커지고 있습니다. Part 1 의 두 번째 질문이 여기서 개인의 역량으로 내려옵니다.

venn-beta
  set P["Product"]
  set A["Architecture"]
  set I["AI"]
  union P, A["시스템화"]
  union A, I["AI 내장"]
  union P, I["AI 구현"]
  union P, A, I["Verification"]

세 원이 겹치는 자리가 세 역량의 관계입니다. Product 와 Architecture 가 겹치는 곳은 제품을 확장·유지보수가 쉬운 시스템으로 만드는 일(시스템화)이고, Architecture 와 AI 가 겹치는 곳은 system 안에 AI capability 를 넣는 일(AI 내장)이며, Product 와 AI 가 겹치는 곳은 AI 로 feature 와 product 를 구현하는 일(AI 구현)입니다. 세 원이 모두 겹치는 가운데가 Verification 입니다.

성장 모델

역량이 세 가지라면 성장은 세 축으로 봅니다. depth 는 깊이, 즉 전문성입니다. FE, BE, infra, data, model, agent, AI infra 같은 특정 영역을 얼마나 깊이 아는가입니다. 깊이는 쓸 수 있다, 동작 원리를 안다, 설계를 판단한다의 세 단계로 나눠 볼 수 있습니다. breadth 는 넓이, 즉 end-to-end 범위입니다. 인접 영역을 AI 와 함께 다룰 수 있게 되는 것이며, 역할 수행에 필요한 범위를 AI 와 함께 스스로 해결할 수 있을 만큼의 능력을 뜻합니다. scope 는 영역, 즉 architecture 를 판단하는 범위입니다. feature 에서 product, service 와 domain, multiple domains, platform, organization 으로 더 큰 시스템을 판단하는 것이며, seniority 와 가장 강하게 연결됩니다.

이 표의 세 번째 열이 product engineer 로의 전환입니다. FE 전문성을 버리는 것이 아니라, 그 위에 breadth 와 scope 를 더하는 것입니다. AI 가 breadth 를 넓히는 비용을 크게 낮췄기 때문에 이 전환이 예전보다 훨씬 현실적인 목표가 됐습니다.

세 축을 한 그림에 놓으면 형태로 보입니다. breadth 는 옆으로 넓어지는 행이고, depth 는 그중 한 영역이 아래로 갈수록 깊어지는 열이며, scope 는 이 둘을 포함해 판단하는 영역입니다. 아래는 product engineer 로 전환한 frontend 개발자의 모양입니다. breadth 행에는 FE·BE·data·deploy 가 나란히 있고, depth 블록은 FE 영역의 깊이가 1단계에서 3단계까지 있다는 것을 보여주며, 판단하는 영역은 feature 에서 product 와 domain 까지 넓어져 있습니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 14, "bottom": 14}}}}%%
flowchart TB
  subgraph SCOPE["scope · 판단하는 영역 — feature → product → domain"]
    direction TB
    subgraph BREADTH["breadth · 넓이 — 인접 영역을 AI 와 함께 다룬다"]
      direction LR
      FE["FE"] ~~~ BE["BE"] ~~~ DATA["data"] ~~~ DEPLOY["deploy"]
    end
    subgraph DEPTH["depth · 깊이 — FE 의 깊이 1~3단계"]
      direction TB
      L1["1 · 쓸 수 있다"] ~~~ L2["2 · 동작 원리를 안다"] ~~~ L3["3 · 설계를 판단한다"]
    end
    BREADTH ~~~ DEPTH
  end
  style SCOPE fill:#fef3c7,stroke:#f59e0b,color:#1f2937
  style BREADTH fill:#eff6ff,stroke:#3b82f6,color:#1f2937
  style DEPTH fill:#f0fdf4,stroke:#22c55e,color:#1f2937
  style FE fill:#dbeafe,stroke:#3b82f6,color:#1f2937
  style BE fill:#dbeafe,stroke:#3b82f6,color:#1f2937
  style DATA fill:#dbeafe,stroke:#3b82f6,color:#1f2937
  style DEPLOY fill:#dbeafe,stroke:#3b82f6,color:#1f2937
  style L1 fill:#dcfce7,stroke:#22c55e,color:#1f2937
  style L2 fill:#dcfce7,stroke:#22c55e,color:#1f2937
  style L3 fill:#dcfce7,stroke:#22c55e,color:#1f2937

---

마치며

정리하면 세 가지입니다. 구현 비용이 내려가면 한 사람이 책임지는 범위가 넓어지고, 더 많은 엔지니어가 product engineer 처럼 문제의 결과까지 책임지게 됩니다. 생산성은 코드 생성 속도가 아니라 software engineering loop 를 재설계했는지에 따라 달라지고, 개인·팀·조직 loop 의 속도가 맞아야 합니다. 그리고 회사 크기와 무관하게 context, verification, delegation 세 질문에 자기 규모에 맞는 답을 만들어야 합니다.

시작은 작게 할 수 있습니다. 팀에서 개인 loop 하나를 골라, 코드를 더 빨리 쓰는 것보다 먼저 Verify 단계에 검증 Loop 를 세워 봅니다. agent 가 만든 결과를 사람이 눈으로 확인하지 않아도 되는 지점이 하나 생기면, 그때부터 나머지 loop 를 다시 그릴 근거가 쌓입니다.