15장. 팀과 조직에 도입한다

다음은 여러 현장에서 반복된 패턴을 합친 합성 사례로, 등장하는 숫자는 설명을 위한 예시 수치다.

한 회사가 모든 개발자에게 코딩 에이전트 계정을 제공하고 “AI 우선”을 선언했다. 팀마다 다른 규칙과 도구를 만들었고, 보안팀은 실행 기록을 볼 수 없어 고위험 기능을 막았다. 플랫폼팀은 중앙 시스템을 강제했지만 제품팀의 작업 방식과 맞지 않아 우회가 늘었다. 도구는 배포됐지만 공통의 안전 경계와 학습 루프는 없었다.

조직 도입은 라이선스 배포가 아니다. 어떤 일을 어떤 조건에서 위임하고, 누가 공장과 결과를 책임지며, 성공과 실패를 어떻게 학습할지 바꾸는 운영 설계다.

이번 장의 약속

• 반복 가능하고 위험이 낮은 첫 업무를 고른다.
• 팀, 플랫폼, 보안, 제품 책임을 분명히 나눈다.
• 30·60·90일 도입을 증거 기반 단계로 운영한다.
• 생산성 감시가 아닌 공정 개선 지표와 학습 문화를 만든다.

기술보다 먼저 위임 경계를 합의한다

작업을 세 구역으로 나눈다.

기본 허용

실패 영향이 낮고 판정이 강한 작업이다. 문서 링크 수정, 결정론적 코드 생성, 테스트 보강, 작은 내부 리팩터링 등이 후보가 될 수 있다.

조건부 허용

정해진 격리·게이트·사람 승인이 있을 때 수행한다. 공개 API, 데이터 마이그레이션, 새 의존성, 권한 변경 등이다.

금지 또는 별도 통제

검증되지 않은 운영 삭제, 비밀의 모델 입력, 승인 없는 외부 메시지·배포, 법적 판단 자동화처럼 현재 하니스가 위험을 제어하지 못하는 행동이다.

이 목록은 영구적이지 않다. 평가와 운영 증거가 쌓이면 조건부 업무를 넓힐 수 있고, 사건 뒤에는 좁힐 수 있다. 변경 권한과 검토 주기를 정한다.

책임 지도

생성된 변경의 책임은 도구에 귀속되지 않는다. 통합을 승인하고 운영하는 조직이 기존 소프트웨어와 같은 책임 체계를 유지한다.

플랫폼을 제품으로 운영한다

중앙 플랫폼은 다음을 제공한다.

• 작업·명세 스키마와 템플릿
• 격리 실행과 최소 권한 기본값
• 공통 게이트 어댑터와 이벤트 스키마
• 평가 세트 실행과 기준 비교
• 비용·WIP·실패 분포 관측
• 승인·감사·사건 대응 연결
• 실제 에이전트 교체를 위한 검증된 어댑터 계약과 주입 경계

제품팀은 도메인 명세, 지역 안내서, 제품 테스트, 위험별 승인자를 소유한다. 중앙 플랫폼이 모든 도메인 규칙을 알 수 없고, 각 팀이 샌드박스와 감사 체계를 제각각 만들 필요도 없다.

플랫폼 성공은 등록 저장소 수보다 다음으로 본다.

• 첫 성공 작업까지 걸리는 시간
• 실패 진단과 복구 시간
• 기본 경로를 우회하지 않는 비율
• 팀이 직접 추가한 재사용 게이트
• 업그레이드로 깨진 작업 수
• 지원 요청의 원인 분포

성숙도 네 단계

0. 개인 도구

사람이 대화를 통해 코드를 만들고 모든 단계와 책임을 직접 관리한다. 학습에는 유용하지만 재현성과 조직 관측은 약하다.

1. 안내된 단일 작업

저장소 안내, 승인 명세, 격리 공간, 공통 테스트, 사람 리뷰가 있다. 첫 도입 목표다.

2. 통제된 파이프라인

작업 계약, 구조 게이트, 이벤트, 위험 기반 승인, 평가 세트가 있다. 반복 업무를 안정적으로 위임한다.

3. 제한된 병렬 공장

DAG, WIP 한도, 독립 리뷰, 병합 큐, 장기 작업 복구가 있다. 독립 업무군에서 병렬 처리한다.

각 저장소와 업무군은 다른 단계에 있을 수 있다. 조직 선언으로 단계를 건너뛰지 않는다.

첫 업무 선택 워크숍

후보를 다음으로 평가한다.

