코딩 에이전트 확장의 병목은 팀과 조직이다

메타데이터

• 원문 제목: [한영자막] 코딩 에이전트는 스스로 확장되지 않습니다. 팀도 마찬가지입니다. — Patrick Debois, Tessl
• 채널: Tech Bridge
• 발표자: Patrick Debois (Tessl)
• 날짜: 2026-08-24
• 영상 길이: 20분 49초
• 원문 URL: https://www.youtube.com/watch?v=4DdNMO81_HQ
• 자막 기준: 영어 자동 자막 전체를 문맥에 맞게 정리·번역
• 핵심 주제: 코딩 에이전트(Coding Agent)의 성능보다 팀의 작업 방식, 공유 컨텍스트(Context), 하네스(Harness), 플랫폼, 조직 운영을 함께 설계해야 자율 개발(Autonomous Development)이 확장된다.

---

📌 핵심 질문 / 에이전트 확장의 진짜 병목은 무엇인가

==코딩 에이전트의 확장은 모델이나 프롬프트의 문제가 아니라, 에이전트를 사용할 팀과 조직이 아직 그 방식으로 일할 준비가 되었는지의 문제다.==

• 2009년 지속적 배포(Continuous Delivery)가 미친 생각으로 취급되었지만, 실제 장벽은 기술 불가능성이 아니라 조직의 준비 부족이었다.
• 에이전트에 루프(Loops), 하네스(Harnesses), 컨텍스트(Context), 테스트와 가드레일(Guardrails)을 붙이는 일은 곧 상품화되며, 장기적인 차별화 요소가 되기 어렵다.
• 차별화는 개인이 프롬프트를 더 잘 쓰는 데서 나오지 않고, 한 번의 시스템 개선이 모든 팀원에게 재사용되는 공유 시스템에서 나온다.
• 팀 리더와 플랫폼 조직은 잘 정의된 일을 에이전트에 넘기고, 정의되지 않은 문제는 사람의 대화와 판단으로 남기며, 조직 전체가 학습하는 피드백 고리를 만들어야 한다.

에이전트가 코드를 생성하는 속도가 빨라질수록 병목은 코드 작성에서 요구사항 입력, 검토, 배포, 운영, 사용자와 시장의 수용으로 이동한다. 따라서 목표는 사람을 없애는 것이 아니라 사람의 개입을 시스템적으로 줄이면서도 좋은 엔지니어링 관행을 보존하는 것이다. 개인용 도구를 공유 컨텍스트와 중앙 플랫폼으로 확장하고, 비용·재사용·휴먼 터치(human touch)·리스크를 측정해야 지속적 배포가 지속적 학습(Continuous Learning)으로 발전한다.

1. 다크 팩토리로 향하는 출발점

1.1. 지속적 배포와 자율 개발의 평행선

1. 2009년에 지속적 배포가 받았던 반응

   1. Patrick Debois가 2009년에 지속적 배포를 이야기했을 때 많은 사람은 그런 발상을 미친 생각이라고 했다.
   2. 지금 다크 팩토리(Dark Factory), 즉 사람의 직접 개입을 최소화한 자율적 개발을 이야기할 때도 “여기서는 작동하지 않을 것”이라는 반응이 반복된다.

2. “아직 준비되지 않았다”는 신호

   1. “작동하지 않는다”는 말은 기술이 불가능하다는 판정이라기보다 조직이 아직 준비되지 않았다는 신호다.
   2. 언젠가 하고 싶지 않아서가 아니라, 현재의 팀 구조·프로세스·책임·운영 체계가 자율 개발을 받아들일 형태로 세팅되어 있지 않아서 생기는 저항이다.
   3. 따라서 에이전트가 실패할 때 모델만 탓하거나 새 도구만 찾는 것보다 조직의 준비 상태를 점검해야 한다.

1.2. 에이전트 기술은 상품화되고, 조직 설계가 차별화가 된다

1. 현재의 기술적 조립

   1. 에이전트를 루프와 하네스로 최적화하고, 도구를 연결하고, 실행을 검증하는 일은 당분간 중요한 엔지니어링 과제다.
   2. 그러나 이 작업이 좋은 방식으로 조립되면 언젠가는 일반적인 상품(Commodity)이 된다.
   3. 프런티어 랩(Frontier Lab)이 에이전트 실행 기능을 서비스로 제공하는 날이 오면, 개별 조직이 하네스를 갖췄다는 사실 자체는 차별화가 되지 않는다.

