개념
한 서비스에서 도는 것과 조직에서 도는 것은 다르다
레슨 1~6으로 서비스 하나에 기준·스킬·세 층 파이프라인·게이트·지표를 붙였다. 채용 공고가 "주간 배포 게이트를 운영하기 시작한 단계라, AI가 검증하는 서비스를 넓히는 것으로 업무를 시작합니다"라고 쓴 상황이 바로 여기다.
첫 서비스는 대개 QA가 직접 손으로 붙인다. 다섯 번째 서비스부터는 그렇게 할 수 없다. 확장은 같은 일을 여러 번 하는 것 이 아니라 남이 스스로 붙일 수 있게 만드는 것 이다. 이 레슨의 목표는 서비스 하나를 붙이는 절차를 표준화하고, 서비스마다 다른 속도로 가도 게이트가 일관되게 작동하게 하는 것이다.
어느 서비스부터 붙일 것인가
모든 서비스를 동시에 시작하면 어느 것도 끝나지 않는다. 우선순위를 네 축으로 매긴다.
| 축 | 질문 | 높은 점수 |
|---|---|---|
| 위험 | 이 서비스의 결함이 고객·데이터·과금에 얼마나 영향을 주는가 | 과금·인증·데이터 삭제 경로 |
| 변경 빈도 | 이 서비스는 얼마나 자주 바뀌는가 | 매주 배포, AI 에이전트 사용 비율 높음 |
| 준비도 | API 명세·테스트 환경·기존 테스트가 있는가 | OpenAPI 명세, 스테이징 배포 자동화 |
| 협력 의지 | 서비스 팀이 원하는가 | 최근 운영 사고 경험, 리드가 요청 |
위험과 변경 빈도가 왜 붙여야 하는가 를, 준비도와 협력 의지가 지금 붙일 수 있는가 를 말한다. 첫 확장 대상은 네 축이 모두 중간 이상인 서비스로 고른다. 위험만 높고 준비도가 0인 서비스를 먼저 고르면 몇 달째 "환경 만드는 중"에 머물고, 확장 자체가 실패한 사례로 기억된다.
[확장 후보 점수 — 예시, 각 1~5]
서비스 위험 변경 준비도 협력 비고
과금·사용량 계량 5 3 2 4 명세 없음 → 명세 작성부터 1단계
추론 엔드포인트 4 5 4 5 ← 다음 확장 대상
학습 작업 스케줄러 4 4 3 3
콘솔 프런트엔드 3 5 4 2 리드가 E2E 부담 우려 → 협의 필요
모니터링 수집기 2 2 3 3서비스 하나를 온보딩하는 여덟 단계
| 단계 | 산출물 | 주 담당 |
|---|---|---|
| 1. 범위 합의 | 대상 API·화면·비동기 작업 목록, 제외 범위 | QA + 서비스 리드 |
| 2. 위험 지도 | 이 서비스의 치명·높음 위험 목록 (모듈 4 레슨 2 방식) | QA 주도, 서비스 팀 검토 |
| 3. 기준 초안 | 위험별 결정적·해석 기준, 다섯 칸 (레슨 1) | QA 초안, 서비스 팀 검토 |
| 4. 스킬 배포 | 도메인 검증 스킬, AGENTS.md 한 줄 (레슨 2) | QA |
| 5. 파이프라인 연결 | 변경 영향 지도, PR·회귀 층 잡, 판정 레코드 출력 (레슨 4) | 서비스 팀 + QA 지원 |
| 6. 판정자 보정 | 해석 기준이 있으면 골드 세트와 보정 기록 (레슨 3) | QA |
| 7. 관찰 운영 | 게이트에 경고만 내는 기간, 2~4주 | QA |
| 8. 차단 전환 | 차단 규칙 활성화, 게이트 요약에 서비스 포함 | QA + 플랫폼 책임자 승인 |
7단계가 핵심이다. 새 서비스를 바로 차단 게이트에 넣으면 첫 주에 환경·데이터·테스트 결함으로 인한 거짓 차단 이 쏟아진다. 서비스 팀은 게이트를 방해물로 기억하고, 예외 요청이 폭증한다. 관찰 기간에는 경고만 내면서 거짓 차단 비율(레슨 6)을 재고, 합의한 수준 아래로 내려가면 차단으로 전환한다.
[차단 전환 조건 — 예시]
- 관찰 기간 최소 3회 연속 회귀 실행
- 거짓 차단 비율 10% 이하 (최근 2주)
- 필수 기준 미실행 0
- 해석 기준이 있으면 판정자 보정 승인
- 서비스 리드 서명검증 성숙도 0~4단계
모든 서비스가 같은 속도로 가지 않는다. 서비스별 현재 위치를 공용 단계로 표시하면 게이트가 서비스마다 다른 수준으로 적용돼도 혼란이 없다.
| 단계 | 상태 | 게이트 적용 |
|---|---|---|
| 0 미연결 | 파이프라인에 없음. 수동 확인 | 게이트 요약에 "미검증 서비스"로 표시, 변경 포함 시 서비스 리드 확인 서명 |
| 1 기준 정의 | 위험 지도·기준 초안 있음, 자동 판정 없음 | 기준 목록을 사람이 체크리스트로 확인 |
| 2 결정적 자동화 | 결정적 기준이 PR·회귀에서 판정 레코드로 나옴 | 결정적 기준 차단, 해석 기준은 사람 확인 |
| 3 AI 판정 통합 | 보정된 판정자로 해석 기준 자동 판정, 스킬 배포 | 전체 차단 규칙 적용 |
| 4 자기 개선 | 탈출 결함 역추적이 기준 추가로 자동 이어짐, 지표 기반 월간 개선 | 전체 차단 + 기준 추가 리드타임 지표 |
0단계 서비스를 게이트에서 숨기지 않는 것 이 중요하다. 게이트 요약이 "통과 412/412"라고만 쓰면 읽는 사람은 전 서비스가 검증됐다고 생각한다. 미검증 서비스의 변경이 이번 후보에 포함됐다면 요약 맨 위에 적는다. 모듈 31 레슨 1의 "무엇을 시험하지 않을 것인가"를 선언하는 원칙과 같다.
협의를 먼저 끌어내는 법
확장의 가장 큰 병목은 기술이 아니라 다른 팀의 시간 이다. 파이프라인 연결(5단계)은 서비스 팀이 해야 하고, 서비스 팀에게 그것은 자기 백로그 밖의 일이다. 자격요건의 "개발·인프라 등 다른 팀과의 협의를 먼저 끌어내 본 경험"이 여기서 필요하다.
협의를 끌어내는 데 효과가 컸던 방식들이다.
| 방식 | 구체적으로 |
|---|---|
| 그 팀의 사고에서 시작 | "지난달 추론 엔드포인트 삭제 후 과금이 계속된 인시던트, 이 기준 세 줄이면 PR에서 잡혔습니다" — 기준 초안을 그 팀의 사고 기록으로 증명 |
| 첫 기여를 QA가 가져간다 | 1~4단계는 QA가 끝낸 상태로 찾아간다. 서비스 팀에게는 검토와 5단계만 요청 |
| 비용을 숫자로 | 5단계 예상 작업량(잡 2개, 레코드 출력 어댑터 1개, 약 3일)을 제시 |
| 관찰 기간을 약속 | "첫 3주는 경고만 냅니다. 거짓 차단 비율이 10% 아래로 내려가기 전엔 막지 않습니다" |
| 되돌릴 수 있게 | 차단 전환 후에도 거짓 차단이 늘면 경고로 되돌리는 조건을 문서에 명시 |
| 인프라 팀에는 환경 요청을 묶어서 | 서비스마다 따로 요청하지 않고 분기 단위로 "PR 임시 환경·GPU 회귀 노드" 요구를 모아 한 번에 |
반대로 협의를 망치는 방식도 분명하다. "QA 정책이라서 붙여야 합니다" 로 시작하는 것, 기준 초안 없이 "테스트를 만들어 달라"고 요청하는 것, 관찰 기간 없이 바로 막는 것이다.
확장 중에 무너지는 지점
| 무너지는 지점 | 증상 | 예방 |
|---|---|---|
| 기준 ID 체계 파편화 | 서비스마다 ID 규칙이 달라 집계 불가 | 첫 서비스에서 ID 규칙을 문서화하고 스킬 템플릿에 박아 둔다 |
| 판정 레코드 형식 분기 | "우리 서비스는 필드 하나 더 필요" 가 반복되어 형식이 갈라짐 | 확장 필드는 extra 객체로, 공통 필드는 변경 리뷰 필수 |
| 스킬 복붙 | 서비스 팀이 기존 스킬을 복사해 고쳐 씀, 원본 개선이 전파 안 됨 | 공용 절차 스킬 + 도메인 기준 references 로 분리 |
| QA 병목 | 모든 기준 초안·보정을 QA 한두 명이 처리 | 서비스 팀에 "기준 챔피언" 한 명, QA는 검토·보정 담당으로 |
| 판정자 보정 누락 | 새 도메인에 기존 판정자를 그대로 씀 | 새 도메인은 재보정 필수 (레슨 3) |
| 게이트 요약 비대화 | 서비스가 늘어 요약이 수십 쪽 | 서비스별 요약은 접고, 차단·경고·미검증만 첫 화면에 |
확장 계획을 한 장으로
[AI 검증 확장 계획 — 2026 Q4]
현재: 성숙도 3 — compute / 2 — storage, network / 1 — train / 0 — infer, billing, console
목표: 분기 말 성숙도 3 — compute, infer / 2 — train, storage, network / 1 — billing, console
분기 우선 대상: infer (위험 4, 변경 5, 준비 4, 협력 5)
W40 범위·위험 지도 W41 기준 초안·스킬 W42 파이프라인 연결 W43 판정자 보정
W44~46 관찰 운영 W47 차단 전환 판정
병행: billing 명세 작성 지원 (0 → 1), console 리드와 E2E 범위 협의
필요 자원: 추론 회귀용 GPU 노드 2 (인프라팀 요청 W40), infer팀 기준 챔피언 1
측정: 서비스별 기준 커버리지, 거짓 차단 비율, PR 발견 비율 (레슨 6)
위험: infer 해석 기준(모델 응답 품질) 골드 세트 라벨러 확보 — 확보 실패 시 결정적 기준만으로 2단계 유지마지막 줄처럼 계획이 실패할 수 있는 지점과 그때의 대안 을 적어 두면, 분기 말에 목표를 못 채워도 "어디까지 왜 됐는가"를 설명할 수 있다.
실무에서 왜 필요한가
AI 검증 자동화를 도입한 조직의 상당수가 "한 팀에서는 잘 되는데 퍼지지 않는다"에서 멈춘다. 첫 서비스는 열정적인 개인이 손으로 붙였고, 그 방법이 문서화되지 않았으며, 두 번째 팀은 게이트가 첫 주부터 막아서 반감을 가졌다. 확장을 설계하는 QA는 기준을 쓰는 사람에서 표준을 만드는 사람 으로 역할이 바뀐다.
공고가 "아직 붙지 않은 서비스로 확장"과 "지금 설계하는 기준이 곧 팀의 표준"을 같이 쓰는 것도 그래서다. 첫 확장에서 정한 ID 규칙· 레코드 형식·온보딩 단계·성숙도 정의가 이후 모든 서비스에 복제된다. 처음에 조금 더 신경 쓴 규칙이 스무 개 서비스에서 비용을 아낀다.