우리는 프롬프트를 전달하는 것을 멈췄습니다. 대신 메모리를 공유하기 시작했습니다.

모든 멀티 에이전트 (multi-agent) AI 데모는 거의 비슷해 보입니다.

한 에이전트가 무언가를 생성합니다.
다른 에이전트가 그 출력을 소비합니다.
또 다른 에이전트가 그 체인을 이어갑니다.

체인이 길어질수록, 더 많은 컨텍스트 (context)가 손실됩니다.

우리는 스스로에게 한 가지 질문을 던졌습니다:

만약 AI 에이전트들이 프롬프트를 전혀 전달하지 않는다면 어떻게 될까?

대신...

만약 그들이 메모리 (memory)를 공유한다면 어떨까요?

문제점

현대의 멀티 에이전트 시스템은 우리가 **에이전트 전화 게임 (Agent Telephone Game)**이라고 부르는 문제로 고통받고 있습니다.

모든 에이전트는 다음 에이전트를 위해 정보를 요약합니다.

중요한 아키텍처 (architectural) 결정들이 사라집니다.

요구사항이 표류합니다.

작은 변화가 전체 워크플로우 (workflow)를 재시작하게 만듭니다.

소프트웨어 엔지니어링 (software engineering)의 경우, 이는 심각한 문제가 됩니다.

다음과 같은 간단한 요구사항 하나가:

"PostgreSQL을 MongoDB로 교체하세요."

수십 개의 이전 결정들을 무효화할 수 있습니다.

진화하는 대신...

대부분의 AI 워크플로우는 모든 것을 다시 생성합니다.

우리의 아이디어

프롬프트 체이닝 (prompt chaining) 대신, 우리는 소프트웨어 엔지니어링을 위한 **메모리 우선 운영체제 (Memory-First Operating System)**를 구축했습니다.

모든 전문가 (specialist)는 동일하게 진화하는 메모리로부터 읽고 씁니다.

아무도 직접적으로 통신하지 않습니다.

메모리가 신뢰할 수 있는 단일 원천 (source of truth)이 됩니다.

우리의 AI 전문가들은 다음과 같습니다:

• 💡 아이디어 구상 (Ideation)
• 📄 제품 요구사항 (Product Requirements)
• 🏗 아키텍처 (Architecture)
• ⚙ 기술 스택 (Tech Stack)
• 🚀 구현 전략 (Implementation Strategy)

각 전문가는 Cognee에 의해 구동되는 공유 그래프 (shared graph)에 지식을 기여합니다.

메시지 대신 메모리

다음과 같은 방식 대신:

에이전트 A → 에이전트 B → 에이전트 C

우리는 다음과 같이 구축했습니다:

        공유 메모리 (Shared Memory)

      ↑     ↑      ↑
...

모든 전문가는 단순히 메모리의 최신 상태를 관찰하고, 관련이 있을 때 기여합니다.

프롬프트 전달은 없습니다.

취약한 오케스트레이션 (orchestration)도 없습니다.

이벤트 기반 지능 (Event-Driven Intelligence)

메모리가 변경될 때마다...

시스템은 자동으로 반응합니다.

사용자가 기술 스택 (technology stack)을 업데이트하면:

• 메모리가 변경됩니다.
• 그래프 (Graph)가 업데이트됩니다.
• 관련된 전문가 (specialists)들이 깨어납니다.
• 구현 (Implementation)이 적응합니다.

아무도 "다시 실행"을 누르지 않습니다.

메모리 자체가 워크플로 (workflow)를 오케스트레이션 (orchestrate)합니다.

계획을 넘어 (Beyond Planning)

대부분의 계획 도구들은 문서를 생성한 후 멈춥니다.

우리는 더 나아가고 싶었습니다.

구현 프롬프트 (implementation prompts)가 생성되면, 개발자들은 Claude Code나 Codex와 같은 도구를 사용할 수 있습니다.

구현이 완료된 후...

그 결과물은 다시 우리의 플랫폼으로 가져와집니다.

검증 (verification) 단계에서는 구현 내용이 메모리 내부에 저장된 원래의 의도와 여전히 일치하는지 확인합니다.

만약 드리프트 (drift, 괴리)가 감지되면...

모든 것을 다시 구축하는 대신...

플랫폼은 다음을 생성합니다:

Module 2

↓
...

이를 통해 프로젝트는 처음부터 다시 시작하는 대신 진화할 수 있습니다.

살아있는 메모리 시각화 (Visualizing Living Memory)

우리의 가장 큰 목표 중 하나는 AI 메모리를 가시화하는 것이었습니다.

우리는 다음을 구축했습니다:

• 라이브 지식 그래프 (live knowledge graph)
• 동기화된 메모리 생명주기 타임라인 (synchronized memory lifecycle timeline)

모든 작업은—

• 기억하기 (Remember)
• 회상하기 (Recall)
• 개선하기 (Improve)
• 잊기 (Forget)

프로젝트가 진화함에 따라 시각적으로 나타납니다.

로그 (logs)를 지켜보는 대신...

메모리가 생각하는 과정을 지켜보게 됩니다.

왜 Cognee인가? (Why Cognee?)

Cognee는 우리에게 단순한 저장소보다 훨씬 더 강력한 무언가를 제공했습니다.

그것은 우리의 AI 전문가들에게 지속적이고 진화하는 메모리 (Memory)를 제공했습니다.

그것은 그들이 협업하는 방식을 완전히 바꾸어 놓았습니다.

이제 메모리는 단순한 데이터가 아닙니다.

그것은 전체 엔지니어링 라이프사이클 (Engineering lifecycle)을 조율하는 운영체제 (Operating system)입니다.

우리가 배운 것 (What We Learned)

우리는 또 다른 AI 플래너 (AI planner)를 만들고 있다고 생각하며 이 해커톤을 시작했습니다.

우리는 훨씬 더 흥미로운 무언가를 만들었다는 것을 깨달으며 끝을 맺었습니다.

혁신은 더 많은 에이전트 (Agents)를 추가하는 것이 아니었습니다.

혁신은 프롬프트 전달 (Prompt passing)을 제거하는 것이었습니다.

모든 전문가가 동일하게 진화하는 메모리를 공유할 때...

AI는 실제 엔지니어링 팀과 훨씬 더 유사하게 동작합니다.

읽어주셔서 감사합니다!

만약 당신이 AI 시스템을 구축하고 있다면, 공유 메모리 (Shared memory) 대 프롬프트 체이닝 (Prompt chaining)에 대한 당신의 생각을 듣고 싶습니다.