AI 에이전트가 추론할 수 있는 메모리 제공: FalkorDB를 사용한 AI 슈퍼바이저 구축

우리가 그래프 메모리를 사용하여 AI 코딩 에이전트 제어 평면에서 실패, 결정, 의존성 및 검증을 연결하는 방법.

문제점: AI 에이전트는 작업을 완료했지만, 실제로는 일을 끝내지 못할 수 있다.

AI 코딩 에이전트는 코드 작성, 버그 수정, 다단계 작업 완료 능력이 점점 향상되고 있습니다. 하지만 에이전트에게 업무를 위임하는 것은 여전히 문제를 야기합니다: 어떻게 그 일이 실제로 정확하게 끝났는지 알 수 있을까요?

에이전트는 요구사항을 오해하거나, 실패한 접근 방식을 반복하거나, 인계 과정에서 중요한 컨텍스트를 잃거나, 심지어 변경 사항이 테스트를 통과하지 못했음에도 성공했다고 보고할 수 있습니다. 여러 작업이 서로 의존하는 경우, 이러한 문제들은 관리하기가 더욱 어려워집니다.

개발자들은 결국 모든 실행을 감독하게 됩니다: 진행 상황 확인, 실패 진단, 다음에 무엇을 시도할지 결정, 컨텍스트 전송 및 출력 수동 검증 등을 수행합니다.

이러한 과정은 저희로 하여금 간단한 원칙을 중심으로 AI Supervisor를 구축하도록 이끌었습니다:

에이전트의 완료 메시지는 주장(claim)이다. 증거가 무엇이 검증될 수 있는지를 결정한다.

사용자가 고립된 에이전트 실행을 관리하는 대신, 임무(mission)를 제출합니다. AI Supervisor는 작업을 계획하고, 호환 가능한 에이전트를 조정하며, 실행을 모니터링하고, 복구 처리를 하며, 승인 기준에 따라 결과를 평가합니다.

그래프 메모리가 필요한 이유?

저희의 첫 번째 과제는 단순히 실행 이력을 저장하는 것이 아니었습니다. 그것은 한 이벤트가 다른 이벤트에 어떻게 영향을 미치는지 표현하는 것이었습니다.

실패한 코딩 작업을 생각해 봅시다. 그 실패 자체도 중요하지만, 뒤따르는 질문들 역시 중요합니다:

• 어떤 실행이 실패를 발생시켰는가?
• 슈퍼바이저는 이에 대응하여 어떤 결정을 내렸는가?
• 다음 시도를 위해 어떤 에이전트가 선택되었는가?
• 작업이 궁극적으로 검증되었는가?
• 결과를 뒷받침하는 증거는 무엇인가?

연결되지 않은 로그들의 집합은 이러한 관계들을 따라가기 어렵게 만듭니다. 저희는 임무 이력이 연결되고 쿼리 가능하기를 원했습니다.

AI 슈퍼바이저를 위한 그래프 메모리 및 관계 계층으로 FalkorDB를 선택했습니다. SQLite는 애플리케이션 상태 처리를 계속 담당하는 반면, FalkorDB는 미션(missions), 태스크(tasks), 실행(executions), 실패(failures), 결정(decisions), 핸드오프(handoffs), 그리고 검증 증거(verification evidence) 전반에 걸친 관계를 나타냅니다.

실행 이력을 그래프로 변환하기

우리는 미션의 중요한 부분들을 Mission, Task, Execution, ExecutionEvent, Decision, Handoff, Verification, Evidence와 같은 그래프 엔티티(graph entities)로 모델링합니다.

관계(Relationships)는 이러한 엔티티들이 어떻게 연결되는지를 표현합니다:

• DEPENDS_ON: 태스크 의존성을 나타냅니다.
• FAILS_WITH: 실행을 실패 이벤트에 연결합니다.
• RESPONDS_TO: 감독 결정(supervisory decision)을 유발한 이벤트에 연결합니다.
• SELECTS: 에이전트 선택 기록입니다.
• TRANSFERS_CONTEXT: 핸드오프 중 컨텍스트 전이를 나타냅니다.
• EVALUATES 및 EVALUATES_EXECUTION: 검증을 태스크와 특정 실행에 연결합니다.
• SUPPORTED_BY: 검증을 지원하는 증거에 연결합니다.

