Undo Beats IQ: Flamehaven을 거버넌스가 적용된 AI 런타임으로 구축 (프롬프트 앱이 아님)

발행: (2026년 1월 6일 오후 04:37 GMT+9)
6 min read
원문: Dev.to

Source: Dev.to

공개: 이 글은 AI의 도움을 받아 작성되었으며, 저자가 검토/확인했습니다. #ABotWroteThis

대부분의 에이전시 AI 데모는 샌드박스에서는 빛나지만, 실제 운영에서는 무너집니다.

운영은 “그냥 프롬프트만”이 아닙니다. 예산, 사고, 드리프트, 감사 요구, 그리고 되돌릴 수 없는 부작용이 포함됩니다.

실제 시스템을 배포해 본 사람이라면 같은 사후 분석 문구를 보았을 겁니다:

“우리는 무슨 일이 일어났는지 재현할 수 없습니다.”

그 한 문장이 신뢰를 무너뜨립니다. 조용한 드리프트나 폭주 비용이 더해지면, “똑똑한” 에이전트는 위험 요소가 됩니다.


The Solo‑Builder Constraint

혼자서 빌드하는 나는 인력을 확장할 수 없습니다. 팀은 프로세스로 운영 위험을 완화합니다: 리뷰, 승인, 런북, 온‑콜 순환. 그 같은 사치가 없을 때, 런타임 자체가 규율 있는 팀원처럼 행동해야 합니다:

  • 잘못된 행동을 거부 (정책에 묶인 실행)
  • 발생한 일을 기록 (재생 가능한 트레이스)
  • 위반을 조기에 감지 (드리프트 + 예산 체크)
  • 복구를 우선시 (롤백을 일급 기능으로)

이는 비전 선언이 아니라 설계 제약입니다.

Core Principles (hard rules, not slogans)

  1. Abstain > Fabricate – 증거나 권한이 충분하지 않다면, 올바른 출력은 중단입니다.
  2. Audit > Opinion – 흔적 없는 주장은 단순 콘텐츠에 불과합니다.
  3. Undo > IQ – 운영에서는 복구가 뛰어남보다 더 가치 있습니다.
  4. Budgeted Intelligence – 추론은 명시적인 비용/컴퓨팅 한도 안에서 이루어져야 합니다.

이 규칙들은 “에이전트 마법”을 엔지니어링된 운영으로 바꿉니다.

Architecture: Treat Execution Like a Compiled Operation

기본 에이전트 패턴은 보통:

prompt → tool calls → side effects → logs (maybe)

Flamehaven은 제어점을 더 앞당깁니다:

spec → policy → context → execution → trace

Minimal Pipeline

flowchart LR
  A[Intent] --> B[SovDef Spec]
  B --> C[Policy Bind]
  C --> D[WorkingContext + context_hash]
  D --> E[Execution]
  E --> F[TraceVault ledger]
  F --> G[Drift/Budget Controller]
  G --> H[Accept / Abstain / Remediate]

SovDef: Declare Boundaries Like Code

“에이전트가 결정한다” 대신, 사전에 제약을 정의합니다:

sovdef:
  objective: "Summarize incident and propose fix"
  tools:
    allowed: ["retriever", "validator", "diff", "ticket_writer"]
    forbidden: ["external_web", "send_email", "delete_data"]
  evidence:
    required: ["source_refs>=2", "validator_pass=true"]
  budgets:
    max_tokens: 6000
    max_cost_usd: 1.20
  rollback:
    required: true

이는 코드 리뷰처럼 에이전트 행동을 검토 가능하게 합니다: 권한, 증거 요구사항, 예산 상한, 롤백 요구사항.

Evidence Pack (What I Ship With Each Release)

각 릴리스에는 다음이 포함됩니다:

  • 레포 링크 + 커밋 해시
  • 최소 재현 단계 (복사‑붙여넣기 가능한 실행 파일)
  • 하나의 실제 실패 사례 + 해결책
  • 트레이스 재생 데모

예시 실패 모드:

제한 없는 툴 호출 → 예산 초과 감지 → 자동 거부 + 롤백 경로 강제 적용

Failure example

Pitfalls & Limitations

  • 일부 외부 변이는 되돌릴 수 없습니다 (예: 이메일 전송). → 기본 금지, 명시적 정책 + 인간 게이트가 있을 때만 허용.
  • 드리프트 감지는 작은 샘플에서 잡음이 많습니다. → 메트릭 + 임계값 + 에스컬레이션 게이트 결합.
  • 트레이싱/검증은 오버헤드가 있습니다 (~10–20 % 토큰). → 3 AM 사고와 재현 불가능한 사후 분석보다 저렴합니다.

Takeaways

Flamehaven은 가장 자율적인 런타임이 되려는 것이 아니라, 가장 생존 가능한 런타임이 되려는 목표를 가지고 있습니다: 감사, 예산, 드리프트, 그리고 실패 처리.

2026년 현재, 격차는 모델 IQ가 아니라 무슨 일이 일어났는지 증명하고 잘못됐을 때 복구하는 능력에 있습니다.

Back to Blog

관련 글

더 보기 »

기술은 구원자가 아니라 촉진자다

왜 사고의 명확성이 사용하는 도구보다 더 중요한가? Technology는 종종 마법 스위치처럼 취급된다—켜기만 하면 모든 것이 개선된다. 새로운 software, ...

에이전틱 코딩에 입문하기

Copilot Agent와의 경험 나는 주로 GitHub Copilot을 사용해 인라인 편집과 PR 리뷰를 수행했으며, 대부분의 사고는 내 머리로 했습니다. 최근 나는 t...