2. 다크 팩토리의 전제

   1. 조직 내부에서 어느 정도 자율적 작업(Autonomous Working)이 이뤄지는 방향으로 간다고 가정하면, 핵심 질문은 “에이전트를 어떻게 더 똑똑하게 만들까?”에서 “우리의 협업·플랫폼·조직을 어떻게 바꿀까?”로 옮겨간다.
   2. 에이전트 한 개를 잘 쓰는 개인과 Claude Code 같은 도구를 함께 사용하는 팀은 전혀 다른 운영 문제를 갖는다.

2. 개발자의 정체성과 새로운 기술적 역할

2.1. 개발자는 지휘자가 되는가

1. 오케스트레이터 서사

   1. 흔히 개발자가 점점 에이전트의 지휘자(Conductor) 또는 오케스트레이터(Orchestrator)가 된다고 말한다.
   2. 실제로 개발자는 에이전트를 관리하고, 여러 에이전트가 협력하도록 조정하며, 결과를 검토하는 방향으로 이동하고 있다.

2. 역할 변화가 만드는 마찰

   1. 많은 개발자는 “우리는 더 나은 프롬프트를 쓰거나 더 나은 사양(Specification)을 작성하는 일을 하겠다고 엔지니어가 된 것이 아니다”라고 느낀다.
   2. 기술적 문제를 직접 다루고 싶었던 사람이 프롬프트와 사양만 관리하게 되면, 이것이 정말 자신이 원하는 역할인지 의문이 생긴다.
   3. 컨텍스트 엔지니어링(Context Engineering)은 프롬프트가 단순한 한 번의 입력이 아니라 테스트·평가·배포·최적화의 대상이라는 점을 보여줬지만, 프롬프트와 사양만 만지는 일은 여전히 많은 개발자에게 공허하게 느껴졌다.

2.2. 하네스와 루프가 되살리는 엔지니어링의 감각

1. 새로운 기술적 경로

   1. 조직이 하네스와 루프를 도입하고 더 자율적인 작업을 시도하자, 개발자는 에이전트를 돕는 도구와 에이전트용 도구를 만들기 시작했다.
   2. 에이전트가 사용할 수 있는 도구를 프로그래밍 방식으로 만들면서, 개발자는 자신의 도메인 지식과 엔지니어링 역량이 다시 직접 쓰인다는 감각을 얻었다.

2. 추상화가 만든 새로운 장인정신

   1. 추상화(Abstraction)는 개발자의 작업을 없애기만 하는 것이 아니라, 엔지니어링이 이동할 새로운 위치를 만든다.
   2. 코드 한 줄을 직접 작성하는 대신, 에이전트가 안정적으로 코드를 만들도록 컨텍스트·도구·검증·하네스를 설계하는 일이 새로운 기술적 장인정신이 된다.
   3. 겉보기에는 “추상화, 추상화, 추상화”가 반복되는 것처럼 보여도, 그 안에 새로운 엔지니어링 작업이 생긴다.

3. 회의적인 사람을 참여시키는 방법

   1. 에이전트가 만든 결과물의 품질을 비판하는 회의적인 개발자는 오히려 좋은 컨텍스트를 만드는 데 적합하다.
   2. “당신의 지식을 모두 사용해 에이전트 결과를 개선해 달라”고 요청하면, 품질에 대한 불만이 시스템 개선으로 전환된다.
   3. 바닐라 코딩 에이전트의 결과를 못마땅해하는 사람에게 그 분노와 회의론을 하네스·검증 규칙·컨텍스트 개선에 쓰도록 하면, 저항이 품질 향상의 동력이 된다.

2.3. 생성된 코드를 고치는 대신 생성 시스템을 고친다

1. 핵심적인 사고 전환

   1. 회사가 개발자에게 권할 가장 큰 변화는 에이전트가 생성한 코드를 매번 손으로 고치는 일을 멈추고 시스템을 개선하는 것이다.
   2. 한 번의 결과를 고치는 것은 해당 출력에만 효과가 있지만, 컨텍스트·하네스·테스트·가이드라인을 고치면 이후 모든 출력에 효과가 난다.

