2026년에는 누구나 에이전트 데모를 가지고 있습니다. 하지만 유료 고객, 감사관, 또는 환자 앞에 내놓을 수 있는 에이전트를 가진 사람은 훨씬 적습니다. "노트북(notebook)에서는 작동했다"와 "매번 안전하게 작동하며, 무엇을 했는지 설명할 수 있다" 사이의 간극은 대부분의 에이전트 프로젝트가 조용히 실패하는 지점이며, 바로 이 간극을 메우기 위해 우리가 Kite를 만들었습니다.

우리는 방금 이를 오픈 소스로 공개했습니다: https://github.com/beevr-labs/Kite. 이 프레임워크는 Python 기반이며, MIT 라이선스를 따르고, pip install kite-agent 명령어로 바로 설치할 수 있습니다. 이것은 Kite가 왜 존재하는지, 그리고 우리가 무엇을 배웠는지에 대한 솔직한 기록입니다.

Kite가 해결하는 문제

우리는 규제 산업(regulated industries)을 위한 프로덕션 소프트웨어를 구축하기 때문에, 항상 동일한 벽에 부딪혔습니다. 대중적인 에이전트 프레임워크(agent frameworks)들은 프로토타입(prototype) 제작에는 훌륭하지만, 프로덕션(production) 단계에서는 고통스럽습니다. LangChain이나 AutoGen에서 첫 번째 작동하는 에이전트를 만드는 것은 설정(configuration) 프로젝트에 가깝고, 일단 그것이 완료되어도 프로덕션에서 실제로 중요한 요소들인 가드레일(guardrails), 재시도(retries), 멱등성(idempotency), 관찰 가능성(observability), 평가(evaluation)를 별도로 결합해야 합니다. 우리는 매 클라이언트마다 동일한 스캐폴딩(scaffolding)을 다시 구축하고 있었습니다. Kite는 우리가 처음부터 가졌기를 바랐던 프레임워크입니다. 안전성에 대해 확고한 견해(opinionated)를 가지고 있으며, 실행 가능한 에이전트로 빠르게 전환해주고, 코드를 읽기에 충분히 작습니다.

모든 것의 핵심이 되는 단 하나의 설계 결정: LLM을 신뢰할 수 없는 것으로 취급하라

이것이 핵심 아이디어입니다. Kite에서 모델은 행동을 제안할 뿐, 실행하지 않습니다. 제어된 커널(kernel)이 에이전트와 실제 세계 사이에 위치하여, 어떤 것이 실행되기 전에 제안된 모든 행동을 정책(policy)에 따라 검증합니다. 따라서 에이전트가 agent.run("rm -rf /")를 호출하기로 결정하더라도, 커널은 파일 시스템이 고통스러운 경험을 하기 전에 이를 거부합니다.

단순해 보일 수 있습니다. 하지만 이는 에이전트에게 실제 도구(tools)를 부여할 때 느끼는 안도감의 차원을 완전히 바꿔 놓습니다. 모델은 당신의 자격 증명(credentials)을 가진 프로세스가 아니라, 당신이 샌드박스(sandbox)화 할 수 있는 플래너(planner)가 됩니다. 민감한 데이터나 실제 인프라에서 에이전트를 실행하는 누구에게나, 이 경계는 데모와 실제로 배포 가능한 것 사이의 차이를 만듭니다.

기본적으로 제공되는 기능

• 다섯 가지 추론 패턴 (Five reasoning patterns), 에이전트별 선택 가능: ReAct (생각, 행동, 관찰), ReWOO (사전에 계획을 세우고 단계를 병렬로 실행하며, Kite 측정 기준 약 2배 더 빠름), Tree of Thoughts (여러 경로 탐색), Plan-Execute (분해 및 실패 시 재계획), 그리고 Reflective (생성, 비판, 개선).
• 프로덕션 안전 프리미티브 (Production safety primitives): 연쇄적인 장애를 중단시키는 서킷 브레이커 (circuit breaker), 모든 것을 즉시 중단해야 할 때 사용하는 킬 스위치 (kill switch, 에이전트별 또는 전역 설정 가능), 그리고 재시도된 작업이 고객에게 중복 결제되지 않도록 작업 ID를 기반으로 하는 멱등성 (idempotency).
• 단순한 수준을 넘어선 검색 (Retrieval that is not a toy): HyDE, 하이브리드 BM25 및 벡터 검색 (vector search), MMR 중복 제거 (deduplication), 그리고 재순위화 (reranking).
• 프롬프트 A/B 테스트 (Prompt A/B testing): 실제 트래픽에 대한 통계적 신뢰 구간을 포함. "새 프롬프트가 더 나은 느낌이다"라는 주장은 배포 기준이 될 수 없기 때문입니다.

