제목: AI 에이전트도 코드처럼 관리한다, 선언형 도구 Kastor

AI 에이전트의 모델과 프롬프트, 도구 설정이 여러 파일과 플랫폼에 흩어져 있지는 않나요?
Kastor는 이 복잡한 구성을 하나의 검토·버전 관리 가능한 명세로 통합하려는 오픈소스 도구예요.

1. Kastor, AI 에이전트의 Source of Truth

Kastor는 에이전트 구성을 HCL(HashiCorp Configuration Language, 선언형 설정 언어)로 정의하는 Source of Truth 계층이에요. 명세를 검증한 뒤 실행 가능한 프레임워크 코드로 변환하거나, 호스팅된 에이전트의 상태를 관리할 수 있어요.

현재 에이전트 설정은 프레임워크 코드, 프롬프트 파일, 플랫폼 UI, 환경 변수 등에 분산되기 쉽습니다. Kastor는 모델과 프롬프트, 도구, 입력·출력, 의존성, 배포 대상을 하나의 선언형 계약으로 관리해 이런 문제를 줄여줘요.

중요한 점은 생성된 코드가 아니라 Kastor 모듈 자체가 원본이라는 것입니다. 따라서 Git에서 변경 사항을 검토하고, 이전 버전과 비교하며, 동일한 결과물을 반복 생성하기가 쉬워져요.

2. validate, build, plan으로 나뉜 워크플로

Kastor의 동작 방식은 명세를 검증한 다음, 코드 생성 또는 플랫폼 상태 관리로 이어지는 두 가지 경로로 구분돼요. 목적에 따라 필요한 워크플로만 선택할 수 있습니다.

• kastor validate: 참조 관계와 프롬프트 변수를 검사해 배포 전 설정 오류를 발견해요.
• kastor build: 명세를 실행 가능한 LangGraph 프로젝트로 컴파일해요.
• kastor plan: 실제 변경 없이 생성·수정·삭제 항목과 드리프트(외부에서 발생한 상태 변경)를 확인해요.
• kastor apply: 계획된 구성을 대상 플랫폼에 반영하고 로컬 상태 파일을 갱신해요.

예를 들어 프롬프트에서 정의하지 않은 변수를 사용하거나 존재하지 않는 에이전트 출력을 참조했다면 validate 단계에서 확인할 수 있어요. 운영 환경에서는 plan으로 변경 영향을 먼저 검토한 후 apply하는 방식이 유용합니다.

3. .agent, .tool, .prompt로 역할 분리

하나의 Kastor 모듈은 역할별 선언 파일로 구성돼요. 파일 경로가 아니라 model.fast, prompt.weather_system, tool.web_search 같은 주소로 연결한다는 점이 핵심입니다.

• .agent: 모델과 프롬프트, 도구, 입력·출력 및 의존성을 정의해요.
• .tool: 도구 인터페이스와 실제 구현 소스를 연결할 때 사용해요.
• .prompt: 프롬프트 템플릿과 필수 변수를 명시해 누락을 방지해요.
• kastor.hcl·*.kastor: 모델과 빌드 대상, 기본 설정 등 프로젝트 수준 구성을 관리해요.

에이전트 출력 참조는 유효성 검사뿐 아니라 의존성 그래프의 실행 순서에도 반영됩니다. 여러 에이전트가 데이터를 주고받는 콘텐츠 생성 파이프라인이나 리서치 시스템을 설계할 때 특히 유용해요.

4. 빠르게 시작하는 두 가지 방법

처음 사용한다면 kastor init demo로 에이전트, MCP 도구, 프롬프트, 모델, LangGraph 대상을 포함한 기본 모듈을 만들 수 있어요. 생성 직후 별도 수정 없이 kastor validate와 kastor build를 실행할 수 있습니다.

API 키 없이 기능을 확인하려면 내장 메모리 플랫폼을 이용하면 됩니다. examples/weather에서 validate, plan, apply를 실행하면 원격 리소스를 만들지 않고도 상태 비교와 드리프트 탐지 흐름을 체험할 수 있어요.

실제 날씨 에이전트를 실행하려면 Go 1.26+, Python 3.11+, OpenAI 및 Tavily API 키가 필요합니다. mcp_servers.json에 Tavily MCP 서버를 연결하고 OPENAI_API_KEY를 설정한 뒤, 생성된 프로젝트의 main.py에 위치와 날짜를 JSON 입력으로 전달하면 돼요.

5. 런타임이 아닌 상위 관리 계층

Kastor는 에이전트를 직접 실행하는 런타임이 아니며 LangGraph나 Dify를 대체하지 않아요. 빠르게 변하는 에이전트의 전체 제어 루프보다, 그 바깥의 검토·버전 관리·비교 가능한 계약에 집중합니다.

Terraform과도 출발점이 달라요. Terraform이 원격 리소스 관리에 강하다면, Kastor는 그보다 앞선 에이전트 명세부터 정의하고 동일한 명세로 코드 생성과 호스팅 플랫폼 조정을 모두 수행하려 합니다.

현재는 초기 PoC(개념 검증) 단계로 LangGraph 코드 생성, 로컬 상태, 3-way diff, 드리프트 탐지 등이 동작해요. 향후 v0에서는 Vercel eve 코드 생성과 Bedrock AgentCore·Dify 같은 호스팅 플랫폼 제공자가 후보로 검토되고 있습니다.

6. 설치 방법과 현재 주의점

macOS에서는 brew install weirdGuy/tap/kastor로 설치할 수 있으며, 설치 스크립트나 go install도 지원해요. 설치 스크립트는 체크섬을 검증하고 sudo 없이 실행되므로 배포 자동화에도 활용하기 좋습니다.

다만 현재 생성 코드는 참조된 상위 에이전트를 자동 실행하지 않아요. 예를 들어 forecast 출력을 weather 입력이 참조하더라도, 먼저 forecast를 실행한 뒤 결과를 직접 전달해야 합니다.

또한 API 키가 포함된 mcp_servers.json은 Git에 커밋하면 안 됩니다. 명세는 버전 관리하되 자격 증명은 배포 설정으로 분리한다는 원칙을 지키는 것이 안전해요.

마무리하며

Kastor의 핵심은 새로운 런타임을 만드는 것이 아니라, 흩어진 AI 에이전트 설정을 하나의 선언형 계약으로 관리하는 것이에요. 특히 여러 에이전트와 플랫폼을 함께 운영하거나 변경 이력을 리뷰해야 하는 팀이라면 주목할 만합니다.

아직 초기 프로젝트인 만큼 먼저 예제 모듈에서 validate, build, plan 흐름을 체험해 보세요. 에이전트도 일반 소프트웨어처럼 검토하고 재현해야 한다면, Kastor가 적합한 관리 계층인지 판단해볼 수 있을 거예요.