2. “무엇을 만드는가”에서 “무엇이 만들게 하는가”로

   1. John Swix가 몇 년 전 말한 표현처럼, “그것을 만드는 일을 멈추고, 그것을 만드는 것을 만들어라(Stop building the thing, but build the thing that builds the thing)”라는 방향이다.
   2. 자동완성(Autocomplete)·프롬프트·개별 에이전트 실행에 밀착된 사람은 한 단계 위로 올라가 시스템을 생각해야 한다.
   3. 목표는 인간의 터치(human touches)를 줄이되, 테스트·문서화·검토·보안 같은 엔지니어링 관행은 유지하는 것이다.

3. 팀의 일하는 방식이 바뀌는 지점

3.1. 프롬프트가 아니라 엔지니어링 관행을 지시한다

1. 바이브 코딩의 한계

   1. 처음에는 프롬프트를 입력하고 결과가 나오면 계속 진행하는 바이브 코딩(Vibe Coding) 서사가 강했다.
   2. 성숙한 방식은 에이전트에게 구현만 시키지 않고, 테스트를 작성하고 문서를 갱신하며 좋은 엔지니어가 지켜야 할 모든 절차를 함께 수행하도록 지시한다.

2. YOLO식 개발 금지

   1. 에이전트에게 대충 맡기고 결과를 운에 맡기는 방식은 시스템을 유지할 수 없게 만든다.
   2. 사람이 직접 하던 엔지니어링 관행을 에이전트의 작업 흐름 안에 명시해야 에이전트도 더 나아지고 시스템도 안정적으로 유지된다.

3.2. 계획과 회고의 대상이 코드에서 시스템으로 이동한다

1. 회고(Retrospective)의 변화

   1. 고급 팀은 “코드에 문제가 있었다”고만 말하지 않고 “시스템에 문제가 있었다”고 말한다.
   2. 에이전트가 같은 문제를 반복해서 만났다면, 회고의 질문은 “왜 이 코드가 틀렸나?”가 아니라 “하네스·컨텍스트·검증 체계에서 무엇을 고칠까?”가 된다.
   3. 반복 실패가 시스템 학습으로 전환될 때, 같은 실수가 팀 전체에 계속 재발하는 것을 막을 수 있다.

2. 계획(Planning)의 분할

   1. 충분히 범위가 정해진 작업은 에이전트가 쉽게 집어 간다. 요구사항과 완료 조건이 잘 정의되어 있고 하네스가 안정적이기 때문이다.
   2. 범위가 불분명한 작업은 여전히 사람에게 남는다. 팀이 대화로 의도를 정하고, 여러 선택지를 비교하고, 제품 방향을 합의해야 하기 때문이다.
   3. 계획은 “에이전트로 곧바로 보낼 수 있는 잘 정의된 작업”과 “팀이 대화로 결정해야 하는 작업”으로 나뉜다.

3. 팀 리더의 역할

   1. 구성원이 각자 알아서 프롬프트를 쓰며 “가서 알아서 해보라”고 하는 것은 리더십이 아니다.
   2. 팀 리더는 구성원이 프롬프트를 배우면 재사용 가능한 컨텍스트로 전환하도록 속도와 제약을 설정해야 한다.
   3. “프롬프트를 더 쓰라”에서 “이 컨텍스트를 재사용 가능하게 만들라”로 넘어가는 단계적 지시가 팀의 학습 속도를 결정한다.

3.3. 코드 밖으로 확장되는 하네스

1. 다운스트림 조직의 병목

   1. 개발팀의 생산량이 늘어나면 Go-to-Market(GTM) 조직과 다른 downstream 팀이 결과를 따라가기 어려워진다.
   2. 사용자도 기능 변화와 업데이트 속도를 따라가기 힘들 수 있다.
   3. 개발팀만 자동화하면 전체 가치 흐름에 병목이 남으므로, GTM·사용자 지원·운영에도 자동화를 제공해야 한다.

