AI의 병목 현상은 코드 생성 자체가 아니라 '코드 통제(Governing)' 능력이다

자율 AI 코딩 에이전트(Claude, Devin, Antigravity, 또는 Copilot Workspace)에게 프로덕션 레포지토리에서 자유를 준 경험이 있는 사람이라면 불편한 느낌을 알고 있을 것입니다. 한 분기 전에는 에이전트가 훌륭한 알고리즘을 작성했지만, 다음 순간에는 관련 없는 파일을 건드리거나, go.mod 파일을 재작성하고, 존재하지 않는 단위 테스트(unit tests)를 환각적으로 생성하며, 심지어 main 브랜치에 직접 커밋하려고 시도합니다.

업계는 근본적인 진실을 인식하기 시작했습니다:

AI 지원 소프트웨어 엔지니어링의 실제 병목 현상은 토큰 속도나 코드 생성이 아닙니다. 그것은 무엇이 생성되는지를 검증하고, 제약하며, 결정론적으로 통제할 수 있는 능력입니다.

저는 응용 AI 엔지니어링(Applied AI Engineering) 대학원 과정 중 이 반복적인 마찰을 산업 소프트웨어 엔지니어링 표준으로 바꾸는 것을 목표로 삼았고, 이것이 바로 Pipeline-AI입니다.

본 글에서는 저희가 어떻게 Go 1.24 OS 라이프사이클 훅(lifecycle hooks), 엄격한 TDD(Test-Driven Development), 그리고 역할 특화 기능을 Google Antigravity 생태계에 네이티브하게 통합하여 결정론적이고 제로 트러스트(zero-trust)의 멀티 에이전트 워크플로우를 구축했는지 자세히 설명하겠습니다.

함정: 왜 '프롬프트 엔지니어링'은 통제에 실패하는가

AI 에이전트를 통제하려는 순진한 방법은 자연어 제약 조건을 프롬프트에 추가하는 것입니다:

“internal/user/ 외의 파일은 수정하지 마십시오. 그리고 main 브랜치에 직접 커밋하지 마십시오.”

하지만 이는 수학적인 현실 때문에 실패합니다: LLM(대규모 언어 모델)은 확률적이지만, 소프트웨어 엔지니어링은 결정론적 보장(deterministic guarantees)을 요구하기 때문입니다.

만약 LLM이 밀집된 컨텍스트 창이나 깊은 추론 트리 하에서 지침을 무시할 1%의 가능성을 가지고 있다면, 그 1%는 여러분의 릴리스 브랜치에 나타날 것입니다. 통제(Governance)는 에이전트의 프롬프트 안에 존재할 수 없습니다. 그것은 실행 환경(운영체제 수준)에 존재해야 합니다.

1. 제로 트러스트 방어: OS 라이프사이클 훅 (PreToolUse)

저희의 첫 번째 아키텍처 결정은 최소 권한 원칙(principle of least privilege)을 강제하는 것이었습니다. 즉, 주요 대화 세션이 코드를 직접 편집하는 것이 물리적으로 금지되었습니다.

Google Antigravity는 네이티브 라이프사이클 후크(lifecycle hooks)를 제공하며, 특히 PreToolUse 이벤트를 주목할 만하게 사용합니다. 에이전트가 파일 수정 도구(write_to_file, replace_file_content)를 호출할 때마다, 이 후크는 디스크에 단 하나의 바이트도 쓰이기 전에 요청을 가로챕니다.

우리는 외부 종속성이 전혀 없는(stdlib만 사용) 정적으로 컴파일된 Go 1.24 바이너리인 pipeline-hook을 구축했습니다. 이는 표준 입력(stdin)의 JSON 페이로드를 가로채어 어떤 서브 에이전트가 실행 중인지 식별하고, 대상 파일을 프로젝트 가드레일(guardrails)과 비교합니다:

// Go에서 pipeline-hook의 간소화된 가로채기 로직
func run(stdin io.Reader, stdout, stderr io.Writer) int {
    var in hookInput
...
}

만약 제품 트리아지 에이전트나 권한 없는 세션이 internal/auth/token.go를 수정하려고 시도하면, OS 후크가 즉시 decision: deny로 호출을 중단시킵니다. 프롬프트 협상 과정이 없습니다. 도구 호출은 시스템 경계에서 차단됩니다.

2. 16개 스킬 파이프라인: 전문화 대 모놀리식 에이전트

흔한 안티 패턴(anti-pattern) 중 하나는 '만능' 에이전트에 의존하는 것입니다. 단일 프롬프트로 비즈니스 요구사항을 이해하고, 데이터베이스 스키마를 설계하며, 단위 테스트를 작성하고, 코드를 구현하고, diff 결과를 검토하도록 요청하면 대규모 컨텍스트 드리프트(context drift)와 얕은 추론이 발생합니다.

Pipeline-AI에서는 소프트웨어 개발 수명 주기(software development lifecycle)를 16개의 전문화된 스킬로 분해했습니다:

