AI 코딩 Agent가 빨라질수록 이상한 곳에서 막힙니다. 코드가 아니라 dependency입니다.

“이 기능에 lodash 하나만 추가해줘” 같은 요청을 Agent가 스스로 처리하는 순간, 패키지 선택도 사람이 아니라 기계의 속도로 일어납니다. 사람이 모든 선택을 리뷰하는 구조는 그 속도를 못 따라가고 병목이 됩니다. GitLab의 Dependency Firewall 발표에서 개발자가 특히 볼 만한 지점이 여기입니다.

Dependency Firewall은 무엇인가

한 줄 정의는 이렇습니다. 프로젝트의 보안 정책을 만족하지 못하는 패키지가 fetch되기 전에 막는 구조입니다.

Agent/개발자가 패키지 요청
  → 정책 평가 (evaluate)
  → allowed / warned / blocked 중 하나
  → warn 모드: 경고하고 통과 / enforce 모드: 차단·quarantine

평가 기준은 브리핑에 나온 네 축 그대로입니다.

  • package age: 나온 지 얼마 안 된 패키지인가 (신규 악성 패키지의 전형 패턴)
  • vulnerability severity: 알려진 취약점의 심각도
  • malicious-package detection: 악성 패키지 탐지
  • license compliance: 라이선스 정책 준수

매칭되는 정책이 없으면 allowed, warn 모드 정책에 걸리면 warned, enforce 모드 정책에 걸리면 blocked가 떨어집니다. 정책이 하나도 연결 안 된 프로젝트는 항상 allowed라는 점도 중요합니다. “allowed = 안전 검증됨”이 아니라 “걸리는 정책이 없음”이라는 뜻이거든요.

API로 보면 감이 온다

GitLab Docs에 공개된 Dependency Firewall API(19.4, experiment, Premium·Ultimate)를 보면 설계 철학이 드러납니다.

먼저 프로젝트의 방화벽 상태를 확인합니다.

curl --request GET \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/1/dependency_firewall/enablement"

{
  "enabled": true
}

다음은 패키지 평가입니다. npm의 lodash 4.17.15를 예로 들면:

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --header "Content-Type: application/json" \
  --url "https://gitlab.example.com/api/v4/projects/1/dependency_firewall/evaluate" \
  --data '{"ecosystem": "npm", "name": "lodash", "version": "4.17.15"}'

{
  "outcome": "blocked",
  "reason": "Package 'lodash' violates 'deny-mit' policy"
}

눈여겨볼 설계가 몇 가지 있습니다.

  • 지원하는 ecosystem이 넓습니다. cargo, composer, conan, gem, golang, maven, npm, nuget, pub, pypi, swift. 패키지 매니저 한 곳이 아니라 전선을 넓게 보는 구조입니다.
  • CI/CD job token으로 파이프라인 안에서 인증할 수 있습니다. 다만 job token은 자기가 도는 프로젝트만 조회·평가할 수 있고, 다른 프로젝트는 403입니다. “옆 프로젝트 방화벽 상태를 몰래 보는” 일을 원천 차단합니다.
  • 설치 세션 상관관계용 헤더(X-Gitlab-Dependency-Firewall-Session-Id)가 있습니다. 한 번의 install 명령이 패키지마다 평가를 여러 번 쏘면 같은 세션으로 묶어 audit·분석 이벤트에 기록합니다. 나중에 “누가·언제·무엇을 깔았나”를 묶어서 볼 수 있게요.
  • 평가는 Reporter 이상 권한이면 package registry가 꺼져 있어도 됩니다. upstream에서 가져오는 의존성을 평가하는 거라 registry on/off와 독립이라는 설명입니다.

왜 사후 리뷰로는 안 되는가

사람 속도의 리뷰가 깨지는 지점을 구체적으로 적어보면:

Agent가 10분 만에 PR 5개를 올림
  → 각 PR마다 dependency 2~3개 추가
  → 리뷰어는 코드 + 의존성 + 라이선스 + 취약점을 다 봐야 함
  → "일단 머지하고 나중에 보자"가 기본값이 됨
  → 나중에 보는 일은 오지 않음