2. 요구사항 입력의 병목

   1. 개발팀이 빠르게 만들더라도 요구사항이 충분히 빨리 들어오지 않으면 생산성이 막힌다.
   2. 요구사항을 모으고 정제하고 우선순위를 정하는 워크플로우도 하네스의 일부가 되어야 한다.
   3. 하네스는 코딩 단계에서 끝나는 도구가 아니라, 요구사항부터 사용자에게 전달되는 과정 전체를 연결하는 시스템이다.

4. 측정과 공유 시스템의 승수 효과

4.1. 에이전트의 성능을 보는 두 가지 지표

1. 휴먼 터치 수

   1. 에이전트가 올바른 결과를 내도록 사람이 몇 번 개입해야 하는지 측정한다.
   2. 컨텍스트·하네스·가이드라인이 좋아질수록 필요한 인간의 수정과 재지시 횟수는 내려가야 한다.
   3. 토큰 사용량만 보는 것보다, 사람이 에이전트의 경로를 얼마나 자주 바로잡는지 보는 편이 시스템 개선 방향을 알려준다.

2. 공유 시스템의 승수

   1. 개인이 혼자 생산성을 10배 높이는 것보다, 공유 시스템의 한 부분을 고쳐 모든 사람이 혜택을 받게 하는 편이 조직에 더 큰 승수(Multiplier)가 된다.
   2. 한 번 고친 컨텍스트나 하네스가 모든 팀원에게 적용되면, 한 사람의 개선이 아니라 팀 전체의 개선이 된다.
   3. 팀 저장소에서 컨텍스트를 공유하고 하네스를 함께 작업하는 단계는 조직 전체의 멀티플레이어 시스템으로 가는 출발점이다.

4.2. 플랫폼 조직으로 넘어가는 단계

1. 플랫폼이 맡아야 할 새로운 영역

   1. 기존 플랫폼 팀은 인프라·클라우드·MCP 게이트웨이 같은 일에 집중해 왔지만, 코딩 에이전트의 확장에는 새로운 공용 기능이 필요하다.
   2. 재사용 가능한 스킬 레지스트리(Skill Registry), 컨텍스트를 평가하는 평가 시스템(Evaluation System), 코딩 에이전트 전용 가드레일, 에이전트 정체성(Identity) 관리가 그 예다.
   3. 개발자 경험(Developer Experience) 팀과 플랫폼 팀이 이 영역을 나눠 갖더라도 중앙에서 연결하는 책임자가 필요하다.

2. 명확한 오너십

   1. 플랫폼 팀은 인프라를 소유하지만 개발 방식까지 직접 소유하지 않을 수 있고, 개발자 경험 팀은 개발 방식을 다루지만 모든 인프라를 소유하지 않을 수 있다.
   2. 두 조직 사이에 책임이 흩어지면 누구도 프로그램 전체를 추진하지 않게 된다.
   3. 플랫폼과 개발자 경험의 경계를 넘나들며 중앙 공용 기능을 이끌 오너를 지정해야 한다.

5. 재사용 가능한 파브드 로드와 레지스트리

5.1. 팀마다 다시 만들지 않는 공용 구성요소

1. 파브드 로드(Paved Road)

   1. 여러 팀이 인증 시스템(Authentication System)을 각자 새로 구현할 이유는 없다.
   2. 공통 인증을 공유 구성요소로 레지스트리에 올리고, 팀이 쉽게 가져다 쓰도록 해야 한다.
   3. 같은 린터(Linter), 보안 도구, 하네스를 사용한다면 그것도 재사용 가능한 구성요소로 관리해야 한다.

2. 플랫폼 레지스트리의 목적

   1. 클라우드의 파브드 로드와 유사하게, 컨텍스트·하네스·스킬·검증 도구를 조직의 재사용 레지스트리로 중앙화한다.
   2. 각 팀이 스스로 만든 결과를 공유하는 것만으로는 재사용성이 보장되지 않는다.
   3. 공용 구성요소는 테스트 가능하고, 다른 팀이 확장할 수 있고, 보안 스캔을 통과하며, 누가 유지보수하는지 명확해야 한다.

5.2. 무질서한 스프롤과 선택의 피로

