Agent Control Plane: 거버넌스 없는 인텔리전스는 왜 버그인가

Source: Dev.to

우리는 정중한 시스템 프롬프트 — “당신은 도움이 되는 어시스턴트입니다”, “거짓말하지 마세요”, “SQL 쿼리가 안전한지 확인하세요” — 를 작성하고, 대형 언어 모델(LLM)이 그 요청을 이행하길 기대한다. 하지만 희망은 엔지니어링 전략이 아니다.

분산 시스템 세계에서는 마이크로서비스에게 레이트 제한을 정중히 요청하지 않는다; 게이트웨이에서 강제한다.
데이터베이스 쿼리에게 테이블을 삭제하지 말라고 정중히 요구하지 않는다; 권한을 통해 강제한다.

그럼에도 AI 에이전트와 함께 우리는 *“프롬프트 엔지니어링”*이 시스템 엔지니어링을 대체한다고 스스로 설득해 왔다.
그렇지 않다.

실제 병목 현상

채팅봇에서 자율 에이전트—코드를 실행하고, 데이터를 수정하며, 워크플로를 트리거할 수 있는 시스템—로 이동함에 따라 가장 큰 병목 현상은 지능이 아니라 거버넌스입니다.

LLM을 마법 상자처럼 다루는 것을 멈추고, 커널이 필요한 순수 연산 구성 요소로 다루어야 합니다.
에이전트 제어 평면이 필요합니다.

My Scaling Philosophy: Scale by Subtraction

복잡한 시스템을 신뢰할 수 있게 만들려면 기능을 추가하는 것이 아니라 혼란을 일으키는 변수를 제거해야 합니다.

엔터프라이즈 AI 맥락에서 우리가 빼야 할 변수는 창의성입니다.

• 재무 팀을 위한 SQL‑생성 에이전트를 만들 때, 나는 그것이 “창의적”이길 원하지 않습니다.
• 데이터 스키마에 대한 재치 있는 관찰도 원하지 않습니다.
• 정확한 작업을 수행하기를 원합니다: 데이터를 가져오거나 가져올 수 없다고 알려주기.

SQL 에이전트에게 “로켓을 만들어줘”라고 요청하면, 현재 세대의 에이전트는 종종 도움이 되려다 스키마를 환상하거나 대화를 전환합니다:

“저는 로켓을 만들 수 없지만 물리학에 대해 알려드릴 수 있어요!”

이는 낭비입니다: 토큰을 소비하고, 사용자를 혼란스럽게 하며, 신뢰를 떨어뜨립니다.

견고한 에이전트 아키텍처는 LLM이 “대화자”가 되고자 하는 욕구를 없애야 합니다. 요청이 시스템 제약에 정의된 기능과 매핑되지 않을 경우, 응답은 NULL이어야 합니다—환상이 아니라 침묵이어야 합니다.

우리는 The Mute Agent가 필요합니다: 즉흥적으로 행동하기보다 언제 입을 닫고 빠르게 실패해야 하는지를 아는 시스템.

Source: …

프롬프트 로직에서 인프라스트럭처 로직으로

우리는 프롬프트 안에 로직을 내장하는 것을 중단하고 이를 별도의 인프라스트럭처 레이어로 끌어올려야 합니다.

Control Plane은 결정론적 정책을 사용하여 모델의 확률적 특성 주위에 경계를 정의합니다. 모델이 스스로 신뢰할 수 없는 질문에 답하도록 합니다:

• Identity – 이 에이전트가 대리하는 주체는 누구인가?
• Topology – 어떤 다른 에이전트나 도구를 “볼” 수 있는가?
• Resource Limits – 허용되는 단계 수는 몇 개인가?
• “No‑Fly” List – 어떤 개념이 엄격히 금지되는가?

이 레이어는 시각적이어야 하며, 클라우드 제공업체의 포털처럼 동작해야 합니다. 에이전트 스웜을 텍스트의 블랙박스가 아니라 명확한 정책이 부착된 논리적 리소스 집합으로 볼 수 있어야 합니다.