그래서 Agent autonomy가 커질수록 사후 코드 리뷰보다 사전 정책 enforcement가 중요해진다는 말이 나옵니다. 방화벽은 “못 믿으니 못 쓰게”가 아니라 “믿고 빨리 쓰게” 두는 장치입니다. 악성·취약·비준수 패키지가 빌드에 닿기 전에 걸러지니 Agent에게 더 넓은 자율성을 줄 수 있습니다.

이건 Governed Software Factory 글에서 다룬 큰 그림의 일부이기도 합니다. 문맥(Orbit), 비밀(Secrets Manager), 조립(Artifact Central)과 함께 의존성이 묶여야 Agent가 production까지 갈 수 있습니다.

최소 게이트: 오늘 바로 둘 수 있는 것

방화벽이 아직 experiment(기능 플래그 dependency_firewall_phase1, 기본 off)라 당장 못 쓰는 팀도 많습니다. 그럴 때는 이 네 개를 자동 게이트로 두세요. AI가 dependency를 추가할 수 있는 repo라면 최소선입니다.

1. allow/deny policy
   - ecosystem별 허용 범위 문서화 (예: npm은 lockfile 필수, 신규 패키지는 age 30일+)
   - warn부터 시작해 enforce로 올리기 (처음부터 block이면 일이 멈춘다)

2. vulnerability scan
   - MR마다 스캔, 심각도 기준 차단선 명시
   - 자동 수정(auto-remediation)은 별도 리뷰 큐로 (19.2의 방향과 동일)

3. lockfile diff
   - lockfile 변경은 코드 변경과 분리 리뷰
   - "왜 이 버전인가" 한 줄을 PR 본문에 강제

4. audit trail
   - 누가·언제·무엇을·왜 설치했는지 세션 단위로 기록
   - 주간 리뷰 1회: warned 통과분만 모아보기 (전수 리뷰 금지)

warn 모드 운영 팁이 하나 있습니다. 처음부터 enforce로 막으면 Agent가 멈추고 개발자가 방화벽을 끄는 쪽으로 수렴합니다. warn으로 2주 돌려 “무엇이 얼마나 걸리는지”를 재고, 상위 패턴부터 enforce로 올리세요. Git 실무 글의 리뷰 흐름과 같이 보면 자리 잡기가 쉽습니다.

CodeBridge Mini Lab: 우리 repo 위험도 재기

1. 최근 머지된 MR 20개를 뽑는다
2. 각 MR에서 Agent·사람이 추가한 dependency를 센다
3. 각 dependency에 표시:
   - age 30일 미만인가?
   - 알려진 취약점이 있는가?
   - 라이선스가 정책과 충돌하는가?
   - lockfile diff 없이 들어왔는가?
4. 네 칸 중 하나라도 Y면 "방화벽이 있었다면 걸렸을 후보"로 집계

판정:
- 후보가 0이면 지금 흐름 유지 + warn 모드 준비
- 후보가 3건 이상이면 allow/deny 초안부터 작성
- lockfile diff 누락이 절반이면 리뷰 규칙부터 고친다 (도구보다 규칙이 먼저)

결론: dependency도 기계 속도로 통제해야 한다

한 줄로 닫습니다.

Agent가 패키지를 고르는 속도라면, 통제도 같은 속도로 자동이어야 한다.

사람 리뷰를 없애자는 얘기가 아닙니다. 사람의 눈은 “정책 예외를 판단하는 곳”에 쓰고, 반복되는 차단은 기계에 맡기자는 얘기입니다. warn으로 시작해 enforce로 올리고, lockfile diff와 audit trail을 남기세요. 그 다음에 Agent에게 더 큰 자율성을 줘도 늦지 않습니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

정책을 두기 전에 리뷰와 형상관리의 기본 흐름이 잡혀 있어야 방화벽이 말썽이 아니라 힘이 됩니다. lockfile diff를 읽고 리뷰하는 습관부터 다지고 싶다면, 실무형 Git 흐름이 이 글의 최소 게이트와 바로 이어집니다.