가드레일과 도입 전 점검

이 장에서 배우는 것 세 가지 가드레일과 각각을 어디에 거는지, 그리고 도입 전 자가 점검표.

속도를 올리면 틀리는 속도도 올라갑니다

가드레일은 브레이크가 아닙니다.

속도를 늦추는 장치가 아니라, 그 속도를 감당할 수 있게 만드는 조건입니다.

세 가지를 봅니다.

가드레일 1 — Human-in-the-Loop

무엇인가

중요한 비즈니스 로직 변경은 명시적인 사람의 승인을 거칩니다.

어디에 거나

이게 설계의 핵심입니다.

graph TD
  A["변경"] --> B{"되돌릴 수 있나?"}
  B -->|"예"| C["자동 진행"]
  B -->|"아니오"| D["사람 승인"]

실무에서 승인이 걸리는 지점들입니다.

너무 많이도 너무 적게도 안 됩니다

되돌릴 수 있는가를 기준으로 삼으면 대체로 적정선이 나옵니다.

가드레일 2 — 환각 통제

무엇인가

AI는 그럴듯하게 틀립니다. 코드가 컴파일되고 리뷰를 통과해도 의도와 다를 수 있습니다.

이걸 막는 것은 리뷰가 아니라 결정론적인 테스트 스위트입니다.

필요한 것

코드가 소모품이라는 명제가 성립하는 유일한 조건이 이것입니다. 테스트가 부실하면 재생성은 개선이 아니라 도박입니다.

가드레일 3 — 비용 관리

무엇인가

에이전트가 쉬지 않고 돈다는 것은 토큰을 쉬지 않고 쓴다는 뜻입니다. 모든 작업에 가장 비싼 모델을 붙이면 비용이 통제를 벗어납니다.

모델 라우팅 (Model Routing)

모든 작업에 최고 성능의 모델을 붙이면 토큰 비용이 기하급수적으로 증가합니다. 작업의 복잡도와 추론 요구량에 따라 모델을 지능적으로 분기합니다.

사이클이 분 단위로 짧을수록 이 라우팅 선택이 수백 번 일어나므로 비용 절감 효과가 기하급수적으로 누적됩니다.

그 외 통제 장치

Connect의 사용량 화면에서 보는 것이 이 데이터입니다. 총액이 아니라 분포를 봐야 합니다.

도입 전 자가 점검

방법론을 넣기 전에 조직이 갖춰야 하는 것들입니다. 하나라도 비어 있으면 그것부터 채우는 편이 빠릅니다.

첫 줄이 절대 조건입니다. 나머지는 없어도 부분 도입이 가능하지만, 테스트가 없으면 이 방법론은 위험하기만 합니다.

어떤 조직에 맞나

맞는 경우

• 고객 요구가 빠르게 바뀌는 곳
• 기능 출시 속도가 경쟁력인 곳
• 테스트·모니터링이 이미 성숙한 곳
• 기술 거버넌스가 서 있는 곳

권하지 않는 경우

• 테스트 문화가 없는 조직 — 속도만 올라가고 품질 판정은 아무도 못 하는 상태가 됩니다
• 규제상 모든 변경에 사람 검토가 법으로 요구되는 영역
• 배포가 분기 단위로 묶여 있는 환경 (먼저 그것부터)

확인

1. 승인 지점을 정하는 기준 한 줄은?

2. "코드는 소모품"이 성립하는 유일한 조건은?

3. 도입 전 점검에서 절대 조건 하나는?

AI Transformation 트랙이 끝났습니다. 이제 이 개념들이 실제 제품에서 어떻게 구현되어 있는지 봅니다 → 내 컴퓨터의 HyperTeams · Connect 둘러보기