1. 공유 저장소만으로는 충분하지 않다

   1. 누구나 저장소에 올릴 수 있게만 하면 비슷한 스킬이 여러 개 생기고, 원본·포크·유사 버전이 뒤섞인다.
   2. 사용자는 어느 스킬을 선택해야 하는지 알 수 없고, 유지보수자가 사라진 구성요소를 계속 사용하게 될 위험이 있다.

2. 중앙 오너의 품질 책임

   1. 영역별 오너는 구성요소를 만들기만 하지 않고 테스트 가능성, 확장성, 보안 검사, 지속적인 유지보수를 책임져야 한다.
   2. 공유 컨텍스트와 하네스가 조직의 공식 자산이 되면, 개인이 비공식적으로 나눠 쓰는 파일보다 신뢰성과 수명이 길어진다.

5.3. 합의와 선택권의 균형

1. 단일 표준이 어려운 이유

   1. 두 개발팀이 일하는 방식 하나에 합의하려면 커뮤니케이션과 조정 비용이 크다.
   2. 탭(Tab)과 스페이스(Space)를 정하는 논쟁처럼 사소한 차이도 실제 협업에서는 큰 마찰이 될 수 있다.

2. 세네 가지 파브드 로드

   1. 모든 조직에 하나의 방식만 강제하기보다 세 개 또는 네 개 정도의 관리되는 파브드 로드를 카탈로그로 제공하는 편이 현실적이다.
   2. 팀은 자신에게 맞는 길을 선택할 수 있고, 필요하면 자체 방식을 유지할 수도 있다.
   3. 다만 중앙에서 제공하는 구성요소는 공식 예산으로 유지하고, 자체 방식은 팀이 별도 비용과 책임을 감수해야 한다.
   4. 유지보수된 공용 경로가 가장 쉽게 도입되는 선택지가 되도록 만드는 것이 목표다.

6. 비용을 보이게 하고 최적화하기

6.1. 제한보다 가시성

1. 토큰과 실행 비용

   1. 에이전트 사용 비용이 크다고 무조건 전체 지출을 제한하면 학습과 개선까지 막힌다.
   2. 플랫폼 팀은 에이전트가 얼마를 쓰는지, 몇 번의 반복(iteration)을 거치는지, 어떤 작업이 비용을 많이 만드는지 보이게 해야 한다.

2. 최적화의 근거

   1. 실행 반복 횟수를 줄이면 비용을 낮출 수 있고, 더 나은 컨텍스트와 하네스도 불필요한 반복을 줄인다.
   2. 비용이 보이지 않으면 최종 결과만 보고 원인을 알 수 없다.
   3. 비용과 반복 수를 시각화하면 올바른 모델 선택, 모델 사용 교육, 컨텍스트 개선, 하네스 개선 중 무엇이 효과적인지 판단할 수 있다.

6.2. VP Engineering의 방어 논리

1. 기존 생산성 지표의 어려움

   1. 엔지니어링 리더는 구매한 라이선스 수, 빨라진 배포, 좋아진 품질을 근거로 에이전트 투자를 설명해야 한다.
   2. 배포 속도와 품질의 개선은 비교 기준을 잡기 어려워 증명하기 힘들다.

2. 여정의 지표

   1. 에이전트 실행이 몇 번의 턴(turn)을 거쳐 완료되는지, 그 실행이 얼마나 개선되고 있는지, 구성요소가 얼마나 재사용되는지를 측정하면 더 설득력 있는 근거가 된다.
   2. 에이전트 사용 전후의 개인 생산성을 단순 비교하기보다, 시스템이 반복될수록 휴먼 터치·실행 턴·비용이 줄고 재사용이 늘어나는지를 보여줘야 한다.

7. 조직 차원의 변화 관리

7.1. 유행하는 변화 프로그램의 한계

1. 일반적인 확산 패턴

   1. 해커톤, 런치 앤 런(Lunch and Learn), 성공 사례 공유, 전용 Slack 채널, 챔피언 프로그램은 흔히 쓰이는 변화 관리 방식이다.
   2. 과거 애자일(Agile)이나 DevOps를 확산할 때도 같은 방식이 사용됐다.

