AI VIDEO BRIEFING

AI 운영체제 직접 구축하기: 웹훅·스케줄·에이전트 3계층 아키텍처와 컨텍스트 허브 설계법

AI 엔지니어 데이브 에벨라르가 공개한 개인용 AI 운영체제 설계도를 정리했다. 웹훅과 스케줄러, 대화형 에이전트 세 계층을 하나의 인프라 위에 올리고 마크다운 컨텍스트 허브를 연결하는 방식, 그리고 비용과 보안 관리 요령을 함께 다룬다.

남의 에이전트 저장소를 복제하지 마라: 'AI 운영체제'를 3계층으로 직접 짓는 법 영상 대표 이미지

핵심 메시지

  • 인기 있는 에이전트 하네스 저장소를 그대로 복제해 API 키와 개인정보를 넘기는 방식은 키 유출·데이터 유출 사고로 이어지기 쉽다.
  • AI 운영체제는 트리거(웹훅), 스케줄(크론), 에이전트(대화형) 세 계층으로 나누면 새 기능을 추가할 때마다 시스템을 다시 만들 필요가 없다.
  • 세 계층을 같은 인프라 위에 올려야 에이전트가 웹훅을 호출하고 크론 작업 결과를 다시 컨텍스트로 가져다 쓸 수 있다.
  • 에이전트가 참조하는 파일 저장소는 폴더마다 한 줄짜리 요약(abstract)과 개요(overview)를 두는 3단계 계층 구조로 만들어 컨텍스트 낭비를 막는다.
  • 무거운 코딩 에이전트를 클라우드에서 돌리면 비용이 빠르게 늘어나므로 최대 턴 수와 예산 상한을 반드시 설정해야 한다.

쉽게 이해하기

최근 개발자 커뮤니티에서는 미리 만들어진 AI 에이전트 하네스 저장소가 유행하고 있다. 영상의 발표자는 이 흐름 자체는 LLM 등장 이후 가장 흥미로운 발전이라고 평가하면서도, 저장소를 그대로 복제해 API 키를 넣고 메신저와 결제 수단 접근 권한까지 넘기는 사용 방식에는 분명한 우려를 표한다. 이미 키가 유출되고 데이터가 새는 사례가 여러 건 보고됐기 때문이다.

그가 제안하는 대안은 남이 만든 저장소를 그대로 쓰는 대신 구조를 뜯어보고 필요한 부분만 자기 환경에 맞게 다시 구현하는 것이다. 초기 LLM 시대에 여러 프레임워크가 빠르게 비대해지면서 불필요한 추상화가 쌓였던 경험과 같은 맥락이다. 직접 만들면 스스로 유지보수할 수 있고 이해할 수 있는 코드베이스가 남는다는 것이 그의 주장이다.

AI 운영체제의 개념은 일반 운영체제와 같다. 새 기능이 필요할 때 앱을 하나 설치하듯이, AI 시스템도 새 역량을 '설치'할 수 있어야지 매번 새 저장소를 배포하고 설정을 다시 해서는 안 된다. 그가 제시한 구성 요소는 멀티모달 입력, 단기·장기 기억, 모델, 마크다운 형태의 스킬과 서브에이전트, 도구와 외부 서비스 연동, 컴퓨터 사용 능력, 그리고 정형·비정형 파일 접근이다.

실제 구현은 클라우드 서버 위에서 도커 컴포즈로 관리된다. 파이썬 기반 백엔드에서 FastAPI가 엔드포인트를 담당하고, Caddy가 리버스 프록시와 HTTPS를 처리한다. 들어온 이벤트는 레디스 큐에 쌓이고 Celery 워커가 실제 작업을 실행하며, Celery Beat가 크론 성격의 예약 작업을 맡는다. 여기에 Claude 에이전트 SDK를 붙여 클라우드에서 코딩 에이전트 인스턴스를 띄운다. 발표자는 언어와 도구 선택 자체는 중요하지 않고 계층 구조를 이해하는 것이 핵심이라고 강조한다.

