파이프라인 하단부에서 벌어지는 일
AI-First 워크플로우 논의는 대부분 코드 생성과 리뷰에 집중된다. 그런데 요즘 흥미로운 신호들이 파이프라인 하단부—테스트 선택, 보안 취약점 탐지, 에이전트 권한 관리—에서 동시에 터지고 있다. 이 세 가지를 묶어서 보면 공통된 질문이 남는다. 자동화가 이 지점까지 내려왔을 때, 팀은 무엇을 직접 설계해야 하는가?
ML 기반 테스트 선택: 70~80% 단축의 실체
Dev.to에 올라온 한 프로토타입이 눈에 띈다. Playwright + scikit-learn + GitHub Actions 조합으로 커밋마다 변경된 파일을 분석해 영향받을 테스트만 선별 실행하는 구조다. src/services/inventory.js가 바뀌면 모델이 inventory.spec.js와 order.spec.js만 골라 돌리고, 전체 스위트는 야간 배치로 돌린다. 저자는 커밋당 테스트 시간을 70~80% 줄일 수 있다고 주장한다.
수치만 보면 솔깃하다. 그런데 현장에서 이걸 붙이기 전에 냉정하게 따져야 할 게 있다. 모델 신뢰도가 충분히 쌓이기 전까지 '선택되지 않은 테스트'가 놓치는 버그는 누가 잡나? 저자 본인도 '보수적 폴백 전략'과 '야간 전체 실행'을 반드시 유지하라고 명시한다. 즉, 이 접근의 핵심은 ML 모델 자체가 아니라 폴백 설계다. 히스토리 데이터가 부족한 초기에는 선택 범위를 넓게 잡고, 드리프트 모니터링과 재학습 주기를 파이프라인 설계에 처음부터 포함시켜야 한다. '빠른 피드백'이 목표라면, 그 속도를 보장하는 안전망 비용도 함께 설계에 넣어야 한다.
Codex Security: 보안 에이전트가 파이프라인에 들어올 때
OpenAI가 Codex Security를 공개했다. 코드 저장소를 분석해 취약점을 찾고, 검증하고, 수정안까지 제안하는 AI 보안 에이전트다. 베타 기간 30일 동안 120만 건 이상의 커밋을 스캔해 792건의 중요 취약점과 1만 561건의 고위험 취약점을 탐지했다는 수치가 인상적이다. 오탐률도 반복 분석을 거치며 50% 이상 줄었다고 한다.
몇 주 전 Anthropic의 Claude Code Security가 나왔고, 이제 OpenAI까지 같은 레인에 들어왔다. 보안 에이전트의 파이프라인 통합이 선택이 아닌 표준이 되어가는 속도가 예상보다 빠르다. 그런데 여기서 멈추면 안 된다. 오탐 50% 감소는 나머지 50%가 여전히 남아 있다는 뜻이기도 하다. 에이전트가 수정안을 '제안'하는 수준에서 '자동 적용'하는 방향으로 진화할수록, 팀이 설계해야 할 검증 게이트의 위치와 책임자가 명확해야 한다.
퍼미션 크립: 느린 문제가 빠른 위기가 되는 순간
Dev.to의 또 다른 글이 이 흐름에 중요한 경고를 던진다. 프로덕션 AI 에이전트의 90일 패턴이다. 처음엔 읽기 전용으로 시작한 에이전트가, 파일 쓰기 → Slack 알림 → 웹훅 트리거 순으로 권한을 쌓아간다. 각각의 추가는 합리적인 이유가 있었다. 하지만 아무도 전체를 돌아보지 않는다.
이건 AI 파이프라인에서도 정확히 같은 방식으로 일어난다. ML 테스트 선택 에이전트가 처음엔 테스트 목록만 생성하다가, 실패 시 재실행 트리거 권한을 받고, 그 다음엔 배포 파이프라인 제어권까지 얻게 된다. 보안 에이전트는 취약점 리포트만 하다가 PR 자동 생성 권한을 받고, 나중엔 직접 커밋한다. 권한이 쌓일수록 실수의 폭발 반경이 커진다. 읽기 전용 에이전트의 오작동은 '귀찮음'이지만, 이메일 발송 권한을 가진 에이전트의 오작동은 새벽 2시에 고객 200명에게 이상한 메일을 보내는 사고다.
거버넌스 설계: 팀이 직접 짜야 할 세 가지
이 세 가지 신호를 종합하면 실용적인 설계 원칙 세 개가 나온다.
첫째, 폴백을 먼저 설계하라. ML 테스트 선택이든 보안 에이전트든, 자동화 레이어가 실패했을 때 무엇이 동작하는지를 먼저 정의해야 한다. 전체 테스트 스위트 야간 실행, 수동 보안 검토 트리거—이 폴백이 없으면 자동화는 단일 장애점이 된다.
둘째, 에이전트별 권한 명세를 코드로 관리하라. 문서가 아니라 에이전트가 실제로 읽는 설정 파일에 '할 수 있는 것 / 승인 후 할 수 있는 것 / 절대 하지 않는 것'을 명시한다. 퍼미션 크립 글에서 제안하는 SOUL.md 방식이 직관적인 예시다. 이걸 에이전트가 매 턴 혹은 매 세션 시작 시 다시 읽게 만들면, 컨텍스트 누적에 따른 드리프트를 억제할 수 있다.
셋째, 월 1회 권한 감사를 파이프라인 루틴에 넣어라. 각 에이전트가 현재 실제로 보유한 크리덴셜과 파일 경로를 문서가 아닌 실제 시스템에서 확인한다. '이 에이전트가 지금 할 수 있는 최악의 단일 행동은 무엇인가'라는 질문을 던지고, 그 답이 치명적이라면 즉시 권한을 줄인다.
전망: 속도와 통제의 균형점
테스트 자동화, 보안 자동화, 배포 자동화—파이프라인 하단부에 AI가 깊숙이 들어오는 속도는 앞으로 더 빨라질 것이다. 도구는 이미 나와 있다. 문제는 도구가 아니라 팀이 설계하는 거버넌스 레이어다.
역설적으로, 자동화가 많아질수록 인간이 직접 쥐어야 할 결정 지점이 더 선명해진다. 어느 단계에서 에이전트를 멈추고 사람이 확인할 것인가. 어느 권한은 절대 에이전트에게 주지 않을 것인가. 이 경계를 설계하지 않으면, 파이프라인 속도는 올라가도 통제권은 조용히 빠져나간다. 테크 리드가 지금 해야 할 일은 AI 도구를 더 많이 붙이는 것이 아니라, 붙인 AI가 어디까지 행동할 수 있는지를 명시적으로 설계하는 것이다.