2. 라이선스와 교육만으로는 부족하다

   1. 라이선스를 배포하고 사람을 교육한 뒤 각자 시도하게 두는 “수천 송이 꽃을 피워보자”식 전략은 작동하지 않는다.
   2. 조직은 각자의 실험 결과를 공유하는 데서 멈추지 않고, 팀 리더와 플랫폼 조직에게 실제 시스템을 바꾸라는 권한과 의무를 줘야 한다.

7.2. 팀 리더와 플랫폼 팀에 부여할 권한

1. 조직의 실행 단위

   1. 에이전트 확장은 개인 개발자의 도구 선택 문제가 아니라 팀 단위의 작업 방식과 플랫폼 단위의 공용 자산 문제다.
   2. 팀 리더는 업무를 에이전트가 처리할 수 있게 구조화하고, 플랫폼 팀은 공유 컨텍스트·검증·가드레일·비용 가시성을 제공해야 한다.

2. 조직의 승수 구조

   1. 개인 → 팀 공유 시스템 → 조직의 멀티플레이어 시스템으로 이동할수록 한 번의 개선이 더 많은 사람에게 퍼진다.
   2. 여러 방향으로 개선이 번지는 플라이휠(Flywheel)을 만들려면, 공용 자산을 만들고 유지할 공식 책임이 있어야 한다.

8. 채용과 역량 평가

8.1. 새로운 직함은 실력을 증명하지 않는다

1. 빠르게 생기는 직함

   1. AI Product Engineer, Deployed Engineer, Agentic Engineer, AI Engineer 같은 직함이 등장하고 있다.
   2. 채용 공고에 새 직함을 적으면 새로운 의도를 가진 지원자가 모일 수 있지만, 직함만으로 에이전트 활용 성숙도를 판단할 수는 없다.
   3. 아직 누구도 이 분야에서 충분히 성숙하지 않았기 때문에 직함은 역량 검증이 아니라 관심의 신호에 가깝다.

2. AI를 이어폰으로 쓰는 면접 이야기

   1. 면접 중 AI가 귓속으로 답을 알려주도록 사용하는 지원자 이야기가 들릴 정도로 기존 면접 방식은 변하고 있다.
   2. 이런 상황에서는 암기한 답이나 도구 사용 여부보다 실제로 문제를 해결하고 설명하는 능력을 확인해야 한다.

8.2. 세 단계의 실전 평가

1. 첫 단계: AI 활용 과제

   1. 지원자에게 과제를 주고 AI의 도움을 받아 문제를 최대한 깊이 해결하게 한다.
   2. AI를 썼다는 사실을 감점하지 않고, AI를 얼마나 잘 활용해 결과를 끌어내는지 본다.

2. 둘째 단계: 워크스루와 기술적 취향

   1. 과제를 통과한 뒤 지원자에게 무엇을 했는지, 왜 그 설계가 좋은지 설명하게 한다.
   2. 이 과정에서 결과물의 기술적 품질뿐 아니라 좋은 선택을 판별하는 감각(Taste)과 엔지니어링 판단을 확인한다.

3. 셋째 단계: 협업 가능성

   1. 지식과 결과물을 팀에 공유할 의지가 있는지, 혼자만 잘하는 솔로 플레이어인지 확인한다.
   2. 조직에 필요한 사람은 공유 가능하고(Sharable), 재사용 가능하며(Reusable), 엔지니어링 등급(Engineering Grade)의 결과물을 만드는 사람이다.

8.3. 한 사람에게 세 능력을 모두 요구하지 않는다

1. 서로 다른 역량 조합

   1. ML이나 AI를 공부했는지, 코딩 전문가인지 하나만으로 판단하지 말고 AI 활용·엔지니어링 판단·협업 능력의 조합을 본다.
   2. 세 가지 모두에 뛰어난 사람이 없더라도 괜찮다.

2. 멘토링의 역할

   1. 한 영역에 강한 사람이 다른 영역에서 멘토링과 교육을 받도록 설계하면 된다.
   2. 서로 다른 능력의 프로필을 단순히 주니어·시니어라는 하나의 축으로 납작하게 만들면 실제 강점과 지원 필요 영역을 놓치게 된다.

9. 팀 규모와 역할의 현실

9.1. 만능 개발자 한 명이라는 환상

