왜 나는 AI 에이전트를 위한 가드레일을 6개월 동안 만들었는가
Source: Dev.to
Source:
왜 만들었는지, 어떻게 작동하는지, 그리고 무엇을 배웠는지
문제: AI 에이전트는 강력하지만 무섭다
저는 AI 에이전트에 집착해 왔습니다 – 챗봇이 아니라 실제로 무언가를 수행하는 에이전트 말이죠. 에이전트가 할 수 있는 일은 다음과 같습니다:
- 풀 리퀘스트 병합
- 쿠버네티스에 배포
- 데이터베이스 레코드 업데이트
- 여러분을 대신해 슬랙 메시지 전송
기술은 이미 준비돼 있습니다. 하지만 프로덕션에 배포하려고 할 때마다 같은 일이 일어났습니다:
보안팀이 거부했습니다.
솔직히 말해서, 그들은 옳았습니다.
생각해 보세요: AI에게 프로덕션 시스템에 쓰는 권한을 주면서 감사 로그도, 승인 워크플로우도, 정책을 강제할 방법도 없습니다. 마치 인턴에게 루트 권한을 주고 행운을 기대하는 것과 같습니다.
저는 팀들이 **“PoC 지옥”**이라고 부르는 상황에 갇혀 있는 것을 계속 보았습니다 – 훌륭한 데모는 있지만 거버넌스 스토리가 없어서 절대 배포되지 않음.
해결책: 정책‑우선‑디스패치
모든 AI 행동이 실행되기 전에 정책 검사를 통과해야 한다면 어떨까요?
그것이 Cordum의 핵심 아이디어입니다.
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ AI Agent │ --> │ Safety Kernel│ --> │ Action │
└─────────────┘ └──────────────┘ └─────────────┘
│
┌──────┴──────┐
│ Policy │
│ (as code) │
└─────────────┘어떤 작업도 실행되기 전에, Safety Kernel이 정책을 평가하고 다음 중 하나를 반환합니다:
- ✅ Allow – 정상 진행
- ❌ Deny – 사유와 함께 차단
- 👤 Require Approval – 인간이 개입해야 함
- ⏳ Throttle – 속도 제한
코드 보여주기
정책은 다음과 같이 정의됩니다:
# policy.yaml
rules:
- id: require-approval-for-prod
match:
risk_tags: [prod, write]
decision: require_approval
reason: "Production writes need human approval"
- id: block-destructive
match:
capabilities: [delete, drop, destroy]
decision: deny
reason: "Destructive operations not allowed"
- id: allow-read-only
match:
risk_tags: [read]
decision: allow에이전트가 위험한 작업을 시도하면 Cordum이 개입합니다:
{
"job_id": "job_abc123",
"decision": "require_approval",
"reason": "Production writes need human approval",
"matched_rule": "require-approval-for-prod"
}작업은 대시보드에서 인간이 승인할 때까지 대기합니다. 전체 감사 로그가 남고, 컴플라이언스도 만족합니다.
아키텍처
Cordum은 컨트롤 플레인이며, 에이전트 프레임워크가 아닙니다. 에이전트를 조정하고 거버넌스를 제공하지만 LangChain이나 CrewAI를 대체하지는 않습니다.
┌─────────────────────────────────────────────────────────┐
│ Cordum Control Plane │
├─────────────────────────────────────────────────────────┤
│ ┌───────────┐ ┌──────────────┐ ┌─────────────────┐ │
│ │ Scheduler │ │ Safety Kernel│ │ Workflow Engine │ │
│ └───────────┘ └──────────────┘ └─────────────────┘ │
├─────────────────────────────────────────────────────────┤
│ ┌───────────────┐ ┌───────────────────────────────┐ │
│ │ NATS Bus │ │ Redis (State) │ │
│ └───────────────┘ └───────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
│ │ │
┌────┴────┐ ┌────┴────┐ ┌───┴────┐
│ Worker │ │ Worker │ │ Worker │
│ (Slack) │ │ (GitHub) │ │ (K8s) │
└──────────┘ └──────────┘ └────────┘기술 스택
- Go – 핵심 컨트롤 플레인 (~15 K 라인)
- NATS JetStream – 최소 한 번 전달을 보장하는 메시지 버스
- Redis – 작업, 워크플로, 컨텍스트를 위한 상태 저장소
- React – 실시간 업데이트가 가능한 대시보드
성능
- (성능 세부 사항은 발췌본에 포함되지 않음)
이 프로젝트를 만들며 배운 점
- 안전을 기능으로, 제약이 아니라
처음엔 거버넌스를 “불가피한 악”이라고 생각했지만…
기업들은 규정 준수가 필요합니다. 하지만 저는 그것을 기능으로 보게 되었습니다.
- (레슨의 나머지는 원본 내용에 계속됩니다)*
1. “쓰기 권한”은 경쟁 우위
모든 AI 행동이 정책에 따라 평가되고 기록될 때, 이전에는 불가능했던 사용 사례를 열 수 있습니다.
- Banks can use AI agents.
- Healthcare can use AI agents.
“쓰기” 능력은 강력한 차별화 요소가 됩니다.
2. 프로토콜이 예상보다 더 중요하다
나는 CAP에 많은 시간을 투자했고, 그 보람을 얻었다. 깔끔한 프로토콜을 갖추면 다음과 같은 이점이 있다:
- 워커를 어떤 언어로든 작성할 수 있다.
- 컨트롤 플레인을 독립적으로 진화시킬 수 있다.
- 제3자가 호환 가능한 도구를 구축할 수 있다.
3. Open source is a distribution strategy
I could have built this as a closed SaaS from day one, but open source gives us:
- Trust – you can read the code.
- Self‑hosting – enterprises love this.
- Community funnel – users contribute and spread the word.
Business model: open‑core. Self‑hosted is free forever; cloud/enterprise features are paid.
다음 단계
로드맵에는 다음이 포함됩니다:
- Helm chart for Kubernetes 배포.
- Cordum Cloud – 관리형 버전.
- 대시보드 내 Visual workflow editor.
- More packs – AWS, GCP, PagerDuty 등.
직접 사용해 보기
🌐 웹사이트:
📦 GitHub:
📋 프로토콜:
📚 문서:
AI 에이전트를 구축하고 거버넌스가 내장된 시스템을 원한다면 한 번 시도해 보세요. 유용하다고 생각되면 레포지토리에 ⭐ 별을 달아 주세요.
읽어 주셔서 감사합니다! 댓글로 질문에 답변해 드리겠습니다.