이러한 관계들은 단순히 무엇이 일어났는지에 대한 이력 이상의 것을 제공합니다. 그것은 왜 일어났고 그 후에 무엇이 뒤따랐는지를 조사하기 위한 구조를 제공합니다.

완료와 검증의 차이점

우리의 가장 중요한 설계 결정 중 하나는 태스크 의존성(task dependencies)에 관한 것입니다.

만약 에이전트가 어떤 태스크가 완료되었다고 보고한다고 가정해 봅시다. 그것이 그 출력물이 정확하다는 것을 자동으로 의미하지는 않습니다. 변경 사항은 컴파일될 수는 있지만 테스트를 통과하지 못할 수도 있고, 구현체는 수용 기준(acceptance criterion)을 놓칠 수도 있습니다.

AI 슈퍼바이저는 완료와 승인된 검증(accepted verification)을 구분합니다. 의존하는 태스크는 필요한 선행 검증이 승인될 때까지 차단 상태로 남아 있어야 합니다.

FalkorDB는 이러한 의존성 및 검증 관계를 나타내어 함께 검사할 수 있게 합니다. 이를 통해 어떤 이유로 태스크가 차단되었는지, 그리고 그 검증과 관련된 실행 및 증거가 무엇인지 추적하기가 더 쉬워집니다.

더 넓은 교훈은 에이전트 협업에는 단순히 낙관적인 상태 메시지(optimistic status messages)가 아니라 명시적인 상태와 증거가 필요하다는 것입니다.

실패를 유용하게 만들기: 파싱 오류 시연

저희는 또한 UTF-8 BOM 파싱 문제를 포함하는 실패 복구 워크플로우를 구축했습니다.

초기 실행에서 파싱 오류가 발생합니다. 이 워크플로우는 해당 실패를 기록하고, 이를 후속 복구 결정, 선택된 에이전트, 다음 시도, 그리고 검증 증거와 연결합니다.

이러한 순서가 중요한 이유는 재시도가 무관한 이벤트로 취급되어서는 안 되기 때문입니다. 이러한 시도들을 연결함으로써 개발자가 무엇이 실패했는지, 시스템이 어떻게 반응했는지, 그리고 최종 결과가 검증되었는지 이해할 수 있는 추적 가능한 이력을 만듭니다.

FalkorDB를 사용하면 이러한 이벤트들이 고립된 기록이 아니라 관련된 그래프 데이터가 됩니다. 영속화된 그래프는 애플리케이션을 재시작한 후에도 검사할 수 있습니다.

이것이 저희가 AI 슈퍼바이저에 바라는 방향입니다: 실패는 복구 및 디버깅을 위한 유용한 맥락을 남겨야 합니다.

그래프 메모리를 가시화하기

저희는 개발자들이 애플리케이션 뒤의 보이지 않는 데이터베이스가 아니라 탐색할 수 있는 무언가인 '그래프 메모리 작업 공간(Graph Memory Workspace)'을 구축했습니다.

이 작업 공간에는 그래프 상태 및 통계, 상호작용 가능한 그래프 탐색기, 노드 및 관계 검사, 실행 및 결정 계보, 활동 기록, 그리고 쿼리 템플릿이 있는 읽기 전용 Cypher 쿼리 인터페이스가 포함됩니다.

이를 통해 개발자들은 임무 관련 관계를 직접 검사할 수 있게 됩니다: 실패를 추적하여 그것이 유발한 결정으로 이동하고, 후속 시도를 검토하며, 검증을 그 근거 증거까지 역추적할 수 있습니다.

그래프는 아키텍처 구성 요소이자 디버깅 도구가 됩니다.

우리가 배운 것들

AI 슈퍼바이저를 구축하면서 저희는 몇 가지 교훈을 얻었습니다.