1. 이상적인 만능 인력

   1. 모든 일을 혼자 처리하는 한 명의 만능 개발자는 매력적인 꿈이다.
   2. 실제로는 PM이나 디자이너처럼 상호보완적인 역량을 가진 사람과 짝을 이루게 된다.

2. 백업과 운영의 필요

   1. 한 사람이 휴가를 가도 시스템이 멈추지 않으려면 백업 인력이 필요하고, 이때 팀은 최소 세 명 정도로 늘어난다.
   2. 프로덕션 운영과 들어오는 티켓을 돌볼 사람도 필요하다.
   3. 생산성이 매우 높으면 같은 사람이 운영과 기능 개발을 함께 할 수 있지만, 버그를 처리하는 동안 기능 개발 속도는 떨어진다.

3. 주니어의 학습

   1. 주니어가 팀에 들어와 세 영역에서 좋은 결과가 무엇인지 배우게 해야 조직의 역량이 이어진다.
   2. 에이전트가 코드를 대신 써도 품질 기준과 설계 감각을 배우는 과정은 사라지지 않는다.

9.2. 소수 정예만으로 조직을 구성할 수 없는 이유

1. 경험 많은 한두 명이 모든 팀을 책임지는 구조는 초기에는 빠를 수 있지만 조직 전체 확장에는 한계가 있다.
2. 각 팀을 솔로 또는 두 명으로만 구성하는 방식은 운영·백업·학습·제품·품질 업무를 동시에 감당하기 어렵다.
3. 그러므로 에이전트 활용법과 시스템 설계에 대한 교육에 계속 투자해야 한다.

10. 다크 팩토리와 리스크 기반 자율성

10.1. 모든 기능을 동일하게 자동화하지 않는다

1. 어두운 공장과 희미한 공장

   1. 최종 목표를 완전한 다크 팩토리라고 하더라도, 현실은 위험 수준에 따라 조명이 남아 있는 딤 팩토리(Dim Factory)에 가깝다.
   2. 어떤 기능에 어느 정도의 리스크를 허용할지는 기능별로 달라진다.
   3. 모든 기능이 자율적으로 만들어지는 것은 아니며, 중요한 기능에는 더 강한 감사와 검증이 필요하다.

2. 감사와 검증의 투자

   1. 누가 코드를 바꿨는지 확인할 수 있는 출처 추적(Provenance)을 남겨야 한다.
   2. 생성된 코드가 실제로 유용하고 안전한지 확인하는 검증기(Verifier)를 둬야 한다.
   3. 검증기가 실패하는 상황에서는 시스템이 현재 무엇을 하고 있는지 파악하는 상황 인식(Situational Awareness)에 투자해야 한다.

10.2. 마이크로매니저에서 자율 승인까지

1. 조직의 통제 방식은 모든 코드를 사람이 직접 승인하는 마이크로매니저부터, 정해진 조건을 만족하면 에이전트가 자율적으로 승인하는 방식까지 연속선상에 있다.
2. 정답은 하나의 승인 모델이 아니라 기능의 위험도에 맞는 통제 수준이다.
3. 위험이 낮은 기능은 자동화하고, 영향이 큰 변경은 더 많은 사람의 검토·감사·검증을 거치게 해야 한다.

11. 지속적 배포에서 지속적 학습으로

11.1. 지식을 실행 가능한 자산으로 바꾼다

1. 지식의 포착

   1. 팀의 지식은 사람의 머릿속에만 남지 않고 스킬, 컨텍스트, 하네스에 기록되어야 한다.
   2. 하네스는 사업적 맥락(Business Context)을 에이전트가 넘지 않도록 제약하면서도 필요한 작업을 수행하게 한다.

2. 지식의 재사용

   1. 한 번 기록된 지식은 팀 전체와 조직 전체에 반복해서 사용될 수 있어야 한다.
   2. 공용 자산에 오너·테스트·보안·비용 정보가 붙으면 지식이 실행 가능한 운영 자산으로 바뀐다.

11.2. 반응 속도가 만드는 지속적 학습

1. 지속적 배포의 다음 단계는 지속적 학습이다.
2. 핵심 질문은 “새로운 것을 얼마나 빨리 넣고 뺄 수 있는가?”다.
3. 새로운 모델·컨텍스트·스킬·하네스를 빠르게 교체하는 능력은 반응 모드(Reactive Mode)의 핵심이다.
4. 시스템을 더 안정적으로 만드는 것만으로는 충분하지 않다. 시스템의 더 많은 부분을 바꾸면서도 안정성을 유지할 수 있어야 한다.