작동 방식

가장 빠른 방법은 생성기 (generator)를 사용하는 것입니다. 에이전트를 설명하면 실행 가능한 파일을 얻을 수 있습니다:

pip install kite-agent
export GROQ_API_KEY=your_key
kite generate "research assistant that searches and summarizes" --out agent.py
...

또는 Python에서 직접 구축하고 추론 패턴을 선택할 수 있습니다:

from kite import Kite

ai = Kite()
...

Kite 자체 벤치마크에 따르면 첫 번째 에이전트를 만드는 데 걸리는 시간은 1분 미만입니다 (LangChain이 테스트에서 약 30분, AutoGen이 약 20분이 소요되는 것과 대조적). 또한 콜드 스타트 (cold startup)는 약 50ms 정도입니다 (약 2초 및 약 1초와 대조적). 이 비교 수치는 감사 결과가 아닌 저자들의 수치로 받아들여야 하지만, 설계 의도는 명확합니다: 안전하게 실행되는 에이전트에 빠르게 도달하는 것입니다.

프로덕션에서 에이전트를 운영하며 배운 점

• 모델은 작업의 약 10%에 불과합니다. 나머지 90%는 도구 (tools), 재시도 (retries), 가드레일 (guardrails), 멱등성 (idempotency), 그리고 평가 (evaluation)입니다. 더 나은 모델을 사용한다고 해서 킬 스위치 (kill switch)가 없는 상황을 해결할 수는 없습니다.
• 대부분의 "에이전트 실패"는 변장한 IO 실패입니다. 불안정한 도구 (flaky tool), 중복된 부작용 (side effect), 부분적인 쓰기 (partial write) 등이 이에 해당합니다. 관찰 가능성 (Observability)과 멱등성 (idempotency)은 거의 매번 프롬프트 튜닝 (prompt tuning)을 한 번 더 하는 것보다 효과적입니다.
• 신뢰할 수 없는 구성 요소 (untrusted-component)라는 프레임워크는 제약이 아니라 자유를 줍니다. 커널 (kernel)이 승인 또는 거부를 결정하는 주체가 되면, 에이전트에게 실제 권한을 부여하는 것에 대해 두려움을 느끼지 않게 됩니다.

우리가 이를 오픈 소스로 공개한 이유

블랙박스 (black boxes)로 가득 찬 분야에서, "코드를 읽을 수 있다"는 점은 기밀 유출이 아니라 차별화 요소입니다. 우리는 규제 산업을 위한 프로덕션 AI를 구축하며, 기술 구매자의 신뢰를 얻는 방법은 그들에게 우리의 기술 스택 중 가장 어려운 부분을 믿고 맡기라고 설득하는 대신 직접 검사할 수 있도록 허용하는 것입니다.

Kite는 MIT 라이선스이며 **https://github.com/beevr-labs/Kite**에서 확인할 수 있습니다. 이슈 (Issues)와 PR (Pull Requests)을 환영합니다. 만약 여러분이 프로덕션급 또는 컴플라이언스 (compliance) 준수가 필요한 AI를 구축하고 있으며, 지루한 90%의 작업을 처리해 줄 파트너를 원하신다면, 저희의 작업 방식은 여기에서 확인하실 수 있습니다.

여러분은 프로덕션에서 에이전트를 구축하기 위해 무엇을 사용하고 있으며, 무엇이 계속 문제를 일으키나요? Kite가 어떤 부분에서 도움이 되고 어떤 부분에서 도움이 되지 않을지 궁금합니다.

원문은 beevr.ai에 게시되었습니다.