검증 게이트 오너십 — 자동화되는 것은 실행이고, 남는 것은 기준이다

AI가 작성하는 코드의 비중이 빠르게 늘고 있다. 동시에 검증 도구 자체도 벤더화되고 있다 — Playwright 기반 E2E 에이전트가 테스트를 대신 돌리고, VLM이 시각 회귀 diff를 판정한다. "검증마저 자동화되면 개발자에게 남는 게 뭔가"라는 질문이 자연스럽게 나온다.

상황

이 질문에 답하려면 검증을 하나의 덩어리로 보지 말고 두 층으로 쪼개야 한다.

문제

검증에는 서로 성격이 다른 두 가지가 섞여 있다.

검증 실행: 테스트를 돌리고, 스크린샷을 비교하고, 메트릭을 수집하는 행위. 도구가 하는 일이고, 벤더가 잘한다.
검증 기준: 얼마나 느리면 실패인가. 어떤 픽셀 차이가 결함이고 어떤 것이 의도된 변경인가. 어느 메트릭이 떨어지면 배포를 막아야 하는가.

두 번째는 벤더가 가져갈 수 없다. 임계값은 자사 RUM 데이터에 묶여 있고, 결함의 정의는 자사 비즈니스 맥락에 묶여 있다. 같은 200ms 지연도 검색 결과 페이지에서는 실패고 관리자 화면에서는 허용일 수 있다. 이 판단의 근거 데이터와 책임은 조직 바깥으로 이전되지 않는다.

flowchart LR
    subgraph vendor["벤더화 가능 — 검증 실행"]
        A[E2E 에이전트<br/>Playwright]
        B[VLM 시각 diff]
        C[메트릭 수집기]
    end
    subgraph org["이전 불가 — 검증 기준"]
        D[임계값<br/>자사 RUM 기반]
        E[결함 정의<br/>비즈니스 맥락]
        F[게이트 운영 책임<br/>배포 차단/통과 판단]
    end
    A --> D
    B --> E
    C --> F

접근과 판단

이 구분이 일시적 현상이 아니라 반복되는 패턴이라는 근거로 두 개의 전례가 있다.

전례 1 — SRE와 CI/CD. 배포 파이프라인 도구는 지난 20년간 꾸준히 벤더화됐다. Jenkins에서 GitHub Actions로, 자체 모니터링에서 Datadog으로. 그런데 사내에서 배포 게이트를 설계하고 운영하는 사람의 가치는 떨어지지 않고 오히려 올라갔다. 배포 자동화는 운영자를 없앤 것이 아니라, "어떤 조건에서 배포를 막을 것인가"를 설계하는 더 비싼 직군을 만들었다. 도구는 사왔지만 게이트는 사올 수 없었기 때문이다.

전례 2 — SQL과 DBA. SQL 문법 지식이 상식화되면서 'SQL 개발자'라는 직함은 소멸했다. 그러나 데이터 정합성 게이트를 소유하던 DBA는 사라지지 않고 데이터 엔지니어로 진화했다. 살아남은 것은 문법 숙련자가 아니라, "이 데이터가 신뢰할 수 있는가"를 판정하는 기준의 소유자였다.

두 전례의 공통 구조: 실행 계층이 상품화될 때, 기준 계층의 소유자는 오히려 희소해진다.

구현

이 원칙을 AI 코드 도입 조직에 적용하면 병목의 위치가 예측된다.

핵심 동인은 책임 비대칭이다. AI 작성 코드 비중이 30%를 넘어도, 배포 사고의 책임은 AI에게 0% 이전된다. 사고가 나면 게이트를 통과시킨 사람이 책임진다. 그런데 코드 생산 속도가 사람의 코드 리딩 속도를 초과하는 순간, 라인 단위 검수는 물리적으로 불가능해진다.

그러면 검수는 코드 층에서 행동 층으로 올라갈 수밖에 없다.

라인 리뷰 대신 E2E 시나리오: "이 코드가 맞는가" 대신 "이 동작이 맞는가"
스타일 검토 대신 시각 회귀: 렌더링 결과물 자체를 검증
로직 추적 대신 메트릭 게이트: 성능·에러율 임계값으로 배포를 차단

이 행동 층 게이트의 임계값을 자사 데이터로 설정하고, 게이트가 울렸을 때 차단/통과를 판정하고, 오탐과 미탐을 튜닝하는 역할 — 이것이 벤더도 AI도 가져갈 수 없는 자리다.

결과

이 판단을 커리어 포지셔닝에 적용할 때 한 가지 함정이 있다. 특히 한국 시장에서 '검증을 소유한다'는 표현은 QA 직군 전환으로 오독되기 쉽고, 그렇게 읽히는 순간 감가된다.

패키징 원칙:

직함은 '배포 관문 설계·운영자'로 — 테스터가 아니라 게이트의 아키텍트
반드시 피처 딜리버리 실적과 병기 — 검증만 하는 사람이 아니라, 만들면서 관문도 설계하는 사람
팔리는 것은 하네스 코드가 아니다 — 도입 전후 수치(사고율, 배포 빈도, 리드타임)와 게이트 운영 기록이다

배운 것

자동화 물결 앞에서 "무엇이 자동화되는가"보다 "무엇이 이전 불가능한가"를 먼저 물어야 한다. 이전 불가능성의 근거는 대개 두 가지다: 자사 데이터에 묶인 기준, 그리고 사고 책임.
실행 계층의 상품화는 기준 계층 소유자의 가치를 올린다. CI/CD와 SQL에서 두 번 반복된 패턴이고, AI 코드 검증에서 세 번째로 반복될 가능성이 높다.
병목은 곧 포지션이다. 코드 생산이 무한히 빨라지는 조직에서 병목은 배포 관문으로 이동하며, 병목을 소유한 사람이 조직에서 가장 대체하기 어렵다.