안전·품질·거버넌스: 코드리뷰, 테스트, 보안 경계선 세우기
자동화가 커질수록 "빨리 만드는 능력"보다 "안전하게 통과시키는 능력"이 생산성을 좌우합니다. Antigravity가 일을 잘해도, 조직은 결국 어디까지 맡길지, 무엇을 증거로 삼아 통과시킬지, 누가 책임을 지는지가 정해져 있어야 속도를 잃지 않습니다.
이 챕터의 목표는 두 가지입니다. 첫째, 에이전트가 건드리면 안 되는 영역(경계선)을 설계합니다. 둘째, 테스트·리뷰·배포를 통과시키는 필수 검증 게이트를 '자동화 친화적'으로 고정합니다.
안전장치가 생산성인 이유
에이전트는 "클릭"이 아니라 "행동"을 합니다. API를 호출하고, 레코드를 바꾸고, 배포를 트리거하며, 사람보다 빠르게 연쇄 작업을 수행합니다.2 그러니 거버넌스는 문서로 선언하는 순간 끝나지 않습니다. 권한·도구·데이터·출력의 경계에서 강제되어야 합니다.3
여기서 핵심은 '느리게 만들자'가 아닙니다. 높은 성숙도 조직은 보안과 거버넌스가 혁신을 늦추기보다 더 빠르게 채택하도록 돕는 기반이 된다고 봅니다.1 즉, 안전장치는 브레이크가 아니라 핸들입니다.
1) 에이전트가 건드리면 안 되는 영역(경계선) 정의하기
경계선은 "금지 목록"이 아니라, 권한과 영향 범위를 좁혀서 사고 반경(blast radius)을 제한하는 설계입니다. 실무에서 가장 효과적인 시작점은 네 가지입니다.
에이전트를 '1급 신원(Identity)'으로 취급한다
가장 흔한 실패는 에이전트가 과권한 서비스 계정으로 광범위하게 움직이는 것입니다. 해결책은 간단합니다. 에이전트를 '실체 있는 사용자(비인간 주체)'로 두고, 역할·테넌트·지역·업무 목적을 좁게 부여합니다.3 필요하면 "요청자 사용자로 실행(run-as-user)" 원칙을 적용해, 사람이 가진 권한을 넘어서는 대리 실행을 금지합니다.3
이렇게 하면 "에이전트가 무엇을 할 수 있나?"가 아니라 "이 에이전트는 누구를 대표해서, 어떤 일만 할 수 있나?"로 질문이 바뀝니다.
스코프를 '기능 이름'이 아니라 '행동 단위'로 쪼갠다
권한은 보통 너무 굵습니다. 예를 들어 admin 같은 역할은 에이전트에게 위험합니다. 대신 행동을 invoice.create, refund.issue, user.export처럼 API/도메인 행동 단위로 스코프화하고, 그 스코프를 정책으로 묶어야 합니다.2
이때 중요한 규칙이 하나 있습니다. "모델에게 자격증명을 오래 쥐여주고 프롬프트로 예의 바르게 만들기"는 위험합니다. 권한은 모델이 아니라 도구와 작업에 묶여야 하며, 회전·감사 가능해야 합니다.3
데이터·커넥터를 '에이전트 안전 경계'로 다룬다
현업에서 사고의 대부분은 모델이 똑똑하지 않아서가 아니라, 연결이 넓어서 납니다. 커넥터·액션·HTTP 접근을 무제한으로 열어두면, 의도치 않은 데이터 노출과 원치 않는 행동이 생깁니다.1
따라서 "승인된 데이터 소스만 사용", "환경 분리(dev/test/prod)", "민감 데이터는 기본 차단" 같은 원칙은 정책 문장이 아니라 기술적 통제(정책 엔진, 게이트웨이, 비밀 관리)로 강제되어야 합니다.12
출력은 '실행 가능한 것'과 '설명 가능한 것'으로 나눈다
에이전트 출력은 두 종류입니다.
실행 가능한 출력: 코드, 인프라 변경, 결제/환불, 배포 트리거처럼 곧바로 부작용(side effect)이 생기는 것
설명 가능한 출력: 문서 요약, 계획, 보고서처럼 사람이 읽고 판단하는 것
실행 가능한 출력은 "모델이 그렇게 말했으니 실행"이 절대 되면 안 됩니다. 출력과 실행 사이에 검증자(validator)를 두고, 고위험 행동은 사람 승인을 요구합니다.3
2) '티어(등급)'로 거버넌스를 설계하면 빨라진다
모든 에이전트를 같은 규칙으로 묶으면 두 가지 중 하나가 일어납니다. 낮은 위험의 개인 자동화까지 과도하게 막아 그림자 자동화가 생기거나, 반대로 미션 크리티컬까지 느슨하게 운영해 사고가 납니다.1
그래서 위험도 기반 티어링이 출발점입니다.1
추천 티어(예시)
T1 개인 생산성(낮은 위험): 읽기 전용, 샌드박스 데이터, 로컬/개인 워크스페이스 중심
T2 팀/부서 업무(중간 위험): 공유 리포지토리/문서, 제한된 커넥터, 변경은 PR 기반
T3 미션 크리티컬(높은 위험): 프로덕션 데이터/배포/결제 등, 강제 게이트·감사·승인 필수
여기서 포인트는 "티어가 높을수록 절차가 늘어난다"가 아니라, 티어가 높을수록 자동화가 더 필요하다는 점입니다. 사람이 늘어서 승인하는 방식은 확장되지 않습니다. 높은 성숙도 조직은 환경 프로비저닝, 정책 강제, 모니터링을 자동화해 거버넌스를 확장합니다.1
3) 필수 검증 게이트: 에이전트 워크플로에 '통과 조건'을 박아 넣기
앞서 배포 가능한 변경을 만들기 위해 테스트, 롤백, 관측성이 왜 중요한지 살펴봤다면, 여기서는 그것이 언제, 누구에 의해, 어떤 증거로 통과되는지를 거버넌스 관점에서 고정합니다.
게이트 A. 변경 제안(Plan) 승인: "무엇을 왜 바꾸나"를 먼저 잠근다
에이전트는 실행이 빠르기 때문에, 계획이 느슨하면 피해도 빨라집니다. 그래서 고위험 티어(T3)에서는 다음이 승인 없이는 진행되지 않게 설계합니다.
변경의 목적과 범위
영향 받는 시스템/데이터
롤백 전략
검증(테스트/배포 검증) 계획
이 단계는 문서 형식이 아니라, PR 템플릿/체크리스트/승인 규칙처럼 워크플로에 내장되어야 합니다.1
게이트 B. 코드리뷰(사람) + 자동 스캔(기계)의 분업
보안 코드리뷰는 자동 도구가 놓치는 취약점을 사람이 맥락으로 찾는 과정입니다.4 따라서 "AI가 리뷰했으니 사람은 생략"이 아니라, 사람이 봐야 하는 영역을 좁혀주는 방향으로 자동화를 배치해야 합니다.4
실무에서 리뷰를 빠르게 만드는 요령은 '범위'와 '관점'을 고정하는 것입니다. OWASP가 제안하는 방식처럼, 변경점 중심(diff-based) 리뷰를 기본으로 하고, 인증/인가, 입력 검증, 암호화, 로깅 같은 고위험 경로에 사람의 주의를 집중합니다.4
게이트 C. 테스트 게이트: 실패하면 "다음 단계가 존재하지 않게"
에이전트가 코드를 만들고 고치는 속도가 빨라질수록 테스트는 선택이 아니라 정지 버튼입니다. 조직 관점에서의 핵심은 테스트의 종류가 아니라, 다음 두 가지를 워크플로에 박는 것입니다.
기본 규칙: 테스트 실패 시 병합/배포가 불가능
예외 규칙: 예외 승인은 누가, 언제, 왜 했는지 기록되고 티어에 따라 허용 범위가 다름
게이트 D. 배포 검증(Verification): "배포가 끝나면 검증이 시작"
배포 후 검증은 '있으면 좋은 것'이 아니라, 프로덕션 사고를 줄이는 마지막 문입니다. Cloud Deploy는 배포 후 skaffold verify 기반으로 검증 컨테이너를 실행해 성공/실패를 배포 결과로 연결할 수 있고, 실패 시 출시는 실패 처리됩니다.6 Harness의 Verify 단계도 로그·메트릭 기반으로 배포 이상 징후를 탐지하고 필요하면 롤백까지 자동화하는 패턴을 제공합니다.7
즉, 고위험 티어에서의 배포는 "성공"이 아니라 "검증 통과"가 성공입니다.
4) 런타임 강제(Policy Enforcement): 가이드가 아니라 '집행'
정책이 문서로만 존재하면, 결국 개인의 주의력에 의존합니다. 에이전트 거버넌스에서 반복해서 등장하는 권장 패턴은 다음입니다.
중앙 정책 레이어(정책 엔진)에 규칙을 한 번 정의한다.
실행 경로(API 게이트웨이/툴 실행기)에서 런타임으로 매 요청을 검증한다.
모든 행동을 감사 로그로 남기고, 이상 징후를 모니터링한다.2
또한 도구(툴) 자체를 공급망처럼 취급해야 합니다. 에이전트가 사용할 수 있는 도구는 버전을 고정(pin)하고, 도구·스코프·데이터 소스 추가는 승인 절차를 거치며, 자동 도구 체이닝은 정책으로 허용된 경우만 가능하게 합니다.3
5) 감사 가능성(Auditability): "왜 그렇게 했는가"까지 재구성할 수 있어야 한다
거버넌스는 사고를 막는 것만이 아니라, 사고가 났을 때 재구성 가능한 증거를 남기는 일입니다.13 이를 위해 다음 두 층이 필요합니다.
첫째, 행동 감사 로그입니다. 누가(요청자), 어떤 에이전트가, 어떤 정책 하에서, 어떤 도구를 사용해, 무엇을 읽고·바꾸고·배포했는지를 남깁니다.23
둘째, 결정의 증거(Artifacts)입니다. 계획, 변경 요약, 테스트 결과, 배포 검증 결과, 승인 기록이 한 묶음으로 남아야 "이 결정이 합리적이었는지"를 나중에 판단할 수 있습니다.13
여기서 중요한 운영 질문은 하나입니다.
"지금 당장, 우리 조직의 에이전트 목록과 각각의 권한을 증거로 보여줄 수 있는가?"3
이 질문에 '네'라고 답할 수 있으면, 이미 절반은 끝난 것입니다.
6) 팀이 바로 쓰는 템플릿: 경계선 + 게이트를 한 장으로
아래는 T2~T3 수준에서 바로 적용 가능한 '한 장짜리' 설계 템플릿입니다.
(1) 에이전트 경계선 선언문(Agent Boundary Statement)
에이전트 이름/목적을 한 줄로 쓰고, 그 아래에 다음을 고정합니다.
대표 신원: 어떤 사용자/팀/테넌트를 대표하는가(교차 테넌트 금지)
허용 도구: 승인된 도구 목록(버전/엔드포인트 포함)
허용 스코프: 행동 단위 스코프 목록(예:
repo.write,deploy.trigger)금지 영역: 프로덕션 데이터 직접 수정, 결제/환불 자동 실행, 비밀/키 열람 등
사람 승인 필요: 파괴적 변경, 권한 확대, 배포, 데이터 내보내기
이 문서는 '정책 문서'가 아니라, 실제 런타임 정책(게이트웨이/정책 엔진/CI 규칙)으로 옮겨지는 것이 목표입니다.23
(2) PR 게이트 체크리스트(보안/품질)
OWASP의 보안 코드리뷰 관점을 빌려, 사람이 보는 체크를 좁고 강하게 둡니다.4
인증/인가 변경이 있는가? 있다면 수평/수직 권한 상승 가능성을 검토했는가
입력이 새로운 sink(DB/파일/명령/템플릿/외부 HTTP)로 흘러가는가
비밀/키/토큰이 코드·로그·환경 변수에 노출될 여지가 있는가
에러 처리/로깅이 민감 데이터 마스킹을 보장하는가
의존성 추가/업데이트가 있다면 출처와 라이선스를 확인했는가
(3) 배포 게이트(검증 포함)
배포 버튼을 누르는 주체가 사람이든 에이전트든, 아래는 동일해야 합니다.
테스트 통과(필수)
배포 후 검증 작업 통과(필수): 예를 들어 Cloud Deploy verify 컨테이너가 0 종료 코드로 끝나야 성공으로 처리6
이상 징후 감시(필수): 일정 시간의 로그·메트릭 분석에서 비정상 패턴이면 실패로 처리하고 필요 시 롤백7
요약: 더 큰 자동화에는 더 강한 '경계 + 게이트'가 필요하다
Antigravity를 크게 쓰려면, 잘 시키는 법보다 안전하게 통과시키는 법이 먼저입니다.
에이전트를 1급 신원으로 만들고 스코프를 행동 단위로 쪼개며,23 도구·데이터·출력 경계에서 정책을 런타임으로 집행하고,3 티어링으로 위험도에 맞는 통제를 자동화해야 합니다.1 여기에 사람 중심의 보안 코드리뷰와,4 배포 후 검증을 파이프라인의 성공 조건으로 묶으면,67 자동화가 커질수록 오히려 더 빠르게 움직일 수 있습니다.
참고
1Pillar 3: Security and governance (Microsoft Copilot Studio Guidance)
2AI Agent Governance Starts with Guardrails (Frontegg)
3From guardrails to governance: A CEO's guide for securing agentic systems (MIT Technology Review)
4Secure Code Review Cheat Sheet (OWASP)
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.