1. pm-triage              → 범위를 분류하고, DEL-ID 태그를 지정하며, 기술적 요구사항을 식별
2. architecture-guardrails → 기술적 경계와 불변 잠금(invariant locks)을 설정
3. [data-model]           → 스키마 및 엔티티 설계 (PostgreSQL, Mongo, DynamoDB)
...

(괄호는 구성에 의해 활성화되는 선택적 모듈을 나타냅니다.)

각 에이전트는 명확한 경계를 가집니다. code-reviewer는 읽기 전용 권한만 가지며 코드를 수정할 수 없습니다. 또한, dev-implementation 에이전트는 test-writer가 실패하는 테스트를 커밋해야만 작업을 시작합니다.

3. 환각(Hallucination)에 대한 해독제로서의 엄격한 TDD

LLM을 위한 가장 좋은 명세는 실패하는 단위 테스트입니다:

1. Red: test-writer 에이전트는 아키텍처 가드레일(architectural guardrails)을 받아 Go의 표준 testing 패키지를 사용하여 포괄적인 테이블 기반 테스트를 작성합니다. 이 에이전트는 go test ./...를 실행하여 실패를 증명합니다.
2. Green: dev-implementation 에이전트가 작업을 이어받습니다. 이 에이전트의 임무는 사용자 의도를 추측하거나 미래 기능을 사변하는 것이 아닙니다. 오직 테스트를 통과시키는 것만이 유일한 목표입니다.
3. Refactor & Format: go test -race ./...가 녹색(green)이고, PostToolUse 훅을 통해 gofmt가 코드를 자동으로 포맷하면 구현은 중단됩니다. 데드 코드(dead code)는 없고, 범위 확장(scope creep)도 없습니다.

4. 배포 게이트키퍼: pipeline-validate

어떤 풀 리퀘스트(Pull Request, PR)가 생성되기 전에, 저희의 커스텀 검증기(validator)가 배포를 확인합니다:

go tool pipeline-validate docs-ai/deliveries/DEL-011/report.md

검증기는 다음 경우에 자동으로 배포를 거부합니다:

• 체크리스트 작업이 미체크 상태로 남아 있는 경우.
• 배포 보고서에 해결되지 않은 마커(예: TODO, FIXME, TBD, 채우기 텍스트)가 포함된 경우.
• 실제 git diff가 명시적으로 승인된 보안 감사 섹션 없이 보안 민감 파일(security_surface_paths)을 건드린 경우.

게이트키퍼가 실패하면, Git 배포는 중단됩니다. PR은 열 수 없습니다.

5. 실제 사례 연구: 데스크톱 Go + SQLite

저희는 이 파이프라인을 활성 데스크톱 애플리케이션에서 검증했습니다:

• CGO 불변성(Invariant) 확보: 파이프라인은 외부 종속성이 Linux/WSL2에서 Windows로의 크로스 컴파일(cross-compilation)을 깨뜨리지 않도록 강제했으며, 그 결과 독립 실행형 37MB 실행 파일을 생성했습니다.
• 사전 보안 검증: 에이전트가 internal/storage/sqlite/를 수정했을 때, 파이프라인은 자동으로 보안 표면(security surface) 접촉을 플래그 지정하고, 매개변수화된 쿼리(SQL injection 방지)를 강제하며 govulncheck를 통과시켰습니다.
• Git 보호: main 브랜치로의 직접 푸시는 로컬에서 .githooks/pre-push에 의해, 원격에서는 GitHub Rulesets에 의해 차단되었습니다. 모든 배포물은 깔끔하게 스쿼시된(squashed) PR을 통해 프로덕션에 도달했습니다.

응용 AI 엔지니어를 위한 핵심 시사점

1. AI 에이전트를 터미널 접근 권한을 가진 초고속 주니어 엔지니어처럼 취급하세요: 강력한 도구를 제공하되, 결정론적(deterministic) OS 훅과 포괄적인 테스트 스위트로 격리해야 합니다.
2. 결정론이 확률을 이깁니다: 가능한 한 자연어 프롬프팅(natural language prompting)을 컴파일된 CLI 게이트(go tool)와 정적 린터(static linter)로 대체하세요.
3. 역할 전문화는 컨텍스트 저하를 최소화합니다: 수술용 범위(surgical scope)를 가진 더 작은 에이전트는 적은 토큰을 소비하고, 실수를 덜 하며, 감사(audit)하기가 훨씬 쉽습니다.

오픈 소스 (Open Source)

pipeline-init 스캐폴딩 CLI, Go 훅, 그리고 16개의 전체 Antigravity 스킬 카탈로그를 포함한 전체 도구 키트는 MIT 라이선스 하에 오픈 소스로 공개되었습니다:

👉 GitHub: rodrigodosanjosoliveira/pipeline-ai

워크플로우에서 자율 코딩 에이전트의 거버넌스(governance)와 가드레일(guardrails)을 어떻게 처리하고 계신가요? 아래 댓글에서 논의해 봅시다! 💬👇