빈도
판정 가능성
실패 격리
되돌리기
문맥 준비도
현재 사람 시간
도메인/보안 위험

첫 후보는 점수가 높고 팀이 실제로 귀찮아하는 일이어야 한다. 사용 빈도가 낮은 멋진 데모는 학습 데이터를 만들지 못한다.

좋은 후보 예:

• 정해진 패턴의 API 필드 추가
• 도메인 규칙에 대한 테스트 보강
• 버전 업과 호환성 수정
• 반복적인 코드 모드 변경
• 문서와 코드 링크 신선도 검사

주의할 후보:

• 요구가 계속 바뀌는 신규 제품 전체
• 운영 장애의 자동 수정·배포
• 소유자 없는 레거시 대수술
• 개인정보·금전 이동이 포함된 범용 작업

30일: 한 흐름을 닫는다

목표는 한 업무군의 기준선과 최소 공장이다.

1주

• 최근 작업 10~20개의 흐름·품질·사람 시간 기준선을 수집한다.
• 위임 경계와 중단 기준을 승인한다.
• 제품, 저장소, 플랫폼, 보안 소유자를 정한다.

2주

• 저장소 안내와 승인 명세 템플릿을 만든다.
• 결정론적 모의 어댑터로 성공·차단·정책 위반을 검증한다.

3주

• 작업자 주입 경계와 제품별 변환 어댑터를 구현해 실제 에이전트를 격리된 단일 작업에 연결한다.
• 모든 결과는 사람 리뷰 뒤 수동 통합한다.

4주

• 기준선과 리드 타임, 첫 시도 통과, 사람 시간, 실패 분포를 비교한다.
• 계속·수정·중단 결정을 문서화한다.

30일의 성공은 자동화율이 아니라 반복 가능한 증거와 학습이다.

60일: 공통 경계를 강화한다

• 반복 실패를 명세 검사·구조 게이트·저장소 안내 개선으로 옮긴다.
• 대표 작업과 실패 주입 평가 세트를 만든다.
• 이벤트 스키마와 개인정보 필터를 표준화한다.
• 낮은 위험 작업에 제한된 독립 리뷰를 도입한다.
• 팀 두 곳 이상에서 같은 온보딩 경로를 검증한다.
• 공장 자체의 온콜/지원과 변경 관리 소유자를 정한다.

팀마다 프롬프트 템플릿을 복제하는 대신 공통 하니스와 지역 도메인 지식의 경계를 찾는다.

90일: 증거가 있는 곳만 확장한다

• 실제 독립 작업에만 동시성을 2→4처럼 단계적으로 늘린다.
• 후단 WIP와 사람 리뷰 용량을 함께 제한한다.
• 낮은 위험·강한 판정 업무만 자동 통합 후보로 삼는다.
• 장기 작업 체크포인트와 작업자 손실 훈련을 실행한다.
• 모델·도구 변경을 평가 게이트 뒤에 배포한다.
• 분기별 위임 경계와 사건 학습 검토를 운영한다.

90일 뒤에도 제품 의미와 고위험 판단은 명시적 사람이 소유한다.

교육은 프롬프트 강의로 끝나지 않는다

역할별로 배울 내용이 다르다.

개발자

명세 예시와 불변 조건, 작은 작업 계약, 인계, 게이트 실패 진단, 생성 코드 리뷰를 실습한다.

테크리드

저장소 지도, 구조 규칙, 작업 그래프, 병렬성·통합 비용, 위험 기반 완료 정의를 설계한다.

플랫폼/보안

격리 위협 모델, 최소 권한, 이벤트 데이터 분류, 평가와 변경 배포, 사건 대응을 훈련한다.

리더

생성량이 아닌 흐름·품질·사람의 주의 지표, 도입 중단 기준, 책임 경계를 배운다.

좋은 교육 과제는 성공 데모뿐 아니라 명세 차단, 경로 공격, 불안정 테스트, 늦은 결과를 직접 복구하게 한다.

심리적 안전과 실패 기록

에이전트 작업 실패를 개인의 능력 평가에 사용하면 사람은 실패를 숨기고 수동 우회한다. 공정 개선을 위해 다음 원칙을 둔다.

• 실행 실패율을 개인 순위로 쓰지 않는다.
• 사람 개입을 자동화 실패가 아니라 필요한 판단 데이터로 분류한다.
• 사건 회고는 모델 탓으로 끝내지 않고 명세·도구·정책·게이트를 본다.
• 우회를 처벌하기 전에 기본 경로가 왜 불편했는지 측정한다.
• 고위험 행동을 안전하게 차단한 사례를 좋은 결과로 인정한다.