주요 발언 모음

“We’re not ready yet.” — “아직 준비되지 않았을 뿐이다.”

“Stop building the thing, but build the thing that builds the thing.” — “그것을 만드는 일을 멈추고, 그것을 만드는 것을 만들어라.”

“Minimize the human touches, but still with good engineering practices.” — “좋은 엔지니어링 관행을 유지하면서 인간의 개입을 최소화하라.”

“We had issues with the system.” — “코드가 아니라 시스템에 문제가 있었다고 말하라.”

“Can I keep it reliable while changing more of the system?” — “시스템을 더 많이 바꾸면서도 안정성을 유지할 수 있는가?”

“We didn’t sign up for better prompt writing.” — “우리는 더 나은 프롬프트 작성을 하겠다고 엔지니어가 된 것이 아니다.”

핵심 데이터 & 수치

• 2009년: 지속적 배포가 미친 생각으로 취급되던 시점이며, 현재 다크 팩토리 논쟁과 대비되는 출발점이다.
• 10배 개인 생산성의 한계: 한 사람이 10배 빨라지는 것보다, 한 번의 시스템 개선이 모든 사람에게 적용되는 편이 더 큰 조직 승수를 만든다.
• 세네 개의 파브드 로드: 모든 팀에 하나의 방식을 강제하기보다 관리되는 3~4개의 선택지를 제공하는 현실적 타협안이다.
• 최소 세 명으로 늘어나는 팀: 만능 인력 한 명에 상호보완적 역할, 휴가 백업, 운영·티켓 처리를 더하면 실제 팀 규모가 커진다.
• 두 가지 핵심 지표: 에이전트가 올바르게 일하기까지 필요한 인간의 개입 횟수와, 공유 시스템 개선이 여러 사람에게 미치는 승수다.

결론 및 시사점

1. 에이전트가 아직 작동하지 않는다는 반응을 기술의 한계로 단정하지 말고 팀과 조직의 준비 부족으로 해석한다.
2. 개발자의 역할을 프롬프트 작성자로 축소하지 말고, 컨텍스트·하네스·도구·평가 시스템을 만드는 엔지니어로 확장한다.
3. 에이전트가 만든 코드의 매번 수정하는 대신, 반복 실패를 회고해 시스템·가이드라인·검증기를 개선한다.
4. 계획 단계에서 에이전트가 바로 처리할 수 있는 명확한 작업과 사람이 대화로 결정할 작업을 분리한다.
5. 개발팀의 하네스를 요구사항 수집, GTM, 사용자 지원, 운영까지 연결해 전체 가치 흐름의 병목을 줄인다.
6. 휴먼 터치, 실행 턴, 비용, 재사용률을 측정해 라이선스 수나 막연한 생산성 주장보다 개선의 여정을 증명한다.
7. 플랫폼 팀과 개발자 경험 팀 사이에 중앙 오너를 두고 스킬 레지스트리·평가·가드레일·정체성·비용 가시성을 공용 서비스로 만든다.
8. 공용 구성요소는 테스트 가능성·확장성·보안·유지보수 책임을 갖춘 파브드 로드로 운영하며, 무관리 스킬 스프롤을 막는다.
9. 모든 팀에 하나의 방법을 강제하기보다 관리되는 3~4개의 경로를 제공하고, 중앙 경로를 가장 쉽게 선택할 수 있게 만든다.
10. 기능의 위험도에 따라 마이크로매니지먼트와 자율 승인의 수준을 다르게 정하고, 출처 추적·검증·상황 인식을 갖춘다.
11. 채용에서는 새 직함보다 AI 활용, 엔지니어링 판단, 협업과 공유 가능성을 과제로 검증하고, 부족한 영역은 멘토링으로 보완한다.
12. 최종 목표는 사람을 제거하는 공장이 아니라, 스킬·컨텍스트·하네스에 지식을 축적해 안정성을 유지하면서 시스템을 계속 바꾸고 학습하는 조직이다.