데이터와 컨텍스트 계층은 이벤트·메타데이터용 PostgreSQL과 에이전트가 직접 탐색하는 파일 시스템으로 나뉜다. 파일 저장소는 정체성(identity), 인박스(inbox), 영역(areas), 프로젝트(projects), 지식(knowledge), 보관(archive)으로 구성되며 모두 마크다운에 가깝게 유지해 에이전트가 읽을 수 있게 한다. 여기에 폴더마다 한 줄짜리 abstract와 짧은 overview를 두는 3단계 로딩 방식을 적용해, 전체 저장소를 2,000토큰 이내로 훑은 뒤 필요한 파일만 열도록 만들었다.

주요 인사이트

  • 세 계층은 용도가 다르다. 개인 업무 자동화는 대화형 에이전트 계층이 적합하고, 사람의 개입 없이 배경에서 돌아야 하는 업무 자동화는 웹훅과 스케줄 계층이 더 안정적이다.
  • 웹훅 처리는 서명 검증 → 데이터베이스 저장 → 백그라운드 워커 위임 순서로 나눠, 요청 수신과 실제 처리를 분리하는 이벤트 기반 구조로 만든다.
  • 에이전트의 성능 수준은 단순 LLM API 호출부터 도구를 붙인 에이전트 프레임워크, 코딩 에이전트 런타임 전체를 서브프로세스로 띄우는 방식까지 스펙트럼으로 존재한다. 빠른 응답이 필요하면 가벼운 모델, 무거운 작업이면 강력한 모델을 배정하면 된다.
  • 발표자는 실험 과정에서 API 비용이 순식간에 50달러에 도달한 경험을 언급하며, 어떤 작업에 무거운 에이전트를 쓸지 신중히 판단해야 한다고 말한다.
  • AI가 코드를 대신 쓰는 상황에서는 오류가 늘어날 수밖에 없으므로 Sentry와 Grafana 같은 모니터링을 처음부터 붙이고, 이벤트를 영구 저장해 디버깅 흔적을 남겨야 한다.

자주 묻는 질문

AI 운영체제의 세 계층은 각각 무엇인가?

1계층은 웹훅과 API 엔드포인트로 들어오는 트리거 기반 동작, 2계층은 크론 잡 형태의 예약 워크플로, 3계층은 메신저 등으로 사용자가 직접 호출하는 대화형 에이전트다. 1·2계층은 배경에서 자동으로 돌고, 3계층은 사용자의 입력에 따라 동적으로 판단한다.

컨텍스트 허브의 3단계 로딩은 왜 필요한가?

에이전트가 파일을 무작정 크롤링하면 필요 없는 내용까지 읽어 컨텍스트 창을 소모한다. 폴더마다 한 줄 abstract, 짧은 overview, 전체 파일 순으로 단계를 두면 에이전트가 먼저 요약만 훑고 필요한 파일만 열 수 있다. 발표자는 이 방식으로 저장소 전체를 2,000토큰 이내로 파악할 수 있다고 말한다.

이 구조를 만들 때 첫 단계로 무엇을 해야 하나?

발표자는 가장 시급한 문제를 해결하는 계층부터 시작하라고 권한다. 개인 작업 자동화가 목적이면 에이전트와 스킬부터, 여러 시스템 연동이나 팀·부서 단위 자동화가 목적이면 웹훅과 스케줄 계층부터 만드는 식이다.

발표자는 이 시스템이 완성됐다고 말하나?

아니다. 웹훅 기반 자동화 같은 부분은 일반적인 소프트웨어 엔지니어링이지만, 에이전트가 스킬과 마크다운 파일로 상호 연결되는 영역은 매우 실험적이며 고객사에는 아직 적용하지 않았다고 밝힌다. 초기에는 결과가 최적이 아닐 때가 많아 사람이 계속 개입해야 한다고도 덧붙인다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식