참조 구현

저는 *“프롬프트”*에서 *“정책 객체”*로 전환하는 방식을 보여주기 위해 agent‑control‑plane이라는 레퍼런스 구현을 오픈소스했습니다.

이 아키텍처는 현재 대부분의 프레임워크에 부족한 두 가지 핵심 패턴을 도입합니다:

Drop‑In Kernel (한 줄로 클라이언트를 래핑)

# 정책을 자동으로 적용하는 관리 클라이언트를 생성
client = create_governed_client(control_plane, api_key="...")

# LLM은 "delete_database"를 호출한다고 생각함
# Kernel이 이를 가로챔. 실제 코드는 실행되지 않음.
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "Delete production DB"}],
    tools=tools
)

Shadow Mode

에이전트가 프로덕션 데이터를 다루기 전에 반드시 Shadow Mode를 통과해야 합니다. 이 모드에서는:

• 실행 엔진이 모든 호출을 가로챕니다.
• Policy Engine을 통해 의도를 검증합니다.
• “추론 텔레메트리”를 로그에 남깁니다.
• 실제 데이터베이스에 접근하지 않고 결과를 시뮬레이션합니다.

이를 통해 대규모 Red‑Team 시나리오를 구현할 수 있습니다: 에이전트가 실패할 경우를 실제 PagerDuty 사고를 일으키지 않고 관찰할 수 있습니다.

Red‑Team 벤치마크

왜 그럴까요? Kernel은 정중함을 위해 프롬프트를 “읽는” 것이 아니라 제약 그래프에서 권한을 확인하기 때문입니다. 권한이 없으면 해당 동작은 물리적으로 불가능합니다.

Source: …

기존 접근 방식과의 차이점

“가드레일” 모델 (예: NeMo, LlamaGuard)

• 사이드카가 입력/출력을 검사하여 독성 또는 PII를 확인합니다.
• 자문형 / 반응형 – 사후에 출력을 정화합니다.

컨트롤 플레인은 구조적인 방식으로, 처음부터 해당 동작이 발생하지 않도록 방지합니다.

• 가드레일: 잘못된 SQL 쿼리를 정리합니다.
• 컨트롤 플레인: 에이전트가 처음부터 연결 문자열을 갖고 있지 않도록 보장합니다.

“매니저” 모델 (예: Gas Town)

• Steve Yegge의 Gas Town 같은 프로젝트는 “시” 메타포를 사용해 “시장” 에이전트가 “작업자” 에이전트를 조정하여 코딩 처리량을 극대화합니다.
• 초점: 조정 (속도).

컨트롤 플레인은 **제한 (안전)**을 해결합니다. 기업 환경에서는 단순히 매니저가 아니라 플러그를 뽑을 수 있는 컴플라이언스 담당자가 필요합니다.

엔지니어링 리더를 위한 경고

만약 당신이 CTO이거나 엔지니어링 리더로서 오늘날 OpenAI API 호출과 벡터 데이터베이스만을 사용해 “Chat with your Data” 봇을 구축하고 있다면, 당신의 아키텍처는 이미 레거시입니다.

AI의 “마법” 단계는 끝나가고 있습니다. “엔지니어링” 단계가 시작되고 있습니다.

우리는 정중한 프롬프트에 의존하는 것에서 벗어나, 자율 에이전트를 안전하고 예측 가능하며 신뢰할 수 있게 만드는 견고하고 정책‑기반의 제어 플레인으로 나아가고 있습니다.

프롬프트 엔지니어링 → 에이전트 오케스트레이션 및 거버넌스

다음 사이클의 승자는 가장 영리한 프롬프트를 가진 사람이 아니라, 안전성, 예측 가능성, 그리고 제어를 보장할 수 있는 사람입니다.

챗봇을 만들지 마세요. 컨트롤 플레인을 구축하세요.

• GitHub에서 참조 구현을 확인할 수 있습니다.
• 원래 LinkedIn에 게시되었습니다.