AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

AI 에이전트는 “NO”를 모른다, Context as Code로 아키텍처 지키는 법

Jira 티켓 하나가 들어왔습니다. “결제 성공 후 이메일 알림을 추가해주세요.” AI 코딩 에이전트는 지체 없이 300줄의 코드를 생성하고, 결제 도메인 핵심부에 SMTP 라이브러리를 직접 임포트해 PR을 제출합니다. 테스트는 통과, CI도 녹색 — 그리고 아키텍처는 조용히 무너집니다.

사진 출처: O’Reilly Radar

소프트웨어 아키텍트 Artur Huk이 O’Reilly Radar에 AI 에이전트 시대의 빌드타임 거버넌스 전략을 제시했습니다. 핵심 주장은 이렇습니다. AI 에이전트는 기본적으로 “YES 기계”로 설계되어 있고, 아키텍처를 지키려면 “NO”를 자동화해야 한다는 것입니다.

출처: Context as Code – O’Reilly Radar

AI 에이전트는 아키텍처를 모른다

시니어 엔지니어가 같은 티켓을 받았다면 이렇게 말했을 겁니다. “그 방식은 안 됩니다. 메시지 버스에 PaymentSuccessEvent를 발행하세요.” 이 인간적인 마찰, 즉 아키텍처적인 “NO”가 시스템을 유지 가능하게 합니다.

AI 에이전트에게는 이 마찰이 없습니다. 에이전트는 bounded context 같은 개념을 따지지 않습니다. 그냥 기능을 완성합니다. Addy Osmani가 이름 붙인 “comprehension debt(이해 부채)”—AI가 코드를 생성하는 속도를 인간이 이해하고 검토하는 속도가 따라가지 못하는 격차—는 이렇게 소리 없이 쌓입니다.

Huk은 이 현상을 “프랑켄슈타인 공장”이라 부릅니다. 동작하는 코드를 대량으로 찍어내지만 누군가 그것을 통제하려는 순간 위기가 시작되는 구조입니다. 프랑켄슈타인의 비극은 창조 행위 자체가 아니라, 창조물을 다스릴 프레임이 없었다는 데 있었습니다.

컨텍스트를 코드처럼 다루기

Huk이 제안하는 해법은 Context Compilation Pattern입니다. 에이전트가 코드를 생성하기 전, 빌드타임에 경계를 명시적으로 선언하고 기계적으로 강제하는 파이프라인입니다.

핵심 아이디어는 간단합니다. 프롬프트 엔지니어링처럼 “더 좋은 대답을 달라”고 요청하는 게 아니라, 에이전트가 생성할 수 있는 공간 자체를 제한하는 것입니다.

파이프라인은 크게 두 레이어로 구성됩니다.

  1. 구조화된 컨텍스트 주입: 에이전트 프롬프트를 아무 마크다운이나 쌓는 게 아니라, 우선순위가 있는 아티팩트들로 조립합니다. intent.md(무엇을 만드는가), boundaries.md(구조적 불변 규칙), threat-model.md(보안 위협 시나리오)가 그 예입니다.
  2. 생성 후 정적 검증: LLM이 코드를 생성한 뒤, Semgrep·Bandit·CodeQL 같은 결정론적 AST 도구가 경계 위반 여부를 기계적으로 확인합니다. 이 단계는 AI가 아닌 확정적 도구가 담당합니다.

예를 들어 boundaries.md에 “Billing 모듈은 외부 네트워크 I/O를 절대 허용하지 않는다. requestssmtplib를 임포트하지 말 것”이라고 선언하면, 대응하는 Semgrep 규칙이 CI에서 해당 임포트를 감지해 빌드를 즉시 실패시킵니다. 에이전트가 SMTP 코드를 생성하더라도 파이프라인 밖으로 나오지 못합니다.

우선순위 체계도 있습니다. 위협 모델 > 경계 선언 > 코딩 표준 > 기능 요구사항 순으로, 보안과 아키텍처 경계가 기능 요청보다 무조건 우선합니다. 충돌이 생기면 AI가 타협점을 찾는 게 아니라 CI가 빌드를 거부하고, 개발자가 설계를 바꿔야 합니다.

역할도 바뀐다

이 구조에서 각 역할의 산출물이 달라집니다. 비즈니스 애널리스트는 intent.md와 기계 실행 가능한 acceptance-criteria.md를 작성하고, 소프트웨어 아키텍트는 PR 리뷰 대신 boundaries.md로 구조적 불변 규칙을 사전 선언합니다. QA·보안 엔지니어는 threat-model.md로 위협 시나리오를 코드 생성 전에 정의합니다. 개발자는 “context orchestrator”로서 이 아티팩트들의 충돌을 조율하고, 제로 트러스트 경로처럼 직접 구현이 필요한 핵심 코드를 담당합니다.

중요한 점은 이 접근이 경제성을 따집니다. Huk은 프로토타입, 내부 유틸, 마케팅 사이트처럼 아키텍처 실패 비용이 낮은 곳에는 에이전트를 제약 없이 쓰는 게 맞다고 합니다. 반면 결제 시스템, 헬스케어 플랫폼, 금융 규제 환경처럼 잘못된 의존성 하나가 법적 책임으로 이어지는 곳에서는, 경계 선언에 드는 엔지니어링 비용이 사후 수습 비용보다 압도적으로 쌉니다.

희소해지는 것은 구문이 아니라 경계

Huk의 글이 던지는 더 큰 화두는 엔지니어링 가치의 전환입니다. 코드를 생성하는 비용이 사실상 0에 수렴하는 시대에, 희소한 자원은 “올바른 코드를 쓰는 능력”이 아니라 “올바른 코드가 나올 수 있는 조건을 설계하는 능력”입니다.

전통적인 코드 리뷰가 변경 하나를 통제한다면, 잘 검토된 boundaries.md 하나는 이후 수백 번의 생성 사이클을 통제합니다. 시니어 엔지니어의 핵심 역할이 절차적 코드 작성에서 선언적 경계 설계로 이동한다는 시각입니다.

이 글은 에이전트 거버넌스를 다룬 3부작의 마지막 편으로, 원문에는 DIR(Decision Intelligence Runtime), ROA(Responsibility-Oriented Agents) 등 관련 개념과 오픈소스 레퍼런스 구현도 소개되어 있습니다.

참고자료:


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다