# 가드레일과 도입 전 점검
> **이 장에서 배우는 것**
> 세 가지 가드레일과 각각을 어디에 거는지, 그리고 도입 전 자가 점검표.
## 속도를 올리면 틀리는 속도도 올라갑니다
가드레일은 브레이크가 아닙니다.
> **속도를 늦추는 장치가 아니라, 그 속도를 감당할 수 있게 만드는 조건입니다.**
세 가지를 봅니다.
---
## 가드레일 1 — Human-in-the-Loop
### 무엇인가
**중요한 비즈니스 로직 변경은 명시적인 사람의 승인을 거칩니다.**
### 어디에 거나
이게 설계의 핵심입니다.
```mermaid
graph TD
A["변경"] --> B{"되돌릴 수 있나?"}
B -->|"예"| C["자동 진행"]
B -->|"아니오"| D["사람 승인"]
```
실무에서 승인이 걸리는 지점들입니다.
| 영역 | 예 |
|---|---|
| 돈이 움직이는 경로 | 결제, 정산, 환불, 가격 |
| 권한과 접근 제어 | 역할 변경, 권한 부여 |
| 외부로 나가는 데이터 | 개인정보, 대외 API, 메일 발송 |
| 되돌리기 어려운 변경 | 스키마 마이그레이션, 데이터 삭제 |
### 너무 많이도 너무 적게도 안 됩니다
| | 결과 |
|---|---|
| 승인이 너무 많음 | 조율 비용이 돌아옴 → **애자일로 회귀** |
| 승인이 너무 적음 | 아무도 안 본 로직이 프로덕션에 |
**되돌릴 수 있는가**를 기준으로 삼으면 대체로 적정선이 나옵니다.
---
## 가드레일 2 — 환각 통제
### 무엇인가
AI는 [그럴듯하게 틀립니다](/guide/ai-hallucination). 코드가 컴파일되고 리뷰를
통과해도 의도와 다를 수 있습니다.
**이걸 막는 것은 리뷰가 아니라 결정론적인 테스트 스위트입니다.**
### 필요한 것
| 항목 | 왜 |
|---|---|
| **단위·통합·E2E를 함께** | 한 층만으로는 통과와 정상을 구분 못 함 |
| **샌드박스 환경** | 문제 코드가 프로덕션에 닿기 전 격리 |
| **테스트를 명세로 취급** | 코드에 맞춰 고치는 순간 방어선이 사라짐 |
> [코드가 소모품](/guide/ha-fluid-software)이라는 명제가 성립하는 **유일한 조건**이
> 이것입니다. 테스트가 부실하면 재생성은 개선이 아니라 도박입니다.
---
## 가드레일 3 — 비용 관리
### 무엇인가
에이전트가 쉬지 않고 돈다는 것은 **토큰을 쉬지 않고 쓴다**는 뜻입니다. 모든
작업에 가장 비싼 모델을 붙이면 비용이 통제를 벗어납니다.
### 모델 라우팅
작업 난이도에 모델을 맞춥니다.
| 작업 | 모델 |
|---|---|
| 형식 변환, 단순 분류, 반복 수정 | 가벼운 모델 |
| 설계, 어려운 진단, 복잡한 판단 | 강한 모델 |
사이클이 짧을수록 이 선택이 자주 일어나므로 **효과가 누적됩니다.**
### 그 외 통제 장치
```
□ 자가 치유 루프 최대 재시도 횟수
□ 작업당 비용 상한
□ 사용량 모니터링과 알림
```
[Connect의 사용량 화면](/guide/cn-usage)에서 보는 것이 이 데이터입니다.
총액이 아니라 **분포**를 봐야 합니다.
---
## 도입 전 자가 점검
방법론을 넣기 전에 조직이 갖춰야 하는 것들입니다. **하나라도 비어 있으면 그것부터
채우는 편이 빠릅니다.**
| 점검 항목 | 왜 필요한가 | 없으면 |
|---|---|---|
| 테스트 자동화가 신뢰할 만한가 | 프로세스 3의 판정 기준 | **전체가 성립 안 함** |
| 배포 파이프라인이 자동인가 | 프로세스 4 | 1~3만 도입 |
| 롤백이 빠른가 | 빨리 배포한 만큼 빨리 되돌려야 | 배포 주기를 늦춤 |
| 모니터링이 실시간인가 | 다음 사이클의 입력 | 루프가 안 닫힘 |
| 승인 지점이 합의됐는가 | 사후에 정하면 사고 뒤에 정함 | 먼저 합의 |
**첫 줄이 절대 조건입니다.** 나머지는 없어도 부분 도입이 가능하지만, 테스트가
없으면 이 방법론은 위험하기만 합니다.
## 어떤 조직에 맞나
**맞는 경우**
- 고객 요구가 빠르게 바뀌는 곳
- 기능 출시 속도가 경쟁력인 곳
- 테스트·모니터링이 이미 성숙한 곳
- 기술 거버넌스가 서 있는 곳
**권하지 않는 경우**
- **테스트 문화가 없는 조직** — 속도만 올라가고 품질 판정은 아무도 못 하는 상태가
됩니다
- 규제상 모든 변경에 사람 검토가 법으로 요구되는 영역
- 배포가 분기 단위로 묶여 있는 환경 (먼저 그것부터)
---
## 확인
**1. 승인 지점을 정하는 기준 한 줄은?**
답
**되돌릴 수 있는가**입니다. 너무 많이 걸면 조율 비용이 돌아와 애자일로 회귀하고,
너무 적게 걸면 아무도 안 본 로직이 프로덕션에 나갑니다.
**2. "코드는 소모품"이 성립하는 유일한 조건은?**
답
**테스트가 촘촘한 것**입니다. 재생성한 코드가 예전 동작을 유지하는지 보장하는 게
테스트뿐이라, 테스트가 부실하면 재생성은 도박이 됩니다.
**3. 도입 전 점검에서 절대 조건 하나는?**
답
**신뢰할 만한 테스트 자동화**입니다. 나머지 항목은 없어도 부분 도입이 가능하지만,
테스트가 없으면 이 방법론은 속도만 올리고 품질 판정은 못 하는 상태를 만듭니다.
---
**AI Transformation 트랙이 끝났습니다.** 이제 이 개념들이 실제 제품에서 어떻게
구현되어 있는지 봅니다 →
[내 컴퓨터의 HyperTeams](/guide/ht-what-is-it) · [Connect 둘러보기](/guide/cn-what-is-it)