1. 관계가 기록만큼 중요할 수 있습니다. 실행을 저장하는 것도 유용하지만, 그것을 실패, 복구 결정, 그리고 검증과 연결하면 이력이 훨씬 더 많은 정보를 담게 됩니다.

2. 메모리는 목적이 필요합니다. 단순히 영구 저장소만으로는 AI 시스템의 신뢰성을 높일 수 없습니다. 중요한 질문은 저장된 컨텍스트가 의사결정을 설명하거나, 작업을 조정하거나, 복구를 지원하는 데 도움이 될 수 있는지 여부입니다.

3. 검증(Verification)은 오케스트레이션의 일부여야 합니다. 검증을 나중에 생각하는 것으로 취급하면, 검증되지 않은 작업이 의존적인 태스크로 흘러들어갈 수 있습니다. 승인된 검증을 전제 조건으로 만드는 것은 시도된 작업과 검증된 결과 사이에 더 명확한 경계를 만듭니다.

4. 관측 가능성(Observability)은 아키텍처에 내장되어야 합니다. 개발자는 시스템이 무엇을 했는지뿐만 아니라, 왜 태스크가 차단되었는지, 어떤 이벤트가 의사결정을 촉발했는지, 그리고 결과가 어떤 증거를 뒷받침하는지 이해해야 합니다.

5. 정직한 시스템 상태가 중요합니다. 사용 불가능한 에이전트, 실패한 실행, 검증되지 않은 결과는 성공적인 결과로 제시되어서는 안 됩니다. 신뢰할 수 있는 감독(Supervision)은 가시적인 상태와 추적 가능한 증거를 필요로 합니다.

우리가 구축한 것

AI Supervisor는 프론트엔드에 React, TypeScript, Vite를 사용하고, 백엔드에 Python과 FastAPI를 사용합니다. 실시간 업데이트에는 WebSockets을, 애플리케이션 상태에는 SQLite를, 연결된 미션 메모리에는 FalkorDB를, 그리고 구성된 경우 태스크 격리를 위해 Git Worktrees를 사용합니다.

이 프로젝트는 그래프 저장 계층, 그래프 기반의 미션 관계, 그래프 검사를 위한 API 엔드포인트, Graph Memory Workspace, 그리고 그래프 통합 및 미션 제어 동작을 다루는 테스트들을 포함합니다.

다음 계획은?

우리는 AI Supervisor가 미션 히스토리를 활용하여 복구 결정 지원, 호환 가능한 에이전트 런타임 간 작업 조정, 그리고 결과 독립적 검증에 사용하는 방식을 계속 개선하고 싶습니다.

애플리케이션 상태와 그래프 히스토리의 일관성을 유지하는 것, 인프라 장애를 처리하는 것, 그리고 복구 결정이 이전 시도에 의해 진정으로 정보화되도록 보장하는 것에는 여전히 엔지니어링 과제가 남아 있습니다. 이들은 지속적인 테스트와 개선이 필요한 영역들입니다.

우리의 목표는 단순히 프로젝트가 그래프 데이터베이스를 사용한다고 말하기 위해 이를 추가하는 것이 아닙니다. 그것은 연결된 메모리를 실제 워크플로우에 유용하게 만드는 것입니다.

최종 생각

AI 에이전트는 코드를 생성할 수 있지만, 신뢰할 수 있는 소프트웨어 개발에는 조정(coordination), 복구(recovery), 책임 소재(accountability), 그리고 검증(verification) 또한 필요합니다.

FalkorDB는 이러한 프로세스 뒤에 숨겨진 관계들을 모델링하는 자연스러운 방법을 제공했습니다. 작업(tasks), 실패(failures), 결정(decisions), 인계(handoffs), 증거(evidence)를 연결함으로써, 우리는 임무 기록을 더 쉽게 쿼리하고, 탐색하며, 이해할 수 있게 만듭니다.

AI Supervisor는 하나의 아이디어를 중심으로 구축되었습니다. 작업을 위임하되, 에이전트의 성공 주장을 작업 완료에 대한 증거와 혼동하지 않는 것입니다.

프로젝트: https://github.com/M0izz/AI-Supervisior

실시간 인터페이스: https://ai-supervisior.vercel.app/