사건 대응

에이전트 관련 사건도 기존 소프트웨어 사건 관리에 통합한다.

탐지 → 영향 제한 → 실행/자격 증명 중단 → 증거 보존
    → 영향 분석 → 복구/회전 → 원인 분류 → 평가·게이트 개선

필요한 증거:

• 작업·실행·명세·정책 버전
• 도구 행동과 승인
• 작업 공간과 patch 해시
• 외부 효과와 자격 증명 범위
• 게이트·리뷰·통합 이벤트

모델의 숨은 사고 내용을 사건 근거로 기대하지 않는다. 관찰된 입력 출처와 행동을 기록한다.

빌드 대 구매와 벤더 교체

모델·도구를 평가할 때 데모 성능 외에 본다.

• 작업/도구/이벤트의 내보내기 가능성
• 격리와 데이터 경계
• 모델·도구 버전 고정과 변경 알림
• 사용량·비용 원시 데이터
• 정책·승인 통합
• 장애 시 대체·중단 경로
• 평가 세트에서의 실제 업무 프로필

공장의 작업 계약, 명세, 게이트, 산출물은 특정 벤더 대화 형식에 묶지 않는다. 어댑터를 얇게 유지해야 교체 실험이 가능하다.

실습: 팀 도입 문서 만들기

다음 한 페이지를 팀과 함께 채운다.

# 에이전트 공장 도입 계약

## 첫 업무군
## 범위 밖 업무
## 성공 가설과 중단 기준
## 제품/저장소/플랫폼/보안 소유자
## 필수 명세·게이트·사람 승인
## 제공할 데이터와 금지 데이터
## 기준 지표와 30일 검토일
## 사건 연락·실행 중단·자격 증명 회전
## 확장 조건

리더의 구두 승인보다 버전 관리되는 계약으로 남긴다.

왜 실패하는가

전사 도입을 먼저 선언한다

업무군별 판정 가능성과 위험이 다르다. 한 팀·한 흐름의 증거에서 시작해 재사용 경계를 찾는다.

자동화율을 목표로 둔다

사람 승인이 필요한 고위험 작업까지 억지로 자동화한다. 검증된 가치 흐름과 사람 주의의 이동을 측정한다.

중앙 플랫폼이 모든 규칙을 소유한다

도메인 의미가 낡고 팀이 우회한다. 중앙은 실행 안전과 공통 계약, 제품팀은 명세와 지역 게이트를 소유한다.

사건을 모델의 환각으로 끝낸다

왜 잘못된 행동이 권한을 얻고 게이트를 통과했는지 개선하지 못한다. 시스템 원인과 방어 공백을 찾는다.

운영 판단: 다음 팀으로 확장할 조건

• 첫 팀에서 같은 업무군을 여러 번 실행해 기준선과 비교했다.
• 정책 위반과 심각 결함이 정의된 한도 안이다.
• 실패의 대부분을 재현하고 소유자에게 라우팅할 수 있다.
• 온보딩 문서로 새 개발자가 도움 없이 첫 작업을 완료한다.
• 플랫폼 운영·사건·업그레이드 소유자가 있다.
• 제품팀이 지역 명세와 게이트를 실제로 소유한다.
• 확장이 후단 리뷰와 CI 용량을 초과하지 않는다.

연습문제

1. 팀 업무 열 개를 기본 허용, 조건부, 금지/별도 통제로 분류하고 근거를 적어라.
2. 제품팀과 플랫폼팀 사이의 책임 충돌 가능성이 큰 항목 세 개를 RACI 또는 책임 표로 정리하라.
3. 실제 업무군 하나로 30일 도입 가설, 중단 기준, 측정값을 작성하라.
4. 에이전트 생성 코드로 보안 사건이 났다고 가정하고 모델 밖의 시스템 원인을 다섯 번 ‘왜’로 추적하라.

체크포인트

• 업무군별 위임 경계와 책임 소유자가 승인됐다.
• 30일은 한 흐름, 60일은 공통 경계, 90일은 증거 있는 확장으로 설계됐다.
• 성과 지표가 개인 감시가 아니라 공정 개선에 쓰인다.
• 공장 변경, 장애, 보안 사건의 운영 소유권이 있다.

다음 장에서는 지금까지 만든 모든 층을 하나의 주문 처리 공장으로 조립한다. 깨끗한 환경에서 성공·실패·복구·병렬·리뷰·관측을 실행하고 출간용 화면까지 같은 결과에서 생성한다.